EP1114380A4

EP1114380A4 - System and method for system to system credit information transmission

Info

Publication number: EP1114380A4
Application number: EP99943734A
Authority: EP
Inventors: David L Wallace; Marguerite Anne Hammond; Judy Headley
Original assignee: Equifax Inc
Current assignee: Equifax Inc
Priority date: 1998-08-20
Filing date: 1999-08-19
Publication date: 2001-11-28
Also published as: AU5677199A; CA2341039A1; WO2000011586A8; WO2000011586A1; WO2000011586A9; EP1114380A1

Abstract

The invention relates to a credit updating system (16) which permits credit files stored in different formats, and possibly in different countries, to be seamlessly exchanged and updated without conversion on the end users' part. A central credit repository (20) stores credit information in a universal format, such as the ICCIF format formulated by Equifax, In., but contains an interpreter module (40) to accept and map data from idiosyncratic foreign credit systems (24) to that database. The client (10a) of the credit system, such as banks issuing credit cards, can specify language, currency denomination, exchange rate and other information according to their needs. System-to-system credit file updating is enhanced.

Description

SYSTEM AND METHOD FOR SYSTEM TO SYSTEM CREDIT INFORMATION TRANSMISSION

Field of the invention The invention relates to consumer and commercial credit transaction database systems.

Background of the Invention In the credit industry, credit issuers need to know the credit history of potential credit recipients, including both consumers and commercial entities. Before issuing credit to a potential new account holder of any type, credit issuers such as banks, department stores, and realty companies typically request information about the history of that potential new account holder's existing accounts. Accordingly, there are automated systems that collect business or personal credit history information and release that information to credit issuers when appropriately requested. These credit reporting systems typically operate as follows. Customers of the credit reporting system (that is, credit grantors) submit information about their account holders to a repository, including consumers and commercial enterprises. As an example, Bank Z, along with other credit issuers, reports current account information for all of its credit account holders including their name, current address, balance and payment history, among other information, to a credit reporting repository which is often a central computerized database. That credit reporting system collects account information from the variety of credit issuers associated with the system, including Bank Z, and records that information in a database. Then, under appropriate circumstances, other credit issuers, consumers or others may request credit history information for a particular consumer or commercial enterprise from the records of the credit reporting system. For instance in the United States that request may be by a bank considering a consumer for a new credit card account. The credit reporting system then generates a report which lists information from various accounts with all credit issuers that are stored in the database for that particular consumer or commercial enterprise. Credit issuers may use that reported information to assess whether to issue credit by using various modeling and scoring algorithms to assess the risk involved in granting the credit.

The credit information recorded by the various collection systems used throughout the world varies from country to country, and even within a single country. For example, information collected in India may vary significantly from information collected in Mexico or the United States. Languages, cultures, and currencies differ in these various countries, and accordingly the types of information collected by credit systems used in these countries also varies. Accordingly, a credit reporting system designed for one reporting format is not capable of accepting information from a customer that provides information in another format. A uniform reporting system does not exist, and more flexible and universal information access is desirable.

Summary of the Invention An object of the invention is to overcome these and other problems with existing credit reporting systems.

Another object of the invention is to provide a uniform system and method for collecting credit information for credit recipients over the world.

Another object of the invention is to provide a system and method that allows system to system communication of credit information. Another object of the invention is to provide a system and method for translating and collecting credit history information from a variety of different formats and storing that data in a credit history database in a uniform manner.

Another object of the invention is to provide a credit history system and method for receiving and using data from existing formats throughout the world. Another object of the invention is to provide a credit history system and method that enables users to generate reports in different languages, formats and currencies.

Another object of the invention is to provide a credit history system and method that displays graphical user interfaces to the user in the user's preferred language.

The invention relates to a system that accepts credit information from any source, translates it into a uniform credit information format and stores that data into a database. Therefore, according to one embodiment, consumer or commercial information from an arbitrary source from anywhere in the world may be stored in and delivered from a single system. The invention may be interfaced to existing credit history systems, because those existing systems do not have to be altered to report a different credit history format. The existing system's format may be translated into the uniform credit information formats and then stored on the system for use in reporting credit history.

