Cross payments system

Abstract

Currently, making financial transactions between independent payment systems that are insulated from each other is complex, time-consuming, error- and scam-prone, and necessitates many steps on the part of the sender. The present invention reduces the complexity and the steps for such transactions. Furthermore, the invention allows a transaction request to have one or more recipients from varying payments systems and is implemented such that transaction processing is done through code and the use of API calls.

Description

CROSS PAYM ENTS SYSTEM (CPS)BACKGROU ND OF THE INVENTION

[0001] The present invention relates to a computer method and system for processing financial transactions between independent payments systems.

[0002] Independent payments systems, as stated in our invention, are payments systems for which direct interfaces or integrations don't exist. On the other hand, payments systems that can communicate with each other through a prior established integrated interface, aren't considered by the invention as independent payments systems. For instance, Zelle payment system uses a phone number or an email to make a bank wire within the United States. The Zelle protocol is inherently bound to the banking payment system through its integration with bank accounts. Therefore, Zelle and the Banking payment system aren't considered independent payments systems for our invention's sake. However, sending from Zelle to Ethereum or any other cryptocurrency or sending from Zelle to a foreign mobile money payment such as Orange Money, a French mobile payment system, necessitate wiring through independent and non-integrated payments systems and thus, within the scope of the invention.

[0003] To create interfaces and thus achieve integrations between these independent payments systems, our invention uses a combination of mechanisms: for polling it uses JSON- RPC API and REST API, for communication it uses the WebSocket API, for transport it uses a message queue and finally for storage, it uses a NoSQL database. Let's define each of these terms.

[0004] API stands for Application Programming Interface. It's a set of rules for building and integrating software applications. Application developers create these rules and expose them for other software systems to communicate or integrate with their applications programmatically. Invoking such a rule to communicate with an application is usually referred to as making an API call. For example, an API call to a Foreign Exchange could specify that the client provides the sending and receiving countries to query an exchange rate; the server responds by providing the sending and receiving currencies as well as the exchange rate between the currencies.

[0005] JSON-RPC stands for JavaScript Object Notation-Remote Procedure Call. JSON-RPC API thus defines the set of rules to use the JSON-RPC mechanism. JSON-RPC API allows for notifications requests to be sent to the server and answered asynchronously. More specifically, a notification request is an API call to a specific method on a server. The API call is made of a method to invoke, parameters associated to the method when necessary, and an identifier that matches the request to the response. JSON-RPC simplicity, compactness, and protocol flexibility make it ideal for various network constraints. JSON-RPC's client / server model offers data- handling flexibility, making it preferred for specific use cases like blockchain and Web3 applications.

[0006] REST, commonly known as RESTful, stands for Representational State Transfer. A REST API is therefore an application programming interface that follows the REST architectural style and allows for communication between RESTful web services or applications. REST-style architectures include clients and servers, where clients send requests to the servers that in turn process these requests and return appropriate responses back to the clients. In REST systems, requests and responses are built around the transfer of representations of resources.

[0007] A WebSocket is a computer communications protocol that provides a two-way communication channel over a single Transmission Control Protocol (TCP) connection. It was standardized by the IETF as RFC 6455. The WebSocket enables full-duplex communication between a client application and a web server with lower overhead, thus facilitating real-time data transfer. A WebSocket API is an application programming interface that aligns with the WebSocket protocol. A WebSocket connection is established by a client sending a WebSocket handshake request in the form of, for example, a clear-text request, a server replies with a WebSocket handshake response, and the connection is upgraded to a WebSocket connection.

[0008] Message queues allow different parts of a system to communicate and process operations asynchronously. A message queue provides a lightweight buffer which temporarily stores messages, and endpoints that allow software components to connect to the queue to send and receive messages. The messages are usually small, and can be things like requests, replies, error messages, or just plain information. To send a message, a component, called a producer, adds a message to the queue. The message is stored in the queue until another component, called a consumer, retrieves the message and does something with it. A message queue is known to provide reliable, scalable, loosely coupled, and asynchronous communication.

