HK1199123B - System and method for optimizing the loading of data submissions - Google Patents

Description

System and method for optimizing loading of data submissions

Cross Reference to Related Applications

This international application claims priority from U.S. provisional application No.61/549737 entitled "SYSTEMAND METHOD FOROPTIMIZING THE LOADING OF DATA SUBMISSIONS" filed on 20/10/2011 and U.S. non-provisional application No.13/654267 filed on 17/10/2012, both of which are incorporated herein by reference in their entirety.

Technical Field

The present invention relates to a system and method for optimizing the loading of data submissions into a database. More specifically, the present invention provides systems and methods for detecting changes in data records based on submitting calculated summary values to input data and based on data already in the database.

Background

The consumer loan industry decides on the credit or loan offering or the preferred credit or loan terms to the consumer based on the general principles of risk (i.e., the risk of losing the redemption of a collateral). Credit and loan institutions typically avoid granting credits or loans to high-risk consumers, or may grant credits or loans to such consumers at higher interest rates or under other conditions that are less favorable than those typically given to low-risk consumers. Consumer data (including consumer credit information) is collected and used by credit investigation institutions, financial institutions, and other entities to evaluate reputation and aspects of the consumer's financial and credit history.

New and updated consumer data may be loaded into the credit data database at the credit bureau almost continuously. The consumer data may include information such as indicative data identifying the consumer and financial data (e.g., status of tendered debts, on-time payment records, etc.) relating to a transaction line (e.g., credit line). Computing resources must be devoted to handling the loading of consumer data, such as loading, searching, and matching the data indicative of the incoming load record with the data indicative of the existing data record to determine if any changes have occurred. Such an approach is computationally expensive and inefficient and, accordingly, reduces the overall data loading capacity of the system. This problem may be more pronounced in countries and markets with a large population and/or large data records. Such negative effects may even result in the data loading not being performed within the necessary timeframe and specification.

Accordingly, there is a need for an improved system and method that can efficiently load and process consumer data records that are entered into a database, for example, to increase data loading capacity and reduce the amount of resources occupied by loading a particular data record.

Disclosure of Invention

The present invention seeks to solve the above problems by providing a system and method for detecting changes in data records based on summary values computed on input data submissions and based on data already in the database. The system and method are designed, for example, as: (1) normalizing all or a portion of the input data record to normalize the data prepared for comparison with existing data; (2) calculating a summary value for all or a portion of the input data record for comparison with an existing summary value; and (3) creating or updating a summary value record and/or data record corresponding to the input data record based on the comparison of the summary values.

In a particular embodiment, all or a portion of the received input data record containing the consumer data may be selected and normalized. The summary value may be calculated over the normalized data and may be a hash code, a hash value, a checksum or a Cyclic Redundancy Check (CRC). The calculated summary value may be compared to existing summary values to determine if existing data in the database has changed compared to data in the input data record. If there are no existing summary values, a new data record and a record of the new summary values may be created in one or more databases. If the calculated summary value is not equal to the existing summary value, the existing data record and summary value record may be updated in the database. If the calculated summary value is equal to the existing summary value, no change to the existing summary value occurs. The loading of other data from the input data record may be performed, such as loading updates to the transaction amount into a credit data database or other database.

These and other embodiments, as well as various permutations and aspects, will become apparent from and more fully understood from the following detailed description and drawings, which set forth illustrative embodiments indicating the various ways in which the principles of the present invention may be employed.

Drawings

FIG. 1 is a block diagram illustrating a system for detecting changes in data records based on summary values computed for input data submissions and based on data already in the database.

FIG. 2 is a block diagram of one form of the computer or server of FIG. 1 having a storage element with a computer-readable medium for implementing a system for detecting changes in data records based on submitting calculated summary values to input data and based on data already in the database.

FIG. 3 is a flow chart illustrating operations for detecting changes in data records based on submitting calculated summary values for input data and based on data already in a database using the system of FIG. 1.

Detailed Description

The following description describes, illustrates and exemplifies one or more specific embodiments of the present invention according to its operating principle. This description is not intended to limit the invention to the embodiments described herein, but rather to explain and teach the principles of the invention in a manner that enables one of ordinary skill in the art to understand these principles and, based on this understanding, be able to utilize them not only to practice the embodiments described herein, but also to practice other embodiments that may come to mind in accordance with these principles. The scope of the invention is intended to cover all such embodiments as may come within the scope of the following claims, either literally or under the doctrine of equivalents.

