WO2007145500A1

WO2007145500A1 - Transaction server

Info

Publication number: WO2007145500A1
Application number: PCT/MY2007/000038
Authority: WO
Inventors: Jin Feei Jeffrey Loh; Eng Sia Lee
Original assignee: Mobile Money International Sdn Bhd
Priority date: 2006-06-12
Filing date: 2007-06-11
Publication date: 2007-12-21
Also published as: MY149658A; CN101536048A

Abstract

A transaction server is disclosed that has a receiver module configured to receive an instruction message from a first mobile communications device for a transaction from a first account to a second account. The transaction server also has a transmission modul configured to send a response message to the first mobile communications device a request for a validation instruction for the transaction, the response message being in response to the receipt of the instruction message. The server is configured to record receipt of the validation instruction. The server is also configured to record receipt of the validation instruction. In response to the validation instruction, the server validates and effects the transaction. A corresponding method is also disclosed.

Description

TRANSACTION SERVER

Technical Field

The invention relates to a transaction server for effecting transactions from a user account. More particularly, the invention relates to validating transactions from the user account.

Background

Systems for implementing mobile phone based payments where, essentially, a mobile telephone acts as an electronic wallet (e- wallet) are known. In such systems, a monetary value is held in an e-wallet for each user, and the details of each e-wallet are stored centrally in a server database.

With a mobile telephone, transactions may be conveniently and commonly effected using a messaging service such as SMS. For example, to send $20 from a first e-wallet identified or associated with a first mobile phone +60122070239 to a second e-wallet identified with a second mobile phone +60164452228, the following SMS is sent:

PAY 0164452228 20 753535

As can be seen, the text string of the message comprises several fields: "0164452228" is the recipient mobile telephone's number; "20" is the transfer amount (e.g. $20); and 753535 is a six-digit PIN associated with the user and/or the e-wallet +60122070239. The server receives this SMS through a telecommunication link to an SMS centre or portal.

Such a system is attractive because it facilitates money movement. It means practically anyone, anytime, anywhere can be paid. For example, to pay a friend several miles away all a user need do is to use their mobile telephone to send a simple SMS to the SMS portal to effect payment from the e-wallet or account. Unfortunately, such a system has several drawbacks which, if not properly addressed, can adversely affect its implementation and security.

Messaging services such as SMS as a means of communication are never 100% reliable. A sender of an SMS never knows for certain if the message will be delivered or when. Sometimes an SMS is delivered to the same recipient multiple times. These failings of SMS are particularly problematic for e- wallet transactions. For example, a user may be at a shop and use their mobile telephone to send an SMS to the server's SMS portal requesting payment for goods to the shop owner's account. However, it is possible that the mobile telephone may not receive acknowledgement from the server that the payment request has been either received, or that payment has been initiated. Such situations can arise during a period of peak use of the SMS system or, simply, the SMS is "dropped" by the messaging service. In such situations, the user is presented with a quandary. What should the user do? Should the user just leave? Should the user send another payment request? The server might receive the user's first SMS and effect the transaction the moment after a second instruction SMS is sent, or the user gives up and leaves the shop. Alternatively, the server might receive several copies of the single SMS and the server effects multiple payments to the shop owner for a single transaction. The user is unlikely to be able to receive any real help from the help centre for the server as the call centre may advise the user that the SMS has not arrived yet and that no transaction has been effected so far. Conceivably, the SMS could arrive at the server the very moment the user terminates the telephone call with the call centre.

Another problem is human error. Inevitably, users will key in a wrong recipient's mobile number or incorrect transaction amount in the SMS. The user may call the call centre to request a reversal. In cases like these, security for the recipient could be compromised - e.g. the recipient is a shop owner who has provided goods or services in good faith to an e-wallet user. Should the call centre do the reversal? The user may have just bought something from the shop owner and requested a reversal the moment after the goods were collected or the user has left the shop. Security is another problem. It is a well-known fact that SMS can be spoofed quite easily. If a fraudster somehow manages to obtain a person's PIN, the fraudster can spoof an SMS message to the server to instruct a transaction quite easily.

