GB2438651A

GB2438651A - Secure financial transactions

Info

Publication number: GB2438651A
Application number: GB0610872A
Authority: GB
Inventors: Michael Arnold
Original assignee: Individual
Current assignee: Individual
Priority date: 2006-06-02
Filing date: 2006-06-02
Publication date: 2007-12-05
Also published as: GB0610872D0

Abstract

A method of facilitating a financial transaction, comprising the steps of: a customer requesting to purchase an item from an online vendor; the vendor seeking to validate the identity of the customer from a trusted authority by providing the trusted authority with information capable of uniquely identifying the customer; the trusted authority validating the identity of the purchaser by comparing the information supplied by the vendor with information pre-supplied by the customer; if the customer's identity is validated, the trusted authority transmitting a message to the customer seeking approval to complete the transaction; if the customer wishes to complete the transaction, transmitting to the trusted authority certain information known only to, and/or particular to, the customer; and the trusted authority approving payment to the vendor and transmitting confirmation messages to the vendor and the customer.

Description

1 2438651 Method and Apparatus for Secure Financial Transactions The

present invention is concerned with a method and apparatus for providing improved security in financial transactions which are performed over the internet, using payment cards, such as debit cards or credit cards.

Prior arL e-commerce systems used to make purchases over the Internet (e.g. by a customer purchasing a product or service via his home computer from a remote website) require the customer to enter his payment card details, together with a range of personal information.

The data which is normally required includes full name, address, credit (or debit) card number, card expiry date, and Card verification Number (CVN) . With this information, an unscrupulous third party may be able to make purchases without the card-holder's permission or advance knowledge.

The required data is normally transmitted via a secure link, such as https, to the remote server, so that the sensitive data is encrypted for transmission.

However, some websites do not encrypt the data, rendering it vulnerable to interception in transit. Furthermore, once the data reaches its destination, there is no guarantee that its security will be maintained, particularly if the customer is buying from a retailer he is unfamiliar with. The more retailers that the customer deals with in this way, the greater is the risk of his personal data being misused in some way.

Even if the data is securely transmitted and it is not misused on arrival, many consumers are still unwilling to enter their credit or debit card details for transmission over the Internet. This is particularly true for more elderly people who are perhaps suspicious of the Internet.

As such, a great many people are depriving themselves of the opportunities which purchasing over the Internet can offer. Likewise, many retailers are failing to attract potential customers, because of often ungrounded fears over data security.

Embodiments of the present invention aim to address both the real and the perceived problems of data security, whether referred to above or not.

According to the present invention there is provided a method as set forth in the appended claims. Preferred features of the invention will be apparent from the dependent claims, and the description which follows.

Furthermore, according to another aspect of the invention, there is provided apparatus arranged to perform the method of the first aspect.

For a better understanding of the invention, and to show how embodiments of the same may be carried into effect, reference will now be made, by way of example, to the accompanying diagrammatic drawings in which: Figure 1 shows a system configuration in accordance with an embodiment of the invention; and Figure 2 shows a typical message transfer in accordance with an embodiment of the invention.

Embodiments of the present invention allow a credit or debit card holder to pre-register their card details with a trusted authority, such as a bank or other financial institution. The details held can include any or all of card number, expiry date, CVN, customer name, or address.

The registration process can be arranged to take place in a manner which does not place the card data in any jeopardy (either real or perceived) . For instance, the cardholder may register the required details in person at a branch of his bank or by telephone or fax. It is also technically possible to perform this task over the internet, using a suitable secure browser, but given the nature of the invention, this option is not likely to appeal to the probable target market. However, if the cardholder is satisfied that the supplied link is secure, then it may be useful to register the details in this way.

Just because the cardholder is generally suspicious of supplying card details over the Internet, they may be happy to provide them to a known trusted institution, so it may still be worthwhile to capture the data in such an online manner.

Once the cardholder's details have been registered with the trusted authority, any vendor with whom the customer later deals is able to authenticate the customer's credentials by making a query to the trusted authority.

