System and method for providing an automated trading platform for cross-border settlements

Systems and methods described herein for automated cross-border settlement transactions, the system comprising: a trading platform network coupled to a plurality of settlement solution networks; and an autonomous bot configured to execute a plurality of instructions for: executing a scheduler to convert a plurality of user requirements and system requirements into a target schedule; executing a plurality of settlement transactions via the settlement solutions using the trading platform; determining a differential between the executed settlement transactions and the target schedule; and modifying the execution of future settlement transactions if the differential is greater than a predefined threshold.

TECHNICAL FIELD

The invention relates in general to systems and methods for optimizing cross-border settlements by using automated services to handle and execute transaction calls.

BACKGROUND

Many money transfer service providers operate large money transfer networks that include infrastructure located all over the world. These money transfer networks are utilized to provide money transfer services to customers of the money transfer service providers. For example, the money transfer services allow a first party, referred to as a sending party, to send an amount of funds to a second party, referred to as a receiving party. In order to utilize the money transfer service, the sending party submits a request to the money transfer service provider. The request typically includes information that identifies the sending party and the receiving party, as well as information that indicates the amount of funds, referred to as a send amount, to be transferred to the receiving party. The money transfer service provider typically collects an amount of funds that is greater than the send amount (e.g., due to fees charged by the money transfer service provider for the money transfer transaction service) from the sending party and once the amount of funds is received, a money transfer agent is authorized to fund a remittance of the send amount to a receiving party.

To facilitate money transfer transactions for its customers, a money transfer service provider generally maintains bank accounts in various regions where the money transfer services are to be provided. The amount of funds received from the sending party may be transferred to a first bank account, such as a holding bank account, established with a first bank operating in the region where the sending party is located, and the remittance of the receive amount to the receiving party is funded from a bank account established with a second bank operating in the region where the receiving party is located. For example, where the money transfer transaction is initiated between a sending party located in the United States and a receiving party located in Mexico, funds received from the sending party may be transferred to a first bank account, such as a bank account that the money transfer service provider has established with a bank operating in the United States, and the remittance of the receive amount may be funded from a second bank account, such as a bank account that the money transfer service provider has established with a bank operating in Mexico.

SUMMARY

Systems and methods described herein facilitate the functionality of a network for implementing cryptocurrency based money transfer transactions between a sending party and a receiving party are described. In certain embodiments, there is system for automated cross-border settlement transactions, the system comprising: a trading platform located on at least one server and coupled to a plurality of settlement solutions; and an autonomous bot located on the at least one server, the autonomous bot configured to execute a plurality of instructions for: executing a scheduler to convert a plurality of user requirements and system requirements into a target schedule; executing a plurality of settlement transactions via the settlement solutions using the trading platform; determining a differential between the executed settlement transactions and the target schedule; and modifying the execution of future settlement transactions if the differential is greater than a predefined threshold.

The foregoing has outlined rather broadly the features and technical advantages of the present disclosure in order that the detailed description that follows may be better understood. Additional features and advantages will be described hereinafter which form the subject of the claims. It should be appreciated by those skilled in the art that the conception and specific embodiment disclosed may be readily utilized as a basis for modifying or designing other structures for carrying out the same purposes of the present disclosure. It should also be realized by those skilled in the art that such equivalent constructions do not depart from the scope of the present disclosure as set forth in the appended claims. The novel features which are believed to be characteristic of embodiments described herein, both as to its organization and method of operation, together with further objects and advantages will be better understood from the following written description when considered in connection with the accompanying figures. It is to be expressly understood, however, that each of the figures is provided for the purpose of illustration and description only and is not intended as a definition of the limits of the present disclosure.

DETAILED DESCRIPTION

Specific examples of components, signals, messages, protocols, and arrangements are described below to simplify the present disclosure. These are, of course, merely examples and are not intended to limit the invention from that described in the claims. Well-known elements are presented without detailed description in order not to obscure the present invention in unnecessary detail. For the most part, details unnecessary to obtain a complete understanding of the present invention have been omitted inasmuch as such details are within the skills of persons of ordinary skill in the relevant art.