Summary

The invention is defined in the independent claims. Some optional features of the invention are defined in the dependent claims.

If the transaction instruction (e.g. SMS from the user to the server) is delayed or not delivered, the user knows very well no transaction has been effected from his account (e-wallet) as the user is neither requested to provide the validation instruction and, therefore, it is not possible for the user to provide the validation instruction. If the user receives a request for the validation instruction from the server at a later time seeking validation for the transaction, the user then has the option to proceed with the validation instruction for the transaction or to decline to send the validation instruction. In the event the server receives multiple copies of the transaction instruction (e.g. SMS), the server may be configured also to send multiple requests for validation in the form of SMS messages to the user seeking confirmation and the user can choose how many of these requests for a validation instruction he/she can reply to, if any. In embodiments of the invention, each request for validation provides different instructions for effecting the validation instruction (e.g. different telephone numbers are provided for the user to call to validate the transaction). The user may then selectively choose whether and how many times the recipient in the transaction is to be paid. Optionally, additional information such as the account (e-wallet) balance and details of previous transactions are included in the request for the validation instruction.

Further, the likelihood of user error is now significantly reduced. In embodiments of the server, the server is configured to look up the recipient's name from a server database, and to transmit the requested recipient's details to the user with the request for the validation instruction to the user. Optionally, the transaction amount is also shown. Yet further, the server provides enhanced security and fraudsters may find it more difficult to spoof the server. The server may selectively choose the means by which the user is to request validation of the transaction; e.g. in embodiments of the invention, a telephone number for the user to call or message to is randomly picked from hundreds of numbers; the user may be requested to enter a URL on the user's internet browser to request validation, or any of many other possible ways in which a communication can be effected. Thus, the fraudster will not know the number to call to confirm a transaction, or the URL to visit. This means the fraudster must intercept the request for validation of the transaction sent by the server and at the same time spoof a user ID.

Brief Description of the Drawings

Exemplary embodiments will now be described, by way of example only, and with reference to the accompanying drawings. In the drawings:

Fig. 1 is a block diagram illustrating implementation of an exemplary; Fig. 2 is a flow diagram illustrating the process of the implementation of an exemplary embodiment;

Fig. 3 illustrates the process of an exemplary embodiment; and Fig. 4 illustrates a schematic view of the basic structure of an e-wallet system.

Detailed Description of the Exemplary Embodiments

Implementation of a transaction with a transaction server is illustrated in Figure 1. The system 10 comprises a transaction server 12, a first e-wallet 14 representing/being associated with a first account, and a second e-wallet 16 representing/being associated with a second account. The first e-wallet 14 is associated with the mobile communication device 18 and in particular with the owner of mobile communications device 18. Association with the device 18 is represented by the dashed line 14 A. Association of second e-wallet 16 with the second mobile communication device 20 is represented by the dashed line 16 A. Mobile communications devices 18, 20 may be a mobile telephone, portable telephone, cellular telephone, PDA, a device such as a "Blackberry", or telecommunications-enabled portable computer such as a laptop computer, notebook computer, tablet computer, and so forth. To effect a transaction, the second communication device 20 is used to send a message 22 via a messaging service - e.g. SMS, MMS or email - to a receiving module such as, for example, the SMS portal 13 of server 12. The intended transaction is for the transfer of a sum of money to the e-wallet 14 of the first user being the user of communication device 18. The message 22 takes the form of:

PAY 0164452228 20 753535

