Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
SERVER AND METHOD FOR MANAGING AN ACCOUNT
Document Type and Number:
WIPO Patent Application WO/2019/059847
Kind Code:
A1
Abstract:
In one aspect, there is provided a server for managing an account for a user who does not own a bank account, the account suitable for non-credit cash transactions, the server comprising: at least one processor; and at least one memory including computer program code; the at least one memory and the computer program code configured to, with the at least one processor, cause the server at least to: receive, from a user device, information relating to the user; generate the account in response to a verification of the received information; send, to the user device, details relating to the generated account, the generated account being to be used for cash amount to be transacted

Inventors:
ALABEDE OLASENI (US)
MONTET FRANCIS (KE)
CLARK KEISHA (NG)
Application Number:
PCT/SG2018/050483
Publication Date:
March 28, 2019
Filing Date:
September 21, 2018
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
MASTERCARD LABS KENYA HOLDINGS PTE LTD (SG)
International Classes:
G06Q20/02; G06Q20/36
Foreign References:
US20120310824A12012-12-06
US20120191596A12012-07-26
US20140310153A12014-10-16
CN105550928A2016-05-04
Attorney, Agent or Firm:
SPRUSON & FERGUSON (ASIA) PTE LTD (SG)
Download PDF:
Claims:
CLAIMS

What is claimed is:

1. A server for managing an account for a user who does not own a bank account, the account suitable for non-credit cash transactions, the server comprising:

at least one processor; and

at least one memory including computer program code;

the at least one memory and the computer program code configured to, with the at least one processor, cause the server at least to: receive, from a user device, information relating to the user;

generate the account in response to a verification of the received information; send, to the user device, details relating to the generated account, the generated account being to be used for cash amount to be transacted.

The server according to claim 1, wherein the at least one memory and the computer program code is further configured with the at least one processor to:

generate an account identifier identifying the account and the user; and send, to the user device, the generated account identifier in response to a input.

3. The server according to any one of the preceding claims, wherein the at least one memory and the computer program code is further configured with the at least one processor to:

receive, from a device, transaction details for a transaction between the user and a party, the transaction details indicating the generated account identifier.

4. The server according to claim 1 or 2, wherein the at least one memory and the computer program code is further configured with the at least one processor to:

receive, from a device, details relating to a party of the transaction relating to the transaction details.

5. The server according to claim 3 or 4, wherein the at least one memory and the computer program code is further configured with the at least one processor to:

update, a database, in response to the receipt of the cash transaction details.

6. The server according to claim 5, wherein the at least one memory and the computer

program code is further configured with the at least one processor to:

receive, from the user device, a loan request, the loan request including the generated account identifier;

retrieve, from the database, historical transaction details relating to historical transactions that have been completed relating to the generated account identifier over a predetermined period of time; and

facilitate the loan request in response to a determination if the historical transactions satisfy a predetermined criteria.

7. The server according to claim 6, wherein the at least one memory and the computer

program code is further configured with the at least one processor to:

forward, to another server, the loan request, the other server relating to a financial institution indicated in the loan request.

8. The server according to claim 7, wherein the at least one memory and the computer

program code is further configured with the at least one processor to:

receive, from the other server, a loan approval message informing that the loan request has been approved by the financial institution.

9. The server according to claim 8, wherein the at least one memory and the computer

program code is further configured with the at least one processor to:

receive, from the user device, an amount indicated in the loan request; and update, the database, with a timestamp indicating the time at which the amount is received.

10. The server according to claim 9, wherein the at least one memory and the computer

program code is further configured with the at least one processor to:

generate a reliability score for the user in response to the updated timestamp.

11. The server according to claim 3 or 4, wherein the device is the user device.

12. A computer-implemented method for managing an account for a user who does not own a bank account, the account suitable for non-credit cash transactions, the method comprising: receiving, from a user device, information relating to the user; generating the account in response to a verification of the received information;

sending, to the user device, details relating to the generated account, the generated account being to be used for cash amount to be transacted.

13. The method according to claim 12, further comprising:

generating an account identifier identifying the account and the user; and sending, to the user device, the generated account identifier in response to a user input.

14. The method according to claim 12 or 13, further comprising:

receiving, from a device, transaction details for a transaction between the user and a party, the transaction details indicating the generated account identifier.

15. The method according to claim 12 or 13, further comprising:

receiving, from a device, details relating to a party of the transaction relating to the transaction details.

16. The method according to claim 14 or 15, further comprising:

updating, a database, in response to the receipt of the cash transaction details.

17. The method according to claim 16, further comprising:

receiving, from the user device, a loan request, the loan request including the generated account identifier; retrieving, from the database, historical transaction details relating to historical transactions that have been completed relating to the generated account identifier over a predetermined period of time; and

facilitating the loan request in response to a determination if the historical transactions satisfy a predetermined criteria.

18. The method according to claim 17, further comprising:

forwarding, to another server, the loan request, the other server relating to a financial institution indicated in the loan request.

19. The method according to claim 18, further comprising:

receiving, from the other server, a loan approval message informing that the loan request has been approved by the financial institution.

20. The method according to claim 19, further comprising:

receiving, from the user device, an amount indicated in the loan request; and updating, the database, with a timestamp indicating the time at which the amount is received.

21. The method according to claim 20, further comprising:

