WO2003012714A1

WO2003012714A1 - A security system for transactions

Info

Publication number: WO2003012714A1
Application number: PCT/NZ2002/000142
Authority: WO
Inventors: Karen Elizabeth Courtney
Original assignee: Karen Elizabeth Courtney
Priority date: 2001-07-31
Filing date: 2002-07-31
Publication date: 2003-02-13

Abstract

This security system assists financial transactions with a single-use unique token, generated on request at a payer's bank by the bank's secure software. The token has no value to an interceptor. The token, carrying abbreviated accounts information, is handed to the payee as proof that funds have been set aside. The payee hands the token to his bank and funds are transferred. The system facilitates debit banking, transactions in non-secure external environments, e-commerce, and a 'cashless society'. The invention is a layer on top of the bank's existing payment systems.

Description

TITLE A SECURITY SYSTEM FOR TRANSACTIONS.

FIELD

This invention relates to a system for enhancing the security of a financial transaction; such as a transaction between a person and a bank or other financial institution, or between one financial institution and another, and more particularly this invention relates to a system for authenticating or authorising such a transaction.

BACKGROUND

Current systems for making possible, let alone protecting, a transaction between a person and a financial institution, or between one financial institution and another, are deficient in many ways. Credit card fraud and more generally credit card transaction failure may range from 5 to 30% of transactions (dependent on the field of activity). In the United Kingdom, credit card fraud is said to cost a million pounds a day. Use of a credit card exposes the account holder to exploitation by a thief as is well known. Risks associated with credit card theft over the World Wide Web are widespread and well-known, restricting adoption of e-commerce. The UK figure for fraud mentioned above is expected to double by 2005.

Where on-line banking in its general sense is involved, making one's account number known to the general population (or even a subset such as one's clients) amounts to a risk. Even for deposits, the owner no longer has control over what can be put in to the account.

Where bank-to-bank transfers of money are involved, more checks and in general more security is involved, but the associated costs of the relatively complex procedures represent an unnecessary drain on the economy.

It is particularly useful to make financial services available to developing countries and there is a need for provision of secure money-based transactions not involving credit cards, cheque books, or even actual money in the market place. There is therefore a need to overcome the above weaknesses in security and in the verification of transactions, preferably in a simple and reliable manner.

DEFINITIONS TANS - Transaction Authorisation Number System.

TAN - Transaction Authorisation Number Vendor - Refers to the intended recipient of the transaction regardless of whether any goods or services are given in return. This term is interchangeable with Payee, Seller or recipient. This person is the intended recipient of monies and / or information with regard to a transaction from the Purchaser.

String - an array of characters (letters and/or numbers). Purchaser - Refers to the person making the TAN request regardless of whether any goods or services are given in return. This term is interchangeable with Payer or Buyer. This also refers to anyone from whom instructions for a transaction are taken.

Payee - Refers to the intended recipient of the transaction regardless of whether any goods or services are given in return. This term is interchangeable with Vendor, Seller or recipient. This person is the intended recipient of monies and/or information with regard to a transaction from the Purchaser.

Payer - Refers to the person making the TAN request regardless of whether any goods or services are given in return. This term is interchangeable with Purchaser or Buyer. This also refers to anyone from whom instructions for a transaction are taken. Person - Individual, Company, Corporation, Governmental Institution, Partnership, Charitable Trust, Incorporated Society, or any group of individuals who is a party to the transaction. The terms he, his, him, her(s) she, you or your(s) are interchangeable with any of these descriptions.

Bank - Refers to any institution with whom the Purchaser's monies, stocks, bonds or shares are held, or where they have a deposit or credit facility. Transaction - Refers to any passing of monies or any form of instruction for a Transaction between parties regardless of whether any goods or services are given in return.

Credit Card - Refers to either a credit facility or other facility whereby the card account or credit account can be used in making a payment. E.g. credit cards, American Express Cards, Eftpos, (acronym for Electronic funds transfer at point of sale), Smart Cards etc. Validated - Once the Vendor has presented the TAN to the bank, the payment of funds are then validated if the TAN has not been cancelled prior by the Purchaser.

Non-validated - If the Purchaser cancels the transaction prior to presentation to the bank by the Vendor of the TAN, then monies are not passed to the Vendor and the transaction is void. TAN request - Refers to the point where the Purchaser requests their Bank, for a TAN and supplies specific information regarding the transaction at that time to their Bank.

Sum of money - Cash, electronic funds, tokens, financial instruments or other documents with an agreed value

TAN cancellation - Refers to the point prior to validation of the TAN where the Purchaser for whatever reason decides he does not want to proceed with the Transaction and notifies his Bank from whom the TAN has been authorised that the TAN is cancelled.

OBJECT

It is an object of this invention to provide an improved system for the authentication and authorisation of a financial transaction or other instruction, or at least to provide the public with a useful choice. STATEMENT OF INVENTION

