WO2000011574A2

WO2000011574A2 - System and method for updating a credit information database

Info

Publication number: WO2000011574A2
Application number: PCT/US1999/018724
Authority: WO
Inventors: David L. Wallace
Original assignee: Equifax, Inc.
Priority date: 1998-08-20
Filing date: 1999-08-19
Publication date: 2000-03-02
Also published as: AU5568399A; WO2000011574A3

Abstract

An advanced credit reporting and query system receives credit information into a central database (4) to service queries and provide other output. Unlike conventional credit reporting systems, the database is encoded to identify those fields which have changed since the last update (20) to the database, so that rewriting of the same data on the same fields is avoided. Database coherency and detection may be performed by hashing (24) or other techniques.

Description

SYSTEM AND METHOD FOR UPDATING A CREDIT INFORMATION DATABASE

FIELD OF THE INVENTION

The invention relates to systems for storing and updating and credit information.

BACKGROUND OF THE INVENTION

Financial database administrators maintain data for variety of customers. For example, a credit bureau typically maintains a database of consumer credit information for its merchant customers. Credit bureau customers may include banks, credit card providers, mortgage lenders and other loan providers, retail stores and other financial institutions that provide credit to consumers. Existing credit bureau systems incorporate information supplied by the merchant customer (that is, bank, credit card provider, etc.) into periodic updates to be entered into the credit bureau database. Typically, the customer-provided information includes information regarding the individual consumer credit accounts maintained by the merchant customer.

For example, a credit card provider may provide the credit bureau with information regarding the individual consumer credit card accounts that it maintains. This information usually includes consumer name and address, account number and account activity (such as charges incurred, payments made, etc.). Existing credit bureau databases store this customer information using identification fields such as name, address and identification number (e.g. Social Security number).

When updated information is received from the credit card provider, the database is updated to reflect the new account information. Executing that update, however, is complicated. For example, a retail store may provide the credit bureau with an update containing all of its consumer credit accounts. To update the database, existing systems must first look up the first consumer account in the customer- provided update and then replace the information currently stored for the consumer's account history with updated information. Current systems replace the information even if there has been no change from the last update. Once that individual account record is updated, the next consumer in the customer-provided update is located in the database. Information stored for that consumer account is updated for the fields corresponding to the merchant customer providing the update.

This process continues until all of the consumers and commercial entities in the customer-provided update have been updated in the database. Similar updates occur for all other merchant customers of the system, so that the overall database is eventually updated as a whole. This type of system leads to inefficient and time consuming updates for the credit bureau. Other drawbacks exist.

SUMMARY OF THE INVENTION

An object of the invention is to overcome these and other drawbacks in existing credit database systems.

Another object is to provide a system, database structure, article of manufacture and method for efficiently updating a consumer credit information database.

Another object is to provide a system, database structure, article of manufacture and method which provide a consumer credit database organized in a relational manner which allows for quick and efficient updating.

Another object is to provide a system, database structure, article of manufacture and method which provide a database organized with customer tables and consumer tables within a relational database so that entries in the customer tables correspond to entries in the consumer tables.

Another object is to provide a system, database structure, article of manufacture and method which provide a consumer credit information database that updates only information that differs or has changed from that already stored for a particular merchant customer or consumer.

The invention accomplishing these and other objects relates in one regard to a relational database system installed on a computer operating a software module, such as computer readable code that may be stored on a data storage medium such as a disk. The code may then be loaded onto a computer system for operation according to the invention.

The relational database configured according to the invention may be arranged into tables for customers (credit data providers such as credit card companies, banks, and mortgage companies, for example) as well as tables for consumers and commercial entities. These tables may be interrelated so that information in the customer table is related to or associated with entries in the consumer tables and commercial entity tables.

Customer tables may store information regarding credit history information for a variety of consumers and commercial entities in records. The records for the consumer and commercial entities may relate to entries in the consumer and commercial entity tables.

In one aspect of operation, merchant customers provide updates to the system. The database may be updated by filtering each customer's data to identify those consumer accounts that have had activity since the prior update.

