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 
       [0001]    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 
       [0002]    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). 
         [0003]    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 
       [0004]    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. 
         [0005]    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. 
         [0006]    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 
         [0007]      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. 
           [0008]      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. 
           [0009]      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. 
           [0010]      FIG. 4  is a schematic diagram of an exemplary transaction record. 
           [0011]      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. 
           [0012]      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. 
           [0013]      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 
       [0014]    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. 
         [0015]    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&#39;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). 
         [0016]    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. 
         [0017]    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. 
         [0018]    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). 
         [0019]    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 . 
         [0020]    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. 
         [0021]    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&#39; 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. 
         [0022]    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. 
         [0023]    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 . 
         [0024]    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 . 
         [0025]    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. 
         [0026]    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. 
         [0027]    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. 
         [0028]    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. 
         [0029]      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. 
         [0030]    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. 
         [0031]    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. 
         [0032]    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. 
         [0033]    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.