In a first broad aspect this invention provides a device for assisting in execution of any one of a variety of financial transactions between a payer and a payee, such as a transfer of funds from a payer account held in a payer bank (the term "bank" is as previously defined), to a payee account held in a payee bank, wherein the device (hereinafter called the TAN) comprises a unique string of human-readable characters created in a medium by secure software at the payer bank and made available to the payer for forwarding to the payee and in turn to the payee bank in order to identify and authorise the transfer; the TAN including (a) at least part of a descriptor capable of determining the source of the funds, (b) at least part of a descriptor capable of determining the destination of the funds, and (c) a description of the funds to be transferred; the TAN having an effective lifetime which ceases on completion of the transaction

In a related aspect, the level of security operating within the bank is not compromised by existence of the TANS function.

In a second broad aspect the invention provides a method for assisting in execution of a financial transaction between a payer and a payee such as a transfer of funds from a payer account held in a payer bank (the term "bank" is as herein defined), to a payee account held in a payee bank, wherein the method includes the creation of a TAN by secure bank software upon initiation of the transfer; the TAN being made available to the payer for forwarding to the payee as proof of availability of funds; the TAN including at least part of a descriptor capable of deteαnining the payer account, and at least part of a descriptor capable of determining the payee account; the TAN further includes a description of the funds to be transferred, so that the TAN is capable of use as an identifier for, and as authorisation for the transaction, and having an effective lifetime which ceases on completion of the transaction.

In a related aspect, the level of security operating within the bank is not compromised by performance of the TANS function.

95 In a related aspect the TAN further includes a randomly generated or non-deterministically generated component which might be based on a fast real-time clock.

Preferably the environmental information includes date and time.

In another related aspect the TAN is converted into an encrypted form, so that it is relatively infeasible for a person lacking an appropriate recovery algorithm to recover information 100 pertaining to the translation.

In a further related aspect the TAN comprises said information encrypted into a second form, and capable of being decrypted back into the first form.

In one alternative, the TAN is converted into a human-compatible shortened form, so that it is easier for any persons involved in the financial transaction to reliably communicate the TAN 105 between themselves by oral, written, or like means including allowances or human error.

Preferably the TAN is provided with at least one character capable of representing an outcome of a self-check procedure, so that subsequent repetition of the self-check procedure is capable of indicating any corruption of the TAN.

In a third broad aspect, the invention provides a form of debit banking, wherein the method for 110 enhancing the security of a financial transaction as previously described in this section requires an availability of sufficient funds within the payer account as a prerequisite for construction of the TAN, so that existence of the TAN serves to indicate to a payee that sufficient funds have been set aside and that the transaction is able to be completed.

In a fourth broad aspect, the invention provides a method for allowing an intending purchaser 115 (payer) entitled to use a payer account within a payer bank to purchase a purchaser's goods or services on a debit basis in a public environment at risk of interception of data by an unauthorised person, wherein the method includes that the payer: presents a request for a TAN to the payer bank, identifying the payer account, specifying the cost of the goods or services, and specifying the location of a payee account within a payee 120 bank, whereupon the payer bank attempts to set aside funds, verifies if possible that funds have been set aside, and generates a corresponding TAN including information describing (1) identifying at least in part the payer account, (2) the cost of the goods or services, and (3) at least in part the identity of the payee account, receives the TAN from the payer bank, 125 forwards the TAN to a vendor (the payee) of the goods or services, so that the payee can present the TAN to the payee bank thereby causing the funds identified by means of the TAN to be transferred to the payee account after which action the TAN may expire and after which the vendor may release the goods or services to the intending purchaser; and further wherein the information carried within the TAN has no elements allowing an 130 interceptor to do other than replicate the intended transaction if the TAN was decoded and acted on by the unauthorised person before the TAN has expired.

In a fifth broad aspect, the invention provides a method of implementing an e-commerce transaction, for allowing an intending purchaser (payer) entitled to use a payer account within a payer bank to purchase a purchaser's goods or services on a debit basis over the world-wide 135 web, characterised in that the method includes use of a personal computer connected to the world-wide web and hence capable of facilitating communications between one or more of (1) the buyer (payer), (2) a TAN-capable payer bank, (3) the vendor (payee) and (4) the vendor bank, so that the personal computer connected to the world-wide web is capable of implementing a rapid TAN-based debit payment from the payer to the payee.

140 In a sixth broad aspect the invention provides a digital computer running a set of instructions capable of causing the method previously described in this section to be put into effect.

More particularly the digital computer, when running the above-mentioned software, is capable at least of:

1. Synthesising a TAN using available data and set of rules,

145 2. Synthesising a short-form TAN,

3. Checking that the short-form TAN does not conflict with (a) extant TANs and (b) inappropriate words in a local language,

4. Verifying that funds specified are available within the nominated account,

5. and if available, adding the TAN to a set of extant TANs, and 150 6. communicating the TAN to the duly authorised requester.

Optionally the set of rules includes a randomisation step.