It should be noted that in the description and drawings, identical or substantially similar components may be labeled with identical reference numerals. However, sometimes these components may also be marked with different numbers, for example, where such marking is advantageous for a clearer description. Furthermore, the drawings presented herein are not necessarily drawn to scale, and in some instances the scale may be exaggerated to more clearly describe certain features. Such labeling and mapping does not necessarily imply a potentially substantial purpose. As mentioned above, this description is intended to be construed in an integral and consistent manner with the principles of the invention as taught herein, as understood by those of ordinary skill in the art.

FIG. 1 illustrates a data loading system 100 for detecting changes in data records based on submitting calculated summary values for input data and based on data already in a database according to one or more principles of the present invention. The system 100 may use data from input data records that are intended to be loaded into the credit reporting system 108 and the associated credit data database 112. The system 100 may be part of or include portions of a larger system, such as the International Credit reporting System (iCRS) of the Union Ring (TransUnion).

The various components of the system 100 may be implemented using software executed by one or more servers or computers, such as the computing device 200 with processor 202 and memory 204 shown in fig. 2, which will be described in more detail below. In one embodiment, the system 100 may use the normalization engine 104 and the summary value engine 106 to normalize all or a portion of an input data record submission and calculate a summary value. In another embodiment, the system 100 may compare the calculated summary value to existing summary values to determine if there is a change in the input data record as compared to existing data in the credit data database 112. The existing summary values may be stored in the summary value database 110.

An input data record may be generated and transmitted from the source 102. The input data record may include credit information corresponding to the consumer, such as indicative data identifying the consumer and financial data related to a transaction line (e.g., credit line), such as status of debt repayment, on-time payment records, etc. The source 102 may be a member of a credit investigation institution, including a financial institution, insurance company, utility company, etc. having credit information associated with one or more consumers. The credit information may be based on credits granted to the consumer. For example, a bank may periodically send a record of input data for a customer who has loaned from the bank. The input data record may identify the consumer by indicative data such as name, address, account number, date of birth, identification number, etc. The input data record may also contain data relating to the status of the loan, such as outstanding balances, last payment date, on-time status, and other information. The input data records may be sent, for example, monthly, or more or less frequently. The format of the input data record may be specific and different for a particular market and/or country.

The normalization engine 104 may convert all or a portion of the data in the input data records received from the source 102 into a reduced normalized format to allow for a more fuzzy match of the data. An exact and pattern alternative to using regular expressions may be used in the normalization engine 104 to convert data. In one embodiment, the indicative data in the input data record is normalized by the normalization engine 104 before it is operated on by the summary value engine 106 to calculate the summary value. For example, an example of the abbreviation "NY" may be replaced with "new york". As another example, a number in an address may be spelled out, such as "street 1" becoming "first street". As a further example, the common abbreviation for name may be expanded, e.g., "jr." to "Junior". Thus, the summary value calculated for the indicative data in the input data record may be equal to the previously calculated summary value for the same consumer in the summary value database 110 if the indicative data has not changed.

The summary value engine 106 may calculate a summary value for the normalized data received from the normalization engine 104. As described above, the normalized data may be a version of all or a portion of the data in the input data record. In some embodiments, one or more summary values may be calculated for different portions of the input data record. The summary value may be a hash code, hash value, checksum, Cyclic Redundancy Check (CRC), or other unique representation of the data in the input data record. The summary value may be computed using a deterministic function, such as a hash function (e.g., MD5, SHA-2, etc.), a checksum function or algorithm, or a CRC algorithm (e.g., CRC-32). Where the summary value is a CRC value, the CRC value may be calculated from the input data record by summing the values of the characters in the string of characters of the input data record and dividing the resulting sum by a prime number. For example, the string of input data records may be indicative data.