Referring toFIG.1, one embodiment of an environment100includes a trading platform102that interacts with an autonomous bot104, which represents one or more services that are configured to provide desired functionality. It is understood that both the trading platform102and autonomous bot104may reside on a single server in some embodiments. In the present example, the autonomous bot104may include and/or handle user requirements106(e.g., user transaction parameters), a scheduler and/or optimizer108, and system requirements110(e.g., internal transaction parameters). The autonomous bot104interacts with a customer/user112, which may be a person, another program or service, or an institutional entity, such as a corporate treasury department.

The autonomous bot performs various functions (described below in greater detail) using the trading platform102to interact with third party or in-house settlement solutions. For purposes of example, the settlement solutions include Ripple114, Society for Worldwide Interbank Financial Telecommunication (SWIFT)116, and/or other settlement solutions118. Ripple114is discussed as an example only. There are many other currency and cryptocurrency exchanges. Such exchanges may provide a real time gross settlement system, a cryptocurrency exchange, currency exchange, and remittance network. Accordingly, references herein to settlement solution and/or currency exchange components may include, use, or otherwise interact with the technology of third party remittance network or exchange, such as Ripple. It is understood that Ripple is used for purposes of example and other settlement solutions may be used (including a custom settlement solution), and the present disclosure is not limited to the use of such third-party settlement solutions.

One or more of the components of the autonomous bot104, such as the user requirements106, the scheduler/optimizer108, and system requirements110may include hardware and/or software technology that enables the services provided by the autonomous bot104. It is understood that the components106,108, and110are for purposes of example only, and may be combined in whole or in part, may be further divided into additional subsets, or may be arranged in many different ways.

The autonomous bot104, in conjunction with the trading platform102, may use the settlement solutions114,116, and/or118to accomplish cross border settlements. For example, the autonomous bot104, either separately or in conjunction with the trading platform102, may provide a platform that can initiate and execute cross border settlement transactions. The platform may estimate all transfer costs before executing the settlement. The platform may perform real-time or near-real time cost comparisons with other settlement solutions. The platform may optimize transaction size by breaking up a transaction. The platform may randomize transaction times to prevent hedging. The platform may self-heal after failures have been detected. The platform may automate a settlement transaction based on factors such as currency, time, corridor, duration, and/or cost efficiency. The platform may evaluate liquidity of both the internal and external accounts. The platform may decide between different source currencies to reduce cost.

Referring toFIG.2, a sequence diagram200illustrates one embodiment of a message flow that may occur between components ofFIG.1. The message flow represents a process by which a settlement transaction may occur using the settlement solution114to accomplish cross border settlements. It is understood that other processes may be executed with respect to the settlement solutions116and118.

In some embodiments, the autonomous bot104may be a service living in a web application and its actions are represented by the vertical line under the Web App. The Web App may include a web interface and a server, with a user interacting via the interface and the server executing the logic. The autonomous bot104may be distributed across multiple system nodes, but this adds complexity to the system. For example, such distribution may provide a higher level of availability (e.g., in case a system goes down), but it requires coordination to make sure only one of the nodes is executing a transfer. In other embodiments, the autonomous bot may be configured and/or deployed in a different manner.

FIGS.3through7show how a customer (named Treasury) can interact with the web interface of the Web App. However, the same logic may apply to the autonomous bot104. The Treasury provides the parameters for the bot, and the autonomous bot will handle and execute all calls (e.g., as calls to the RippleNet). The autonomous bot104may automatically confirm the transactions by checking a list of conditions.

In some embodiments, in step202, the Treasury enters parameters for a transaction. In other embodiments, the Treasury may define a single transaction or a specific daily/weekly goal, and only when such a goal is provided will the autonomous bot apply logic to optimize the various transaction parameters. In step204, the Web App gets a token and, in step206, posts a quote collection to the RippleNet. RippleNet forwards the request internally in order to use Ripple's XRP for fund transfers in step208.