The database is preferably updated by locating, in the database, only those accounts with credit update information that differs or has changed from that currently stored in the database. For those accounts with changes, updates may be made by replacing data stored in the customer tables. That information is then reflected in the consumer tables through the correspondence between entries in the customer and consumer tables. In this manner, the speed and efficiency of the update may be increased. Other advantages exist. BRIEF DESCRIPTION OF THE DRAWINGS

Fig. 1 illustrates a schematic of the elements of a system according to an embodiment of the invention.

Fig. 2 illustrates an embodiment of a database system according to the invention.

Fig. 3 illustrates an embodiment of a relational database system according to the invention in more detail.

Fig. 4 illustrates a schematic flow diagram for processing according to the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

An embodiment of the invention is illustrated in Fig. 1. As shown in that figure, the system includes a database administrator 2 that maintains a database 4. Database administrator 2 may comprise a credit bureau system or other consumer credit reporting system receiving information on accounts held by customers 8, which may be include credit card providers (e.g., Visa™, MasterCard™, Discover™, American Express™, or other credit card providers), banks, mortgage lenders or other loan providers, retail merchants or other credit providing entities. Customers 8 provide administrator 2 with credit history information regarding individual consumers and commercial entities that have accounts with that customer.

Credit history information includes consumer identification information and account activity information. Administrator 2 accumulates information from customers 8 and stores that information in database 4. Accordingly, database 4 comprises a collection of information relating to consumer and commercial credit history information. Database 4 may be or include relational database packages. 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 invention. Customers 8 and other systems or entities generate requests to administrator 2 for information regarding potential new account holders, such as the potential new account holder's credit history with other credit providers. In some instances, consumers or commercial entities (consumers 10) may directly approach administrator 2 in order to obtain a report of that consumer's own credit history (indicated by a dashed line in Fig. 1). According to a preferred embodiment of the present invention, database 4 comprises a relational database storing a plurality of customer data tables 6, each corresponding to a discreet credit granting customer. Fig. 2 illustrates a schematic diagram of one embodiment of a configuration of the customer data tables 6 according to the invention. According to this embodiment, each of customer data table 6s contains certain predefined categories or fields of information. For example, customer data tables 6 may include customer tables, consumer name tables, consumer address tables and other categories of information. In one embodiment, each customer data table 6 may be associated with a group of separate consumer data tables 6a in database 4. Fig. 2 depicts that association for one customer data table, customer A. Multiple customer data tables may be provided.

Each table of customer data tables 6 may be further organized into categories 100, with a plurality of records each having entries for each of the categories 100. For example, the categories 100 may include credit account numbers, account history, account holder information (such as name, address, social security number, etc.) and other information. Customer data tables 6 may comprise a record for each consumer 10 (including commercial entities) that has an account with that merchant customer.

Database 4 includes tables for consumers and commercial entities. Those tables may also be organized into records, one record for each consumer or commercial entity. The record in the consumer data tables may include categories for the consumers' name, address, social security number, date of birth, credit accounts, account balances for each account, and payment history. Numerous relationships between customer data tables 6 and their fields are possible.

Customer data tables 6 within database 4 may be arranged in a relational manner. For example, the customer data tables 6 may be arranged with pointers 110 connecting tables in a predefined manner. As shown in Fig. 3, in one embodiment of database 4 may include pointers 110a, HOd, HOe, between fields or records in customer data tables 6 (e.g. an account number field) to fields or records in one or more consumer data tables 6a associated with that table (i.e. referencing the appropriate name in a consumer name data table). Therefore, instead of having an entry in the consumer record for the account balance within a particular one of customer data tables 6, a pointer 110 may be placed in the customer data table 6 pointing to a field in the corresponding particular consumer data table 6a representing the consumer's account balance. By abstracting consumer balance and other entries in this way, updates to records within customer data tables 6 for that consumer's account balance are automatically referenced in the consumer data tables 6a as well.

In this manner, database 4 may handle multiple customers and multiple consumers. Because most consumers have multiple credit accounts with multiple credit issuers (customers), each consumer record may contain pointers to customer data tables 6 for each of the customers (credit granting entities) with whom that consumer has an account. Further, because database 4 maintains credit information for multiple merchant customers, each customer may have a separate table within customer data tables 6 with records for each of the individual consumers or commercial entities that have accounts with that customer. Those records are then linked to the records within consumer data tables 6 for the consumer or commercial entity.