generating a reliability score for the user in response to the updated timestamp.

22. The method according to claim 14 or 15, wherein the device is the user device.

Description:
SERVER AND METHOD FOR MANAGING AN ACCOUNT

TECHICAL FIELD

[0001] The present invention relates broadly, but not exclusively, to servers and methods for managing an account, especially for a user who does not have a bank account. In some embodiments, the servers and methods may be configured to collect information relevant to the customer (e.g., KYC data)

BACKGROUND

[0002] With the proliferation of mobile communication devices, such as mobile telephones, financial account holders that have such devices have begun to use them to effect financial transactions.

[0003] Recently, there is an increasing and significant number of users effecting financial transactions online e.g., using the Internet or via a mobile device application program. It is known that the merchants are limited to use accounts that they have with financial institutions.

[0004] However, this is impossible for micro -merchants and micro- small-medium enterprises who do not have the adequate collateral to have a relevant account with the financial institutions. There are two billion of such entities who are financially excluded, one million of which is in Africa. While there are financial programs in place to assist these entities, only a small percentage is successful. For example, four out of twenty such programs are successful in Africa.

[0005] In the recent time, financial institutions have enhanced the way in which they provide their services. For example, financial institutions can post descriptions of their on-going promotions e.g., low interest rate loans, which can then be searched by users who use their application program. If a user is interested in a posted promotion, the user can contact a financial institution, usually one with which the user has an account, to get the low-interest rate open. For users who do not have accounts with such financial institutions, either they will not be aware of these on-going openings or they have to first open an account with the financial institutions. Thus, these types of application programs are still based on the traditional process of account opening at a financial institution.

[0006] While such application programs have provided an improved level of convenience to financial institutions, known resources nevertheless suffer from a number of disadvantages and inconveniences associated with the time consuming process of posting on-line promotions, reviewing application forms mailed or submitted by users, deciding which users are good candidates after reviewing application forms, contacting those users, and going through the application process. Further, this traditional process provides limited insight to the financial credibility of a user. Such traditional process typically takes about two days to one week to complete, creating barriers for the micro-merchants and micro- small-medium- enterprise.

[0007] A need therefore exists to provide methods and servers for managing an account with a user who typically does not own a bank-related account, using one of a plurality of accounts that addresses one or more of the above problems.

[0008] Furthermore, other desirable features and characteristics will become apparent from the subsequent detailed description and the appended claims, taken in conjunction with the accompanying drawings and this background of the disclosure.

SUMMARY

[0009] In an aspect, there is provided a server for managing an account for a user who does not own a bank account, the server comprising:

at least one processor; and

at least one memory including computer program code;

the at least one memory and the computer program code configured to, with the at least one processor, cause the server at least to: receive, from a user device, information relating to the user; generate the account in response to a verification of the received information;

send, to the user device, details relating to the generated account, the generated account being to be used for .

[0010] In an embodiment, the at least one memory and the computer program code is further configured with the at least one processor to:

generate an account identifier identifying the account and the user; and

send, to the user device, the generated account identifier in response to a user input.

[0011] In an embodiment, the at least one memory and the computer program code is further configured with the at least one processor to:

receive, from a device, transaction details for a transaction between the user and a party, the transaction details indicating the generated account identifier.

[0012] In an embodiment, the at least one memory and the computer program code is further configured with the at least one processor to:

receive, from a device, details relating to a party of the transaction relating to the transaction details.

[0013] In an embodiment, the at least one memory and the computer program code is further configured with the at least one processor to:

update, a database, in response to the receipt of the transaction details.

[0014] In an embodiment, at least one memory and the computer program code is further configured with the at least one processor to:

receive, from the user device, a loan request, the loan request including the generated account identifier;

retrieve, from the database, historical transaction details relating to historical transactions that have been completed relating to the generated account identifier over a predetermined period of time; and

facilitate the loan request in response to a determination if the historical transactions satisfy a predetermined criteria. [0015] In an embodiment, the at least one memory and the computer program code is further configured with the at least one processor to:

forward, to another server, the loan request, the other server relating to a financial institution indicated in the loan request.

[0016] In an embodiment, the at least one memory and the computer program code is further configured with the at least one processor to:

receive, from the other server, a loan approval message informing that the loan request has been approved by the financial institution.

[0017] In an embodiment, the at least one memory and the computer program code is further configured with the at least one processor to:

receive, from the user device, an amount indicated in the loan request; and

update, the database, with a timestamp indicating the time at which the amount is received.

[0018] In an embodiment, the at least one memory and the computer program code is further configured with the at least one processor to:

generate a reliability score for the user in response to the updated timestamp.

[0019] In an embodiment, the device is the user device.

[0020] In an aspect, there is provided a computer-implemented method for managing an account for a user who does not own a bank account, the account suitable for non-credit transactions, the method comprising: receiving, from a user device, information relating to the user;

generating the account in response to a verification of the received information;

sending, to the user device, details relating to the generated account, the generated account being to be used f.

[0021] In an embodiment, the method further comprises generating an account identifier identifying the account and the user; and sending, to the user device, the generated account identifier in response to a user input.

[0022] In an embodiment, the method further comprises receiving, from a device transaction details for a transaction between the user and a party, the transaction details indicating the generated account identifier.

