System and Method of Matching Financial Transaction Records to Merchant Records of a Merchant Profile Database

Abstract

A system and method for matching transaction records to merchant records of a merchant profile database is provided, the transaction records containing transaction data of financial presentation devices that are presentable to a plurality of merchants, the transaction data including merchant identifying data that identifies the merchant for the transaction. The system includes a memory storing a plurality of transaction records, a merchant profile database storing a plurality of merchant profile records, a processor, and a match logic module executable by the processor and adapted to recognize a plurality of variations in the merchant identifying data contained in the transaction records, the match logic module operable to match each of the transaction records to an associated merchant profile record in the merchant profile database according to the recognized variations in the merchant identifying data.

Description

FIELD OF THE INVENTION

The present invention relates to data processing systems and more particularly relates to a system and method of matching records of transactions made using a financial presentation device with merchant profile records.

BACKGROUND OF THE INVENTION

When a financial presentation device such as a credit card or debit card is used to make a purchase from a merchant, data pertaining to the transaction including such information as the card account number, the merchant name, the transaction date, and the purchase amount is generated at the merchant location (point of sale) and transmitted electronically to an acquirer. The transaction data is passed from the acquirer to a financial service network and then to an issuer (i.e., the entity the issues the financial presentation device) that provides authorization for the transaction. Upon authorization, the financial service network generates a settlement record of the transaction. The issuer uses the settlement record to generate another transaction record that also includes customer-related (e.g., corporation) data. The issuer-generated transaction records are in turn useful to financial service networks, such as Visanet®, for generating tax reports and other purposes, particularly when matched and enriched with merchant related data (merchant profile records) stored by the financial service network. However, there is a drawback in relying on issuer-generated data, in that it has been found that despite the fact that the transaction records have a standard format, issuers sometimes introduce variations or anomalies into the data of the transaction records, for example, by appending extraneous data in certain fields. These variations, some of which are common, make it a difficult task to match the issuer-generated transaction records with corresponding merchant profile records stored (which would match but for the variations).

Therefore, it is desirable to provide a system and method that correctly matches transaction records with merchant profile records by accounting for known variations.

SUMMARY OF THE DISCLOSURE

According to a first aspect, the present invention provides a system for matching transaction records to merchant records of a merchant profile database in which the transaction records contain transaction data of financial presentation devices that are presentable to a plurality of merchants, and the transaction data includes merchant identifying data that identifies the merchant for the transaction. The system includes a memory storing a plurality of transaction records, a merchant profile database storing a plurality of merchant profile records, a processor, and a match logic module executable by the processor and adapted to recognize a plurality of variations in the merchant identifying data contained in the transaction records. The match logic module is operable to match each of the transaction records to an associated merchant profile record in the merchant profile database according to the recognized variations in the merchant identifying data.

According to a second aspect, the present invention provides a system for matching transaction records to merchant records of a merchant profile database in which the transaction records contain transaction data of financial presentation devices that are presentable to a plurality of merchants, and the transaction data includes merchant identifying data that identifies the merchant for the transaction. The system includes a memory storing a plurality of transaction records, a merchant profile database storing a plurality of merchant profile records, a processor, and a match logic module executable by the processor. The match logic module is adapted to recognize a plurality of variations in the merchant identifying data contained in the transaction records, determine whether the merchant identifying data in a transaction record contains at least one of the plurality of recognized variations, correct the merchant identifying data if it is determined that the merchant identifying data contains at least one of the plurality of recognized variations, and match the transaction records to associated merchant profile records in the merchant profile database based on the corrected merchant identifying data.

According to a third aspect, the present invention provides a method of matching transaction records to merchant records of a merchant profile database in which the transaction records contain transaction data of financial presentation devices that are presentable to a plurality of merchants, and the transaction data includes merchant identifying data that identifies the merchant for the transaction. The method includes receiving the transaction records and matching each of the transaction records to an associated merchant profile record in the merchant profile database according to a plurality of recognized variations in the merchant identifying data.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of an exemplary system for matching transaction records to merchant records of a merchant profile database according to an embodiment of the present invention.

FIG. 2 is a block diagram of an exemplary computer adapted to execute a match logic module according to an embodiment of the present invention.

FIG. 3 is a flow chart of a method of matching transaction records to merchant records of a merchant profile database according to an embodiment of the present invention.

FIG. 4 is a schematic diagram of an exemplary transaction record.

FIG. 5 is a schematic diagram showing detection of a variation in the merchant name field of exemplary merchant identifying data according to an embodiment of the present invention.

FIG. 6 is a schematic diagram showing detection of a phone number variation in the state field of exemplary merchant identifying data according to an embodiment of the present invention.