By configuring a database system in this relational manner, information may be searched within a given table of customer data tables 6 for account number, consumer name, or any other field using query techniques known in the art, such as the SQL language. Also, consumers may be located by searching the consumer data tables 6a. A spectrum of information is readily available, as compared to other systems in which data is configured and searchable on only one or a limited number of fields, such as consumer name.

According to another aspect of the invention, other relationships between customer data tables 6 are possible. For example, customer data tables 6 may be arranged to permit an indication that an account having joint account holders is joint through pointers arranged in the fields.

In one aspect, at least one category 100 in customer data tables 6 or consumer data tables 6a may comprise a relationship code. For example, in Fig. 3, a relationship code category is listed as a possible category 100 in a consumer name data tables 6a. The relationship code may comprise a numerical code, for example, a six digit number, or other code to identify a number of predetermined relationships between categories 100. The relationship code may be used to designate various consumer to consumer relationships. For example, "spouse of," "parent of," "sibling of," and "child of may be coded to illustrate relationships between consumers in data base 4. Pointers between categories may be used to associate data entries corresponding to relationship codes.

For example, in Fig. 3, pointer 110b may indicate a spousal relationship between consumers. Consumer to commercial relationships may also be indicated with relationship codes and pointers in consumer data tables 6a or customer data tables 6. For example, codes indicating "owner of," or "principal of may be entered into customer data tables 6 or consumer data tables 6a. Pointer 110c in Fig. 3 indicates an example of a consumer to commercial relationship (owner). Other relationship codes are possible. For example, commercial to consumer codes ("has an owner who is"), commercial to commercial codes (e.g. "operates," "is a parent company of," etc.) and other relationships may be designated.

Relationship codes may also be used to indicate relationships between multiple consumer accounts. For example, consumers may have a joint account at a bank. A code and pointer llOd indicating joint ownership may be incorporated into customer data table 6, indicating multiple consumer names in one of the consumer data tables 6a associated with the account, as shown in Fig. 3. While Fig. 3 illustrates both of the associated consumer accounts as being located with one of consumer data tables 6a, associated consumer accounts could be located in different tables of consumer data tables 6a. Similarly, shared relationships between personal and commercial accounts may also be indicated by a code and pointer 1 lOe, indicating for example joint ownership or authorized agent status for the consumer to the business.

Certain relationship codes may be designated as requiring verification or manual entry or confirmation into the system. For example, spousal, parental and business ownership, partnership or power of attorney relationships may require external verification to designate such a relationship. Other relationships may preferably be automatically determined by the system. For example, shared addresses, joint credit accounts and other relationships may be automatically determined. Other relationships are possible.

The invention provides an efficient manner of updating credit information stored in database 4. One embodiment of a method for updating credit information may be explained with reference to the flowchart of Fig. 4. In step 20, a credit bureau (such as administrator 2) may receive a periodic or other update of credit history information from a customer 8. That update may include account information for multiple consumer and/or commercial entity accounts maintained by that customer. That update may be organized by consumer and commercial entity account number, for example, and delivered in batch, online or other transmission form. The update may occur at predetermined times that may be advantageous for customer 8 and administrator 2. For example, the updates may occur at the end of the customer's billing cycle, monthly, quarterly (e.g. every three months) or some other predetermined time period. Customer updates may be delivered in the form of any suitable computer readable format. For example, the customer 8 may deliver an update to the administrator 2 using a magnetic computer tape or disk, over a computer network (e.g. over the internet), a telephone modem or other computer readable format.

Administrator 2 receives the updates from customers 8 and processes them. According to one embodiment, administrator 2 may, in step 22, access the customer data table 6 stored within database 4 and generate a hash report 112 for each entry in the data table 6 for the customer from whom the update was received, as described below. Also, that hash report 112 may be performed at some other time and stored with the customer data table 6.

Generating a hash report 112 involves reducing a string of characters to a shorter, fixed length value or code, as understood in the art. For example, a data string including a consumer's name may be reduced to a four digit code according to ASCII or other values of the characters of the string, when added together and divided modulo- 16 or by other techniques. The use of a hash report 112 allows for quick and reliable checking of data entries and for changes in those entries.

