WO2022137026A1 - A method and system for processing financial transactions for a customer - Google Patents

A method and system for processing financial transactions for a customer Download PDF

Info

Publication number
WO2022137026A1
WO2022137026A1 PCT/IB2021/061754 IB2021061754W WO2022137026A1 WO 2022137026 A1 WO2022137026 A1 WO 2022137026A1 IB 2021061754 W IB2021061754 W IB 2021061754W WO 2022137026 A1 WO2022137026 A1 WO 2022137026A1
Authority
WO
WIPO (PCT)
Prior art keywords
customer
credit
account
transaction
amount
Prior art date
Application number
PCT/IB2021/061754
Other languages
French (fr)
Inventor
Yannis BENLACHTAR
Original Assignee
STRÖH, Frederyk Andries Jacobus
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by STRÖH, Frederyk Andries Jacobus filed Critical STRÖH, Frederyk Andries Jacobus
Publication of WO2022137026A1 publication Critical patent/WO2022137026A1/en
Priority to ZA2023/05938A priority Critical patent/ZA202305938B/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/223—Payment schemes or models based on the use of peer-to-peer networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3223—Realising banking transactions through M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/325—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/385—Payment protocols; Details thereof using an alias or single-use codes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4016—Transaction verification involving fraud or risk level assessment in transaction processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/405—Establishing or using transaction specific rules

