Method and system for predicting transaction

[0002] The present invention provides a method and system for predicting transactions, in particular, to aid in providing personalisation for Internet transactions.

[0003] It has long been a goal of data mining applications to attempt to predict individual's preferences. Such applications usually operate by gathering user data and perhaps expert information to divide populations into a suitable number of clusters, each cluster being associated with a respective plurality of attribute values, for example, individuals who are married with children, vote democrat, live in suburbia, drink black coffee and earn over $60,000 per annum might form one cluster. When data mining applications are presented with incomplete data for an individual, they find the most suitable cluster for such an individual and use the associated attribute values of the cluster to predict the individuals unknown attributes.

[0004] U.S. Pat. No. 5,704,017 discloses a system for collaborative filtering utilizing a belief network. This involves defining a belief network, then cumulatively adding a number of expert supplied and user data to the network, and finally using the network to predict unknown values in the network for a new user. As an example, a belief network with attributes concerning a user's age, sex, income bracket, lifestyle (“sedentary”, “active”, etc.), coffee preference, and preferred music style can be defined, and user data for these attributes can be added to the network. Then, for a new user, if age, sex, income bracket and lifestyle are supplied the network predicts the user's likely coffee preference and preferred music style. Such a network, however, relies on having access to all (or at least a large portion of) user data before it can make a prediction relating to a single user.

[0005] Internet transaction processing systems, for example, Banking sites, which provide access to a range of standard transactions for their customers, including inter-account transfers, bill payment, ordering new cheques, are known. If such transactions were performed in a bank branch environment where the customer is well-known, and has been visiting regularly for a number of years, it is likely that the staff in the branch will get to know the sort of things which the customer wants to do, and will anticipate the customer's requests: for example, the first time the customer visits the branch after payday, they may usually want to take out 250 dollars in cash. So, when the customer approaches the teller, the teller may anticipate this, and have the cash ready at hand. Of course, the customer may not want to perform this transaction, so they can still perform anything else, but they usually do, so this in general will bring a number of advantages: it shortens the transaction time for the customer, increases their loyalty to the bank, and increases the throughput of the bank teller.

[0006] It is an object of the present invention to provide the same level of anticipation for transactions performed over the Internet based only on prior customer activity.

[0007] Accordingly the present invention provides a personalisation sub-system as claimed in claim 1.

[0008] So, for example, when the customer clicks to bring up an “inter-account transfer” panel, the system of the invention may recognise that usually, with a given balance in their savings and cheque accounts, and at this time of the month, at this point in the financial year, the customer will want to transfer 500 dollars to their cheque account. So, as well as providing a window enabling the customer to manually enter the details for an inter-account transfer, the system also provides a personalised window containing the system's anticipated reason for the visit, with a single-click option to complete the current transaction, FIG. 2.

[0009] Embodiments of the invention will now be described with reference to the accompanying drawings, in which:

[0010] FIG. 1 is a schematic diagram of an Internet banking system including the personalisation sub-system according to the invention;

[0011] FIG. 2 shows a page for a predicted transaction generated according to the invention; and

[0012] FIG. 3 is a flow diagram illustrating the operation of a first embodiment of the invention; and

[0013] FIG. 4 is a flow diagram illustrating the operation of a second embodiment of the invention.

[0014] Referring now to FIG. 1, in an Internet banking system, a customer connects to a bank's web server 10 from a client computing device 20, typically running a web browser 22. In the future, it is envisaged that not alone might customers connect from conventional personal computers, but also from mobile phones or digital televisions or other pervasive computer devices. Nor is it necessary to use a browser, as it is possible for the client to, for example, run a dedicated program.

[0015] In any case, the bank's web server typically connects via a secure link to the bank's back-office system 30 where customer records 32 are stored. In response to customer interaction with pages displayed on their browser, the bank's web server delivers further HTML pages. These pages range from the bank's home and login pages, the same for every customer, to customer specific pages displaying the customer's account details retrieved from the secure back-office system and pages enabling the customer to execute transactions. The actual delivery of these customer specific pages may be accomplished by any number of standard mechanisms for producing dynamic content on HTML pages, such as a CGI gateway programs, Java Server Pages (JSPs) or Active Server Pages (ASPs), the description of which is not thought necessary for the purposes of describing the operation of the present invention.