As discussed above, the first field is the instruction "PAY", second field in the transaction instruction is an identifier for the recipient account preferably being the telephone number of first communication device 18; third field "20" is the value of the transaction; and the fourth field 753535 is an authentication code for the transaction, for example, a PIN of the second communication device 20 or a specific authentication code for the transaction. This provides a first level of security for the transaction. Responsive to receiving the instruction 22 from the device 20, the server 12 first matches the authentication code of the fourth field with the stored authentication code (extracted from the server 12 by, for example, recognition of the telephone number of the communication device 20 and using a look-up table to find the authentication code) and a transmission module 11 of the server sends to the device 20 a request 24 for the transmission of a validation instruction for the transaction. In embodiments of the server 12, this request may also be sent via a messaging service. Should the second user at device 20 wish for the transaction to be processed, the device 20 is then used to send a validation instruction 26 to the receiving module 13 of server 12. The server 12 records receipt of the validation instruction 26 and, responsive to this, the server 12 validates the transaction. Embodiments of the server then effect the transaction 28 of (in this example) $20 from second e-wallet 16 to first e-wallet 14.

Embodiments of the server 12 allow for the communication device 20 to be used to make a telephone call to a communications module 15 of the server 12 (or another communications portal) to provide the validation instruction. The request for the transmission of a validation instruction may, in embodiments of the server 12, provide details of the telephone number at server 12 to be called. Embodiments of the server 12 are configured only to allow receipt of reliable means of communication for the request for validation: e.g. a telephone call, a message sent through GPRS (General Packet Radio Services) or through a secure (e.g. encrypted) internet communication.

It will be appreciated that one or more of the communications portals 11, 13, 15 may be distinct from server 12, may be used to send and receive communications from the devices 18, 20. In such embodiments of the server 12, the server 12 is configured to initiate and control sending and receipt of these instructions, so that a transaction may be effected from an account/e-wallet 16.

It will be further appreciated that embodiments of the server 12 allow for the e- wallets 14, 16 to be integral with the server 12.

In embodiments of the server 12, the server 12 is configured to validate the transaction if receipt of the validation instruction is recorded by the server 12 within a predetermined period from sending, to the communication device 20, the request 24 for the transmission by device 20 of a validation instruction. If the receipt of the validation instruction 26 is not recorded by the server 12 within that pre-determined time period, the transaction may be voided.

After the server 12 receives a transaction request 22 (say at 5: 15pm 24th May) from the device 20, the server 12 forwards to the device 20 the following SMS message, seeking confirmation:

Please confirm $20 transfer to 0164452228 (Lee Eng Sia) by calling 0320540301. This message expires 5:25pm 24/05.

Thus, the request for the validation instruction confirms the identifier for the recipient account for the transaction. By doing so, the risk of human error in instructing a transaction to a wrong account may be reduced. In exemplary embodiments of the server 12, the server 12 invites a telephone call to be made from communications device 20 to a telephone number (0320540301 above) to provide the validation instruction 26. In exemplary embodiments, the server 12 employs a pool of several hundreds (or even thousands) of telephone numbers, and 0320540301 is selected from this pool. Exemplary embodiments of the server 12 are configured to select a different telephone number for different transactions. The selection may be random, or organised.

Exemplary embodiments of the server 12 allow for the telephone number to be called by device 20. It is not necessary for the telephone call to be connected; the server need only capture the caller identifier from the telephone call. Either the call may be disengaged the call after, say, two or three rings, or the server is configured to disengage the call once an DD of device 20 has been extracted from the call. From this, the ID may be determined, providing further enhanced security for the transaction. Thus, there is no requirement for incurring unnecessary cost in actually connecting the telephone call to provide the validation instruction.

Thus, in exemplary embodiments of the server 12, the transaction will only be effected by the server 12 if the call 26 from the second mobile communications device 20 is received before 5:25pm on 24th May. This gives a window of 10 minutes to instruct validation of the transaction and, thereby, to confirm payment.

If the sender makes a (missed) call to 0320540301 before the expiry time, the transaction proceeds and both the devices 18, 20 of the sender and the recipient are notified accordingly. Exemplary embodiments of the server 12 allow for this to made via a messaging service — e.g. SMS, MMS or equivalent - and, in the event of messaging service notification failure, a call can be made into a helpline IVR (Interactive Voice Response, not shown) where confirmation of the validation of the transaction is made by providing the last transaction from the e-wallet. Optionally, a call centre can easily handle such enquiries either by receiving a call from or placing a call to one or both of the communication devices 18, 20. Thus, exemplary embodiments of the server may alleviate the problems associated with prior art e-wallet payment systems.

