WO2010150229A2

WO2010150229A2 - A financial transaction system and a method for operating a financial transaction system

Info

Publication number: WO2010150229A2
Application number: PCT/IB2010/052909
Authority: WO
Inventors: Bradley Ivan Kark; Ruperta O'kelly
Original assignee: Retail Mobile Credit Specialists (Proprietary) Limited
Priority date: 2009-06-25
Filing date: 2010-06-25
Publication date: 2010-12-29
Also published as: ZA201004518B; WO2010150229A3

Abstract

This invention relates to a system for facilitating a financial transaction and to a method of operating the system. In particular, the system comprises a database storing a plurality of unique identifiers and information associated with a plurality of registered users including credit profiles associated with the registered users, a receiver module configured at least to receive a unique identifier from a user and information relating to the financial transaction; a validation module configured to validate the received unique identifier thereby to proceed with the particular financial transaction; a credit and/or risk management module arranged to perform a credit and/or risk management check for the registered user and the particular transaction, thereby to determined if the particular transaction is allowed or not; and an accounting module configured to facilitate processing the particular transaction if the credit and/or risk management module determines that the particular transaction is allowed.

Description

A FINANCIAL TRANSACTION SYSTEM AND A METHOD FOR OPERATING A FINANCIAL TRANSACTION SYSTEM

BACKGROUND OF THE INVENTION

THIS invention relates to a system for facilitating a financial transaction, and to a method of operating the system for facilitating a financial transaction.

Retailers of goods and/or services typically provide retail accounts to customers for purchasing goods and/or services from them. These retail accounts usually permit customers to purchase items and/or servic,es on credit and pay for the purchases at a later time.

When making purchases from the retailer, customers or authorised agents of the customers are typically physically present at the premises of the retailer so as to provide the retailer with retail account cards or other information associated with their respective retail accounts in order to process the transactions for the purchases of goods and/or services. The retail accounts of the customers are then respectively debited for the purchase price of the goods and/or services purchased. One problem with this arrangement is that customers have to be physically at the premises of the retailer during operating hours thereof in order to purchase goods and/or services.

It is therefore an object of the present invention at least to address the abovementioned problem and to provide an alternative way of facilitating a transaction.

SUMMARY OF THE INVENTION

According to a first aspect of the invention there is provided a system for facilitating a financial transaction, the system comprising:

a database storing a plurality of unique identifiers and information associated with a plurality of registered users, wherein the information associated with the plurality of registered users comprises at least a credit profile associated with each of the registered users,

a receiver module configured at least to receive an input of a unique identifier from a user and information relating to the financial transaction which the user wishes to engage in;

a validation module configured to validate the received unique identifier thereby to proceed with the financial transaction;

a credit and/or risk management module arranged to perform a credit and/or risk management check for the registered user and the financial transaction, using at least the credit profile associated with the user, thereby to determine if the financial transaction is allowed, or not, based, at least in part, on the credit profile of the user; and an accounting module configured to facilitate processing the financial transaction if the credit and/or risk management module determines that the financial transaction is allowed.

The system may comprise a transmitter module configured at least to transmit a rejection message to a user in response to the validation module determining that the received unique identifier is invalid or in response to the credit and/or risk management module determining that the financial transaction is not allowed.

The receiver module and transmitter module may be adapted to communicate, in real-time with the user at a remote location, via one or more of at least a USSD (Unstructured Supplementary Service Data) session, web or mobile web session, SMS (Short Message Service) messages, or an IVR (Interactive Voice Response) session.

The financial transaction may comprise a purchase, by the user, of items/s and/or service/s offered for sale by a retailer, the accounting module may therefore be configured to debit a retail account of the user for at least a purchase price of the item and/service purchased by the user if the credit and/or risk management module determines that the financial transaction is allowed.

The retail account may be provided for a user at the retailer, wherein the accounting module is configured to forward information indicative of the transaction to the retailer for authorisation.

The credit profile may comprise at least one credit level or tier which is assigned to a user, or vice versa, based on a credit behavior pattern and/or fraud score associated with the user.

Each credit tier may comprise predetermined limits or rules which determine a maximum monetary amount which a user can spend daily and/or monthly and/or the number of transactions that can be performed on -A-

a daily and/or monthly basis, wherein the credit and/or risk management module is configured to determine if the financial transaction is at least within the predetermined limits or rules corresponding to the credit tier associated with the user.

The system may be configured to retrieve a virtual item from the retailer and transmit the same to the user by way of the transmitter module.

The virtual item may be a pre-paid airtime voucher for crediting a mobile telephone account of a user.

The system may comprise a registration module configured to receive information from a user via the receiver module to register the user to the system.

The system may further comprise a voucher management module configured to retrieve or generate vouchers in response to at least the credit and/or risk management module determining that the financial transaction is allowed, which vouchers are transmitted to the user via the transmitter module, and wherein the vouchers are usable in trade to purchase at least one item and/or service.

The system may further comprise an off-line wallet associated with each user, each off-line wallet being configured to be debited by the accounting module instead of a retail account associated with the user at least when an authorisation system associated with the retailer is down or unavailable.

