WO2006004441A2

WO2006004441A2 - Electronic banking

Info

Publication number: WO2006004441A2
Application number: PCT/NZ2005/000156
Authority: WO
Inventors: Allan Shane Laycock
Original assignee: Eftwire Limited
Priority date: 2004-07-05
Filing date: 2005-07-05
Publication date: 2006-01-12
Also published as: WO2006004441A3

Abstract

Electronic transactions are carried out using customer information securely stored by an augmentation system inside or outside the bank transaction system, and released to the financial transaction authority on receipt of a password from a customer identified by the particular form of contact. Thus a phone customer is identified by the number of the calling phone and the password or token releasing the information is applicable only to calls from that number. The password is coded and encrypted where possible, and the customer information released if the password is correct is also encrypted in its passage to the transaction authority. The password may be an offset of the calculable PIN of a customer account. Transactions may be limited on the basis of the security of the form of contact. A customer who has registered with an Augmentation System may contact the Augmentation System, and use this to inject a transaction into the required bank IVR at 110, meanwhile allowing the Augmentation System to retrieve information important to transactions, for instance the bank and bank account number. The use of an Augmentation System enables payments from user to a merchant to be approved in real time (and notified to the merchant) whether or not they are settled overnight.

Description

ELECTRONIC BANKING

TECHNICAL FIELD OF THE INVENTION

The present invention relates to a system, method and/or apparatus used to process electronic transactions. Preferably, the present invention may be used to process the financial transactions of a user by mediating in the transactions between the customer and a financial institution.

Within this specification a reference to a "financial institution" is a reference to an organisation capable of electronically carrying out financial transactions on behalf of a customer in a secure environment. Typically such financial transaction authorities are banks or organisations contracting to banks.

BACKGROUND ART

The ability to execute financial transactions quickly and easily is of advantage to businesses. For example, in retail situations a consumer or customer is more likely to purchase goods or services on the spur of the moment if the financial transaction involved can be completed conveniently. Physical cash, credit cards or electronic point of sale (EFTPOS) access cards all allow the user or consumer to quickly and easily execute a financial transaction to pay for goods or services.

In general, the most common forms of payment used in financial transactions require a customer or user to be physically present at the point of sale. A purchaser normally has to present some form of physical token, such as cash, or a credit, debit, bank or EFTPOS card which validates the purchaser's authority to access funds available through a financial institution.

This can be inconvenient for some people as they may wish to order and pay for goods or services from a location remote from the point of sale. Furthermore, this "point of sale" approach also requires that the purchaser carry some form of token at all times at which they may want to complete such transactions, where this token must be secured against theft or unauthorised access.

One alternative approach to the point of sale situation discussed above is through the use of credit cards and telecommunications or information technology networks. Credit card payment networks allow a customer to transmit the characteristic numbers and information printed onto their credit card to facilitate and authorise a credit card transaction remote from the point of sale. The credit card information is then collected by the seller or vendor and batch processed at a later time.

Although this scenario does allow users to complete a financial transaction remote from the point of sale, there are still some problems with this approach. There is limited security associated with the use of credit cards in such remote transaction scenarios. The user of the credit card does not necessarily have to present any form of authentication information or token to complete the transaction and trigger the delivery of goods or services. This allows for stolen credit cards to be used to uplift goods and services if the thief has access to a telephone or internet terminal. Alternatively the thief need only take the details of the credit card number and expiry date.

Furthermore, the large number of digits and particulars of the credit card which needs to be communicated to a retailer can put some customers off completing such transactions. A customer needs to read out all the information printed on their credit card slowly and clearly and ensure that this information is correctly relayed to the retailer or seller involved. Attempts to pay multiple bills by Telephone or Internet banking are slow and cumbersome.

In addition, this form of remote payment facility is not necessarily available to all potential customers of a retailer. It is sometimes common for some of a retailer's customers not to be issued with or have access to a credit card required for such remote transactions.

It is known to address the above problems by providing systems which require the user to register with an authority of some sort, which authority will then confirm some additional information supplied by the customer before allowing a transaction to proceed.

However, again there are some limitations with the approach described in this document.

Another alternative approach is for a customer to provide their bank account details to the merchant and the merchant records these details. When the merchant requires payment for goods, the merchant sends a payment instruction to the financial institution. The merchant receives the result of the financial transaction the next day. Although this scenario does allow users to complete a financial transaction remote from the point of sale, there are still some problems with this approach. There is limited security associated with the use of account information in such remote transaction scenarios. The user of the account does not necessarily have to present any form of authentication information or token to complete the transaction and trigger the delivery of goods or services. This allows for stolen account information to be used to uplift goods and services if the thief has access to a telephone or internet terminal.

In addition, this form of remote payment facility offers significant problems to the merchant. The merchant does not know the result of the transaction until the next financial day. This can lead to payment transaction being declined and the merchant having to pursue the customer for payment.

Another alternative approach is for the customer to initiate the payment transaction direct with their financial institution. However, except for an EFTPOS payment, only the customer knows the result of the transaction at the time the transaction takes place, the merchant does not know until the next day. It can be very difficult for the customer to tell the merchant that payment was accepted and for the merchant to accept such information as correct. If the transaction is executed on a Friday evening, the merchant may not know the result of the transaction until the next Tuesday.

Through limitations in the security of such a system the finances or credit of a user may potentially be accessed by an unauthorised third party. A user account may be set up in conjunction with such system through information which could readily be obtained through public channels or personal documentation which is not normally considered to be of sensitive or secure nature.

For example, in some instances a bank account number provides enough information to register an account for use with such a service. Such accounts may be set up with insecure information and then subsequently used anonymously to access the finances or available credit of the unsuspecting owner of the information used in the registration process. Typically these accounts are set up using a paper form, giving personal details over a telephone or entering personal details into an internet registration form. However, there is great reluctance by users to enter this information onto any form, and all of these types of registration processes are time consuming. In addition, all of these types of registration processes can expose confidential, personal data to other sources and therefore they cannot be fully secure or trusted. These registration processes require a user to sign confirming their acceptance of the terms and conditions, and there is no guarantee that the signature upon the document is not forged.

Furthermore, established financial institutions such as banks or other major lending providers do not provide a secure channel for transactions into their own transaction processing systems or networks. As the registration or application procedures employed in the system discussed above do not necessarily comply with the standard, secure access protocols of normal banking institutions, there is potential for these institutions to exhibit a high degree of resistance to taking up or offering transactions through such a facility.

These types of systems also store identification information that validates the user. If this information store were compromised the compromiser would have immediate access to all the information necessary to perform fraudulent transactions.

A system, method and/or apparatus which addressed any or all of the above problems would be of advantage. A system which allows the user to remotely register for its use without having to enter personal details onto a paper form, reveal personal details over a telephone or enter personal details into an internet registration form would be of advantage. A system which allows the user to easily and simply participate in a range of financial transactions using a number of different access methods from a wide variety of locations would also be of advantage.

A system which allowed access to a financial institution where the security of the access rights is on a par with existing banking or financial institutions security standards, and which preferably allowed wireless or mobile electrical devices to access such financial networks or services would also be of advantage. A system which has its own payment authorisation process but also uses the financial institutions accepted, secure payment authorisation process would be of advantage. A system which stores information in such a way that if the information store was compromised, a person could not use the gained information for fraudulent purposes would also be of advantage. A system which allowed a business or merchant to know that the funds required for a transaction were guaranteed at the time of the transaction would also be of advantage.