It will be appreciated that variations on this implementation for a transaction may be effected. For instance, the communications device 18 may be requested to transmit a validation instruction and/or receive confirmation of the payment. Communication with one or other of the devices 18, 20 may be over the Internet or, via GPRS, either of which are relatively reliable forms of communication. When the device 18 must send the validation instruction, further layers of security might be implemented to avoid situations where a device that erroneously receives the request for validation (i.e. the sender keys in a wrong number) can validate the transaction and receive payment. For example, the device 18 may be required to obtain a further authorisation code or the like from the device 20. The validation instruction may be required to include, for example, a PIN. Further security can be implemented in many ways.

Figure 2 illustrates the process flow for a transaction validated by the transaction server 12 of Figure 1.

The process starts at 50. At 52, a transaction instruction 22 is sent to the receiving module 13 of server 12 by SMS. At 54, this instruction 22 is received at the server 12 and, responsive to this, the transmission module 11 of server 12 sends a request 24 for a validation instruction 56. At 58, the server 12 waits for the validation instruction 26. If this is not received, the process may end simply at 66 or the process loops around waiting for the validation instruction 26 as indicated by dashed line 60. When/if it is determined at 58 that the validation instruction 26 is received at receiving module 13, the transaction is validated at 62 and, optionally, the server may effect the transaction at 64. The process ends at 66. As a further option, one or both of the communication devices 18, 20 are sent a confirmation message to confirm that the transaction has been validated and/or effected. Alternatively, the server can call either or both the devices 18, 20 to announce the transaction validation. To save unnecessary costs, the server 12 is optionally configured to disengage (hang up) the call even before the call is answered - a missed call in reverse. But it serves a simple purpose of letting the sender know the transaction has been validated and/or effected successfully.

In all SMS messages from the server to the devices 18, 20, additional information such as the e-wallet balance, and/or details of previous transactions, may be included.

The owner of the device with the telephone number 0164452228 may not have an authorised account. That is, the user of device 18 is not an existing e-wallet user. Thus, a new account needs to be created for the telephone number 0164452228. Indeed, this mobile number may not be valid because of human input error. In cases like this, the server 12 is configured to request that the (missed) call is made by the communication device 18, instead of the communication device 20. This ensures the mobile number 0164452228 is not keyed in wrongly by the sender for the message sent by SMS. The request for a validation instruction - e.g. an SMS seeking confirmation from the payer - would thus take the form:

Please confirm $20 transfer to 0164452228 (NEW USER) by asking 0164452228 to missed call 0320540322. This message expires 5:25pm 24/05.

The transaction is validated once the server receives a call from 0164452228 to 0325040322. Alternatively, the server 12 is configured for either the sender (payer) or the recipient (payee) to call the telephone number to validate the transaction - irrespective of whether the recipient is a new user or not.

This is an advantageous design feature and may be provided independently as will be discussed below.

Some mobile telephones have their caller ID barred or disabled. Thus, the server 12 is unable to capture the caller ID when such users place a call to provide the validation instruction. To overcome this, and for the creation of each new e-wallet, the number to call for the validation instruction (0320540322 in the above example) is allocated from a special pool of pre-determined telephone numbers and the server is configured to activate only one number at any one time for one transaction. So when a call without caller ID is received by the server at 0320540322, the server is configured to recognise that this is a validation instruction for a particular transaction, and the fact that the new user (caller) has caller ID feature disabled in his phone is immaterial. Therefore, if the caller mobile has no caller-ID, then the transaction server can still validate one particular transaction based solely on the telephone number called. Generally, if caller- ID is available for caller identification, a single telephone number for validation can be used for validation of simultaneous/multiple transactions.