RippleNet sends a quote request to all available exchanges that support the requested currency pair (e.g., to Exchange B in step210and simultaneously to Exchange A in step212). These respond to RippleNet in steps216and214, respectively. RippleNet receives the quotes in step218, and sends a single quote to the Web App in step220. For example, assume that the company wants a US→MXN exchange. Exchange A provides a quote for US→crypto, and Exchange B provides a quote for crypto→MXN. RippleNet will combine this information and provide a useful quote back to the company based on the requested currencies.

The Web App posts a quote acceptance to RippleNet in step222, which forwards the request in step224. RippleNet generates a payment ID and locks the quote in step226. In step228, RippleNet sends a quote response, which results in the response being sent to the Web App in step230.

In step232, the Web App initiates various processes such as scheduling calculations, breaking the transaction into smaller transactions, verification checks, and other processes, which are described in detail elsewhere in the present disclosure. The result is presented to the treasury, which confirms the transaction in step234(assuming the transaction is confirmed and not canceled).

In step236, the Web App posts the settlement payment to the RippleNet, which forwards the request in step238. RippleNet sends orders and transfers to the Exchange B in step240, to Ripple's XRP ledger in step242, and to the Exchange A in step244. In step246, RippleNet communicates to the Exchange A to execute the transaction. The Exchange A converts US dollars to XRP in step248, and withdraws the XRP from the XRP ledger in step250.

The XRP ledger performs a digital asset exchange in step252, and deposits the XRP into the Exchange B in step254. Exchange B converts the XRP into the desired fiat currency in step256, and forwards the fiat payment to the payout bank/location in step258. Following this payment process (or while the payment process is ongoing), RippleNet sends a payment response in step260, which is forwarded to the Web App in step262.

Step264represents a loop in which the Web App polls the RippleNet for the transaction status at defined intervals (e.g., every five seconds) until the payment response of step262is received or the transactions fails. If the transaction fails, the autonomous bot may automatically attempt to schedule the transaction again, based on the following information.

The autonomous bot104looks at the platform at a holistic level and generally focuses more on trends rather than individual transactions. If it was transaction specific, a simple retry mechanism would suffice (e.g., restarting at step206following a transaction failure). However, using a holistic approach, the autonomous bot104looks at its goal and determines that it is deviating from its optimal schedule. To resolve this higher-level issue, the autonomous bot104can use multiple options (e.g., more transactions, higher value transactions, different settlement mechanisms, or a combination of these).

Generally, with respect to the flow inFIG.2, some of the autonomous bot logic applies before step206, where the autonomous bot decides the transaction amount and timestamp, some of the autonomous bot logic happens before step236, and some of the autonomous bot logic applies after step262. For manual transactions, the result is presented to Treasury and they have to confirm. For autonomous bot transactions, this is automatically covered, and the autonomous bot is allowed to execute/settle transaction on Treasury's behalf, given that it adheres to the parameters that are set by Treasury112in steps106and110.

Another thing that happens between steps230and232is not shown in the diagram, as this is taken care of by RippleNet. After accepting the quote, all parties (e.g., RippleNet, Exchange A, and Exchange B) are going to prepare for this transaction by making sure they are connected, have enough information, and are willing to proceed. This mutual agreement results into a locked state. In other words, this locked state means that all involved parties are capable and willing to execute this transaction before it is committed. In step232, the process basically waits until this state becomes available. If no locked comes back, the transaction is aborted (and a self-healing process might kick in).

The autonomous bot104consumes the user configuration as will be described below in greater detail. The autonomous bot104may then divide the amount to be transferred into more efficient transaction sizes. These transactions may be scheduled throughout a time window with a quasi-random timestamp. While the transaction is being triggered, a list of checks may be verified.