Preferably the digital computer is one also at least in part entrusted with the running of the accounting software of a bank or other financial institution, or alternatively is in communications with other computers that are so entrusted, so that security measures used 155 within the bank in general are inherently applied to the generation and utilisation of TANS. PREFERRED EMBODIMENT

The description of the invention to be provided herein is/are given purely by way of example and are not to be taken in any way as limiting the scope or extent of the invention.

DRAWINGS

160 Fig 1: is a block diagram showing a person-to-person transaction involving a TAN generated by a purchaser's bank computer in software according to the invention.

Fig 2: also a block diagram, shows a simple TAN payment flow pattern, involving a TAN generated by a purchaser's bank computer in software according to the invention.

Fig 3: shows a foreign-exchange TAN payment flow, involving a TAN generated by a

165 purchaser's bank computer in software according to the invention.

Outline of the Transaction Authorisation Number System TANS.

For each transaction, the TANS involves the automated generation of a unique authorisation code which provides instructions to a bank or other intermediary to facilitate the transaction.

TANS is a system implemented as computer code that sits inside the bank's existing security 170 structures and firewalls. It resides as a layer on top of the bank's existing payments systems, from where it gives the purchaser a means of authorising an individual, specific transaction by issuing a unique transaction number that will facilitate payment. Note that the purchaser's account details are not passed to the other party of a transaction and are thereby kept as secure as the bank's security system allows.

175 The unique transaction number is generated within an algorithm by taking specific data elements of the transaction and converting them into a string of numbers. This resulting number may have, but does not necessarily have a component derived from additional, random or otherwise undetermined numbers such as instant time. A mathematical algorithm is then passed over these identifying numbers reflecting the transaction to produce a shortened and

180 more convenient, manageable transaction number consisting of alpha and/or numeric characters. Preferably a checksum is included, so that any change made to a character after TAN generation can be identified. For example a TAN to be passed between people might be written as "EH8 9JR PX7 221" which is not difficult to relay accurately, verbally or in writing. It may be useful for the TAN generator to screen out confusingly similar sounds such as M - N,

185 B - V or confusing looking characters such as L, 1, and 1 perhaps by repeating with a different random component. A TAN used within computers, such during an e-commerce transaction, is free of length and similarity constraints. The TAN is specific to that one transaction. If the number is found and used by another party, it will be of no value to them other than to pay for the purchaser's intended transaction. 190 The TAN has a brief life. It expires as soon as the transaction is completed. In some circumstances, it may remain available for only a few days at most, after which the reserved funds are returned to the payer's account.

EXAMPLES OF TANS

This includes examples of TANs each created as an authorisation for a specific type of 195 transaction. Any transaction involves a set of descriptors capable of identifying it as unique: derived from the persons, the amount, and the instant of time at which the transaction is said to occur. For example:

1. The Payer a) The Payer's Date of Birth or Company Incorporation or Registration 200 b) The number of the Payer's Bank e.g. 050 c) The number of the Branch or Authorisation Centre e.g. 252

2. The Payee a) Account name b) The number of the Payees Bank e.g. 030

205 c) The number of the Payees Bank Branch e.g. 626

3. Instant of time: a) The Date of the Transaction Authorisation e.g. 120401 (December 4 2001) b) The Time of the Transaction Authorisation e.g. 080045 (8 am and 45 seconds GMT)

4. Amount:

210 a) The amount of the Transaction e.g. $100 b) The currency of the Transaction e.g. $USD

5. Randomised element: a) Optionally, one or more randomly produced numbers can be included. A number made by concatenating all numerals involved is large (at about 60 characters) and

215 hence perhaps inconvenient for human copying and memory. The number can then be converted into a compressed representation by passing it through a mathematical algorithm in order to provide a smaller alphanumeric string (the TAN of this invention) suitable to be passed to the Vendor. This number is always linkable back to the parties and elements of the Transaction that uniquely identify it. That is, the algorithm can be run in reverse to at least

220 confirm that a specific shortened form TAN could have been made from the full set of descriptors. This algorithm may be as simple as converting the string of base-ten (decimal) numbers into base-36 numbers using 0-9 and A-Z to represent the new set of digits. In that case, though, the TAN could be unpacked easily by a hacker in order to ascertain the participants' account 225 numbers. Further processing, such as a rearrangement of the numbers to be packed in a prescribed way, is likely to be required. Alternatively, known methods of data compression such as Huffman codes may be used.

I prefer that this algorithm forms a TAN which is self-confirming by including a checksum to indicate inadvertent or deliberate mis-communication. I also prefer that the algorithm also

230 includes checking means (such as a list of all previous TANS made that day, or all currently valid TANs) to confirm that duplicate compressed representations have not inadvertently been made. The reader will be aware that as the TAN gets shorter and shorter, the risk of inadvertent duplication or other confusion rises. Note that the risk that a criminal will crack the TAN by generating and communicating a large number of guesses is not large, because if the