The existing summary values may be looked up by the summary value engine 106 from a summary value database 110 in communication with the summary value engine 106. The summary value engine 106 may calculate a summary value based on the data in the input data record and then compare the calculated summary value to existing summary values for the same consumer in the summary value database 110. Existing summary values, if any, may be retrieved from the summary value database 110 based on the lookup key. In one embodiment, data segments from the input data records may be used as lookup keys to find existing summary values in the summary value database 110. The data fields used as lookup keys may include account number, member KOB (business class) and code, account type, ownership indicator, and/or contract type. The data segment may also be used in conjunction with the indicative data segment as a lookup key, for example in some markets the account number may be duplicated. In another embodiment, the summary value calculated based on the input data record may be used as a lookup key to the summary value database 110. In this embodiment, in the case where the input data record is different from the existing data, there is no difference between a mismatch with the existing summary value and a failure to find a match for the summary value calculated because there is no existing summary value.

If the summary value engine 106 does not find an existing summary value in the summary value database 110, the input data record may be considered new. A new summary value record containing the calculated summary value may be created in the summary value database 110 corresponding to the consumer. This summary value record may have a lookup key associated with it, as described above, or may only include the calculated summary value. Further, new data records based on the input data records may be created in the credit data database 112 by the credit reporting system 108. The credit reporting system 108 may manage, process, and analyze credit information stored in the credit database 112. Members of the credit bureau may access and query the credit reporting system 108 to retrieve credit data associated with the consumer. For example, when a consumer applies for a loan, a search query may be initiated by a bank so that the bank may review the consumer's credit report to assess the consumer's reputation. The bank may enter the consumer's personal information into the credit reporting system 108 in a search query to retrieve the credit report.

The summary value engine 106 may also retrieve existing summary values corresponding to the consumer from the summary value database 110. In this case, the calculated summary value may be compared to existing summary values to determine if they are equal. If the calculated summary value is not equal to the existing summary value, this indicates that the data record (e.g., the indicative data) of the consumer to which the summary value is applied has changed. In this case, the calculated summary value may replace an existing summary value in the summary value database 110. In addition, the consumer's data records may be retrieved from the credit data storage 112 and compared to the input data records to determine which changes occurred. Changes in the data may be updated in the credit data database 112 based on the input data records. Updates to information in the input data record for which the summary value is not applied (e.g., transaction amount) may also be changed in the consumer's data record in the credit data database 112.

However, if the calculated summary value is equal to the existing summary value, this indicates that no change has occurred in the data record (e.g., the indicative data) of the consumer to which the summary value was applied. In which case the summary value database 110 need not be updated. Furthermore, the consumer's data records need not be updated in the credit data database 112 for the information for which the summary values apply. Updates to information in the input data record for which the summary value is not applied (e.g., transaction amount) may also be changed in the consumer's data record in the credit data database 112.

FIG. 2 is a block diagram of a computing device 200 installed with executable software to facilitate the data loading system 100. One or more instances of computing device 200 may be used to implement any, some, or all of the components in system 100, including normalization engine 104, summary value engine 106, and credit reporting system 108. Computing device 200 includes memory element 204. Memory element 204 may include computer-readable media for implementing system 100 and for implementing specific system things. The memory element 204 may also be used to implement the summary value database 110 and the credit data database 112. Computing device 200 also contains executable software, some of which may or may not be specific to system 100.

In some embodiments, the system 100 is implemented in software as an executable program and is executed by one or more special or general purpose digital computers, such as a mainframe computer, personal computer (desktop, notebook, or other), personal digital assistant, or other handheld computing device. Thus, computing device 200 may represent any computer in which system 100 resides or partially resides.

Generally, for the hardware architecture shown in FIG. 2, the computing device 200 includes a processor 202, a memory 204, and one or more input and/or output (I/O) devices 206 (or peripherals) that are communicatively coupled via a local interface 208. The local interface 208 may be one or more buses or other wired or wireless connections as is known in the art. The local interface 208 may have additional elements, which are omitted for simplicity, such as controllers, buffers (caches), drivers, transmitters, and receivers, to facilitate external communication with other similar or different computing devices. In addition, the local interface 208 may include address, control, and/or data connections to enable internal communication with other computer components.