Definitions

  • This invention relates to a financial service system. More particularly the invention relates to a method and system for processing financial transactions for a customer via a mobile financial system or a closed-loop system.
  • Individual financial transactions i.e., the transfer of money from one individual to another, are key fundamentals of today's economy. In general, these transactions are enabled by financial institutes, e.g., banks, financial service providers, and/or credit card companies.
  • financial institutes e.g., banks, financial service providers, and/or credit card companies.
  • a prerequisite for any transaction in that sense is that the individual intending such a transaction has to be registered to an institution representing some financial service provider and has to have an established identity there. That identity allows the individual to create financial transactions to yet another individual and/or business entity.
  • Such an identity may be for example a bank account, a credit card, or the like.
  • SoV digital store of value
  • Store of value systems enables its users to deposit and withdraw money, make peer-to-peer transfers, pay bills, purchase airtime, save money in a virtual account, borrow money and make payments to a merchant and the like.
  • Store of value systems may also be a closed-loop system such as mobile operators’ airtime wallets and the like.
  • M-Pesa mobile phone-based money transfer, payment, and microfinancing service
  • financial institutions and independent digital wallet providers
  • bKash independent digital wallet providers
  • a new generation of financial services have recently been developed in addition to the store of value systems, namely digital loans, micro-savings, cost-effective international remittances, and micro insurances.
  • digital loans have been very popular due to the lack of loan services from traditional brick-and-mortar banks. These banks have a relatively high-cost base to serve such micro-loans and due to the lack of credit history, it has been difficult for these institutions to assess the creditworthiness of the unbanked customers. Therefore, micro-loan services were mainly driven by fintech companies either independently or in association with mobile network operators and financial institutions.
  • the first generation of micro-loan products were in the form of unsecured personal loans where customers requested the loans through a dedicated process via Unstructured Supplementary Service Data (USSD) or mobile applications (apps). Once the loan is disbursed, the customers needed to go back to the Store of Value system interface (e.g., USSD or app) to complete a transaction such as a bill payment.
  • USSD Unstructured Supplementary Service Data
  • This two-step process was inconvenient and a new generation of services have proposed an overdraft service where the customers can obtain an instantaneous loan to cover any insufficient balance at the time of purchase. This method may not be convenient if the customers want to keep money in their account for a later use or for a cash-out transaction.
  • a method for processing financial transactions for a customer via a mobile device including the steps of:
  • the method may include the additional step of utilising an existing, or establishing a funding account for the customer.
  • the funding account may be established by the customer via the mobile device, a service provider or a financial institution.
  • the funding account may be used to fund the credit account and be hosted on a service provider system or the financial institution.
  • the method may include the additional step of linking additional financial accounts and/or physical bank cards to the customers account thereby allowing the customer to utilise other financial accounts and/or physical bank cards.
  • the step of deducting the transaction amount from the selected account may include checking if there are sufficient funds available in the customer’s credit account. In a first scenario where there are sufficient credit funds available, the transaction amount is deducted from the credit account with the amount transferred to the recipient.
  • the method may include the subsequent step of sending a confirmation notification to the customer and the recipient. The method may further include offering the customer the option to convert the transaction into an instalment payment.
  • the method includes the step of sending a request to the customer requesting whether the funds required to cover the credit shortfall can be deducted from the main account. The transaction amount is then deducted from the credit and the main account with the amount transferred to the recipient. The method may include the subsequent step of sending a confirmation notification to the customer and the recipient. The method may further include offering the customer the option to convert the transaction into an instalment payment.
  • the method includes the step of sending a transaction failure message to the customer and prompting the customer to add additional funds into the main account or pay any outstanding debt on the credit account.
  • the method may include the step of receiving a request from the customer to make a financial transaction.
  • the financial transaction may be in the form of a payment, money transfer or a reservation of an amount on the credit or main account (deposit).
  • the method may include the subsequent step of prompting the customer to select what financial transaction the customer wishes to make and from which account or linked bank card the transaction amount should be deducted.
  • the customer may additionally select from which account the transaction amount is to be deducted with an optional prefix/postfix character input in addition to the input of existing menu options.
  • the method may include the step of setting a recurring instruction that indicates that the transaction amount of a specific transaction is to be deducted from the credit account, other linked accounts or bank cards while keeping the same menu options.
  • the method may include a step of prompting the customer to select if the financial transaction is to reserve an amount on the credit account or the main account (deposit).
  • the customer may set an expiry period/date of the reserved amount.
  • the method may include the step of user authentication.
  • the step of user authentication may include receiving a unique identifier from the customer.
  • the method may include the step of prompting the customer if they wish to convert at least some of the transaction into a credit transaction or an instalment payment.
  • the invention further provides for the step of linking the credit account to a virtual or physical card for use by the customer for online and physical payments.
  • the invention also provides for the generation of quick response (QR) codes, in-app notifications, tokens and secure HTTP links to facilitate payments, money transfers and reservations/deposits.
  • QR quick response
  • the invention provides for the step of allowing the customer to generate a “pay me” or deposit request using static or dynamic quick response (QR) codes and push Unstructured Supplementary Service Data (USSD) and send the request to a requestee.
  • QR quick response
  • USSD Unstructured Supplementary Service Data
  • it may provide an approval option which is accessible by the requestee to approve the pay-me or deposit request and transfer a requested amount.
  • expirable vouchers be it scannable or non- scannable
  • the method further provides for the step of linking the credit account to different store of value and closed loop systems.
  • the closed loop system may include any closed loop system such as a mobile operators’ airtime, vouchers, betting and the like.
  • a customer may divide a credit account into associated sub-accounts with each subaccount linked to different users and/or different main accounts.
  • the invention further provides for the bundling of a single or multiple insurance policies with a credit facility service which provides the virtual credit account and/or establishing/linking a loyalty program with the various transactions to the benefit of the customer.
  • the method may include charging fees for each financial transaction made on credit.
  • the fees which are charged may include:
  • the method may include the step of receiving a payment from a customer to repay an outstanding credit.
  • the payment may be made by transferring the money from their main account to their credit account.
  • the method may include an additional or an independent step of setting up a guarantee for credit purchases if the customer has no credit record or a low credit score.
  • the step of setting up the guarantee may include the steps of designating at least one guarantor, collateralizing a portion or the full credit account by the guarantor, and releasing the guarantor from the transaction when the credit account is closed.
  • the step of designating the guarantors may include providing the guarantors’ details such as MSISDN, email, national identification card number, driver’s license number, bank identification number, voting card number or any other official document number. Once the guarantors' details are provided the customer may provide how much of the credit account each guarantor is requested to guarantee and the duration. Once the guarantor is designated, a notification may be sent to each guarantor via an App notification, SMS, USSD push, email and/or other electronic means. The notification may include information of the requestor, the amount of the guarantee, a reference number, the call to action and where to find additional information.
  • the notification may include information of the requestor, the amount of the guarantee, a reference number, the call to action and where to find additional information.
  • the guarantors may accept the guarantee by dialling a USSD short code, clicking on a web-based link, sending an SMS, and/or to click on the app notification or open the app and approve the guarantee.
  • the guarantor by accepting the guarantee, may be prompted to enter the customer’s details and/or reference number, confirm the guarantee amount and guarantee duration, accept the terms and conditions of the service provide, and the account details from which to debit the guarantee amount.
  • the guarantee may be executed using any one of the following steps:
  • the guarantee amount is automatically debited from the guarantor’s selected account by a service provider and transferred to an escrow account or any other account;
  • the guarantor transfers the guarantee amount to a designated account selected by the service provider;
  • the service provider establishes a lien or a reserve on the guarantor’s chosen account.
  • a system for processing financial transactions for a customer in accordance with the first aspect of the invention, the system including;
  • the server being in wireless communication with the mobile device via at least one channel;
  • the recipient device in wireless communication with the server; and wherein the mobile device is configured to receive a request from the customer to make a financial transaction and transfer a transaction amount to the recipient device.
  • the mobile device may receive the request from the customer via SMS, USSD, mobile application, website, and/or interactive voice response (IVR).
  • the request may be sent to the server with the server prompting the customer via the mobile device to indicate what financial transaction they wish to conduct.
  • the mobile device may be any one of the following: mobile telephone; personal digital assistant (PDA); desktop or laptop computer; tablet or the like.
  • PDA personal digital assistant
  • desktop or laptop computer tablet or the like.
  • the recipient device may be any one of the following: point of sale machines; automated teller machines (ATM); mobile telephones; personal digital assistants (PDA); laptop computers; and desktop computers.
  • the recipient device may be associated with any one of the following recipients: government, utilities, education, commerce, charities, and the like.
  • the application which runs on the server may be configured to:
  • a main credit account is opened and may contain many sub-accounts.
  • the credit accounts may be hosted on the server or at a financial institution;
  • escrow accounts may be created on the server or hosted externally;
  • Figure 1 shows a schematic diagram of a system for processing financial transactions for a customer in accordance with the invention
  • Figure 2 shows a schematic illustration of a menu of options presented by a mobile device via which the customer can conduct a financial transaction
  • Figure 3 shows a schematic illustration of a menu of options presented by a mobile device via which the customer can conduct a financial transaction but wherein a credit account facility is used as payment source through the use of pre-/postfix input options;
  • Figure 4 shows a schematic diagram of the transfer of a transaction amount when the customer selects to pay from their credit account
  • Figure 5 shows a schematic diagram of the transfer of a transaction amount when the customer selects to pay from their main account
  • Figure 6 shows a schematic diagram of a credit account and associated main accounts
  • Figure 7 shows a schematic illustration of a menu presented by a mobile device via which the customer designates guarantors.
  • the system for processing financial transactions includes a mobile device which is associated with a customer, enabling the customer to make financial transactions quickly and easily, no matter where he/she is.
  • the mobile device is in the form of a mobile telephone; personal digital assistant (PDA); desktop or laptop computer; tablet or the like.
  • PDA personal digital assistant
  • the present invention supplants the need for an account holder to have a bank account, bank checks, direct deposit, or credit card.
  • the system further includes a server (not shown) on which a store of value application I system (SoV) 10 is executed and which is associated with a service provider 12.
  • SoV store of value application I system
  • the server is in wireless communication with the mobile device via at least one of the following channels including SMS 14, USSD 16, mobile application 18, website, and/or interactive voice response (IVR) 20.
  • the server is also in communication with at least one recipient device which is associated with a recipient in the form of billers 22 such as government 24, utilities 26, education 28, commerce 30, charities, and the like.
  • the server may also be in communication with recipient devices in the form of any one or more of point-of-sale machines associated with a merchant 32; automated teller machines (ATM) 34; mobile telephones; personal digital assistants (PDA); laptop computers; and desktop computers (not shown).
  • ATM automated teller machines
  • PDA personal digital assistants
  • laptop computers laptop computers
  • desktop computers not shown.
  • the mobile device (not shown) is configured and operable to receive a request from a customer 36 to make a financial transaction and transfer a transaction amount to the recipient device 38.
  • the mobile device may receive the request from the customer via SMS 14, USSD 16, mobile application 18, website, and/or interactive voice response (IVR) 20.
  • the request may be sent by the mobile device to the server where the store of value system 10 concludes the financial transaction based on the method described below.
  • the method for processing financial transactions for a customer via the mobile device includes the step of utilizing an existing main account 40 for the customer 36.
  • This main account 40 is preferably an account that is associated with the customer on the SoV system 10. Alternatively, where no such account exists for a new customer, a main account may be established for the prospective customer. This can be either an account which is hosted on the server, on the service provider system, or at a financial institution.
  • the main account 40 can be established by receiving a request from the customer 36 via the mobile device to registerer a new account on the server. The customer 36 is prompted to enter certain information whereafter the main account 40 is established.
  • an additional mobile credit account 42 for the customer 36 is created on the server.
  • the mobile credit account 42 is created with a maximum credit limit based on the outcome of a credit scoring which is conducted by the system or through an appropriate institution.
  • the service provider system may integrate with various 3rd party institutions or data sources (via an API) such as financial institutions, credit bureaus, financial brokers, retailers, eCommerce, borrowers, and the like. By utilising these data sources, the service provider system may perform credit scoring - a score that gives an indication of the credit worthiness of a user.
  • the user may request to facilitate a financial transaction via the mobile device.
  • An additional funding account 44 can also be established for the customer 36.
  • the funding account 44 is used to fund the different transactions of the customer and is hosted on the server, on the service provider system, or at a financial institution.
  • Figure 2 shows a screenshot of a menu 46 which is presented to the customer 36 via the mobile device when a customer makes a request to conduct the financial transaction.
  • the menu presented to the customer includes a number of options which include send money 48, buy airtime 50, payments 52, make payments with credit 54, withdrawal 56, and my account 58.
  • the user is prompted to select any one of the menu options. In this particular embodiment, the user selects to make a payment by providing the appropriate input onto the mobile device i.e., number 3 for “Payments”.
  • a second menu 60 is presented to the customer whereafter the menu will include different entities which the user can pay such as “1 . Utilities” 62, “2. Pay TV” 64, “3. School fees” 66, and “4. Taxes” 68.
  • Utilities in the form of “Electricity bill”
  • the user is prompted by menu 70 to pay the full amount or enter the amount they wish to pay as described. In this embodiment, the amount will be automatically deducted from the customer’s main account.
  • the invention also provides for a means to conveniently select from which account the payment must be made.
  • another menu 72 is presented where an input (i.e. 1 . Utilities) is provided with a postfix “*”.
  • the customer will input 1 * as shown in the second screen 72 of Figure 3.
  • the system is configured to utilize the applicable funds for the transaction to be utilized from the credit account.
  • pre- or postfixes in the input of options therefore provides a convenient way to indicate and select the preferred account from which the transaction amount should be deducted. In other words, where no pre- or postfix is used, the amount will be deducted from the main account, whereas the use of a pre- or postfix will result in the amount being deducted from the credit account.
  • the interface may provide for other means, such as actual dedicated/additional options menu (not shown) which may be chosen to enable the user to indicate and select the preferred account from which the transaction amount should be deducted.
  • a graphic user interface may also be provided with further “dropdown menus” etc. to provide options, facilitate the process etc. If the user selects to pay with the credit facility, the method follows the steps as shown in Figure 4. The steps include checking if there is sufficient credit available to complete the transaction 74.
  • the transaction amount is deducted from the credit account with the amount transferred 76 to the recipient.
  • the method includes the step of checking 78 and/or asking the customer if the funds can be taken from the main account 78. If sufficient funds are available, the transaction amount is then deducted from the credit and the main account with the amount transferred 80 to the recipient.
  • a confirmation notification 82 is sent to the customer and the recipient as well as offering the customer if they wish to convert at least some of the transaction into an instalment payment 84.
  • a transaction failure message (not shown) is sent to the customer which prompts the customer to fund the account or pay any outstanding debt on the credit account.
  • the method follows the steps as shown in Figure 5 where the transaction amount is transferred from the customer’s main account to the recipient and a payment notification is sent to the mobile device associated with the customer and the recipient.
  • the store of value application/system 10 sends a credit offer 88 to the customer via the mobile device. If the client accepts the offer, the store of value application checks if there is sufficient credit available 90. Where there is sufficient credit available, the transaction amount is transferred 92 from the credit account or the funding account to the main account. Where there is not sufficient credit available 94, a transaction failure message is sent to the customer and which prompts the customer to fund the account or pay any outstanding debt on the credit account. As shown in Figure 6, each credit account may be associated with sub-accounts with each credit account and sub-account linked to different users and/or different main accounts. For example, in Figure 6, a credit account 96 belonging to a father and which is linked to the father’s main account is shown.
  • the father may add members of his family each having their own account 96.1 , 96.2 to use his credit account as a common credit pool. Therefore, a child can for example pay for a bill using the credit account linked to his father and any balance payments would come from the father’s main account.
  • the father in this case is considered the owner and the administrator.
  • Company A may also provide credit facilities to Employees 1 , 2 and 3 as shown. Each sub-account 98.1 , 98.2, and 98.3 may have a different maximum credit limit set by the Company A.
  • the method may include offering a grace period and charging fees for each financial transaction made on credit after the grace period.
  • the fees which are charged can include:
  • the method includes the step of receiving a payment from a customer to repay an outstanding credit.
  • the payment is made by transferring the money from their main account to their credit account.
  • the method includes an additional step of setting up a guarantee for credit purchases if the customer has no credit record or a low credit score.
  • the step of setting up the guarantee includes the steps of designating at least one guarantor by providing the guarantor’s details such as MSISDN, email, national identification card number, driver’s license number, bank identification number, voting card number, or any other official document number.
  • the customer is able to enter the mobile number on as prompted on menu 100. Once the guarantor’s details are provided the customer may provide how much of the credit account each guarantor is requested to guarantee and the duration as shown in menu 102.
  • the customer can also set up additional guarantees for the credit purchase as shown in menu 104.
  • a notification is sent to each guarantor via an App notification, SMS, USSD push, and/or email.
  • the notification includes information of the requestor, the amount of the guarantee, a reference number, the call to action, and where to find additional information.
  • the guarantor is able to accept or reject the guarantee by dialing a USSD short code, clicking on a web-based link, sending an SMS, and/or to click on the app notification or open the app and approve the guarantee.
  • the guarantor by accepting the guarantee, is prompted to enter the customer’s details and/or reference number, confirm the guarantee amount and guarantee duration, accept the terms and conditions of the service, provide the account details from which to debit the guarantee amount, and the like.
  • the guarantee can be executed using any one of the following steps:
  • the guarantee amount is automatically debited from the Guarantor’s selected account by a service provider and transferred to an escrow account or any other account;
  • the guarantor transfers the guarantee amount to a designated account selected by the service provider; and/or
  • the service provider establishes a lien or a reserve on the guarantor’s chosen account.
  • the guarantee is returned to the guarantor by transferring the amount back to the guarantor’s account and/or by releasing the lien on the guarantor’s amount.
  • the user/customer is also able to link a credit card (whether virtual or physical) on the system of the invention.
  • the customer may link and use his existing credit card in making payments on the system of the invention.
  • This provides a convenient way for customers to utilize the credit card in the same/similar manner as a conventional credit card, but through means of the system and method of the invention.
  • the service provide system has the capabilities to bundle a single or multiple insurance policies with the credit facility service. In other words, for a customer to enjoy the credit service, they must take at least one insurance policy.
  • the platform allows for the micro charging of the insurance premium from any customer account e.g., daily, weekly, monthly etc. and offer a digital insurance claim management system.
  • the service provider system may provide a loyalty program that offers points for each transaction unit and level status such as silver, gold and platinum.
  • the points may be redeemed for goods and services or used as cashback or any other type of appropriate reward to the customer.
  • the invention provides a convenient credit facility, an intuitive user experience, and a debt securitization method to provide a superior service to customers using SoV systems.
  • customers at the time of purchase may choose to keep their balance untouched and use the credit facility instead.
  • the invention further provides methods to keep the user experience on the system virtually unchanged while giving the customer the option to pay from their balance or credit facility.
  • the invention further provides a means of securitizing the credit risk (and therefore provide more inclusion) using other users of the SoV systems.
  • a yet further advantage of the invention provides a method of bundling the credit facility with insurance services.
  • the invention furthermore provides potentially cheaper cost of finance: by keeping cash in their balance to use it for a cash-out transaction for example would work out cheaper than cashing out a personal loan.
  • the invention can be used for certain transactions that require blocking an amount on the customers’ accounts such as pre-authorization for hotels reservation and car rentals which can only be done with credit cards (credit card penetration is very low in such markets).
  • the invention provides more convenience and control for business expenses by allowing businesses to give credit facilities to their employees on any store of value system.
  • the customer experience can remain virtually unchanged on the SoV system while giving the customers the choice to switch between the credit and the other accounts. It also allows more financial inclusion on the SoV systems by providing credit risk securitization.
  • the invention may be carried out on any suitable device/s which will be provided with the necessary software and hardware components required to carry out the invention.
  • suitable computer software will be implemented onto the various devices to carry out the invention as described above. These are accordingly not provided in any unnecessary detail as this will be within the competence of a person skilled in the art.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