According to a second aspect of the invention there is provided a method of operating a system for facilitating a financial transaction, the method comprising:

receiving, by way of a receiver module, an input of a unique identifier from a user and information relating to the financial transaction which the user wishes to engage in; validating, by way of a validation module, the received unique identifier thereby to proceed with the financial transaction;

performing a credit and/or risk management check, by way of the credit and/or risk management module, for the registered user and the financial transaction, using at least a credit profile associated with the registered user, thereby to determined if the financial transaction is allowed, or not, based, at least in part, on the credit profile of the user; and

processing, via an accounting module, the financial transaction if the credit and/or risk management module determines that the financial transaction is allowed.

The method may comprise transmitting, by way of a transmitter module, a rejection message to a user in response to determining that the received unique identifier is invalid or in response to determining that the financial transaction is not allowed.

The method may comprise communicating with the user, at a remote location, in real-time via one or more of at least a USSD (Unstructured Supplementary Service Data) session, web or mobile web session, SMS (Short Message Service) messages, or an IVR (Interactive Voice Response) session.

The financial transaction may comprise a purchase, by the user, of items/s and/or service/s offered for sale by a retailer, the method therefore may comprise operating the accounting module to facilitate debiting a retail account of the user, at a retailer, for at least a purchase price of the item and/service purchased by the registered user if the user passes the credit and/or risk management check. The accounting module may transmit information indicative of the transaction to the retailer in order for the retailer to authorise the transaction. However, in certain example embodiments, the accounting module may debit the user account at the retailer.

Each tier may comprise predetermined limits or rules which determine a maximum monetary amount which a user is allowed to spend daily and/or monthly and/or the number of transactions that can be performed on a daily and/or monthly basis, the credit and/or risk management check therefore comprises at least determining if the financial transaction is at least within the predetermined limits or rules corresponding to the credit tier associated with the user.

The method may comprise retrieving a virtual item from the retailer and transmitting the same to the user by way of the transmitter module.

The virtual item may be a pre-paid airtime voucher for a crediting a mobile telephone account of a user.

The method may comprise registering a user to the transaction system by way of a registration module.

Registering a user to the transaction system may comprise the steps of:

receiving validation information from the user, the validation information comprising at least information to identify the user and/or the retail account of the user at the retailer;

performing a credit and/or risk management check on the user or the retail account of the user; transmitting a request to the retailer to authorise registration of the user to the system if the user passes the credit and/or risk management check; and

registering the user to the system if information indicative of the authorisation of the registration of the user by the retailer is received.

The method may comprise generating and transmitting a unique identifier to the user once the user has been registered to the system.

The unique identifiers may be stored in a database together with respective information associated with the user or the retail account of the user.

The method may comprise:

retrieving or generating vouchers, in response to at least the credit and/or risk management module determining that the particular transaction is allowed, which vouchers being usable in trade to purchase at least one item and/or service; and

transmitting the vouchers to the user.

The method may comprise transmitting the purchase request to the retailer for authorisation after the user passes the credit and/or risk management check.

The method may comprise receiving authorisation from the retailer to debit the retail account of the user.

The method may comprise debiting an off-line wallet associated with a user, by way of the accounting module, instead of a retail account associated with the user at least when an authorisation system associated with the retailer is down or unavailable.

According to a third aspect of the invention there is provided a set of computer executable instructions, which when executed by a machine, causes the machine to perform the steps of:

receiving an input of a unique identifier from a user and information relating to the financial transaction which the user wishes to engage in;

validating the received unique identifier thereby to proceed with the financial transaction;

performing a credit and/or risk management check for the registered user and the particular transaction, using at least a credit profile associated with the user, thereby to determined if the financial transaction is allowed, or not, based, at least in part, on the credit profile of the user; and

processing the particular transaction if the credit and/or risk management module determines that the financial transaction is allowed.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 shows a schematic diagram of a network comprising a system in accordance with an example embodiment;

Figure 2 shows a schematic diagram of a transaction system of Figure 1 in greater detail; Figure 3 shows a flow diagram of a method in accordance with an example embodiment;

Figure 4 shows a schematic diagram of a process flow in accordance with an example embodiment;

Figure 5 shows a flow diagram of another method in accordance with an example embodiment;

Figure 6 shows a schematic diagram of another process flow in accordance with an example embodiment;

Figure 7 shows a flow diagram of another method in accordance with an example embodiment; and

Figure 8 shows a diagrammatic representation of a machine in the example form of a computer system in which a set of instructions for causing the machine to perform any one or more of the methodologies discussed herein, may be executed.

DESCRIPTION OF PREFERRED EMBODIMENTS

In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of an embodiment of the present disclosure. It will be evident, however, to one skilled in the art that the present disclosure may be practiced without these specific details.

Referring to Figures 1 and 2 of the drawings where a network in accordance with an example embodiment is generally indicated by reference numeral 10. The network 10 comprises a financial transaction system 12 in accordance with an example embodiment. The system 12 is arranged to communicate with a plurality of users or customers 14 and a plurality of retailers, particularly retailer authorisation systems 20 associated with the retailers (described below), via a communications network 16 so as to facilitate financial transactions between the users 14 and retailers for goods and/or services offered by the latter.

