NOVEL METHOD
The present invention relates to a method for controlling the authorisation of an account transaction requested by or on behalf of a user, and to means for putting said method into effect, so as to improve the security of the authorisation procedure for account transactions.
In today's increasingly"cash-less"society, ever greater reliance is placed in everyday life on direct account transactions as a convenient means by which payments may be made or promised. Credit and debit card transactions, direct debit arrangements, bank transfers and other such transactions are widely employed, both by businesses and by individuals. Such account transactions have proved particularly valuable for the purposes of remote sales, for which the payer and payee are not physically present in the same location at the time of completion of sale. Thus, for example, a person holding an account with a fund holder such as a bank, building society or credit institution, who wishes to place an order by telephone, over theInternet, or in writing, for goods or for the regular supply of a service, is conveniently able to make or promise payment to the goods or service provider simply by supplying the provider with the number of his account, usually in conjunction with a fixed verification number (such as the card expiry date, or issue number). These numbers will be notified by the goods or service provider to the fund holder, together with an indication of the amount of the proposed account transaction. Authorisation for the transaction will be given by the fund holder if the numbers notified are correct (subject, of course, to the fulfilment of other relevant conditions, such as the existence of adequate funds in the account, or the prior agreement of a sufficient credit level for performance of the transaction).
The security of the authorisation procedures for account transactions has, however, become a matter of significant concern, both to account holders and to fund holders. A remote credit card transaction is typically authorised by a credit card company following the notification to the company of the credit card account number and the card issue number; no signature or other identifying information being required at the time of authorisation. This procedure is clearly open to fraudulent use by a third party who may have illicitly stored or noted down the account number and card issue number, for example following the completion of a legitimate credit card transaction. It is estimated that billions of dollars are lost each year through credit card fraud alone.
There is, therefore, an urgent need for improvements in the security of the authorisation procedure for account transactions, in particular remote transactions, so as to work towards the reduction or elimination of fraud.
According to one aspect of the present invention, therefore, there is provided a method for controlling the authorisation of an account transaction requested by or on behalf of a user, comprising the steps of prompting the provision of an account code by or on behalf of said user; ascertaining whether the code provided by or on behalf of said user matches a previously-agreed account code; if said code matches said previously-agreed account code, cancelling said previously-agreed account code and provided any relevant conditions imposed by or on behalf of the holder of funds in or in respect of said account are satisfied, authorising said transaction; if said code does not match said previously-agreed account code, not authorising said transaction.
According to this method, therefore, the authorisation of any account transaction requested by a user will require the provision by the user of a
"one-time code", which has previously been agreed between the account holder and the fund holder. After the one-time code has been used once for authorising or requesting authorisation of a transaction, the code is cancelled and cannot be used for the purpose of authorising future transactions. Hence, any third party who may intercept and/or illicitly record the one-time code provided by or on behalf of said user following a request for an account transaction will not be able to put this information to subsequent fraudulent use, as the cancellation of the one-time code by the holder of funds in said account will have exhausted the validity of that code for the purposes of authorising any future transactions.
Preferably, said method may further comprise the step of prompting the provision of information relating to said account transaction, which information may include information identifying said account, such as the number of said account, and/or information concerning the value of said transaction in currency, and/or other information concerning the nature of said transaction, such as information identifying the person in favour of whom the transaction is to be performed. Said method may further comprise the step of inspecting and/or processing said information so as to ascertain whether said relevant conditions are satisfied.
Advantageously, said method may further comprise the step of generating said previously-agreed account code, and notifying said previously-agreed account code to the holder of said account prior to the authorisation of said account transaction.
In preferred embodiments, said previously-agreed account code may be randomly generated. This will serve to ensure that said previously-agreed account code cannot be"worked out"by any third party on the basis of codes employed in connection with the authorisation of any earlier account
transactions.
Advantageously, a plurality of different previously-agreed account codes may be generated, and said holder of the account may be notified at regular or irregular intervals with successive batches of said different previously-agreed account codes, each batch comprising a plurality of codes. In particularly preferred embodiments, said batches of codes may be successively notified to said account holder on a regular basis, such as once a month, or more or less frequently. Alternatively, or in addition, said batches of codes may be successively notified to said account holder as and when required, for example when all or nearly all the previously-agreed account codes notified to the account holder have been used, or on requestSuitably, each batch of account codes may comprise between 2 and 50 codes, typically between 5 and 15 codes. However, the appropriate number of codes for inclusion in each batch may be determined by consideration of factors such as the rate of use of account codes by the account holder, and the frequency with which said batches of account codes are notified to the account holder. Accordingly, the number of codes in each batch notified to the account holder may be fixed, or may vary depending (for example) on the rate of use of the account codes by the account holder, or in response to a request by the account holder.
Conveniently, on notification of a batch of account codes to said account holder, any previously-agreed codes notified previously to said account holder may be automatically cancelled by or on behalf of said holder of funds, preferably with immediate effect. This will preclude the accumulation of a"back-log"of unused codes, in cases where the codes are only infrequently used.
Advantageously, said previously-agreed account codes in each batch of codes may be notified to said account holder in a particular order, and the arrangement may be such that if said code provided by or on behalf of said user does not match the first account code in said order, said account transaction is not authorised; and if said code provided by or on behalf of said user matches the first account code in said order, said first account code is cancelled and replaced by the next account code in said order. This will mean that, for the purposes of authorising a series of account transactions, the codes in each batch must be utilised by the account holder in order.
According to another aspect of the present invention, there is provided means adapted for controlling the authorisation of an account transaction requested by or on behalf of a user, said means comprising data supply means adapted for enabling the supply of an account code in connection with a request for authorisation of said account transaction by or on behalf of said user; and data processing means adapted for receiving said account code supplied to the data supply means, checking whether said account code matches a previously-agreed account code valid for said account, and if said account code matches said previously-agreed account code, cancelling said previously-agreed account code, and authorising said account transaction provided that any relevant conditions imposed by or on behalf of the holder of funds in said account are satisfied ; said data supply means being connectable to the data processing means so as to enable the transmission and reception of information therebetween.
Advantageously, said data supply means may also be adapted for enabling the supply of information relating to an account transaction, in connection with a request for authorisation of said account transaction by or on behalf of said user; and said data processing means may also be adapted for receiving said information supplied to the data supply means, and inspecting
said information so as to identify said account and/or the value of said transaction in currency and/or the person in favour of whom the transaction is to be performed. In some embodiments, said data processing means may be adapted for prompting the supply of an account code by or on behalf of said user following and in response to the receipt of said information. Said data processing means may be adapted for inspecting and/or processing said information relating to an account transaction so as to ascertain whether said relevant conditions are satisfied.
Said information relating to an account transaction may include information identifying said account, such as the number of said account, and/or information concerning the value of said transaction in currency, and/or other information concerning the nature of said transaction, such as information identifying the person in favour of whom the transaction is to be performed.
In preferred embodiments, said data processing means is centrally located, and a plurality of remote data supply means are provided, which data supply means can be used by or on behalf of a plurality of users in a plurality of different locations. Said or each data supply means may comprise a screen adapted for displaying visual information relating to said account transaction and/or a keyboard adapted for supplying said code.
In said method or means for controlling the authorisation of an account transaction, said relevant conditions may, for example, include a requirement for funds in excess of the value of said account transaction to be present in said account; and/or a condition that said value of said account transaction does not exceed a particular amount; and/or any other condition or conditions which may have been previously agreed between the holder of funds in said account and the account holder, and/or previously specified or stated by or on behalf of the holder of funds in said account. One or more or
no relevant conditions may be imposed by or on behalf of the holder of funds in said account.
Advantageously, said or each previously-agreed account code may comprise a plurality of letters and/or symbols and/or digits and/or spaces.
Conveniently, said account code may be suitable for communication orally, in writing, or electronically, for example via e-mail or over the Internet.
Accordingly, said account code may suitably comprise a plurality of typographical symbols, letters, digits and/or spaces. Preferably, each account code may comprise between 3 and 25 symbols, letters, digits and/or spaces.
In particular, where said account code is supplied in conjunction with other information identifying said account, such as an account number, said account code may advantageously comprise between 3 and 8 symbols, letters, digits and/or spaces. Where said account code is not supplied in conjunction with other information identifying said account, said account code may advantageously comprise between 12 and 25 symbols, letters, digits and/or spaces, such as 16-20 symbols, letters, digits and/or spaces.
Typically, the method of the present invention may be carried out by or on behalf of the holder of funds in or in respect of said account. Said holder of funds may for example be a bank, a building society, a retail institution, or a credit institution.
Said account may be a debit account or a credit account. Typically, said account transaction may involve the removal of funds from said account, or the accumulation of credit in respect of said account.
Said account holder may be a natural or legal person, such as a private individual or a company.
Said authorisation of the account transaction may usually comprise the performance of said transaction by the holder of funds in said account, or a statement, promise, agreement or fixed intention by the holder of funds in said account that said transaction will be performed. Advantageously, said authorisation of the account transaction may be performed on the basis of said information relating to the account transaction.
Said prompting of an account code may comprise an explicit request for the supply of an account code by or on behalf of a user. More generally, however, said prompting of an account code comprises a requirement that an account code be supplied by or on behalf of a user.
The method of the present invention may be particularly suited for use in connection with account transactions which are remotely requested by or on behalf of said user, for example in writing, by telephone or facsimile, or electronically, such as by email or via the Internet or other local or widearea network.
Following is a description, by way of example only, of an embodiment of the present invention.
Figure 1 shows a list of account codes issued by a credit card company to a credit card account holder, for use during the month of August 2000.
Figure 2 is a schematic diagram illustrating a means for controlling the authorisation of a credit card account transaction, in accordance with the present invention.
Figure 3 is a flow chart illustrating the checking and authorisation procedure carried out by the processing means illustrated in Figure 2.
A credit card company will conventionally assign a unique and permanent account number, typically 16 digits in length, to each account opened by a customer. This account number is notified to the client holding the account, and is typically printed or embossed on the surface of the credit card or cards issued by the credit card company to the account holder. The number can be used subsequently in order to identify the account for the purposes (inter alia) of requesting and authorising account transactions.
In implementing the method of the present invention, the credit card company will typically issue each account holder on a monthly basis with a batch of confidential account codes in a specified order (see Figure 1). A record of the batch of account codes, in order, will be kept by the company.
The number of account codes in the batch will vary from case to case, depending on the previous frequency of use of such codes by the account holder.
Figures 2 and 3 illustrate a system for authorising a credit card payment to be made on behalf of a customer to a shop, in respect of an order for goods which has been placed remotely by the customer (for example, by telephone). The customer holds a credit card account with a credit card company, and has previously been issued by the credit card company with a list of confidential account codes for use in connection with remote account transactions (see Figure 1).
On receipt of the customer's order, the shop notify the customer of the cost of the order, and request him to provide a valid account code.
The code supplied by the customer and the cost of the order are entered by the shop into a PC (1), and this information, together with details of the shop's bank account, is transmitted via a modem and telephone line (2) to
the credit card company's server (3), which includes a processing means (4) adapted for receiving this information.
Figure 3 sets out the steps taken by the processing means on receipt of this information. As shown in Figure 3, the account code supplied by the customer is checked against the first code in the list of confidential account codes most recently supplied to each person holding an account with the credit card company. If a match is found, the first of the confidential account codes on the list in question is immediately cancelled, and replaced by the next code on that list. The credit level in the account in question is then assessed in view of the cost of the order requested by the customer. Provided that the payment of this amount would not take the credit level in the account above a pre-agreed level, the payment is authorised. Authorisation of the payment involves the transmission of electronic instructions from the credit card company's server to the credit card company's bank's server, specifying the transfer of funds totalling the cost of said order from the credit card company's bank account to the shop's bank account; and the recording of this transaction in connection with the customer's account.
As will be noted, the account code supplied on behalf of the customer, if correct, is cancelled whether or not authorisation is forthcoming. Hence, any person who may make a record of the account code supplied in connection with a credit card transaction or attempted transaction will be unable to use this data for fraudulent purposes, as the account code will no longer be valid for the purposes of future transactions. Accordingly, a significant increase in the security of the authorisation procedure will be achieved.
Cancellation procedures for credit card account numbers are already implemented by credit card companies, for the purpose of"stopping"credit card accounts after a credit card has been reported lost or stolen. Such
procedures can be readily adapted for the purposes of cancelling account codes, in accordance with the present invention.
The authorisation procedure of the present invention may be used only for the purposes of remote transactions, where the account holder is not physically present at the point of sale-such as purchases made over the telephone or over the Internet. Alternatively, the authorisation procedure may be employed for the purposes of any or all credit card transactions.