GB2493331A - Transaction Systems and Methods - Google Patents

Abstract

Methods, systems and apparatus are provided for performing transactions. A method of conducting a transaction involves authorising the transaction only if a cumulative balance in an account of different currencies exceeds the transaction amount by a predetermined amount. A method of providing funds from a sending party to a receiving party involves, upon the provision of a token to a user, his/her account having currency balances in a first currency, and a second currency associated with the token provider. A method of conducting a transaction without direct external authorisation involves mutually validating a merchant and customer token 850, such as cards, through a POS and then transferring 860 a balance from the customer token to the merchant token. A merchant and customer token are also claimed, which may be in a smart card. The merchant and customer token have an account management application. A POS terminal is also provided that is adapted for offline transactions between two smart cards. The terminal has a first and second interface and can transfer a balance amount between the tokens. Also a process for reconciliation 870 of an account is also provided, involving performing offline transactions using a token and subsequently establishing communication with a financial institution to update the account with the offline transactions.

Description

Transaction Systems and Methods

Field of Invention

This invention relates to systems, apparatus and methods to allow users to carry out transactions such as card payments. In aspects, this approach is particularly applicable to cross border and other transactions involving more than one currency.

Background to Invention

Traditionally, all cards issued by banks and other financial institutions are denominated to one currency and are linked to an account in the bank or the institution in that currency. Cards enabling financial transactions to be carried out between banks are generally associated with a card payment scheme (hereafter card scheme"), such as Visa or Mastercard. These schemes provide a system for enabling interaction between one bank and another with the card payment scheme as an intermediary. When a cardholder travels abroad and uses the card in a merchant establishment that bills in a currency other than the currency of the card, a currency conversion process is needed. This process is carried out by either the card scheme associated with the card, or by the issuing bank (the bank which has issued the card) or the acquiring bank (the bank with which the merchant has its account). The institution which carries out the process also sets the exchange rate.

Under this system, a common transaction layout known as the standard card process enables a cardholder to perform a transaction in a currency that is different to the card currency. In this process the card issuer carries out the currency conversion.

When the cardholder presents the card to a merchant, the merchant requests authorisation from the card scheme for the transaction in the transaction currency. The card payment scheme forwards the authorisation request on to the card issuer, which then provides an authorisation response. If authorisation is granted, the transaction is carried out as follows: the card issuer settles with the card scheme in the card currency; the card scheme performs currency conversion and then settles with the transaction acquirer (the bank for the merchant receiving funds in the transaction) in the transaction currency; and finally, the transaction acquirer settles with the merchant.

The exchange rate in this case is set by the card scheme in consultation with the card issuer.

The final amount debited subsequently appears in the card currency on the cardholder's statement together with the exchange rate that was used.

In a variation on this approach, the cardholder is able to purchase goods abroad using a transaction currency that is the same as the card currency, with dynamic currency conversion to the merchant's home currency for settlement with the merchant. For example, under this

I

system a British cardholder can purchase items in France where the transaction currency is sterling pounds rather than euros.

In this approach, the exchange rate is set by the transaction acquirer and shared with the merchant. All transaction steps then take place in the card currency and the cardholder's statement will subsequently show the transaction in the card currency.

In both the standard card process and dynamic currency conversion, it is not clear to the user what exchange rate is being used. Under the standard card process the final amount debited only appears subsequently to the transaction on the cardholder's statement. Under dynamic currency conversion the cardholder may have a limited opportunity to view the rate used at the time of transaction, but will have no practical control of this process. This lack of transparency reduces user confidence and creates regulatory concerns.

In an effort to provide more options for users, some card issuers offer dedicated cards denominated in currencies of interest to the cardholder. For instance, a British cardholder normally having a card denominated in Pounds Sterling could have additional cards denominated in euros, dollars, rands, and so on. When this cardholder travels to France and pays for a transaction billed in euros, the cardholder can use the euro denominated card.

These cards may be pre-loaded in a number of ways: using a debit or credit card, online banking or cash-loading at point of purchase. If a euro denominated card is taken to France and used for payment in euros, no currency conversion is necessary. The currency conversion has effectively already taken place at the pre-loading stage, and the currency exchange rate for this pre-loading stage is simply that set by the card issuer at that time.

Such a card can still be used to perform a transaction in a currency that is different to the card currency, but in that case currency conversion again becomes necessary under either the standard card process or under dynamic currency conversion, as above.

Use of separate denominated cards of the relevant currency for each transaction does enable the user to see the true cost of each transaction as it is carried out, but it has obvious practical disadvantages. Managing several different currency cards presents significant inconvenience to the cardholder: the correct cards have to be remembered and greater numbers of cards may have to be carried around. If an incorrect card is taken by mistake unnecessary further currency conversion costs will be incurred. Furthermore, there are costs associated with producing each of the cards, which are ultimately passed on to the cardholder. This system also has a layer of inflexibility in that once a card is pre-loaded, further currency conversion costs will be incurred if the cardholder subsequently requires more funds in a particular currency than planned.

The Commonwealth Bank of Australia operates a prepaid card called the "Travel Money Card" which allows a balance to be held in up to six currencies. When used for a transaction, the card will seek to debit the balance in the transaction currency. When there is an insufficient currency balance in the transaction currency, the card will seek to debit the balance in another currency according to a previously determined currency order. This approach provides additional possibilities, but still provides only limited flexibility and control for the user.

The present invention seeks to address some or all of the above issues.

Summary of Invention

In a first aspect, the invention provides a method of conducting a transaction, comprising: providing a user token, associated with a user account having a plurality of currency balances in different currencies, to a merchant; requesting authorisation of a transaction to debit a transaction amount from one of the currency balances in the account; providing authorisation for the transaction only if a cumulative currency balance in the account exceeds the transaction amount by a predetermined amount, where the cumulative currency balance is determined by summing the currency balances in the different currencies in the user account and any credit limit for the user account; and completing the transaction only if authorisation is provided.

This approach is advantageous over the prior art, as it allows the user far greater control and flexibility in transactions compared to conventional card transactions.

In a preferred arrangement, the credit limit for the user account is zero -this is a prepaid system, in which the user account is required to maintain a non-negative credit balance.

Advantageously, the user token is a banking card, and the steps of requesting authorisation and completing the transaction are carried out using a point of sale terminal. The steps of requesting and providing authorisation comprise requesting and providing authorisation may be mediated through an interchange switch when the user token and the merchant are not associated with a same financial institution.

In a related aspect, the invention provides a method for a user to conduct a transaction with a merchant, comprising: providing a user token, associated with a user account having a plurality of currency balances in different currencies, to a merchant; requesting authorisation of a transaction to debit a transaction amount from one of the currency balances in the account; receiving authorisation for the transaction only if a cumulative currency balance in the account exceeds the transaction amount by a predetermined amount, where the cumulative currency balance is determined by summing the currency balances in the different currencies in the user account; and being permitted to complete the transaction only if authorisation is provided.

In a related aspect, the invention provides a method of conducting a transaction at a point of sale terminal of a merchant, comprising: receiving a user token, associated with a user account having a plurality of currency balances in different currencies; requesting authorisation of a transaction to debit a transaction amount from one of the currency balances in the account; receiving authorisation for the transaction only if a cumulative currency balance in the account exceeds the transaction amount by a predetermined amount, where the cumulative currency balance is determined by summing the currency balances in the different currencies in the user account; and completing the transaction only if authorisation is provided.

In a related aspect, the invention provides a method of providing a transaction authorisation response, comprising: receiving an authorisation request for a transaction to debit a transaction amount from a currency balance of an account having a plurality of currency balances in different currencies; providing authorisation for the transaction only if a cumulative currency balance in the account exceeds the transaction amount by a predetermined amount, where the cumulative currency balance is determined by summing the currency balances in the different currencies in the user account.

In a related aspect, the invention provides a system for conducting transactions from a user account in a plurality of currencies, comprising: means for holding a user account having a plurality of currency balances in different currencies; a user token associated with the user account for presenting to a merchant; and point of sale apparatus for receiving the user token and for requesting authorisation for a transaction in one of the currencies in the user account, and for completing the transaction if authorisation is received; wherein the means for holding the user account is adapted to authorise the transaction only if a cumulative currency balance in the account exceeds the transaction amount by a predetermined amount, where the cumulative currency balance is determined by summing the currency balances in the different currencies in the user account.

In such a system, the means for holding a user account may be a computer system associated with a financial institution or may be a computer system associated with an interchange switch. The user token may comprise a banking card.

In a related aspect, the invention provides a user token for use in a system for conducting transactions from a user account in a plurality of currencies, the user token comprising: a memory comprising an identification of the user account and authentication information to link the user account with a user, wherein the user token is adapted for use in a method as described above. This user token may be a banking card.

In a related aspect, the invention provides a point of sale apparatus for use in a system for conducting transactions from a user account in a plurality of currencies, the point of sale apparatus comprising a user token reading means, a user interface, and a communication means for communicating with a remote server adapted to provide authorisation information, wherein the point of sale apparatus is adapted for use in a method as described above.

In a further aspect, the invention provides a method of providing funds from a sending party to a receiving party, comprising: the sending party establishing a currency balance in a first currency in a user account and obtaining an authorisation code; the sending party providing the authorisation code to the receiving party; the receiving party providing the authorisation code to a user token provider; and the user token provider providing the receiving party with a user token associated with the user account, whereby upon provision of the user token the user account has currency balances in the first currency and a second currency associated with the user token provider.

Advantageously, the currency balance is established with a first financial institution and the user token provider is associated with a second financial institution.

In a related aspect, the invention provides a method of receiving funds from a sending party, comprising: receiving an authorisation code from the sending party associated with a user account having a currency balance in a first currency; providing the authorisation code to a user token provider; and receiving a user token associated with the user account, whereby upon receipt of the user token the user account has currency balances in the first currency and a second currency associated with the user token provider.

In a related aspect, the invention provides a method of sending funds to a receiving party, comprising: establishing a currency balance in a first currency in a user account; obtaining an authorisation code for enabling the receiving party to obtain a user token associated with the user account from a user token provider, whereby upon receipt of the user token the user account has currency balances in the first currency and a second currency associated with the user token provider; providing the authorisation code to the receiving party.

In a related aspect, the invention provides a method of delivering funds from a sending party to a receiving party, comprising: receiving an authorisation code from the receiving party for matching to a user account having a currency balance in a first currency; providing the authorisation code to an account provider to obtain account details to be associated with a user token; creating and providing the receiving party with a user token associated with the user account, whereby upon provision of the user token the user account has currency balances in the first currency and a second currency associated with the delivery of the funds.

In a related aspect, the invention provides a method of providing funds from a sending party to a receiving party, comprising: receiving funds from the sending party; establishing a currency balance representing the funds in a first currency in a user account; providing an authorisation code associated with the user account to the sending party; receiving the authorisation code from a user token provider and matching the authorisation code to the user account; providing account details to the user token provider to allow creation and provision of a user token associated with the user account to the receiving party, whereby upon receipt of the user token the user account has balances in the first currency and a second currency associated with the user token provider.

In a further aspect, the invention provides a method of conducting a transaction without direct external authorisation, comprising: providing a merchant token and a customer token to a point of sale device; establishing to each other the validity of the merchant token and the customer token through the point of sale device; completing the transaction by transferring a transaction amount from a currency balance held on the customer token to a currency balance held on the merchant token; whereby one or more of the merchant token, the customer token and the point of sale device is subsequently connected to an account providing institution to reconcile the transaction against a customer account associated with the customer token and a merchant account associated with the merchant token.

The customer token may be adapted to hold currency balances in a plurality of currencies.

In a related aspect, the invention provides a method for a customer to conduct a transaction without direct external authorisation, the method comprising: providing a customer token to a point of sale device also provided with a merchant token; establishing the validity of the merchant token and demonstrating the validity of the customer token to the merchant token; and completing the transaction by transferring a transaction amount from a currency balance held on the customer token to a currency balance held on the merchant token.

The customer token may be adapted to hold currency balances in a plurality of currencies.

In a related aspect, the invention provides a method for a merchant to conduct a transaction with a customer without direct external authorisation, the method comprising: providing a merchant token to a point of sale device also provided with a customer token; establishing the validity of the customer token and demonstrating the validity of the merchant token to the customer token; and completing the transaction by receiving a transaction amount from a currency balance held on the customer token to increment a currency balance held on the merchant token.

In a related aspect, the invention provides a customer token for conducting offline transactions, comprising: a processor and a memory, wherein the memory contains account identification information, customer authorisation information and a transferable account balance associated with the identified account, and wherein the memory further comprises an account management application adapted to run on the processor, wherein the customer token is adapted to execute the account management application when in connection with a point of sale terminal, whereby on customer authorisation using the customer authorisation information the customer token is adapted to debit the transferable account balance held in the memory to transfer funds to another account associated with the point of sale terminal.

The memory of the customer token may hold a plurality of transferable account balances in a plurality of currencies.

In a related aspect, the invention provides a merchant token for conducting offline transactions, comprising: a processor and a memory, wherein the memory contains account identification information, and an account balance associated with the identified account, and wherein the memory further comprises an account management application adapted to run on the processor, wherein the merchant token is adapted to execute the account management application when in connection with a point of sale terminal when the point of sale terminal is also in connection with a customer token, whereby on customer authorisation to debit an account balance on the customer token by a transfer amount, the account management application is adapted to credit the account balance of the merchant token by the transfer amount.

The merchant token may be adapted to reconcile the account balance directly with an account provider when a transaction threshold has been reached. This transaction threshold may comprise a predetermined number of transactions.

In a related aspect, the invention provides a smart card comprising a customer token or a merchant token as described above.

In a related aspect, the invention provides a point of sale terminal adapted for offline transactions between two smart cards, the point of sale terminal comprising: a memory storing a transaction application and a processor adapted to run a transaction application; a user interface; a first interface for a customer token and a second interface for a merchant token; wherein on activation of the transaction application, the point of sale terminal is adapted to cooperate with a customer token and a merchant token to transfer a transfer

S

amount from a transferable account balance held on the customer token to an account balance held on the merchant token.

Advantageously, the point of sale terminal further comprises a telecommunications interface, and wherein the point of sale terminal is adapted to communicate with an account provider associated with a merchant token to enable reconciliation of a merchant account with the merchant token. These first and second interfaces may be smart card interfaces.

In a related aspect, the invention provides a process for reconciliation of an account between a token used for offline transactions and a financial institution, comprising: performing one or more offline transactions using the token, and recording offline transaction details on the token; establishing communication between the token and a server of a financial institution; and reconciling the account at the financial institution by updating the account with the stored offline transactions.

If the offline transactions exceed a predetermined threshold, the step of reconciling the account may be required to take place before further offline transactions can be made. If the token is a merchant token, the offline transactions may comprise one or more transactions made offline with a customer token through a point of sale terminal.

Brief Description of Drawings

Specific embodiments of the invention will now be described, by way of example, with reference to the accompanying drawings, of which: Figure 1A shows a transaction system embodying aspects of the invention and suitable for use with other aspects of the invention -Figure 1 B shows a schematic representation of the flows of money in such a system; Figure 2 shows a user token for use in the transaction system of Figure 1; Figure 3 shows a point of sale terminal for use in the transaction system of Figure 1; Figure 4 shows an embodiment of a method of establishing and initialising a multicurrency account; Figure 5 shows an embodiment of a method of carrying out a transaction using a multicurrency account; Figures 6A, 6B and 6C show steps of a method as shown in FigureS from the perspective of the user, the issuing host and the P05 terminal respectively; Figure 7 shows an embodiment of an end of day reconciliation process for an interchange for multicurrency accounts; Figure 8 shows an embodiment of a process for a third party sending funds to establish a multicurrency account and for a user token to be initialised; Figures 9A to YD show the process of Figure 8 from the perspective of the sending party, the receving party, the PUS terminal and the financial institution providing the account respectively; Figure 10 shows a smart card for use as a user token in a further embodiment of the invetion; Figure 11 shows a smart card for use as a merchant token in a further embodiment of the invention; Figure 12 shows a PUS terminal for use in conducting offline transactions according to a further embodiment of the invention; Figure 13 shows data stored in the memory of the smart card of Figure 10; Figure 14 shows data stored in the memory of the smart card of Figure 11; Figure 15 shows a process for carrying out offline transactions using the appraratus of Figures 10 to 14; Figure 16 shows steps carried out by a user in the process of Figure 15; Figure 17 shows steps carried out bya merchant in the process of Figure 15; Figure 18 shows steps carried out at a PUS in the process of Figure 15; Figure 19 shows a reconciliation process to reconcile accounts after offline transactions carried out as indicated in Figures 15 to 18; Figure 20 shows steps carried out by a merchant in the process of Figure 19; Figure 21 shows steps carried out at a PUS in the process of Figure 19; and Figure 22 shows steps carried out at a financial institution in the process of Figure 19.

Description of Specific Embodiments

The elements of a transaction system in which aspects of the invention may be embodied is shown in Figure 1. The transaction system 1 contains a number of domains 2 each relating to a different host -typically a bank. A host may be a card issuer or a transaction acquirer (a merchant's bank), though not all hosts need be both card issuers and transaction acquirers.

These host domains 2 do not interact directly, but are connected by an interchange switch 3, which is the medium for transactions between host domains.

Each of the host domains 2 illustrated contains a host switch 21, which connects to a network of point-of-sale (P05) terminals 22. A merchant interacts with his or her host domain (the merchant's bank) through the PUS terminal 22 associated with that merchant. The bank has an electronic banking host 23 (hereafter termed "host") associated with its host switch 21 -the host is adapted to complete transactions and reconcile them with customer accounts, together with all other actions conventionally involved in maintaining and supporting a banking infrastructure. A host will generally be a banking institution, but may cover entities other than conventional banks which also hold customer accounts. As this aspect of the transaction system is essentially conventional and so will be well understood by the person skilled in the art, it will not be discussed in detail here, though aspects of particular relevance to implementation of aspects of the invention will be described further below. It should be noted that the functionality of the host switch 21 may be provided by a group of switches, and that the functionality of the host 23 will in practice generally be provided by a network of servers and other computing system elements. Furthermore, as well as P03 terminals, there are other transaction acquiring terminals, of which some examples are shown in Figure 1.

Automatic telling machines 25 will also be connected to the host 23 through the host switch 21. Web interaction through a computer 27 or a mobile phone 26 will pass directly to the host 23 (as this communication will be by HTTP protocols rather than by ISO 8583 as used by banking switches). Interactive voice response (IVR) and other telephonic banking will use telephony from a user's telephone 26 to a call centre 24 within the host's firewall, and then with the host 23 through a host intranet.

The customer 4 is shown as outside the host domains 2, though the customer has a user token 41 which will typically be provided by one of the host domains 2 in a manner described below. This user token 41 is usable as a transaction card (such as a credit card or debit card) to enable transactions to be carried out.

At this level of definition, the transaction system is essentially similar to that used in payment systems such as Visa or Mastercard. The roles of each system element and their relationship to aspects of the invention will now be described with reference to Figures 1 to 3.

Figure 2 shows a user token 41 -this is typically provided in the form factor of a credit card, with a memory 42 holding the particulars of a user account with which the card is associated.

The memory is readable by a P03 terminal 22 and may, for example, be provided in a magnetic strip or an embedded microchip. The user token may be a smart card, with processing as well as memory capability when powered. Account particulars such as the account number, the name of the account holder and the card expiration date are stored in the memory for interrogation by the POS terminal. The card is insertable into the P05 terminal so that, when inserted, the P03 terminal can read the memory of the card and retrieve the particulars of the user account. A user 4 may also be able to access account details from the Internet by use of appropriate security details, and these security details may perform the role of user token in some embodiments described below.

Figure 3 shows the P03 terminal 22, which is a computing device with memory 221, processor 222 and networking capability 223, as well as a card reader 224 for interaction with the user token 41 and a secure PIN pad 225 to allow a user to enter a PIN securely. It can receive a user token and will have an identity associated with the merchant (this may be provided by some form of merchant token, or may be an identity which can be validated by the host domain associated with that P03 terminal -such as a cryptographic identity held in secure hardware). The memory 221 stores application code for reading at least a user token, for sending and receiving messages to and from the host domain 2 and the interchange switch 3, for requesting and receiving user input and for performing validation processes, including where necessary combining the user input with information stored on the card for external verification. The FOS terminal 22 is connected either telephonically or by a network to its host domain and can send and receive messages using these channels. When a user token 41 is inserted into the FOS terminal 22, it is used to enable transaction processes set out below involving the user and the host domain and, where necessary, the interchange switch by running the code in its memory and responding to inputs from relevant parties.

As is discussed further below, the P05 terminal 22 can support transactions other than a simple purchase. These can include enabling a funds transfer transaction in which a sending party provides funds for a beneficiary; and establishment of a new user token associated with an account.

The interchange switch 3 is a switch, or network of switches, that enables communication between domains 2 for accounts associated with the interchange switch 3. It handles authorisation, transaction and settlement procedures which cross domains 2. As for the host switch 23, the interchange switch 3 may be embodied by a plurality of switches, servers, and other computing infrastructure.

In regard to transaction authorisation across domains, the interchange switch 3 is adapted to transmit messages between hosts to allow receipt and processing of authorisation requests and transmission of a response based on net funds available in the cardholder's multicurrency account. If authorisation for the transaction is granted, the processing steps of the transaction are performed by the host 23 and messages instructing settlement are subsequently passed on by the interchange switch 3 and sent to the relevant institutions, such as the cardholder's bank. To enable such communication, each host 23 using the interchange switch 3 has an account with an interchange switch provider. This account will reflect a totality of money flows for that host 23 in relation to the interchange switch 3.

The card issuer is typically the cardholder's bank -the user token 41 is part of the same domain 2 as the card issuer, or card issuing bank (it is possible that the card will be physically provided by another entity -such as the merchant, as discussed in processes below -but for these purposes the "card issuer" is considered to be the financial entity with which the user has funds on account). The card issuer acts as a bridge connecting the cardholder's funds to other parties with whom the cardholder is transacting, and executes these transactions on authorisation from the cardholder.

The acquirer is the merchant's bank, and so forms part of the same domain 2 as the merchant. The acquirer takes essentially the same role in respect of the merchant as the card issuer takes in respect of the cardholder, and the acquirer will thus need similar functionality to the card issuer -typically, a given bank holding an account with the interchange switch 3 will be able to take either a card issuer or an acquirer role.

The basic structure of a multicurrency account as used in aspects of the present invention will now be described, together with embodiments of methods for establishing and initialising such accounts.

A host 23 is thus able to provide multicurrency functionality to accounts held by cardholders.

This is delivered using a ledger comparable to traditional ledgers except that it holds balances in more than one currency. The ledger provides a record of withdrawals and deposits together with their resulting new balances, and in this way the ledger forms the core structure of the account. Since balances are held in multiple currencies, all transaction entries are given in every currency of the account, typically together with other information relating to the individual transactions. This other information can include payer identification, payee identification, time of transfer, charges made by relevant financial service providing institutions and transaction reference numbers.

Multicurrency accounts are set up under the cardholder's name, and typically established in the cardholder's home country. Accounts can be established by a range of approaches, including at the cardholder's bank, online or at a P05 terminal. A general process of account establishment and initialisation is shown in Figure 4. In general, the cardholder will have to provide some form of secure identification (step 200) and will have to provide sufficient minimum funds (step 220) to load the account and to cover any charges associated with establishing the account. Details and funds required to establish the account are sent to the interchange switch which processes and forwards these to the interchange server where the multicurrency account is established (step 240).

Once an account has been established it will be associated with a home currency: this may be a currency of the cardholder's home country, or may be the working currency of the card issuer. In some embodiments, the card issuer offers a selection of currencies that can be chosen by the cardholder as the home currency of the account, but the discussion here assumes that the home currency of the account is a currency of the cardholder's home country, and is fixed by the card issuer. In any case, the home currency acts as a default currency for the account in which a net balance expressing the total funds across all currency balances can be provided.

In order to provide the account holder with a card, the host 23 generates card initialisation details that are sent to the location of the user (step 260). For example, if the user is setting up the multicurrency account at their bank, the card initialisation details will be sent to the bank, where a card can be taken from a stock of blank cards and loaded with details relating to the multicurrency account and identifying the user as the account holder. As is discussed further below, a similar process can be carried out at a merchant with a FOS machine 22 if a bank has subcontracted card issuing capability to the merchant. This initialises the card (step 280) and from that point on the cardholder can use the card for purchase and other transactions, as described below.

A cardholder can load different currencies onto their account by a range of approaches: these include the conventional approaches at a bank or online (by depositing currency or by transferring funds from another account) and also by using a P05 terminal and providing funds to a merchant. As new currencies are loaded onto the account, corresponding new currency balances are established and the multicurrency aspect of the account develops organically with use depending on the transaction activity of the cardholder. The funds on the account can then be expressed as a list of balances in the various currencies of the account, together with the net balance expressed in the home currency. The net balance provides a convenient indication of total funds, based on prevailing currency exchange rates and taking into account any negative currency balances. Cardholders can view their balances online or at ATM terminals, or by requesting print outs at their bank, or by other conventional methods of account access such as mobile phone text alerts and other mobile banking applications.

Cardholders can move funds between their currency balances, for example online, at a PUS terminal or using a mobile phone application. Although such transfers are between currency balances of the cardholder's account and are set up by the cardholder, they do not take place entirely within the multicurrency account. Transfers between currency balances require currency conversion, and consequently an interaction with an internal currency conversion account administered by the treasury function of the cardholder's bank is involved. The mechanism of the transfer is provided by a combination of transactions between currency balances of the multicurrency account and currency conversion accounts of the cardholder's bank such that funds only change currency when moving between the internal currency conversion accounts of the bank.

Fund transfers between currency balances may also be necessary as part of an end of day (EUD) reconciliation process. For example, if the account has a euro balance of zero in the morning and 50 euros are spent that day, the resulting currency balance will be -50 euros.

Whether this is carried over from one banking day to another will be determined by host policies -it may be the policy of the banking host that negative currency balances should be neutralised at the end of the banking day. If so, during the EOD process, the negative balance is neutralised by moving funds from positive currency balances into the euro balance according to an automatic EUD protocol that steps through the positive balances using a predetermined route. Neutralising the euro balance using other currencies involves currency exchange and therefore requires interaction with the card issuers internal currency converting accounts, in the same way as for manual transfers between currency balances. This process can start with the home currency (assuming there are funds there) and step through the other currencies until the negative balance is cleared -however, the process of determining the order in which funds will be transferred by other currencies may operate according to institution-defined or customer-defined rules (for example, the rule may be to remove small balances first, or least used balances, or simply to debit currency balances in a currency order determined by the customer). There may also be legal considerations -for example, it may not be possible to debit a balance in a currency for which currency controls apply other than by performing a transaction within the relevant country. Regardless of the order in which balances are stepped through, this process involves a currency exchange which is effected by interacting with the internal currency exchange accounts of the host.

Cardholders can have physical or virtual cards associated with their multicurrency account.

Virtual cards can be used for internet banking and mobile transactions, while physical cards can have functionality from a fuller range, including capabilities for payment at P08 terminals and obtaining a cash advance at ATM terminals. Virtual cards may simply comprise a card number and various of the security and identification details that would be found on an equivalent physical card.

A process of transacting using a user token for a multicurrency account (multicurrency card) will now be described with reference to Figures 5 and 6. Figure 5 provides a general outline of the transaction process, with Figures 6A, 6B and 6C showing the transaction process from the perspective of the user, the interchange switch and the P08 terminal respectively.

Once a multicurrency account has been established and loaded with funds, the rriulticurrency card can be used to effect transactions at P08 terminals to purchase items in retail environments. The steps of the transaction process involve interaction between various parties, and will now be described in some detail.

The cardholder initiates the transaction process by providing his or her card 41 to the merchant (step 410), and the card is inserted into the P08 terminal 22. Once the card has been inserted, various data stored in the memory 42 of the card are interrogated by the P08 terminal and information specifying the cardholder's identity and bank details can be extracted for use in the transaction. This information is combined with user input provided by the cardholder (step 424), such as a PIN code entered using the secure PIN pad for the P08 terminal and retained there securely (for example, as defined in existing standards for secure transactions), and it is at this point that the POS terminal initiates the series of requests that are required to perform the transaction. The first request is to check that the transaction is acceptable from the point of view of the acquirer. The data extracted from the memory of the card together with the user input are sent in the standard message protocol format to the host switch of the acquirer, in accordance with normal requirements -the PIN code is not sent in an explicit format during this communication, but rather is convolved with the other data being sent in such a way that the acquirer has enough information to carry out its checks but at no point has access to the cardholder's PIN code.

Assuming the transaction is acceptable to the acquirer (it is possible that a transaction could be flagged, say, as being unacceptable for that merchant or for KYC concerns) but the cardholder is not a cardholder of the acquirer, a message is sent to the host of the card issuer (ie. the cardholder's bank) to check there are sufficient funds in the cardholder's account (step 426). This message crosses domains 2 and therefore travels via the interchange 3 which receives and re-routes the message towards its destination. For the purpose of re-routing, the acquirer sends the request to the interchange 3 together with the card number which includes the cardholder's bank identification number (BIN). The interchange then identifies the cardholder's bank and forwards the transaction request to the card issuer's host switch 21. The transaction request is finally delivered to the card issuer's host (step 432) where the cardholder's money lives, and the level of funds in the cardholder's account can be established.

In the approach shown here, the level of funds will be sufficient if the total funds on the account are equivalent to at least 105% of the transaction amount, where the final 5% provides a margin to allow for changes in currency exchange rates between the time of the transaction and the next EOD process. The choice of margin is essentially arbitrary and need not be set to 5% -it may be set at whatever level is considered appropriate to the host or could be varied according to perceived customer risk. Once the level of funds has been established, an authorisation response (either authorise or decline') is sent from the host server (step 434), through the host switch and interchange, and into the domain of the merchant's bank, finally arriving at the merchant's POS terminal 22 (step 442).

The POS terminal completes the transaction only if it receives authorisation to do so (step 444). The transaction steps are essentially similar to those carried out using conventional credit cards -however, the decision making process to authorise a transaction is different in character from that used for conventional credit card transactions.

If the Card Issuer and the Acquirer have accounts with the same host, the transaction will take place within the same domain 2 and there will be no need for communication with the interchange 3. In this case, an authorisation request from a P08 terminal 22 will arrive at the host switch 21 and be sent directly to the host server 23 for checking the funds in the cardholder's account.

An end of day (EOD) reconciliation process for a multicurrency account will now be described with reference to Figure 7.

At the end of the day the interchange 3 generates and distributes the settlement report (steps 810 and 820) so that funds can be collected from cardholder accounts and delivered ultimately to merchant accounts. Each host has an account with the interchange 3, reflecting the totality of the transactions of that host through the interchange 3, and the settlement report relates to all of these host accounts. This closes a money flow loop -as shown by Figure lB -initiated by the provision of a product or service from the merchant to the cardholder earlier that day. The interchange collects funds from the card issuers (step 830), deducts any fees or charges (step 840) and distributes the funds to the acquirers (step 850) according to the settlement report. The acquirers settle with the individual merchants who bank with them, and similarly the card issuers settle with the cardholders' accounts.

The interchange 3 may have local bank accounts in each country in which it operates for settlement purposes. This contributes to the seamless settlement process referred to above.

If for a particular transaction the issuer and acquirer are in different countries, they may each settle with the interchange in their local country with the interchange moveing funds cross-boarder between its own settlement accounts. This cross-border settlement is achieved through a network operation of the global settlement accounts of the interchange.

When the card has been in use for sometime, funds will begin to deplete as transactions take place. The account will therefore need loading. This can be done using various approaches, including for example using cash, using a bank transfer or by making a debit or credit card transaction online. For cash-loading, a POS terminal 22 can be used to identify the cardholder's account either by reading a magstripe or embedded microchip on the user token 41, or by receiving a permanent account number (PAN) entered by the cardholder.

If the account is loaded using home currency, the funds can either enter the home currency balance or they can be converted into a foreign currency of the cardholder's choosing. If the cardholder wants to load a currency that has not been loaded before, this will establish in the account a new balance in that chosen currency. A currency balance can be established in any currency supported by the multicurrency account. As usual, currency exchange involves interacting with the card issuer's internal exchange accounts, and consequently it is the card issuer that sets the exchange rate at the point of load. As different currencies are loaded, the net balance is always shown in the home currency.

An embodiment of a method by which a third party can provide funds to establish a multicurrency account, and hence a user token, with additional funds will now be described with reference to Figures Band 9A through SD.

In this further aspect, a transaction system as described above can be used to provide funds from a sending party to a beneficiary. In this approach, the sending party provides funds which are used to set up and load a multicurrency account for the beneficiary, and the beneficiary is given a card associated with the account. The beneficiary can use the card for typical transactions, including requesting a cash advance at an ATM and purchasing items at a PUS terminal.

The overall process is as indicated in Figure 8: a currency balance is established and an authorisation code provided (step 610) and this authorisation code is provided to the receiving party (step 620)-this code is provided to a user token provider (step 640) and the user token is provided (step 660). Further details are as set out in Figures 9A to 9D, which indicate the steps taken by each separate actor. The steps taken by the sender are shown in Figure 9A, those taken by the receiver of the funds in Figure 9B, those taken at the PUS terminal in Figure 90, and those taken at the interchange or relevant host financial institution in Figure SD.

In order to set up an account for the beneficiary, funds are made ready for transfer from the sending party (typically by debiting an existing sending party account) to the interchange 3 or to a host providing accounts supported by the interchange, where a new account is established. The sending party inputs data specifying the amount of funds to be transferred and further information needed for the transfer is either input or created. The beneficiary details (name and address) and possibly also an identification of the sender may be provided -in some countries, some or all of this information may be required for KYC purposes. In one arrangement, two codes are assigned to the transaction -an identification number consisting of a Bank Identification Number (BIN) and a random number generated by the relevant host system, and a collection code determined by or under the control of the sending party. When the interchange has received the funds (step 611) and deducted any fees and costs, the remainder is loaded onto the account to establish a currency balance in a first currency in the account (step 612).

The beneficiary collects the funds by receiving a card associated with the new account. This card can be provided at a card provider with a stock of "blank" cards for initialising -while this could be a bank, it may also be a suitably accredited merchant, as card initialisation can be carried out using a PUS machine. For secure provision of the card, one or more authorisation codes are generated and provided to the sending party (step 613), who then forwards the code to the beneficiary (step 620). The beneficiary then presents this code to the card provider (step 640) and the code can be used to initiate a blank card so that it is associated with the new account. This blank card will contain a memory and (in embodiments which require this) application software to enable it to perform card functions -initialisation is required to associate the card with a particular account.

When the beneficiary arrives at a card provider with the authorisation code, the card provider inserts a blank card into the P08 terminal and the authorisation code is entered manually using a user input pad of the POS terminal. The authorisation code is communicated from the P05 terminal to the interchange, where the code is matched to the beneficiary's account (step 642) and an initiation message is sent to the P08 terminal. If beneficiary identification is required, details may be sent back to the host used by the sending party, which may reject account initiation if details provided are insufficient. Data based on this initiation message is loaded onto the card -at this point, funds are transferred from the sending party host and are made available to the card (step 644). At this point, if the first currency is not one of the currencies of the country in which the beneficiary is collecting the card, the multicurrency account will have balances in two currencies: the first currency or sending currency', and the receiving currency. This completes the transaction and the card provider removes the card from the P08 terminal and provides it to the beneficiary (step 660). The beneficiary may also need to create security details (such as a PIN) for use of the card -an initial PIN may be provided with the blank card, which may then be changed by the user through a P05 terminal or an ATM using conventional processes for changing credit card or debit card PINs.

Alternative ways of transferring cash are available, such as card to card transfers. Where details of a recipient card are known, a sending party may direct a particular balance in a particular currency (or collection of currencies) to be sent to a particular card account.

In the embodiments described above, the process of authorising a transaction is carried out on-line. In a further aspect, embodiments of the invention are provided which support off-line transactions. This is particularly useful in the context of a multicurrency card, which will typically be used across a range of countries, some of which may have an unreliable or intermittent communications infrastructure. 0ff-line transactions are useful in rural areas or other contexts such as at sea or in flight where connectivity can be an issue. Aspects of the invention provide a card which can be loaded with funds for off-line payments. Since it is the card rather than the account that is loaded with funds, the card effectively plays a role similar to that of cash, and the card can be considered as equivalent to an electronic "purse" or "wallet".

A card suitable for use as a user token in this arrangement is shown in Figures 10 and 13.

The card holds in its memory 812 an electronic purse application, or other means of storing an amount of funds that have been loaded onto the card and can be used for off-line transactions. The application is run by a processor 814 operable when power is supplied to the card (for example, by electrical connection or inductively). In embodiments, the electronic purse application is held together with cardholder data in the memory 812 of an embedded chip of an integrated circuit card (or chip card') according to the Europay, MasterCard and VISA (EMV) global standard. The memory 812 of the card holds a balance in each of the currencies loaded into the electronic purse. This balance will have been transferred out of the user's regular account into the electronic purse application -such balances are now physically associated with the card and can be treated effectively as cash (so if the card is lost, funds held in the electronic purse application are also lost).

Various other details associated with off-line functionality may be stored on the card. These may include, for example, upper limits beyond which the card cannot be preloaded and information for know your customer (KYC) checks or other ways to provide some reassurance to a merchant that the card is used legitimately. Upper limits for loading are desirable for off-line cards since, like cash, if they are lost the funds loaded onto them are also lost. Since it is not possible in off-line activities to verify the identity and acceptability of a customer by contacting their bank or other account providing institution, it can be advantageous to store readable data to allow the merchant to establish some level of trust directly.

The card is set up to interact locally with POS terminals, ATM terminals and other devices having appropriate card reading facilities. Devices provided with a chip reader interrogate the chip according to a communication protocol for carrying out transactions including payments, loading funds and loading refunds.

A merchant card is also provided, as shown in Figures 11 and 14, and has similar functionality to that of the user card, but is used for off-line payment receipt, off-line refund provision, and other off-line activities. Like the user card, the merchant card has a memory 832 that holds at least one account having an associated currency balance and a processor 834 for running applications stored in the memory. The currency balance in the merchant card will accumulate from the various off-line transactions and can then be transferred in a reconciliation process when brought on-line (using POS terminal as shown in Figure 1).

As is shown in Figure 12, a cut-down POS terminal 820 is provided for off-line activity. It has a chip reader 821 for interacting with the user and merchant cards, and in particular for obtaining a transaction amount stored in the memory 812 of the user card and delivering itto the memory 832 of the merchant card. The cut-down POS terminal also has a memory 822 and a processor 823, but has no networking capability. A range of off-line transactions are supported by the POS terminal 820 including payment transactions and fund loading transactions.

An embodiment of a process of carrying out an off-line payment transaction will now be described with reference to Figures 15 to 18. Figure 15 shows the overall process, whereas Figures 16, 17 and 18 show the process from the perspective of the user, the merchant and the P05 machine respectively. User and merchant tokens are provided for insertion into a cut-down P05 terminal (steps 840, 841, 842 and 843) which coordinates messages between the cards to check or validate that the customer and merchant are mutually acceptable to each other (step 850). From the point of view of the merchant, these steps can a sufficient level of assurance that the user is the legitimate bearer of the user token. If the parties are mutually acceptable, the POS terminal 820 provides a validation response (steps 850, 851 and 852) to confirm that validation has been completed successfully.

The merchant provides a transaction amount to the cut-down P05 terminal (step 862) by scanning a product barcode, entering a product code using an input keypad or similar methods. The customer confirms that the transaction amount can be deducted from their card by providing user input (steps 861 and 864), for example using a keypad on the cut-down P05 terminal with yes and no' or confirm' and decline inputs, and the P05 terminal transfers the transaction amount from a currency balance held on the user card to a currency balance held of the merchant card (step 860). The P03 terminal then provides confirmation that the transaction has been completed (steps 865, 867, 869) and the user card is returned to the customer (steps 866 and 868).

The merchant can carry out a number of off-line transactions with customers and each time a new transaction is processed the data relating to it will be stored on the merchant's card. As more transactions are carried out, the need to synchronise these transactions with the merchant's bank account increases. This is achieved by on-line activities to reconcile the merchant's card with an account providing institution.

Subsequent reconciliation is not necessary for customers, unless they wish to transfer the "cash" held in their electronic purse application back into their account.

The overall reconciliation process is shown in Figure 19, using a connected P03 of the type shown in Figure 1. The merchant's perspective is shown in Figure 20, the perspective of the P08 in Figure 21, and the perspective of the host in Figure 22. In order to reconcile a merchant card with an associated bank account the merchant inserts his card into the P03 terminal and the terminal establishes a connection to the relevant host (steps 872, 878, 884).

This should be done at reasonably regular intervals so that funds building up on the card can be deposited into a bank account.

With the card in the connected P08 terminal, the merchant provides user input to request reconciliation (step 880) and the P03 terminal sends a reconciliation request to the account providing institution (steps 874 and 886). In embodiments, the request message includes details identifying the merchant card so that it can be matched to the associated account, and in embodiments includes details identifying the associated account itself. The balance on the card is also included in the request message so that the correct amount can be uploaded.

Upon receipt of the reconciliation request, the host performs various checks and confirms that the balance amount can be received for the merchant's account (steps 894 and 887). The balance amount can then be sent to the host (steps 876 and 888) and upon receipt (step 896) the host confirms that reconciliation is complete (steps 898, 890 and 882).

In embodiments, there is a maximum number of off-line payments a merchant can receive before his or her card must be reconciled with the host. In this case, the merchant card counts the number of off-line transactions that have taken place since the last reconciliation and at least one of the merchant card and cut-down POS has functionality to refuse further off-line payments before reconciliation. In embodiments, similar restrictions apply to the total balance that can be stored on a merchant card.

Claims (1)

1. <claim-text>CLAIMS1. A method of conducting a transaction, comprising: providing a user token, associated with a user account having a plurality of currency balances in different currencies, to a merchant; requesting authorisation of a transaction to debit a transaction amount from one of the currency balances in the account; providing authorisation for the transaction only if a cumulative currency balance in the account exceeds the transaction amount by a predetermined amount, where the cumulative currency balance is determined by summing the currency balances in the different currencies in the user account and any credit limit for the user account; and completing the transaction only if authorisation is provided.</claim-text> <claim-text>2. A method as claimed in claim 1, wherein the credit limit for the user account is zero.</claim-text> <claim-text>3. A method as claimed in claim 1 or claim 2, wherein the user token is a banking card, and the steps of requesting authorisation and completing the transaction are carried out using a point of sale terminal.</claim-text> <claim-text>4. A method as claimed in any preceding claim, wherein the steps of requesting and providing authorisation comprise requesting and providing authorisation through an interchange switch when the user token and the merchant are not associated with a same financial institution.</claim-text> <claim-text>5. A method for a user to conduct a transaction with a merchant, comprising: providing a user token, associated with a user account having a plurality of currency balances in different currencies, to a merchant; requesting authorisation of a transaction to debit a transaction amount from one of the currency balances in the account; receiving authorisation for the transaction only if a cumulative currency balance in the account exceeds the transaction amount by a predetermined amount, where the cumulative currency balance is determined by summing the currency balances in the different currencies in the user account and any credit limit for the user account; and being permitted to complete the transaction only if authorisation is provided.</claim-text> <claim-text>6. A method of conducting a transaction at a point of sale terminal of a merchant, comprising: receiving a user token, associated with a user account having a plurality of currency balances in different currencies; requesting authorisation of a transaction to debit a transaction amount from one of the currency balances in the account; receiving authorisation for the transaction only if a cumulative currency balance in the account exceeds the transaction amount by a predetermined amount, where the cumulative currency balance is determined by summing the currency balances in the different currencies in the user account and any credit limit for the user account; and completing the transaction only if authorisation is provided.</claim-text> <claim-text>7. A method of providing a transaction authorisation response, comprising: receiving an authorisation request for a transaction to debit a transaction amount from a currency balance of an account having a plurality of currency balances in different currencies; providing authorisation for the transaction only if a cumulative currency balance in the account exceeds the transaction amount by a predetermined amount, where the cumulative currency balance is determined by summing the currency balances in the different currencies in the user account and any credit limit for the user account.</claim-text> <claim-text>8. A system for conducting transactions from a user account in a plurality of currencies, comprising: means for holding a user account having a plurality of currency balances in different currencies; a user token associated with the user account for presenting to a merchant; and point of sale apparatus for receiving the user token and for requesting authorisation for a transaction in one of the currencies in the user account, and for completing the transaction if authorisation is received; wherein the means for holding the user account is adapted to authorise the transaction only if a cumulative currency balance in the account exceeds the transaction amount by a predetermined amount, where the cumulative currency balance is determined by summing the currency balances in the different currencies in the user account and any credit limit for the user account.</claim-text> <claim-text>9. A system as claimed in claim 8, wherein the means for holding a user account is a computer system associated with a financial institution.</claim-text> <claim-text>10. A system as claimed in claim 8 or claim 9, wherein the user token comprises a banking card.ii. A user token for use in a system for conducting transactions from a user account in a plurality of currencies, the user token comprising: a memory comprising an identification of the user account and authentication information to link the user account with a user, wherein the user token is adapted for use in the method of any of claims ito 6.12. A user token as claimed in claim ii wherein the user token is a banking card.13. A point of sale apparatus for use in a system for conducting transactions from a user account in a plurality of currencies, the point of sale apparatus comprising a user token reading means, a user interface, and a communication means for communicating with a remote server adapted to provide authorisation information, wherein the point of sale apparatus is adapted for use in the method of any of claims ito 6.14. A method of providing funds from a sending party to a receiving party, comprising: the sending party establishing a currency balance in a first currency in a user account and obtaining an authorisation code; the sending party providing the authorisation code to the receiving party; the receiving party providing the authorisation code to a user token provider; and the user token provider providing the receiving party with a user token associated with the user account, whereby upon provision of the user token the user account has currency balances in the first currency and a second currency associated with the user token provider.15. A method as claim 14, wherein the currency balance is established with a first financial institution and the user token provider is associated with a second financial institution.16. A method of receiving funds from a sending party, comprising: receiving an authorisation code from the sending party associated with a user account having a currency balance in a first currency; providing the authorisation code to a user token provider; receiving a user token associated with the user account, whereby upon receipt of the user token the user account has currency balances in the first currency and a second currency associated with the user token provider.17. A method of sending funds to a receiving party, comprising: establishing a currency balance in a first currency in a user account; obtaining an authorisation code for enabling the receiving party to obtain a user token associated with the user account from a user token provider, whereby upon receipt of the user token the user account has currency balances in the first currency and a second currency associated with the user token provider; providing the authorisation code to the receiving party.18. A method of delivering funds from a sending party to a receiving party, comprising: receiving an authorisation code from the receiving party for matching to a user account having a currency balance in a first currency; providing the authorisation code to an account provider to obtain account details to be associated with a user token creating and providing the receiving party with a user token associated with the user account, whereby upon provision of the user token the user account has currency balances in the first currency and a second currency associated with the delivery of the funds.19. A method of providing funds from a sending party to a receiving party, comprising: receiving funds from the sending party; establishing a currency balance representing the funds in a first currency in a user account; providing an authorisation code associated with the user account to the sending party; receiving the authorisation code from a user token provider and matching the authorisation code to the user account; providing account details to the user token provider to allow creation and provision of a user token associated with the user account to the receiving party, whereby upon receipt of the user token the user account has balances in the first currency and a second currency associated with the user token provider.20. A method of conducting a transaction without direct external authorisation, comprising: providing a merchant token and a customer token to a point of sale device; establishing to each other the validity of the merchant token and the customer token through the point of sale device; completing the transaction by transferring a transaction amount from a currency balance held on the customer token to a currency balance held on the merchant token; whereby one or more of the merchant token, the customer token and the point of sale device is subsequently connected to an account providing institution to reconcile the transaction against a customer account associated with the customer token and a merchant account associated with the merchant token.21. A method as claimed in claim 20, wherein the customer token is adapted to hold currency balances in a plurality of currencies.22. A method for a customer to conduct a transaction without direct external authorisation, the method comprising: providing a customer token to a point of sale device also provided with a merchant token; establishing the validity of the merchant token and demonstrating the validity of the customer token to the merchant token; and completing the transaction by transferring a transaction amount from a currency balance held on the customer token to a currency balance held on the merchant token.23. A method as claimed in claim 22, wherein the customer token is adapted to hold currency balances in a plurality of currencies.24. A method for a merchant to conduct a transaction with a customer without direct external authorisation, the method comprising: providing a merchant token to a point of sale device also provided with a customer token; establishing the validity of the customer token and demonstrating the validity of the merchant token to the customer token; and completing the transaction by receiving a transaction amount from a currency balance held on the customer token to increment a currency balance held on the merchant token.25. A customer token for conducting offline transactions, comprising: a processor and a memory, wherein the memory contains account identification information, customer authorisation information and a transferable account balance associated with the identified account, and wherein the memory further comprises an account management application adapted to run on the processor, wherein the customer token is adapted to execute the account management application when in connection with a point of sale terminal, whereby on customer authorisation using the customer authorisation information the customer token is adapted to debit the transferable account balance held in the memory to transfer funds to another account associated with the point of sale terminal.26. A customer token as claimed in claim 25, wherein the memory holds a plurality of transferable account balances in a plurality of currencies.27. A merchant token for conducting offline transactions, comprising: a processor and a memory, wherein the memory contains account identification information, and an account balance associated with the identified account, and wherein the memory further comprises an account management application adapted to run on the processor, wherein the merchant token is adapted to execute the account management application when in connection with a point of sale terminal when the point of sale terminal is also in connection with a customer token, whereby on customer authorisation to debit an account balance on the customer token by a transfer amount, the account management application is adapted to credit the account balance of the merchant token by the transfer amount.28. A merchant token according to claim 27, wherein the merchant token is adapted to reconcile the account balance directly with an account provider when a transaction threshold has been reached.29. A merchant token as claimed in claim 28, wherein the transaction threshold comprises a predetermined number of transactions.30. A smart card comprising a customer token according to claim 25 or claim 26 or a merchant token comprising any of claims 27 to 29.31. A point of sale terminal adapted for offline transactions between two smart cards, the point of sale terminal comprising: a memory storing a transaction application and a processor adapted to run a transaction application; a user interface; a first interface for a customer token and a second interface for a merchant token; wherein on activation of the transaction application, the point of sale terminal is adapted to cooperate with a customer token and a merchant token to transfer a transfer amount from a transferable account balance held on the customer token to an account balance held on the merchant token.32. A point of sale terminal as claimed in claim 31, wherein the point of sale terminal further comprises a telecommunications interface, and wherein the point of sale terminal is adapted to communicate with an account provider associated with a merchant token to enable reconciliation of a merchant account with the merchant token.33. A point of sale terminal as claimed in claim 31 or claim 32, wherein the first and second interfaces are smart card interfaces.34. A process for reconciliation of an account between a token used for otfline transactions and a financial institution, comprising: performing one or more offline transactions using the token, and recording offline transaction details on the token; establishing communication between the token and a server of a financial institution; and reconciling the account at the financial institution by updating the account with the stored offline transactions.35. A process as claimed in claim 34 wherein if the offline transactions exceed a predetermined threshold, the step of reconciling the account is required to take place before further offline transactions can be made.36. A process as claimed in claim 34 or claim 35, wherein the token is a merchant token, and the offline transactions comprise one or more transactions made offline with a customer token through a point of sale terminal.</claim-text>