In our PCT7NZ02/00007 (also published as NZ patent specification 523709 we describe a mobile payment system.

All references, including any patents or patent applications cited in this specification are hereby incorporated by reference. No admission is made that any reference constitutes prior art. The discussion of the references states what their authors assert, and the applicants reserve the right to challenge the accuracy and pertinence of the cited documents. It will be clearly understood that, although a number of prior art publications are referred to herein; this reference does not constitute an admission that any of these documents form part of the common general knowledge hi the art, hi New Zealand or hi any other country.

It is acknowledged that the term 'comprise' may, under varying jurisdictions, be attributed with either an exclusive or an inclusive meaning. For the purpose of this specification, and unless otherwise noted, the term 'comprise' shall have an inclusive meaning - i.e. that it will be taken to mean an inclusion of not only the listed components it directly references, but also other non-specified components or elements. This rationale will also be used when the term 'comprised' or 'comprising' is used hi relation to one or more steps in a method or process.

ABBREVIATIONS

The following abbreviations are used in this specification:

API - Application Program Interface

CDR -Call Data Record

CRM - Customer Relationship Manager

CRN - the Customer Reference Number

DDE - Direct Debit Entry HTML - Hypertext Mark-up Language

IVR - Interactive Voice Response

PAC - Payment authentication Code

SCM - security control module

SMS -Short Message Service

SMSC - Short Message Service Centre

OBJECT OF THE INVENTION

It is an object of the present invention to address the foregoing problems or at least to provide the public with a useful choice.

Further aspects and advantages of the present invention will become apparent from the ensuing description which is given by way of example only.

STATEMENT OF THE INVENTION

In one aspect the invention provides apparatus for carrying out a transaction with a financial institution comprising an augmentation system interposed between the customer's point of access and the financial institution, the augmentation system having a secure store capable of securely storing information about the customer including a stored version of a customer's token and sufficient information to emulate a customer request to a financial institution, means for receiving a request to carry out a transaction from a customer, means for receiving from a customer a token required to authorise the request, means for comparing the token with the stored version of the token and means for presenting a financial institution with stored details of the customer's account and details of the transaction required

Preferably the means for presenting a financial institution with stored details of the customers account and details of the transaction required includes a telephone device adapted to contact the IVR platform of the said financial institution and to inject the necessary telephone codes to emulate details of the customer's account and customer identification taken from the secure store.

Preferably the augmentation system securely stores details of the customer's account, securely stores identification of at least one of the customer's major creditors and a customer code allocated to the creditor, and wherein the augmentation system is capable of presenting to the financial institution sufficient customer and creditor details to carry out the required transaction through the financial institutions payment platform, such as a telephone banking IVR interface.

In another aspect the invention provides a method of carrying out a transaction with a financial institution comprising receiving a request to carry out a transaction from a customer, receiving from a customer a token required to authorise the request, comparing the token with a stored version of the token and if verified presenting a financial institution with stored details of the customers account and details of the transaction required through the financial institutions payment platform such as a telephone banking IVR interface..

In another aspect the invention provides a method of carrying out a transaction with a financial institution comprising receiving a request to carry out a transaction from a customer, presenting the financial institution with stored details of the customer's account and then bridging the customer directly into the financial institutions payment platform, such as a telephone banking IVR interface to complete authorisation of the customer by them entering their token. Details of the transaction required can then be presented to the financial institution by the augmentation system.

Preferably the token is a password

Alternatively the stored version of the token is not identical to the token but can be compared by means of calculation.

Preferably the request to carry out a transaction from the customer is a request for telephone banking wherein the customer has previously been registered with an augmentation system via a financial institutions approved channel such as a telephone banking network.

Preferably the telephone communication from the customer does not identify the amount to be transferred but wherein the amount to be transferred has been pre selected by the customer during the initial or subsequent registration via the telephone banking system.

In another exemplification of the invention the customer may enter the amount in the message to the augmentation system.

Preferably the augmentation system securely stores details of the customers account, securely stores identification of at least one of the customer's major creditors and a customer code allocated to the creditor, and wherein the augmentation system presents to the financial institution, on receipt of a customer token confirming the customer identity, and a customer code confirming the creditor identity, sufficient customer and creditor details to carry out the required transaction.

In another exemplification of the invention the customer may select the creditor by entering a code during the transaction to the augmentation system.

Preferably the user contacts the augmentation system via a mobile remote user terminal which has been pre-registered with the augmentation system using an approved channel of the financial institution, such as the telephone banking network to confirm that the user is an authorised customer of the financial institution.

In another exemplification the invention relates to a method of providing a secure customer registration system capable of carrying out financial transactions with a financial institution comprising securely recording customer details necessary for carrying out a financial transaction, providing the customer with a token, and providing a system for acting on receipt of the token to initiate a transaction with a financial institution.

Preferably the recording of the customer details and the allocation of the token is carried out using a known secure system.

Preferably the recording of the customer details takes place during a normal transaction with a financial institution.

Preferably the token is used in conjunction with an indication of the transaction amount, type and debtor or creditor.

Preferably the type and debtor or creditor is indicated by a further token. In a further exemplification the invention relates to a method of carrying out a transaction with a financial institution comprising receiving a request to carry out a transaction from a customer, receiving from a customer a token required to authorise the request, comparing the token with a stored version of the token and if verified presenting a financial institution with stored details of the customers account and details of the transaction required.

Preferably the token is a password.

Preferably the stored version of the token is not identical to the token but can be compared by means of calculation.

Preferably the communication to the financial institution is secure.

Preferably the request to carry out a transaction identifies the debtor or creditor either by an account code or by a code stored with the details of the customers account.

Preferably the communication from the customer is not required to be secure where the debtor or creditor is identified by a code.

The communication from the customer does not necessarily identify the amount to be transferred.

In yet a further exemplification the invention relates to a method of carrying out a transaction with a financial institution for a customer comprising securely storing details of the customers account, securely storing identification of at least one of the customer's major creditors and a customer code allocated to the creditor, and presenting to the financial institution on receipt of a customer token confirming the customer identity, and a customer code confirming the creditor identity, sufficient customer and creditor details to carry out the required transaction.

Preferably where a single customer transaction is of a transfer type and involves two different financial institutions it may be broken into a crediting transaction and a debiting transaction which are separately carried out.

Reference throughout this specification will be made to the financial transaction processed being telephone banking transactions between a retailer or vendor of goods or services and a customer of such a vendor. However, those skilled in the art should appreciate that other relationships and other types of transactions or protocols may also be employed in conjunction with the present invention and reference to the above only throughout this specification should in no way be seen as limiting. For example, in some embodiments the present invention may be adapted to set up bill payment or bill payment authorisation facility which triggers the payment of a regular charge or bill between a customer and a particular vendor of goods or services (such as for example, a utilities company). This type of payment is commonly known as a Direct Debit Entry (DDE).

Preferably the system provided may also service the needs of a plurality of users or the customers of one or more vendors of goods or services. Such a system may facilitate financial transactions preferably between a large number of customers and vendors, with the system, apparatus, or components employed to implement the present invention providing secure access to financial information associated with each of the users or customers involved. Preferably the present invention may also provide customers or users, remote access to such transactions where the user need not necessarily be present at the point of sale involved for a particular transaction.

In a further preferred embodiment the information store provided may be implemented through use of at least one computer system loaded with software adapted to provide a database or other similar type of data storage and retrieval facility. Database technology is well known in the art and may be used effectively to store the financial information associated with a plurality of users in a secure yet easily and quickly accessible facility. Furthermore, the information store provided may also include security software and/or hardware used to validate information or communications from a user wishing to access secured financial information. Such components can be employed to determine whether the user involved has the authority to execute a particular financial transaction using the secured financial information involved.

Preferably the present invention may allow a user or customer to employ a remote user terminal to communicate with the information store and subsequently trigger the release of secured financial information to execute a required transaction. Preferably the remote user terminal employed may communicate with the information store using existing communications infrastructure procedures, protocols or facilities which are secured against authorised interception. In a further preferred embodiment a mobile remote user terminal may be employed to access or use the present invention. A mobile terminal, such as for example, a cellular telephone or cellular enabled personal digital assistant (PDA), or laptop computer may be employed in conjunction with the present invention. These types of terminals can allow convenient and secure access to the financial transaction facility provided. Reference throughout this specification will also be made to the remote user terminal employed being a cellular telephone or other type of wireless or radio frequency based transceiver. However, those skilled in the art should appreciate that other types of terminals may also be used in conjunction with the present invention and reference to the above only throughout this specification should in no way be seen as limiting. For example, in one alternative embodiment land line telephones may also be employed as a user terminal if required.

Preferably a terminal used to access or communicate with the information store may include or have associated at least one address attribute. An address attribute may uniquely identify the specific user terminal involved and preferably may provide a communication routing address normally used to facilitate communications with the terminal involved. For example, in a preferred embodiment a cellular telephone may be employed as a remote user terminal, where the telephone number of the cellular phone makes up the address attribute required or used.

Those skilled in the art should appreciate that the address attribute associated with terminal employed will be determined by the type of terminal in addition to communications channels or protocols used by the terminal. For example, in other alternative embodiments internet protocol addresses for computer systems, network card MAC addresses or remote access point addresses for wireless computer networks may also provide address attributes to be employed in conjunction with the present invention.

Preferably a prior user registration procedure may be implemented in conjunction with the present invention before a user is allowed to access the facilities provided in accordance with the present invention.

Preferably as part of this registration process, a user may provide or supply details of the address attribute of a remote terminal they wish to employ to access the facilities provided in accordance with the present invention. For example, in a further preferred embodiment where the remote user terminal employed is a cellular telephone, the telephone number of the cellular phone involved may be supplied as part of this registration process. Preferably the prospective user of the present invention may provide an address attribute which uniquely identifies their terminal, and where the terminal involved preferably is only accessible to the user wishing to execute financial transactions in accordance with the present invention.

Reference throughout this specification will also be made to the user terminal employed being a cellular telephone. The address attribute provided may in such instances be the telephone number of such as cellular 'terminal', it may be the EMS phone identification or it may be the MIN provider identification, any of which can uniquely identify the terminal involved. Furthermore, reference throughout this specification will also be made to a user communicating with the financial institution's processing system using a single terminal only which has a single address attribute. However, those skilled in the art should appreciate that more than one terminal may be employed by a single user, as may more than one address attribute for a single terminal if required. Those skilled in the art should appreciate that other configurations and arrangements of the present invention are envisioned and reference to the above only throughout this specification should in no way be seen as limiting.

In a preferred embodiment as part of this user registration process, a user may also be supplied with an access code or the user may choose a specific code.- Such an access code can, in combination with a received valid user terminal address attribute, authorise a user's access to the financial information which is secured in the information store and hence provide the ability to complete financial transactions using said information.

In a further preferred embodiment the access code provided may take the form of a password or a sequence of alphanumeric characters. Most users of the present invention would be familiar with password used to access financial institutions through telephone banking based transactions. A distinct alphanumeric access code may preferably take the form of a number of digits that may be lesser than, equal to or greater than the format of standard banking password where this access code should only be known to the user registering to employ the facilities provided in accordance with the present invention.

Preferably the information store provided may be adapted to release the stored and secured financial information of a particular user upon receipt of a valid user terminal address and valid access code for the owner of the information involved. Preferably the owner of such information may be the only person or party with access to both the remote user terminal (which has the associated received address attribute) and who is the only person or party in possession of the access code employed. Upon receipt of a valid terminal address attribute and access code associated with a particular user, the user's secured financial information may then be released and used to implement or execute a financial transaction.

In a further preferred embodiment the terminal address attribute employed to validate or authorise access to such financial information may preferably be extracted from communications made directly between the information store and remote user terminal. The information store may query or receive such address attribute information from the remote terminal, and may authorise or subsequently refuse access to the financial information stores depending on whether the correct address attribute for an identified user's terminal is received. For example, in one embodiment caller line identification technology can be employed to obtain or extract the telephone number address attribute of a calling user's telephone.

In a further preferred embodiment the level of security that the remote user terminal supports and the level of security on the communication lines employed determine the range of financial services that the user of the remote terminal may expect to gain access to.

For example, in one preferred embodiment the progress of a transaction may be allowed or refused in conjunction with the present invention depending on the particular type of terminal employed by a user. Different types of terminals and communications equipment have differing levels of security facilities some of which can allow unauthorised persons to receive and interpret communications, giving them the potential to fraudulently execute a transaction with a user's financial details.

In a preferred embodiment each financial transaction which may be executed or processed in conjunction with the present invention may be assigned a particular type. The type of transaction will preferably be determined by the significance or liability involved to a user if the transaction could be completed by an authorised person. For example, one-off bill payments to an assigned payee associated with the user may be provided with a different transaction type to direct electronic transfers of funds to any ^discriminate third party bank account. Different transaction types may be allowed for more secure types of terminal (such as for example WAP enabled cellular telephones), while the same transaction can be disabled for the more basic forms of terminals (such as voice only cellular telephones or land lines).

In a further preferred embodiment each financial transaction that occurs within the system may be matched against limits or regulated in some way so as to monitor and prevent fraudulent use of the system.

In yet another embodiment of the present invention monitoring software or processes may also track historical transaction activity for a particular user. Such monitoring algorithms (also known as "scoring engines") can monitor transactions processed in association with a particular user to detect irregular usage patterns or patterns that indicate the potential for fraud or unauthorised use of financial details has occurred. Such monitoring algorithms may disable further transactions being made in association with a particular user if such potential fraudulent activities are detected.

According to a further aspect of the present invention there is provided a method of registering a user , said user having been issued with a token by a financial institute, said token being used to facilitate financial transactions

the method of registering a user being characterised by the steps of:

i) receiving token information associated with the token issued to the user requesting registration, and