Also, because of the variation in language, currency, consumer identification protocols, address and other formats, the invention provides a database that stores an integral code or indicator of the type of data being stored. For example, for currency fields, the numerical amount of the currency may be stored along with an indicator of the currency denomination. Accordingly, credit information including balances from one country may be readily translated into credit information in another country.

Also, the fields stored in the database may be configured to accommodate large names, as used in some countries, or larger currency values for countries having relatively large numerical exchange rates, such as Mexico or Italy, for example. In this manner, the uniform database is able to accept data from all originating countries without having to be individually customized for implementation in different countries.

Additional fields may be stored in the database that permit for better modeling and scoring. Modeling and scoring techniques are used by credit issuers to evaluate the credit worthiness of an application for credit and also assess future risk, fraud possibility, potential profitability and other factors. Accordingly, the database contains a rich and extensible structure of stored fields, such as ten year's worth of account history, rate, balance, past due, and monthly payment amounts, credit limits and highest credit granted, charge off amount and date, payment date, expiration date (particularly for credit card accounts), and defined status messages with associated codes. This is rather than simply providing free-form verbiage that is not useful to score or to sort accounts, as in some prior art systems. Also, the invention may store graphical user interfaces, code tables listing selections to be made by a user, and other textual or graphical information in multiple languages. A user may select the language desired for the graphical user interface. Reports may also be generated in different languages or formats by storing different textual information to be printed on the report and permitting the user to select the language for the report. The currency denomination of the report may also be selected by the user and generated by using the currency codes stored with the credit history data stored in the database.

Brief Description of the Drawings

Fig. 1 illustrates an overall system according to one embodiment of the invention.

Fig. 2 illustrates a translation of account information performed by a system according to the invention. Fig. 3 illustrates a translation of account information performed by a system according to another embodiment of the invention.

Fig. 4 illustrates a data transmission format according to the invention. Fig. 5 illustrates a flow chart of credit update processing according to the invention. Detailed Description of the Preferred Embodiments An overall credit system architecture according to one embodiment of the invention is depicted in Fig. 1. As shown in that figure, the overall credit system 100 comprises an arbitrary number of client customer systems, shown as 10a through lOn although a single customer system 10a may be deployed. Customer systems 10a through lOn communicate with a central credit system 16. Central credit system 16 comprises a storage and retrieval system 18 in communication with one or more databases 20. Additionally, central credit system 16 may communicate with other credit systems 24 housing their own credit records.

Customer systems 10a through lOn constitute a report requesting element 42 which permits any one or more of customer systems 10a through lOn to request reports from central credit system 16 over a network connection. Report requesting element 42 may comprise a GUI selection unit 44 through which users at customer systems 10a through lOn may request credit reports from central credit system 16. Central credit system 16 may generate reports 26 to one of customer systems 10a through lOn based on information stored in database 20, as described in more detail below. Reports 26 may also be generated for and transmitted to other systems or entities including credit systems 24.

According to one embodiment of the invention, credit information may be directly transmitted from customer systems 10a through lOn to central credit system 16 over a network. The network may be or include as a segment any one or more of, for instance, the Internet, an intranet, a LAN (Local Area Network), WAN (Wide Area Network) or MAN (Metropolitan Area Network), a frame relay connection, Advanced Intelligent Network (AJN) connection, a synchronous optical network (SONET) connection, a digital Tl, T3 or El line, Digital Data Service (DDS) connection, DSL (Digital Subscriber Line) connection, an Ethernet connection, ISDN (Integrated Services Digital Network) line, a dial-up port such as a V.90, N.34 or N.34bis analog modem connection, a cable modem, an ATM (Asynchronous Transfer Mode) connection, FDDI (Fiber Distributed Data Networks) or CDDI (Copper Distributed Data Interface) connections, WAP (Wireless Application Protocol), GPRS (General Packet Radio Service), GSM (Global System for Mobile Communication) or CDMA (Code Division Multiple Access) radio frequency links, RS-232 serial connections, IEEE- 1394 (Firewire) connections, USB (Universal Serial Bus) connections or other wired or wireless, digital or analog interfaces or connections.