Further, embodiments of the server 12 are configured to effect all future transactions for this user in the same or similar way. Effectively, the server is configured to identify a category for this transaction in this way. That is, the server identifies that the category of the transaction is such that it is for payment to a particular recipient who does not have an authorised account.

This feature may also be particularly effective for, say, catalogue shopping. For a payer to make a payment to purchase an item from a catalogue, the payer is invited to call a particular number to purchase the item. By the very action of calling that number, the server identifies the category of the transaction (e.g. it is a purchase of a particular goods) and processes the transaction accordingly.

The server may also be configured to validate transactions for catalogue sales where each item in the catalogue is tagged with a product code. When a customer wants to purchase a product, they can enter a message into their mobile device for the device to send an SMS. The message contains the relevant product code. Once the server has received the SMS, a call must be made to confirm the purchase. Similarly, the same principle can be used for soft goods or services such as discounted call airtime, mobile phone airtime top-ups, and so forth.

The method described in the first embodiment above is particularly useful for paying merchants where the sender must know with certainty whether a transaction has been effected. In certain less formal situations, a quicker payment method is often desirable; for example, when a user wishes to transfer money to, say, the user's sister. However, even in these situations, it is important that a method is in place to ensure the money transfer is not done wrongly.

In a second embodiment, a missed call mechanism is used to build a so-called "buddy list" for each user of e-wallet.

As before an SMS message is sent to the server requesting money transfer:

SEND 0164452228 20 753535

To initiate such transactions, a different instruction or keyword "SEND" is used to differentiate this from the example in the first embodiment although it will be appreciated that the first field of the transaction request may take a number of different forms.

To prevent the sender incorrectly entering the recipient's number (0164452228), the server checks to determine if 0164452228 is an authorised account. In embodiments of the server, a list of authorised accounts is maintained as a "buddy list". If indeed

0164452228 exists in this list, the $20 is transferred to the e-wallet of 0164452228. No further validation may be required. Thus, upon receipt of a transaction instruction for a transaction to an account for a recipient, responsive to determining that the account for the recipient is an authorised account, the server 12 automatically validates the transaction.

In situations where the recipient account is not an authorised account, once a validation instruction 26 for the transaction to the unauthorised account is received, the server is configured to flag the recipient account as an authorised account.

However if this is not the case, the server 12 sends a message to the payer: 0164452228 is not in your buddy list. To add 0164452228 to your buddy list, please ask 0164452228 to call 0320540202.

Once 0164452228 makes a (missed) call to 0320540202, the server 12 is configured to flag 0164452228 as being an authorised account for that payer; that is the recipient is added to the payer's "buddy list". The server also effects the transfer from e-wallet 16 to e-wallet 14 once the missed call is received.

Alternatively, the sender can also request 0164452228 to make a (missed) call to 0320540202 even before the sender sends his SMS, assuming 0320540202 has been advertised to him for this purpose. In such a case, the server 12 need not send the above SMS to the sender. Straightaway, 0164452228 shall be added to the sender's buddy list and the transfer can be made.

Embodiments of the server are configured to receive an instruction from a user to add a recipient account as an authorised account. This is particularly helpful in situations where the recipient 0164452228 has caller E) barred, the payer can still add 0164452228 to his buddy list by sending the following SMS to the server:

BUDDY 0164452228

When a recipient account is an authorised account for one user, embodiments of the server are configured to flag an account associated with the user as an authorised account for a recipient with whom the recipient account is associated. That is, the buddy list can be mutual; if user A is in user B's buddy list, then the server is configured to add user B to user A's buddy list automatically.

The process of the second embodiment is described with reference to Figure 3. The process starts at 100. At 102 communications device 20 sends a request for a transaction to a recipient (user at device 18) account. The server 12 determines whether the recipient account is an authorised account at 104 and upon determination the recipient account is authorised, the transaction is validated and, optionally, effected at 112. If determined at 104 that the recipient account is not an authorised account, the server 12 sends a request for a validation request. When this validation request has been received 108, the transaction is validated at step 112, subject to the transaction request meeting any requirements for validation. The process may loop around 108 with loop 110 while waiting for the validation transaction.