ii) receiving an institution authorisation code from said user, said authorisation code being used to make a valid identification of said user, and

iii) receiving at least one address attribute associated with a remote user terminal to be used by the user to access the financial transaction processing system, and

iv) generating and/or receiving an access code to the user to allow access to the financial transaction processing system.

According to a further aspect of the present invention there is provided a method of registering a user, said user having been issued with a token by a financial institute, said token being used to facilitate financial transactions the method of registering a user being characterised by the steps of: i) receiving token information associated with the token issued to the user requesting registration, said token normally being used by said financial institute to identify financial details of said user, and

ii) receiving an institution authorisation code from said user, said authorisation code being used with the token information to make a valid identification of said user by the financial institution and

iii) receiving at least one address attribute associated with a remote user terminal to be used by the user to access the financial transaction processing system via the augmentation system, and

iv) assigning or receiving an access code to the user to allow access to the financial transaction processing system via the augmentation system.

According to a further aspect of the present invention there is provided a method of registering a user substantially as described above wherein said registration method occurs without the user having to communicate or disclose any financial details identified by the financial institution using the token information associated with the token issued to the user.

According to yet another aspect of the present invention there is provided a method of registering a user substantially as described above wherein the assigned access code is generated for and communicated to the user.

According to yet another aspect of the present invention there is provided a method of registering a user substantially as described above wherein the assigned access code is generated by the user and communicated to the system employed to implement the present invention.

According to a further aspect of the present invention there is provided a method of registering a user substantially as described above, wherein said institution authorisation code is adapted to authorise transactions to be completed in conjunction with the token issued to the user.

According to yet another aspect of the present invention there is provided a method of registering a user substantially as described above wherein the institution authorisation code is adapted to facilitate point of sale financial transactions in conjunction with the token issued to the user.

Preferably the present invention may employ tokens issued by existing or established financial institutions, where these tokens are used by the customers of such institutions to facilitate financial transactions. Preferably the transactions involved are where the token provides the financial information required to execute a transaction between the customer or user involved and vendor of goods or services.

Those skilled in the art should appreciate that a financial institution as referred to throughout this specification may be defined as any entity, group, or association which provides financial services. Such institutions may provide standard banking facilities and/or additional credit or loan facilities to customers or members - and hence will be issuing tokens to users or customers which allow access to or which can facilitate the execution of financial transaction. Furthermore, a financial institution as discussed in accordance with the present invention may also employ, implement or run the augmentation system provided in accordance with the present invention if required.