[0009] NoSQL, also referred to as "not only SQL" or "non-SQL", is an approach to database design that do not use structured query language (SQL) for data handling, it's schema-less and enables the storage and querying of data outside the traditional structures found in relational databases. Instead of the typical tabular structure of a relational database, NoSQL databases house data within one data structure, such as JSON document. Since this non-relational database design does not require a schema, it offers rapid scalability to manage large and typically unstructured data sets and often outperforms traditional relational database management system (RDBMS) in terms of data analysis efficiency, system performance, users' availability and ease of deployment.

[0010] The processing of a transaction, as described in more details below, is done through code and API calls with no human intervention once the transaction request is received in the system. There exist third parties swap mechanisms from centralized and decentralized exchanges to convert between certain independent payments systems, for mobile payments, there exists the USSD (Unstructured Supplementary Service Data) protocol that is a Global System for Mobile Communications (GSM) to send text messages and effectuate crosspayments with supported mobile payments networks.

[0011] Centralized exchanges allow the users to swap from one currency to another within their platforms using a custodial wallet; a decentralized exchange (DEX), on the other hand, uses a non-custodial wallet and relies on Automated Market Makers (AMMs) which use a liquidity pool mechanism to effectuate a currency swap. Whatever the swapping mechanism used, the sender and recipient are one and the same person and the protocols and mechanisms are different from the ones used in the present invention.

[0012] USSD on the other hand, is used for Wireless Application Protocol (WAP) browsing, mobile money payment services, prepaid callback services, menu-based information and location-based content services. With USSD Applications, users interact directly from their mobile phones by making selections from various menus. Unlike a SMS message, a USSD session enables a two-way communication between the user's phone and the USSD application that guarantees instantaneous queries and answers. It works like this: a user's request is sent to the USSD gateway which forwards the request to the USSD application running on the telecommunication network. The process is then repeated in reverse once the request is processed by the USSD application. The present invention doesn't use the USSD protocol described and consequently, doesn't claim the transactions effectuated using this technology.

[0013] The present invention falls under Groups G06Q 10 / 00 - G06Q 50 / 00 and G06Q 99 / 00 of the U.S. patent classification, which covers systems or methods that involve significant data processing operations, i.e. data processing operations that need to be carried out by a technological, e.g. computing, system, or device.SU M MARY OF THE I NVENTION

[0014] Our invention processes transactions between independent payments systems by:

[0015] a. creating a technological financial highway wherein payments systems interface.

[0016] b. plugging payments systems into that highway through a message queue.

[0017] b. processing financial transactions between these plugged-in payments systems.BRI EF DESCRI PTION OF DRAWINGS

[0018] FIG.l is an overview of the main components of the invention; it depicts the interactions between the CPS Engine, the NoSQL database, the processing steps, the message queue and its interfaces, the payments nodes and their underlying payments systems.

[0019] FIG.2 is the transaction flow of a received transaction request. It shows a transaction request's various steps and the status of the overall transaction throughout its processing.

[0020] FIG.3 is a JSON representation of a transaction request. It contains the sender and recipient personal and payment information, among other information.

[0021] FIG.3A is a detailed JSON representation of a recipient's information. The JSON here shows an array which means that more than one recipient can be processed at once.

[0022] FIG.3B is like FIG.3A with the exception that the information herein contained is that of a sender and that only one sender per transaction is allowed.DETAI LED DESCRIPTION OF TH E I NVENTION

[0023] The present invention provides a method and system for processing financial transactions between independent payments systems to reduce the complexities, the challenges and the number of steps needed to perform such financial transactions independently. A financial transaction between independent payments that would have required many steps is reduced to only one step, namely, submitting a transaction request with all relevant information to the Cross-Payment System (CPS). Some payments systems implement a sender's authorization, in that scenario, two steps instead of one are required.

[0024] By way of an example, banking and crypto are independent payments systems residing in different eco-systems. For a user to transfer from a bank account to a crypto account, that individual needs to first go to a cryptocurrency exchange, use a bank account to buy the cryptocurrency equivalency of the wire amount, then using that same exchange or a crypto wallet app, send the cryptocurrency amount to the recipient's crypto account. If the money is sent from the cryptocurrency exchange, this transfer between bank and crypto accounts will have three steps, however, if the user has a crypto wallet and wants to effectuate the transfer within it, then the cryptocurrency will be transferred from the cryptocurrency exchange to the user's wallet before being sent to the recipient, in this scenario, the transfer will require four steps. In our invention, transferring from a bank to a crypto account will only take two steps: submitting the request to CPS and then authorizing the crypto payment. Additionally, if a sender must wire to multiple recipients belonging to different crypto systems, the number of steps required to perform these transactions will be a multiple of the number of recipients factor by three or four steps depending on the above scenarios, in CPS however, that use case is also reduced to only two steps.