Accordingly, the implementation of the invention eliminates the need for physical storage media to store the credit information and then ship that physical storage medium to the credit reporting system for input and storage, although such a method of transmission to central credit system 16 may also be used within the scope of the invention.

System to system communication may be performed by customer system 10 transmitting credit information to central credit system 16 data in a predetermined format that is received by central credit system 16. For example, according to one embodiment, as described in more detail below, a format created by Equifax Inc. called the International Consumer and Commercial Input Format (ICCIF) may be used. Version 2 of the ICCLF format, including fields and records, is more fully disclosed as an Appendix to this application.

The ICCLF format may comprise consumer base records and commercial base records, each with a header and trailer record. Consumer base records may comprise fields for consumer base, consumer name, address information, identification information, telephone number, relationship information, historical information, collateral information, account number change, purchased portfolio/sold to segment, employment and other income. The commercial base segment may comprise fields for commercial base, address information, identification information, telephone number, relationship information, commercial base, commercial financial information, commercial name, historical information, collateral information, account number change, and purchased portfolio/sold to.

According to one embodiment of the invention, some or all of this selection of information may be required by central credit system 16. For example, it may be required to provide the header and file trailer, as well as the consumer name, and address for the consumer base segment and the commercial base and commercial name for the commercial base segment.

Fig. 4 illustrates an example of a ICCIF customer transmission including both consumer and commercial base segments. According to one aspect, the character format may be a variable block format. Other fields may be either variable or fixed. A variable block format sends only data, whereas the fixed field format sends a data block equal in size to that allotted, even if much of the content is blank. As shown in Fig. 4, the format used for system to system transfers may comprise a header record, a plurality of consumer base segments, and a trailer record. The format may also comprise a header record, a plurality of commercial base segments and a trailer record. Multiple consumer base segment blocks and commercial base segment blocks may also be sent.

According to the invention, the ICCLF format may employ or embed certain conventions for data transmission. For example, alphabetic fields may be upper case letters. Numeric fields may be right justified and zero filled. If a descriptive field is not available, it may be filled with blanks. If a numeric field is not available, it may be zero filled. For date fields, the data may be formatted in YYYYMMDD format. If a date is not available, the field 01 may be used. For currency fields, whole numbers of currency may be used, for example, dollars without cents. For time stamp fields, the convention YYYYMMDDHHMMSS may be used.

Accordingly, customer systems 10a through lOn may transmit data directly to central credit system 16 in a predetermined format, such as ICCLF. Other customer systems 10 may also directly transmit information to central credit system 16. As depicted in Fig. 1, central credit system 16 may also receive credit information from a customer system 1 Ob that transmits data in a format different from that received by credit system 16. For example, many existing customer systems in the world already have established idiosyncratic reporting formats. Altering such formats may be costly and require a significant overhaul of those existing local systems. The invention enables a central credit system 16 to receive, process, and store information, even from existing systems that transmit information in a different format from ICCLF or other standard protocol.

According to another aspect of the invention, a format translator 14 may be used to receive data from customer systems 10 in a data format 12, translate that data into the predetermined data format, such as ICCLF, and then transmit that information to central credit system 16. Format translator 14 may be an adaptation of customer system 10, may be a stand-alone unit intermediate between customer system 10 and central credit system 16, or may comprise an element of central credit system 16.

As described above, different customer systems may report credit history using different native formats. The formats from different countries may differ and sometimes reporting systems in the same country differ as well. Through format translator 14, credit information from customer systems 10 may be accepted and processed by credit system 16 regardless of the format used by customer system 10 to report that information.