Similarly, a consumer's address may be reduced to a numerical code in a hash report 112. Subsequent updates of the consumer's address table are each newly hashed. If the hash total for an entry in the updated table does not match the prior numerical total, then the entries do not correspond and an update of the consumer's address may be performed.

In step 22, a hash report 112 may be generated for each consumer or commercial entity account in the update. Processing may be performed to compile hash reports and other functions (e.g. quality assurance checks).

In step 24, hash report totals for each account stored in customer data table 6 for that particular customer may be compared the hash report 112 generated for the update to identify entries requiring updates. At step 26, if the hash report total from the update does not match the prior hash report totals for the accounts stored in the customer data table 6, the entries in the data table for the hash reports that do not match may then be updated with the information provided in the update report. For example, at step 28 consumer data may be updated in the appropriate table 6. If the hash totals match, or at the end of suitable processing (e.g. step 28), the process proceeds to step 30 to update the entries of the subject table of customer data tables 6 for account information for those accounts that logged activity. In such a manner, only those accounts for which a change occurred are identified for accessing and updating. The result is a faster and more efficient updating process.

Further, because the data is stored in a relational manner, updates to account information stored in the customer data tables 6 for a customer automatically update the data table by reference for the consumer or commercial entity that is the owner of the account, in the descendant consumer data tables 6a. Accordingly, updates need only occur to one table and through the relational database, the entire database is correspondingly updated.

Other embodiments and uses of the invention will be apparent to those skilled in the art from consideration of the illustration of the specification and practice of the invention disclosed herein. For example, while a single administrator 2 is described as accessing a single database 4 for inquiries and updating, credit information constituting the overall database may be distributed amongst several storage sites or media, and connected by network or other connections. Similarly, while pointers 110 have been illustrated as associating fields from customer data tables 6 with consumer data tables 6a, pointer links may extend between different ones of customer data tables 6 or different ones of consumer data tables 6a or to other imported data sources. 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 updating a network database, comprising:

(a) receiving input to modify the network database;

(b) modifying one or more information fields of the network database; and

(c) creating a status information field associated with the modified information fields of the network database indicating that the change has occurred in those fields.

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

3. The method of claim 2, wherein the credit database comprises at least one of consumer and vendor credit information.

4. The method of claim 1, wherein step (c) comprises detecting those fields modified by updates to the database and creating a tag field indicating modified fields in the database.

5. The method of claim 4, wherein the step of creating a tag field comprises the step of performing a hash function on the information fields of the network database.

6. The method of claim 5, wherein the step of performing a hash function comprises encoding the characters of an information field as sum, and detecting when the sum has changed.

7. The method of claim 1, further comprising the step of servicing information requests against the network database.

8. The method of claim 1, wherein the information fields comprise a relationship code indicating a relationship between at least two of the information fields.

9. The method of claim 8, wherein the relationship codes designate at least one of verification or manual entry into the network database.

10. The method of claim 1, wherein the update to the network database is performed using an online transmission.

11. The method of claim 1, wherein the update to the network database is performed by delivery of computer readable media.

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

13. A network database system, comprising: an input port, to receive input to modify the network database; a processor unit, connected to the input port, the processor unit modifying one or more information fields of the network database and creating a status information field associated with the modified information fields of the network database indicating that the change has occurred in those fields.

14. The system of claim 13, wherein the network database comprises a credit database.

15. The system of claim 14, wherein the credit database comprises at least one of consumer and vendor credit information.

16. The system of claim 13, wherein the processor unit detects those fields modified by updates to the database and creates a tag field indicating modified fields in the database.

17. The system of claim 16, wherein the processor unit creates the tag field by performing a hash function on the information fields of the network database.

18. The system of claim 17, wherein the hash function is performed by encoding the characters of an information field as sum, and detecting when the sum has changed.

19. The system of claim 13, wherein the processor unit services information requests against the network database.

20. The system of claim 13, wherein the information fields comprise a relationship code indicating a relationship between at least two of the information fields.

21. The system of claim 21 , wherein the relationship codes designate at least one of verification or manual entry into the network database.

22. The system of claim 13, wherein the update to the network database is performed using an online transmission.

23. The system of clam 13, wherein the update to the network database is performed by delivery of computer readable media.

24. The system of claim 13, wherein the network database comprises a relational database.