The processor 202 is a hardware device for executing software, particularly software stored in the memory 204. Processor 202 may be any custom made or commercially available processor, such as, for example, a kernel-series or vPro processor manufactured by Intel corporation, or a Phenom, Athlon, or sempern processor manufactured by ultramicron devices corporation. Where computing device 200 is a server, the processor may be, for example, a Xeon or Itanium processor from Intel or an Opteron-services processor from Superdevice corporation. Processor 202 may also represent multiple parallel or distributed processors working in concert.

The memory 204 may include any one or combination of volatile memory elements (e.g., random access memory (RAM, such as DRAM, SRAM, SDRAM, etc.)) and nonvolatile memory elements (e.g., ROM, hard drive, flash drive, CDROM, etc.). It may comprise electronic, magnetic, optical, and/or other types of storage media. The memory 204 may have a distributed architecture, where various components are located remotely from each other, but still accessed by the processor 202. These other components may reside in devices located elsewhere on the network or in a cloud arrangement.

The software in memory 204 may include one or more separate programs. A stand-alone program comprises an ordered listing of executable instructions for implementing logical functions. In the example of FIG. 2, the software in memory 204 may include system 100 in accordance with the present invention, as well as a suitable operating system (O/S) 212. Examples of suitable commercially available operating systems 212 are the Windows operating system available from Microsoft corporation, Mac OS X available from apple computer, the Unix operating system available from AT & T, or derivatives of Unix, such as BSD or Linux. The operating system O/S212 will depend on the type of computing device 200. For example, if computing device 200 is a PDA or Palm top computer, operating system 212 may be iOS for operating certain devices from apple computers, Inc., PalmOS for devices from Palm computing, Inc., Windows Phone8 from Microsoft, Android from Google, Inc., or Symbian from Nokia, Inc. Operating system 212 fundamentally controls the execution of other computer programs, such as system 100, and provides scheduling, input-output control, file and data management, memory management, and communication control and related services.

If the computing device 200 is an IBM PC compatible computer or similar device, the software in the memory 204 may further include a Basic Input Output System (BIOS). The BIOS is a set of basic software routines that initialize and test hardware at startup, start the operating system 212, and support data transfer between hardware devices. The BIOS is stored in ROM so that the BIOS can execute when the computing device 200 is activated.

Steps and/or elements and/or portions of the present invention may be implemented using a source program, executable program (object code), script, or any other entity comprising a set of instructions to be executed. Further, software implementing the present invention may be written in (a) an object-oriented programming language having data classes and methods, or (b) a procedural programming language having routines, subroutines, and/or functions, such as, but not limited to, C, C + +, C #, Pascal, Basic, Fortran, Cobol, Perl, Java, Ada, and Lua. The components of system 100 may also be written in a proprietary language developed to interact with these known languages.

The I/O devices 206 may include input devices such as a keyboard, mouse, scanner, microphone, touch screen, barcode reader, or infrared reader. It may also include output devices such as a printer, video display, audio speakers or headphone port or projector. The I/O device 206 may also include means for communicating with inputs or outputs, such as a short-range transceiver (RFID, bluetooth, etc.), a telephone interface, a cellular communication port, a router, or other type of network communication device. The I/O device 206 may be built into the computing device 200, or may be external and connected via wireless or via a connecting cable, such as through a universal serial bus port.

When the computing device 200 is in operation, the processor 202 is configured to execute software stored in the memory 204 to transfer data to and from the memory 204, and to generally control the operation of the computing device 200 in accordance with the software. The system 100 and operating system 212, in whole or in part, may be read by the processor 202, buffered at the processor 202, and then executed.

In the context of this document, a "computer-readable medium" may be any means that can store, communicate, propagate, or transport the data objects for use by or in connection with system 100. The computer readable medium can be, for example, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, propagation medium, or any other device with similar functionality. More specific examples (a non-exhaustive list) of the computer-readable medium would include the following: an electrical connection (electronic) having one or more wires, a Random Access Memory (RAM) (electronic), a read-only memory (ROM) (electronic), an erasable programmable read-only memory (EPROM, EEPROM, or flash memory) (electronic), an optical fiber (optical), and a portable compact disc read-only memory (CDROM) (optical). Note that the computer-readable medium could even be paper or another suitable medium upon which the program is printed, as the program can be electronically captured, via, for instance, optical scanning of the paper or other medium, then compiled, interpreted or otherwise processed in a suitable manner if necessary, and then stored in a computer memory. System 100 can be implemented in any type of computer-readable medium for use by or in connection with an instruction execution system or apparatus, such as a computer.