For ease of illustration only two users and one retail authorization system 20 are/is shown. The users 14 may be registered users of the system 12 as will be described below.

The communications network 16 may advantageously comprise a telecommunications network, particularly a mobile or cellular telecommunications network to allow the system 12 to receive data from a remote user 14 via a mobile computing device associated with the user 14, for example, a cellular or mobile telephone, or the like. It follows that the system 12 may be arranged to receive data from the user 14 in the form of USSD (Unstructured Supplementary Service Data) messages, SMS (Short Messaging Service) messages, IVR (Integrated Voice Response) data, or the like.

In other example embodiments, the communications network 16 may be a packet-switched network and may form part of the Internet. Instead, the communications network 108 may be a circuit switched network, public switched data network, or the like. The system 12 may be configured to communicate with the user 14, for example from a PC (Personal Computer) or laptop of the user 14, over the Internet via a webpage, or the like. Preferably, the system 12 may be configured to communicate with the user 14 via a mobile Internet site or mobile web/website accessible, for example, via a mobile computing device associated with the user 14. The mobile computing device may be a smart phone, a PDA (personal digital assistant), or the like.

The user 14 may also communicate, for example, input data to the system 12 by calling in to a call center 18 via a mobile telecommunications network or PSTN (Public Switched Telephone Network). The call center 18 transmits the data received from the user 14 (explained in greater detail below) to the system 12 via the Internet, for example. In other example embodiments, the call center 18 is provided at the location of the system 12.

The retailer authorisation system 20 as hereinbefore mentioned may typically be provided at a retailer of items or goods and/or services. However, it will be appreciated that in certain example embodiments, the retail authorisation system 20 may be located at or served from an off-site location to the retailer. In any event, the retailer typically provides retail accounts to users 14 for facilitating the purchase of goods and/or services therefrom. In certain example embodiments, these goods are virtual goods.

The retail account may typically by a financial account held at or maintained by the retailer to allow the user 14 to purchase goods and/or services on credit, for example. When purchased on credit, the goods and/or services purchased by the user 12 are typically repaid at intervals, typically periodic, and in accordance with a predetermined interest rate schema or regime.

Turning now to Figure 2 of the drawings where the system 12 is illustrated in greater detail. In particular, the system 12 comprises a plurality of components or modules which correspond to the functional tasks to be performed by the system 12. In this regard, "module" in the context of the specification will be understood to include an identifiable portion of code, computational or executable instructions, data, or computational object to achieve a particular function, operation, processing, or procedure. It follows that a module need not be implemented in software; a module may be implemented in software, hardware, or a combination of software and hardware. Further, the modules need not necessarily be consolidated into one device but may be spread across a plurality of devices within the network 10, or even network 16 for that matter. It follows that the system 12 may be served from a server connected to the network 16, or 10. In particular, the system 12 comprises a database 22 storing or configured to store at least a plurality of unique identifiers and information associated with a plurality of registered users 14 therein. As mentioned above, the users 14 will be understood to include registered users as will be described below.

The database 22 may be configured to link a unique identifier associated with a particular user 14 to the identifying information associated with the user 14. The identifying information may typically be indicative of the identity of the user 14 and also retail account details of at least one retail account of the user 14 at least one particular retailer. In certain example embodiments, the retail account details associated with the user 14 comprises details of a plurality of retail accounts of the user 14 at one or a plurality of different retailers.

The system 12 also comprises a receiver module 24 arranged at least to receive a unique identifier from the registered user 14 in order to initiate the financial transaction. The receiver module 24 may also receive a user name from the user 14 to identify the same. However, it will be appreciated that if the user 14 communicates with the system 12 by way of their cellular or mobile telephone, they may be automatically identified by the system 12 by way of their MSISDN (Mobile Station Integrated Services Digital Network) number, IMSI (International Mobile Subscriber Identity), IMEI (International Mobile Equipment Identity), or the like. It will be appreciated that the IMSI, IMEI, and MSISDN may therefore form part of the identifying information associated with the user 14.

In any event, the unique identifier may advantageously be a security PIN (Personal Identification Number) in the form of a numeric and/or alphanumeric code uniquely assigned or chosen by the user 14 upon registering to the system 12. The receiver module 24 may be configured to communicate over the network 16. It follows that the receiver module 24 may comprise a suitable telecommunication module for example a GSM (Global System for Mobile communications), GPRS (General Packet Radio Service), 3G, UMTS (Universal Mobile Telecommunications System) module, or the like to enable the receiver module 24 to communicate with the user 14 via the network 16 accordingly. Instead, or in addition, the receiver module 24 comprises a modem to allow the system 12 to communicate with the user 14 via the Internet, mobile web or a web server.

The receiver module 24 is also conveniently arranged to receive transaction data from a user 14 indicative of a financial transaction which the user 14 desires to carry out. The transaction details may comprise information indicative if the purchase amount of the goods and/or services associated with the financial transaction.