Optionally, when the transaction to the new (previously unauthorised) recipient account has been validated, the new account is flagged as an authorised account.

Embodiments of the server are configured to de-authorise an authorised account within a pre-determined time period from authorisation of the authorised account. That is, an expiry date is attached to each entry in the buddy list. This means that if a payer does not send money to a recipient before the expiry date, the recipient is removed from the payer's buddy list. The expiry date is renewed every time money is transferred to the recipient.

A further embodiment of the server seeks to address the problem that users are worried their mobile communication devices might be misused when their mobile phones double as a payment instrument.

Thus, embodiments of the server are configured to record receipt of an activation telephone call from a user and, upon recording receipt of the activation telephone call, to activate or deactivate an account for the user. Thus, it is possible for a user to LOCK/UNLOCK his/her account/e-wallet by allocating one or more telephone numbers for the user to call for this purpose.

Embodiments of the server are configured to select between activation and deactivation of the account in dependence of a status of the account. For example, when a user wants to lock his mobile account, the user places a (missed) call to 0320540000. Upon receipt of another call to this number, the server 12 checks the status of the account and, in dependence of this check, toggles the account status: if currently activated, the account is de-activated and vice versa. Alternatively, the user is provided with two telephone numbers: one to lock the account and one to unlock it.

In some embodiments of the server, the server calls the user back through an IVR to prompt him to enter a PDSf or UNLOCK code.

If embodiments of the server detect a call to a wrong number 0320540002, the server is configured to disable the mobile payment account associated with that mobile phone. This is to prevent fraud. For example, the server is configured to select from a pool of hundreds or thousands of telephone numbers. For each user the server allocates a different number for LOCKING and UNLOCKING of the account. So, an unauthorized user obtaining an authorised users mobile communications device 18 would not know which number to call to UNLOCK the e-wallet account. Guessing a wrong number from the designated pool will be an indication for the server to lock the e-wallet account.

Figure 4 illustrates a schematic view of the basic structure of an e-wallet system 100 as disclosed in, for example, International Patent Publication No. WO 2006/049582 filed by the present Applicant(s) and hereby incorporated by reference as if disclosed herein in its entirety. The e-wallet system 100 has two sides: a bank sub-system 102 including a bank database 104 and an e-wallet sub-system 202 including an e-wallet database 204.

The bank database 104 has typical banking facilities, including a number of user savings and current accounts, exemplified in Figure 4 by way of a user 1 current account 106, a user 2 current account 108 and a user N-I current account 110. The bank database 102 also includes a number of user credit accounts, exemplified in Figure 4 by way of a user 1 credit account 112, a user 2 credit account 114, a user N-I credit account 116 and a user N credit account 118. The user credit accounts contain what may be described as electronic money, but which is generally referred to herein as funds. The user credit accounts may be associated with the respective user current and/or savings accounts, but need not necessarily be. In Figure 4, the user N credit^' account 118 is not associated with any other bank account. Additionally, the bank database 104 includes a consolidated e-wallet bank account 120. There is also an e-wallet sub-system credit account 122 and associated e-wallet subsystem current account 124, for the company running the e-wallet system to add money to and withdraw money from the consolidated e-wallet bank account 120. These are operable in similar ways to the user credit and current accounts.

The e-wallet database 204 has a number of user e-wallets 212, 214, 216, 218, one for each user credit account 112, 114, 116, 118 in the bank database 104. Thus, there is a user 1 e-wallet 212, a user 2 e-wallet 214, a user N-I e-wallet 216 and a user N e-wallet 218. Additionally, the e-wallet database 204 contains an escrow e-wallet 226 and a transaction charges e-wallet 228. Within the e-wallet database 204, the user N e-wallet 118 is treated no differently from the other e-wallets, even though, in the bank subsystem 102, the user N has no bank account other than the user N credit account 118.