The invention relates to a method and system for processing financial transactions for a customer via a mobile financial system or a closed-loop system. The invention provides for utilising an existing, or establishing, a main account for the customer and creating a virtual credit account for the customer with a maximum credit limit based on the outcome of a credit scoring. A customer is able to select if the transaction amount is to be deducted from the main account and/or the credit account after which the transaction amount is deducted from the selected account and deposited to a specified recipient.

Description

A METHOD AND SYSTEM FOR PROCESSING FINANCIAL TRANSACTIONS FOR A CUSTOMER
FIELD OF THE INVENTION
This invention relates to a financial service system. More particularly the invention relates to a method and system for processing financial transactions for a customer via a mobile financial system or a closed-loop system.
BACKGROUND TO THE INVENTION
Individual financial transactions, i.e., the transfer of money from one individual to another, are key fundamentals of today's economy. In general, these transactions are enabled by financial institutes, e.g., banks, financial service providers, and/or credit card companies. A prerequisite for any transaction in that sense is that the individual intending such a transaction has to be registered to an institution representing some financial service provider and has to have an established identity there. That identity allows the individual to create financial transactions to yet another individual and/or business entity. Such an identity may be for example a bank account, a credit card, or the like.
Globally, about 1 .7 billion adults remain unbanked, without an account at a financial institution or through a mobile money provider. Unbanked adults have however started to become financially included around the world thanks to the proliferation of cost-effective, digital store of value (SoV) systems. Store of value systems enables its users to deposit and withdraw money, make peer-to-peer transfers, pay bills, purchase airtime, save money in a virtual account, borrow money and make payments to a merchant and the like. Store of value systems may also be a closed-loop system such as mobile operators’ airtime wallets and the like.
Store of value systems have been typically promoted by mobile network operators, such as “M-Pesa” which is a mobile phone-based money transfer, payment, and microfinancing service, financial institutions, and independent digital wallet providers such as “bKash” in Bangladesh. A new generation of financial services have recently been developed in addition to the store of value systems, namely digital loans, micro-savings, cost-effective international remittances, and micro insurances. In particular, digital loans have been very popular due to the lack of loan services from traditional brick-and-mortar banks. These banks have a relatively high-cost base to serve such micro-loans and due to the lack of credit history, it has been difficult for these institutions to assess the creditworthiness of the unbanked customers. Therefore, micro-loan services were mainly driven by fintech companies either independently or in association with mobile network operators and financial institutions.
The first generation of micro-loan products were in the form of unsecured personal loans where customers requested the loans through a dedicated process via Unstructured Supplementary Service Data (USSD) or mobile applications (apps). Once the loan is disbursed, the customers needed to go back to the Store of Value system interface (e.g., USSD or app) to complete a transaction such as a bill payment. This two-step process was inconvenient and a new generation of services have proposed an overdraft service where the customers can obtain an instantaneous loan to cover any insufficient balance at the time of purchase. This method may not be convenient if the customers want to keep money in their account for a later use or for a cash-out transaction.
OBJECT OF THE INVENTION
It is accordingly an object of the present invention to provide a method for processing financial transactions for a customer via a mobile financial system or a closed-loop system and a mobile financial system that will, provide a useful alternative to existing systems.
SUMMARY OF THE INVENTION
According to a first aspect of the invention, there is provided a method for processing financial transactions for a customer via a mobile device, the method including the steps of:
- utilising an existing, or establishing, a main account for the customer;
- creating a virtual credit account for the customer with a maximum credit limit based on the outcome of a credit scoring; - receiving a request from the customer to facilitate a financial transaction with the customer able to select if the transaction amount is to be deducted from the main account and/or the credit account; and
- deducting the transaction amount from the selected account and depositing the transaction amount to a specified recipient.
The method may include the additional step of utilising an existing, or establishing a funding account for the customer. The funding account may be established by the customer via the mobile device, a service provider or a financial institution. The funding account may be used to fund the credit account and be hosted on a service provider system or the financial institution.
The method may include the additional step of linking additional financial accounts and/or physical bank cards to the customers account thereby allowing the customer to utilise other financial accounts and/or physical bank cards.
The step of deducting the transaction amount from the selected account may include checking if there are sufficient funds available in the customer’s credit account. In a first scenario where there are sufficient credit funds available, the transaction amount is deducted from the credit account with the amount transferred to the recipient. The method may include the subsequent step of sending a confirmation notification to the customer and the recipient. The method may further include offering the customer the option to convert the transaction into an instalment payment.
In a second scenario where there are not sufficient credit funds available but the main account has sufficient funds to cover the credit shortfall, the method includes the step of sending a request to the customer requesting whether the funds required to cover the credit shortfall can be deducted from the main account. The transaction amount is then deducted from the credit and the main account with the amount transferred to the recipient. The method may include the subsequent step of sending a confirmation notification to the customer and the recipient. The method may further include offering the customer the option to convert the transaction into an instalment payment. In a third scenario where there are not sufficient credit funds available and the main account has insufficient funds to cover the credit shortfall, the method includes the step of sending a transaction failure message to the customer and prompting the customer to add additional funds into the main account or pay any outstanding debt on the credit account.
The method may include the step of receiving a request from the customer to make a financial transaction. The financial transaction may be in the form of a payment, money transfer or a reservation of an amount on the credit or main account (deposit). The method may include the subsequent step of prompting the customer to select what financial transaction the customer wishes to make and from which account or linked bank card the transaction amount should be deducted. The customer may additionally select from which account the transaction amount is to be deducted with an optional prefix/postfix character input in addition to the input of existing menu options. Furthermore, the method may include the step of setting a recurring instruction that indicates that the transaction amount of a specific transaction is to be deducted from the credit account, other linked accounts or bank cards while keeping the same menu options.
The method may include a step of prompting the customer to select if the financial transaction is to reserve an amount on the credit account or the main account (deposit). The customer may set an expiry period/date of the reserved amount.
The method may include the step of user authentication. The step of user authentication may include receiving a unique identifier from the customer.
After a customer made a financial transaction, the method may include the step of prompting the customer if they wish to convert at least some of the transaction into a credit transaction or an instalment payment.
The invention further provides for the step of linking the credit account to a virtual or physical card for use by the customer for online and physical payments. The invention also provides for the generation of quick response (QR) codes, in-app notifications, tokens and secure HTTP links to facilitate payments, money transfers and reservations/deposits. The invention provides for the step of allowing the customer to generate a “pay me” or deposit request using static or dynamic quick response (QR) codes and push Unstructured Supplementary Service Data (USSD) and send the request to a requestee. Moreover, it may provide an approval option which is accessible by the requestee to approve the pay-me or deposit request and transfer a requested amount. It also allows for the generation of expirable vouchers, be it scannable or non- scannable
The method further provides for the step of linking the credit account to different store of value and closed loop systems. The closed loop system may include any closed loop system such as a mobile operators’ airtime, vouchers, betting and the like.
A customer may divide a credit account into associated sub-accounts with each subaccount linked to different users and/or different main accounts. The invention further provides for the bundling of a single or multiple insurance policies with a credit facility service which provides the virtual credit account and/or establishing/linking a loyalty program with the various transactions to the benefit of the customer.
The method may include charging fees for each financial transaction made on credit. The fees which are charged may include:
- A setup fee for each credit transaction;
- Daily, weekly, monthly, or annual interest fees;
- A rollover fee if the credit is not paid on time and rolled over;
- Late payment penalties;
- Insurance premiums on a daily, weekly, monthly, or annual basis; and/or
- Account maintenance or subscription fees.
The method may include the step of receiving a payment from a customer to repay an outstanding credit. The payment may be made by transferring the money from their main account to their credit account.
The method may include an additional or an independent step of setting up a guarantee for credit purchases if the customer has no credit record or a low credit score. The step of setting up the guarantee may include the steps of designating at least one guarantor, collateralizing a portion or the full credit account by the guarantor, and releasing the guarantor from the transaction when the credit account is closed.
The step of designating the guarantors may include providing the guarantors’ details such as MSISDN, email, national identification card number, driver’s license number, bank identification number, voting card number or any other official document number. Once the guarantors' details are provided the customer may provide how much of the credit account each guarantor is requested to guarantee and the duration. Once the guarantor is designated, a notification may be sent to each guarantor via an App notification, SMS, USSD push, email and/or other electronic means. The notification may include information of the requestor, the amount of the guarantee, a reference number, the call to action and where to find additional information.
The guarantors may accept the guarantee by dialling a USSD short code, clicking on a web-based link, sending an SMS, and/or to click on the app notification or open the app and approve the guarantee. The guarantor, by accepting the guarantee, may be prompted to enter the customer’s details and/or reference number, confirm the guarantee amount and guarantee duration, accept the terms and conditions of the service provide, and the account details from which to debit the guarantee amount.
The guarantee may be executed using any one of the following steps:
- The guarantee amount is automatically debited from the guarantor’s selected account by a service provider and transferred to an escrow account or any other account;
- The guarantor transfers the guarantee amount to a designated account selected by the service provider; and/or
- The service provider establishes a lien or a reserve on the guarantor’s chosen account.
When the credit account and all obligations are fully repaid by the customer, the guarantee is returned to the guarantor by transferring the amount back to the guarantor’s account and/or by releasing the lien on the guarantor’s amount. In accordance with a second aspect of the invention, there is provided a system for processing financial transactions for a customer in accordance with the first aspect of the invention, the system including;
- a mobile device which is associated with the customer;
- a server on which an application is executed, the server being in wireless communication with the mobile device via at least one channel;
- a recipient device associated with at least one recipient, the recipient device in wireless communication with the server; and wherein the mobile device is configured to receive a request from the customer to make a financial transaction and transfer a transaction amount to the recipient device.
The mobile device may receive the request from the customer via SMS, USSD, mobile application, website, and/or interactive voice response (IVR). The request may be sent to the server with the server prompting the customer via the mobile device to indicate what financial transaction they wish to conduct.
The mobile device may be any one of the following: mobile telephone; personal digital assistant (PDA); desktop or laptop computer; tablet or the like.
The recipient device may be any one of the following: point of sale machines; automated teller machines (ATM); mobile telephones; personal digital assistants (PDA); laptop computers; and desktop computers. The recipient device may be associated with any one of the following recipients: government, utilities, education, commerce, charities, and the like.
The application which runs on the server may be configured to:
- Manage a funding account which is located either on the server or be hosted by a financial institution;
- Manage the credit accounts: for each customer using the credit facility, a main credit account is opened and may contain many sub-accounts. The credit accounts may be hosted on the server or at a financial institution;
- Manage escrow accounts: escrow accounts may be created on the server or hosted externally;
- Transfer monies (credit, debit, refund) between any accounts on the server; - Set liens or reserve an amount on customers’ accounts on the server;
- Get, process and store “know your customerVFICA information;
- Provide aggregated data or transactional records of a customer for profiling and credit scoring;
- Transfer money, information and manage refunds from any biller;
- Transfer money, information and manage refunds from any merchant;
- Transfer money, information and manage refunds from any agent;
- Exchange regular and ad-hoc reports and data records; and/or
- Provide customer care and technical support.
These and other features of the invention are described in more detail below.
BRIEF DESCRIPTION OF THE ACCOMPANYING FIGURES
Embodiments of the invention are described below, by way of non-limiting examples only, and with reference to the accompanying figures in which:
Figure 1 shows a schematic diagram of a system for processing financial transactions for a customer in accordance with the invention;
Figure 2 shows a schematic illustration of a menu of options presented by a mobile device via which the customer can conduct a financial transaction;
Figure 3 shows a schematic illustration of a menu of options presented by a mobile device via which the customer can conduct a financial transaction but wherein a credit account facility is used as payment source through the use of pre-/postfix input options;
Figure 4 shows a schematic diagram of the transfer of a transaction amount when the customer selects to pay from their credit account;
Figure 5 shows a schematic diagram of the transfer of a transaction amount when the customer selects to pay from their main account; Figure 6 shows a schematic diagram of a credit account and associated main accounts; and
Figure 7 shows a schematic illustration of a menu presented by a mobile device via which the customer designates guarantors.
DETAILED DESCRIPTION OF THE INVENTION
With reference to the figures, a method for processing financial transactions for a customer via a mobile device and a system for processing financial transactions for a customer in accordance with the first aspect of the invention is described.
The system for processing financial transactions includes a mobile device which is associated with a customer, enabling the customer to make financial transactions quickly and easily, no matter where he/she is. The mobile device is in the form of a mobile telephone; personal digital assistant (PDA); desktop or laptop computer; tablet or the like. The present invention supplants the need for an account holder to have a bank account, bank checks, direct deposit, or credit card.
As shown in figure 1 , the system further includes a server (not shown) on which a store of value application I system (SoV) 10 is executed and which is associated with a service provider 12. The server is in wireless communication with the mobile device via at least one of the following channels including SMS 14, USSD 16, mobile application 18, website, and/or interactive voice response (IVR) 20.
The server is also in communication with at least one recipient device which is associated with a recipient in the form of billers 22 such as government 24, utilities 26, education 28, commerce 30, charities, and the like. The server may also be in communication with recipient devices in the form of any one or more of point-of-sale machines associated with a merchant 32; automated teller machines (ATM) 34; mobile telephones; personal digital assistants (PDA); laptop computers; and desktop computers (not shown).
As shown in figure 4, the mobile device (not shown) is configured and operable to receive a request from a customer 36 to make a financial transaction and transfer a transaction amount to the recipient device 38. The mobile device may receive the request from the customer via SMS 14, USSD 16, mobile application 18, website, and/or interactive voice response (IVR) 20. The request may be sent by the mobile device to the server where the store of value system 10 concludes the financial transaction based on the method described below.
The method for processing financial transactions for a customer via the mobile device includes the step of utilizing an existing main account 40 for the customer 36. This main account 40 is preferably an account that is associated with the customer on the SoV system 10. Alternatively, where no such account exists for a new customer, a main account may be established for the prospective customer. This can be either an account which is hosted on the server, on the service provider system, or at a financial institution. The main account 40 can be established by receiving a request from the customer 36 via the mobile device to registerer a new account on the server. The customer 36 is prompted to enter certain information whereafter the main account 40 is established.
Once the information from the customer is received and the main account 40 is established or the existing main account is identified and utilized as the case may be, an additional mobile credit account 42 for the customer 36 is created on the server. The mobile credit account 42 is created with a maximum credit limit based on the outcome of a credit scoring which is conducted by the system or through an appropriate institution. To conduct the credit score, the service provider system may integrate with various 3rd party institutions or data sources (via an API) such as financial institutions, credit bureaus, financial brokers, retailers, eCommerce, borrowers, and the like. By utilising these data sources, the service provider system may perform credit scoring - a score that gives an indication of the credit worthiness of a user.
Once the credit account 42 is created for the user, the user may request to facilitate a financial transaction via the mobile device.
An additional funding account 44 can also be established for the customer 36. The funding account 44 is used to fund the different transactions of the customer and is hosted on the server, on the service provider system, or at a financial institution. Figure 2 shows a screenshot of a menu 46 which is presented to the customer 36 via the mobile device when a customer makes a request to conduct the financial transaction. The menu presented to the customer includes a number of options which include send money 48, buy airtime 50, payments 52, make payments with credit 54, withdrawal 56, and my account 58. The user is prompted to select any one of the menu options. In this particular embodiment, the user selects to make a payment by providing the appropriate input onto the mobile device i.e., number 3 for “Payments”. After a payment is selected, a second menu 60 is presented to the customer whereafter the menu will include different entities which the user can pay such as “1 . Utilities” 62, “2. Pay TV” 64, “3. School fees” 66, and “4. Taxes” 68. Once the user selects the entity they wish to pay, in this embodiment “1 . Utilities” in the form of “Electricity bill”, the user is prompted by menu 70 to pay the full amount or enter the amount they wish to pay as described. In this embodiment, the amount will be automatically deducted from the customer’s main account.
The invention also provides for a means to conveniently select from which account the payment must be made. In the embodiment shown in Figure 3, after the “Payment” option is selected, another menu 72 is presented where an input (i.e. 1 . Utilities) is provided with a postfix “*”. In other words, the customer will input 1 * as shown in the second screen 72 of Figure 3. In this embodiment, the system is configured to utilize the applicable funds for the transaction to be utilized from the credit account. The use of pre- or postfixes in the input of options therefore provides a convenient way to indicate and select the preferred account from which the transaction amount should be deducted. In other words, where no pre- or postfix is used, the amount will be deducted from the main account, whereas the use of a pre- or postfix will result in the amount being deducted from the credit account.
It will also be appreciated that the interface may provide for other means, such as actual dedicated/additional options menu (not shown) which may be chosen to enable the user to indicate and select the preferred account from which the transaction amount should be deducted. Also, where a smartphone is used as the device, a graphic user interface may also be provided with further “dropdown menus” etc. to provide options, facilitate the process etc. If the user selects to pay with the credit facility, the method follows the steps as shown in Figure 4. The steps include checking if there is sufficient credit available to complete the transaction 74.
In a first scenario where there is sufficient credit available, the transaction amount is deducted from the credit account with the amount transferred 76 to the recipient.
In a second scenario where there is not sufficient credit available but the main account has sufficient funds to cover the credit shortfall, the method includes the step of checking 78 and/or asking the customer if the funds can be taken from the main account 78. If sufficient funds are available, the transaction amount is then deducted from the credit and the main account with the amount transferred 80 to the recipient.
In the first and second scenarios, a confirmation notification 82 is sent to the customer and the recipient as well as offering the customer if they wish to convert at least some of the transaction into an instalment payment 84.
In a third scenario where there is not sufficient credit available 86 and the main account also has insufficient funds to cover the credit shortfall, a transaction failure message (not shown) is sent to the customer which prompts the customer to fund the account or pay any outstanding debt on the credit account.
If the user selects to make a payment with their main account facility, the method follows the steps as shown in Figure 5 where the transaction amount is transferred from the customer’s main account to the recipient and a payment notification is sent to the mobile device associated with the customer and the recipient.
Once the payment has been made, the store of value application/system 10 sends a credit offer 88 to the customer via the mobile device. If the client accepts the offer, the store of value application checks if there is sufficient credit available 90. Where there is sufficient credit available, the transaction amount is transferred 92 from the credit account or the funding account to the main account. Where there is not sufficient credit available 94, a transaction failure message is sent to the customer and which prompts the customer to fund the account or pay any outstanding debt on the credit account. As shown in Figure 6, each credit account may be associated with sub-accounts with each credit account and sub-account linked to different users and/or different main accounts. For example, in Figure 6, a credit account 96 belonging to a father and which is linked to the father’s main account is shown. The father may add members of his family each having their own account 96.1 , 96.2 to use his credit account as a common credit pool. Therefore, a child can for example pay for a bill using the credit account linked to his father and any balance payments would come from the father’s main account. The father in this case is considered the owner and the administrator. On the same basis, Company A may also provide credit facilities to Employees 1 , 2 and 3 as shown. Each sub-account 98.1 , 98.2, and 98.3 may have a different maximum credit limit set by the Company A.
The method may include offering a grace period and charging fees for each financial transaction made on credit after the grace period. The fees which are charged can include:
A setup fee for each credit transaction;
Daily, weekly, monthly, or annual interest fees;
A rollover fee if the credit is not paid on time and rolled over;
Late payment penalties;
Insurance premiums on a daily, weekly, monthly or annual basis; and/or Account maintenance or subscription fees.
The method includes the step of receiving a payment from a customer to repay an outstanding credit. The payment is made by transferring the money from their main account to their credit account.
As shown in Figure 7, the method includes an additional step of setting up a guarantee for credit purchases if the customer has no credit record or a low credit score. The step of setting up the guarantee includes the steps of designating at least one guarantor by providing the guarantor’s details such as MSISDN, email, national identification card number, driver’s license number, bank identification number, voting card number, or any other official document number. As shown in Figure 7, the customer is able to enter the mobile number on as prompted on menu 100. Once the guarantor’s details are provided the customer may provide how much of the credit account each guarantor is requested to guarantee and the duration as shown in menu 102. The customer can also set up additional guarantees for the credit purchase as shown in menu 104.
Once the guarantor is designated, a notification is sent to each guarantor via an App notification, SMS, USSD push, and/or email. The notification includes information of the requestor, the amount of the guarantee, a reference number, the call to action, and where to find additional information.
The guarantor is able to accept or reject the guarantee by dialing a USSD short code, clicking on a web-based link, sending an SMS, and/or to click on the app notification or open the app and approve the guarantee. The guarantor, by accepting the guarantee, is prompted to enter the customer’s details and/or reference number, confirm the guarantee amount and guarantee duration, accept the terms and conditions of the service, provide the account details from which to debit the guarantee amount, and the like.
The guarantee can be executed using any one of the following steps:
The guarantee amount is automatically debited from the Guarantor’s selected account by a service provider and transferred to an escrow account or any other account;
The guarantor transfers the guarantee amount to a designated account selected by the service provider; and/or
The service provider establishes a lien or a reserve on the guarantor’s chosen account.
When the credit account and all obligations are fully repaid by the customer, the guarantee is returned to the guarantor by transferring the amount back to the guarantor’s account and/or by releasing the lien on the guarantor’s amount.
It will be appreciated that the user/customer is also able to link a credit card (whether virtual or physical) on the system of the invention. In this respect, the customer may link and use his existing credit card in making payments on the system of the invention. This provides a convenient way for customers to utilize the credit card in the same/similar manner as a conventional credit card, but through means of the system and method of the invention.
Moreover, the service provide system has the capabilities to bundle a single or multiple insurance policies with the credit facility service. In other words, for a customer to enjoy the credit service, they must take at least one insurance policy. The platform allows for the micro charging of the insurance premium from any customer account e.g., daily, weekly, monthly etc. and offer a digital insurance claim management system.
Furthermore, the service provider system may provide a loyalty program that offers points for each transaction unit and level status such as silver, gold and platinum. The points may be redeemed for goods and services or used as cashback or any other type of appropriate reward to the customer.
It is accordingly asserted that the invention provides significant advantages over existing systems and methods.
The invention provides a convenient credit facility, an intuitive user experience, and a debt securitization method to provide a superior service to customers using SoV systems. In this respect, customers at the time of purchase may choose to keep their balance untouched and use the credit facility instead. The invention further provides methods to keep the user experience on the system virtually unchanged while giving the customer the option to pay from their balance or credit facility.
The invention further provides a means of securitizing the credit risk (and therefore provide more inclusion) using other users of the SoV systems.
A yet further advantage of the invention provides a method of bundling the credit facility with insurance services.
The invention furthermore provides potentially cheaper cost of finance: by keeping cash in their balance to use it for a cash-out transaction for example would work out cheaper than cashing out a personal loan. The invention can be used for certain transactions that require blocking an amount on the customers’ accounts such as pre-authorization for hotels reservation and car rentals which can only be done with credit cards (credit card penetration is very low in such markets). The invention provides more convenience and control for business expenses by allowing businesses to give credit facilities to their employees on any store of value system.
The customer experience can remain virtually unchanged on the SoV system while giving the customers the choice to switch between the credit and the other accounts. It also allows more financial inclusion on the SoV systems by providing credit risk securitization.
It will further be appreciated that the foregoing example has been provided merely for the purposes of explanation and is in no way to be construed as limiting of the present invention. While the present invention has been described with reference to an exemplary embodiment only, it is understood that the words which have been used herein are words of description and illustration, rather than words of limitation. The present invention is also not intended to be limited to the particulars disclosed herein. Rather, the present invention extends to all functionally equivalent structures, methods and uses, such as are within the scope of the invention.
For example, the invention may be carried out on any suitable device/s which will be provided with the necessary software and hardware components required to carry out the invention. In addition, suitable computer software will be implemented onto the various devices to carry out the invention as described above. These are accordingly not provided in any unnecessary detail as this will be within the competence of a person skilled in the art.