[0025] Although our invention covers independent payments systems, it can also process traditional payment transactions. To understand this, let's assume we integrated three independent payments systems in CPS: Zelle, Ethereum and Card. With these three integrations, we can perform nine different financial transactions: Zelle to Zelle, Zelle to Ethereum, Zelle to Card, Ethereum to Ethereum, Ethereum to Zelle, Ethereum to Card, Card to Card, Card to Zelle and Card to Ethereum. Of these, Zelle to Zelle, Ethereum to Ethereum, Card to Card, are not claimed by the present invention because they are transactions within same payment systems and as such, are already implemented by these systems. However, Zelle to Ethereum, Zelle to Card, Ethereum to Zelle, Ethereum to Card, Card to Zelle and Card to Ethereum are transactionsclaimed by the present invention because no direct integrations for these exist. If we add a dependent payment system to this example, let's say banking, then the set: Zelle, Ethereum, Card and Banking, has a subset of dependents systems namely, Bank and Zelle, as stated above. In this scenario also, some payments systems are claimed by the invention, whereas some aren't. For instance, Zelle to Zelle, Ethereum to Ethereum, Card to Card, Banking to Banking, Banking to Zelle and Zelle to Banking are not claimed by the present invention, whereas the remaining transactions are.

[0026] As a formula, for N independent systems integrated in CPS, N2is the total amount of possible financial transactions, with N of these not claimed and N2- N transactions claimed by the present invention. If a subset of Y dependent systems is added to a set of N systems, then the formula becomes: N2total amount of possible transactions and N2- Y2total amount of claimed transactions. Finally, let's consider adding multiple subsets of dependent payment systems within a set of payment systems: Let N be the total number of payment systems, Y be a set of dependent payment systems within N and Z another set of dependent systems within N. With Y and Z independent of each other, the formula here becomes: N2number of possible total transactions, N2- Y2- Z2number of claimed transactions by the invention; thus for 4 independent payment systems integrated, 16 financial transactions can be processed within CPS with 4 of these not claimed and 12 claimed by the present invention as in the initial formula. For 5 payment systems integrated with two of these payment systems being dependent, the total of possible transactions within CPS is 25 and the total amount of claimed 25 - 4, thus 21 transactions, the second scenario of the formula. Finally, for 5 payment systems with two sets of dependent payments systems, let consider here the example of Card, Ethereum, Tether, Zelle and Banking; Tether is an Ethereum's Token, thus the set Ethereum, Ether is a dependent one; Zelle and Banking as discussed above, is also a dependent set, with this in mind, the number of possible transactions is 25, and the number of claimed transactions is 17, 25 - 4 - 4, the third scenario in the formula.

[0027] FIG.l illustrates the main components of the invention. At the heart of the invention are an engine service 101, payments nodes 107 and 108, a message queue 106, and a NoSQL database 102.

[0028] The payments nodes are interfaces to the supported payments systems 109 and 110. For each payment system, the invention prescribes one or more accounts to send and receivemoney. The amount allocated to an account is directly proportional to the financial transactions within that system.

[0029] Finally, the engine service 101 is a service that interfaces 105 with the message queue, to send and receive messages to and from the payments systems via the payment nodes. It acts as the nervous system of the entire invention. FIG.2 details the interactions between the engine service, the message queue, and the NoSQL database. Throughout the description, we will refer to the engine service as CPS Engine 101.

[0030] The CPS Engine is connected to the NoSQL database 204, 104, 206, 209 and 210 and to the message queue 103 and 104. The payments nodes also connect to the same message queue 107 and 108. Messages are exchanged between the CPS Engine and the payments nodes via this message queue 106.