The receiver module 24 may also be conveniently arranged to prompt the user 14 for various information such as their PIN, transaction data, user name, or the like. This is particularly relevant where the user 14 communicates with the system 12 via USSD, web or mobile web, IVR sessions, or SMSs.

The system 12 also comprises a validation module 26 arranged to validate the received PIN for a particular user 14. This may be done in a plurality of ways, for example, by comparing the received PIN with a PIN stored in the database 22 associated with a particular user 14 (identified by the user name or IMSI, IMEI₁ or MSISDN as the case may be), for example, by way of a suitable look-up table in the database 22 storing PINs associated with a plurality of users 14. Alternatively, or in addition, the PIN received may be validated by applying a validation algorithm to the received PIN to determine the validity thereof, and in some instances even the identity of the user 14.

The system 12 also comprises a credit and/or risk management module 28 arranged to perform a credit and/or risk management check for the user 14 once the validation module 26 determines that the received PIN code is valid. In this regard, it will be noted that each user 14 is assigned a credit profile based on a credit behavior pattern of the user 14 (assessed by a behavior scoring module which is not illustrated). The credit behavior pattern may conveniently be determined or calculated based at least on information indicative of a user's frequency of payment of their respective accounts, as well as the frequency of their associated account/s being overdue. In this regard, it will be appreciated that the credit behavior pattern may be indicative of the likelihood or probability of a user 14 paying his or her account. The credit profile of each user 14 is advantageously stored in the database 22 and associated respectively therewith in the database 22. The credit profile may be a credit level or tier which is assigned to a user 14. Each tier comprises predetermined limits that determine the maximum amount that may be purchased daily (maximum daily monetary amount which may be spent) and/or monthly and/or the number of transactions that may be performed on a daily and/or monthly basis. Or in other words, each tier comprises spending rules.

It follows that the credit management check performed by the module 28 may be to determine if the user 14 and transaction details such as the purchase amount, or the like, is allowed in accordance with the tier which the user 14 is on. In other words, the module 28 determines if the transaction is allowed or not for a particular user based on the associated credit tier which the user 14 is on. For example, if a user 14 exceeds their daily spending limit determined by their associated credit tier, then the module 28 determines that any further transaction for the day is not allowed and vice versa.

In summary it will be understood that the database 22 comprises a record of each user registered to the system 12. Each record may typically comprise information indicative of at least one or more of the unique identifier associated with the user, the credit profile of the user, the IMSI, IMEI, or MSISDN associated with the user, the usemame of the user, information to identify the retail account at retailer, and the like. It will be noted that for a mobile web session, the IMSI, IMEI, and MSISDN will not be relevant to determining the identity of the user 14. In this regard, the unique identifier and a usemame will be important to allow the user 14 to have access or to use the system 12.

A portion or percentage of credit available to the user 14 could be held back from participating in the virtual sale of products or services by way of the system 12, the portion or percentage being usable only in stores or retail stores.

In addition, daily and/or monthly usage is tracked and reviewed along with the times that products are purchased and the recipients of these products which then advantageously used in fraud and retention strategies. In particular, it will be noted that the module 28 is further configured to apply fraud models/strategies to determine a fraud score associated with a particular user. The fraud score is determined using at least information derived from the user behavior patterns associated with a particular user 14. It will be understood that the fraud score enables the module 28 and system 12 to determine a user's propensity for fraudulent behavior, especially toward their retail account.

The system 12 may be configured to apply retention strategies by analysing customer behavior and to remind customers to use the system 12 after a period of dormancy which is atypical to the users usual behavior patterns

An accounting module 30 is also provided in the system 12. The accounting module 30 is advantageously arranged to debit or facilitate debiting the retail account of the registered user 14 for at least a purchase price of the item and/service purchased by the registered user 14 if the user 14 passes the credit and/or risk management check administered by the module 28. As previously mentioned, the user 14 is typically a registered user 14. It follows that the system 12 conveniently comprises a registration module 32 arranged to register or facilitate registering a user to the system 12 (explained in greater detail below). For ease of explanation, the user to be registered by the module 32 already has a retail account with the retailer. However, the registration module 32 may also be arranged to register users which do not have retail accounts with the retailer. This comprises receiving and storing information associated with the user 14.

The system 12 further comprises a voucher management module 34 arranged to retrieve or generate vouchers to allow the registered user to purchase at least one item and/or service therewith. The module 34 may be actuated after the module 28 gives the go-ahead for a particular transaction. The vouchers may be for a particular financial or monetary amount associated with the goods desired to be purchased by the registered user 14 as will be described below.

It will be appreciated that the vouchers may be obtained or retrieved from a database or they may be generated.

The system 12 conveniently comprises a transmitter module 36 arranged to transmit the vouchers to the registered user 14. The transmitter module 36 may be similar to the receiver module 24. In a preferred example embodiment the transmitter module 36 forms part of the receiver module 24 or a communication module (not illustrated) in general.

In any event, the transmitter module 36 and the receiver module 24 may operatively facilitate communication between the transaction system 12 and the retailer's authorisation system 20.