[0016] It should be seen that processing of the customer's interaction with the bank site takes place on both the bank's server and the client computing device. Typically, client side processing involves the instantiation of pre-loaded classes 24 resident on the client device. Using client side processing has the advantage of reducing server processing load and speeding up application response time.

[0017] In a preferred embodiment, the banking system comprises a personalisation sub-system for addressing the problem of discovering what is the “most likely reason” for a customer to want to perform a transaction. As will be described, the sub-system operates only on the customer's historical data to make a prediction of the attributes of the record for the transaction to be performed—the target record. As the customer's data can be made available on the client device, the personalisation sub-system can therefore comprise classes resident on the client device with all the attendant speed benefits this brings. This contrasts with prior art data mining systems which typically define clusters from information from large customer populations before making a prediction in relation to a single customer.

[0018] It will be seen, however that, for implementations dozens of records are retrieved, the overhead of records over the Internet to the client for it to process may swamp any benefits of the client itself being faster at processing (having more spare MIPS). In such cases, the Java application could be reside on the server side, behind JSPs or ASPs, and generate HTML as its result, to be sent to the client.

[0019] In any case, the personalisation sub-system responds to a user moving to perform the current transaction to execute three stages which will be described with reference to FIG. 3:

[0020] Pooling: All relevant customer historical data records are retrieved, and made available in a “pool”, step 50. For example, if the customer chooses to make a payment to a credit card account, then previous credit card payments are retrieved; if a customer chooses to pay a bill, then previous bill payments are retrieved. Each record matches a standard template with fixed attributes and attribute types. In the transaction of FIG. 2, which shows an inter-account transfer, the template has the following attributes:

[0021] sourceAccount

[0022] targetAccount

[0023] transferAmount

[0024] sourceAccountBalanceBeforeTransfer

[0025] targetAccountBalanceBeforeTransfer

[0026] dayOfTheWeekofTransfer (range 0-6)

[0027] dayOfTheMonthOfTransfer (range 1-31)

[0028] monthOfTransfer (range 1-12)

[0029] In this case, two attributes are unknown: targetAccount and transferAmount, as the system attempts to predict both the account the customer may wish to transfer money into and the amount to be transferred.

[0030] Scoring: The objective of the scoring step is to find similar records from the pool to the current transaction.

[0031] To do this, a target record is now constructed, step 52, with some attributes populated with known details for the current transaction. In the example above, the target record has the sourceAccount, sourceAccountBalanceBeforeTransfer, and the date attributes filled in. The date related attributes, whether generated automatically, assuming the customer wishes the transaction to execute immediately, or manually when they are entered directly by the customer, can be thought of as environmental attributes. Other attributes such as account balances can be thought of as background attributes.

[0032] After this step, the “pool” contains a number (potentially, dozens or even hundreds) of records matching this template, preferably with all possible attributes populated in each record (for some templates, it may not be possible to complete all attributes for each record).

[0033] The scoring step generally comprises going through each record in the pool, and scoring it for its similarity to the target record. The notion of “similarity” is defined by how close a record is, in a multi-dimensional space, to the target record.

[0034] To define how close a record is to the target record, each attribute which has a value in the target record and the corresponding value in the historical record under inspection are examined, step 54. A measure of “distance” is applied to these two records: for example, for the dayOfTheWeekOfTransfer attribute, the distance could be the difference, modulo 7, between the two values: so the distance between 3 and 5 is 2, and the distance between 6 and 0 is 1.

[0035] Quantitative values from individual attributes are translated into qualitative values to allow a distance calculation from more than one attribute. This is done by normalising the distances, step 56, so that a distance of 100 (between two sourceAccountBalanceBeforeTransfer amounts of 5000 and 5100, perhaps) does not totally dominate a distance of 1 in the dayOfTheweekOfTransfer. The scaling used to perform this normalisation depends on the normal range of values in each attribute, and is preferably to predefined by a human business analyst.

[0036] Once normalised distances are available for each attribute, they are composed to provide an overall score of “similarity”, step 58. In the preferred embodiment, this composition uses Euclidian notion of distance, that is the square root of the sum of the squares of each historical record's attribute's distance from its corresponding target record's attribute.

[0037] Merging: In the first embodiment, all but the nearest records are now excluded from consideration, step 60: the cutoff value which defines “nearest” is again initially set by human business analysts, but can be automatically fine-tuned by the system as it discovers that people do, or do not, tend to take the personalised transaction recommendation provided by the system.