In a further preferred embodiment, an institution authorisation code may also be received as

, part of the registration process executed. This authorisation code may be used to make a valid identification of the specific user who wishes to register to gain access to the facilities or functions provided by the financial transaction processing system involved. In a further preferred embodiment, the institution authorisation code received may be the same code which authorises transactions to be implemented in relation to the token or password

Preferably as part of the user registration process executed, at least one address attribute of a remote user terminal may also be received. An address attribute can uniquely identify a specific terminal device to be employed by the user registering to access the financial transaction processing system, as discussed above. After details of a user's token have been received and the identity of a user has been confirmed through receipt of a correct password, the address attribute or attributes of a user's terminal may then be recorded. As discussed above, a cellular telephone number for a user's cellular phone can be employed as an address attribute where this phone number in combination with an authentic or valid access code will allow a user to execute transactions in accordance with the present invention. The information stored within the system is preferably encrypted based on information supplied by the customer and not held in the system. Typically this could be done by providing the customer details with encryption based on the customer's phone number and password. This information is not held in the system as such and hence is not accessible to anyone viewing the system data, although given the customers input on accessing it; the system can decrypt the data and pass it to the required financial institution.

Preferably once the above information has been received and the identity of the user wishing to register has been validated or confirmed, an access code may be generated and released to the newly registered user. This access code can be used in conjunction with the address attribute of the user's terminal to gain access to and facilitate the execution of financial transactions using the present invention. In a further preferred embodiment, the access code provided may be generated or chosen by the user and subsequently supplied to the components, equipment or personnel employed to complete the registration process. Alternatively and in other embodiments a random or secure access code may be generated and supplied to the user.

Preferably once the access code has been generated or received, the augmentation system will then calculate an access code offset. The access code offset is the numeric difference between the user's access code and the password entered by the user to validate the token. By using this access offset code, it ensures that the system does not store the user's access code or the user's password within its information store and therefore this protects the data within the information store from fraudulent use.

In this embodiment the provision of an access code offset avoids the need for the present invention to store a user's password or financial institution authorisation code, thereby eliminating the chance of unauthorised persons obtaining access to a user's password from the information store. Furthermore, financial transactions may be processed or forwarded to a financial institution for processing without validation of the access code supplied by a user. The access code supplied will in turn be used to generate a password which is in turn incorporated into a transaction request forwarded to a financial institution. If the supplied access code is incorrect then the associated password generated will be incorrect and the transaction involved will be refused by the financial institution.

Reference throughout this specification will also be made to the present invention employing or storing an access code offset in relation to a particular user to in turn avoid storing the user's password or financial institution authorisation code. However, those skilled in the art should appreciate that other configurations of the present invention are envisioned and reference to the above only throughout this specification should in no way be seen as limiting.

Preferably once this registration process procedure has been completed, the token received and the access code offset assigned to the user may be stored within the information store provided as part of the augmentation system. The token received may therefore form at least a portion of the financial information to be recorded and secured within the information store. Furthermore, the information store may also retain or associate as part of the financial information of a user both the supplied address attributed or attributes for a user terminal in addition to the access code offset generated from the access code assigned to the user. Upon receipt of a transmission or connection with the user's terminal, the information store may release financial information incorporating or including the token information received when a valid access code is supplied, and when the information store can determine that the communicating terminal has the same address attribute as that stored or recorded.

Furthermore, in an additional preferred embodiment the user supplied access code and the stored access code offset can be used to generate or calculate the password or institution authorisation code to be used to authorise the execution of a payment transaction against a payment channel approved by the financial institution such as a Telephone Banking transaction. The password or institution authorisation code required can be calculated from the difference between the stored access code offset and the access code supplied by a user. A calculated password can then be used as part of the payload of a financial transaction to be processed by a financial institution.

Furthermore, in an additional preferred embodiment the registration details, such as the user supplied access code and password may be provided to the user's financial institution and such institution will supply a virtual set of details, such as the access code and password to be used by the augmentation system. Such access codes and passwords would be valid only to a particular payment channel; if the stored information was compromised an unauthorised person could not use the gained information for fraudulent purposes through the use of normal payment channels typically used by the user. Such tokens may not even be known to the user hence the user cannot reveal them to any third party or have them stolen by anyone.

The present invention may provide many potential advantages over the prior art.

Furthermore, the registration system discussed above improves a security of access to these transactions, as existing financial institution and banking security procedures are implemented to ensure only authorised users have access to the present invention.

In addition the registration system discussed above allows a user to be registered without the user having to disclose or provide confidential financial details or information. The token issued to a user may be employed to access such sensitive information without said information needing to be written down, transmitted or otherwise disclosed as part of the registration process.

The present invention may also provide an augmentation system which can be configured in such a way that if the stored information was compromised, an unauthorised person could not use the gained information for fraudulent purposes through the availability of only user access codes offsets as opposed to institution authorisation codes.

Preferably the present invention will enable the augmentation system to inform the merchant the result of a financial transaction at the time the transaction takes place, whereas such a result would normally only be known by the customer and not known by the merchant until the next financial day. This enables the merchant to offer goods and accept payment via channels used by the financial institution that would normally only give the result of the transaction the next financial day.

BRIEF DESCRIPTION OF DRAWINGS

Further aspects of the present invention will become apparent from the following description which is given by way of example only and with reference to the accompanying drawings in which:

Figure 1 illustrates a block schematic diagram of components employed to provide an augmentation system in accordance with Example 1. Figure 2 is a schematic diagram of the system flow of the registration process.

Figure 3 is a schematic wiring diagram of the registration process.

Figure 4 is a schematic diagram showing the system flow of the SMS payment process.

Figure 5 is a schematic wiring diagram of the SMS payment process.

Figure 6 is a schematic diagram showing the settlement process.

Figure 7 is a schematic diagram showing the CRM process.

Figure 8 illustrates a modified block schematic diagram of the components employed to provide a financial transaction processing system, using any one of three channels for the purpose of registration.

Figure 9 illustrates a similar block schematic diagram to that of Figure 7 with one small modification.

Figure 10 is a schematic diagram showing the combination of registration with the

Augmentation System using IVR, followed by an SMS transaction request and the creation of an IVR payment transaction.

Figure 11 is a schematic diagram showing the combination of registration with the

Augmentation System using IVR₅ followed by a Virtual EFTPOS card and SMS transaction.

Figure 12 is a schematic diagram showing the combination of registration with the

Augmentation System using IVR, followed by creation of a Virtual Internet account and then an SMS initiated payment transaction.

Figure 13 is a schematic diagram showing the combination of registration with the

Augmentation System using IVR₅ followed by a voice call from the customer to initiate a payment request form he augmentation system to the

Bank IVR, where the augmentation system does not store the password and the customer is required to enter it each time. Figure 14 is a schematic diagram showing the combination of registration with the

Augmentation System using IVR, followed by a voice call from the customer's mobile to initiate a payment request from the augmentation system to the Bank IVR, where the augmentation system is able to create the IVR request to the Bank IVR and can use the stored password to validate the transaction.

BEST MODES FOR CARRYING OUT THE INVENTION

Example 1:

Figure 1 illustrates a block schematic diagram of components employed to provide a system in accordance with a preferred embodiment. These components include a terminal 109 which connects to the telephone banking network of the financial institution or to a central transaction authority 104 through an Interactive Voice Response (IVR) interface within the augmentation system 105.

Registration:

Under the inventive system the user registers with the augmentation system 105. A user may register providing the number of a telephone from which further transactions may be made, and may provide a password to be used on the telephone. This may be stored in the augmentation database 107 or an offset to it from the user's actual password may be stored.

While registration through a telephone banking network is described above, it is also possible to register via other means, for instance a secure internet connection from a computer at 108 in conjunction with a verified connection to the augmentation system server, e.g. verified by a known digital signature verification authority. .