[0023] In an embodiment, the method further comprises receiving, from a device, details relating to a party of the transaction relating to thetrans action details.

[0024] In an embodiment, the method further comprises updating, a database, in response to the receipt of the transaction details.

[0025] In an embodiment, the method further comprises receiving, from the user device, a loan request, the loan request including the generated account identifier;

retrieving, from the database, historical transaction details relating to historical transactions that have been completed relating to the generated account identifier over a predetermined period of time; and

facilitating the loan request in response to a determination if the historical transactions satisfy a predetermined criteria.

[0026] In an embodiment, the method further comprises:

forwarding, to another server, the loan request, the other server relating to a financial institution indicated in the loan request.

[0027] In an embodiment, the method further comprises:

receiving, from the other server, a loan approval message informing that the loan request has been approved by the financial institution.

[0028] In an embodiment, the method further comprises:

receiving, from the user device, an amount indicated in the loan request; and updating, the database, with a timestamp indicating the time at which the amount is received. [0029] In an embodiment, the method further comprises:

generating a reliability score for the user in response to the updated timestamp.

[0030] In an embodiment, the device is the user device.

BRIEF DESCRIPTION OF THE DRAWINGS

[0031] Embodiments of the invention will be better understood and readily apparent to one of ordinary skill in the art from the following written description, by way of example only, and in conjunction with the drawings, in which:

[0032] Figure 1 shows a block diagram of a transaction system 100 within which an account can be managed.

[0033] Figure 2 shows a flow chart illustrating a computer-implemented method for managing an account according to an example embodiment.

[0034] Figure 3 shows a schematic diagram of a computer system suitable for use in executing the method depicted in Figure 2.

[0035] Figure 4 shows an exemplary computing device to realize a server for the payment network server 108 shown in Figure 1.

[0036] Figures 5A-5D show schematic diagrams illustrating different aspects of the problem to which embodiments of the method and system of the present invention seek to solve.

[0037] Figure 6 shows typical profiles of a merchant according to an example embodiment.

[0038] Figures 7A-7B show schematic diagrams illustrating features of the system depicted in Figure 3 according to an example embodiment.

[0039] Figures 8A-8B show schematic diagrams illustrating the working of the system depicted in Figure 3 according to an example embodiment.

[0040] Figures 9A-9E show schematic diagrams illustrating a user interface of the system depicted in Figure 3 according to an example embodiment.

[0041] Figure 10 shows a schematic diagram illustrating a value chain of the system depicted in Figure 3 according to an example embodiment. [0042] Figures 11A-11C show schematic diagrams illustrating benefits of the system depicted in Figure 3 according to an example embodiment.

[0043] Figures 12A-12B show schematic diagrams illustrating the different markets for implementation of the system depicted in Figure 3 according to an example embodiment.

[0044] Figure 13 shows a table illustrating the differences between similar systems and the system depicted in Figure 3 according to an example embodiment.

[0045] Figures 14A-14B show tables illustrating various estimated capital expenses of the system depicted in Figure 3 according to an example embodiment.

DETAILED DESCRIPTION

[0046] Embodiments of the present invention will be described, by way of example only, with reference to the drawings. Like reference numerals and characters in the drawings refer to like elements or equivalents.

[0047] Some portions of the description which follows are explicitly or implicitly presented in terms of algorithms and functional or symbolic representations of operations on data within a computer memory. These algorithmic descriptions and functional or symbolic representations are the means used by those skilled in the data processing arts to convey most effectively the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self -consistent sequence of steps leading to a desired result. The steps are those requiring physical manipulations of physical quantities, such as electrical, magnetic or optical signals capable of being stored, transferred, combined, compared, and otherwise manipulated.

[0048] Unless specifically stated otherwise, and as apparent from the following, it will be appreciated that throughout the present specification, discussions utilizing terms such as "scanning", "calculating", "analysing", "determining", "replacing", "generating", "initializing", "outputting", "receiving", "retrieving", "identifying", "predicting" or the like, refer to the action and processes of a computer system, or similar electronic device, that manipulates and transforms data represented as physical quantities within the computer system into other data similarly represented as physical quantities within the computer system or other information storage, transmission or display devices.

[0049] The present specification also discloses server for performing the operations of the methods. Such server may be specially constructed for the required purposes, or may comprise a computer or other device selectively activated or reconfigured by a computer program stored in the computer. The algorithms and displays presented herein are not inherently related to any particular computer or other server. Various machines may be used with programs in accordance with the teachings herein. Alternatively, the construction of more specialized server to perform the required method steps may be appropriate. The structure of a computer will appear from the description below.

[0050] In addition, the present specification also implicitly discloses a computer program, in that it would be apparent to the person skilled in the art that the individual steps of the method described herein may be put into effect by computer code. The computer program is not intended to be limited to any particular programming language and implementation thereof. It will be appreciated that a variety of programming languages and coding thereof may be used to implement the teachings of the disclosure contained herein. Moreover, the computer program is not intended to be limited to any particular control flow. There are many other variants of the computer program, which can use different control flows without departing from the spirit or scope of the invention.