[0038] In practice, some optimisation is possible so that every record does not need to be examined, but that some records can be discarded early as they will be known to be “too far away” from the target record. Such optimisation does not affect the principle of this invention.

[0039] Having obtained a subset of the overall record set, comprising those records which are “similar” to the target record, the final step merges these records, to produce a most-likely completed version of the target record, with missing attributes filled in. It is this completed target record which is then used to fill the “personalised transaction” field of FIG. 2.

[0040] Merging comprises filling in the blank values of interest in the target record. So, for each blank value of interest (and not all may be of interest—in the example of FIG. 2, only the targetAccount and transferAmount attributes are of interest), a “most likely” value is found.

[0041] For most attribute types, experiments have shown that the median (for continuous values) or mode (for discrete values) of the corresponding attributes from the set of nearest historical records are most appropriate. That is, the missing attribute value is taken to be the median or modal value from the subset of records defined as “similar” to the target record, steps 62 & 64.

[0042] The resulting completed target record is then used to produce the HTML text in the window accompanying the target transaction, FIG. 2.

[0043] It will be seen, however, that in certain cases a prediction for the current transaction is only useful if is exactly what is required. Take for example, a customer who always pays their entire credit card bill. If previous bills have amounted to US$300, US$500 and US$700 and the current bill is $550, then a predicted transfer amount of US$500 is of no use to the customer.

[0044] In a second embodiment of the invention, a derived attribute, comprising a “ratio” of two other attributes is chosen by a domain expert as an attribute which is potentially useful in prediction. In the example of a credit card payment, such a useful ratio might be the ratio of the credit card bill to the previous amount paid. This attribute is calculated for the historical records and used in the prediction of other attributes in the target record.

[0045] A weighting is associated with each attribute and the sub-system performs an automatic adjustment of weightings to select the appropriate target attribute on which to base a prediction, based on only the historical data for this customer.

[0046] The weighting of the target attributes is used to determine which target attribute is used for prediction whether it is an absolute value type attribute, or a derived value attribute such as a ratio.

[0047] Note that the utility of the ratio attribute, as determined by the weighting given to it, will be particular for this customer: although an initial weighting may be given to the ratio by a domain expert, the actual weighting used will, over time, be largely determined by a customer's behaviour.

[0048] The operation of the second embodiment will now be described in more detail with reference to FIG. 4. The example used is that of credit card payments, where the sub-system is trying to anticipate the credit card repayment amount which a customer will make, so the system can pre-fill the repayment amount for the customer.

[0049] The bank has historical data for each customer relating to earlier credit card payments. For each payment, the bank knows the month (1-12), the cheque account balance, the credit card balance at date of repayment, and the amount of payment made by the customer.

[0050] Based on the domain expert's understanding of credit card repayments, the expert adds a fifth attribute which may be useful in determining likely repayment: the ratio of the credit card payment to the credit card balance. The minimum payment required by the bank on an outstanding balance is 10% of the balance, a ratio of 0.1; the likely maximum ratio for a customer is 1.0 (ignoring over-payment of a balance). The domain expert also decides to give both target attributes (absolute amount and ratio) an equal initial weighting.

[0051] The following data represents the credit-card payments of a customer over a year (these are in fact rounded amounts taken from a live account).