Extension of registration:

A customer may dial in through the augmentation system using IVR, which will connect (by bridging) to the financial institution's telephone banking system at 104 and then identify themselves as a verified customer by providing the required identification and token. The customer may then provide more detail of what is required to allow the augmentation system to retrieve information important to later transactions, for instance the customer's bank, the customer's bank account and the customer's password, or offset as appropriate.

Tracing the traffic through the augmentation system in a customer transaction with the bank is relatively simple in most cases and allows the system to build up details of whom a customer transacts business with and what type of transaction they wish to carry out with that person. This allows a choice including this option to be added to the customers profile as one of the possible choices available to them.

Similarly a registered customer may connect to the augmentation system through a secure internet interface 108 and be bridged through to an internet banking interface of a bank at 111. Again, the augmentation system may extract relevant details from the session to add additional details or parameters to the customer's details.

Preset Transactions:

A customer may set up a number of different preset transactions, for instance a transaction which provides a predetermined pre-payment to the customers mobile phone by crediting the telephone service provider, or a transaction crediting a specific merchant which pays a specified amount to only that merchant, i.e. a funds transfer system. Such a preset transaction may even provide for a payment of a fixed amount, for instance $20.00 to the telephone service provider.

This is preferably done by providing a billing number for each merchant, being possibly a six digit number, and providing also an invoice number from the merchant, from details of that merchant held in the augmentation system. Thus every transaction with a particular merchant is tracked against an invoice number, and the system can output a paid invoice to whomever is required with the customer and merchant names based on the banks acceptance of a transfer.

Levels of Access:

Under the augmentation system it is comparatively easy to assign different levels of transaction to the different levels of access. Thus where a user accesses the augmentation system using a standard telephone 112, via a telecommunications provider 113, only funds transfer to selected predetermined merchants are allowed. Access via the customers own mobile phone in conjunction with the users password would normally allow the full range of transactions, provided the mobile supported an adequate security system. Where it did not the access might be downgraded to payment to known merchants.

Similarly access via the IVR entry of the augmented system would normally be limited to funds transfer.

A single user may have several associated telephone numbers and TPINs, and the facilities associated with each may vary depending upon the inherent security of the telephone type.

Tokens:

The tokens associated with a customers use of the system may range from a simple four digit T-PIN for use on the telephone for a payment or transfer to a password meeting enhanced security requirements. A customer may have many different tokens associated with different fixed transfers or may only a single token. The latter is preferable where an IVR or internet access is used since it is simpler to guide the user to the desired choice using such systems.

Isolation:

The augmentation system may be internally isolated within secure boundaries, the inputs being encrypted and the output decrypted or re-encrypted in a system to suit the destination system. Similarly the database 107 associated with the augmentation system may be internally encrypted at 114 so that physical theft of the database or backups is not fatal.

It should be noted that the financial institutions would be essentially unaware that the request for a transaction was being created in the augmentation system rather than directly by the customer. It is, of course, essential that the security of the exchange of data with the financial authorities meets the requirements set by them, and that any data which could be considered to belong solely to the customer and the financial institution is not transmitted to any other person.

Additionally the information held in the augmentation system and relating to customer details is encrypted based on a password from the customer which is not held as such in the system. Hence the data cannot be viewed from within the augmentation system, merely forwarded to carry out a financial transaction. Operation:

A. Using Telephone Banking as the entry point:

Once a customer has registered and decides to make a payment using the telephone banking route he can either text into the augmentation system or dial into the augmentation system and use its IVR system. As soon as the customer is recognised, the augmentation system then dials into the selected Bank's IVR platform and injects its stored values of the customer's data into the Bank's system and thus speeds up the transaction by allowing the augmentation system to mediate the transaction with the Bank. If the customer has dialled into augmentation system he may be asked to enter his password directly into the bank's IVR to increase security, thus obviating the need for the augmentation system to store the password or an offset. If the customer has text into the augmentation system he may be called back by the augmentation system to enable entry of the password directly into the bank's IVR.

B. Using Internet Banking as the entry point;

Similarly the customer can enter the system using Internet banking and use the

Augmentation system to emulate a log on with the Internet Banking gateway.

Example 2 - Prepaid Top Up System

This is a high level description of a Prepaid Top up system that uses a mobile phone to initiate the transaction and an electronic interface to the Financial Institution (hereinafter called "Bank") Telephone Banking system to authenticate the payment.

An augmentation system complements the transaction by reducing the amount of data required to be entered by a customer and performs an update to a carriers' platform in real time once the payment is authorised. This augmentation system is in this example referred to as an "ESwitch" or "Eftwire ESwitch".

Although Telephone Banking could be used today to enable a top up solution, a Bank would have to modify its Telephone Banking architecture to enable a "real time" payment solution.

We overcome this limitation within the Telephone Banking system by using our technology (hereafter called "EFTWIRE") as a payment "negotiator". By knowing that a transaction has taken place and that the funds have been authorised for payment, EFTWIRE is able to inform the mobile network prepaid platform, in real time, thus overcoming the existing limitations within the Telephone Banking system.

With any Telephone Banking payment, the customer must key in a lot of data to enable the payment to take place. With a mobile phone using SMS, the keying in of this data is not very practical.

To enable a SMS initiated Telephone Banking payment, the system stores data on behalf of the customer. When the customer initiates a payment request to the system, the system uses this data to assist the customer in making a Telephone Banking payment.

The system has two processes, a registration process and a payment process. The assumption is that the customer already has Telephone Banking facilities.

The purpose of this document is to provide a basic understanding of how the system works.

This document details the use of SMS as the delivery mechanism for the payment request. Other payment request delivery mechanisms such as Voice, Sim ToolKit, USSD, WAP or GPRS can also be used where circumstances require.

Additionally, the system can also be interfaced with other payment systems such as Internet Banking.

Registration Process:

The following section describes how a registration takes place, the interaction between the customer, the ESwitch (an IVR platform and electronic Switch supplied by EFTWIRE) and the Telephone Banking platform belonging to a Bank.

Registration Process - System Flow - (refer to Figure 2)

The steps in Figure 2 are as follows:

1. Customer calls the ESwitch located at a secure hosting site. The customer will use their phone keypad (DTMF tones) to respond to the IVR section of the ESwitch prompts. 2. The customer is requested to enter a Payment authentication Code (PAC). This is the code the customer will use when requesting a Prepaid Top Up. The ES witch then asks the customer to enter their Telephone Banking ID number and Telephone Banking password. These are not stored.

3. The ESwitch passes the Telephone Banking information entered by the customer directly to the BANK Telephone Banking platform.

4. If the BANK Telephone Banking platform authenticates the customer information, the ESwitch retrieves the list of customer available accounts. The ESwitch will use script commands to access the appropriate Telephone Banking menu.

5. The available accounts are replayed to the customer and the customer is requested to select an account to be used for Prepaid Top Up.

6. The customer selects an account.

7. The ESwitch stores the customer data into the database (see following note).

8. The ESwitch informs the customer that they are now registered. Terms and Conditions are played to the customer and the customer is asked to confirm acceptance before the registration is considered "active".

Note: The ESwitch does NOT store the Telephone Banking ID number and password. During step 3, the information provided by the customer is used to create to create "offset" information of the Telephone Banking ID number and password.

Telephone Banking ID 12345678 Telephone Banking Password 12345

Mobile Phone Number XOR 04001234567 Phone Access Code XOR 98765

ID Offset = 16344243567 Password Offset = 85420

For example: For a payment to take place the customer must provide key information (phone number, which is provided automatically by the mobile network when the transaction is initiated, and the PAC) so that the original information (Telephone Banking ID and Telephone Banking password) can be reconstructed.

