Patent Document

FIELD OF THE INVENTION  
         [0001]    The present invention relates to systems and methods for the analysis of large quantities of credit transactions and more particularly to a system and method for enabling the effective marketing of credit card services to existing customers.  
         BACKGROUND OF THE INVENTION  
         [0002]    Issuers of debit and credit cards currently perform analysis (“data mining”) of the transactions their customers conduct with respect to the card issued by the issuer. This transactional information is acquired directly by the issuer because of the use of the issuer&#39;s card by the customer. The transactional data can include information with respect to where the customer has used the card, how much has been spent on the card, the type of merchants frequently visited and which card services are most often used by the customer.  
           [0003]    A significant deficiency in the analysis currently performed by issuers is that the analysis is only performed with respect to transactions occurring on the issuer&#39;s own card or cards. In reality, consumers often have several credit and/or debit cards from several issuers. For example, some consumers use a particular credit card for travel because of incentives provided by the issuer of that card, while the same consumer uses a different card for other more general purposes.  
           [0004]    In the current systems and methods of analysis used by issuers, the issuer is ignorant with respect to the consumer&#39;s usage of these other cards and can therefore not make informed decisions about proper marketing strategies targeted towards its existing customers.  
         SUMMARY OF THE INVENTION  
         [0005]    The present invention solves the problems of the prior art systems and methods by performing analysis on credit and debit card transactions conducted by its customers, regardless of the issuer of the actual cards used in the transactions. Complete transaction data is obtained by the issuer from a Merchant Acquirer. A Merchant Acquirer is an agent for the bank of a merchant. The Merchant Acquirer participates in the approval of a request for charges by cardholders at the merchant. In this role, the Merchant Acquirer obtains all transaction data with respect to the merchant&#39;s bank and thus is able to provide the transaction data to the issuer.  
           [0006]    After the transaction data, including credit card numbers, is received by the issuer from the Merchant Acquirer, it is “scrubbed” in order to eliminate transactions on cards issued by the issuer and to eliminate any duplicate non-issuer card numbers. A file of “scrubbed” non-issuer credit card numbers is then sent to a Credit Bureau for processing.  
           [0007]    The Credit Bureau maintains credit profiles on holders of credit/debit cards. Using the scrubbed file from the issuer and its own internal credit profiles, the Credit Bureau identifies which of the non-issuer card numbers in the scrubbed file actually belong to consumers who own a card from the issuer. Once this identification has been made, the Credit Bureau appends the issuer&#39;s card number of the consumer to the non-issuer card number in the scrubbed file. This update file is then returned to the issuer for analysis. In this manner, the issuer is able to identify which of its card holders carry other credit cards, which cards are used most frequently, where the cards are being used and how the consumers uses the issuer&#39;s card with respect to its other credit cards. With this type of information in hand, the issuer can develop marketing plans to target its existing customers in order to induce the customer to use the issuer&#39;s card instead of any non-issuer card.  
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0008]    For the purpose of illustrating the invention, there is shown in the drawings a form which is presently preferred, it being understood, however, that the invention is not limited to the precise arrangement and instrumentality shown.  
         [0009]    [0009]FIG. 1 illustrates the conventional approval process when a cardholder requests a charge at a merchant;  
         [0010]    [0010]FIG. 2 is a high level block diagram illustrating the data flow of the processing of the present invention;  
         [0011]    [0011]FIG. 3 depicts processing of transaction data performed by the issuer;  
         [0012]    [0012]FIG. 4 depicts the processing performed by the Credit Bureau; and  
         [0013]    [0013]FIG. 5 illustrates the updating of the internal database by the issuer.  
     
    
     DETAILED DESCRIPTION OF THE INVENTION  
       [0014]    As way of background, FIG. 1 illustrates the approval process when a consumer/cardholder  100  has requested a charge  105  at a merchant  110 . When the merchant  100  has received the request for the charge  105 , it formats the request  105  and forwards a formatted request for approval  112  to its bank  125 . Typically, instead of the bank  125  directly receiving the request for approval  112 , its agent, a Merchant Acquirer  120  processes the request  112 . The Merchant Acquirer  120  both stores the information constituting the request  112  and forwards the request  122  to an Association  130  such as Visa™ or Mastercard™. The Association  130  then forwards the request  132  to the institution  135  which issued the card to the cardholder  100 . The institution  135  is typically a bank, but is not necessarily always so. This institution  135  will be referred to as the Issuer  135  Because the Issuer  135  maintains the cardholder&#39;s account, it is able to determine if the request for approval ( 112 ,  122 ,  132 ) should be granted or denied. The decision  134 , whether granting or denying approval, is forwarded back to the Association  130 , forwarded  124  to the Merchant Acquirer  120  and returned  114  to the merchant  110 . The flow  137  between the cardholder  100  and the Issuer  135  represents the settlement process (i.e., paying the bill).  
         [0015]    As described above, the Merchant Acquirer  120  in its processing of the request  112  retains data describing the transaction. In this role, a typical Merchant Acquirer  120 , on a monthly basis, obtains transaction data with respect to millions of transactions related to millions of cardholders  100  issued by thousands of Issuers  135 . Prior to the present invention, the Issuer  135  never made use of the transaction data acquired the Merchant Acquirer  120 .  
         [0016]    [0016]FIG. 2 illustrates, at a high level, the data flow of the present invention. On a regular basis, for example monthly, the Issuer  135  requests  205  “raw” transaction data from the Merchant Acquirer  120 . The term “raw” in this context means that the transaction data has not yet been processed by the Issuer  135 . The request  205  can also be a standing request (i.e., the Merchant Acquirer  120  sends the transaction data to the Issuer  135  even without having received a specific request  205 ). In response to the request  205 , the Merchant Acquirer  120  forwards  210  “raw” transaction data to the Issuer  135 . A sample of the types of information contained in the “raw” transaction data is described below in connection with Table 1.  
         [0017]    Upon receipt of the raw transaction data, the Issuer  135  performs a “scrubbing” process on the data as more fully described below with respect to FIG. 3. The scrubbing process eliminates duplicate transactions and stores new transactions related to non-Issuer accounts which may be owned by existing Issuer cardholders. As a result of the scrubbing process, a file is produced which contains transaction records for non-Issuer accounts about which the Issuer  135  has no knowledge whatsoever. In order to identify if any of the transactions were made on non-Issuer cards which belong to an existing customer of the Issuer  135 , the scrubbed file is transmitted  220  to a Credit Bureau  200 . In order to minimize the processing performed by the Credit Bureau  200 , the scrubbed file can consist of merely a listing of the non-Issuer account numbers.  
         [0018]    The Credit Bureau  200  maintains credit files for each of the existing customers of the Issuer  135 . As part of these credit files, the Credit Bureau  200  has a record of the account numbers of all of the cards carried by the customer. The Credit Bureau  200  performs a matching operation in which it identifies transactions having account numbers which belong to customers of the Issuer  135 , regardless of whether or not the account is an Issuer account. If a match is found, the Credit Bureau  200  will append the Issuer&#39;s account number to the transaction record containing the previously unknown account number. The matching process performed by the Credit Bureau  200  is described below in connection with FIG. 5.  
         [0019]    Once the Credit Bureau  200  has completed its matching process, it forwards  225  the file containing appended records back to the Issuer  135 . With the appended file in hand, the Issuer  135  is able to update its internal database to: 1) link new account numbers to existing Issuer account numbers; and 2) update its transaction database with the transactions performed on the newly identified account numbers.  
         [0020]    Table 1 depicts a sample of the type of information (data fields) captured by a Merchant Acquirer  135  with respect to each transaction it processes. Typically, the Merchant Acquirer  135  maintains this information in a database with one record per transaction with each record containing the fields described in Table  
                           TABLE 1                                       1.   Merchant Name           2.   Merchant Account Number, assigned by               Merchant Acquirer           3.   Merchant City           4.   Merchant State, Province, Country           5.   Merchant Category Code (MCC)           6.   Standard Industry Code (SIC)           7.   Merchant Zip Code           8.   Cardholder Account Number           9.   Transaction Amount           10.   Transaction Date           11.   Card Expiration Date           12.   Cardholder ID           13.   Transaction Code           14.   Product Code                      
 
         [0021]    Fields  1  through  7  are each related to the merchant  110  involved in the transaction while fields  8  through  14  relate more specifically to the cardholder  100 . Field  5 , Merchant Category Code (MCC) is an industry code which is more refined than the Standard Industry Code (SIC) record  6 . The cardholder ID, field  12 , indicates whether the signature of the cardholder  100  was verified, a Personal Identification Number (PIN) was entered, or whether it was a mail order transaction. The transaction code, field  13 , indicates the type of transaction which occurred (e.g., sale, credit or cash advance). The product code, field  14 , indicates the type of card used (e.g., American Express™, Discover™, or a bank card). Additional information relating to certain transactions is also retained by the Merchant Acquirer  135  but will not be further described as this information is not essential to the understanding of the present invention.  
         [0022]    The file of raw transaction data  210  forwarded from the Merchant Acquirer  120  to the Issuer  135  can contain some or all of the above described transaction data. Once the raw transaction data  210  has been received by the Issuer  135  from the Merchant Acquirer  120 , the Issuer  135  performs a “scrubbing” process on the raw transaction data as illustrated in FIG. 3.  
         [0023]    As depicted in FIG. 3, the Issuer  135  receives the raw transaction data file  210  from the Merchant Acquirer  120 . The Issuer  135  then, for each transaction record contained in file  210 , performs a scrubbing process in order to eliminate duplicate and/or unnecessary records. The first step  300  in the process is to determine whether or not the transaction relates to a card issued by the Issuer  135 . If the transaction was performed by a cardholder  100  of the Issuer  135 , the record for the transaction is dropped  302 . The information relating to this transaction is retained separately during the conventional process of the Issuer  135  maintaining the cardholder&#39;s account. Accordingly, only transactions which do not belong to the Issuer  135  should remain.  
         [0024]    In step  305 , it is determined if non-issuer account numbers appear more than once. If yes, the duplicate account numbers are eliminated in step  302 . Once duplicate account numbers have been eliminated, the process moves onto step  350  in which it is determined whether or not the card account number contained in the transaction record already exists in the data warehouse  315 . The data warehouse  315  contains, in part, information relating to non-Issuer accounts which have previously been determined to belong to an Issuer&#39;s cardholder. The data warehouse  315  further contains all of the database files required to perform the processing of the present invention. Preferably these database files are maintained in a relational database in order to facilitate relatively quick and simple access to the records contained in the database, both for updating the database files and for performing analysis on the data. Again, in step  350  it is determined whether or not the transaction was performed by an Issuer cardholder who has a non-Issuer account identified in the data warehouse  315 . If the non-Issuer account number is in the data warehouse  315 , the transaction information can be added, at step  310 , to the data warehouse  315 . The records which survive step  350  reflect card account numbers which have not been previously identified as belonging to customers of the Issuer  135 .  
         [0025]    The process of scrubbing described above is repeated for every transaction data record received from the Merchant Acquirer. Once the file (or a copy thereof) containing the transactions records have been scrubbed by the above described process, the file is formatted  360  for transmission to the Credit Bureau  200 . Typically, the only information required by a Credit Bureau  200  to match non-Issuer account numbers to Issuer account numbers is the non-Issuer account number as described in the matching process below.  
         [0026]    [0026]FIG. 4 depicts the matching process performed by the Credit Bureau  200 . The formatted file  400  from the Issuer  135  is received by the Credit Bureau  200 . In step  410 , an account number from the formatted file  400  is compared to the Credit Bureau&#39;s list of other account numbers belonging to customers of the Issuer  135 . If the account does not belong to any existing customer of the Issuer  135 , the record for that account number is thrown away in step  420 .  
         [0027]    If the account number is determined to belong to an existing customer of the Issuer  135 , then the Issuer&#39;s account number for the customer is appended to the record for the previously unmatched account number. Steps  410 - 430  are repeated for every record contained in the scrubbed file  400 . Once the matching process  410 - 430  has been completed, a file  440  containing only the appended records is generated and forwarded  450  back to the Issuer  135 .  
         [0028]    [0028]FIG. 5 illustrates the updating process performed by the Issuer  135  upon receipt of the appended file from the Credit Bureau  200 . As described above, the appended file includes at least records containing the account number of the non-Issuer account and the appended Issuer account number. For each of the records in the appended file, the newly identified non-Issuer account number is added to the data warehouse and is linked to the existing Issuer account in data warehouse. Additionally, the actual transaction information associated with the newly identified non-Issuer account number can be added to data warehouse  315 .  
         [0029]    Once the data warehouse  315  has been updated, the Issuer  135  can then perform any variety of analysis on this data in order to identify specifically targeted marketing opportunities. For example, simple query of the data warehouse  315  would identify all of the existing customers of the Issuer who have used someone else&#39;s credit card to rent a car. The Issuer  135  could then design a promotion targeted at these existing customers which would hopefully induce the customer to use its card when renting cars in the future.  
         [0030]    Although the present invention has been described in relation to particular embodiments thereof, many other variations and modifications and other uses will become apparent to those skilled in the art. It is preferred, therefore, that the present invention be limited not by the specific disclosure herein, but only the gist and scope of the disclosure.

Technology Category: 3