Abstract:
A method for analyzing transactional payment data is shown. Transaction data, relating to a transaction between a payor and at least one of a plurality of payees is collected. The collected transaction data from a plurality of payors is normalized to create normalized data. The normalized data is scaled to create financial information. The financial information is provided to a user.

Description:
RELATED APPLICATION DATA  
       [0001]     The present application is related to and claims the benefit of U.S. Provisional Application No. 60/183,757, filed on Feb. 22, 2000, which is expressly incorporated herein by reference in its entirety. 
     
    
     BACKGROUND OF THE INVENTION  
       [0002]     1. Field of the Invention  
         [0003]     The present invention relates to financial transaction data and systems and methods for using such data. More particularly, the invention relates to systems and methods for compiling financial transaction data and processing such data to provide financial information.  
         [0004]     2. Description of the Related Art  
         [0005]     Stock analysts, bank credit underwriters, government agencies like the Federal Reserve Bank and the IRS, and companies are interested in any available information about the flow of money as it relates to the potential prediction of future econometric parameters, such as the future direction of the market, the price of a particular stock, corporate revenue or earnings, credit ratings, or sales trends. For example, analysts attempt to use this information to assess the current health of a company as well as its potential future position in the marketplace. Through the assessment of a company&#39;s strategy and performance, stock analysts create an estimate of the “value” of a company, and ultimately what the company&#39;s stock will be worth in the future. Analysts can then either recommend the purchase or sale of a stock to clients or, in the case of a mutual fund analyst, take or unwind a position in the stock. Futures analysts are similarly inclined.  
         [0006]     Unfortunately for the analysts, not much information is publicly available outside of monthly or quarterly announcements from a given company or quarterly announcements of commodity inventories from government agencies. News is generally shared quickly, but actual revenue, performance data, and inventory levels are only released on fixed dates throughout the year.  
         [0007]     In today&#39;s marketplace, financial transactions are performed using various types of payment systems. Such payment systems include credit card systems and debit card systems. Payment systems for financial transactions also include check payment and clearing systems, wire transfer systems and the automated clearing house (“ACH”) system.  
         [0008]     One example is the credit card. Credit cards, most commonly represented by plastic wallet-sized cards, are provided to customers by credit card issuers, which may be banks or other financial institutions. With a credit card, a customer can purchase products and services without an immediate exchange of cash. Instead, the customer incurs debt with each purchase. Thereafter, the customer repays the debt upon receipt of a periodic statement from the issuer. In many cases, a cardholder has the option to pay the outstanding balance in full or to defer at least a portion of the balance for later payment with accompanying interest or finance charges.  
         [0009]     In addition to credit cards, there are cards that function like credit cards but are associated with a bank account, like a checking account. Transactions are cleared through a credit card clearinghouse like the Visa or MasterCard networks. These credit-card-like that are associated with a checking account are sometimes called check cards.  
         [0010]     Additionally, debit cards may used to make payments in some situations. Debit cards are also ordinarily associated with a bank account of some type. A common type of debit card is the automated teller machine (“ATM”) type card. There are also other types of payment cards, such as stored value cards and smart cards. Each of these cards must generate a transaction record when a sales transaction occurs. Additionally, transaction data may be obtained from banking systems regarding cash deposits and withdrawals, including wire transfer systems, and the ACH system. A user of a payment system, including the credit card, debit card, checking, wire transfer, ACH, and cash deposit systems is referred to herein as a payor.  
         [0011]     Credit card issuers and other payment system operators collect a large amount of payor data, some of which is obtained from payors directly. To apply for a credit card, for example, an applicant typically must supply demographic information (e.g. age, city of residence), financial information (e.g., monthly expenses-and bank account balance), and employment information (e.g., salary or length of employment). To determine whether to issue a card to the applicant, an issuer usually will contact a credit reporting agency to obtain the applicant&#39;s credit history.  
         [0012]     Payment system operators also collect a great deal of information indirectly through the course of a transaction. Much of the indirectly obtained data is obtained through a merchant when the merchant obtains payment through the payment system. For example, when a payor makes a purchase, a payment system operator, such as a credit card issuer, obtains information about where the purchase was made (e.g., the store name and location), the purchase price, and the item or items purchased. The data collected by the operator can be used in a number of ways. For example, the purchase data may be used by credit card issuers to generate billing statements and collect payment from cardholders.  
         [0013]     Credit card issuers may use cardholder information to offer additional products and services to the cardholder. Some issuers also utilize mailing lists including cardholder information for marketing purposes. However, use of a cardholder&#39;s personal data can create concerns over protecting consumer privacy. To remedy this, many issuers offer cardholders the option of removing their names from marketing lists.  
         [0014]     The use of purchase data is even more fraught with privacy concerns, and most issuers have established policies against releasing data about purchases by individual consumers. Therefore, with the exception of obtaining payment, payment system operators, such as credit card issuers, may not make any use of personally identifiable information belonging to those payors who have requested to be removed from marketing lists. Therefore, there is a need in the art for systems that use aggregate payor information that is not personally identifiable to generate real-time market information predictions.  
         [0015]     It is also possible to collect information about merchant sales transactions by examining information about check clearing transactions, wire transfers, ACH transfers and cash deposit records. For example, when a merchant decides whether to accept a check from a consumer, the merchant may use a check verification service. A check verification service provides an electronic database of persons who have written bad checks or have had their bank accounts closed as a result of bad check writing. Many merchants use such a service to determine whether a consumer has a history of writing bad checks and, in so doing, transmit sales transaction information to the databases of the check verification service provider.  
         [0016]     In practice, many merchants run checks through an electronic reader or enter checking account numbers into terminals. The check verification service then approves or denies the check. Some check verification systems will deny a check if multiple checks have been written within a 24-hour period. Therefore, check verification services must keep a record about the check sales transactions conducted at particular merchants. However, there is no existing system that uses this type of information in a non-intrusive manner to provide real-time market information predictions.  
         [0017]     Payment information is accumulated in check clearinghouse systems and similar banking systems. Once a check is deposited, it is routed from the check recipient&#39;s bank to the check writer&#39;s bank. During this process, the check is shipped to one of the regional Federal Reserve banks for clearance, and then sent back to the recipient&#39;s bank. There are other forms of automated checking clearinghouses and groups of banks that have agreed to a system of check exchange. Regardless how checks are cleared, however, payment information is accumulated and available for data processing nearly as quickly as the transactions occur. But there is a need in the art for systems and methods to use this vast amount of payment data to generate real-time market information predictions.  
         [0018]     Some credit card issuers have existing methods of using credit card purchase data without compromising cardholder privacy. For instance, an Internet-based credit card issuer, NextCard.com, provides a monthly list of online.merchants with the greatest number of online transactions by the their cardholders. The merchants are then ranked by the number of online transactions by the issuer&#39;s cardholders. This type of list is of limited utility, however, because it includes only purchases made over the Internet using the issuer&#39;s card, and provides only rankings, not actual sales data. Also, the list cannot be searched (e.g., to find information on a company that is not top-ranked) or sorted (e.g., by industry or product).  
         [0019]     Other businesses use sales transaction information internally for forecasting purposes, e.g., to predict future sales or estimate product demand. For example, Renslo et al., U.S. Pat. No. 5,446,890, discloses a system in a manufacturing environment that uses order information to forecast future demand for products. By forecasting future demand, the system enables a manufacturer to increase or reduce parts in inventory and schedule production of those parts accordingly.  
         [0020]     In Fields et al., U.S. Pat. No. 5,459,656, historical demand and actual current demand are used to predict future business demand for products or tasks. The projections can be used, for example, to update production plans on a regular basis. The models used for forecasting can account for a number of factors that effect demand for a product, including day of the week, season of the year, and promotional events.  
         [0021]     Although systems such as these use actual sales data to predict future demand for products or services, they are limited in their usefulness. For example, these systems are limited to collecting sales data and forecasting future sales for a single product or business. They are not adapted to demonstrate industry-wide or nationwide trends or trends within a particular geographical region or a combination, such as, for example, southeastern automotive related company performance trends.  
         [0022]     It is possible to compile sales figures for an entire industry or segment of the economy using some well-known reporting mechanisms. For instance, many companies report revenues quarterly, and consumer indicators, e.g. the Consumer Price Index, are typically released on a monthly basis. However, these known systems provide information about industries or segments of the economy slowly and only periodically.  
         [0023]     Clearly, there is a need in the art for the ability to make near real-time market information predictions, including revenue trend predictions, based on payment transaction information.  
       SUMMARY OF THE INVENTION  
       [0024]     Systems and methods consistent with the principles of the invention provide near real-time market information predictions based on money flow maps derived from payment transaction information. Payment system operators, such as credit card issuers, have transactional data that is representative at a statistically significant level of general market trends of individual companies and broader econometric data, and payment system operators have access to transactional data on a real-time basis. The present invention meets the need for near real-time trend data by leveraging the transactional data. In one embodiment, the data can be manipulated to best fit corporate revenue trends, giving equity analysts more information on how a company is doing. More specifically, the embodiment can process the transactional data to produce revenue predictions for a company over the next month or quarter.  
         [0025]     Therefore, the present invention will support the use of existing payment systems as well as new forms of electronic or smart cards or any other kind of payment system that generates essentially real-time transaction records.  
         [0026]     Systems and method consistent with the principles of the invention also analyze transactional sales data. Transaction data is collected, the transaction data relating to a transaction between a payor and at least one of a plurality of payees. The collected transaction data is normalized to create normalized data. Normalized data is scaled to create financial information corresponding to a predetermined metric. The financial information is the provided to a user in a useful form.  
         [0027]     Both the foregoing general description and the following detailed description are exemplary and are intended to provide further explanation of the invention as claimed. 
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0028]     The accompanying drawings provide a further understanding of the invention and are incorporated in and constitute a part of this specification. The drawings illustrate various embodiments of the invention, and, together with the description, serve to explain the principles of the invention. In the drawings:  
         [0029]      FIG. 1A  illustrates an embodiment of the system architecture of the present invention;  
         [0030]      FIG. 1B  is a block diagram showing an embodiment of the issuer system;  
         [0031]      FIG. 1C  is a flow chart depicting the features of one embodiment of the present invention;  
         [0032]      FIG. 2A  is a flow chart depicting an embodiment of collecting transactional data;  
         [0033]      FIG. 2B  is a flow chart depicting an embodiment of the authorization and posting process;  
         [0034]      FIG. 2C  illustrates an embodiment of the transactional data;  
         [0035]      FIG. 3A  is a flow chart depicting an embodiment of normalizing data based on total open accounts;  
         [0036]      FIG. 3B  is a flow chart depicting an embodiment of normalizing data based on total transactions;  
         [0037]      FIG. 3C  is a flow chart depicting an embodiment of normalizing data based on average outstanding balance;  
         [0038]      FIG. 3D  is a flow chart depicting an embodiment of normalizing data based on demographics;  
         [0039]      FIG. 3E  is an exemplary flow chart of a process for applying normalized data to calculate predicted performance;  
         [0040]      FIG. 4A  is a flow chart depicting an embodiment of scaling data using past normalized transactions;  
         [0041]      FIG. 4B  is a flow chart depicting an embodiment using a regression analysis to predict actual revenue;  
         [0042]      FIG. 4C  is a flow chart depicting an embodiment of scaling data using a neural network;  
         [0043]      FIG. 4D  is a flow chart depicting an embodiment of scaling data using past normalized transactions with underestimation;  
         [0044]      FIG. 5A  is a flow chart depicting an embodiment of applying data using a direct feed;  
         [0045]      FIG. 5B  is a flow chart depicting an embodiment of applying data using a query;  
         [0046]      FIG. 5C  is a flow chart depicting an embodiment of applying data by providing information to customers when real-time revenue projections vary from consensus estimates;  
         [0047]      FIG. 5D  is a flow chart depicting an embodiment of applying data using industry trends; and  
         [0048]      FIG. 5E  is a flow chart depicting an embodiment of applying data using same store sales. 
     
    
     DETAILED DESCRIPTION  
       [0049]      FIG. 1A  illustrates an embodiment of the system architecture of the present invention. Network  100  may be any type of a network over which information may be exchanged. For example, network  100  may be the Internet, a private data network, or a virtual private network, using a public network such as the Internet. Network  100  may also include a public switched telephone network (PSTN) and/or a wireless network. Merchant  102  represents any number of merchants that provide goods or services in exchange for payment via a particular payment system. For example, merchant  102  may be: an online retail merchant, a traditional retail merchant, or any other type of merchant of goods or services. Each merchant  102  communicates directly to credit card clearinghouse  104  in order to initiate the process of obtaining payment. Credit card clearinghouse  104  may be, for example, the Visa or Master Card networks or a check clearing system.  
         [0050]     In one embodiment, registered end users of issuer-aggregated information, such as, licensed end users  106  and  108  may access the information via network  100 . As shown in  FIG. 1A , there may be many licensed end users. In this embodiment, issuer aggregated information is collected and processed in issuer systems such as issuer systems  112  and  110 , as further described in connection with  FIG. 1B . There may be many such issuer systems, with each issuer system being implemented through any suitable combination of hardware, software and/or firmware.  
         [0051]      FIG. 1B  is a block diagram that illustrates an exemplary issuer system, consistent with the principles of the present invention. Issuer system  120  may be any sufficiently powerful general-purpose computing system. It may be, for example, a mainframe, a multi-processor UNIX system, or a powerful PC server system. In any case, such a system will have at least one input device, such as, input device  122 . Possible input devices include: network interfaces, keyboards, mice, speech recognition devices, document, video, or image input devices, etc. Additionally, issuer system  120  contains at least one output device  124 , such as, for example, display devices, network interfaces, printers, sound or speech output devices, etc.  
         [0052]     As illustrated in  FIG. 1B , issuer system  120  also includes at least one central processing unit (“CPU”)  126 . CPU  126  is used to execute instructions that cause issuer system  120  to operate. Instructions and other data are stored in at least one memory  127  in issuer system. 120 . Also stored in memory  127  is a list of licensed end users  128 . The list of licensed end users allows issuer system  120  to ensure that only properly licensed end users will be able to access issuer system  120 . Transactional database  130  is also stored in memory  127 . This database contains records known to issuer system  120 . These transactions are processed by issuer system  120  in order to provide relevant data to licensed users in the list of licensed users  128 . Additionally, issuer system  120  contains database software  132  that is used to manipulate transactional database  130 . Normalizing and scaling formulas  134  are used by CPU  126  while executing instructions in conjunction with the database software to process the records in transactional database  130  and provide data in a form appropriate for transmission to licensed end users.  
         [0053]      FIG. 1C  is an exemplary flow chart depicting features for using transaction data, consistent with the principles of the present invention. This embodiment of the invention uses transaction data from cardholders to project corporate revenues for companies traded on any of the major exchanges (e.g., NYSE, NASDAQ, AMEX, etc.). The first step is to collect transactional data from merchants to whom payment is made by cardholders (step  142 ). This data is collected when a cardholder transacts at a merchant location using a Capital One™ or other major credit card, or any other kind of payment system that generates transactional information, including a check clearing system. The term cardholder is used as an example in conjunction with one embodiment. Nevertheless, it should be understood that in other payment systems, another term may be substituted for the term cardholder, and the present invention may be practiced in conjunction with transaction records generated in the course of a transaction by any payor, regardless of the term used to identify the payor.  
         [0054]     After a cardholder makes a purchase, the transaction is delivered to the credit card issuer or other payment system operator, such as, for example, the Visa/MasterCard network or the check clearing system. For each company of interest, the dollar value of all transactions can be accumulated over a predetermined period of time, for example from the first day of current business quarter until the current day of business quarter.  
         [0055]     The accumulated transaction data is then processed by an issuer system. For example, the issuer system may normalize the data (step  144 ). Consistent with the principles of the present invention, normalization may be performed in a number of different ways, as further described in conjunction with  FIGS. 3A-3E . After normalizing the data, the issuer system scales the data (step  146 ). As further described in connection with  FIGS. 4A-4D  (step  146 ), the normalized data may be scaled using a number of different techniques. For example, the scaling of data may be performed using linear regression or pattern recognition via a neural network.  
         [0056]     Depending on the particular parameter, different scaling methods may be required to obtain a good prediction. For example, to predict corporate revenue trends, some information about a company&#39;s accounting practices may be necessary. An airline may, for example, obtain payment for a July flight in January, when a traveler plans her trip. However, the airline may not actually book the revenue until the ticket is used. Therefore, there may be some delay between the time when a payment transaction occurs and when the transaction is reflected in revenue.  
         [0057]     Finally, the issuer system applies the data to provide financial information to end users (step  148 ). As further described in connection with  FIGS. 5A-5E , the manner in which the data is applied and presented to end users may vary. Step  148  may involve either providing the scaled and normalized sales information in its raw form or applying the scaled and normalized information to known or newly created models for predicting financial metrics, such as stock price, interest rates, or commodity supplies. One example is the application of sales information to predict a company stock performance. In another example, near real-time predictions may be made about stored supplies of a commodity (such as gasoline). Periodically, government agencies report information about aggregate stored supply levels of particular commodities. Thus, the last published report of commodity storage levels may be used in conjunction with normalized and scaled information about recent sales of the commodity to make near real-time predictions of the actual storage levels, before the next report becomes available. This may be done, for example, by taking an average price per gallon and calculating a number of gallons pumped based on the amount of money being transacted at merchants having, for example, a Standard Industrial Classification (“SIC”) number consistent with retail gasoline sales.  
         [0058]      FIG. 2A  is an exemplary flow chart depicting a process for collecting transactional data, consistent with the principles of the present invention. In step  202 , a customer transacts at a merchant location using a credit card issued by a credit card issuer. The merchant location may be a physical location (such as a “bricks-and-mortar” location) or may be a web site through which the merchant offers goods or services to customers. As part of the transaction, a merchant will collect payment information (e.g., a customer&#39;s credit card number) and compute a transaction total based on the goods and services selected by the customer. This transaction information is then forwarded to a corresponding credit card clearinghouse. The corresponding credit card clearinghouse then delivers information related to the transaction to the credit card issuer to seek authorization (step  204 ). Next, the issuer approves or declines the transaction based on the customer&#39;s status or credit (step  206 ). If the issuer approves the transaction, the transactional data is put into the transactional database (step  210 ). Otherwise, if the transaction is declined, the process terminates (step  208 ). Declined transactions may also be stored in the transactional database. Thereafter, the credit card issuer&#39;s decision concerning the transaction (approved or declined) is sent back to the merchant via the clearinghouse to permit the merchant to complete or terminate the attempted transaction with the customer.  
         [0059]      FIG. 2B  is an exemplary block diagram depicting an authorization and posting process, consistent with the principles of the present invention. During a transaction with a customer, merchant point-of-sale (“POS”) device  222  sends an authorization request to credit card clearinghouse system  224 . The authorization request from merchant POS device  222  will result in an authorization decision from authorization system  224  once the authorization system  224  obtains authorization from issuer mainframe  226 , which is the authorization decision maker. Issuer mainframe  226  uses known methods to determine whether a transaction should be authorized, including making sure that the card is not over its limit, verifying billing address information, and referencing lists of card numbers corresponding to lost or stolen cards. In order to obtain an authorization decision, authorization system  224  further transmits the authorization request to issuer mainframe  226 . These authorization decisions may be stored in a UNIX-based storage device  230  for a period of time, such as, for example seven months. Daily authorization files and nightly account balance updates may be transmitted to issuer mainframe  228 , which is used to update, format and store the data. In one embodiment, this is the data that is used as input to the scaling and normalizing processes. Issuer mainframe  228  may store posting data in a tape storage device  232  for later retrieval or viewing.  
         [0060]     In  FIG. 2B , a credit card clearinghouse posting system  234  may be provided to transmit posted transactions to a second issuer mainframe  236 , which is used to convert the posted transactions into a suitable data format for storage. The posted transactions that are converted by issuer mainframe  236  are transmitted to issuer mainframe  228 , which stores the data to tape storage device  232 .  
         [0061]      FIG. 2C  illustrates, consistent with the principles of the present invention, an example of the transactional data that may be stored sequentially by date. This data may include multiple fields. The first field is place of purchase  242 . The second field is time of purchase  244 . The third field is SIC code  246 . The fourth field is dollar amount  248  corresponding to the amount of money that is to be exchanged in the transaction. The fifth field is account number  250 , which corresponds to the account number of the transacting payor.  
         [0062]     As described above, the normalization of transaction data (step  144  of  FIG. 1C ) may be performed in a number of different ways. Consistent with the principles of the present invention,  FIGS. 3A-3E  demonstrate different examples of the manner in which transaction data can be normalized.  
         [0063]      FIG. 3A  is an exemplary flow chart of a process for normalizing data based on total open accounts. The features of  FIG. 3A  may be performed by an issuer system. In step  302 , the start time of the period over which the data will be normalized is determined. This period may be a specific year, a quarter, or a month, for example, the first quarter of 1997, Jan. 1, 1997 to Mar. 31, 1997. Next, the dollar amount for each transaction stored in the database is retrieved from the start time to the current time for a particular category (step  304 ). A particular category may correspond to, for example a specific merchant. Thereafter, the dollar amounts, of all transactions corresponding to a particular merchant, are added to produce a total dollar amount (step  306 ). If this total dollar amount is for a large on-line merchant, the total amount may be a number such as $1.4 million. Finally, the total is divided by the average number of accounts open during the period from the start time until the current time (step  309 ). This results in a dollar figure, normalized over the total number of open accounts, representing dollars transacted per open account.  
         [0064]      FIG. 3B  is an exemplary flow chart of a process for normalizing data based on total transactions. The features of  FIG. 3B  may be performed by an issuer system. The first step is to determine the start time for the period over which the data is to be normalized (step  312 ). Next, the dollar amount is retrieved for each transaction stored in the database from the start time to the current time (step  314 ). Next, the dollar amounts of all retrieved transactions are added to get the total amount transacted (step  316 ). Finally, the total amount is divided by the sum of the amount of all transactions with the issuer from the start time until the current time (step  318 ). This results in a dollar figure normalized over the total number of transactions, representing dollars transacted per transaction.  
         [0065]      FIG. 3C  is an exemplary flow chart of a process for normalizing data based on an average outstanding balance. The features of  FIG. 3C  may be performed by an issuer system. In step  322 , the start time of the relevant period over which to normalize the data is determined. Next, the dollar amount is retrieved for all transactions stored in the database from the start time until the current time (step  324 ). Thereafter, the dollar amounts are added to produce a total dollar amount over the relevant time period (step  326 ). Next, the total dollar amount is divided by the average outstanding account balance from the start time to the current time (step  328 ). This process results in the total dollar figure normalized over the average outstanding balance, representing dollars transacted per dollar balance.  
         [0066]      FIG. 3D  is an exemplary flow chart of a process for normalizing data based on demographics. Predetermined demographic clusters are identified that uniquely describe particular categories of cardholders. For example, these categories may be associated with particular credit card services offered by an issuer to a group of consumers. Transactions can be summed for all known cardholders in each of these clusters and normalized by the number of active accounts or the number of transactions in each cluster. Because a credit card issuer will often maintain records indicating the amount of money transacted by each demographic cluster, the data can be normalized using these numbers as well.  
         [0067]     In step  342  of  FIG. 3D , one or more demographic profiles is created based on the predetermined demographic categories, and the profiles are labeled D 0  through D n  (step  342 ). Demographic profiles correspond to particular demographic criteria, such as, for example, household income. Demographic clusters are groups of consumers having a particular demographic profile. Next, the total transaction amount corresponding to each cluster is retrieved, labeling the total transaction amounts T 0  through T n  (step  344 ). Next, the average outstanding balance corresponding to each demographic cluster is retrieved, labeling the balance US 0  through US n  (step  346 ).  
         [0068]     Finally, the weighted ratios T n /US n  (for n=0 to the number of clusters) are summed to calculate the normalized quantity (step  348 ). The ratios may be weighted to indicate the relative sizes of each demographic cluster. Table 1 below contains illustrative values corresponding to a calculation made in connection with  FIG. 3D .  
                                   TABLE 1                           Demo-   Total                       graphic   Transaction   Average           Profile:   Amount:   Outstanding   Weight   Weighted       n   D n     T n     Balance   Factor   Ratio                   0   Product A   57,222.40   25,479,999,067   0.5   2.246 × 10 −6         1   Product B   17,923.55    2,643,449,101   0.5   6.781 × 10 −6                    
 
         [0069]    
       
         
           
             
               
                 
                   N 
                   = 
                   
                     
                       
                         
                           w 
                           0 
                         
                         · 
                         
                           
                             T 
                             0 
                           
                           
                             S 
                             0 
                           
                         
                       
                       + 
                       
                         
                           w 
                           1 
                         
                         · 
                         
                           
                             T 
                             1 
                           
                           
                             US 
                             1 
                           
                         
                       
                     
                     = 
                     
                       
                         
                           0.5 
                           · 
                           2.446 
                           · 
                           
                             10 
                             
                               - 
                               6 
                             
                           
                         
                         + 
                         
                           0.5 
                           · 
                           6.781 
                           · 
                           
                             10 
                             
                               - 
                               6 
                             
                           
                         
                       
                       = 
                       
                         4.51 
                         · 
                         
                           10 
                           
                             - 
                             6 
                           
                         
                       
                     
                   
                 
               
               
                 
                   Equation 
                   ⁢ 
                   
                       
                   
                   ⁢ 
                   1 
                 
               
             
           
         
       
     
         [0070]     In equation 1, N is a normalized value that is calculated using demographic profiles.  
         [0071]      FIG. 3E  is an exemplary flow chart of a process for applying normalized data to calculate predicted performance. The features of  FIG. 3E  may be performed by an issuer system. First, a period for which to predict revenue for a company of interest is selected and the period is labeled “t” (step  364 ). Such a period may be, for example, Apr. 1, 2001 to Jun. 30, 2001. Next, a corresponding past period with known revenue is selected and labeled “t−1” (step  366 ). This period may be, for example, Jan. 1, 2000 to Mar. 31, 2000. Next, normalized transaction data is calculated as described in connection with any of  FIGS. 3A-3D , labeling the normalized data TRX t  and TRX t-1  (step  368 ). Next, the gross growth rate is calculated by dividing TRX t  by TRX t-1  (step  370 ). Once a gross growth rate has been determined, the actual revenue for period t−1 is obtained (step  372 ). Actual revenue may be obtained by services such as Standard &amp; Poor&#39;s™. Finally, the actual revenue is multiplied by the gross growth rate to provide a revenue prediction (step  374 ).  
         [0072]     A scale factor is useful for scaling normalized transaction data (N) to produce a prediction of monthly or quarterly corporate revenue. For example, to scale the data (step  146  of  FIG. 1C ), a historical ratio can be used that compares the normalized data to the actual reported revenue of a company. A number of different methods can be used to scale the normalized data, including the exemplary techniques described below with reference to  FIGS. 4A-4D .  
         [0073]      FIG. 4A  is an exemplary flow chart of a process for scaling data using past normalized transactions. In step  402 , the value N is calculated which corresponds to the result of normalizing the data by using, for example, any of the methods disclosed in connection with  FIGS. 3A-3D . Next, the number of past periods X that will be considered is determined (step  404 ). Then, the ratio of normalized results to actual revenue for each of the past X periods is calculated (step  406 ). As described in connection with  FIG. 3E , actual revenue figures may be obtained from known sources. Thereafter, the ratios for the past X periods are averaged to determine the average ratio of normalized transaction amounts to actual corporate revenue (step  408 ). Finally, N is divided by the average ratio to produce a revenue prediction (step  410 ).  
         [0074]      FIG. 4B  is a flow chart depicting an embodiment using a regression analysis to predict actual revenue. First, at step  412 , a number X of past periods to consider in a regression analysis is determined. Next, the normalized data corresponding to the X periods is calculated by using, for example, any of the methods disclosed in connection with  FIGS. 3A-3D  (step  414 ). Then the actual revenue corresponding to the relevant past periods is obtained using known means (step  416 ). Next, based on the normalized data and the actual revenue figures, a regression equation is formulated using, for example, a “least squares” method (step  418 ). Next, a normalized transaction figure is calculated corresponding to a period for which revenue is to be predicted, using any of the methods described in connection with  FIGS. 3A-3D  (step  419 ). Finally, predicted revenue is calculated based on the formulated regression equation (step  420 ).  
         [0075]      FIG. 4C  is an exemplary flow chart of a process for scaling data using a neural network. First, at step  422 , the value N is calculated which corresponds to the result of normalizing the data by using, for example, any of the methods disclosed in connection with  FIGS. 3A-3D . Next, the number of past periods X to be considered is determined (step  424 ). Next, data from the past X periods is provided as input to a known neural network capable of matching patterns corresponding to metrics, such as, for example, accurate revenue prediction (step  426 ). Thereafter, a best fit model is derived from the neural network (step  428 ). A best-fit model may be selected on the basis of the model&#39;s ability to accurately predict past performance as is evident to persons skilled in the art. Finally, the best fit model is applied to normalization data N to calculate a prediction (step  430 ).  
         [0076]      FIG. 4D  is an exemplary flow chart of a process for scaling revenue predictions, correcting for overestimation. First, at step  440 , a value R is calculated, which corresponds to a revenue prediction made using methods consistent with the present invention. Next, the number of past periods X to be considered is determined (step  442 ). Next, for each of the past X periods, a percentage by which revenue was over-estimated is calculated (step  444 ). The over-estimation calculation may be done by comparing the predicted revenue with actual revenue figures obtained form known sources. Thereafter, the average of the percentage of overestimation for the past X periods is computed (step  446 ). Finally, the figure (1—the average percentage of over estimation) is multiplied by R to compute a scaled revenue prediction (step  448 ).  
         [0077]     Illustrative embodiments have been described in connection with the prediction of corporate revenue using input data, such as, for example credit cardholder transaction information. Persons of ordinary skill in the art will appreciate that other types of econometric figures may be predicted without departing from the scope of the invention as claimed, and other inputs may be substituted for credit cardholder transaction data, consistent with the present invention.  
         [0078]     As described above, after the transaction data is normalized and scaled, the data is applied to provide financial information to end users (step  148  of  FIG. 1C ). Consistent with the principles of the present invention, transaction data may be applied and presented in a number of ways. In the following examples, access and retrieval of the data can be performed through a private network (such as a PBX, virtual private network or intranet) and/or a public network (such as a PSTN, public wireless network, or the Internet).  
         [0079]     In one embodiment, predictions may be generated about the direction of large-scale consumer-oriented econometrics. Some examples include consumer spending, Gross Domestic Product, and the money supply M 1 .  
         [0080]     In another alternative embodiment, normalized and scaled transactional data for a particular merchant may be used to generate a credit score for the particular merchant, indicating the merchant&#39;s creditworthiness. This is accomplished by comparing past revenue for the merchant with the predicted revenue, predicted by normalizing and scaling transactional information for the merchant. The credit scores may be provided to potential creditors in exchange for a fee. The credit scoring services may be marketed directly to potential creditors by the operator of the payment system or alternatively by an entity in the existing credit scoring industry.  
         [0081]     In yet another alternative embodiment, sales information regarding demographic trends may be marketed to merchants. For example, a retail merchant may have targeted a particular demographic profile in its advertising and marketing initiatives. The retail merchant is likely be extremely interested to learn whether there was an associated increase in spending among the targeted demographic segment of the consuming public. Therefore, near real-time predictions about the actual spending among a particular demographic profile may be extremely valuable to retailers.  
         [0082]      FIGS. 5A-5E  illustrate further examples of different techniques for applying and presenting data to end users, consistent with the principles of the present invention. The features of  FIGS. 5A-5E  may implemented in a number of system environments, including the exemplary system environment of  FIG. 1  in which licensed end users  106 - 108  receive financial information from one or more issuer systems  110 - 112  via a network  100 .  
         [0083]     In the examples of  FIGS. 5A-5E , licensed end users may register with an issuer system to receive financial information in exchange for agreeing to follow certain licensing terms (e.g., restrictions on dissemination or copying of financial information, payment of license fees, etc.). If the licensing terms require a license fee, payment from licensed end users may be obtained in several forms. For example, a user may obtain unlimited accesses to financial information from an issuer system for a yearly license fee. Alternatively, an end user may pay on a per company or index basis. In certain cases, a user may obtain a discounted price for data for which access is delayed by a predetermined period. Other license fee payment structures are also possible. For example, a user may wish to obtain unlimited access in exchange for the issuer receiving a percentage of the licensed customer&#39;s profit, revenue or managed assets. An end user may pay a flat fee for customized reports or an end user may pay for customized reports, billing for data analysts&#39; and system time on a cost plus basis.  
         [0084]      FIG. 5A  is an exemplary flow chart of a process for applying data using a direct feed. In step  502 , the data is formatted by an issuer system. Some examples of formatting data consistent with the present invention include placing the data into spreadsheet format, such as for example the Excel TM spreadsheet available from Microsoft™. Next, end users that agree to the licensing terms of the issuer system are registered as “licensed” (step  504 ). This step may be performed using an on-line registration process or other registration methods known in the art. During the registration process, basic contact information (e.g., name, mailing address, email address) and/or billing information (e.g., credit card or account number) may be received from an end user. Thereafter, each end user that is registered with the issuer system is sent the formatted financial information on a periodic basis (e.g., daily or weekly) using a designated or preferred delivery method (e.g., on a computer readable medium, such as a compact disk (CD) or tape, or by downloading the information over a network) (step  506 ).  
         [0085]      FIG. 5B  is an exemplary flow chart of a process of applying data using a query. In step  512 , an end user registers as a “licensed” end user with an issuer system (step  512 ). Once again, this step may be performed using an on-line registration process or other registration methods known in the art. Next, a log-in by a licensed end user is received via a web site hosted by the issuer system (step  514 ). During a log-in, the end user may enter a unique combination of information (e.g., username and password) to gain access to the issuer system. After successfully logging into the issuer system, the licensed end user submits a query for financial data about a specific company (step  516 ). The data may be accessed and received in real time through a user interface, or a remote database engine interface, such as, for example a structured query language (“SQL”). For example, licensed customers may type in a company name to access real-time predictions about the company. Following step  516 , data regarding that company is located and sent to the licensed end user (step  518 ). This information may include historical revenue trends as well as revenue predictions and the issuer&#39;s confidence in the prediction. Additionally, the information may include recent news releases, historical earnings trends, filed SEC documents, financial ratings, and consensus estimates.  
         [0086]      FIG. 5C  is an exemplary flow chart of a process for applying data by providing information to customers when real-time revenue projections vary from consensus estimates. In step  512 , an end user registers as a “licensed” end user with an issuer system (step  522 ). Next, consensus estimates of revenue are received from various known sources of such information (step  524 ). Then, a list is created of all companies where the real-time revenue prediction varies from consensus estimates by a set percentage (step  526 ). This step may be performed by identifying where financial experts disagree by a predetermined threshold amount. Next, the generated list is provided to licensed end users by various possible means, including email or facsimile via a network (step  528 ). After the end user receives the information, he or she may connect to the issuer&#39;s system to further examine the list and download additional financial information.  
         [0087]      FIG. 5D  is an exemplary flow chart of a process for applying data using industry trends. Tracking indices for specialized industries can be created using the predicted revenue data. Examples of industries include retail sales, transportation, airlines, mail order, Internet, etc. Tracking indices could be faxed or emailed to “licensed customers” or they could log onto the issuer&#39;s system to examine the indices. In step  532 , an end user registers as a “licensed” user with an issuer system (step  532 ). As described above, this step may be performed using an on-line registration process or other registration methods known in the art. Next, industry selections are received from a licensed end user (step  534 ). This step may be performed by collecting selections via a web page or by other communication means. Based on the selections made by the end user, tracking indices are created for each of the selected industries (e.g. retail sales, airlines etc) (step  536 ). Next, tracking indices are computed and sent to licensed end users for the selected industries (step  538 ). Various communication methods may be used to perform this step, including email, facsimile and/or downloading via a network.  
         [0088]      FIG. 5E  is an exemplary flow chart of a process for applying data using same store sales. In step  542 , an end user registers as a “licensed” user with an issuer system (step  532 ). Next, a company query is received from a licensed end user (step  544 ). Then, the issuer system compiles same store sales for the requested company (step  546 ). Next, the compiled data is provided to licensed end users through, for example, a direct feed or use of real time queries of views on a database server (step  548 ).  
         [0089]     Methods and systems consistent with the principles of the present invention may be used within a consortium model in which multiple issuers join together to form a consortium. Capital One™ or a major credit card issuer could license similar data from other sources, including other credit card companies, Visa, MasterCard, American Express, Discover, retail cards, gas cards or any other issuer in an automated payment system), pooling the data into a consortium database to improve sample size and accuracy of predictions. This same concept may be used to predict earnings, stock price, economic indices, industry indices, interest rates, and sector trends.  
         [0090]     Other embodiments of the invention will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the invention being indicated by the following claims.