One embodiment of a format translator 14 is illustrated in Figs. 2 and 3. Fig. 2 illustrates a first data format record 50 from a customer system 10, for example. Fig. 2 also depicts a second data format record 52, such as an ICCLF format record. In this embodiment first data format record 50 comprises fields for consumer social security number, consumer name, consumer address, telephone number, and other information. According to one embodiment, format translator 14 may receive first data format record 50 and parse that record to determine the various elements. Each field from first data format record 50 may be assigned to or associated with a field in second data format record 52. That assignment may be predetermined and stored with format translator 14. However, because a direct correspondence between fields may not occur, a lexical analyzer or other modules may be used to detect and find a best fit to place the data format from first data format record 50 into second data format record 52.

For example, in the illustrated first data format record 50, consumer social security number is provided. Second data format record 52, illustrated as an ICCLF format record, does not have a corresponding field for social security number information. Consumer social security number may be predetermined by format translator 14 to be a type consumer identification information, and may be placed in the consumer identification information field in the second data format record 52.

Conversely, some information required by the ICCLF format may not be provided from a single field in the first data format record 50. Accordingly, information in a single field from first data format record 50 may be split into two or more fields in second data format record 52, to make subfields available for association. Likewise, individual fields from first data format record 50 may be combined for the purpose of creating a match to a desired field of second data format record 52. Format translator 14 may also include other components for taking a record in one format and translating it into another format, such as the ICCLF format.

Fig. 3 illustrates another example of format translator 14 translating information into another format. According to the embodiment depicted in Fig. 3(a), a record for Consumer Smith from Mexico is provided and in Fig. 3(b), a record for Consumer Jones is provided. For these two records to be assimilated into the same database, the ICCLF format may be used.

As shown in Fig. 3, the two records contain different fields of information. The Consumer Smith record from Mexico lists Mr. Smith's identification number. Mr. Jones' record, on the other hand, lists his U.S. social security number. Both of these numbers may be considered consumer identification information and may be translated into the identification information field of the ICCLF format record, as depicted in Fig. 3. In doing so, however, that information is simply an abstract number with no reference. Therefore, in order to understand what that number represents, a code may be associated with the input that indicates the type of input. According to one aspect of the invention, ISO (International Standards Organization) codes may be used to designate the country of origin of the record and the specific definition of the associated number. Other codes may also be used to designate the type of input as well.

In some countries, such as Mexico, multiple identification formats may be used. For such countries, additional codes may be used to correspond to the various formats. Different codes may therefore be used to designate social security number, RFC/CURP - Government ID, LMSS Tax LD, Driver's License, Passport, Professional License, Voter Registration, and DUNS, to name examples of codes that may be used for the identification number field.

Similarly, the address field may differ for records from Mexico and the United States. Many countries use different address conventions which therefore may need to be coded so that the information may be more easily stored and searched in ICCIF format.

Also, account balance information from different countries may be reported in the currency of the originating country or even multiple currencies. For example, for Mexico, the customer may desire to receive reports in Peso, Old Peso and US Dollars, for example. Reported currencies may be stored in ICCLF by storing the amount and a code associated with the currency information. Other monetary values may similarly be coded to indicate the currency denomination in which the value is being reported.

Through the use of codes and by providing relatively flexible data field formats, the system according to the present invention is customizable for any credit reporting system. A single credit reporting system and associated database may be used all over the world, such as countries like Mexico, India, Argentina, and the United States, without requiring modification to the database or the format of information being stored therein.

By creating a format translator for translating the format of the existing reporting system and updating the code tables that list available codes for that system, central credit system 16 may be readily implemented and extended. The database structure itself for central credit system 16, such as one based on the ICCIF format, may be used in all countries without the need for modification of the database structure of the data stored. In addition to those data fields with which codes are associated, at least the following additional codes may be used: account type, address type, association termination, business type, collateral description, country name, currency type, employment type, gender, LD type, industry, language, location of incorporation, name suffix, name title, name type (commercial), name type (consumer), occupation type, operating status, other income frequency, other income type, ownership, phone number type, portfolio type, position title, rate, reason left employment, relationship, salary frequency, special comments, and terms frequency. Other codes associated with information fields may also be used within the scope of the invention. Once all of the data is received by central credit system 16 and through the use of storage/retrieval system 18, the information is stored into one or more databases 20. According to one embodiment of the invention, each of databases 20 may comprise a relational database system correlating customer information to consumer and commercial information in the database. For example, the Oracleδ relational database sold commercially by Oracle Corp. may be used. Other databases such as DB2 or other data storage or query formats such as SQL may also be used in the present invention.