235 TAN has not been generated by the bank it will not be recognised and if it has already been issued it will facilitate a specific bank transfer between bona fide parties unrelated to the fraudster. I expect that the bank generating the TAN may directly communicate to the bank which is intended to receive the payment the TAN itself, if not more information. TANs may be subject to a number of rules of use to be configured according to each market to be

240 recycled over a specified period typically from one to three months.

The payer's age could be included within the portion of information that is specific to the transaction to assist in on-line and other age limited transactions. The age information could be passed into the TAN as communicated between the people involved in the transaction without compression. This could alert a potential vendor that the potential purchaser is not 245 eligible for the goods requested. For example, it could caution a vendor who is a liquor wholesaler not to supply under-aged persons with alcohol.

Example of Option 1 - Highest Security Level

Examp/e of Opt/on 2- Cash Opt/on

NB Variations on how this can be structured may vary with each bank, dependent on the structure and options of their existing facilities, and the specific level of security required. For example, for a cash transaction, payee information may not be required.

Foreign Exchange Examp/e

Examp/e of Share or Bond Transact/on

EXAMPLES OF PROCEDURES INVOLVING TANS

255 Example 1. This scenario is a sale by a vendor to a purchaser, as shown in Fig 1.

Fig 1 is a block diagram 100 with time increasing downward, with marketplace actions at the left and intra- and inter-bank processes at centre and right. An intending purchaser 101 wishes to purchase some item, shown here as goods or services 102. The purchaser (who presumably has already arranged with his bank 103 to make use of the present invention) contacts his bank

260 preferably by a form of digital telecommunications, alternatively voice, mail, or any other convenient means and using the security procedures previously arranged to verify that the person calling is in fact able to authorise payments from the nominated account 105. He makes a request for a certain amount of money 110 to be given a TAN (Transaction Authorisation Number) and set aside for collection. The bank computer now attempts to reserve the money

265 in the account (assuming that sufficient is available), synthesises a TAN including contributions from the input variables provided (as previously described), checks at least that no existing TANS that are alive have the same short-form code, and advises the purchaser of that short- form coded TAN 106. This procedure should be substantially instantaneous and so both the request and the response may for convenience be made over the same communications

270 channel 111 (preferably a form of digital telecommunications) if bidirectional. A "transaction declined" type of error message may be returned if for example insufficient funds are available.