Alternatively, in one e-wallet implementation, there is no necessity for an e-wallet account to be associated with any bank account. In this way, large sections of the population of a country who either do not have or seldom use bank accounts - low income workers, foreign workers, inhabitants of rural areas having no banking facilities etc. - may utilise the transaction system. Bank links are there to provide a convenient mechanism to top up their e-wallets. The banks can also act as intermediaries to top up e-wallets for other individuals.

The system of the present server is further enhanced where the user can easily transfer money received in the user's e-wallet to any of the user's bank accounts. Furthermore, by working with selected banks, the user can transfer money automatically from the user's existing bank accounts into the user's e-wallet. All it takes is a simple initial registration of the user's mobile phone number at ATMs of participating banks.

It will be appreciated the invention has been described by way of example only and that various departures in detailed design may be made without departing from the scope of the invention. It will be further appreciated that features presented in association with one embodiment of the invention may be provided in combination with another embodiment of the invention.

Claims

THE CLAIMS

1. A transaction server comprising: a receiver module configured to receive an instruction message from a first mobile communications device for a transaction from a first account to a second account; a transmission module configured to send a response message to the first mobile communications device a request for a validation instruction for the transaction, the response message being in response to the receipt of the instruction message; the server being configured to record receipt of the validation instruction; and the server being configured to record receipt of the validation instruction and, in response thereto, validate and effect the transaction.

2. The transaction server of claim 1, wherein the server is configured to validate and effect the transaction if receipt of the validation instruction is recorded by the server within a pre-determined period from sending the response message.

3. The transaction server of claim 1 or claim 2, wherein the server is configured to send a confirmation message to the first mobile communications device to confirm the transaction has been validated and effected.

4. The transaction server of any preceding claim, wherein the instruction message comprises at least one selected from the group consisting of: an identifier of the second account, a value for the transaction, and an authentication code for the transaction.

5. The transaction server of claim 4, wherein the response message comprises a request for a confirmation of at least one of: the identifier of the second account, and the value for the transaction.

6. The transaction server of any preceding claim, wherein the server is configured to capture an identifier of the first mobile communications device from the validation instruction.

7. The transaction server of any preceding claim, wherein the server is configured to select a telephone number from a pool of pre-determined telephone numbers; the response message comprising the telephone number.

8. The transaction server of any preceding claim, wherein the validation instruction is by a confirmation call between the first mobile communications device and a communications module of the server; the confirmation call being initiated by one of: the communications module of the server, and the first mobile communications device.

9. The transaction server as claimed in claim 8 when dependent on claim 7, wherein the confirmation call is by the first mobile communications device to the communications module using the telephone number.

10. The transaction server of claim 9, wherein the communications module is configured to disengage the confirmation call.

11. The transaction server of claim 10, wherein the communications module is configured to disengage the confirmation call after identifying the first mobile communications device.

12. The transaction server of any preceding claim, wherein the server is configured to identify a category for the transaction from the validation instruction.

13. The transaction server of any preceding claim, wherein the server is configured to determine whether the second account is an authorised account, and to send the response message responsive to a determination the second account is not an authorised account.

14. A transaction server comprising: a receiver module configured to receive an instruction message from a first mobile communications device for a transaction from a first account to a second account; the server being configured to determine whether the second account is an authorised account; and responsive to a determination that the recipient account is an authorised account, validate the transaction.

15. The transaction server of claim 13 or claim 14, wherein the transmission module is configured to send the response message to a second mobile communications device associated with the second account.

16. The transaction server of claim 15, wherein the server is configured to, upon receipt of the validation instruction from the second mobile communications device, flag the second account as an authorised account.

17. The transaction server of any preceding claim, wherein the server is configured to receive an instruction from the first mobile communications device to add the second account as an authorised account.

18. The transaction server of any preceding claim, wherein the server is configured to de-authorise an authorised account a pre-determined time after authorisation of the authorised account.

19. The transaction server of any preceding claim, wherein the server is configured to record receipt of an activation telephone call from a user to the server and, upon recording receipt of the activation telephone call, to activate or deactivate the user account.