Claims

1 . A method for processing financial transactions for a customer via a mobile device, the method including the steps of:
- utilising an existing, or establishing, a main account for the customer;
- creating a virtual credit account for the customer with a maximum credit limit based on the outcome of a credit scoring;
- receiving a request from the customer to facilitate a financial transaction with the customer able to select if the transaction amount is to be deducted from the main account and/or the credit account; and
- deducting the transaction amount from the selected account and depositing the transaction amount to a specified recipient.
2. The method as claimed in claim 1 , which includes the additional step of utilising an existing, or establishing a funding account for the customer.
3. The method as claimed in claim 2, wherein the step of establishing the funding account is established via the mobile device, a service provider, or financial institution.
4. The method as claimed in claim 3, wherein the funding account is used to fund the virtual credit account and/or the main account and is hosted on a service provider system or the financial institution.
5. The method as claimed in claim 4, wherein if the customer selects that the transaction amount is to be deducted from the credit account, the step of deducting the transaction amount from the selected account includes checking if there are sufficient credit funds available in the customer’s credit account.
6. The method as claimed in claim 5, wherein if there are sufficient credit funds available in the customer’s credit account, the transaction amount is deducted from the credit account with the transaction amount transferred to the recipient.
7. The method as claimed in claim 6, which includes an additional step of sending a confirmation notification to the customer and the recipient.
8. The method as claimed in claim 7, which includes an additional step of offering the customer to convert the transition into an instalment payment.
9. The method as claimed in claim 5, wherein if there are not sufficient funds available in the customer’s credit account but the main account has sufficient funds to cover the credit funds shortfall, the method includes the step of sending a request to the customer requesting whether the funds to cover the credit shortfall can be deducted from the main account.
10. The method as claimed in claim 9, wherein the available credit funds is debited from the credit account and the credit shortfall debited from main account with the transaction amount transferred to the recipient.
1 1. The method as claimed in claim 10, which includes an additional step of sending a confirmation notification to the customer and the recipient.
12. The method as claimed in claim 1 1 , which includes an additional step of offering the customer to convert the transaction into an instalment payment.
13. The method as claimed in claim 5, wherein if there are not sufficient credit funds available on the customer’s credit account and the main account has insufficient funds to cover the credit funds shortfall, the method includes the step of sending a transaction failure message to the customer and prompting the customer to add additional funds into the main account or pay any outstanding debt on the credit account.
14. The method as claimed in any one of the preceding claims, which includes the step of prompting the customer to select what financial transaction the customer wishes to make and from which account the transaction amount should be deducted. 19
15. The method as claimed in claim 14, wherein the financial transaction is in the form of a payment, a money transfer or a reservation of an amount on the credit account.
16. The method as claimed in claim 14, wherein the customer is able to select from which account or linked bank card the transaction amount is to be deducted with an optional prefix/postfix character input in addition to the input of existing menu options.
17. The method as claimed in claim 16, which includes the step of setting a recurring instruction that indicates that the transaction amount of a specific transaction is to be deducted from the credit account, other linked accounts, or bank cards while keeping the same menu options.
18. The method as claimed in claim 14, which includes the step of prompting the customer to select if the financial transaction is to reserve an amount on the credit account, wherein the customer, by indicating that the financial transaction is to reserve an amount on the credit account, can indicate the expiry period or date of the reserved amount.
19. The method as claimed in claim 14, wherein after a customer makes a financial transaction, the method includes the step of prompting the customer if they wish to convert at least some of the transaction into a credit transaction or a number of instalment payments.
20. The method as claimed in any one of the preceding claims, which includes the step of linking the credit account to a virtual or physical card for use by the customer for online and physical payments.
21 .The method as claimed in any one of the preceding claims, which provides for the generation of any one or more of quick response (QR) codes, in-app notifications, token and secure HTTP links to facilitate payments, money transfers and reservations or deposits. 20
22. The method as claims in any one of the preceding claims, which includes the step of allowing the customer to generate a “pay me” or deposit request using static or dynamic quick response (QR) codes and/or push Unstructured Supplementary Service Data (USSD) and send the request to a requestee.
23. The method as claimed in claim 22, which includes the step of providing an approval option which is accessible by the requestee to approve the pay-me or deposit request and transfer the requested amount.
24. The method as claimed in any one of the preceding claims, which provides for the step of linking the credit account to different store of value and closed loop system.
25. The method as claimed in claim 24, wherein the closed loop system includes any closed loop system including any one of a mobile operators’ airtime, vouchers and betting.
26. The method as claimed in any one of preceding claims, which includes the step of allowing a customer to divide the credit account into associated sub-accounts with each sub account linked to different users and/or different main accounts.
27. The method as claimed in claim 26, which includes the step of bundling a single or multiple insurance policies with a credit facility service which provides the virtual credit account and/or establishing or linking a loyalty program with the various transactions.
28. The method as claimed in any one of the preceding claims, which include the step of receiving a payment from a customer’s main account to their credit account to repay an outstanding credit.
29. The method as claimed in any one of the preceding claims, which includes the step of setting up a guarantee for credit purchases if the customer has no credit record or a low credit score. 21
30. The method as claimed in claim 29, wherein the step of setting up the guarantee includes the steps of designating at least one guarantor, collateralizing a portion or the full credit account by the guarantor, and releasing the guarantor from the transaction when the credit account is closed.
31 .The method as claimed in claim 30, wherein the step of designating the guarantors includes providing the guarantors’ details such as MSISDN, email, national identification card number, driver’s license number, bank identification number, voting card number or any other official document number.
32. The method as claimed in claim 31 , wherein once the guarantor’s details are provided, the customer will be prompted to provide how much of the credit account each guarantor is requested to guarantee and the duration.
33. The method as claimed in claim 32, wherein once the guarantor is designated, a notification, which includes include information of the requestor, the amount of the guarantee, a reference number, the call to action and where to find additional information, is sent to each guarantor via an App notification, SMS, USSD push, email and/or other electronic means.
34. The method as claimed in claim 33, wherein the guarantor is able to accept the guarantee by dialling a USSD short code, clicking on a web-based link, sending an SMS, and/or to click on the app notification or open the app and approve the guarantee.
35. The method as claimed in claim 34, wherein the guarantor, by accepting the guarantee, is prompted to enter the customer’s details and/or reference number, confirm the guarantee amount and guarantee duration, accept the terms and conditions of the service provide, and the account details from which to debit the guarantee amount.
36. A system for processing financial transactions for a customer which includes:
- a mobile device which is associated with the customer; 22
- a server on which an application is executed, the server being in wireless communication with the mobile device via at least one channel;
- a recipient device associated with at least one recipient, the recipient device in wireless communication with the server; and wherein the mobile device is configured to receive a request from the customer to make a financial transaction and deduct a transaction amount from either a virtual credit account or a main account of the customer to and transfer the transaction amount to the recipient device. The system as claimed in claim 36, wherein the mobile device is configured to receive the request from the customer via SMS, USSD, mobile application, website, and/or interactive voice response (IVR). The system as claimed in claim 37, wherein the request is sent to the server with the server prompting the customer via the mobile device to indicate what financial transaction they wish to conduct. The system as claimed in any one of claims 36 to 38, wherein the mobile device is any one of the following: mobile telephone; personal digital assistant (PDA); desktop or laptop computer; tablet or the like. The system as claimed in any one of claims 36 to 39, wherein the recipient device is any one of the following: point of sale machines; automated teller machines (ATM); mobile telephones; personal digital assistants (PDA); laptop computers; and desktop computers. The system as claimed in claim 40, wherein the recipient device may be associated with any one of the following recipients: government, utilities, education, commerce, charities, and the like. The system as claimed in any one of claim 36 to 41 , wherein the application which is executed on the server is configured to:
- manage a funding account which is located either on the server or be hosted by a financial institution; 23
- manage the credit accounts: for each customer using the credit facility, a main credit account is opened and may contain many sub-accounts;
- manage escrow accounts: escrow accounts may be created on the server or hosted externally;
- transfer monies (credit, debit, refund) between any accounts on the server;
- set liens or reserve an amount on customers’ accounts on the server;
- get, process and store “know your customerVFICA information;
- provide aggregated data or transactional records of a customer for profiling and credit scoring;
- transfer money, information and manage refunds from any biller;
- transfer money, information and manage refunds from any merchant;
- transfer money, information and manage refunds from any agent;
- exchange regular and ad-hoc reports and data records; and/or
- provide customer care and technical support.
PCT/IB2021/061754 2020-12-23 2021-12-15 A method and system for processing financial transactions for a customer WO2022137026A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
ZA2023/05938A ZA202305938B (en) 2020-12-23 2023-06-05 A method and system for processing financial transactions for a customer

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
ZA2020/08049 2020-12-23
ZA202008049 2020-12-23