A list of verification checks includes, but is not limited to, checking the proposed settlement cost on the chosen rails, checking the live FX rates at large financial institutions, checking liquidity in the destination market, checking liquidity at the sender (making sure enough funds are available), checking that the transaction does not exceed any of the risk parameters, checking if all services required to execute this trade are operational and active, and/or checking if this settlement transaction exceeds a minimum profitability margin. If all of the verification checks pass, only then will the settlement transaction be executed.

Checking the proposed settlement cost on the chosen rails involves one or more rails, which are technical channels for moving money. For example, rails may include SWIFT (the default, bank to bank transfer), RippleNet, and Visa Direct. Rail selections may be chosen based on cost and/or other parameters, such as time. As an example of time differences, RippleNet is relatively quick (e.g., thirty minutes), whereas SWIFT is around two to three days. It is noted that SWIFT is relatively slow, expensive, has high error rates, and very little transaction transparency, and while RippleNet tries to address these shortcomings, it comes with a lack of liquidity. Factors other than transaction cost may also be taken into account. For example, accessibility to funds may play a significant role from a cash flow, compliance, and liability perspective. Certain settlement methods that might be cheaper in cost may also have much longer processing times, resulting in friction throughout the settlement environment.

Checking the live FX rates at large financial institutions involves validating whether the delta of the two is within a maximum FX spread, which is directed to a percentage that dictates the maximum allowed negative deviation from a given benchmark. A positive deviation may always be allowed, as this is financially beneficial for the company.

Checking that the transaction does not exceed any of the risk parameters involves the volatility of cryptocurrency. More specifically, given the volatility of cryptocurrency, holding a large amount of cryptocurrency is considered a risk. Accordingly, limitations may be put in place to prevent transactions with excessive amounts to reduce the risk. Some or every exchange for some or all transactions may be checked to make sure any defined balance thresholds are not exceeded. Threshold examples are shown inFIG.4.

Checking whether all services required to execute this trade are operational and active involves a process where a health check is executed for each of the infrastructure components. In other words, the platform will check to see that each component is “healthy” before initiating the transactions. This prevents a transaction from being locked in a limbo state from semi-executing transactions or failures.

Checking whether this settlement transaction exceeds a minimum profitability margin involves a cost analysis. More specifically, for most money movement scenarios, there are costs involved. For international transactions, these costs are generally split into two components: an FX rate and a fee. However, there can be many more components, like taxes, discounts, incentives, etc. As these cost components can vary per transaction based on external variables, it can be complex to manage these individual variables. Accordingly, the system may look at the result (e.g., it calculates the final transaction cost) and compares that to the cost of doing business for this transaction. It is noted that this is the profit on moving the money, not the profit made from a consumer. For example, a range of approximately −5% to 5% may be defined as acceptable.

If the trade is unsuccessful or one of the checks fails, a retry policy may kick in that allows the autonomous bot104to re-initiate the trade within a pre-defined time window. The retry may be executed with the same considerations. In addition, a failed health check may block the transaction. It is noted that both retries and self-healing may be implemented, with retries as a micromanagement tool and self-healing as a macro management tool. In another example, if the Market FX rate was too far away from the benchmark, all the calculations would be performed again with current data, but the transaction would not be allowed to proceed if it remained outside of the determined bounds.

Accordingly, in step202, a customer (e.g., the user/customer112) enters parameters for the transaction. In the present example, the customer is the treasury of the business controlling the autonomous bot104and trading platform102.

In another embodiment, for every operation, a user may log into a portal with its user credentials using one of three login types: read only, trader, and admin. The user then selects a day or time window and a specific corridor. One embodiment of an interface that may be presented to the user is shown inFIGS.5-7B. The user has the ability to specify the amount he/she would like to transfer. A spread rate can be provided to specify cost efficiency compared to the SWIFT/Interbank FX rates. After the schedule button is pressed, the entire process will be executed in an automated manner.

