Gatinho, Elaine Margaret (27 Lower Park Drive, 2122 Parkview, ZA)
Van Wyk, Yolande (No. 21, 5th Avenue, 2193 Parktown North, ZA)
Pienaar, Lionel De Villiers (71 Marie Road, Bramley North, 2090 Johannesburg, ZA)
Gatinho, Elaine Margaret (27 Lower Park Drive, 2122 Parkview, ZA)
Van Wyk, Yolande (No. 21, 5th Avenue, 2193 Parktown North, ZA)
| 1. | A method of operating a banking service, the method comprising: recording customer data and storing the customer data in a database, the customer data including a mobile telephone number and a corresponding customer password; receiving a transaction request message sent from a mobile telephone of a customer, the transaction request message including predetermined content comprising alphanumeric characters entered into said mobile telephone by the customer; identifying the customer from the number of the customer's mobile telephone; transmitting a password request message to the customer's mobile telephone, requesting the customer to enter a password; receiving a password entered into said mobile telephone by the customer and sent from said mobile telephone; and if the password corresponds to the mobile telephone number in the recorded customer data, authorizing a transaction corresponding to the predetermined content of the transaction request message sent from the mobile telephone of the customer. |
| 2. | A method according to claim 1 wherein the transaction request message is an SMS message. |
| 3. | A method according to claim 1 or claim 2 wherein the password request message is an SMS message. |
| 4. | A method according to any one of claims 1 to 3 wherein the predetermined content of the transaction request message comprises one of a plurality of wholly or partially predetermined messages corresponding to different transactions. |
| 5. | A method according to claim 4 wherein the transaction request message is wholly predetermined and comprises an alphanumeric component identifying the nature or type of the transaction and a numeric value indicating the monetary value of the transaction. |
| 6. | A method according to claim 4 wherein the transaction request message is partially predetermined and comprises a predetermined component and at least one user determined variable component. |
| 7. | A method according to claim 6 wherein the transaction request message comprises a first predetermined alphanumeric component defining the nature or type of the transaction and a user determined numeric value indicating the monetary value of the transaction. |
| 8. | A method according to claim 7 wherein the transaction request message further comprises a second alphanumeric component identifying a transaction beneficiary or other third party. |
| 9. | A method according to claim 8 wherein the second alphanumeric component is a name identifying a beneficiary previously predetermined by the user. |
| 10. | A method according to claim 8 wherein the second alphanumeric component is a user determined numeric value corresponding to an account number of a beneficiary. |
| 11. | A method according to claim 8 wherein the second alphanumeric component is a user determined numeric value corresponding to the number of a mobile telephone the account of which is to be topped up with airtime. |
| 12. | A method according to any one of claims 1 to 11 wherein the characters making up the transaction request message are entered into the customer's mobile telephone by the customer using the keypad of the mobile telephone. |
| 13. | A method according to any one of claims 1 to 12 including transmitting a confirmatory message to the customer's mobile telephone confirming the transaction. |
| 14. | A method according to claim 13 wherein the confirmatory message is an SMS message. |
| 15. | A method according to any one of claims 1 to 14 including recording customer data entered by the customer via a website, via an ATM, by telephone or by filling an application form. |
| 16. | A system for operating a banking service, the system comprising: a database for storing customer data of a plurality of customers, the customer data for each customer including a mobile telephone number and a corresponding customer password; a message server arranged to receive transaction request messages sent from mobile telephones of customers, the transaction request messages including predetermined content comprising alphanumeric characters entered into said mobile telephones by the customers; and to transmit password request messages to the customer's mobile telephone, requesting the customer to enter a password; and a transaction server arranged to identify customers from the numbers of the customers' mobile telephones included in data transmitted via the message server, to receive passwords entered into said mobile telephones by customers and transmitted via the message server and, if a password corresponds to a respective mobile telephone number in the recorded customer data, to authorize a transaction corresponding to the predetermined content of the transaction request message sent from the mobile telephone of the customer. |
| 17. | A system according to claim 16 wherein the message server is arranged to receive transaction request messages and to transmit password request messages in an SMS message format. |
| 18. | A system according to claim 16 or claim 17 wherein the predetermined content of the transaction request message comprises one of a plurality of wholly or partially predetermined messages corresponding to different transactions. |
| 19. | A system according to claim 18 wherein the transaction request message is wholly predetermined and comprises an alphanumeric component identifying the nature or type of the transaction and a numeric value indicating the monetary value of the transaction. |
| 20. | A system according to claim 18 wherein the transaction request message is partially predetermined and comprises a predetermined component and at least one user determined variable component. |
| 21. | A system according to claim 20 wherein the transaction request message comprises a first predetermined alphanumeric component defining the nature or type of the transaction and a user determined numeric value indicating the monetary value of the transaction. |
| 22. | A system according to claim 21 wherein the transaction request message further comprises a second alphanumeric component identifying a transaction beneficiary or other third party. |
| 23. | A system according to claim 22 wherein the second alphanumeric component is a name identifying a beneficiary previously predetermined by the user. |
| 24. | A system according to claim 22 wherein the second alphanumeric component is a user determined numeric value corresponding to an account number of a beneficiary. |
| 25. | A system according to claim 22 wherein the second alphanumeric component is a user determined numeric value corresponding to the number of a mobile telephone the account of which is to be topped up with airtime. |
BACKGROUND OF THE INVENTION
THIS invention relates to a method of operating a banking service and to a system for implementing a method.
Various systems exist by means of which customers of a bank can use their mobile telephones to access banking services. Known systems have various drawbacks. In particular, some such systems require special software applications to be loaded into the SIM card memory of a customer's mobile telephone in order to provide the necessary functionality, typically comprising an interactive menu. This in turn requires mobile telephones having SIM cards with a relatively large memory capacity. The net result is that a substantial number of mobile telephone users may effectively be excluded from using the system due either to the inconvenience of downloading the necessary software or because their SIM cards do not have the necessary memory capacity.
It is an object of the invention to provide an alternative mobile telephone banking service.
SUMMARY OF THE INVENTION
According to the invention there is provided a method of operating a banking service, the method comprising:
recording customer data and storing the customer data in a database, the customer data including a mobile telephone number and a corresponding customer password;
receiving a transaction request message sent from a mobile telephone of a customer, the transaction request message including predetermined content comprising alphanumeric characters entered into said mobile telephone by the customer;
identifying the customer from the number of the customer's mobile telephone;
transmitting a password request message to the customer's mobile telephone, requesting the customer to enter a password;
receiving a password entered into said mobile telephone by the customer and sent from said mobile telephone; and
if the password corresponds to the mobile telephone number in the recorded customer data, authorizing a transaction corresponding to the predetermined content of the transaction request message sent from the mobile telephone of the customer.
The transaction request message may be an SMS message.
The password request message may also be an SMS message.
The predetermined content of the transaction request message may comprise one of a plurality of wholly or partially predetermined messages corresponding to different transactions.
In the case of messages which are partially predetermined, the non- predetermined portion of the message may comprise a customer-selected value corresponding to a transaction amount, the number of an account to which funds must be deposited or from which funds must be withdrawn, or the number of a mobile telephone the account of which is to be topped up with airtime, for example.
The transaction request message may be wholly predetermined and comprise an alphanumeric component identifying the nature or type of the transaction and a numeric value indicating the monetary value of the transaction.
Alternatively, the transaction request message may be partially predetermined and comprise a predetermined component and at least one user determined variable component.
In one embodiment of the invention, the transaction request message comprises a first predetermined alphanumeric component defining the nature or type of the transaction and a user determined numeric value indicating the monetary value of the transaction.
The transaction request message may further comprise a second alphanumeric component identifying a transaction beneficiary or other third party.
The second alphanumeric component may be a name identifying a beneficiary previously predetermined by the user.
Altematively, the second alphanumeric component may be a user determined numeric value corresponding to an account number of a beneficiary.
As another alternative, the second alphanumeric component may be a user determined numeric value corresponding to the number of a mobile telephone the account of which is to be topped up with airtime.
In any case, the characters making up the transaction request message are entered into the customer's mobile telephone by the customer using the keypad of the mobile telephone.
The method may include transmitting a confirmatory message, preferably an SMS message, to the customer's mobile telephone confirming the transaction.
The customer data may be entered by the customer via a website, via an ATM, by telephone or by filling an application form.
Further according to the invention there is provided a system for operating a banking service, the system comprising:
a database for storing customer data of a plurality of customers, the customer data for each customer including a mobile telephone number and a corresponding customer password;
a message server arranged to receive transaction request messages sent from mobile telephones of customers, the transaction request messages including predetermined content comprising alphanumeric characters entered into said mobile telephones by the customers; and to transmit password request messages to the customer's mobile telephone, requesting the customer to enter a password; and
a transaction server arranged to identify customers from the numbers of the customers' mobile telephones included in data transmitted via the message server, to receive passwords entered into said mobile telephones by customers and transmitted via the message server and, if a password corresponds to a respective mobile telephone number in the recorded customer data, to authorize a transaction corresponding to the predetermined content of the transaction request message sent from the mobile telephone of the customer.
The message server is preferably arranged to receive transaction request messages and to transmit password request messages in an SMS message format.
The predetermined content of the transaction request message may comprise one of a plurality of wholly or partially predetermined messages corresponding to different transactions.
The transaction request message may be wholly predetermined and comprise an alphanumeric component identifying the nature or type of the transaction and a numeric value indicating the monetary value of the transaction.
Alternatively, the transaction request message may be partially predetermined and comprise a predetermined component and at least one user determined variable component.
In one embodiment of the invention, the transaction request message comprises a first predetermined alphanumeric component defining the nature or type of the transaction and a user determined numeric value indicating the monetary value of the transaction.
The transaction request message may further comprise a second alphanumeric component identifying a transaction beneficiary or other third party.
The second alphanumeric component may be a name identifying a beneficiary previously predetermined by the user.
Alternatively, the second alphanumeric component may be a user determined numeric value corresponding to an account number of a beneficiary.
As another alternative, the second alphanumeric component may be a user determined numeric value corresponding to the number of a mobile telephone the account of which is to be topped up with airtime.
BRIEF DESCRIPTION OF THE DRAWINGS
Figure 1 is a simplified diagram illustrating major components of a system for operating a banking service according to the invention; and
Figure 2 is a simplified flow diagram showing major steps in the method of the invention.
DESCRIPTION OF PREFERRED EMBODIMENTS
The present invention aims to provide a mobile telephone-based banking service which utilises standard SMS (Short Message Service) transmissions and which can be implemented on almost any mobile telephone, including older models. In particular, the system of the invention does not require a special software application to be loaded onto the telephone or its SlM (Subscriber Identity Module) card, so that it is not
necessary for bank customers wishing to make use of this service to have recent model mobile telephones or large capacity (32kB) SIM cards. No modifications to either the mobile telephone or the standard SIM card are required to use the method and system.
In order to use the method and system of the invention, a bank customer is required to register for the service. The customer can register via a website, typically an existing Internet banking website operated by the bank offering the service. Alternatively, the customer could register via an ATM (Automatic Teller Machine) of the bank. In both these cases, the registration process can be relatively easy and efficient, since the customer's details are already known to the bank. Essentially, it is only necessary for the customer to enter the telephone number of his/her mobile telephone and to enter a password or PIN (Personal Identification Number). Alternatively, the customer can provide the necessary information to the bank by telephone, either via an automated call center or a conventional operator, or by filling in a suitable form at a local branch of the bank.
The new customer data is stored in a database 12 of a server 10, together with other user data such as personal details of the customer and details of one or more accounts (see Figure 1). The password or PIN data entered by the customer is stored in an associated PIN database 14.
The operation of the method and system of the invention will now be described in more detail with reference to the schematic diagram of Figure 1 and the flow diagram of Figure 2. In Figure 1 , a mobile telephone 16 of a banking customer connects to a mobile telephone network 18 via a base station 20 in a conventional manner. In order to carry out a transaction, the customer chooses one of a number of possible transactions and enters an SMS-format message into his/her mobile telephone via the telephone keypad. The message content may be wholly predetermined or may comprise a predetermined portion and a user entered portion, as described below.
In the prototype system of the invention, several categories of transaction are catered for. The first category of transaction relates to the purchase of mobile telephone airtime. Airtime can be purchased for the mobile telephone being used by the customer to conduct the transaction, or any other mobile telephone, including mobile telephones which are not linked to the system. The system also provides for enquiries regarding the status of the customer's prepaid airtime on the account of the mobile telephone linked to the banking service.
A second category of transaction relates to balance and statement information concerning a bank account linked to the mobile banking service. A further category of transaction relates to the transferring of funds between the account linked to the mobile banking service and another account of the customer at the same bank. In addition, another category of transaction relates to the payment to a third-party beneficiary via the mobile channel. The beneficiary needs to have been linked or set-up prior to the transaction taking place at a branch of the bank, via an Internet banking system operated by the bank, or via a Cellphone Banking helpline operated by the bank. Finally, a further category of transaction relates to management of the mobile banking service itself.
Table 1 below provides examples of the transactions available in the prototype system.
1.1 Buy Prepaid airtime
Note: Any rand value can be requested, subject to the network operators' minimum and maximum airtime values.
1.2 Check account balances
1.3 Get a mini statement
1.4 Transfer money between my own FNB accounts
1.5 Make third party payments
Note: You need to spell the beneficiary name correctly for your transaction to be successful.
1.6 Payment related functions:
1.7 Maintenance Functions
In an initial version of the system of the invention it was necessary that all transactions involving the purchase of prepaid airtime for the mobile telephone linked to the banking service, as well as for another mobile telephone, were completely predetermined from both a value and network perspective. A number of predetermined options were provided for the customer to choose from, corresponding to the value of vouchers utilised by the network operators. In the case of Mobile Telephone Networks of South Africa (MTN), for example, standard voucher values are 30, 60 and 180 minutes of airtime.
Thus, for example, if the customer was an MTN subscriber and wished to purchase R180.00 worth of airtime for the mobile telephone linked to the banking service, the customer had to enter the characters "MTN 180" and send an SMS message to a predetermined number, i.e. 31321. This required the customer to insert the name of the appropriate network operator correctly as well as the respective predetermined voucher amount for that specific network. Similarly, where the customer wished to purchase airtime for another mobile telephone (other than the mobile telephone linked to the described mobile banking system) the customer was required to enter the predetermined portion of the transaction request message and, in addition, was required to enter the mobile telephone number
corresponding to the account which he/she wished to top up, e.g. "MTN 180 0831234567".
In an enhanced version of the invention, the system enables customers purchasing airtime for the mobile telephone linked to the service to simply send an SMS message comprising the word "AIRTIME" together with a user selected numeric amount to the predetermined number 31321. In this version of the system, a predetermined transaction identifier (i.e. the word "AIRTIME") is used in the transaction request message, but the transaction amount is no longer pre-determined, which means that any prepaid amount can now be purchased provided it is within the network minimum and maximum range. From a user point of view, this provides flexible prepaid airtime purchases with a universal transaction keyword that is no longer network specific.
Similarly, if a customer requests the purchase of prepaid airtime for another mobile telephone, the "AIRTIME" transaction keyword together with the desired numeric value and the recipient's mobile telephone number can be sent to the predetermined number e.g. "AIRTIME 100 0831234567". The aim of this enhancement is to minimize the margin of error in use and to provide flexibility in terms of the value of airtime that can be purchased. In the enhanced system of the invention, the original predetermined network specific transaction keywords are still accepted as valid transaction request messages.
In the case of transactions requiring the transfer of funds from one account to another, the transaction request message comprises the word "TRANSFER", a numeric value corresponding to the amount to be transferred selected by the customer, the word "TO" and an account keyword identifying the type of account to which the funds are being transferred (in the case where the customer has more than one account of the same type, the customer additionally enters the last six digits of the account number to differentiate the accounts). Examples of accounts and corresponding account keywords are set out in Table 2 below.
When making a payment, the transaction request message includes the word "PAY", a numeric value that is required to be paid, and the word "TO" as well as name of the beneficiary that the customer wishes to make a payment to. If the customer wishes to specify an account from which the payment must be deducted, this can be done by adding the word "FROM" and the respective account keywords. If the "FROM" account is not specified the transaction will automatically be deducted from the linked Cellphone Banking account chosen at registration. Again, if the customer has more than one of the same type of account; the customer is required to enter the last six digits of the account number that he/she wishes to transact from. The customer also has the option to overwrite the existing reference (that was entered at time of beneficiary set-up) with a new reference; this can be done by adding the word "REF" in front of the reference.
Thus, it can be seen that the method and system of the invention cater for two types of transaction request messages: firstly, transaction request messages which are completely predetermined and, secondly, transaction request messages which are partially predetermined and which comprise a predetermined component and at least one user determined variable component. In the former case, the messages generally comprise an alphanumeric component identifying the nature or type of the transaction and a numeric value indicating the monetary value of the transaction. In the latter case, the transaction request messages generally comprise a predetermined alphanumeric component defining the nature or type of the transaction (e.g. "AIRTIME") but the value of the transaction and, optionally, information identifying the transaction beneficiary or other third party is user determined. The value of the transaction will generally be indicated by a numeric value, and the information identifying the transaction beneficiary or other third party will be a further alphanumeric component.
Table 2
In all cases, the customer enters the alphanumeric characters via the keypad of his/her mobile telephone, including the predetermined component of the transaction request message. Having done this once, the customer can of course save the message or a portion thereof as a template for future use.
Referring again to Figure 1 , the sequence of system transactions will be discussed in further detail. In Figure 1 , the abbreviation "MO" is used for mobile originating messages, that is, messages transmitted from or originating from the mobile telephone. The abbreviation "MT" is used for mobile terminating messages, that is, message originating from a message server of the system and transmitted via the mobile telephone network to the mobile telephone.
The mobile terminating (MT) and mobile originating (MO) messages may be SMS or USSD messages. The format of the messages used is generally in accordance with the GSM specification.
To initiate a transaction, the customer chooses a transaction, enters the relevant characters/numerals for the appropriate message and presses "Send" on the mobile telephone keypad to transmit the transaction request message. The message is transmitted via the base station 20 of the mobile telephone network and via a SMSC (Short Message Switching Center) 22 which forwards the message using SMPP (Short Message Peer to Peer) protocol to a message server 24 forming part of the system. The message server transfers the message data to the bank server 10, where the MSISDN (Mobile Subscriber Integrated Services Digital Network) mobile telephone number is extracted from the message data and used to identify the customer who has sent the transaction request.
Once the customer has been identified, the message server 24 generates a password or PIN request message which is transmitted back by the SMSC 22 and the base station 20 to the mobile telephone 16 and displayed on the screen of the customer's mobile telephone. The message would typically read "To confirm your MTN R180.00 prepaid airtime purchase for 083 123 4567, dial *120*321 *MOPIN#, where MOPIN = your 5-digit FNB Cellphone Banking PIN". If this message reflects the desired transaction, the customer dials the code "*120*321 *MOPIN#", with MOPIN being the previously recorded user password or PIN provided by the customer during the registration process. This data is transmitted as a USSD (Unstructured Supplementary Services Data) string from the mobile telephone 16, via the base station 20 and a USSD center 26. The message is forwarded via SMPP to the message server 24 and from the message server 24 to the bank server 10, which verifies that the received PIN corresponds to the MSISDN extracted from the transaction request message.
If the PIN and the MSISDN correspond, the transaction is authorized and processed and a confirmatory SMS message is generated by the message server 24 and transmitted via the SMSC 22 to the customer's mobile telephone 16 confirming the carrying out of the transaction. In some cases, where the nature of the transaction is a request for information (for example, a balance or mini-statement request), the carrying out of the transaction request and the confirmation thereof are effected by the same SMS message.
The above process is set out in detail in the flow diagram of Figure 2. The flow diagram includes branches to deal with errors, time-outs and cancellations.
Although the above example describes the use of SMS messages by both the customer and the message server of the system, it is also possible for the messages in question to be sent using the USSD format. In that case, it is possible to transmit data from the system to the user to generate menus on the user's mobile telephone from which items can be selected by, for example, entering a number corresponding to a menu item. It will be appreciated, however, that the transaction request message sent by a customer is entered by the customer via the keypad (or other user interface) of the customer's mobile telephone in either case.
A particular advantage of the described method and system is the fact that a banking customer can use almost any mobile telephone to access the mobile banking system, as it is not necessary for him/her to download special software requiring a modern mobile telephone and a SIM card with sufficient memory for this purpose. It will be appreciated that the transactions and messages described above are purely exemplary and that other transactions and messages can be provided in addition or instead.