Central credit system 16 may also share credit information with other foreign credit systems 24. Foreign credit systems 24 may store information in a different format as well. Accordingly, another format translator 22 may be used to translate information stored at central credit system 16 to another format as used by foreign credit system 24. Again, format translator 22 may comprise an element of central credit system 16, a stand-alone unit or may comprise an adaptation to foreign credit systems 24. Format translator 22 may operate in a reverse fashion to that of format translator 14.

Among other advantages, a credit system implemented according to the invention is able to report a single consumer's credit history even if the consumer moves to different countries. For example, a consumer that is born in Mexico, moves to the United States and then moves to Argentina may have credit history in all of those countries. When that consumer applies for credit in Argentina, according to the invention credit history information stored for that individual may be retrieved from Mexico and the United States and may be reported to an Argentinian credit provider in the local currency. Or, other currency denominations may be presented through use of the currency codes and conversion tables.

Different currency denominations may be presented for different periods of time based on the date of the amounts stored in the database. To provide up- to-date conversion of currency, the conversion tables may be updated periodically based on currency exchange rates at the time. For example, an outstanding balance reported in dollars in the United States could be reported to the Argentinian credit provider in United States Dollars or Argentinian Pesos, or any other currency that the credit provider desires.

As described above, it may be desired to transmit information from central credit system 16 to a foreign credit system 28. In doing so, that foreign credit system may transmit all available information or only provide certain information, such as negative credit information. Accordingly, a field may be stored indicating the type of information contained within a set or subset of the records in the database 20. Only negative information may then be provided to the foreign credit system by selection based on those codes stored with the data. System 100 may comprise another facilitating its use in any part of the world. Specifically, as illustrated in Fig. 1, customer systems 10 may comprise a report requesting element 42. Report requesting element 42 may comprise a software-based module that presents a user at customer system 10 with a plurality of queries for input, thereby allowing the user to select the type of report requested. For example, the user may request a report for a potential new account holder. Report requesting element 42 may then accept relevant information about the potential new account holder from the user at customer system 10, and transmit that information to central credit system 16. Report requesting element 42 may include standalone or network enabled code such Hyper text Markup Language (HTML), Dynamic HTML, Extensible Markup Language (XML), Java, Jini, C, C++, Perl, UNIX Shell, Visual Basic or Visual Basic Script, Virtual Reality Markup Language (VRML) or other technology including compilers, assemblers, interpreters or other computer languages. Report requesting element 42 may also include a graphical user interface

(GUI) for use in connection with a computer display. System 100 may store graphical user interface displays and code tables listing the meaning of the various codes used in the system in multiple languages either at customer system 10, central credit system 16, or both. Through GUI selection unit 44, a user at customer system 10 may then select a preferred language from the stored GUI displays. Accordingly, the system may accommodate all language users through one selection, rather than having to have the system reprogrammed for each different country.

GUI selection unit 44 may cooperate with a database either at customer system 10 or at central credit system 16 that stores the various GUI displays and code tables and may retrieve the selected language GUI display and code table upon request by a user. The format for the GUI retrieved from the database of GUIs is then displayed to the user. A user in Mexico may therefore be able to use report requesting element 42 through GUIs in Spanish, English or Portuguese, for example, if desired. Similarly, customer system 10 may comprise a graphical user interface for enabling a user at customer system 10 to initiate transmission of customer credit information to central credit system 16. GUI selection system 44 may be used to modify the language of GUIs used to generate those requests as well. Another aspect of the invention permits selection of the language of the reports generated by central credit system 16. Central credit system 16 may comprise a report language determination unit 40 to enable selection of the language of the report to be generated. Again, a plurality of report formats may be stored corresponding to each potential language. A user, through customer system 10 or an operator at central credit system 16, may input a selection for the language of the report.