20. A transaction server for effecting a transaction from a user account, the server being configured to record receipt of an activation telephone call from a user to the server and, upon recording receipt of the activation telephone call, to activate or deactivate the user account

21. The transaction server of claim 19 or claim 20, wherein the server is configured to select between activation and deactivation of the account in dependence of a status of the account.

22. The transaction server of any of claims 19 to 21, the server being configured to place a telephone call to the user to prompt the user to validate activation or deactivation of the account.

23. A method of validating a transaction comprising: a server receiving from a first mobile communications device an instruction message for a transaction from a first account to a second account; responsive to receipt of the instruction message, the server sending a response message to the first mobile communications device, the response message comprising a request for a validation instruction; the server receiving and recording receipt of the validation instruction; and responsive to recording receipt of the validation instruction, the server validating and effecting the transaction.

24. The method of claim 23, further comprising validating the transaction if receipt of the validation instruction is recorded within a pre-determined period from sending the response message.

25. The method of claim 23 or claim 24, further comprising sending a confirmation message to the first mobile communications device to confirm the transaction has been validated and effected.

26. The method of any one of claims 23 to 25, wherein the instruction message comprises at least one selected from the group consisting of: an identifier of the second account, a value for the transaction, and an authentication code for the transaction.

27. The method of claim 26, wherein the response message comprises a request for a confirmation of at least one of: the identifier of the second account, and the value for the transaction.

28. The method of any one of claims 23 to 27, wherein the server captures an identifier of the first mobile communications device from the validation instruction.

29. The method of any one of claims 23 to 28, wherein the server selects a telephone number from a pool of pre-determined telephone numbers; the response message comprising the telephone number.

30. The method of any one of claims 23 to 29, wherein the validation instruction is by a confirmation call between the first mobile communications device and a communications module of the server; the confirmation call being initiated by one of: the communications module of the server, and the first mobile communications device.

31. The method as claimed in claim 30 when dependent on claim 29, wherein the confirmation call is by the first mobile communications device to the communications module using the telephone number.

32. The method of claim 30 or claim 31 , wherein the communications module disengages the confirmation call.

33. The method of claim 32, wherein the communications module disengages the confirmation call after identifying the first mobile communications device.

34. The method of any one of claims 23 to 33, wherein the server identifies a category for the transaction from the validation instruction.

35. The method of any one of claims 23 to 34, wherein the server determines whether the second account is an authorised account, and sends the response message responsive to a determination the second account is not an authorised account.

36. A method comprising: a receiver module of a server receiving an instruction message from a first mobile communications device for a transaction from a first account to a second account; the server determining whether the second account is an authorised account; and responsive to a determination that the recipient account is an authorised account, validating the transaction.

37. The method of claim 36, wherein a transmission module of the server sends a response message in response to the receipt of the instruction message.

38. The method of claim 35 or claim 37, wherein the response message is sent to a second mobile communications device associated with the second account.

39. The method of claim 38, wherein upon receipt of the validation instruction from the second mobile communications device, the server flags the second account as an authorised account.

40. The method of any one of claims 23 to 39, wherein the server receive an instruction from the first mobile communications device to add the second account as an authorised account.

41. The method of any one of claims 23 to 40, wherein the server de-authorises an authorised account a pre-determined time after authorisation of the authorised account.

42. The method of any one of claims 23 to 41, wherein the server records receipt of an activation telephone call from a user to the server and, upon recording receipt of the activation telephone call, activates or deactivates the user account.

43. A method for activating or deactivating a user account, the method comprising a server receiving and record receipt of an activation telephone call from the user directly to the server and, upon recording receipt of the activation telephone call, activating or deactivating the user account

44. The method of claim 42 or claim 43, wherein the server selects between activation and deactivation of the account in dependence of a status of the account.

45. The method of any one of claims 42 to 44, wherein the server makes a telephone call to the user to prompt the user to validate activation or deactivation of the account, for the transaction from the validation instruction.