Example embodiments will now be further described in use with reference to Figures 3 to 7. The example methods shown in Figures 3 to 7 are described with reference to Figures 1 and 2, although it is to be appreciated that the example methods may be applicable to other networks and/or systems (not illustrated) as well.

Referring to Figure 3 of the drawing where a high level flow diagram of a method for facilitating a financial transaction is generally indicated by reference numeral 40.

When a registered user 14 desires to conduct a financial transaction, for example to purchase airtime or an airtime voucher to recharge their mobile telephone account, they conveniently connect to the system 12 from a remote location. This obviates the need for the user 14 to go into a retailer to use their account to facilitate the purchase.

The user 14 typically connects to the system 12 by initiating a USSD or preferably a mobile web session via their mobile telephone. The user 14 can alternatively connect to the system 12 by way of SMS messages, Internet website, or the call center 18 as hereinbefore described.

The system 12 may be conveniently arranged to identify the user 14 from the IMSI, IMEI, or MSISDN of their mobile telephone. In other example embodiments, the user 14 is identified by their username.

The method 40 comprises receiving, at block 42, a unique identifier or PIN code from the registered user 14 via the receiver module 22 as hereinbefore described.

The method 40 then comprises validating, at block 44 by way of the validation module 26, the received unique identifier thereby to proceed with the financial transaction. It will be appreciated that if the PIN is incorrect, the method 40 may comprise transmitting a suitable message to the user 14 by way of the transmitter module 36. The message may preferably be an SMS messsge. The validation module 26 typically compares the received PIN with a PIN stored in the database 22 for the particular user 14. It will be noted that the system may prompt the user 14 for additional information in which to assist in validating the PIN, for example the identity of the user 14, or the like.

If the unique identifier or PIN is validated by the validation module 26, the method 40 comprises performing a credit and/or risk management check, at block 46 by way of the module 28, on the registered user 14 or the retail account associated therewith. It will be noted that at this step, the method 40 comprises checking the fraud score associated with the user by way of the module 28 to determine the probability of the user 14 committing a fraudulent transaction. It will be noted that suitable corrective action or a flag may be raised if there is a good chance that the user is about to make a fraudulent transaction, for example, extra steps may be taken to allow a transaction to proceed. The credit profile advantageously comprises information indicative of the fraud score associated with the user 14.

It is then determined, at block 48, if the user 14 passes the check in step 46, the method 40 comprises debiting, at block 50 by way of the accounting module 30, the retail account at a retailer of the registered user 14 for at least a purchase price of the item and/service purchased by the registered user 14, for example airtime for their cellular telephone.

It follows that if the user 14 does not pass the check in step 46, the method 40 comprises generating and transmitting, at block 52, a decline or unsuccessful transaction message to the user 14, typically in the form on an SMS message via the transmitter module 36, effectively informing the use 14 of the declining of the transaction.

Referring now to Figures 4 and 5 of the drawings where a process flow diagram comprising elements of the network 10 of Figure 1 is generally indicated by reference numeral 60 (Figure 4) and a flow diagram of a method in accordance with an example embodiment is generally indicated by reference numeral 70. The method 70 is similar to the method 40 and similar steps will be indicated by the same reference numerals. In an example embodiment, the method 70 may be a more detailed exposition of the method 40 for the purchase of an airtime voucher by the user 14.

In any event, the method 70 comprises receiving, at block 72, an initiating code from the user 14 via the receiver module 24 for example. The initiating code may be a code to initiate the transaction with the system 12 or to alert the system 12 that the user 14 intends on making a transaction by way of the system 12. The user 14 may typically transmit the initiating code via USSD, mobile web, SMS message, IVR, or the like. In one example embodiment, the initiating code allows the user 14 to connect to the system 12 for example to connect and initiate a LJSSD or mobile web session with the system 12. For ease of explanation, reference will be made to USSD or mobile web communication between the user 14 and the system 12.

In one example embodiment (not discussed), when the user 14 transmits the initiating code via their mobile telephone or mobile computing device, the system 12 may prompt the user 14 for their identity, username, or the like.

Once the user 14 is "logged" into the system 12 via the USSD or mobile web session, the method 70 comprises prompting, at block 74, the user 14 for their unique PIN.

The method 70 then comprises receiving the PIN from the user 14 via the receiver module 24 in the USSD or mobile web session and validating the received PIN by way of the validation module 44 as hereinbefore described with reference to steps 42 and 44 of method 40.

Once the PIN is validated the method 70 comprises transmitting, at block 76 by way of the transmitter module 36, a list of goods and/or services offered for sale to the user 14. The list may be retrieved from the database 22. The list may be updated when desired and/or at periodic intervals. The list advantageously allows the user 14 determine which goods and/or services they would like to purchase. In the example under discussion, the user 14 desires to purchase a virtual item in the form of airtime for their mobile telephone. In this regard the user 14 makes their selection for the airtime according to the service provider and the denomination or amount of airtime accordingly.

The method 70 then includes receiving, at block 78 via the receiver module 24, the selection or purchase request for example R50.00 of airtime from service provider X.