Publications (1)

Publication Number Publication Date
WO2022137026A1 true WO2022137026A1 (en) 2022-06-30

Family

ID=79024812

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2021/061754 WO2022137026A1 (en) 2020-12-23 2021-12-15 A method and system for processing financial transactions for a customer

Country Status (2)

Country Link
WO (1) WO2022137026A1 (en)
ZA (1) ZA202305938B (en)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070027799A1 (en) * 2005-07-29 2007-02-01 Jpmorgan Chase Bank, N.A. Universal line of credit having multiple financial product features
US8538845B2 (en) * 2011-06-03 2013-09-17 Mozido, Llc Monetary transaction system
US8676708B1 (en) * 2010-10-29 2014-03-18 Aton Behavioral Finance, LLC Methods and apparatus for facilitating a financial transaction

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070027799A1 (en) * 2005-07-29 2007-02-01 Jpmorgan Chase Bank, N.A. Universal line of credit having multiple financial product features
US8676708B1 (en) * 2010-10-29 2014-03-18 Aton Behavioral Finance, LLC Methods and apparatus for facilitating a financial transaction
US8538845B2 (en) * 2011-06-03 2013-09-17 Mozido, Llc Monetary transaction system

Also Published As

Publication number Publication date
ZA202305938B (en) 2024-03-27