As per any normal Telephone Banking transaction, the system cannot guarantee the security between the telephone and the ESwitch. However the ESwitch does use industry standard 3DES encryption systems to protect the Telephone Banking information and offset information. All information stored in the database is also encrypted using 3DES security. It is also assumed that the ESwitch will be housed within BANK authorised premises.

Note: If a customer changes their Telephone Banking ID number, telephone number or password, they will be required to reregister.

Registration Process - Wiring Diagram (Refer to Figure 3)

This shows the connections between the components, where customer 301 initially calls the ESwitch 302 and provides sufficient information that the switch is able to verify the customer information matches that at bank 304. The customer details and a means of confirming the customer identification may then be stored in a secure manner in database 303.

Payment Process

The following section details an SMS initiated transaction. It describes how a payment takes place, the interaction between customer, the ESwitch, the Telephone Banking platform belonging to BANK and the mobile carrier's Prepaid platform.

SMS Payment Process - System Flow (Refer Figure 4)

The steps in Figure 4 are as follows:

1. Customer initiates a payment request by sending an SMS message to the ESwitch. The SMS message contains the customers mobile payment code (PAC).

2. The ESwitch retrieves the offset information from the database using the mobile phone number (provided by the carrier automatically) as the key. 3. The ES witch uses the stored offset information, the customer's mobile phone number and the PAC to calculate the Telephone Banking ID and Telephone Banking password.

4. The ESwitch uses the existing BANK Telephone Banking platform electronic interface (API) to enter the Telephone Banking ID, password, biller information, account to be used and the amount of the transaction.

5. The Telephone Banking platform responds with a payment confirmed message and receipt number.

6. The ESwitch updates the Prepaid platform.

7. The ESwitch returns an SMS to the user inforrning them of their new prepaid balance and receipt information.

SMS Payment Process - Wiring Diagram (Figure 5)

In Figure 5 it shows the relationship between customer 501, the network 502, Eftwire's Eswitch equipment 505, and the link between Eftwire and the bank 506. This Figure shows the mobile carry network receiving a text message at 503 as an SMS from the customer, and that this text message is then forwarded to the ESwitch 505. Eftwire is able to use its ESwitch 505, and the stored information about the customer to perform the Telephone Banking payment with bank 506. The Bank 506 confirms the payment transaction hi its response to the ESwitch, which then performs the Prepaid Top Up to the prepaid platform 504 within the mobile network. At the same time Eftwire returns the result in a text message to the mobile network at 503 which returns that message to the customer confirming that the Top Up has taken place.

Settlement Process (Figure 6)

In first step of Figure 6 the ESwitch 601 generates the Telephone Banking payment in response to a request from customer 602, but needs to know the Biller Code and the Customer Reference Number (CRN) to enable a Telephone Banking payment to take place. The Biller Code identifies the network and the ESwitch assumes that each network will set up a separate biller code specifically for this type of prepaid top up. Normally the CRN identifies the customer and the invoice that the customer is paying. However, for prepaid top up, no CRN exists as there is no network invoice for a prepaid customer. In a normal situation, the CRN is created by the network and is generated from a known formula with a check digit. EFTWIRE proposes to create a new range of CRN's (based upon the phone number) for each network, each number will be used to identify the prepaid top up and the customer. The EFTWERE generated CRN can be limited to a specific number range. Numbers can repeat on a daily basis as long as no number is the same for one day.

Once a CRN is created a top up to the Prepaid platform 604 can be made, with a receipt recorded at the ES witch. The prepaid platform creates a payment in payment file 605.

Bank 603 will settle all payments overnight as a batch process. The settlement will occur internally within the Bank and be an "intra account" settlement process and no financial transactions will need to be sent to any external processing centre.

BANK Impact - To implement such a system most Banks will need to modify or develop a settlement process to transfer funds between BANK customer accounts and the carriers' accounts.

Reconciliation Files:

EFTWIRE Settlement File

BANK Settlement File

Prepaid Platform Payment File

A settlement external to the Bank will take place with reconciliation at 609 of the information from settlement files 606 and 608, and payment file 605. Network CRM Functions

Without specific changes to the CRM systems of each carrier, it is not possible for carrier support staff to tell if a customer has registered for prepaid top up within the EFTWIRE system.

The existing CRM systems also do not have a specific file detailing prepaid top up requests or the result of a prepaid top up transaction.

However, there are other options available that can provide a "go to market" CRM capability while the mobile networks consider the integration of specific solutions into their platforms or provisioning of HTML links into the EFTWIRE system.

Registration Information

Customers can perform a self check if they are registered. The customer does this by sending a text message to the EFTWIRE system. EFTWIRE will reply with the registration status of the customer.

If a customer attempts a top up transaction and the customer is not registered, EFTWIRE will reply with a message informing the customer that they must register before they can use the system. Transaction Information

Any transaction attempt will receive a reply message, the content of the message depends upon the transaction result i.e. transaction accepted, transaction declined etc. It is assumed that CRM staff are not able to view the contents of an SMS message; therefore they would not be able to identify the status of a message based upon its content. However, each return message could originate from a specific number, for example: an accepted registration could have an originating number of 410; a declined registration could have an originating number of 411. CRM staff can identify the status of a registration or a top up transaction by looking at the customers CDR record and matching the appropriate originating SMS number.

Example SMS originating numbers and codes

CRM Process Diagram (Refer Figure 7)

Figure 7 shows the overall process of the customer relationship manager where a customer calls the customer relationship manager to query a transaction. An initial SMS from customer 701 results in a request to the ES witch 703 which as previously explained tops up the customer account via the prepaid platform 704, meanwhile confirming with the customer that a top up has occurred.

The customer can then query the CRM 706 to check that the transaction has taken place, and CRM staff can query the transaction status in the CDR database 705.

Key elements of the System

1. The customer's actual Telephone Banking information is not stored anywhere on the ES witch or in the database. Any information held in the database that relates to the Telephone Banking information is offset information and is encrypted using standard security control module systems (SCM' s) as provided by vendors such as Eracom. The customer must provide key information to enable the Telephone Banking information to be reconstituted when required.

2. The customer is allowed to store and record their codes or PINs as long as the storage of this information does not contravene Bank's Terms and Conditions. In part, the system is acting as a secure, BANK authorised storage device (or electronic wallet) of a code known only by the customer. This code is stored in such a way as that it does not contravene the BANK Terms and Conditions, is not derivable as the code on its own and is fully encrypted and secured to BANK standards.

3. If the PIN or offset is not allowed to be stored then the customer can enter the PIN direct into the BANK system and therefore this will not contravene the BANK terms and conditions.

4. The ESwitch is not acting as a third party, service agent or authorised payment agent. 5. The ESwitch cannot initiate a payment transaction on its own.

6. The customer must initiate all transactions. The ESwitch acts only as a switch for the Telephone Banking transaction and each and every transaction is initiated and authorised by the customer.

7. The same security encryption technologies and devices as used by BANK are also used by EFTWIRE to protect BANK customer information stored within the system.

Example 3:

Figure 8 illustrates a block schematic diagram of components employed to provide a financial transaction processing system in accordance with a preferred embodiment. It is an expanded version of Figure 1 with 3 input channels and 3 possible output channels. These components include an EFT or EFTPOS terminal 101 with an encryption pad 102 normally providing an encrypted output to a financial transaction authority such as the EFTPOS network 103. The EFTPOS network connects to the individual banks within the network or to a central transaction authority 104.

Registration:

Under the inventive system the user registers with the augmentation system 105 in a secure manner, by any one of the input channels, hi practice we prefer the telephone route using an IVR platform, but registration could be by way of the EFTPOS network where the customer has both an EFTPOS account and either a telephone banking account or an internet banking account or through the Bank CRM systems.

In this example, the customer chooses registration via an EFTPOS terminal equipped with a program cooperating with the secure server of the augmentation process via a decryption utility 106. This program could assist in recording the information from the user's credit or debit card, and any authorisation required with it. A user may register providing the number of a telephone from which further transactions may be made, and may provide a PIN to be used on the telephone (T-PIN). This may be stored in the augmentation database 107 or an offset to it from the users actual PIN may be stored.