To connect to other computing devices, computing device 200 is equipped with network communication devices and circuitry. In a preferred embodiment, the network communication device comprises a network card, such as an ethernet card or a wireless connection card. In a preferred network environment, a plurality of computing devices 200 on a network are each configured to communicate with one another using the Internet protocol suite (TCP/IP). However, it will be appreciated that various network protocols may be employed, such as IEEE802.11wi-Fi, Address resolution protocol ARP, spanning Tree protocol STP, or fiber distributed data interface FDDI. It should also be understood that while the preferred embodiment of the present invention is for each computing device 200 to have a broadband or wireless connection to the internet (e.g., DSL, cable, wireless, T-l, T-3, OC3, or satellite, etc.), the principles of the present invention are equally applicable through a standard dial-up connection via a modem or other connection means. Wireless network connections are also contemplated, such as wireless ethernet, satellite, infrared, radio frequency, bluetooth, near field communication, and cellular networks.

An embodiment of a method 300 of detecting a change in a data record based on submitting a calculated summary value to input data and based on data already in the database is shown in FIG. 3. If a change in a credit data record has been detected by calculation and comparison of the summary values, the method 300 may result in the creation or updating of a credit data record in the credit data database 112. The credit data storage database 112 may include records of the consumer including indicative data identifying the consumer and data related to a transaction amount (e.g., credit line) (e.g., status of debt repayment, on-time repayment records, etc.). The summary value database 110 may include records of summary values corresponding to records in the credit data database 112, and in particular, summary values that are representative of data in these records. In one embodiment, the summary value is representative of the indicative data in the record. However, the summary value may be representative of any data in the records in the credit data database 112. The normalization engine 104, summary value engine 106, and/or credit reporting system 108 may perform all or part of the method 300.

At step 302, one or more input data records may be received at the data loading system 100 from the source 102. The input data record may include credit information that may be pertinent to the consumer, such as indicative data identifying the consumer and data related to a transaction amount (e.g., credit line) (e.g., status of debt repayment, on-time repayment record, etc.). The source 102 may be a member of a credit investigation institution, including a financial institution, insurance company, utility company, etc. having credit information associated with one or more consumers. All or a portion of the input data record may be selected to calculate a summary value at step 304. In one embodiment, indicative data in the input data record may be selected at step 304. The input data records may be sent from the source 102, for example, monthly, or more frequently or less frequently.

The selected data from step 304 may be normalized by the normalization engine 104 at step 306. The normalization engine 104 may convert selected data from the input data records into a reduced normalized format to allow for a more fuzzy match of the data. The summary value may be computed by the summary value engine 106 on the normalized data at step 308. The summary value engine 106 may calculate a summary value for the normalized data received from the normalization engine 104. In some embodiments, one or more summary values may be calculated for different portions of the input data record. As described above, the summary value may be a hash code, hash value, checksum, Cyclic Redundancy Check (CRC), or other unique representation of the data in the input data record.

After the summary value is calculated, it may be determined at step 310 whether a summary value corresponding to the consumer associated with the input data record already exists in the summary value database 110. The summary value engine 106 may attempt to retrieve an existing summary value from the summary value database 110 using a lookup key, such as another piece of information (e.g., an account number) or a calculated summary value from an input data record. If there is no existing summary value in the summary value database 110 at step 310, the input data record may be classified as new and the method 300 continues to step 312. At step 312, a new summary value record containing the calculated summary value from step 308 may be created in the summary value database 110. In addition, the information in the input data record may be loaded into a new data record in the credit data storage database 112. The method 300 may be completed after performing step 312.

However, if at step 310 there is an existing summary value in the summary value database 110, then the method 300 continues to step 314. At step 314, the existing summary value is loaded from the summary value database 110. If a corresponding data record exists in the credit data database 112, then an existing summary value will exist. In some embodiments, the data records in the credit data database 112 may be further confirmed as matching the input data records by successfully comparing the account numbers in the input data records with the account numbers in the existing data records. The summary value calculated at step 316 and the loaded existing summary value may be compared to determine if they are the same. If they match each other exactly, the calculated summary value and the existing summary value may be determined to be equal. If the calculated summary value and the existing summary value are equal, then at step 320, loading of the input data record is not required and the method 300 is complete. Although the summary values are equal, indicating that the data corresponding to the summary value (e.g., the indicative data) has not changed, other data in the input data record may be updated into the data record in the credit data database 112 at step 320. These other data may include, for example, financial data related to transaction amounts.