[0031] The messages passing through the message queue and the payments nodes are three in nature: requests, responses status, and errors messages. The CPS Engine sends messages requests to intended payments nodes. The payments nodes reply with responses status to the CPS Engine. These replies reflect the status of the transactions made. Sometimes, however, a transaction request is not properly routed or has missing information, in that case, errors messages are sent back to the CPS Engine as replies.

[0032] The payments nodes only communicate with the CPS Engine 106 and their underlying payments systems 109 and 110; given their independent nature, they can't communicate with each other via the message queue. Additionally, a payment node on its own, can't start a communication with the CPS Engine; rather, working in a master and slave paradigm, they receive requests from the CPS Engine, act on them and then provide responses status or error messages back to CPS Engine 207 and 208. A payment node is code defined in the invention to interface with a card, a bank, a mobile, or a crypto payment system 109 and 110. For a payment system to be included and supported within CPS, two conditions are required: one or more liquidity account(s) in that payment system exist(s) to facilitate CPS send and receive operations, and the payment system has a well-defined API to send and receive money and to get the status of a sent or received transaction.

[0033] A CPS transaction request FIG. 3 is made of a sender FIG. 3B and recipients FIG. 3A and additional information such as status, transaction type, transaction identifier, fee, sender or user identifier and details regarding the debit and disbursement steps.

[0034] The sender's info FIG. 3B consists of personal information such as first and last name, email, address, city, country, currency, language, phone, amount to send and the transaction type. Depending on the payment system, the sender will have further information such as the bank information, the payment identifier ("paymentld") which represents card information, and the phone number for mobile payments. The payment system used is reflected in the transaction type ("transactionType") field.

[0035] The recipient's info FIG. 3A is an array of one or more recipients. The recipient's information consists of personal information such as first and last name, email, address, city, country, language, currency, language, sender identifier ("senderld") which is the same value as the userid field in FIG. 3, and amount to receive. Depending on the payment system, the recipient information will have further information such as the bank info, the payment identifier ("paymentld") which represents card information, the crypto address, and the phone number for mobile payments. The payment system used is reflected in the transaction type ("transactionType") field. The recipients' payments systems, in the case of multiple recipients, need not be the same. For instance, through one transaction request, a sender can send to multiple recipients with varying payment systems such as bank, card, mobile and crypto systems. The CPS Engine will go through that multi-verse request 202 and internally reduce the multi-recipient transaction to 1:1 transactions 201 between the sender and each recipient before doing downstream operations 203.

[0036] Once the CPS Engine receives a transaction request 101, it first checks whether it's a multi-recipient transaction 202; in the event it is 201, the transaction request is transformed to N transactions between the sender and each recipient, N being the number of recipients. Each transaction is assigned a unique transaction identifier ("TransactionlD") 203. After being segmented and ordered 204, a transaction request within the CPS Engine is bound to two phases: a debit phase 103, and a disbursement phase 104. The debit from sender is the first step and the disbursement to recipient is a conditional second step 207 based on the result of the first step.

[0037] In the debit phase, the sender provides personal information, the payment system to debit from, the amount to debit as well as payment information such as card information for card transactions, bank account information for bank transactions, phone number for mobile payments FIG. 3B; in the case of mobile payments, the sender is sent a notification to authorize the payment. For crypto systems with no existing wallets in CPS, a QR-code is sent to performthe actual payment 205. The CPS Engine then sent the debit request through message queue 106 to the designated payment node 107. The payment node in turns creates an API call and sends it to its underlying payment system and waits for the result 109. The result can be sent immediately to the payment node, this is true for card, bank, mobile and certain crypto transactions. In other cases, however, the payment node must use a polling or web socket mechanism to query recent transactions 109.

[0038] Once a request response status is received, the payment node sends a status update to CPS Engine 207. The status received can be a denied, a failed, a pending or a successful transaction. If the status is denied, in which case not approved by the sender, or a failed transaction, in which case payment didn't go through for some reasons, the debit from sender is marked as failed, the entire transaction is aborted 206, and the second step is not performed. A failure notification is sent to the sender 200 and the transaction's state is saved 206 and 102. If the status is pending, nothing happens, the payment node will continue sending API requests to the payment system until either a failure or success response is received 107 and 109. Finally, if the status is a successful transaction, in which case money is debited from the sender to a liquidity account provided by the payment node, a successful notification is sent to the user 200, the debit from sender is marked successful, the transaction's state is saved 104 and 102, and the CPS Engine activates the second step of disbursing money to the recipient 104.