Next the purchaser 101 hands the TAN to the vendor 107, on a piece of paper, verbally, using a shift register, memory, or other storage means in a shared piece of electronic hardware, or the like. The vendor requests his bank 108 to use the TAN to transfer funds into his (the vendor's)

275 account 109. The vendor's bank need not be particularly set up for TAN processing. All that is required is passing the code (plus destination account details) from bank 108 to bank 103, as a request for the immediate transfer of the funds from bank 103 to bank 108, normally in the usual virtual form. If the purchaser's bank software is able to locate the cited TAN, the funds are removed from the purchaser's account, the TAN is deactivated, and the funds are placed in

280 the vendor's account. This procedure should also be substantially instantaneous and so both the request from the vendor and the response from his bank that funds have indeed been transferred as per the TAN (and their amount) may for convenience be made over the same communications channel 112. At that moment, the vendor can consider himself to have been paid and the goods or services may be delivered as appropriate to the satisfied purchaser 101'.

285 Referring to Fig 2 and starting at top centre at a moment when a purchase has been agreed, this block diagram shows that the payer (purchaser) 101 communicates securely with his bank 103 to provide the payee 107 (vendor's) name and bank sort code as sufficient details, together with the value of the purchase. The payer bank 108 optionally communicates with the payee bank during establishment of a TAN and debiting of the payer's account, for better validation. 290 The TAN is returned (4d) to the payer, who passes it (5) to the payee who then passes the TAN top his bank, which returns it to the payer bank and at that time, payment (9) is made.

Possible problems and their solutions:

1. A hacker may break into the purchaser -> bank secure communication link, but this is the standard link that is present for any user-to-bank communication and should be as secure as

295 any prior-art links. This invention cannot alter the security of this link.

2. If the purchaser has insufficient funds (however that status is defined) in his account 105, this is made known immediately and no TAN is established.

3. If the TAN is incorrectly cited (ie not found during bank-to-bank communication link 113) this may be made known to the vendor and the purchaser immediately.

300 4. If (as is unlikely) the incorrectly cited TAN happens to coincide with a valid TAN waiting to be taken up, the payment is most likely to be wrong. The account numbers in the full-form TAN are unlikely to match. Software checks can be used, and the TAN may be of a longer length to minimise this risk.

5. If a third party intercepts the TAN (for example it may be on a discarded scrap of paper) 305 and tries to benefit by it, nothing will happen because the TAN only relates to the identified transaction between two parties involved and has a limited lifetime. The third party might be able to pay the funds.

6. Hackers trying to steal by using lots of TANs at the stage of the 113-type bank-to-bank link will at worst simply have the effect of causing recipients to be paid. Each TAN is a single-

310 use, virtual token and the underlying detailed instructions have already been set up by another, unassociated interaction.

7. If the purchaser tries to delude the vendor with too small a payment, for example, the vendor can learn the size of the payment at the time of the response from his bank.

8. If the purchaser's bank becomes insolvent, actual payments may never be made from it to 315 bank 108. This should be no more than an extremely rare event.

Example 2. This scenario is that of a person entering retail premises to buy some goods or services.

The intending purchaser accesses his account, held by his bank. One specific way may be over the Internet: another may be at a telecommunications-linked terminal analogous to an Eftpos 320 terminal, and a third way may be over one's digital cellphone, WAP phone, or using conventional branch or call centre facilities, or the like. Once the account has been accessed in a suitably secure manner by password and PIN, a first selection screen offers these choices:

1. to generate a TAN,

2. to cancel a TAN, or

325 3. to view a list of TANs that have been authorised: both validated and non-validated.

Assuming that the first option was selected, the next selection screen shows the following fields:

1. Name of recipient (the vendor)

2. Recipient's account bank and branch (not full account details) 330 3. Amount

4. Currency (e.g. USD, NZD etc)

5. purchase details (optional for the purchasers records)

After filling in these fields, the purchaser may print the page (if facilities to print exist) and submits it by pressing the 'submit' field.

335 The bank confirms the Purchasers request by repeating:

1. confirmation of recipient details

2. confirmation of amount

3. confirmation of currency

4. confirmation of purchase details.

340 Once the purchaser confirms the information as correct, a TAN is calculated within the bank using the algorithm described previously, and sent to the purchaser's terminal for his use. Preferably, money from the purchaser's account is instantly set aside (or flagged) for this specific transaction and is not available for other use unless cancelled by the purchaser prior to submission of the TAN by the vendor. (This aspect gives the vendor more assurance that

345 payment is on its way).

At this moment the purchaser will be prompted to copy the TAN. Perhaps it will be printed if printing means are available, or perhaps a pencil and paper are called for. Usually, though, the whole process is likely to be occurring on a terminal at the vendor's premises, or while the purchaser is on the vendor's web site and is able to establish a secure connection to his bank 350 whether by phone or on-line from which purchaser obtains the TAN immediately the purchaser's call has ended. Otherwise the purchaser gives the TAN to the vendor. The TAN however is media independent and could be used by a traditional bank customer who would go to a branch, obtain a number and pass it to the merchant either directly or by mail.

The vendor submits the TAN to his bank (requiring a second call to a new called party), which 355 immediately communicates on-line with the purchaser's bank to get verification of funds held under that same TAN at the purchaser's bank. At the same time that the flagged monies are released to the vendor's bank the TAN is disabled/exhausted at the purchaser's bank. The vendor can instantly supply the goods that were purchased. The purchaser's bank is in a position to immediately confirm details of the transaction that has just taken place to the 360 purchaser, optionally including the remaining funds in the account and optionally naming the person who claimed the money held under the TAN.

The precise details of the way the TAN will operate will depend upon the condition of use created by the bank with the customer, and the arrangements as to confirmation of an effective value in the purchaser's account. Users of the TAN may apply different rules as to when value 365 passes and when cancellation or retraction is possible.

It will be appreciated by a skilled reader that the TAN is usable only once, as a kind of disposable validation certificate of the transaction. Also, because of the use of fine divisions of real time and the optional use of random numbers, a second TAN is most unlikely to resemble the first TAN. A would-be thief would, if they manage to obtain the real TAN, merely facilitate 370 the transaction by delivering it to the bank unless the TAN issued was a bearer or cash TAN.

If the purchaser wants to cancel a TAN he may do so but clearly the vendor would want to know this before the goods are handed over.

There may be situations where the code making up the TAN becomes corrupted and in that case the purchaser would ask for the the first TAN to be reissued and any transcription or 375 transmission errors would be made good.

Example 3. This scenario is that of a retailer who wishes to increase business by selling goods online, where the existing problem is that potential customers are reluctant to give banking or credit information over the Internet, to a non-secure site. The solution using a TAN is as follows:

380 The customer accesses ABC Retailers' website using a browser as usual, and fills out a shopping basket. When given the total purchase amount for this transaction, the customer acquires access to his bank account also via the Web, perhaps using a second browser window. His bank site and the ABC Retailers site are open at the same time. After using his usual secure access password and pin, two options are given to him: 385 1. 'Do you wish to authorise a transaction?'

2. 'Do you wish to cancel a transaction authorisation?'

After indicating his choice of the first option, the next screen comes up with the following fields to be filled in:

1. Name of recipient

390 2. Amount

3. Bank no. and sort(branch) code

4. Currency (e.g. USD, NZD etc)

5. Details

Then the customer submits the page by pressing the 'submit' field. 395 The customer's bank confirms the customer's request by repeating:

1. confirmation of recipient details

2. confirmation of amount

3. confirmation of currency

A print facility is available on this page to confirm the customer's initial submission.

400 Once the customer confirms the information is correct, a TAN is given. Monies are instantly set aside (or flagged) on the customer's bank account for this specific transaction and are not available for other use unless cancelled by the customer. The customer will be prompted to copy the TAN (a macro can be set up for this, to cut and paste the number), and give the TAN to ABC Retailer. ABC Retailer submits this TAN immediately to his bank, which can get

405 verification of funds held instantly online by the customer's bank and the monies are released immediately after which the TAN is disabled/exhausted.

ABC Retailer can instantly supply the goods purchased, and the customer's bank can confirm the transaction details to the customer immediately.

In this instance it is still possible that ABC Retailer will fail to supply the goods, but the main 410 point of the invention is that the customer's bank details have not been published on the Web. The second point is that payment by the customer is assured if the TAN is handed over to the customer's bank by ABC Retailer.

Example 4. This example scenario is that of a roofing contractor working for a house owner.

The solution using a TAN is as follows: 415 The roofing contractor, having installed a new roof for the house owner, gives a physical (paper) invoice to the house owner via hardcopy in the usual way. As in the previous examples, the house owner obtains a TAN from his bank to cover payment. The roofing contractor phones his bank, using secure phone banking services of the type currently available, while a new option to receipt monies is now available. The TAN can be given by the

420 contractor over the telephone to his bank by using the touch-tone phone pad. His bank immediately seeks verification of the TAN from the house owner's bank, gets verification of receipt of payment and the house owner gets confirmation of the payment with a reference number.

Example 5. This example scenario is that of a Personnel Consultancy who invoices a client for 425 successful placement of a candidate. The solution using a TAN is as follows:

The personnel consultancy emails the client with a copy of the invoice. The client accesses his credit card account and authorises the transaction which procedure involves generation of a TAN. The TAN is given to the personnel consultancy who emails this string of characters to his bank account. The TAN included sufficient data to identify the customer down to branch 430 level, in case of multiple accounts the TANs would by prior agreement go to a specific account. The payment is verified instantly as monies had already been set aside at the time of generation of the TAN, and clearing is not required. The payment is deposited directly into the personnel consultancy account and confirmation is sent to both parties by the client's credit card company.

435 Example 6. This example scenario is that of a Car Sales Company dealing with an individual customer. The solution using a TAN is as follows:

The customer selects a car of choice for purchase. The customer then uses the offices of the car sales company and accesses the Web using their PC to obtain a TAN. In the same manner as previously described, the TAN is confirmed (if sufficient money exists) and money is 440 transferred immediately to the car sales company.

Example 7. This example scenario is when solicitors for a vendor and a purchaser settle the purchase of a residential dwelling. The solution using a TAN is as follows:

A TAN is given by the purchaser to their solicitor to pay the vendor. The solicitor passes this number to the vendor's solicitor via fax. Authorisation is verified and monies are deposited 445 accordingly. The vendor's soHcitor passes a separate TAN to the company holding their mortgage to discharge it in order to give clear title at settlement.

Example 8. Use of Electronic Trading Matching Systems

A number of trading systems exist both on a global and domestic basis for the trading in financial markets of foreign exchange, stocks, and bonds. One of the issues in matching is that 450 although matching is anonymous the parties need to have authorised trading limits available for the transaction. The matching system is obliged to store and maintain those limits on a real time basis. This adds complexity to the system, increases processing time, and raises security issues for both network provider and trading parties.

If a TANS structure is employed a party inserting a foreign exchange bid for a specific size and 455 price of a currency would have the option to insert a TAN that would indicate that funds were available within the relevant nostro/vostro account, and authorising funds to be transferred in accordance with market convention for the trade. The TAN would include standard bank instructions plus potentially dealer information to improve trading limit management within the dealing room.

460 Example 9. Flow chart depiction of a foreign exchange TAN payment.

Referring to Fig 3, and starting at top centre at a moment where a purchase 1 has been agreed, including the currency pair, buy/sell volume and price data, with the payee dealer information, this block diagram shows how the payer (purchaser) 101 communicates securely (2) with his bank 103 to provide the payee 107 (vendor's) name and bank sort code and other details 465 together with the value of the purchase. The payer bank 108 optionally communicates with the payee bank during establishment of a TAN and debiting of the payer's account, or his notes position, for better validation both at generation of the TAN and the transmission of the TAN from payee (or dealer) 107 to payee bank 108 for payment, as per the value date instruction at 9. Some notes concerning the flow chart include:

470 1. That the transaction is with a known party with whom the other party holds position limits, as is customary. Therefore the payee has the payer name and the details of the Vostro account.

2. That while there is a clear understanding of which dealer is involved, whether you are buying or selling the nominated currency, and its rate and volume, a value date can be

475 generated but is prudently confirmed especially for forwards transactions.

3. A foreign exchange transaction may generate two TANs, each representing an instruction by the party to its Nostro account holder, to facilitate the transaction.

4. The TANs should be constructed for facilitating automatic reconciliation.

5. Because the TANs can completely reconstitute the elements of the transaction, it is up to 480 the foreign exchange dealers to determine whether common values, currencies, dealer ID size, and time are recorded (given that clocks sometimes drift fast or slow. 6. In the diagram, Fig 3, the respective banks 103, 108 could be the back offices of the respective banks or in fact the respective Nostro and Vostro account holders.

Options:

485 1. TANS need not be delivered to the bank by the payer bank. Further, they could be a special confirmation TAN that would validate against payee delivered TANs.

2. The dealer ID may be the name of the dealer or limited to a dealer call code.

3. TANs could be left at an untruncated length or tmncated into a short string of characters preferably retaining uniqueness for a limited period such as a month or thereabouts. (NB,

490 mention of a TAN as being limited to 8 characters in length is by way of example only).

4. The value date could be defaulted by mutually agreed calculators. NB: mention of a TAN of 8 characters length is by way of example only.

VARIATIONS

Although we have described a variety of types of transaction in the previous section, it is 495 possible to use the invention for all forms of Transactions, across all industries, and for all personal requirements.

Some examples are: Business to Business, Business to Customer, Customer to Business, Business to Employee and vice versa, Individual to Individual, Government Organisation to Government Organisation, Business or Individual and vice-versa. 500 The invention can be used instead of cheques or credit cards and can be used for international monetary transactions, including stocks, bonds, and futures trading.

Transactions can be made in any variety of ways. For example, over the Wolrd Wide Web, by email, by mail, face to face, over the phone, or by fax.

All that is required is access to a PC, a phone or a direct visit to your bank to give properly 505 secure access to your bank account, and then to request a TAN for whatever transaction you may be making. Access may also be made into your bank account via telephone banking to secure a TAN which can be provided to you any number of ways e.g. verbally, by mail, by fax, by email, via the net, etc.

While immediacy is a virtue of this system, it should also be possible to hold a TAN for a long 510 period as a form of hold over some money almost as effectively as if it was held in trust.

COMMERCIAL BENEFITS or ADVANTAGES

1. Provides a new, relatively secure form of transaction for which protection by uncrackable encryption is not important. Because the TAN is specific to that one transaction, if the TAN is intercepted by another party, it will be of no value to them other than to pay for 515 the purchaser's intended transaction. Account data is vulnerable not only on the public network, but also on the databases of any vendor, especially when operating online retail activities.

2. Provides debit banking services, compatible with e-commerce.

3. Provides a means for non-cash and monetary transactions to take place that protects the 520 purchaser from fraudulent use of their account details to the extent that the current bank's security system is safe, and with the particular advantage that there is no other disclosure of the purchaser's account details to third parties.

4. Limits the exposure to potential fraudulent dealings or to a maximum of one transaction in as far as the bank's security system is safe.

525 5. Allows vendors to offer bank level security to a transaction, by Twiggy backing' on the security level offered by the Bank. Vendors would no longer need to produce a 'secure website' of their own as the security to the transaction is offered by the bank(s).

6. Eliminates the need for third party validation of transactions.

7. Sets aside funds for a specific transaction.

530 8. Allows for immediate clearance of the funds once the TAN has been given. It eliminates the clearance period required when cheques are cleared.

9. Eventually replaces cheques and facilitates online bill payment processing.

10. Allows for a much safer and easier way of transferring funds.

11. Allows for both payer and payee, or just the payer to a transaction (dependent on whether 535 payee information is included in details making up the transaction number) to track details of the transaction. If a dispute arises this can act as a verification of details to the transaction.

12. Severely limits the opportunity for a third party to gain access to the purchaser's account details.

540 13. Limits the opportunity of the vendor using the purchaser's account details for any subsequent unauthorised dealings.

14. Increases the means by which a vendor can securely offer to sell his goods or services without concern by the purchaser of releasing sensitive account information. This is achieved by allowing vendors and purchasers to take full advantage of the banks' secure

545 systems for payment of their accounts.

15. Adds security to the vendor at the time of releasing goods, as he can quickly verify that the monies have been set aside for the specific transaction he is engaged in with the purchaser, and are validated for payment to his account. 16. Avoids rejection by an online retailer of a legitimate valid purchaser due to fear of fraud 550 and fear of reversal fees.

17. Increases the amount of sales because of the added security that purchasers will have when making a transaction.

18. To decrease the theft of credit cards by eventually moving away from the necessity of carrying them on a person, whilst retaining the credit card account provisions.

555 19. To provide a secure means of electronic billing and payment processing.

20. To potentially reduce the banks' need for insurance to cover fraud, as the exposure of their banks' customers is reduced, and to reduce uninsured exposure to the cost of fraud.

21. To reduce the purchaser's and/or the vendor's exposure to fraud.

22. To allow the full potential of "e-commerce" to be realised, by substantially reducing risk of 560 on-line fraud and by reverting to a debit charge system.

23. To enhance usefulness of technology such as WAP enabled cellular telephones.

24. Developing nations can implement a money-based market system using banks and preferably telephone lines (optionally but not necessarily using digital telecommunications devices) without the complexity of credit cards, cheque books or even physical money in

565 the market, and so help to advance their economies.

Finally, it will be understood that the scope of this invention as described and/or illustrated within this specification is not limited to the preferred embodiments described herein for illustrative purposes. Those skilled in the art will appreciate that various modifications, additions, and substitutions are possible without departing from the scope and spirit of the

570 invention as set forth.

Claims

1. A device for assisting in execution of any one of a variety of financial transactions (examples as herein defined) between a payer and a payee, such as a transfer of funds from a payer account held in a payer bank (the term "bank" is as herein defined), to a payee account held

575 in a payee bank, characterised in that the device (hereinafter called the TAN) comprises a unique string of human-readable characters created in a medium by secure software at the payer bank and made available to the payer for forwarding to the payee and in turn to the payee bank in order to identify and authorise the transfer; the TAN including (a) at least part of a descriptor capable of determining the source of the funds, (b) at least part of a

580 descriptor capable of determining the destination of the funds, and (c) a description of the funds to be transferred; the TAN having an effective lifetime which ceases on completion of the transaction, and wherein the level of security provided by the bank is not compromised.

2. A method for assisting in execution of a financial transaction between a payer and a payee such as a transfer of funds from a payer account held in a payer bank (the term "bank" is as

585 herein defined), to a payee account held in a payee bank, characterised in that the method includes the creation of a TAN within secure bank software upon initiation of the transfer; the TAN being made available to the payer for forwarding to the payee as proof of availability of funds; the TAN including at least part of a descriptor capable of determining the payer account, and at least part of a descriptor capable of determining the payee account;

590 the TAN further includes a description of the funds to be transferred, so that the TAN is capable of use as an identifier for, and as authorisation for the transaction, and having an effective lifetime which ceases on completion of the transaction.

3. A method for enhancing the security of a financial transaction as claimed in claim 2, characterised in that the TAN further includes a random component.

595 4. A method for enhancing the security of a financial transaction as claimed in claim 2 or in claim 3, characterised in that the TAN is converted into an encrypted form, so that it is relatively infeasible for another person to recover information pertaining to the translation.

5. A method for enhancing the security of a financial transaction as claimed in any one of claims 2, 3, or 4, characterised in that the TAN is converted into a shortened form, so that

600 it is easier for any persons involved in the financial transaction to reliably communicate the

TAN between themselves by oral or like means.

6. A method for enhancing the security of a financial transaction as claimed in claim 4 or in claim 5, characterised in that the TAN is provided with at least one character capable of representing an outcome of a self-check procedure, so that subsequent repetition of the self- 605 check procedure is capable of indicating any corruption of the TAN.

7. A method for enhancing the security of a financial transaction as claimed in claim 2, characterised in that an availability of sufficient funds within the payer account is a prerequisite for construction of the TAN, so that existence of the TAN serves to indicate to a payee that sufficient funds have been set aside and that the transaction is able to be

610 completed.

8. A method allowing an intending purchaser (payer) entitled to use a payer account within a payer bank to purchase a purchaser's goods or services on a debit basis in a public environment at risk of interception of data by an unauthorised person, characterised in that the method includes that the payer:

615 a) presents a request for a TAN to the payer bank, identifying the payer account, specifying the cost of the goods or services, and specifying the location of a payee account within a payee bank, whereupon the payer bank attempts to set aside funds, verifies if possible that funds have been set aside, and generates a corresponding TAN including information describing (1) identifying at least in part the payer account, (2) the cost of the

620 goods or services, and (3) at least in part the identity of the payee account, b) receives the TAN from the payer bank, c) forwards the TAN to a vendor (the payee) of the goods or services, so that the payee can present the TAN to the payee bank thereby causing the funds identified by means of the TAN to be transferred to the payee account after which action the TAN may expire and

625 after which the vendor may release the goods or services to the intending purchaser; d) and further wherein the information carried within the TAN has no elements allowing an interceptor to do other than replicate the intended transaction if the TAN was decoded and acted on by the unauthorised person before the TAN has expired.

9. A method of implementing an e-commerce transaction, for allowing an intending purchaser 630 (payer) entitled to use a payer account within a payer bank to purchase a purchaser's goods or services on a debit basis over the world-wide web, characterised in that the method includes use of a personal computer connected to the world-wide web and hence capable of facilitating communications between one or more of (1) the buyer Opayer), (2) a TAN- capable payer bank, (3) the vendor (payee) and (4) the vendor bank, so that the personal 635 computer connected to the world-wide web is capable of implementing a rapid TAN-based debit payment from the payer to the payee.