Returning to step 316, if the calculated summary value is not equal to the existing summary value, the input data record may be classified as requiring updating and the method 300 continues to step 318. Inequality of the summary value indicates that the data corresponding to the summary value (e.g., the indicative data) has changed. At step 318, the calculated summary value may replace an existing summary value in the summary value database 110. Data records in the credit data database 112 may also be retrieved, compared, and updated to reflect changes in the data from the input data records. In addition, financial data (e.g., trade credits) in the input data record that does not correspond to the summary value may also be updated into the data record in the credit data database 112 at step 318.

When the records in the summary value database 110 and the credit data database 112 are created or updated, the last modified date may be updated to the current date in the applicable database. In some embodiments, the summary value of the corresponding data record may be stored with the data record in the credit data database 112. Changes in information (e.g., indicative data) may be sent to the credit reporting system 108 and credit data database 112 in queries from members of the credit bureau. If such a change in information is detected in the query, this new data may be stored in the credit data database 112 along with the data record. In addition, the summary value attached to the data record may be removed. In this case, when an input data record is received by the data loading system 100 for loading at some time in the future, for example, by the method 300, then the system 100 may detect the absence of a summary value in the corresponding data record in the credit data database 112 and update the appropriate record as needed.

Any method descriptions or blocks in the drawings should be understood as representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or method steps, and alternate implementations are included within the scope of the embodiments of the present invention in which functions may be executed out of order from that shown or discussed (including substantially concurrently or in reverse order), depending on the functionality involved, as would be understood by those reasonably skilled in the art.

It should be emphasized that the above-described embodiments of the present invention, particularly, any "preferred" embodiments, are possible examples of implementations, merely set forth for a clear understanding of the principles of the invention. Many variations and modifications may be made to the above-described embodiments of the invention without departing substantially from the spirit and principles of the invention. All such modifications are intended to be included herein within the scope of this disclosure and the present invention and protected by the following claims.

Claims (20)

1. A method for detecting changes in data records stored in a database using a processor, the method comprising:

receiving, at a processor, an input data record associated with an individual consumer, the input data record comprising indicative data and financial data, wherein the indicative data identifies the consumer;

normalizing, using a processor, at least a portion of the indicative data to produce normalized indicative data;

calculating, using a processor, a summary value based on the normalized indicative data, wherein the summary value is representative of the indicative data;

determining, using a processor, whether an existing summary value associated with the consumer exists in a database by using a lookup key associated with an input data record, the lookup key including a data segment of indicative data and a data segment of financial data;

creating, using a processor, a new data record associated with the consumer in a database if the existing summary value does not exist in the database, the new data record including the summary value, the indicative data, and the financial data; and

if the existing summary value exists in the database, then:

loading, using a processor, the existing summary value in an existing data record associated with the consumer from a database;

determining, using a processor, whether the summary value is equal to the existing summary value;

if the summary value is not equal to the existing summary value:

replacing, using a processor, the existing summary value with the summary value in the existing data record in a database; and is

Storing, using a processor, the indicative data and the financial data in the existing data records in a database; and

storing, using a processor, financial data in the existing data record in a database by altering at least a portion of existing financial data in the existing data record with financial data if the summary value is equal to the existing summary value, wherein the existing financial data comprises non-null data.

2. The method of claim 1, wherein:

the summary value comprises one or more of a hash code, a hash value, a checksum, or a cyclic redundancy check, CRC; and is

Calculating the summary value includes: using a processor, the summary value is calculated by applying a deterministic function to the normalized indicative data.

3. The method of claim 2, wherein the deterministic function comprises one or more of a hash function, a checksum algorithm, or a CRC algorithm.

4. The method of claim 1, wherein the lookup key comprises one or more of a data segment of indicative data, a data segment of financial data, or a summary value.