The method 70 then proceeds according to steps 46 and 48 as hereinbefore described for method 40 of Figure 3. However, if the user 14 passes the credit and/or risk management check of block 46, the method 70 comprises transmitting the purchase request to the retailer authorisation system 20 for authorisation of the purchase request, block 82. If the user 14 does not pass the check at block 46 then the method comprises transmitting, at block 80, a suitable message to the user 14 informing the same of the declined transaction. This message may be in the USSD or mobile web session or it may be an SMS message.

If the authorisation system 20 authorises the transaction then the method 70 comprises, at block 84, debiting the retail account of the user 14 for the amount of the purchase request i.e. R50.00 and retrieving or generating and transmitting a voucher, by way of the modules 34 and 36 respectively, to the user 14. The voucher may be an SMS message comprising a voucher code in the form of a recharge code for recharging the user's 14 airtime balance in the amount of R50.00. The user 14 may then use the voucher code to recharge their airtime balance with service provider X. In other example embodiments, the system 12 may be arranged to automatically recharge the airtime balance with the purchase amount selected by the user 14. It will be noted that the system 12 may be arranged to add a service fee amount to the purchase price debited from the retail account of the user 14.

Also in other example embodiments, the voucher or information indicative thereof, in the amount of the purchase request debited from the retail account of the user 14, may be presented to the retailer or other affiliated retailers or vendors of goods and/or services to purchase goods and/or service therefrom to the value of the purchase request. The information indicative or associated with the voucher may be a voucher code, or the like.

If the retailer's authorization system 20 declines the transaction for whatever reason, the system 12 may be arranged to forward, block 86, a message to the user 14 informing the user of the declined or unsuccessful transaction. It follows that the system 12 is arranged to interface with the system 20 in order to determine whether to generate the voucher and/or declining message. The declining message may be in the form of an SMS message, or the like.

It will be noted that in an example embodiment, an online authorisation request is still sent to the retailer. The first check is therefore by way of the system 12, to ensure the customer is still within their daily/monthly transaction limits. The second check is the authorisation with the retailer to ensure there are funds available on the retail account of the user 14

It will be appreciated that the user 14 needs to firstly register to the system 12 in order to perform a transaction as delineated above. In this light, reference is made to Figures 6 and 7 of the drawings. Figure 6 illustrates a process flow diagram 90 for registering the user 14 in accordance with an example embodiment with illustrated elements of the network 10 of Figure 1, and Figure 7 illustrates a flow diagram 100 of a method of registering the user 14. The registration module 32 operatively oversees or manages the registration and the interaction of the relevant modules of the system 12 in order to register the user 14 to the system 14. As previously mentioned, the user 14 typically has a retail account with the retailer which manages the retail authorisation system 20. However, in order to make use of the system 12 the user 14 needs to register to use the system 12.

The user 14 can be contacted by a call center agent 18 to register or the user 14 can self-register with the system 12 using USSD, IVR, SMS messages, an Internet registration webpage, or the like. For ease of explanation, the latter example embodiment where for example the user 14 self-registers via a USSD session will be discussed.

It will be appreciated that the user 14 logs on to the system 12 via a USSD session i.e. the user 14 initiates a USSD session with the system 12 by way of their mobile computing device.

The system 12 may typically prompt the user 14 for validation information, the validation information comprising at least information to identify the user 14 and/or the retail account of or associated with the user 14.

It follows that in Figure 7, the method 100 comprises receiving, at block 102, validation information from the user 14 typically via the receiver module 24.

The method 100 advantageously comprises performing a credit and/or risk management check, at block 104 by way of module 28, on the user 14 or the retail account of the user 14. The step 104 may be similar to the step 46.

It then is determined, at block 106 similarly to block 48, if the user 14 passes the check of block 104.

If the user 14 passes the check at block 104, the method 100 comprises transmitting, at block 108 via the transmitter module 36, a registration request to the retailer's authorisation system 20 to authorise registration of the user 14 to the system 12. It follows that if the user 14 does not pass the check at block 104 then the method 100 comprises transmitting, at block 110, a suitable message to the user 14 informing the same of the declined or unsuccessful registration.

It is determined, at block 112, if the retailer's authorisation system 20 authorises or declines the registration request. If the retailer authorises the registration the method 100 would then comprise generating and transmitting the unique identifier or PIN to the user 14. In other example embodiments, the user 14 may select their own PIN. In any event, it is important that the PIN is uniquely associated with the user 14 and/or the user's account at the retailer.

The method 100 may preferably comprise (not shown) storing the unique identifiers in the database 22 and associating the same with respective users 14 and/or retail accounts of users 14.

If the retailer's authorisation system 20 declines the registration application, the method 100 comprises transmitting, at block 116, a message indicating a declined or unsuccessful registration to the user 14. This message may be a pre-generated message stored in the database 22 and may be the same or similar message transmitted to the user 14 in step 110.

It will be understood that at the end of the method 100, the user 14 is advantageously registered to the system 12.