Figure 1 shows an exemplary system configuration. The customer's computer 10 is connected to the Internet 400 in the usual way (e.g. dial up, broadband or wireless connection) . Also shown is the user's mobile telephone 20, details of which may be registered with the trusted authority and which may be used for messaging.

Also connected to the internet are a plurality of vendor's web servers 100-199. The customer's computer may access any of these in a known way using regular browsers such as Internet Explorer from Microsoft .

The vendors' web servers are further connected, either via the internet or dedicated lines, to one or more bank systems 300 for handling payment transactions.

The bank systems or transaction servers 300 are connected to a trusted authority 200, preferably by dedicated lines or a secure signalling system. The trusted authority includes a database of customer details enabling transactions to be made by said customers without needing to transmit sensitive data over a public network (e.g. the Internet 400) Communication between the bank 300 and the trusted authority 200 are deliberately very secure and not intended to be accessible to unauthorised third parties.

Also connected to the bank computers 300 is a message centre 30 which is operable to transmit and receive messages to customers by a number of means. For instance, email messages may be sent to and from 310 to the user's PC 10 and SMS messages may be sent to and from 310 to the user's telephone 20.

Having described the physical setup, it is instructive to examine an example transaction to demonstrate the system in operation.

The customer (C) visits a website for a vendor (V) and decides to purchase an item. C has previously registered his payment card details with a trusted authority (such as his bank or card provider) and decides to make use of that facility to complete purchase of the item, rather than enter his card details directly.

At the payment stage, C selects the appropriate payment option, instructing V's system to contact the trusted authority to authorise payment. This is preferably an automated request made to the trusted party using https or other secure link. The request would include at least the client's name and address so that he can be uniquely identified.

Assuming the details provided by V coincide with those registered by C, the trusted authority contacts C to seek confirmation of the payment.

The trusted authority may contact C in one or more ways from the following: * Email * SMS (Short Message Service) or text message to a registered telephone number.

* Personal telephone call to a pre-registered number.

* Automated telephone call a pre-registered number, possibly using Interactive Voice Response (IVR) system.

In order to authorise the payment, the customer must reply to the message from the trusted authority with an agreed pre-defined response in the form of a password.

In a particularly preferred embodiment, the message to the customer from the trusted authority is in the form of an automated voice message. The response from the customer can then be verified to ensure that the password/security code given matches the pre-agreed password/security code and voice authentication can be used to provide further confidence that it is in fact the customer giving the authorisation, rather than an impostor.

In case of a fault with the authentication process e.g. an incorrect password is given or the voice does not match the registered voice, then the purchase is not authorised, the customer's account is not debited and the vendor is informed accordingly.

The same result is obtained in the event of a time-out i.e. if a correct response is not forthcoming within a defined period of time.

Figure 2 shows a typical message flow according to an embodiment of the invention. The steps involved in a transaction are labelled 1 to 10.

The four solid vertical lines represent the customer, the vendor, the trusted authority and the transaction server.

In the setup exemplified in Figure 2, the trusted authority and the transaction server are physically collocated in the bank premises, although this needn't be the case and they may be physically separated but connected by a secure link. In any event, a secure firewall is provided between them.

At Step 1, the Customer seeks to make an online purchase from a particular vendor.

At Step 2, the Vendor seeks verification from the trusted authority that the customer is indeed so registered and includes sufficient information to identify the customer (name, address) and the amount of the transaction.

At Step 3, the trusted authority authenticates the customer's identity and card details with the payment authority at the transaction server. The payment authority may be a bank, credit or debit card provider or other financial institution (e.g. VISA, American Express) At Step 4, assuming that all the details provided are valid, the transaction server confirms the details and authenticates the customer.

At Step 5, the trusted authority transmits a message directly to the customer via one or more means (e.g. SMS, email or automated telephone call with or without voice recognition) At Step 6, the customer confirms the purchase by a suitable reply, possibly using a pre-defined password, PIN or other secret confirmation technique (e.g. digital certificate) . If a voice response is used, it may optionally be processed to ensure that the speaker is indeed the registered cardholder.