[0039] In this disbursement step 106, the CPS Engine uses the recipient's information FIG. 3A to prepare a payment request by providing all relevant information to do the transfer. The recipient's payment information can be a card, a bank, a mobile or a crypto account.

[0040] The CPS Engine then sends a payment request through message queue 106 to the designated payment node 108. As a result, the payment node triggers an API call to disburse money from its liquidity account to the recipient's provided account 108 and waits for the result. The result can be sent immediately to the payment node, this is true for card, bank, mobile and certain crypto transactions. In other cases, however, the payment node must use a polling or web socket mechanisms to query recent transactions. The polling mechanisms used are JSON-RPC API and REST API; mechanisms defined earlier.

[0041] Once a request response status is received, the payment node sends a status update to the CPS Engine. The status received can be a failed, a pending or a successful transaction 208. If the status is a failed transaction, the disbursement to the recipient is marked as failed, the transaction is saved 102 as failed and refundable, the sender is sent a failed notification withinformation on how to get refunded 209 and 200. If the status is pending, nothing happens, the payment node will continue sending APIs requests to the underlying payment system until either a failure or success response is received 108 and 110. Finally, if the status is a successful disbursement, a successful notification is provided to the sender 210 and 200 and to the recipient 211, the transfer to the recipient and the transaction are marked as successful 210 and saved 102, thus concluding the disbursement phase, and by extension, the transaction request.

Claims

Claims1. I claim a method for processing financial transactions between independent payments systems.

2. The method of claim 1 wherein the number of steps needed to perform these financial transactions, in an eco-system of convoluted and independent payments systems, is reduced.

3. The method of claim 1 wherein the number of steps needed by the sender to perform a transaction is reduced to submitting one transaction request with all the necessary information.

4. The method of claim 1 wherein the number of steps needed by the sender to perform a transaction is reduced to submitting one transaction request and authorizing or paying for its processing.

5. The method of claim 1 wherein a sender can send to one or multiple recipients with varying payments systems in one transaction request.

6. The method of claim 1 wherein a transaction request between independent payments systems is given an identifier, is segmented into a debit from the sender and a disbursement to the recipient and is ordered so that the debit from sender is the first step and the disbursement to the recipient is the conditional second step.

7. The method of claim 1 wherein a transaction is deemed a failure if the debit from the sender is not successful.

8. The method of claim 1 wherein a transaction is deemed a failure if the debit from the sender is successful but the disbursement to the recipient is not.

9. The method of claim 1 wherein a transaction is deemed a success if the debit from the sender and the disbursement to the recipient are both successful.

10. The method of claim 1 wherein a payment system has a well-defined API or method for debiting money from a sender and disbursing money to a recipient, as well as a well-defined API or method for getting the status of a debited or disbursed payment transaction.

11. The method of claim 1 wherein a payment system can be a crypto or digital payment system with an API as described in claim 10.

12. The method of claim 1 wherein a payment system can be a mobile or mobile money payment system with an API as described in claim 10.

13. The method of claim 1 wherein a payment system can be a debit card, a credit card, a prepaid card, an ATM card or any electronic card with an API as described in claim 10.

14. The method of claim 1 wherein a payment system can be a wallet, crypto wallet, digital wallet or e-wallet with an API as described in claim 10.

15. The method of claim 1 wherein a payment system can be a bank performing banking transactions such as domestic and international wire, real time processing (RTP), and ACH with an API as described in claim 10.

16. The method of claim 1 wherein for N independent payments systems integrated in CPS, there are up to N2possible financial payments combinations that can be executed by the invention.

17. The method of claim 1 wherein for N independent payments systems integrated in the invention, there are N2- N maximum payments combinations that are claimed and a minimum of N payments combinations not claimed by this invention.

18. The method of claim 1 wherein for N payments systems with a subset of Y dependent systems integrated in the invention, there are N2- Y2maximum payments combinations that are claimed by this invention.

Images