[0051] Furthermore, one or more of the steps of the computer program may be performed in parallel rather than sequentially. Such a computer program may be stored on any computer readable medium. The computer readable medium may include storage devices such as magnetic or optical disks, memory chips, or other storage devices suitable for interfacing with a computer. The computer readable medium may also include a hard-wired medium such as exemplified in the Internet system, or wireless medium such as exemplified in the GSM mobile telephone system. The computer program when loaded and executed on such a computer effectively results in a server that implements the steps of the preferred method.

[0052] In embodiments of the present invention, use of the term 'server' may mean a single computing device or at least a computer network of interconnected computing devices which operate together to perform a particular function. In other words, the server may be contained within a single hardware unit or be distributed among several or many different hardware units.

[0053] In the following description, a user (or a merchant) may refer to one who has an account identifier. In specific embodiments, the account identifier may be linked to various financial institutions. For example, a user may sign up for a universal account so as to be linked to various financial institutions. The user is also a customer who initiates a transaction with a supplier with whom the user uses an account relating to the account identifier to pay the supplier (or transfer an amount from the account). Additionally or alternatively, the user is also a merchant with whom a customer has initiated a transaction to buy good and/or services from the user (or transfer an amount to the account). In an embodiment, the transaction is a payment transaction. In other words, effecting the transaction involves a payment between parties to the transaction.

[0054] FIG 1 illustrates a block diagram of a transaction system 100 within which transaction data can be received.

[0055] The system 100 comprises a transaction device 102 in communication with a merchant device 104. The merchant device 104 may also be in direct communication with a payment network server 108, without having to communicate with the transaction device 102.

[0056] The merchant device 104 is in communication with an acquirer server 106. The acquirer server 106, in turn, is in communication with the payment network server 108. The payment network server 108, in turn, is in communication with an issuer server 110.

[0057] The transaction device 102 typically is associated with a customer (or supplier) who is a party to a transaction that occurs between the transaction device 102 and the merchant device 104 through a transaction. The transaction device 102 may be a fixed (wired) computing device or a wireless (portable) computing device. In specific implementations, the transaction device 102 may be a handheld or portable or mobile device carried or used by the customer, or may refer to other types of electronic devices such as a personal computer, a land-line telephone or an interactive voice response (IVR) system and the like. The mobile device may be a device, such as a mobile phone, a laptop computer, a personal digital computer (PDA), a mobile computer, a portable music player (such as an iPod™ and the like).

[0058] The merchant device 104 typically is associated with the merchant who is also a party to the transaction that occurs between the transaction device 102 and the merchant device 104 through the transaction. The merchant device 104 may be a point-of-sale (POS) terminal, an automatic teller machine (ATM), a personal computer, a computer server (hosting a website, for example), an IVR system, a land-line telephone, or any type of mobile device such as a mobile phone, a personal digital assistant (PDA), a laptop computer, a tablet computer and the like.

[0059] The acquirer server 106 generally is associated with an acquirer who may be an entity (e.g. a company or organization) which issues (e.g. establishes, manages, administers) a transaction credential or an account (e.g. a financial bank account). Examples of the acquirer include a bank and/or other financial institution (or lender). As stated in the above, the acquirer server 106 may include one or more computing devices that are used to establish communication with another server by exchanging messages with and/or passing information to the other server. In various embodiments below, the acquirer may be known as a financial institution referring to one who may loan funds to a merchant and the acquirer server 106 may be an other server.

[0060] The payment network server 108 typically is associated with a payment facilitator. For example, the payment network server 108 may be the Banknet® network operated by MasterCard®. The payment facilitator (e.g. MasterCard®) may be an entity (e.g. a company or organization) who operates to process transactions, clear and settle funds for payments between two entities (e.g. two banks). The payment network server 108 may include one or more computing devices that are used for processing transactions. For various embodiments below, the payment facilitator (e.g. MasterCard®) may be an entity (e.g. a company or organization) which issues (e.g. establishes, manages, administers) a transaction credential or an account (e.g. a financial bank account) of the merchant. An exemplary payment network server 108 is shown in Figure 4. [0061] The issuer server 110 generally is associated with an issuer and may include one or more computing devices that are used to perform a payment transaction. The issuer may be an entity (e.g. a company or organization) which issues (e.g. establishes, manages, administers) a transaction credential or an account (e.g. a financial bank account). An account may be associated with a plurality of transaction devices 102. In various embodiments below, the acquirer may be known as a financial institution referring to one who may loan funds to a merchant and the acquirer server 106 may be another server.

[0062] The payment network server 108 may be configured to communicate with, or may include, a database (or a transaction database) 109. The transaction database 109 stores data corresponding to a transaction (or transaction data). Examples of the data include Transaction ID, Merchant ID, Merchant Name, MCC / Industry Code, Industry Description, Merchant Country, Merchant Address, Merchant Postal Code, Aggregate Merchant ID and or other relevant information that is provided when the merchant signs up for an application program as a user. For example, data ("Merchant name" or "Merchant ID") relating to the merchant, time and date for which the goods/ services relating to the transaction will be delivered are included in the database 109. The database 109 may include a reliability score for each merchant (or user of an application program) indicating how reliable the user is. One of the criteria to determine how reliable the user is whether or not the user has settled the transactions within a predetermined time period based on the timestamp indicating a time at which a payment for a loan is made. For example, if the merchant has paid an amount required to satisfy a loan repayment scheme.