While registration through an EFTPOS terminal is described above it is also possible to register via other means, for instance a secure internet connection from a computer at 108 in conjunction with a verified connection to the augmentation system server, e.g. verified by a known digital signature verification authority. Such a registration may not provide the level of customer detail provided by that from an EFTPOS terminal, since no hidden card detail is provided. Thus the level of transaction provided as a result of such a registration may differ from that provided by other methods; however in most cases it is possible to elicit sufficient data to allow a relatively full range of transactions.

Similar restrictions may apply where a registration arises from a telephone banking interface 109 where the user interacts through an Intelligent Voice Recognition (IVR) interface within the augmentation system, using a combination of voice commands and telephone keypad presses to provide the required information.

Extension of registration:

Once a customer is registered with the augmentation system they may extend their registration to include other methods of carrying out transactions. Thus a customer who has initially registered via EFTPOS may dial in through a telephone banking interface, identify themselves as a verified customer by providing the required identification and token and may then either provide more detail of what is required or may be connected by bridging through the augmentation system to the required bank TVR at 110, meanwhile allowing the augmentation system to retrieve information important to later transactions, for instance the bank and bank account number.

Similarly a registered customer may connect to the augmentation system through a secure internet interface 108 and either provide additional details or be bridged through to an internet banking interface of a bank at 111. Again, the augmentation system may extract relevant details from the banking session to add additional details or parameters to the customer's details. Preset Transactions:

This is preferably done by providing a billing number for each merchant, being possibly a six digit number, and providing also an invoice number from the merchant, from details of that merchant held in the augmentation system. Thus every transaction with a particular merchant is tracked against an invoice number, and the system can output a paid invoice to whoever is required with the customer and merchant names based on the banks acceptance of a transfer.

Customer to customer transactions:

The system can also provide for the transfer of money between two customers who are known to the augmentation system but not to each other. Such a system may be required, for instance, as a result of a successful online auction tender or where a customer purchases something direct from another customer. When a request for such a transfer is presented the augmentation system will simply debit one account and credit the other after verifying that the tokens for at least one of the parties involved are correct.

Levels of Access:

Under the augmentation system it is comparatively easy to assign different levels of transaction to the different levels of access. Thus where a user accesses the augmentation system using a standard telephone 112, via a telecommunications provider 113, only funds transfer to selected predetermined merchants are allowed. Access via the customers own mobile phone in conjunction with the user's password would normally allow the full range of transactions, provided the mobile supported an adequate security system. Where it did not the access might be downgraded to payment to known merchants.

A single user may have several associated telephone numbers and passwords, and the facilities associated with each may vary depending upon the inherent security of the telephone type.

Tokens:

The tokens associated with a customers use of the system may range from a simple four digit password for use on the telephone for a payment or transfer to a password meeting enhanced security requirements. A customer may have many different tokens associated with different fixed transfers or may only a single token. The latter is preferable where an IVR or internet access is used since it is simpler to guide the user to the desired choice using such systems.

Isolation:

It should be noted that the financial transaction authorities would be essentially unaware that the request for a transaction was being created in the augmentation system rather than directly by the customer. It is, of course, essential that the security of the exchange of data with the financial authorities meets the requirements set by them, and that any data which could be considered to belong solely to the customer and the financial transaction authority is not transmitted to any other person.

A. Using Telephone Banking as the entry point:

Once a customer has registered and decides to make a payment using say the telephone banking route he dials into the Augmentation system and uses its IVR system. As soon as the customer is recognised, the Augmentation system then dials into the selected Bank's IVR platform and injects its stored values of the customer's data into the Bank's system and thus speeds up the transaction by allowing the Augmentation system to mediate the registration with the Bank. Meanwhile the customer may have chosen from a number of options such as bill payment, access to account information, etc. This request may be recorded by the Augmentation system whilst it is emulating the customer's identification with the Bank. As soon as this emulation is recognised by the Bank, the Augmentation system can then either (a) transmit the recorded request from he customer, or (b) return the voice channel to the customer who can then make a request direct from the bank.

B. Using EFTPOS as the entry point:

The customer can use an ATM or EFTPOS machine to contact the Augmentations system and authorise a transaction. By this means the Augmentation system can be used to arrange a bill payment either direct to a Merchant's account or via a service such as BPAY. Entry via an ATM or EFTPOS machine may also allow the customer to access his telephone banking or internet banking service as the Augmentation system can speed up the identification process by emulating the customer's identity.

Using Internet Banking as the entry point:

Similarly the customer can enter the system using Internet banking and use the Augmentation system to emulate a log on with the Internet Banking gateway.

Using a Mobile Telephone as the entry point:

In this situation the customer may use his mobile telephone to contact the augmentation system to authorise a bill payment or top up of his prepaid telephone account. This could be as easy as texting your telephone pin to a mobile number or short code associated with the augmentation system - resulting in the augmentation system emulating an ivr transaction and debiting the user's account and crediting the account of the mobile service provider.

Real time payment approval:

In each of these examples the augmentation system either stores or has access to the information needed to emulate the customer's real ivr, internet or eftpos transactions.

It also allows the customer to use any of the output channels for a real time payment approval. For example by using a bank's telephone banking platform the customer can quickly and easily pay a merchant and ensure that the merchant has a mediated response from eftwire that confirms that the merchant will be paid during the bank's normal settlement process (usually overnight). The merchant can then release the goods or services and be assured that they will receive the funds into their bank account.

Alternatively where a bank payment process is overnight, such as a Delayed Direct Entry transaction, and such transaction was adapted by the bank to provide a real time payment result, the augmentation system can then quickly and easily service the merchant and customer using such a payment channel.

EXAMPLE 4:

This example is similar to example 3 and can be explained with reference to the block schematic diagram of figure 9. It provides a similar financial transaction processing system to that of example 1 , but in this example the client details are held in a transaction authority database rather than a database under the control of the augmentation operator.

In figure 9 the numerals are in most cases the same as in figure 8 with the addition of layer 116 described below.

The system components include an EFT or EFTPOS terminal 101 with an encryption pad 102 normally providing an encrypted output to a financial transaction authority such as the EFTPOS network 103. The EFTPOS network connects to the individual banks within the network or to a central transaction authority 104.

Under this system the user registers with the augmentation system 105 in a secure manner, for instance via an EFTPOS terminal equipped with a program cooperating with the secure server of the augmentation process via a decryption utility 106. Alternatively the information stored by the augmentation process is stored as it is read from the card and normally transmitted to the bank, for instance with 3DES encryption or a variation thereof.

The augmentation server in this example does not have the decryption key and is employed only to forward the stored information (normally equivalent to that on track 2 of a financial card) when it is required, the decryption being carried out within the banks secure perimeter. Where the encryption is non-standard a decryption device 116 may be specifically located within the bank security perimeter to service requests from the augmentation system, typically by intercepting the input to EFTPOS network 103. Such decryption devices are known.

This EFTPOS terminal cooperation program could assist in recording the information from the user's credit or debit card, and any authorisation required with it. A user may register providing the number of a telephone from which further transactions may be made, and may provide a PIN to be used on the telephone. This may be stored in the augmentation database 107 or an offset to it from the users actual PIN may be stored.

While registration through an EFTPOS terminal is described above it is also possible to register via other means, for instance a secure internet connection from a computer at 108 in conjunction with a verified connection to the augmentation system server, e.g. verified by a known digital signature verification authority. Such a registration may not provide the level of customer detail provided by that from an EFTPOS terminal, since no hidden card detail is provided. Thus the level of transaction provided as a result of such a registration may differ from that provided by other methods; however in most cases it is possible to securely elicit sufficient data to allow a relatively full range of transactions.