FIG. 7 is an exemplary tax form 1099-MISC that may be filled using transaction records and merchant profile data according to an embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

For purposes of illustration and clarity, the present invention will be discussed in the context of using a credit card. However, persons of ordinary skill in the art will appreciate that the novel features disclosed herein apply to all types of portable financial presentation devices including, but not limited to, credit cards, debit cards, prepaid cards, electronic benefit cards, charge cards, smart cards, key chain devices, personal digital assistants, cell phones, stored value devices or the like so long as the device can be presented to a seller of goods or services for payment.

A financial presentation device such as a credit card or debit card may be used to purchase goods or services from a merchant in a commercial transaction. At the merchant premises, data pertaining to the transaction is generated using merchant premises equipment (a card reader). The transaction data includes, among other information, card number, card holder name, merchant name, merchant city and state, transaction date and time, and purchase amount information. The transaction data is communicated from the merchant through a financial services network in order to authorize the transaction; more specifically, an authorization request including the transaction data is transmitted from the merchant to an acquirer with which it is affiliated. The request is then transmitted from the acquirer through a secure financial services network, such as Visanet, to the issuer at which the customer's account is held. Typically, the issuer then determines whether to authorize the transaction based on criteria such as whether the customer has reached a credit limit or is in default on payments (although the financial services network may also perform a portion or all of the authorization process).

After the transaction has been authorized, the financial services network generates a settlement record that includes and stores the transaction data. In addition, the issuer generates a record which includes the transaction data and also includes customer-related data to which issuer has access but the financial services network may not (e.g., the corporation name if the customer is a corporation). Financial services networks are expanding their repertoire of services; one of services offered is provision of financial reports such as tax forms for corporate clients. To produce certain tax forms, such as the 1099-MISC form which is used to report transactions for services, merchant related information is required that the issuer is not privy to, and is thus not included in the transaction record. To supplement the transaction record with merchant related data, the financial services network queries a merchant profile database using data that identifies the merchant within a transaction record (‘merchant identifying data’) with the aim of matching the merchant involved in the transaction with a merchant in the merchant profile database. According to some embodiments, the merchant identifying data includes four fields: merchant name, merchant city, merchant state, and merchant category code (MCC). The query attempts to match each of these fields against a merchant profile record in the merchant profile database.

Since the database query typically only returns exact matches, slight variations in any of the fields of the merchant identifying data between a transaction record and a merchant profile record will result in a non-match even though the records may correspond, i.e., the merchants in the two records may be the same. The present invention reduces the probability of corresponding records not matching by detecting known variations in the merchant identifying data that can be corrected or normalized so that the merchant identifying data can then be matched against corresponding merchant profile data in a merchant profile record. According to an embodiment of the present invention, matching logic searches for preset patterns of variations, corrects (removes) the variations in the merchant identifying data of the transaction record, and then re-queries the merchant profile data base using the corrected or ‘normalized’ merchant identifying data. Known types of variations include, among others, extraneous information in the merchant name field (e.g., invoice information, store information, additional character(s)), and phone numbers in the merchant state field that includes non-numerical characters.

An exemplary block diagram of a system 100 for matching transaction records with merchant profile records according to an embodiment of the present invention is shown in FIG. 1. Issuer 102 represents one or more issuer banks that issue financial presentation devices to customers, maintain corresponding account records, and authorize commercial transactions executed with financial presentation devices. When a transaction is executed, data pertaining to the transaction is communicated to the issuer 102 via a financial services network 106. Using the data obtained, the issuer 102 generates a transaction record including the details of the transaction such as the financial presentation device (card) account number, the date and time of the transaction, the dollar amount of the transaction and merchant identifying data including the merchant name, the city and state where the merchant is located and a merchant category code (MCC).

The transaction record may also include additional information concerning the customer account and the commercial transaction. In one or more embodiments, the issuer generates the transaction record in Visa Commercial Format (VCF), the specifications for which may be found in the document “Visa Commercial Format 4.0” published by Visa, Inc. in 2007, which is hereby incorporated by reference. An exemplary transaction record that may be generated by issuer 102 is shown in FIG. 4. As shown, the transaction record includes a transaction number 402, an account number 404, a customer (e.g., corporation) name 405, a transaction date 406, a transaction time 408, the merchant name 410, the city 412 and state 414 where the merchant is located, the MCC 416 (items 410, 412, 414, 416 being collectively labeled as merchant identifying data), a purchase amount 422, customer address 424 and an acquirer bank identification number (BIN) 426.