[0063] The transaction device 102 is capable of wireless communication using a suitable protocol with the merchant device 104. For example, embodiments may be implemented using transaction devices 102 that are capable of communicating with Wi-Fi / Bluetooth- enabled merchant devices 104. It will be appreciated by a person skilled in the art that depending on the wireless communication protocol used, appropriate handshaking procedures may need to be carried out to establish communication between the transaction device 102 and the merchant device 104. For example, in the case of Bluetooth communication, discovery and pairing of the transaction device 102 and the merchant device 104 may be carried out to establish communication. [0064] In an example, during a transaction, a transaction request message 112 is generated at the transaction device 102. The transaction request message 112 is generated by the transaction device 102 in response to the customer (or a party) making a selection of a good and/or service to be purchased from the merchant. In other words, the transaction request message 112 relates to a transaction between the customer and the merchant. The transaction may be performed at a retail shop of the merchant. In specific implementations, the transaction device 102 may be fitted with a wireless communications interface such as a Near Field Communication (NFC) interface to enable the transaction device 102 to electronically communicate with the merchant device 104 to perform the transaction. NFC is a set of standards to establish radio communication between devices by bringing them into close proximity such as only a few centimetres. NFC standards cover communication protocols and data exchange formats, and are based on radio-frequency identification (RFID) technology. That is, the transaction device 102 may have image capturing capabilities and capture an image of a quick response (QR) code displayed on the merchant device 104. The captured QR code includes an account identifier identifying the merchant and the merchant's account.

[0065] In order to obtain an account identifier, the merchant registers for an account on an application program executing on the merchant device. The application program is one that is managed by the payment network server 108. At the time of registering for the account, the merchant provides his information (e.g., name, a photograph, place of birth, contact number and date of birth) to the payment network server 108. The payment network server 108 may verify the information which may be in a form of checking if the received information is complete or check if the received information corresponds to a user in a black-list. The blacklist listing users with undesirable records who should not be permitted to register for an account. The payment network server 108 may generate an account in response to a verification of the received information. An account identifier will also be generated in response to a generation of the account. The account identifier may include some or all of the information relating to the user and the user account, and may be saved in the database 109.

[0066] The account identifier refers to a number of digits (or characters) which identify a universal account issued by an institution (for example, MasterCard™). For example, in some embodiments, an account is linked to an account which is issued by an issuer pursuant to the MasterCard International Incorporated rules, and the account identifier may be a twelve to nineteen-digit string that identifies both the issuer (which may be based on the first few digits of the string, for example, the first five to ten digits) and the client account at the issuer. The account identifier may also identify if the issuer is subscribed to a standardized Internet transaction protocols such as 3-D Secure™ Network. The 3-D Secure™ Network is consistent with and underlies the authentication programs offered by card issuers (for example, SecureCode™ by MasterCard) to authenticate client for merchant during a remote transaction such as those done over the Internet. The account identifier is typically utilized to route and process transactions that involve the account or those it is linked to. Those skilled in the art will appreciate that other account schemes and formats may be used in conjunction with embodiments described herein.

[0067] In other words, each transaction data relates to a transaction and identifies the party ( a customer or a supplier) and the merchant, generally by way of identifiers of each associated with the user and merchant respectively. Further, the transaction data may also identify the good and/or service to be purchased and a type or nature of the transaction. The transaction data may further identify a value or price of the good and/or service (e.g., a transaction amount) and a location where the good and/or service will be delivered. The transaction data may also indicate a time and date at which the transaction was initiated by the user. The transaction data may also include inputs that are manually entered by the user (or a merchant) in response to a receipt of a non-credit amount.

[0068] The following types of information may be considered linked to an account identifier:

Merchant information :-

• Location

• Interest

• Nature of business

• Size of business

Past transaction information: -

• Details of parties (customers or suppliers) with whom the user has effected transactions [0069] In an embodiment, the payment network server 108 is configured to process a request to sign up for the account and send a notification message to the merchant device 104 once it is determined that the account is set up. In an embodiment, the merchant device 104 may receive a short messaging service message to inform him about his account identifier.

[0070] As mentioned above, the role of the payment network server 108 is to facilitate communication between the merchant device 104 and/or acquirer server 106, the issuer server 110(a) and/or the issuer server 110(b). Therefore, the payment network server 108 may serve as a means through which the merchant device 104 may communicate with a financial institution in a manner that requests and loans may be accepted and forwarded.

[0071] In specific implementations, the payment network server 108 is further configured to perform additional operations. For example, the payment network server 108 may be configured to update the database 109 whenever a merchant registers for an account or pays his loans. Additionally, the payment network server 108 may also be configured to calculate a reliability score for each user based on the historical transactions (including repayment of loans) relating to the user. The historical transactions may be a ledger or a record of transactions that have been carried out using the account.

[0072] Such a server may be used to implement the method 200 shown in Fig. 2. Fig. 2 shows a flowchart illustrating a method 200 for managing an account with embodiments of the invention. The method 200 can be used to the user to at least a financial institution. For various embodiments below, pairing of a user with an at least a financial institution with whom the user does not have an account.

[0073] The method 200 broadly includes:

step 202: receiving, from a user device, information relating to the user step 204: generating the account in response to a verification of the received information; step 206: sending, to the user device, details relating to the generated account, the generated account being to be used for amount to be transacted.