Again, a database table that stores language codes for the report and the actual text corresponding to each language code may be used to store the textual information to be output on the report. The report then uses the language type selected to choose the appropriate textual output for the report when generating the report for that user.

As an example, one user may desire to see a particular potential new account holder's credit history in English and U.S. Dollars, whereas another user, for example, a potential credit issuer in Mexico, may desire to see the credit history in Spanish and Pesos. The English user may select English and U.S. Dollars through report language determination unit 40 which then generates a report listing headings for consumer, account number, address, etc. in English. Further, all currency fields may then be reported in dollars, by collecting the currency fields for that consumer from the database, using the currency code associated with the currency value and translating that currency, if necessary, to U.S. Dollars and outputting that information in the report. Another user in Mexico may desire to see the potential new account holder's credit history in English, but the currency in Pesos (for example, a U.S. bank operating in Mexico). Through the use of codes corresponding to the language of the report and the currency of the report, any combination of reports may easily be generated by report language determination unit without requiring reprogramming for each country in which the system is implemented. A flow chart illustrating the credit update processing of the invention is illustrated in Fig. 5. In step 200, processing begins. In step 202, a request for information or notification of update is received from a client, such as foreign credit system 24. In step 204, the format of the remote credit information format is determined, such as ICCIF or a native format to the foreign location. In step 206, if the credit update or request is not in a universal format such as ICCLF the foreign credit information is translated to universal format including by means of format translator 14, format translator 22. In step 208 the desired credit fields are updated or retrieved. In step 210, the resulting credit fields are translated back to foreign format if necessary. In step 212, the resulting credit information is transmitted to foreign credit system 24 or other client. In step 214, processing ends.

Other implementations and variations of the invention will be apparent to those skilled in the art from the illustrations, specification and practice of the invention disclosed herein. The scope of the invention is accordingly intended to be limited only by the following claims.

Claims

What is claimed is:

1. A method of communicating information between a client source and a network database, comprising the steps of: a. receiving an input of network database update information from the client source at an input port to the database; b. interpreting coding fields within the network database update information to the network database; and c. updating the network database according to the input.

2. The method of claim 1, wherein the step of interpreting comprises the step of examining the coding fields of the input to associate information fields in the input with information fields in the network database.

3. The method of claim 1, wherein the network database comprises a credit file.

4. The method of claim 3, wherein the input comprises information transmitted from a financial record recorded in a different denomination than the information fields of the network database.

5. The method of claim 4, further comprising the step of translating the financial information from a first denomination to a second denomination according to an exchange rate.

6. The method of claim 5, wherein the exchange rate is updated periodically.

7. The method of claim 1 , further comprising the step of communicating an update to a second network database.

8. The method of claim 1, wherein the network database stores records according to the International Consumer and Commercial Input format. 9. The method of claim 1, wherein the database comprises at least one of consumer information and vendor information.

10. The method of claim 1, wherein the information fields of the network database are extensible.

11. The method of claim 1, wherein the network database receives information from the source in a country or origin different than a country of recordation of the information shared by the database.

12. The method of claim 1, wherein the network database comprises a relational database.

13. The method of claim 1, further comprising a step of transmitting information to a foreign country.

14. The method of claim 1, further comprising the step of receiving a report request for credit information in a specified format. 15. The method of claim 14, wherein the specified format comprises at least one of designated language, designated currency denomination and designated other information.

16. A system for communicating information between a client source and a network database, comprising: an input port, the input port being connected to the network database and receiving an input of network database update information from the client source; a processor unit, connected to the input port, the processor unit interpreting coding fields within the network database update information to the network database and updating the network database according to the input.

17. The system of claim 16, wherein the processor unit interprets the coding fields by examining the coding fields of the input to associate information fields in the input with information fields in the network database.

18. The system of claim 16, wherein the network database comprises a credit file.

19. The system of claim 18, wherein the input comprises information transmitted from a financial record recorded in a different denomination than the information fields of the network database.

20. The system of claim 19, wherein the processor unit translates the financial information from a first denomination to a second denomination according to an exchange rate.