The method 100 may also advantageously comprise allocating the registered user 14 a credit and/or risk tier as hereinbefore described. Information indicative of the risk tier may be stored in the database 22 and associated with the relevant user 14. In this regard the database 22 may comprise a profile of each user 14 of the system 12, the information stored in the database 22 being associated with each user 14 may be stored against the relevant profile of the user 14 in the database 22. It will be noted that the methods 40, 70, and 100 are advantageously performed in real-time or on-line. Also, the methods may be computer implemented methods or may be facilitated to a large degree by computers.

The system 12 may advantageously comprise an off-line wallet (not shown) to facilitate the transactions as hereinbefore mentioned for example when the retailer's authorisation system 20 is down. Based on the tier allocated to the user 14, an off-line limit may also be allocated to the user 14 for a maximum purchase price of goods and/or service which the user 14 can purchase when the system 20 is off-line. The off-line wallet may be stored in the database 22 and associated with the user 14. The purchase will then be risk checked on the system 12 hereinbefore explained, however, the check to the retailer will be performed against this off-line wallet.

Figure 8 shows a diagrammatic representation of machine in the example form of a computer system 200 within which a set of instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed. In alternative embodiments, the machine operates as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine may operate in the capacity of a server or a client machine in server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may be a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term "machine" shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein. The example computer system 200 includes a processor 202 (e.g., a central processing unit (CPU), a graphics processing unit (GPU) or both), a main memory 204 and a static memory 206, which communicate with each other via a bus 208. The computer system 200 may further include a video display unit 210 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system 200 also includes an alphanumeric input device 212 (e.g., a keyboard), a user interface (Ul) navigation device 214 (e.g., a mouse), a disk drive unit 216, a signal generation device 218 (e.g., a speaker) and a network interface device 220.

The disk drive unit 216 includes a machine-readable medium 222 on which is stored one or more sets of instructions and data structures (e.g., software 224) embodying or utilized by any one or more of the methodologies or functions described herein. The software 224 may also reside, completely or at least partially, within the main memory 204 and/or within the processor 202 during execution thereof by the computer system 200, the main memory 204 and the processor 202 also constituting machine-readable media.

The software 224 may further be transmitted or received over a network 226 via the network interface device 220 utilizing any one of a number of well-known transfer protocols (e.g., HTTP).

While the machine-readable medium 222 is shown in an example embodiment to be a single medium, the term "machine-readable medium" should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term "machine-readable medium" shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present invention, or that is capable of storing, encoding or carrying data structures utilized by or associated with such a set of instructions. The term "machine-readable medium" shall accordingly be taken to include, but not be limited to, solid-state memories, optical and magnetic media, and carrier wave signals.

The invention as hereinbefore described provides a convenient way for a user to conduct transactions. In particular, the invention provides at least a user with the convenience of being able to use any mobile phone to conduct transactions, purchase virtual products and services, 24 hours a day, 7 days a week from any location. Another advantage of the present invention is that the system provides advanced credit and/or risk management tools thus maximizing net profit on products. The system as described has full plug and play capability to allow the system to interface with a plurality of retailers. The invention also provides a transaction system where the user's payment is processed on-line or in real-time on the user's retail account and the details of the payment is reflected or requested on the users account statement from the retailer.

It will be appreciated that many modifications or variations of the invention are possible without departing from the spirit or scope of the invention.

Claims

1. A system for facilitating a financial transaction, the system comprising:

a credit and/or risk management module arranged to perform a credit and/or risk management check for the registered user and the financial transaction, using at least the credit profile associated with the user, thereby to determine if the financial transaction is allowed, or not, based, at least in part, on the credit profile of the user; and

an accounting module configured to facilitate processing the financial transaction if the credit and/or risk management module determines that the financial transaction is allowed.

2. The system as claimed in Claim 1 , wherein the system comprises a transmitter module configured at least to transmit a rejection message to a user in response to the validation module determining that the received unique identifier is invalid or in response to the credit and/or risk management module determining that the financial transaction is not allowed.

3. The system as claimed in Claim 2, wherein the receiver module and transmitter module is adapted to communicate, in real-time with the user at a remote location, via one or more of at least a USSD (Unstructured Supplementary Service Data) session, web or mobile web session, SMS (Short Message Service) messages, or an IVR (Interactive Voice Response) session.

4. The system as claimed in any one of Claims 1 to 3, wherein the financial transaction comprises a purchase, by the user, of items/s and/or service/s offered for sale by a retailer, the accounting module is therefore configured to debit a retail account of the user for at least a purchase price of the item and/service purchased by the user if the credit and/or risk management module determines that the financial transaction is allowed.

5. The system as claimed in claim 4, wherein the retail account is provided for a user at the retailer, wherein the accounting module is configured to forward information indicative of the transaction to the retailer for authorisation and/or processing.

6. The system as claimed in any one of the preceding claims, wherein the credit profile comprises at least one credit level or tier which is assigned to a user, or vice versa, based on a credit behavior pattern and/or fraud score associated with the user.