In some embodiments, the autonomous bot104may include some or all of the following functionality to manage the scheduler/optimizer108in light of the user requirements106and system requirements110. The autonomous bot104may include the ability to cancel the scheduler and reset intraday and, within that, to be able to set the scheduler for same day trading. The autonomous bot104may include the ability to start scheduler on the current day. The autonomous bot104may include the ability to adjust the scheduler on the current day. The autonomous bot104may include the ability to pause/disable the scheduler on the current day (e.g., to support internal and/or external maintenance downtime). The autonomous bot104may include the ability to reduce the average transaction size (ATS) to increase rates/profitability. The autonomous bot104may include the ability to increase volume during business hours. The autonomous bot104may include the ability to self-heal, meaning that failed autonomous bot transactions should be recovered during the rest of the day if possible.

Referring toFIGS.8and9, in one embodiment, the autonomous bot104may execute the following processes. To initiate, a user112(e.g., the treasury ofFIG.2) provides parameters such as a daily goal, currency, and a maximum amount per transaction. The scheduler108converts these daily goals into a target schedule. In the present example ofFIG.8, because the user112is planning to send more money during business hours, the slope of the graph changes. A buffer may be left at the end of the day with no planned transaction, which provides an opportunity to recover automatically if necessary.

The autonomous bot104may continuously run or may wake up at randomized timestamps to prevent FX hedging. It will calculate the distance between the current time and the suggested scheduler target. The autonomous bot104has a transaction size range (e.g., from $300 to $50,000), so for low deviations it can modify the transaction size to achieve a desired result. If the deviation from the target is too large so resolve with increasing the transaction size, the autonomous bot may automatically increase the transaction frequency.

Before each transaction is committed, some or all of the previously described validation steps are taken into account. If one of them fails, the transaction will not be executed, resulting in the daily send amount trailing further away from the target amount. This may prompt the autonomous bot to recalculate its execution scheduler.

Referring toFIG.10, one embodiment of an exemplary computing system1000is illustrated. The system1000is one possible example of a portion or all of the components in preceding embodiments, including those ofFIG.1. The system1000may include a controller (e.g., a processor/central processing unit (“CPU”))1002, a memory unit1004, an input/output (“I/O”) device1006, and a network interface1008. The components1002,1004,1006, and1008are interconnected by a data transport system (e.g., a bus)1010. A power supply (PS)1012may provide power to components of the system1000via a power transport system1014(shown with data transport system1010, although the power and data transport systems may be separate).

It is understood that the system1000may be differently configured and that each of the listed components may actually represent several different components. For example, the CPU1002may actually represent a multi-processor or a distributed processing system; the memory unit1004may include different levels of cache memory, main memory, hard disks, and remote storage locations; the I/O device1006may include monitors, keyboards, and the like; and the network interface1008may include one or more network cards providing one or more wired and/or wireless connections to a network1016. Therefore, a wide range of flexibility is anticipated in the configuration of the system1000, which may range from a single physical platform configured primarily for a single user or autonomous operation to a distributed multi-user platform such as a cloud computing system.

The system1000may use any operating system (or multiple operating systems), including various versions of operating systems provided by Microsoft (such as WINDOWS), Apple (such as Mac OS X), UNIX, and LINUX, and may include operating systems specifically developed for handheld devices (e.g., iOS, Android, Blackberry, and/or Windows Phone), personal computers, servers, and other computing platforms depending on the use of the system1000. The operating system, as well as other instructions (e.g., for telecommunications and/or other functions provided by the system1000), may be stored in the memory unit1004and executed by the processor1002. In other embodiments, the memory unit1004may be a distributed memory system distributed across a number of computer systems on a network or networks.

The foregoing description of the embodiments of the invention has been presented for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed. Many combinations, modifications and variations are possible in light of the above teaching. For instance, in certain embodiments, each of the above described components and features may be individually or sequentially combined with other components or features and still be within the scope of the present invention. Undescribed embodiments which have interchanged components are still within the scope of the present invention. It is intended that the scope of the invention be limited not by this detailed description, but rather by the claims.