Once a customer is registered with the augmentation system they may extend their registration to include other methods of carrying out transactions. Thus a customer who has initially registered via EFTPOS may dial in through a telephone banking interface, identify themselves as a verified customer by providing the required identification and token and may then either provide more detail of what is required or may be connected by bridging through the augmentation system to the required bank IVR at 110, meanwhile allowing the augmentation system to retrieve information important to later transactions, for instance the bank and bank account number.

Similarly a registered customer may connect to the augmentation system through a secure internet interface 108 and either provide additional details or be bridged through to an internet banking interface of a bank at 111. Again, the augmentation system may extract relevant details from the banking session to add additional details or parameters to the customer's details.

The system can also provide for the transfer of money between two customers who are known to the augmentation system but not to each other. Such a system may be required, for instance, as a result of a successful online auction tender. When a request for such a transfer is presented the augmentation system will simply debit one account and credit the other after verifying that the tokens for at least one of the parties involved are correct.

The augmentation system may be internally isolated within secure boundaries, the inputs being encrypted and the output decrypted or re-encrypted in a system to suit the destination system. Similarly the database 107 associated with the augmentation system may be internally encrypted at 114 (in addition to the encryption on some of the data) so that physical theft of the database or backups is not fatal.

Additionally the information held in the augmentation system and relating to customer details is encrypted based on a password from the customer which is not held as such in the system. Hence the data cannot be viewed from within the augmentation system, merely forwarded to carry out a financial transaction.

Figures 10 to 14 are series of schematics showing different combinations starting with an IVR registration process with the augmentation system, then a variety of different transactions initiated by a voice call or SMS which in turn triggers the augmentation system to make a payment request to Bank's IVR platform or to some other Bank payment process such as EFTPOS or Internet Banking, with the augmentation system notifying the Merchant when the payment transaction has been approved.

Figure 10 generally illustrates at 1000 the combination of registration with the Augmentation System using IVR, followed by an SMS transaction request and the creation of an IVR payment transaction.

Figure 11 illustrates generally at 1100 the combination of registration with the Augmentation System using IVR as in Figure 10, followed by the creation of a Virtual EFTPOS card and the assignment of that information to the customer's account, followed by an SMS request to the augmentations system to initiate a payment transaction.

Figure 12 is similar but in this case it shows the creation of a Virtual Internet account and then an SMS initiated request to the augmentation system for a payment transaction.

Figure 13 illustrates the password pass through approach where the customer retains the password and the augmentation system acts as a bridge to allow the customer to transmit the password to the Bank at the appropriate time in the transaction (where the augmentation system injects the rest of the transaction based on the information stored about that customer in its database).

Figure 14 is a schematic diagram showing the combination of registration with the Augmentation System using IVR, followed by a voice call from the customer's mobile to initiate a payment request from the augmentation system to the Bank IVR, where the augmentation system is able to create the IVR request to the Bank IVR and can use the stored password to validate the transaction.

Industrial Application:

The examples of this invention provide secure payment systems enabling a user to pay many merchant accounts easily and securely by use of an augmentation service provider interposed between the user and the user's bank.

Advantages:

The augmentation system emulates the customer's login with Bank systems to save the customer time and facilitate the customer's transactions. For example the user having registered and provided both the number of a telephone from which further transactions are to be made, and a token such as a password to be used on the telephone, can then dial in to the augmentation system, identify themselves as a verified customer by providing the required identification and token and may then either provide more detail of what is required or may be connected by bridging through the augmentation system to the required bank IVR. This enables payments from user to a merchant (or in some cases from user to user) to be approved in real time whether or not they are settled overnight.

VARIATIONS:

The customer's password may be stored securely in the database of the augmentation system. But it is also possible to operate the augmentation system with the customer retaining the password without in any way storing it in the augmentation system.

For example the customer could make a phone call into the IVR entry point of the augmentation system and the augmentation system would bridge through to the Bank allowing the customer to enter his ID and password directly into the bank payment channel, such as rVR whilst the augmentation system inserts the additional information stored at registration at the appropriate time in the call.

Alternatively to further improve security the augmentation system can be set up so that it does not store the password on registration of that customer and then to initiate a transaction the customer contacts the augmentation system in an appropriate way, for example the customer texts into the SMS number of the augmentation system and the augmentation system then calls him back, after bridging into the Bank system and injecting his ID. The customer then enters his password directly into the bank payment channel, such as IVR and the augmentation system injects the additional information stored at registration at the appropriate time in the call. This method would be adopted if the destination bank objected to an augmentation system storing the password or offset in its database.

Although most of the examples refer to telephone banking, it will be noted that Figures 7 and 8 show 3 different channels for registration and four channels to initiate transaction. It is also possible that a transaction may originate with the customer calling in to the Bank's CRM to query a previous transaction. Any one of these requests for a transition may result in a transaction created or mediated by the augmentation system in any one of the possible output channels available as inputs to a financial institution. Three such channels are shown in figures 8 and 9 but more channels may be available depending upon the technology and banking laws applicable in a particular country now or in the future.

Aspects of the present invention have been described by way of example only and it should be appreciated that various other modifications and additions may be made thereto without departing from the scope thereof.

Claims

CLAIMS:

1. Apparatus for carrying out a transaction with a financial institution comprising an augmentation system interposed between the customer's point of access and a financial institution, the augmentation system having a secure store capable of securely storing information about the customer including a stored version of a customer's token and sufficient information to emulate a customer request to a financial institution, means for receiving a request to carry out a transaction from a customer, means for receiving from a customer a token required to authorise the request, means for comparing the token with the stored version of the token and means for presenting a financial institution with stored details of the customer's account and details of the transaction required.

2. Apparatus as claimed in claim 1, wherein the means for presenting a financial institution with stored details of the customers account and details of the transaction required includes a telephone device adapted to contact the IVR platform of the financial institution and to inject the necessary telephone codes to present details of the customer's account and customer identification taken from the secure store.

3. Apparatus as claimed in claim 1, wherein the augmentation system securely stores details of the customers account, securely stores identification of at least one of the customer's major creditors and a customer code allocated to the creditor, and wherein the augmentation system is capable of presenting to the financial institution sufficient customer and creditor details to carry out the required transaction.

4. A method of carrying out a transaction with a financial institution comprising receiving a request to carry out a transaction from a customer, receiving from a customer a token required to authorise the request, comparing the token with a stored version of the token and if verified presenting a financial institution with stored details of the customers account and details of the transaction required.

5. A method as claimed in claim 4, wherein the token is a password.

6. A method as claimed in claim 4, wherein the stored version of the token is not identical to the token but can be compared by means of calculation.

7. A method as claimed in claim 4, wherein the stored version of the ID and token is not identical to the ID and token but is a virtual value and these values may not be known by the customer.

8. A method as claimed in claim 4, wherein the request to carry out a transaction from the customer is a request for a telephone banking transaction, but wherein the customer has previously been registered with an augmentation system.

9. A method as claimed in claim 8, wherein the telephone communication from the customer does not identify the amount to be transferred but wherein the amount to be transferred has been pre selected by the customer during the initial or subsequent registration.

10. A method as claimed in claim 8, wherein the augmentation system securely stores details of the customers account, securely stores identification of at least one of the customer's major creditors and a customer code allocated to the creditor, and wherein the augmentation system presents to the financial institution on receipt of a customer token confirming the customer identity, and a customer code confirming the creditor identity, sufficient stored customer and creditor details to carry out the required transaction.

11. A method as claimed in claim 8, wherein the user contacts the augmentation system via a mobile remote user terminal which has been pre-registered with the augmentation system.

12. A method as claimed in claim 8, wherein the augmentation system initiates a telephone banking transaction with the IVR platform of the designated financial institution and at the relevant point in the transaction the customer is directly linked to the financial institution's telephone banking network to allow the customer to enter the password directly into the financial institution's system without the aid of the augmentation system.

13. A method as claimed in claim 12, wherein the augmentation system calls the customer once the transaction authorisation has been received by text from the customer.