Transaction records generated by the issuer 102 are received and stored in a VCF transaction record file 104. The issuer 102 may provide the transaction records file 104 on a storage medium such as a magnetic or optical disk, or may communicate the transaction records over a public network or dedicated line preferably having high data transmission capacity.

Upon authorization of the transaction, the transaction data is also stored in the form of a settlement record by the financial services network 106. The financial services network 106 is coupled to a merchant profile database 108 which stores data pertaining to a plurality of merchants. The data stored in the merchant profile database 108 is supplied from acquirers 110 affiliated with the merchants (e.g., banks which maintain the merchants' financial accounts) and also from third party providers 112 that may supply detailed socio-economic information pertaining to the merchants, such as minority or female ownership status. The merchant profile records include such information as the merchant name, street address, city, state, MCC, and tax ID.

A matching logic module 114, described in greater detail below, is a computer-executable program that is coupled to the transaction record file 104 so as to receive transaction records therefrom, and is also coupled to the merchant profile database 108 so as to be able to query the merchant profile database 108 and receive merchant profile records and/or merchant profile data in response.

Referring now to FIG. 2, a block diagram of an exemplary computer 200 including program code for a matching logic module 114 according to an embodiment of the present invention is shown. The computer 200 includes a processor 202, such as a central processing unit (CPU), an I/O interface 204 which sends/receives information via a communication link (not shown) and support circuitry 206. The processor 202, I/O interface 204 and support circuitry 206 are commonly connected to a bus 210 which also connects to a memory 208. The bus 210 is also coupled to the merchant profile database 108.

The memory 208 may include both volatile (RAM) and non-volatile (ROM) memory units and may also include hard disk and backup storage capacity. The memory 208 stores software programs in a program storage portion 212 and stores data in a data storage portion 214. The program storage portion 212 includes the match logic module 114. The match logic module 114 includes software instructions for performing the matching methods according to the present invention and also stores known variations and solutions 216 in the merchant identifying data of transaction records. Transaction records received by the computer 200 from the issuer 102 (via the I/O interface 204) are stored in transaction records data storage 220 which is a portion of the data storage 214 allocated for storing the transaction records locally. Software program modules in the program storage 212 and data from the data storage portion 214 are transferred from memory on as-needed basis as directed by the processor 202.

It is to be appreciated that the computer 200 can be any computer such as a personal computer, minicomputer, workstation, mainframe, or a combination thereof. While the computer 200 is shown, for illustration purposes, as a single computer unit, the system may comprise a group/farm of computers which can be scaled depending on the processing load and database size.

Referring now to FIG. 3, a flow chart of an exemplary method 300 of matching transaction records to merchant records of a merchant profile database according to the present invention is shown. The method begins in step 302. In step 304, a transaction record is received by the match logic module 114 from transaction records data storage 220. In step 306, the match logic module 114 extracts the merchant identifying data in the transaction record, and in step 308, queries the merchant record database 108 with the merchant identifying data. In step 310, the match logic module 114 receives a query response from the merchant profile database indicating whether the merchant identifying data in the query exactly matches data in a merchant profile record of the merchant profile database 108 on a field-by-field basis. In other words, the query response indicates whether the one of the merchant profile records includes the exact same name, city, state and MCC as the merchant identifying data of the transaction record. If the query response includes a merchant profile record, indicating an exact match, in step 320, the match logic module 114 extracts certain fields of data from the merchant profile record for subsequent use.

If the query response from step 310 is empty, indicating that there was no exact match for the merchant identifying data in the merchant profile database, the match logic module 114 determines that the transaction record is ‘unmatched’. It has been found that a significant portion of transaction records that remain unmatched after a first matching round actually contain useful data but have variations that confound ‘exact’ matching logic. To account for such variations, in step 312, the match logic module 114 compares each of the fields of merchant identifying data against known variations or patterns to determine whether each field contains a known variation. FIG. 5 depicts an example comparison 500 in which the merchant name field 502 of a transaction record is compared against several known variations. In the depicted example, the merchant name field contains the data “Federal Express TR0041789823”, where the merchant is Federal Express and the term beginning with ‘TR’ represents a tracking number which is often appended to the merchant name field in transactions involving Federal Express.

Since a merchant profile record for Federal Express will typically not include any tracking information (assuming Federal Express is in the merchant profile database), the merchant name within the transaction record will not match against any merchant profile record. However, when the merchant name field is compared against the variation patterns 504 shown in FIG. 5, it can be seen that “Federal Express TR0041789823” matches the highlighted pattern “[ALPHANUMERIC STRING][2 sp]TR[NUMERIC STRING]” 506, which describes an alphanumeric string followed by two spaces followed, in turn, by a numeric string (without letters). The variation pattern 506 is expressly designed to detect Federal Express data or any other vendor that appends a tracking number starting with “TR” in the manner of the depicted Federal Express record. It is noted that the example shown in FIG. 5 is merely illustrative and should not be taken as representative of actual content of transaction records involving Federal Express Inc.

FIG. 6 depicts another example comparison 600 in which the merchant state field 602 of a transaction record includes a phone number “(212) 854-4704” and the match logic module 114 determines whether the data matches a known format. Merchant location data may be encoded in transaction records as a phone number in one of a number of formats by some merchants or issuers since the area code of a phone number carries state information. For some merchants, such as Internet merchants, corresponding merchant profile records may also include a phone number in the state field (or in another address field). However, the phone numbers stored in the merchant profile records are typically formatted as ten consecutive digits without any special characters such as parentheses or dashes. Therefore, the format of a phone number in the state field in a transaction record may not match the 10 digit format of merchant profile records, and in this case the records will not match. To correct this problem, the merchant state data of an unmatched record is compared against a set of known phone number format variations 604. In the depicted example, the merchant state data “(212) 854-4704” matches the highlighted pattern (###)[sp]###-####, which represents open parenthesis, followed by three consecutive digits, a close parenthesis, a space, three consecutive digits, a hyphen and four further consecutive digits.

Referring again to FIG. 3, in step 314, it is determined whether the merchant identifying data includes a known variation as in the examples of FIGS. 5 and 6. If it is determined that the merchant identifying data includes a known variation in step 314, in step 316 the merchant data is normalized so as to remove the variation using the known variations and solutions 216 stored in the storage 216. If it is determined that the merchant identifying data does not include a known variation, the transaction record remains unmatched and the method branches to step 324. With respect to the example shown in FIG. 5, normalization 508 involves removing the appended portion of the merchant name 502, in particular the two spaces and the tracking number ([2 sp]TR[NUMERIC STRING])which are positioned immediately adjacent ‘Federal Express’. And with respect to the example shown in FIG. 6, normalization 608 involves removing the parentheses, the space and the hyphen, converting the phone number to a sequence of consecutive digits. In general, each variation in the merchant identifying data will have a different corresponding normalization procedure 216 used to convert the variation to the standard or normalized form.

In step 318, the match logic module 114 queries the merchant profile database using the normalized merchant profile data. In step 322 it is determined whether there is a match. If there is a match, the process branches to step 320, and the merchant profile data is extracted for subsequent use, for example, the merchant profile data may be entered into reports and forms as discussed with reference to FIG. 7 below. In an alternate embodiment, the transaction record itself may be changed to reflect the corrected merchant identifying information. One way is to modify the merchant identifying fields while another way would be to append the correct merchant identifying data. After step 320, or if the query of step 322 returns empty, indicating that despite the normalization of the data, there is no match between the merchant identifying data of the transaction record and corresponding data in a merchant profile record, the method branches to step 324, in which it is determined whether there are further transaction records to process. If there are further transaction records to process, the method cycles back to step 304, and if there are no further transaction records to process, the method ends in step 326. In some embodiments of the present invention, the process may be nested, whereby the merchant identifying data may be tested with a different set of variations in each round. In this manner, the number of unmatched transaction records may be filtered down iteratively and the successful matching rate thereby increased.

As noted above, the financial service network 106 (FIG. 1) uses the combination of a transaction record combined with supplemental merchant data extracted from the merchant profile database in producing reports or forms. FIG. 7 shows an example IRS Form 1099-MISC which is used by corporations to report transactions for services to the Internal Revenue Service. The form includes sections where recipient (merchant) information is input including sections for inputting a merchant name 702, merchant street address 704, merchant city and state 706, merchant tax identification number 708 and merchant account number 710. As the data for sections 702, 704, 706, 708 and 710 can be obtained from the merchant profile database (when it is not already included in the merchant identifying data in the transaction record), the input of the information in form 700 may be automated. For example, when a match is found, and a merchant profile record is returned, information can be extracted from the merchant profile record and entered into an electronic version of the form 700. In particular, with respect to the 1099-MISC form depicted, it is important to enter the correct recipient tax identification number 708 and address information, so that the appropriate merchant may be taxed and then notified of the tax imposed on the transaction.

The foregoing specific embodiments represent just some of the ways of practicing the present invention. Many other embodiments are possible within the spirit of the invention. Accordingly, the scope of the invention is not limited to the foregoing specification, but instead is given by the appended claims along with their full range of equivalents.

Claims

1. A system for matching transaction records to merchant records of a merchant profile database, the transaction records containing transaction data of financial presentation devices that are presentable to a plurality of merchants, the transaction data including merchant identifying data that identifies the merchant for the transaction, the system comprising: a memory storing a plurality of transaction records;a merchant profile database storing a plurality of merchant profile records;a processor; anda match logic module executable by the processor and adapted to recognize a plurality of variations in the merchant identifying data contained in the transaction records, the match logic module operable to match each of the transaction records to an associated merchant profile record in the merchant profile database according to the recognized variations in the merchant identifying data.

2. The system according to claim 1, wherein the match logic module is adapted to: determine whether the merchant identifying data contains at least one of the recognized variations;correct the merchant identifying data if it is determined that the merchant identifying data contains at least one of the variations; andquery the merchant profile database with the corrected merchant identifying data.

3. The system according to claim 2, wherein the merchant identifying data includes a merchant name and one of the plurality of variations is an inclusion of one or more extra characters in the merchant name.

4. The system according to claim 3, wherein the merchant identifying data includes a merchant name and a merchant city and the match logic module is adapted to query the merchant profile database using the merchant name and merchant city.

5. The system according to claim 1, wherein the stored transaction records are received from issuers of the financial presentation devices.

6. The system according to claim 1, wherein the match logic module is adapted to obtain merchant information from the matched merchant profile record.

7. The system according to claim 6, wherein the merchant information includes a tax ID of the merchant and a merchant address.

8. The system according to claim 2, wherein the match logic module is adapted to: determine whether the merchant identifying data in a transaction record and corresponding merchant profile data in a merchant profile record match exactly; andfor unmatched transaction records, determine whether the merchant identifying data contains at least one of the recognized variations.

9. The system according to claim 8, wherein the match logic module is adapted to determine whether any of a merchant name, merchant city, merchant state and a merchant category code in the merchant identifying data contain a recognized variation.

10. The system according to claim 9, wherein the match logic module is adapted to output a tax identifier or a merchant address contained in the matched merchant profile record for each transaction record.

11. A system for matching transaction records to merchant records of a merchant profile database, the transaction records containing transaction data of financial presentation devices that are presentable to a plurality of merchants, the transaction data including merchant identifying data that identifies the merchant for the transaction, the system comprising: a memory storing a plurality of transaction records;a merchant profile database storing a plurality of merchant profile records;a processor; anda match logic module executable by the processor and adapted to: recognize a plurality of variations in the merchant identifying data contained in the transaction records,determine whether the merchant identifying data in a transaction record contains at least one of the plurality of recognized variations;correct the merchant identifying data if it is determined that the merchant identifying data contains at least one of the plurality of recognized variations; andmatch the transaction records to associated merchant profile records in the merchant profile database based on the corrected merchant identifying data.

12. The system according to claim 11, wherein the match logic module is adapted to query the merchant profile database with the corrected merchant identifying data to determine a match between merchant profile records of the merchant profile database and the corrected merchant identifying data.

13. The system according to claim 11, wherein the merchant identifying data includes a merchant name and one of the plurality of variations is an inclusion of one or more extra characters in the merchant name.

14. The system according to claim 11, wherein the merchant identifying data includes a merchant name and a merchant city and the match logic module is adapted to query the merchant profile database using the merchant name and merchant city.

15. The system according to claim 14, wherein the match logic module is adapted to output a tax identifier or a merchant address contained in the matched merchant profile record for each transaction record.

16. A method of matching transaction records to merchant records of a merchant profile database, the transaction records containing transaction data of financial presentation devices that are presentable to a plurality of merchants, the transaction data including merchant identifying data that identifies the merchant for the transaction, the method comprising: receiving the transaction records; andmatching each of the transaction records to an associated merchant profile record in the merchant profile database according to a plurality of recognized variations in the merchant identifying data.

17. The method of claim 16, wherein the matching step includes: determining whether the merchant identifying data in the transaction records exactly match corresponding data in associated merchant profile records; andfor those transactions having merchant identifying data that do not have exact matches with corresponding data in an associated merchant profile records, determining whether the merchant identifying data includes one or more of the recognized variations.

18. The method of claim 17, wherein the matching step further includes: correcting the merchant identifying data of the transaction records for which it is determined that the merchant identifying data include one or more of the recognized variations.

19. The method of claim 18, wherein the matching step further includes querying the merchant profile database using the corrected merchant identifying data.

20. The method of claim 16, further comprising: obtaining merchant information from the matched merchant profile records, the merchant information including a tax ID and a merchant address.

21. The method of claim 16, wherein the merchant identifying data includes a merchant name and one of the recognized variations includes an inclusion of one or more extra characters in the merchant name.