Similar Documents

Publication Publication Date Title
US11120413B2 (en) Monetary transaction system
US9704152B1 (en) Mobile payment systems and methods
US20160132884A1 (en) Real-time payments through financial institution
US20160055583A1 (en) Mobile global exchange platform
US20080027844A1 (en) System and Method for Organising and Operating an Electronic Account
US20080162348A1 (en) Electronic-Purse Transaction Method and System
US20100131397A1 (en) Providing "on behalf of" services for mobile telephone access to payment card account
JP7219359B1 (en) Information processing equipment
US11023873B1 (en) Resources for peer-to-peer messaging
US20120066127A1 (en) Overage service subject to condition
WO2013017695A1 (en) Method, system and process for centralized management and control of a budget and electronic mass distribution of funds
WO2022137026A1 (en) A method and system for processing financial transactions for a customer
WO2016073519A1 (en) Mobile global exchange platform
AU2007327711B2 (en) System of transferring and utilising reusable credit
US20240202817A1 (en) Cellular phone-based consolidated communication and financial account
KR20020030058A (en) Phone number banking account management system and payment method
US20210110441A1 (en) Student loan payment device
US20130325724A1 (en) Remittance subscription
WO2021105753A1 (en) Electronic currency transfer method and system
WO2011089451A1 (en) Method - protocol of tele-communication transactions
WO2008101273A1 (en) System of transferring and utilising reusable credit

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21831118

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 04/10/2023)

122 Ep: pct application non-entry in european phase

Ref document number: 21831118

Country of ref document: EP

Kind code of ref document: A1