[0074] The method 200 may be performed by one or more purpose-built computing devices, such as the payment network server 108 that is coupled to one or more databases. At step 202, a request to sign up for an account may be initiated by a merchant and information relating to the user may be received. The information may be at least one of a name, date of birth, place of birth and contact number of the merchant.

[0075] At step 204, the account is generated in response to a verification of the received information. This may be a simple verification by checking if all the fields necessary for registration have been filled in. In other embodiments, the payment network server 108 may do a check with a database to confirm if the information is factual and accurate.

[0076] At step 206, details relating to the generated account will be sent to the user device. The generated account being one that can be used for transactions.

[0077] Additionally, an account identifier is also generated, identifying the account and the user. In various embodiments, the account identifier is a QR code, including details of the account. The account identifier may then be sent to the user device. The QR code may be a static or a dynamic QR code. In response to a response to a user input to display the account identifier, a party (a customer or a supplier) to a transaction may be able to scan the QR code. Alternatively, if a consumer does not have a mobile device (e.g., a smartphone), it is possible for him to enter the details relating to the account (e.g., via USSD) so that the transaction can be completed.

[0078] In various embodiments the method comprise receiving, from a device, transaction details for a cash transaction between the user and a party, the transaction details indicating the generated account identifier. The device may be a user device or a device of the party (customer or a supplier).

[0079] In various embodiments, the method comprises updating, a database, in response to the receipt of the transaction details.

[0080] In various embodiments, the method comprises receiving, from the user device, a loan request, the loan request including the generated account identifier; retrieving, from the database, historical transaction details relating to historical transactions that have been completed relating to the generated account identifier over a predetermined period of time; and facilitating the loan request in response to a determination if the historical transactions satisfy a predetermined criteria. In an embodiment, the method comprises determining if the user has carry out a predetermined number of transactions within a predetermined period of time (e.g., a month) which is an indication of the user's situation.

[0081] In various embodiments, the method comprises forwarding, to another server, the loan request, the other server relating to a financial institution indicated in the loan request. The financial institution being one who subscribes to the service too.

[0082] In the event that the financial institution approves the loan, the method comprises receiving, from the other server, a loan approval message informing that the loan request has been approved by the financial institution. In response to the loan approval request, an amount indicated in the loan request will be forwarded to the user.

[0083] Additionally or alternatively, the method may include receiving, from the user device, an amount indicated in the loan request; and updating, the database, with a timestamp indicating the time at which the amount is received.

[0084] In various embodiments, the method comprises generating a reliability score for the user in response to the updated timestamp. The method may comprise determining if the reliability score is equal to or more than an issuer threshold score indicated in a corresponding issuer registration. In an embodiment, the user is presented to the issuer if it is determined that the reliability score of the user is equal to or more than the issuer threshold score. In other words, the issuer is willing to process a loan transaction with the user. [0085] Figure 3 depicts an exemplary computer / computing device 300, hereinafter interchangeably referred to as a computer system 300, where one or more such computing devices 300 may be used to facilitate execution of the above-described method. In addition, one or more components of the computer system 300 may be used to realize the computer 302. The following description of the computing device 300 is provided by way of example only and is not intended to be limiting.

[0062] As shown in Figure 3, the example computing device 300 includes a processor 304 for executing software routines. Although a single processor is shown for the sake of clarity, the computing device 300 may also include a multi-processor system. The processor 304 is connected to a communication infrastructure 306 for communication with other components of the computing device 400. The communication infrastructure 306 may include, for example, a communications bus, cross-bar, or network.

[0063] The computing device 300 further includes a main memory 308, such as a random access memory (RAM), and a secondary memory 310. The secondary memory 310 may include, for example, a storage drive 312, which may be a hard disk drive, a solid state drive or a hybrid drive and/or a removable storage drive 314, which may include a magnetic tape drive, an optical disk drive, a solid state storage drive (such as a USB flash drive, a flash memory device, a solid state drive or a memory card), or the like. The removable storage drive 314 reads from and/or writes to a removable storage medium 344 in a well-known manner. The removable storage medium 344 may include magnetic tape, optical disk, nonvolatile memory storage medium, or the like, which is read by and written to by removable storage drive 314. As will be appreciated by persons skilled in the relevant art(s), the removable storage medium 344 includes a computer readable storage medium having stored therein computer executable program code instructions and/or data.

[0064] In an alternative implementation, the secondary memory 310 may additionally or alternatively include other similar means for allowing computer programs or other instructions to be loaded into the computing device 300. Such means can include, for example, a removable storage unit 322 and an interface 340. Examples of a removable storage unit 322 and interface 340 include a program cartridge and cartridge interface (such as that found in video game console devices), a removable memory chip (such as an EPROM or PROM) and associated socket, a removable solid state storage drive (such as a USB flash drive, a flash memory device, a solid state drive or a memory card), and other removable storage units 322 and interfaces 340 which allow software and data to be transferred from the removable storage unit 322 to the computer system 300.