[0052] By observation, it can be seen that this customer pays off all their credit card balance most months, only paying the minimum when it's around the turn of the year (Christmas), or when they haven't got much money in their account (during the customer's summer vacation, in this case). It will be seen that to “hard-wire” such information into the sub-system could prove extremely complex, whereas the method according to the invention, while operating in a generic manner, provides surprisingly useful predictions.

[0053] The method presented below is in a non-optimal form for explanatory purposes, although it should be seen that run-time optimisation can be used in practice to prevent re-scanning of the data, but this does not alter the net effect of the invention.

[0054] 1. Minimum and maximum values for each attribute of the current transactions (in this case, month, Chqbal, Ccbal, CCpay, CCpay/CCbal) are set to null, step 66.

[0055] 2. Each historical data record is presented to the sub-system. For each record:

[0056] If an attribute in the record is a new minimum or maximum value for that element, the current minimum or maximum is updated, step 68.

[0057] 3. Once every historical data record has been presented, normalisation scales are derived for each attribute, step 70, to normalise the values of each attribute onto a scale:

[0058] scale increment=(maximum value−minimum value) number of scale increments

[0059] So in the case of the credit card payments above, the scale is divided into 10 slots between $29 and $440. A payment of $45 is given an index of 0, whereas a payment of £250 is given an index of 5.

[0060] 4. When a partially filled target record is presented, the Euclidian distance from each of the historical data records, adjusted by the attribute scale, is determined:

[0061] EuclidianDistance={square root over (Σ(NormalisedAttributeDistance²))}

[0062] For most attributes, the attribute distance is simply one value minus the other value and the normalised attribute distance is this value divided by the scale increment and rounded.

[0063] For circular attributes such as the month of the year, time of day, etc., the normalised attribute distance is the nearest distance modulo an appropriate number: so months 3 and 12 are distance 3 apart, not 9 apart (March is three months from December).

[0064] In any case, normalisation comprises adjusting the attribute difference by the scale increment for that attribute, step 72.

[0065] 5. The selected historical data record with which to make the prediction is the one with the shortest calculated distance from the target record, step 74. The attribute from the selected historical record which is to be used to make the prediction (in this case, CCpay or the ratio of CCpay/CCbal) is then determined.

[0066] 6. For the target record attributes, a count is made to determine which, for this customer, is the more interesting attribute. One fast way to do this for small data sets is to sum the absolute deviations from the average count (1.2, in this case, for 12 values from the previous transactions across 10 scale increments), steps 76 to 80. For the sample data, we have:

[0067] So the total weighting for CCPay was 10.6 whereas the weighting for the ratio attribute was 21.6. As such the ratio attribute, as expected, is considered to be the most useful, in this customer's case, for making a prediction.

[0068] It should be noted that more accurate weightings, based on the kurtosis of the distribution, or the standard deviation of the slot counts could be used although it has been found that this does improve performance much for this type of data. The weighting employed above, however, has the benefit of simplicity and speed. More complex weightings may be more beneficial for other domains.

[0069] It should also be noted that for attributes with a discrete value range, more or less than ten slots may be appropriate: for days of the week, seven slots should be used; for months of the year; twelve slots should be used; or for a yes/no value, two slots should be used.

[0070] 7. The dominant target attribute is selected, step 82, and used for prediction: in this example, the target attribute selected is the ratio attribute. The sub-system then populates as many possible attributes as possible in the target record from this dominant attribute, in this case, calculating the amount of the payment, step 84. Step 82 is repeated, if necessary, and the next most dominant attribute which has not been populated in the target record is chosen, and either further attributes are calculated from this attribute, if it is a ratio, or if it is an absolute value, then its value is simply copied into the corresponding attribute of the target record, steps 84 and 86. This process continues until the target record has been fully populated.

[0071] Based on the sample data above, some sample predictions are:

[0072] So, it can be seen that if the customer has a high cheque account balance, the prediction is that they will pay off the whole credit card balance, even though this is January, and last January they didn't pay off the whole balance. If the customer has a low balance, the prediction is that they will pay of partial balance. It should be seen that it is because the customer normally pays the full amount that means that the ratio is chosen as the dominant attribute, and so, where the closest historical record is one where the ratio is 0.1, the system will predict that a partial payment is required, rather than a full payment as would normally be the case.

[0073] 8. If a prediction is accepted by the customer, any initial weighting assigned by the domain expert to select the target record attribute is adjusted by the determined weights, step 90. So in the example above, using a simple adjustment, initial weightings of, say, 5 would be adjusted to 15.6 and 26.6 respectively. This helps to re-enforce the ability of the sub-system to predict well.

[0074] In a second example of the operation of the second embodiment, the customer chooses to pay an electricity bill, and so the target attribute the sub-system attempts to predict is the amount to be paid, without knowing the amount of the bill. Again only the amount needs to be predicted, although it will be seen that if both the nature of the bill and the amount needed to be predicted, this would also be possible.

[0075] In this example, the domain expert selects no ratio. Instead, the system tends to recommend the same payment as was made at this time last year. Using the system, next year, in month 2, with a cheque account balance of $760, the algorithm will predict a bill payment of $135, which is a reasonable guess from a domain expert's viewpoint.

[0076] It will be seen that while the examples described above relate to Internet Banking transactions, the invention has wider applicability for other, similar, transaction types where the attributes of a partially filled record are to be predicted from a set of historical records.