5. The method of claim 4, wherein the data section of financial data includes one or more of an account number, a member business category, a member code, an account type, an ownership indicator, or a contract type.

6. The method of claim 1, further comprising: if the existing summary value does not exist in the database, storing, using a processor, the lookup key in a new data record associated with the consumer.

7. The method of claim 1, wherein if the summary value is not equal to the existing summary value, storing the indicative data and the financial data in a database comprises:

retrieving, using a processor, indicative data and financial data from the existing data record;

determining, using a processor, a difference between one or more of indicative data or financial data from the input data record and one or more of retrieved indicative data or retrieved financial data; and

updating, using a processor, the existing data record based on the determined difference.

8. The method of claim 1, wherein if the summary value is equal to the existing summary value, storing financial data in a database comprises:

retrieving, using a processor, financial data from the existing data record;

determining, using a processor, a difference between the financial data from the input data record and the retrieved financial data; and

updating, using a processor, the existing data record based on the determined difference.

9. The method of claim 1, wherein normalizing at least a portion of the indicative data comprises: using a processor, the regular expression is evaluated to convert the at least a portion of the indicative data to normalized indicative data.

10. The method of claim 1, wherein:

the financial data includes data relating to a transaction amount associated with the consumer.

11. A system for detecting changes in data records stored in a database, the system comprising:

a processor in communication with a network;

a memory in communication with the processor, the memory to store:

a database;

a normalization engine to:

receiving an input data record associated with an individual consumer, the input data record comprising indicative data and financial data, wherein the indicative data identifies the consumer; and is

Normalizing at least a portion of the indicative data to produce normalized indicative data; and

a summary value engine to:

calculating a summary value based on the normalized indicative data, wherein the summary value is representative of the indicative data;

determining whether an existing summary value associated with the consumer exists in a database by using a lookup key associated with an input data record, the lookup key including a data segment of indicative data and a data segment of financial data;

creating a new data record associated with the consumer in the database if the existing summary value does not exist in the database, the new data record including the summary value, the indicative data, and the financial data; and

if the existing summary value exists in the database:

loading the existing summary value in an existing data record associated with the consumer from a database;

determining whether the summary value is equal to the existing summary value;

if the summary value is not equal to the existing summary value:

replacing said existing summary value with said summary value in said existing data record in the database; and is

Storing the indicative data and the financial data in the existing data records in a database; and

storing financial data in the existing data record of the database by changing at least a portion of existing financial data in the existing data record with financial data if the summary value is equal to the existing summary value, wherein the existing financial data comprises non-null data.

12. The system of claim 11, wherein:

the summary value comprises one or more of a hash code, a hash value, a checksum, or a cyclic redundancy check, CRC; and is

The summary value engine calculates the summary value by applying a deterministic function to the normalized indicative data.

13. The system of claim 12, wherein the deterministic function comprises one or more of a hash function, a checksum algorithm, or a CRC algorithm.

14. The system of claim 11, wherein the lookup key comprises one or more of a data segment of indicative data, a data segment of financial data, or a summary value.

15. The system of claim 14, wherein the data section of financial data includes one or more of an account number, a member business category, a member code, an account type, an ownership indicator, or a contract type.

16. The system of claim 11, wherein the summary value engine is further to store the lookup key in a new data record associated with the consumer if the existing summary value does not exist in a database.

17. The system of claim 11, wherein if the summary value is not equal to the existing summary value, the summary value engine stores the indicative data and the financial data in a database by:

retrieving indicative data and financial data from the existing data record;

determining a difference between one or more of indicative data or financial data from the input data record and one or more of retrieved indicative data or retrieved financial data; and

updating the existing data record based on the determined difference.

18. The system of claim 11, wherein the summary value engine stores financial data in a database if the summary value is equal to the existing summary value by:

retrieving financial data from the existing data record;

determining a difference between the financial data from the input data record and the retrieved financial data; and

updating the existing data record based on the determined difference.

19. The system of claim 11, wherein the normalization engine normalizes at least a portion of the indicative data by evaluating a regular expression to convert the at least a portion of the indicative data to normalized indicative data.

20. The system of claim 11, wherein:

the financial data includes data relating to a transaction amount associated with the consumer.