7. The system as claimed in Claim 6, wherein each credit tier comprises predetermined limits or rules which determine a maximum monetary amount which a user can spend daily and/or monthly and/or the number of transactions that can be performed on a daily and/or monthly basis, wherein the credit and/or risk management module is configured at least to determine if the financial transaction is at least within the predetermined limits or rules corresponding to the credit tier associated with the user.

8. The system as claimed in any one of Claims 3 to 7, wherein the system is configured to retrieve a virtual item from the retailer and transmit the same to the user by way of the transmitter module.

9. The system as claimed in Claim 8, wherein the virtual item is a prepaid airtime voucher for a crediting a mobile telephone account of a user.

10. The system as claimed in any one of the preceding claims, wherein the system comprises a registration module configured to receive information from a user via the receiver module to register the user to the system.

11. The system as claimed in any one of Claims 2 to 10, the system further comprising a voucher management module configured to retrieve or generate vouchers in response to at least the credit and/or risk management module determining that the financial transaction is allowed, which vouchers are transmitted to the user via the transmitter module, and wherein the vouchers are usable in trade to purchase at least one item and/or service.

12. The system as claimed in any one of the preceding claims, wherein the system further comprises an off-line wallet associated with each user, each off-line wallet being configured to be debited by the accounting module instead of a retail account associated with the user at least when an authorisation system associated with the retailer is down or unavailable.

13. A method of operating a system for facilitating a financial transaction, the method comprising: receiving, by way of a receiver module, an input of a unique identifier from a user and information relating to the financial transaction which the user wishes to engage in;

validating, by way of a validation module, the received unique identifier thereby to proceed with the financial transaction;

14. The method as claimed in claim 13, wherein the method comprises transmitting, by way of a transmitter module, a rejection message to a user in response to determining that the received unique identifier is invalid or in response to determining that the financial transaction is not allowed.

15. The method as claimed in claim 14, wherein the method comprises communicating with the user, at a remote location, in real-time via one or more of at least a USSD (Unstructured Supplementary Service Data) session, web or mobile web, SMS (Short Message Service) messages, or an IVR (Interactive Voice Response) session.

16. The method as claimed in any one of Claims 13 to 15, wherein the financial transaction comprises a purchase, by the user, of items/s and/or service/s offered for sale by a retailer, the method therefore comprising operating the accounting module to facilitate debiting a retail account of the user, at a retailer, for at least a purchase price of the item and/service purchased by the registered user if the user passes the credit and/or risk management check.

17. The method as claimed in any one of Claims 13 to 16, wherein the credit profile comprises at least one credit level or tier which is assigned to a user, or vice versa, based on a credit behavior pattern and/or fraud score associated with the user.

18. The method as claimed in Claim 17, wherein each tier comprises predetermined limits or rules which determine a maximum monetary amount which a user is allowed to spend daily and/or monthly and/or the number of transactions that can be performed on a daily and/or monthly basis, the credit and/or risk management check therefore comprises at least determining if the financial transaction is at least within the predetermined limits or rules corresponding to the credit tier associated with the user.

19. The method as claimed in any one of Claims 16 to 18, the method comprising retrieving a virtual item from the retailer and transmitting the same to the user by way of the transmitter module.

20. The method as claimed in Claim 19, wherein the virtual item is a pre-paid airtime voucher for a crediting a mobile telephone account of a user.

21. The method as claimed in any one of Claims 13 to 20, wherein the method comprising registering a user to the transaction system by way of a registration module.

22. The method as claimed in Claim 21 , wherein registering a user to the transaction system comprises the steps of:

performing a credit and/or risk management check on the user or the retail account of the user;

transmitting a request to the retailer to authorise registration of the user to the system if the user passes the credit and/or risk management check; and

23. The method as claimed in claim 22, wherein the method comprises generating and transmitting a unique identifier to the user once the user has been registered to the system.

24. The method as claimed in claim 23, wherein the unique identifiers are stored in a database together with respective information associated with the user or the retail account of the user.

25. The method as claimed in any one of Claims 13 to 24, the method comprising:

retrieving or generating vouchers, in response to at least the credit and/or risk management module determining that the particular transaction is allowed, which vouchers being usable in trade to purchase at least one item and/or service; and transmitting the vouchers to the user.

26. The method as claimed in any one of Claims 16 to 25, wherein the method comprises transmitting the purchase request to the retailer for authorisation after the user passes the credit and/or risk management check.

27. The method as claimed in claim 26, wherein the method comprises receiving authorisation from the retailer to debit the retail account of the user.

28. The method as claimed in any of claims 12 to 26, wherein the method comprises debiting an off-line wallet associated with a user, by way of the accounting module, instead of a retail account associated with the user at least when an authorisation system associated with the retailer is down or unavailable.

29. A set of computer executable instructions, which when executed by a machine, causes the machine to perform the steps of:

performing a credit and/or risk management check for the registered user and the particular transaction, using at least a credit profile associated with the user, thereby to determined if the financial transaction is allowed, or not, based, at least in part, on the credit profile of the user; and processing the particular transaction if the credit and/or risk management module determines that the financial transaction is allowed.

30. A system substantially as described herein with reference to the accompanying drawings.

31. A method substantially as described herein with reference to the accompanying drawings.