At Step 7, the trusted authority transmits an instruction to the transaction server to perform the required payment.

At Step 8, the transaction server responds to the trusted authority that the payment transaction has been completed successfully.

At Steps 9 and 10, the trusted authority transmits messages to the vendor and customer respectively informing each that the transaction has been completed successfully.

If at any stage in the above mentioned process, authentication is denied or the transaction is otherwise suspended, then one or more suitable messages are sent to the appropriate party to inform them of the problem.

Advantageously, embodiments of the invention allow customers to purchase items from remote vendors (either over the Internet or otherwise) without entering confidential data each time a purchase is made. The confidential data need only be registered once with a suitable party and then subsequent transactions can be made using public data which can be confirmed by use of a password or other secret or difficult to forge technique.

This handshaking ensures that rogue parties can not purchase items by knowing only certain public items of information on the customer.

The present invention can be implemented as computer-readable code on a computer-readable recording medium.

The computer-readable recording medium is any data storage device that can store data which can be thereafter read by a computer system. Examples of the computer-readable recording medium include read-only memory (ROM), random-access memory (RAM), CD-ROMs, magnetic tapes, floppy disks, optical data storage devices, and carrier waves (such as data transmission through the Internet) The computer-readable recording medium can also be distributed over network-coupled computer systems so that the computer-readable code is stored and executed in a distributed fashion.

Attention is directed to all papers and documents which are filed concurrently with or previous to this specification in connection with this application and which are open to public inspection with this specification, and the contents of all such papers and documents are incorporated herein by reference.

All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and/or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and/or steps are mutually exclusive.

Each feature disclosed in this specification (including any accompanying claims, abstract and drawings) may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise. Thus, unless expressly stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features.

The invention is not restricted to the details of the foregoing embodiment(s). The invention extends to any novel one, or any novel combination, of the features

disclosed in this specification (including any

accompanying claims, abstract and drawings), or to any novel one, or any novel combination, of the steps of any method or process so disclosed.

Claims

CLPIMS

1. A method of facilitating a financial transaction, comprising the steps of: a customer requesting to purchase an item from an online vendor; the vendor seeking to validate the identity of the customer from a trusted authority by providing the trusted authority with information capable of uniquely identifying the customer; the trusted authority validating the identity of the purchaser by comparing the information supplied by the vendor with information pre-supplied by the customer; if the customer's identity is validated, the trusted authority transmitting a message to the customer seeking approval to complete the transaction; if the customer wishes to complete the transaction, transmitting to the trusted authority certain information known only to, and/or particular to, the customer; and the trusted authority approving payment to the vendor and transmitting confirmation messages to the vendor and the customer.

2. A method as claimed in claim 1 wherein the certain information known only to, and/or particular to, the customer comprises at least one of a password, a PIN number, a security code or a signature produced from the customer's voice.

3. A method as claimed in claim 1 or 2, wherein communications between the vendor and the trusted authority are encrypted and transmitted via data lines.

4. A method as claimed in any preceding claim wherein the means of communication between the trusted authority and the customer comprises at least one of: Short Message Service (SMS) to a registered mobile device; a personal telephone call to a registered number; an automated Interactive Voice Response (IVR) message to a registered telephone number; or an email.

5. A method as claimed in any preceding claim wherein other methods of conducting a financial transaction are additionally offered and the customer opts for only one method.

6. A method as claimed in any preceding claim wherein the trusted authority is a financial institution.

7. A method as claimed in any preceding claim wherein, prior to making a purchase, the customer registers his identity with the trusted authority, along with his payment card details.

8. A method as claimed in claim 7, wherein the step of registering identity comprises the user providing a voice sample for the purpose of establishing a unique voice signature.

9. A computer-readable recording medium on which a program for executing a method according to any preceding claim is recorded.

10. A method as hereinbefore described, having particular reference to the accompanying drawings.