[0065] The computing device 300 also includes at least one communication interface 324. The communication interface 324 allows software and data to be transferred between computing device 300 and external devices via a communication path 326. In various embodiments of the inventions, the communication interface 324 permits data to be transferred between the computing device 300 and a data communication network, such as a public data or private data communication network. The communication interface 324 may be used to exchange data between different computing devices 300 which such computing devices 300 form part an interconnected computer network. Examples of a communication interface 324 can include a modem, a network interface (such as an Ethernet card), a communication port (such as a serial, parallel, printer, GPIB, IEEE 1394, RJ25, USB), an antenna with associated circuitry and the like. The communication interface 324 may be wired or may be wireless. Software and data transferred via the communication interface 324 are in the form of signals which can be electronic, electromagnetic, optical or other signals capable of being received by communication interface 324. These signals are provided to the communication interface via the communication path 326.

[0066] As shown in Figure 3, the computing device 300 further includes a display interface 302 which performs operations for rendering images to an associated display 330 and an audio interface 332 for performing operations for playing audio content via associated speaker(s) 334.

[0067] As used herein, the term "computer program product" may refer, in part, to removable storage medium 344, removable storage unit 322, a hard disk installed in storage drive 312, or a carrier wave carrying software over communication path 326 (wireless link or cable) to communication interface 324. Computer readable storage media refers to any non-transitory, non-volatile tangible storage medium that provides recorded instructions and/or data to the computing device 300 for execution and/or processing. Examples of such storage media include magnetic tape, CD-ROM, DVD, Blu-ray™ Disc, a hard disk drive, a ROM or integrated circuit, a solid state storage drive (such as a USB flash drive, a flash memory device, a solid state drive or a memory card), a hybrid drive, a magneto -optical disk, or a computer readable card such as a SD card and the like, whether or not such devices are internal or external of the computing device 300. Examples of transitory or non-tangible computer readable transmission media that may also participate in the provision of software, application programs, instructions and/or data to the computing device 300 include radio or infra-red transmission channels as well as a network connection to another computer or networked device, and the Internet or Intranets including e-mail transmissions and information recorded on Websites and the like.

[0068] The computer programs (also called computer program code) are stored in main memory 308 and/or secondary memory 310. Computer programs can also be received via the communication interface 324. Such computer programs, when executed, enable the computing device 300 to perform one or more features of embodiments discussed herein. In various embodiments, the computer programs, when executed, enable the processor 304 to perform features of the above-described embodiments. Accordingly, such computer programs represent controllers of the computer system 300.

[0069] Software may be stored in a computer program product and loaded into the computing device 400 using the removable storage drive 314, the storage drive 312, or the interface 340. Alternatively, the computer program product may be downloaded to the computer system 300 over the communications path 326. The software, when executed by the processor 304, causes the computing device 300 to perform functions of embodiments described herein.

[0070] It is to be understood that the embodiment of Figure 3 is presented merely by way of example. Therefore, in some embodiments one or more features of the computing device 300 may be omitted. Also, in some embodiments, one or more features of the computing device 300 may be combined together. Additionally, in some embodiments, one or more features of the computing device 300 may be split into one or more component parts.

[0071] In an implementation, the payment network server 108 may be generally described as a physical device comprising at least one processor 402 and at least one memory 404 including computer program code. The at least one memory 404 and the computer program code are configured to, with the at least one processor 402, cause the physical device to perform the operations described in Figure 2. An example of the payment network server 108 is shown in Figure 4.

[0072] For example, the method of Figure 2 may be implemented as software and stored in a non-transitory fashion in the secondary memory 310 or the removable storage units 318, 322 of the computer device 300.

[0073] Figures 5A-5D show schematic diagrams illustrating different aspects of the problem to which embodiments of the method and system of the present invention seek to solve. Figure 5A identifies that micro -merchants and micro small and medium enterprises (MSMEs), for example a grocery store owner or a food seller, who do not have adequate information and collateral to be able to obtain financial services from financial institutions. Figures 5B, 5C and 5D further illustrate the breakdown of the number of such merchants and SMEs who are excluded from financial services. In particular, there are two billion micro merchants and MSMEs globally of which 445 million are MSMEs who do not have access to financial services as shown in Figure 5B. In Africa, one billion micro merchants and MSMEs are financially excluded of which 455 million are MSMEs and 285 million are informal MSMEs as shown in Figure 5C. As shown in Figure 5D, an estimated 28.5 million or 10% of the informal MSMEs may adopt the system which translates to a growth uptake of 5% per annum.

[0074] Figure 6 shows typical profiles of a merchant according to an example embodiment. In this Figure, an example of a typical micro merchant or MSME is Usman, who is a trader and Wanjiru, who is a farmer. Both are typical micro merchants who do not have a bank account and wishes to obtain a loan or subsidies from their respective Government and financial institutions.

[0075] Figures 7A-7B show schematic diagrams illustrating features of the system depicted in Figure 3 according to an example embodiment. In Figure 7 A, features of the system includes creating an identity profile, capturing and authenticating biometric data, building transaction history for alternative credit decision, making and receiving payments, providing insight, decision support and managing MSME profile information. In Figure 7B, the system may create a plurality of identity profiles, capture and authenticate biometric data, identify and store a national identity, build transaction history, receive transactions, provide insight, decision support, managing MSME profile information and assist in decision making. Figures 8A-8B show schematic diagrams illustrating the working of the system depicted in Figure 3 according to an example embodiment. In Figure 8A, the system includes a server comprising an iDentify.me module, a mobile identity check module (IDCM), a payment transaction services module for virtual card number and a quick response payment module. As shown in Figure 8B, unions (such as farmers union or traders union), agents, banks and peer-to-peer lenders may be on-boarded onto the system. The system may be delivered to 28.5 million micro-merchants by partnering with Aggregators and Trade Unions. Aggregators will provide biometric know-your-customer details, virtual card numbers and quick response payment to receive payments and a ledger for transaction history. The transaction history will be monetized whenever a lender queries the history in order to determine whether to lend money to the merchant or trader.