21. The system of claim 20, wherein the exchange rate is updated periodically.

22. The system of claim 16, further an output port connected to the network database, the output port communicating an update to a second network database.

23. The system of claim 16, wherein the network database stores records according to the International Consumer and Commercial Input format.

24. The system of claim 16, wherein the database comprises at least one of consumer information and vendor information.

25. The system of claim 16, wherein the information fields of the network database are extensible. 26. The system of claim 16, wherein the network database receives information from the source in a country or origin different than a country of recordation of the information shared by the database.

27. The system of claim 16, wherein the network database comprises a relational database. 28. The system of claim 16, wherein the processor unit transmits information to a foreign country.

29. The system of claim 16, wherein the processor unit receives a report request for credit information in a specified format.

30. The system of claim 29, wherein the specified format comprises at least one of designated language, designated currency denomination and designated other information. Appendix - ICCIF Format

Segment 01 (Header Record)

The Header Record must be the first record on the ICCIF file and should include information necessary to identify the credit data provider. The following tables illustrates the contents of the Header Record.

Segment 02/20 (Consumer Base/Commercial Base)

The Consumer/Commercial Data Record consists of the base segment of the standard reporting format and any optional segments that may be appended.

This section describes each data element in the base segment, which should be used to report the primary borrower.

Segment 04 (Consumer Name)

The following table describes consumer name.

Segment 06 (Address information)

The following table describes address information for the subject.

Segment 08 (identification Information)

Segment 10 (Telephone Number)

Segment 12 (Relationship Information)

Note: This segment is reserved for future use.

Segment 21 (Commercial Financial)

Note: This segment is reserved for future use.

Segment 24 (Commercial Name)

Note: This segment is reserved for future use.

Segment 31 (Historical Information)

Segment 41 (Collateral information)

Note: At least one of these fields must be supplied.

Segment 61 (Account Number Change)

Segment 71 (Purchased Portfolio/Sold To)

Note: This segment is reserved for future use.

Segment 91 (Employment)

Segment 92 (Other Income)

Note: This segment is reserved for future use.

Segment 99 (Trailer Record)

Appendix A: ICCIF Code Types

The following table is an alphabetical list of the ICCIF code types and their values. Note that the "name" field corresponds to the field names in each data segment.

Code Type Value/Description

Industry Code (continued) 011511 - "General Contractor -Residential"

011512 - "Heating, Plumbing, Central Air"

011513 - "Electrical Contractor"

011514 - "Masonry/Stonework/Tiles/Plaster 011515 - "Carpentry"

011516 - "Roofing, Siding, Sheet Metal"

011517 - "Concrete Work Contractor

011518 - "Special Trade Contractor"

011530 - "Agriculture / Forestry"

011531 - "Agricultural Cooperatives"

011532 - "Landscape & Horticulture Services" 011590 - "Miscellaneous Manufacturing"

011700 - "Utilities, Fuel, Transportation"

011711 - "Electric / Gas"

011713 - "Water"

011720 - "Mining / Petroleum"

011730 - "Telephone / Communications"

011750 - "Passenger Transportation"

011751 - "Airline /Air Carriers"

011752 - "Bus Line, Charters, Tour Buses"

011753 - "Suburb/Commuter Passenger Train"

011754 - "Ambulance Services"

011755 - "Taxicabs / Limousines"

011756 - "Steamship / Cruise Line"

011757 - "Boat Rentals & Leases"

011758 - "Marinas, Marine Services / Supplies" 011773 - "Railroads"

011780 - "Freight / Trucking / Railroad"

011781 - "Motor Freight Carrier, Trucking"

011782 - "Courier Services Air/Ground/Freight"

011783 - "Public Warehousing" 011800 - "Insurance"

011900 - "Government / Education"

011910 - "Miscellaneous Government"

011911 - "Local Government"

011912 - "State Government"

011913 - "Federal Government" 011920 - "Military"

011940 - "Miscellaneous Education"

011942 - "College / University"

011943 - "Business School" 011945 - "Vocational Training"

011950 - "Medical / Health Services"