CA2311418A1 - Method and system for predicting transactions - Google Patents
Method and system for predicting transactions Download PDFInfo
- Publication number
- CA2311418A1 CA2311418A1 CA002311418A CA2311418A CA2311418A1 CA 2311418 A1 CA2311418 A1 CA 2311418A1 CA 002311418 A CA002311418 A CA 002311418A CA 2311418 A CA2311418 A CA 2311418A CA 2311418 A1 CA2311418 A1 CA 2311418A1
- Authority
- CA
- Canada
- Prior art keywords
- attributes
- target record
- attribute
- sub
- record
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/02—Marketing; Price estimation or determination; Fundraising
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/90—Details of database functions independent of the retrieved data types
- G06F16/95—Retrieval from the web
- G06F16/958—Organisation or management of web site content, e.g. publishing, maintaining pages or automatic linking
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/02—Banking, e.g. interest calculation or account maintenance
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
- Y10S707/99933—Query processing, i.e. searching
- Y10S707/99936—Pattern matching access
Abstract
The invention provides a system for predicting a transaction a customer may wish to make.
In, for example, an Internet banking system, when the customer clicks to bring up an "inter-account transfer" panel, the system 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 a given amount 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 transaction so that with a single-click the customer can complete the transaction.
In, for example, an Internet banking system, when the customer clicks to bring up an "inter-account transfer" panel, the system 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 a given amount 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 transaction so that with a single-click the customer can complete the transaction.
Description
METHOD AND SYSTEM FOR PREDICTING TRANSACTIONS
The present invention provides a method and system for predicting transactions, in particular, to aid in providing personalisation for Internet transactions.
It has long been a goal of data mining applications to attempt to predict an 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 to 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.
15 US Patent 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 2o 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 ofJ user data before it can make a prediction relating to a single user.
25 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 dollarsin 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.
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.
Accordingly the present invention provides a personalisation sub-system as claimed in claim 1.
So, for example, when the customer clicks to bring up an "inter-account transfer" panel in a banking transaction, 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 S00 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 2o a single-click option to complete the current transaction, Figure 2.
Embodiments of the invention will now be described with reference to the accompanying drawings, in which:
Figure 1 is a schematic diagram of an Internet banking system including the personalisation sub-system according to the invention;
Figure 2 shows a page for a predicted transaction generated according to the invention;
Figure 3 is a flow diagram illustrating the operation of a first embodiment of the invention;
and Figure 4 is a flow diagram illustrating the operation of a second embodiment of the invention.
Referring now to Figure 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 only might customers connect from conventional personal computers, but also from mobile phones or digital televisions or other pervasive computer devices.
Nor is it necessary 1o to use a browser, as it is possible for the client to, for example, run a dedicated program.
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 15 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, JavaServer PagesTM (JSPs) code or Active Server 2o Pages (ASPS) code, the description of which is not thought necessary for the purposes of describing the operation of the present invention.
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 25 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.
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 GB9-1999-O l 03 3 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.
It will be seen, however that, for implementations where dozens of records are retrieved, the overhead of transferring 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 reside on the server side, behind JSPs or ASPs, and generate HTML as its result, to be sent to the client.
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 Figure 3:
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, 2o 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 Figure 2, which shows an inter-account transfer, the template has the following attributes:
sourceAccount targetAccount transferAmount sourceAccountBalanceBeforeTransfer targetAccountBalanceBeforeTransfer GB9-1999-O l 03 dayOfTheWeekOfTransfer (range 0-6) dayOfTheMonthOfTransfer (range 1-31) monthOfTransfer (range 1-12) 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.
Scoring: The obj ective of the scoring step is to find similar records from the pool to the current l0 transaction. 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.
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 2o some templates, it may not be possible to complete all attributes for each record).
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.
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 GB9-1999-O l 03 5 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.
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 predefined by a human business analyst.
to 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.
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.
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.
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 Figure 2.
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 Figure 2, only the targetAccount and transferAmount attributes are of interest), a "most likely"
value is found.
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.
1 o The resulting completed target record is then used to produce the HTML
text in the window accompanying the target transaction, Figure 2.
It will be seen, however, that in certain cases a prediction for the current transaction is only useful if it is exactly what is required. Take for example, a customer who always pays their entire 15 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.
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.
2o 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.
A weighting is associated with each attribute and the sub-system performs an automatic 25 adjustment of weightings to select the appropriate target attribute on which to base a prediction, based on only the historical data for this customer.
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.
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.
The operation ofthe second embodiment will now be described in more detail with reference to Figure 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.
1 o 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.
Based on the domain expert's understanding of credit card repayments, the expert adds a fifth 15 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.
2o GB9-1999-O 103 g 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).
Month Cheque accountCredit card Payment Ratio balance: Ch balance: CCbal(CC a ) CC a /CCbal bal 1 $50 $350 $35 0.1 2 $450 $440 $440 1.0 3 $650 $120 $120 1.0 4 $710 $210 $210 1.0 5 $760 $180 $180 1.0 to 6 $550 $230 $230 1.0 7 $50 $290 _ 0.1 $29 8 $610 $380 $380 1.0 9 $680 $160 $160 1.0 $710 $130 $130 1.0 11 $770 $190 $190 1.0 12 $610 $320 $32 0.1 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 2o 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.
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.
1. Minimum and maximum values for each attribute of the current transactions (in this case, 3o month, Chqbal, Ccbal, CCpay, CCpay/CCbal) are set to null, step 66.
2. Each historical data record is presented to the sub-system. For each record:
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.
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:
scale increment = (maximum value - minimum value) number of scale increments 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.
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:
EuclidianDistance= F(NormalisedAttributeDistance2) 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.
For circular attributes such as the month of the year, time of day, etc., the normalised 2o 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).
In any case, normalisation comprises adjusting the attribute difference by the scale increment for that attribute, step 72.
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.
The present invention provides a method and system for predicting transactions, in particular, to aid in providing personalisation for Internet transactions.
It has long been a goal of data mining applications to attempt to predict an 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 to 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.
15 US Patent 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 2o 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 ofJ user data before it can make a prediction relating to a single user.
25 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 dollarsin 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.
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.
Accordingly the present invention provides a personalisation sub-system as claimed in claim 1.
So, for example, when the customer clicks to bring up an "inter-account transfer" panel in a banking transaction, 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 S00 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 2o a single-click option to complete the current transaction, Figure 2.
Embodiments of the invention will now be described with reference to the accompanying drawings, in which:
Figure 1 is a schematic diagram of an Internet banking system including the personalisation sub-system according to the invention;
Figure 2 shows a page for a predicted transaction generated according to the invention;
Figure 3 is a flow diagram illustrating the operation of a first embodiment of the invention;
and Figure 4 is a flow diagram illustrating the operation of a second embodiment of the invention.
Referring now to Figure 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 only might customers connect from conventional personal computers, but also from mobile phones or digital televisions or other pervasive computer devices.
Nor is it necessary 1o to use a browser, as it is possible for the client to, for example, run a dedicated program.
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 15 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, JavaServer PagesTM (JSPs) code or Active Server 2o Pages (ASPS) code, the description of which is not thought necessary for the purposes of describing the operation of the present invention.
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 25 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.
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 GB9-1999-O l 03 3 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.
It will be seen, however that, for implementations where dozens of records are retrieved, the overhead of transferring 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 reside on the server side, behind JSPs or ASPs, and generate HTML as its result, to be sent to the client.
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 Figure 3:
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, 2o 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 Figure 2, which shows an inter-account transfer, the template has the following attributes:
sourceAccount targetAccount transferAmount sourceAccountBalanceBeforeTransfer targetAccountBalanceBeforeTransfer GB9-1999-O l 03 dayOfTheWeekOfTransfer (range 0-6) dayOfTheMonthOfTransfer (range 1-31) monthOfTransfer (range 1-12) 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.
Scoring: The obj ective of the scoring step is to find similar records from the pool to the current l0 transaction. 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.
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 2o some templates, it may not be possible to complete all attributes for each record).
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.
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 GB9-1999-O l 03 5 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.
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 predefined by a human business analyst.
to 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.
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.
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.
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 Figure 2.
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 Figure 2, only the targetAccount and transferAmount attributes are of interest), a "most likely"
value is found.
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.
1 o The resulting completed target record is then used to produce the HTML
text in the window accompanying the target transaction, Figure 2.
It will be seen, however, that in certain cases a prediction for the current transaction is only useful if it is exactly what is required. Take for example, a customer who always pays their entire 15 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.
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.
2o 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.
A weighting is associated with each attribute and the sub-system performs an automatic 25 adjustment of weightings to select the appropriate target attribute on which to base a prediction, based on only the historical data for this customer.
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.
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.
The operation ofthe second embodiment will now be described in more detail with reference to Figure 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.
1 o 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.
Based on the domain expert's understanding of credit card repayments, the expert adds a fifth 15 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.
2o GB9-1999-O 103 g 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).
Month Cheque accountCredit card Payment Ratio balance: Ch balance: CCbal(CC a ) CC a /CCbal bal 1 $50 $350 $35 0.1 2 $450 $440 $440 1.0 3 $650 $120 $120 1.0 4 $710 $210 $210 1.0 5 $760 $180 $180 1.0 to 6 $550 $230 $230 1.0 7 $50 $290 _ 0.1 $29 8 $610 $380 $380 1.0 9 $680 $160 $160 1.0 $710 $130 $130 1.0 11 $770 $190 $190 1.0 12 $610 $320 $32 0.1 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 2o 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.
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.
1. Minimum and maximum values for each attribute of the current transactions (in this case, 3o month, Chqbal, Ccbal, CCpay, CCpay/CCbal) are set to null, step 66.
2. Each historical data record is presented to the sub-system. For each record:
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.
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:
scale increment = (maximum value - minimum value) number of scale increments 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.
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:
EuclidianDistance= F(NormalisedAttributeDistance2) 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.
For circular attributes such as the month of the year, time of day, etc., the normalised 2o 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).
In any case, normalisation comprises adjusting the attribute difference by the scale increment for that attribute, step 72.
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.
6. For the target record attributes, a count is made to determine which, for this customer, is the s 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:
Normalised Count Absolute Normalised Count Abs to CC (Count-1.2) ratio ran (Count-1.2) a ran a a 29-69 3 1.8 0.1-0.18 3 1.8 70-110 0 1.2 0.19-0.27 0 1.2 111-151 2 0.8 0.28-0.36 0 1.2 152-192 3 1.8 0.37-0.45 0 1.2 t5 193-233 2 0.8 0.46-0.54 0 1.2 234-274 0 1.2 0.55-0.63 0 1.2 275-315 0 1.2 0.64-0.72 0 1.2 316-356 0 1.2 0.73-0.81 0 1.2 357-397 1 0.2 0.82-0.9 0 1.2 20 398-440 1 0.2 0.91-1.0 9 7.8 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.
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 not 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.
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.
Normalised Count Absolute Normalised Count Abs to CC (Count-1.2) ratio ran (Count-1.2) a ran a a 29-69 3 1.8 0.1-0.18 3 1.8 70-110 0 1.2 0.19-0.27 0 1.2 111-151 2 0.8 0.28-0.36 0 1.2 152-192 3 1.8 0.37-0.45 0 1.2 t5 193-233 2 0.8 0.46-0.54 0 1.2 234-274 0 1.2 0.55-0.63 0 1.2 275-315 0 1.2 0.64-0.72 0 1.2 316-356 0 1.2 0.73-0.81 0 1.2 357-397 1 0.2 0.82-0.9 0 1.2 20 398-440 1 0.2 0.91-1.0 9 7.8 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.
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 not 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.
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.
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 to 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.
Based on the sample data above, some sample predictions are:
Sample Mt Cheque account Credit card Nearest Ratio h balance: Ch balance: CCbalrecord CC a /CCbal bal #1 1 $250 $380 1 0.1 #2 1 $450 $380 2 1 2o 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.
Based on the sample data above, some sample predictions are:
Sample Mt Cheque account Credit card Nearest Ratio h balance: Ch balance: CCbalrecord CC a /CCbal bal #1 1 $250 $380 1 0.1 #2 1 $450 $380 2 1 2o 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.
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.
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.
Month Cheque accountElectricity bill balance a ment 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 2o reasonable guess from a domain expert's viewpoint.
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.
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.
Month Cheque accountElectricity bill balance a ment 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 2o reasonable guess from a domain expert's viewpoint.
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.
Claims (24)
1. A personalisation sub-system for a transaction processing system comprising a server responsive to requests from a client computing device to execute a transaction, said sub-system comprising:
means, responsive to said client request, for obtaining historical records corresponding to previous client transactions;
means for partially populating a target record from data available to said sub-system, said target record comprising a plurality of attributes;
means for measuring the similarity of each of said historical records to said partially populated target record;
means for selecting at least one similar historical record;
means for populating remaining target record attributes from at least one corresponding attribute of the at least one similar historical record; and means for providing said populated target record to said system as a prediction of said transaction to be executed.
means, responsive to said client request, for obtaining historical records corresponding to previous client transactions;
means for partially populating a target record from data available to said sub-system, said target record comprising a plurality of attributes;
means for measuring the similarity of each of said historical records to said partially populated target record;
means for selecting at least one similar historical record;
means for populating remaining target record attributes from at least one corresponding attribute of the at least one similar historical record; and means for providing said populated target record to said system as a prediction of said transaction to be executed.
2. The personalisation sub-system of claim 1 wherein said sub-system is adapted to reside on said client computing device.
3. The personalisation sub-system of claim 1 or claim 2 wherein said selecting means is adapted to select a pre-determined number of similar historical records; and said populating means is adapted to populate said remaining target record attributes as a function of said pre-determined number of similar historical records' corresponding attributes.
4. The personalisation sub-system of claim 3 wherein said function is a median of said pre-determined number of similar historical records' continuous attributes or a mode of said pre-determined number of similar historical records' discrete attributes.
5. The personalisation sub-system of any one of claims 1 to 4 comprising:
means for calculating a weighting for each remaining target record attribute, said weighting being indicative of a remaining target record attribute's dominance; and wherein said selecting means is adapted to select a most similar historical record; and said populating means is adapted to populate said remaining target record attributes in order of said remaining target record attributes' dominance.
means for calculating a weighting for each remaining target record attribute, said weighting being indicative of a remaining target record attribute's dominance; and wherein said selecting means is adapted to select a most similar historical record; and said populating means is adapted to populate said remaining target record attributes in order of said remaining target record attributes' dominance.
6. The personalisation sub-system of claim 5 wherein said target record attributes comprise a combination of absolute value attributes and attributes whose value is derived from other attributes, and said populating means is responsive to a derived value attribute being the most dominant remaining attribute to populate said target record's corresponding derived value attribute and any remaining target record attributes that can be calculated from said derived value attribute.
7. The personalisation sub-system of any one of claims 1 to 4 comprising means, responsive to said client accepting said prediction, for increasing the weighting of the most dominant remaining target record attribute.
8. The personalisation sub-system of any one of claims 1 to 7 wherein said transaction processing system is an Internet transaction processing system.
9. The personalisation sub-system of any one of claims 1 to 8 wherein said transaction processing system is an Internet bank system.
10. The personalisation sub-system of claim 9 wherein said available data comprises any combination of a current time, a current date or one or more current account balances.
11. The personalisation sub-system of any one of claims 1 to 10 wherein said measuring means comprises means for calculating a normalised Euclidian distance between each of said historical records and said partially populated target record.
12. A method, operable in a transaction processing system comprising a server responsive to requests from a client computing device to execute a transaction, of personalising said system, comprising the steps of:
responsive to said client request, obtaining historical records corresponding to previous client transactions;
partially populating a target record from data available to said sub-system, said target record comprising a plurality of attributes;
measuring the similarity of each of said historical records to said partially populated target record;
selecting at least one similar historical record;
populating remaining target record attributes from at least one corresponding attribute of the at least one similar historical record; and providing said populated target record to said system as a prediction of said transaction to be executed.
responsive to said client request, obtaining historical records corresponding to previous client transactions;
partially populating a target record from data available to said sub-system, said target record comprising a plurality of attributes;
measuring the similarity of each of said historical records to said partially populated target record;
selecting at least one similar historical record;
populating remaining target record attributes from at least one corresponding attribute of the at least one similar historical record; and providing said populated target record to said system as a prediction of said transaction to be executed.
13. The method of claim 12 wherein said method is adapted to be performed on said client computing device.
14. The method of claim 12 or claim 13 wherein said step of selecting is adapted to select a pre-determined number of similar historical records; and said step of populating is adapted to populate said remaining target record attributes as a function of said pre-determined number of similar historical records' corresponding attributes.
15. The method of claim 14 wherein said function is a median of said pre-determined number of similar historical records' continuous attributes or a mode of said pre-determined number of similar historical records' discrete attributes.
16 16. The method of any one of claims 12 to 15 comprising the step of calculating a weighting for each remaining target record attribute, said weighting being indicative of a remaining target record attribute's dominance; and wherein said step of selecting is adapted to select a most similar historical record; and said step of populating is adapted to populate said remaining target record attributes in order of said remaining target record attributes' dominance.
17. The method of claim 16 wherein said target record attributes comprise a combination of absolute value attributes and attributes whose value is derived from other attributes, and said step of populating is responsive to a derived value attribute being the most dominant remaining attribute to populate said target record's corresponding derived value attribute and any remaining target record attributes that can be calculated from said derived value attribute.
18. The method of any one of claims 12 to 15 comprising the step of, responsive to said client accepting said prediction, for increasing the weighting of the most dominant remaining target record attribute.
19. The method of any one of claims 12 to 18 wherein said transaction processing system is an Internet transaction processing system.
20. The method of any one of claims 12 to 19 wherein said transaction processing system is an Internet bank system.
21. The method of claim 20 wherein said available data comprises any combination of a current time, a current date or one or more current account balances.
22. The method of any one of claims 12 to 21 wherein said step of measuring comprises the step of calculating a normalised Euclidian distance between each of said historical records and said partially populated target record.
23. A computer program product comprising computer program code stored on a computer readable storage medium for, when executed on a computing device, causing the computer device to perform the steps of any one of claims 12 to 22.
24. A computer program product comprising computer program code stored on a computer readable storage medium for, when executed on a computing device, predicting a transaction, the program code comprising the personalisation sub-system of any one of claims 1 to 11.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GB9922640A GB2354609B (en) | 1999-09-25 | 1999-09-25 | Method and system for predicting transactions |
| GB9922640.9 | 1999-09-25 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2311418A1 true CA2311418A1 (en) | 2001-03-25 |
Family
ID=10861542
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002311418A Abandoned CA2311418A1 (en) | 1999-09-25 | 2000-06-13 | Method and system for predicting transactions |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US6519576B1 (en) |
| CA (1) | CA2311418A1 (en) |
| GB (1) | GB2354609B (en) |
Families Citing this family (33)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1337944A4 (en) * | 2000-10-27 | 2007-07-04 | Vanguard Trademark Holdings Us | System and method for completing a rental agreement online |
| WO2002067079A2 (en) * | 2000-10-27 | 2002-08-29 | Anc Rental Corporation | Method for completing and storing an electronic rental agreement |
| JP4586281B2 (en) * | 2001-03-13 | 2010-11-24 | コニカミノルタビジネステクノロジーズ株式会社 | Data transmission management apparatus, data transmission management method, data transmission management program, and computer-readable recording medium recording the data transmission management program |
| US6819748B2 (en) * | 2001-09-27 | 2004-11-16 | Capital One Financial Corporation | Menuing method and system |
| US8176186B2 (en) | 2002-10-30 | 2012-05-08 | Riverbed Technology, Inc. | Transaction accelerator for client-server communications systems |
| US8069225B2 (en) * | 2003-04-14 | 2011-11-29 | Riverbed Technology, Inc. | Transparent client-server transaction accelerator |
| FR2848001A1 (en) * | 2002-11-29 | 2004-06-04 | Francois Nadal | METHOD AND SYSTEM FOR REAL-TIME ANTICIPATING, IDENTIFYING, ANALYZING AND RESPONDING TO CONSUMER NEEDS |
| US20050097122A1 (en) * | 2003-08-29 | 2005-05-05 | Thierry Schafflutzel | Redundancy-free provision of multi-purpose data |
| US20050054381A1 (en) * | 2003-09-05 | 2005-03-10 | Samsung Electronics Co., Ltd. | Proactive user interface |
| US20050125280A1 (en) * | 2003-12-05 | 2005-06-09 | Hewlett-Packard Development Company, L.P. | Real-time aggregation and scoring in an information handling system |
| KR100590538B1 (en) * | 2004-02-19 | 2006-06-15 | 삼성전자주식회사 | Method for removing missing vlaues in measured data |
| US20050187756A1 (en) * | 2004-02-25 | 2005-08-25 | Nokia Corporation | System and apparatus for handling presentation language messages |
| US7313575B2 (en) * | 2004-06-14 | 2007-12-25 | Hewlett-Packard Development Company, L.P. | Data services handler |
| US20060248194A1 (en) | 2005-03-18 | 2006-11-02 | Riverbed Technology, Inc. | Connection forwarding |
| US7542916B2 (en) * | 2005-08-05 | 2009-06-02 | International Business Machines Corporation | Queue busting through assignment of kiosks to users |
| US8495139B2 (en) * | 2005-08-05 | 2013-07-23 | International Business Machines Corporation | Automatic scheduling and establishment of conferences |
| US7869583B2 (en) * | 2005-08-05 | 2011-01-11 | International Business Machines Corporation | Real time meeting setup service |
| US20070031804A1 (en) * | 2005-08-05 | 2007-02-08 | International Business Machines Corporation | Personalized course alerts and course completion recording service |
| US20070033382A1 (en) * | 2005-08-05 | 2007-02-08 | International Business Machines Corporation | Dynamic configuration of terminals for professional or customer usage |
| US7497373B2 (en) * | 2005-08-05 | 2009-03-03 | International Business Machines Corporation | Intelligent reminder service to track customer requests and processing |
| US20070078766A1 (en) * | 2005-10-03 | 2007-04-05 | Thomas Michael R | Charitable donations via ATMs |
| US8271309B2 (en) | 2006-03-16 | 2012-09-18 | The Crawford Group, Inc. | Method and system for providing and administering online rental vehicle reservation booking services |
| US8490869B2 (en) * | 2006-05-10 | 2013-07-23 | Metavante Corporation | Predictive authorization techniques |
| US8463843B2 (en) * | 2006-05-26 | 2013-06-11 | Riverbed Technology, Inc. | Throttling of predictive ACKs in an accelerated network communication system |
| US9098613B2 (en) * | 2006-06-23 | 2015-08-04 | Sap Se | Logging of application messages |
| US20110307374A1 (en) * | 2010-06-09 | 2011-12-15 | James Allan Grundner | Account Prediction Tools |
| US20140324524A1 (en) * | 2013-04-30 | 2014-10-30 | Wal-Mart Stores, Inc. | Evolving a capped customer linkage model using genetic models |
| US10803402B2 (en) * | 2017-03-30 | 2020-10-13 | Ncr Corporation | Autopilot network service processing |
| US11087314B2 (en) | 2018-09-26 | 2021-08-10 | The Toronto-Dominion Bank | Adaptive remittance learning |
| US10825307B1 (en) * | 2019-06-24 | 2020-11-03 | International Business Machines Corporation | Transaction plan management |
| US11017401B1 (en) | 2019-11-21 | 2021-05-25 | Rockspoon, Inc. | Predictive pre-authorization of transactions using passive biometrics |
| US11580545B2 (en) | 2019-11-21 | 2023-02-14 | Rockspoon, Inc. | Predictive pre-authorization of subsidiary accounts using passive biometrics |
| US20220277319A1 (en) * | 2021-03-01 | 2022-09-01 | Jpmorgan Chase Bank, N.A. | Methods and systems for forecasting payment card usage |
Family Cites Families (28)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5819226A (en) * | 1992-09-08 | 1998-10-06 | Hnc Software Inc. | Fraud detection using predictive modeling |
| GB9320072D0 (en) * | 1993-09-29 | 1993-11-17 | Ncr Int Inc | Self-service system having predictive capability |
| GB9323489D0 (en) * | 1993-11-08 | 1994-01-05 | Ncr Int Inc | Self-service business system |
| US5799087A (en) * | 1994-04-28 | 1998-08-25 | Citibank, N.A. | Electronic-monetary system |
| US5546523A (en) * | 1995-04-13 | 1996-08-13 | Gatto; James G. | Electronic fund transfer system |
| IL118580A0 (en) * | 1995-06-30 | 1996-10-16 | Massachusetts Inst Technology | Method and apparatus for item recommendation using automated collaborative filtering |
| JPH0962747A (en) * | 1995-08-25 | 1997-03-07 | Hitachi Ltd | Automatic banking transaction system with learning function |
| US5726688A (en) * | 1995-09-29 | 1998-03-10 | Ncr Corporation | Predictive, adaptive computer interface |
| US6061433A (en) * | 1995-10-19 | 2000-05-09 | Intervoice Limited Partnership | Dynamically changeable menus based on externally available data |
| US5748847A (en) * | 1995-12-21 | 1998-05-05 | Maryland Technology Corporation | Nonadaptively trained adaptive neural systems |
| US6026397A (en) * | 1996-05-22 | 2000-02-15 | Electronic Data Systems Corporation | Data analysis system and method |
| US5727129A (en) * | 1996-06-04 | 1998-03-10 | International Business Machines Corporation | Network system for profiling and actively facilitating user activities |
| US5864340A (en) * | 1996-08-22 | 1999-01-26 | International Business Machines Corporation | Mobile client computer programmed to predict input |
| GB9618110D0 (en) * | 1996-08-30 | 1996-10-09 | Ncr Int Inc | Improved self-service system |
| JP3067676B2 (en) * | 1997-02-13 | 2000-07-17 | 日本電気株式会社 | Apparatus and method for predictive encoding of LSP |
| JPH10334310A (en) * | 1997-06-02 | 1998-12-18 | Oki Electric Ind Co Ltd | Automatic transaction device |
| US5933818A (en) * | 1997-06-02 | 1999-08-03 | Electronic Data Systems Corporation | Autonomous knowledge discovery system and method |
| US6023688A (en) * | 1997-11-28 | 2000-02-08 | Diebold, Incorporated | Transaction apparatus and method that identifies an authorized user by appearance and voice |
| US6286018B1 (en) * | 1998-03-18 | 2001-09-04 | Xerox Corporation | Method and apparatus for finding a set of documents relevant to a focus set using citation analysis and spreading activation techniques |
| US6049797A (en) * | 1998-04-07 | 2000-04-11 | Lucent Technologies, Inc. | Method, apparatus and programmed medium for clustering databases with categorical attributes |
| US6047287A (en) * | 1998-05-05 | 2000-04-04 | Justsystem Pittsburgh Research Center | Iterated K-nearest neighbor method and article of manufacture for filling in missing values |
| US6192360B1 (en) * | 1998-06-23 | 2001-02-20 | Microsoft Corporation | Methods and apparatus for classifying text and for building a text classifier |
| US6202068B1 (en) * | 1998-07-02 | 2001-03-13 | Thomas A. Kraay | Database display and search method |
| US6289354B1 (en) * | 1998-10-07 | 2001-09-11 | International Business Machines Corporation | System and method for similarity searching in high-dimensional data space |
| US6263334B1 (en) * | 1998-11-11 | 2001-07-17 | Microsoft Corporation | Density-based indexing method for efficient execution of high dimensional nearest-neighbor queries on large databases |
| US6226408B1 (en) * | 1999-01-29 | 2001-05-01 | Hnc Software, Inc. | Unsupervised identification of nonlinear data cluster in multidimensional data |
| US6430539B1 (en) * | 1999-05-06 | 2002-08-06 | Hnc Software | Predictive modeling of consumer financial behavior |
| US6349309B1 (en) * | 1999-05-24 | 2002-02-19 | International Business Machines Corporation | System and method for detecting clusters of information with application to e-commerce |
-
1999
- 1999-09-25 GB GB9922640A patent/GB2354609B/en not_active Expired - Lifetime
-
2000
- 2000-02-17 US US09/506,163 patent/US6519576B1/en not_active Expired - Fee Related
- 2000-06-13 CA CA002311418A patent/CA2311418A1/en not_active Abandoned
Also Published As
| Publication number | Publication date |
|---|---|
| GB2354609A (en) | 2001-03-28 |
| GB2354609B (en) | 2003-07-16 |
| US6519576B1 (en) | 2003-02-11 |
| GB9922640D0 (en) | 1999-11-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6519576B1 (en) | Method and system for predicting transaction | |
| US10013717B2 (en) | Transaction effects | |
| US10019697B2 (en) | System and method for flexible payment terms | |
| US6049782A (en) | Relationship management system and process for pricing financial instruments based on a customer's relationship with a financial institution | |
| US20190043136A1 (en) | Modelling of Risk Mitigation | |
| US7630935B2 (en) | Award system with increased payout options | |
| US20130282542A1 (en) | Method, apparatus and system for retrieving financial data | |
| US6938008B1 (en) | Loan modeller method and apparatus | |
| US20030130917A1 (en) | Computer system for determining the risk index of a financial instrument and relevant method | |
| US8146807B2 (en) | Method and system for managing case based promises to pay | |
| US20080015982A1 (en) | Funds transfer method and system including payment enabled invoices | |
| US20030065602A1 (en) | Methods and systems for preference-based dynamic passive investing | |
| US20080177652A1 (en) | Methods and systems for managing and trading using a shared order book as internal exchange | |
| US6584453B1 (en) | Reversible move/merge operation for a general ledger | |
| US20130046670A1 (en) | System and method for managing enhancement features assigned to financial presentation devices | |
| US9430759B2 (en) | Fees and foreign currency exchange calculation | |
| WO2010045060A1 (en) | Customizable graphical user interface | |
| WO2008011102A2 (en) | Funds transfer method and system including payment enabled invoices | |
| JP7432659B2 (en) | Account management systems, account management methods, and programs | |
| WO2010045061A1 (en) | Customized card-building tool | |
| US20230281710A1 (en) | Tools for purchasing transactions | |
| US20020010660A1 (en) | Hosting service system of household account information, household account server, account information providing server, household account information processing server, and method for providing household account information using network and storage medium | |
| JP2005216097A (en) | System and method for providing transaction account information | |
| US7970700B2 (en) | Financial products | |
| US7983981B1 (en) | Exchange traded funds and mutual funds providing cash flow distributions |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| FZDE | Discontinued |