[0076] Figures 9A-9E show schematic diagrams illustrating a user interface of the system depicted in Figure 3 according to an example embodiment. In Figure 9A, the user interface includes a picture of the merchant which may be a selfie taken by the merchant's user device, such as a mobile phone. The selfie may be taken by blinking at the camera of the user device. The user interface may also include the name, place of birth, mobile number and a date of birth of the merchant. Additional details will include an ID number of the merchant if one exists and also a photo of the official document that has the ID.

[0077] After registration, the user device may display a welcome message to congratulate the merchant and to indicate that the merchant has a virtual walled and a quick response (QR) code to enable him to do better business as shown in Figure 9B. The user interface may also include options for the merchant to display the virtual wallet QR code or to request a business loan. As shown in Figure 9C, if the merchant selects the option to display the QR code, the user interface shows the QR code on the merchant's user device together with his virtual wallet account number. On the other hand, if the merchant request a business loan, the user interface may indicate whether he has been approved for the loan.

[0078] After the merchant uses his QR code to carry out non-credit or transaction, the user interface may display the total monetary amount of the transactions as shown in Figure 9D. The user interface may also indicate to the merchant that he is eligible to qualify for a loan based on the total monetary amount of the transactions. In an alternative embodiment as shown in Figure 9E, the user device may not have a camera or touchscreen. In this case, the user interface may include numbers for the various options to be selected by the merchant. For example, the merchant may want to view his profile by pressing the " 1" on the number- pad of his device. Other options may include receiving payments, making payments, finding a lender and/or request for assistance with the application. If the merchant wishes to make payment to a supplier, the user interface may request the merchant to enter a virtual wallet merchant code of the supplier. Subsequently, the user interface may request the merchant to enter the amount he wishes to pay and after payment has been made, the user interface displays the profile of the merchant indicating his name, date of birth, place of birth, a monetary amount of the last transaction and any loan payments that have been made.

[0079] Figure 10 shows a schematic diagram illustrating a value chain of the system depicted in Figure 3 according to an example embodiment. The value chain includes a card network of the system, for example MasterCard, and the parties involved in the system. The parties may include MSMEs, partner banks, aggregators and lenders.

[0080] Figures 11A-11C show schematic diagrams illustrating benefits of the system depicted in Figure 3 according to an example embodiment. As shown in Figure 11 A, the system may generate revenues of $481 million over a seven year period. This includes a profile residency fee of $62 million from the MSMEs, a transaction history check fee of $174 million, an authentication fee of $8.7 million for mobile identity check, a transaction switching fee of $62 million, a virtual card number payment transaction service and transaction processing fee of $87 million and an issuer/acquirer assessment fee of $87 million. The table of Figure 11B shows the details of the various fees contributing to the revenue and its respective models, rates and duration. Figure 11C show the various monetary amount of the revenue over a five year period and further illustrated using a chart.

[0081] Figures 12A-12B show schematic diagrams illustrating the different markets for implementation of the system depicted in Figure 3 according to an example embodiment. In Figure 12A, the system may be implemented in sub Saharan Africa and Southern Africa in the first year. In the second year, the system may be implemented in North Africa and Middle East. In the third year and beyond, the system may be implemented in Asia, South East Asia and Latin America. Alternatively, and as shown in Figure 12B, the system may be implemented in Africa (including West Africa, East Africa, Southern Africa and North Africa) in the first two years. The system may then be implemented in Middle East and South East Asia in the second to fourth year. Subsequently, the system may be implemented in Latin America and Asia from the fifth year onwards.

[0082] Figure 13 shows a table illustrating the differences between similar systems and the system depicted in Figure 3 according to an example embodiment. The table of Figure 13 shows the advantages of the system implemented by the card network, i.e. MasterCard, against various other systems such as Kiva and Kopo Kopo. It can be seen from the Figure that the system does not require underwriting which may save time and costs and also includes reference check of the merchant to minimize risk.

[0083] Figures 14A-14B show tables illustrating various estimated capital expenses of the system depicted in Figure 3 according to an example embodiment. In the Figures, various estimations for the required capital expenses are provided over a five year period and the various existing systems of the card network provider are used for the implementation of the current system.

[0084] It will be appreciated by a person skilled in the art that numerous variations and/or modifications may be made to the present invention as shown in the specific embodiments without departing from the spirit or scope of the invention as broadly described. For example, the above description mainly discusses the use of a Bluetooth connection, but it will be appreciated that another type of secure wireless connection, such as Wi-Fi, can be used in alternate embodiments to implement the method. Some modifications, e.g. adding an access point, changing the log-in routine, etc. may be considered and incorporated. The present embodiments are, therefore, to be considered in all respects to be illustrative and not restrictive.




 
Previous Patent: MODULAR CONSTRUCTION SYSTEM

Next Patent: COMPRESSION DEVICES