Fast value transfer between different value systems

Abstract

In a system and method for efficient remittance, a server computer receives, from a first issuer computer via an application programming interface (API), a request to transfer an amount of a first currency to a recipient. The server computer obtains an amount of digital currency corresponding to the amount of first currency and records a record of the transfer to an interactive ledger. The server computer causes the record to be recorded to a blockchain. The server computer transmits a notification of the transfer to a second issuer computer, and receives a request for an amount of a second currency corresponding to the amount of digital currency from the second issuer computer via the API. The server computer transmits the amount of the second currency to the second issuer computer, thereby causing the second issuer computer to provide the amount of the second currency to the recipient.

Description

Background Art

[0001] Remittance involves transferring value from one party to another. Although progress has been made in performing remittances electronically, remittance technologies are generally affected by inefficiencies and delays. For example, in traditional systems, multiple institutions operate within separate ecosystems. To coordinate transfers between different parties, delays are common. Depending on the type of transfer and the destination, remittances typically take one to five days to settle.

[0002] Aspects of the present disclosure, alone and in combination, address these and other problems. Summary of the Invention

[0003] The methods described herein provide a way to extend a user's ability to securely and easily access resources.

[0004] Embodiments include a method that includes: receiving, by a server computer via an application programming interface (API), a request from a first issuer computer to transfer an amount of a first currency to a recipient; obtaining, by the server computer, an amount of digital currency corresponding to the amount of the first currency; recording, by the server computer, a transfer record of the amount of the digital currency to an interledger, where the interledger includes a plurality of records of interactions in both the form of the digital currency and the form of the first currency; causing, by the server computer, a net amount record of a plurality of records including the record in the ledger to be recorded to a blockchain corresponding to the digital currency; transmitting, by the server computer, a notification of the transfer to a second issuer computer; receiving, by the server computer via the API, a request for an amount of a second currency corresponding to the amount of the digital currency from the second issuer computer; and transmitting, by the server computer via the API, a request to the second issuer computer to provide an amount of the second currency corresponding to the amount of the digital currency to the recipient.

[0005] In some aspects, the recipient receives the amount of the second currency in less than ten seconds after the request to transfer the amount of the second currency is received.

[0006] In some aspects, the interledger includes a plurality of sub-ledgers, a sub-ledger among the plurality of sub-ledgers corresponds to the second issuer computer, and the server computer identifies the sub-ledger corresponding to the second issuer computer among the plurality of sub-ledgers and records the record to the sub-ledger corresponding to the second issuer computer.

[0007] In some aspects, the method further includes identifying, by the server computer, a liquidity amount of the digital currency; and determining, by the server computer, that the liquidity amount exceeds a threshold, wherein, in response to the determination, the amount of the digital currency is obtained.

[0008] In some aspects, the request is a first request, the amount of the first currency is a second amount, and the liquidity amount is a first liquidity amount, and the method further includes: receiving, by the server computer via the API from the first issuer computer, a second request to transfer the second amount of the first currency to a recipient; identifying, by the server computer, a second liquidity amount of the digital currency; determining, by the server computer, that the second liquidity amount does not exceed the threshold; and routing, in response to determining that the second liquidity amount does not exceed the threshold, the second request for fiat currency transfer.

[0009] In some aspects, obtaining the amount of the digital currency includes converting the first currency into the digital currency via a remote computing device. In some aspects, obtaining the amount of the digital currency includes minting, by the server computer, the digital currency. In some aspects, obtaining the amount of the digital currency includes obtaining the amount of the digital currency from a liquidity pool held by the server computer.

[0010] In some aspects, the method further includes calculating, by the server computer, a net amount of a plurality of records in the ledger that includes the record. In some aspects, the ledger stores interaction data including a plurality of interactions of transfers, purchases, and sales.

[0011] In some embodiments, a computer-implemented method includes receiving, by a first issuer computer from a user device, a request to transfer an amount of a first currency to a recipient; transmitting, by the first issuer computer via an application programming interface (API) to a server computer, the request to transfer the amount, whereby the server computer: records a transfer record of the amount of the digital currency to an interaction ledger, wherein the interaction ledger includes a plurality of records of interactions in both the form of the digital currency and the form of the first currency; causes the amount of the digital currency to be recorded to a blockchain corresponding to the digital currency; and transmits the amount of the digital currency to a second issuer computer, whereby the second issuer computer provides an amount of a second currency to the recipient.

[0012] In some aspects, the method further includes determining by the first issuer computer that an account associated with a user of the user device has at least the requested amount, wherein the request is transmitted to the server computer via the API in response to the determination.

[0013] The embodiments further include a computing system and a computer-readable medium for performing the above method. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Figure 1 Shows an overview of a system for efficient money transfer according to some embodiments.

[0015] Figure 2 Shows a communication flow diagram of operations performed by a system for efficient money transfer according to some embodiments.

[0016] Figure 3 Shows a block diagram of a server computer of a system for efficient money transfer according to some embodiments.

[0017] Figure 4 Shows a block diagram of an issuer computer of a system for efficient money transfer according to some embodiments.

[0018] Figure 5 Shows a simplified flow diagram of a process for efficient money transfer according to some embodiments.

[0019] Figure 6 Depicts an example of ledger management according to some embodiments.

[0020] Figure 7 Depicts an example of liquidity pooling according to some embodiments. DETAILED DESCRIPTION

[0021] Aspects of the present disclosure provide techniques for efficient money transfer. As described above, in use cases such as sending money cross-border from one currency to another, inefficiencies and delays are common due to the nature of traditional money transfer and settlement techniques. The techniques described herein can use a central settlement ledger and a digital currency blockchain to manage fund transfers, thereby providing substantially instant settlement of funds (even cross-border and between currencies).

[0022] In some instances, a certain amount is transferred to a recipient. For example, a first amount of a first currency (e.g., $500) is transferred to the recipient as a second amount of a second currency (e.g., euros of an equivalent amount). A server computer manages the remittance that can be requested via an application programming interface (API) exposed by the server computer. The server computer receives, via the API, a request from a first issuer computer to transfer an amount of the first currency to the recipient. The server computer obtains an amount of digital currency corresponding to the amount of the first currency, and records a record of the transfer to a ledger. The server computer causes the record to be recorded to a blockchain. The server computer transmits a notification of the transfer to a second issuer computer, and receives, via the API, a request for an amount of the second currency corresponding to the amount of the digital currency from the second issuer computer. The server computer transmits the amount of the second currency to the second issuer computer, thereby causing the second issuer computer to provide the amount of the second currency to the recipient.

[0023] Before discussing the various embodiments, some terms can be described in further detail.

[0024] A "user" can include an individual. In some embodiments, a user can be associated with one or more personal accounts and / or user devices. In some embodiments, a user can also be referred to as a cardholder, account holder, or consumer.

[0025] A "user device" can be any suitable device that can be operated by a user. A user device can include a cellular phone, a personal digital assistant (PDA), a pager, a tablet computer, a personal computer, etc. As additional examples, a user device can include a wearable device (e.g., a watch, a ring, etc.). A user device can include any suitable hardware and software for performing such functions, and can include multiple devices or components.

[0026] A "processor" can refer to any suitable one or more data computing devices. A processor can include one or more microprocessors that work together to achieve the desired function. A processor can include a CPU, which includes at least one high-speed data processor sufficient to execute program components for executing requests generated by a user and / or a system. The CPU can be a microprocessor, such as an AMD Athlon, Duron, and / or Opteron; an IBM and / or Motorola PowerPC; an IBM and Sony Cell processor; an Intel Celeron, Itanium, Pentium, Xeon, and / or XScale; and / or a similar processor.

[0027] "Memory" can be any suitable one or more devices capable of storing electronic data. Suitable memory can include non-transitory computer-readable media that store instructions executable by a processor to implement the desired method. Examples of memory can include one or more memory chips, disk drives, etc. Such memory can operate using any suitable electrical, optical, and / or magnetic operating modes.

[0028] "Server computer" can include a powerful computer or a computer cluster. For example, a server computer can be a mainframe, a small computer cluster, or a group of servers working as a unit. In one instance, a server computer can be a database server coupled to a web server. The server computer can be coupled to a database and can include any hardware, software, other logic, or a combination of the foregoing for servicing requests from one or more client computers. The server computer can include one or more computing devices and can use any of a variety of computing architectures, arrangements, and compilations for servicing requests from one or more client computers.

[0029] "Blockchain" can refer to a distributed database. A blockchain can be used to maintain a growing list of records called blocks. A blockchain can be used to maintain a record of transactions or events between parties in a way that is difficult to forge. Each block in a blockchain can include a number of records as well as a hash of the previous block in the blockchain. If the records in a previous block are changed, then the hash in any of the subsequent blocks can be broken. As a result, in order to forge a given record, a hacker would have to forge the record as well as all subsequent records such that the hashes end up the same. This is extremely difficult in practice. Additionally, a blockchain can be distributed among a large number of entities. Any changes to a blockchain can be verified by comparing the blockchain to multiple individual records.

[0030] "Record" can refer to evidence of one or more interactions. A digital record can be an electronic document of an interaction. A record can include a record identifier and record information. For example, record information can include information describing one or more interactions and / or information associated with the interaction (e.g., a digital signature). Record information can also include a plurality of data packets, each of which includes different data describing different interactions. The record identifier can be a number, a title, or other data value used to identify the record. The record identifier can be non-descriptive as it may not provide any meaningful information about the record information in the record. Examples of records include medical records, academic records, transaction records, voucher issuance records, etc. In some embodiments, records can be stored in the blocks of a blockchain. Individual blocks can include individual records or a predetermined number of records, and a blockchain can be a series of records organized into blocks.

[0031] A "ledger" can be a digital object (e.g., a computer file, a database, a blockchain, etc.) or a physical object for recording transactions. Such transactions can include the exchange of specific resources, goods, services, financial instruments, access (e.g., access to a secure resource or area), etc. Some ledgers can record economic transactions between various accounts and measure and total the economic transactions in terms of monetary units. A ledger can be a permanent summary of all transactions and their amounts, along with the starting and / or ending monetary balances of each account involved in the transactions.

[0032] An "issuer" can refer to an entity that maintains a user's account. The issuer can provide or issue credentials to the user, and the credentials can be used to access the account or resources associated with the account. The account can be associated with a communication device, such as an account registered in an application installed on the communication device. The issuer can also be associated with a host system that performs some or all of the issuer's functions on behalf of the issuer. Examples of issuers can include service providers, banks, merchants, government agencies, transaction processors, etc.

[0033] An "interaction" can be a mutual action, effect, or influence. Exemplary interactions include transactions between two parties and data exchanges between two devices. In some embodiments, an interaction can include a user's request to access secure data, a secure web page, a secure location, etc. In other embodiments, an interaction can include a payment transaction in which two devices can interact to facilitate the payment. An interaction can involve the exchange of monetary funds between two individuals or entities, or the exchange of goods or services for monetary funds.

[0034] The term "message" can include any data or information that can be transmitted from one entity to another (e.g., from one computing device to another). Messages can be communicated internally between devices / components within a computer or computing system, or externally between devices via a communication network. Additionally, a message can be modified, changed, or otherwise altered to include encrypted or anonymized information.

[0035] Figure 1 A general overview diagram of a system 100 for efficient remittance according to some embodiments is shown. System 100 includes one or more user devices (e.g., a first user device 102 and a second user device 110); one or more issuer computers (e.g., a first issuer computer 104 and a second issuer computer 108); and a server computer 106 that is coupled to a blockchain 107A and an exchange 107B.

[0036] Each user device in the user devices (e.g., the first user device 102 and the second user device 110) can be a device operable by a user and capable of executing an application. For example, each of the first user device 102 and the second user device 110 can be a smart phone, a computer, a tablet computer, and so on.

[0037] Each issuer computer in the issuer computers (e.g., the first issuer computer 104 and the second issuer computer 108) can be a computing device operable by an issuer. Examples of issuer computers are described in more detail below with reference to Figure 4 Examples of issuer computers are described in more detail below with reference to

[0038] As described herein, the server computer 106 can include functions for managing remittances. The server computer 106 includes one or more application programming interfaces (APIs), such as API 106A. Examples of server computers are described in more detail below with reference to Figure 3 Examples of server computers are described in more detail below with reference to

[0039] The blockchain 107A is a blockchain ledger corresponding to a digital currency. The blockchain 107A can be managed by the server computer 106 or by a third party. In some instances, the blockchain 107A is a stablecoin blockchain, such as the USD Coin (USDC) blockchain or the Tether (USDT) blockchain. (See, e.g., Hayes et al., “Stablecoins: Definition, How They Work, and Types,” Investopedia, available at https: / / www.investopedia.com / terms / s / stablecoin.asp (2022); Picardo et al., “USD Coin (USDC): Definition, How It Works in Currency, and Value,” Investopedia, available at https: / / www.investopedia.com / usd-coin-5210435 (2022)).

[0040] In some embodiments, stablecoins such as USDC are implemented for remittance. A stablecoin is a digital currency with a stable value, whose market price is backed by stable assets based on low volatility. Stablecoins are also different from central bank digital currencies (CBDCs), which are digital representations of a central bank's own fiat currency and direct obligations. Compared with CBDCs, stablecoins are private market digital alternatives to fiat currencies in terms of a reliable exchange medium. Stablecoin transactions can occur without a bank intermediary, enabling instant settlement between transacting parties regardless of geographical location. Stablecoin interactions are particularly suitable for the technologies described herein because stablecoin interactions are permitted, interoperable, trusted, stable, and open-loop.

[0041] In some instances, exchange 107B is a currency exchange service. Exchange 107B can be managed by server computer 106 or by a third party. In some instances, exchange 107B is a digital payment network, such as Visa (See, for example, “VisaDirect”, Visa, available at https: / / usa.visa.com / run-your-business / visa-direct.html (2022)).

[0042] Figure 2 A communication flowchart of operations for efficient remittance according to some embodiments is shown. In Figure 2 the depicted example, the operations are performed by a first user 201 (e.g., associated with Figure 1 a first user device 102), a first issuer 203 (e.g., associated with Figure 1 a first issuer computer 104), a server computer 205 (e.g., Figure 1 the server computer 106), a second issuer 207 (e.g., associated with Figure 1 a second issuer computer 108), and a second user 209 (e.g., associated with Figure 1 a second user device 110).

[0043] At step 202, the first user 201 may submit a request for funds. For example, the first user 201 may transmit a transfer request to the first issuer 203 to transfer a certain amount of a currency, such as X US dollars, to the second user 209. The request may be, for example, an electronic transfer request sent from the first user device to the first issuer computer via a network. Then the first issuer 203 receives the request.

[0044] At step 204, the first issuer 203 determines whether the first user has a profile identifier established for the alias system. The alias system can be maintained by a server computer or a third party and can map user identifiers to one or more accounts. The alias system can manage an alias directory that can be used to identify a recipient without the need for an account or bank identifier. For example, a recipient can be identified based on a name, phone number, email, etc. In some instances, the profile identifier is linked to a data store, such as Figure 6 the user key table 602 depicted in

[0045] At step 206, if the first user does not have an established profile at step 204, the first issuer 203 invokes a create profile API request. Invoking the profile API request can include one or more user identifiers such as a user's first and last name. The profile API request can alternatively or additionally include user contact information such as a mobile phone number and / or an email address. This invocation causes a profile to be generated for the first user to manage the interaction.

[0046] At step 210, if the first user has an established profile at step 204, or after invoking the create profile API request at step 206, the first issuer 203 queries the user balance associated with the first user 201. For example, the first issuer 203 can perform a database query using the identified first user profile identifier to retrieve the user balance information.

[0047] At step 212, the first issuer 203 determines whether the first user has sufficient funds for the transfer request. For example, the first issuer 203 can compare the user balance identified at step 210 with the transfer request amount received at 202. As another example, the first issuer 203 can compare the user balance identified at step 210 with another configured amount (such as the transfer request amount plus a threshold amount).

[0048] At step 214, if the first user has sufficient funds for the transfer request, as determined by the first issuer 203 at step 212, the first issuer 203 performs a call to an API exposed by the server computer 205 (e.g., such as Figure 2 the CryptoXB API shown in Figure 1As described, in some embodiments, a stablecoin (such as USDC) is implemented, which is desirable for the present invention because stablecoins are permitted, interoperable, trusted, stable, and open-loop. Since stablecoins are backed by fiat currency, there is no volatility risk associated with traditional cryptocurrencies such as Bitcoin.

[0049] At step 216, if the first user, as determined by the first issuer 203 at step 212, does not have sufficient funds for the transfer request, the first issuer 203 notifies the user that the funds are insufficient for the transfer request. For example, the first issuer 203 transmits an alert to the user device of the first user 201 via network communication. Based on such an alert, the first user 201 may restart or cancel the transfer at step 220 (e.g., by transmitting a response message to the first issuer computer via the network).

[0050] At step 218, the first issuer 203 determines whether the first user restarts or cancels the transfer. For example, the first issuer 203 parses the response received from the first user to identify whether the user has requested to restart or cancel the transaction.

[0051] At step 224, when it is determined at step 218 that the first user requests to cancel the transfer, the first issuer 203 cancels the transaction and the process ends.

[0052] At step 220, when it is determined at step 218 that the first user requests to restart the transfer, the first issuer 203 and the first user 201 restart the transaction. The next attempt is performed at step 222. At step 212, the first issuer 203 again determines whether the first user has sufficient funds. This may result in calling the API at step 214.

[0053] At step 226, the server computer 205 receives a request for digital currency via the API in response to the API call transmitted at step 214.

[0054] At step 228, the server computer 205 checks to determine whether the liquidity pool associated with the digital currency is sufficient to support the conversion of fiat currency to the amount of digital currency. The server computer 205 may use one or more ledgers to manage the liquidity pools of digital and / or fiat currency across one or more issuers, as described below with reference to Figure 6 and 7As shown in the described example. The server computer can use the liquidity pool to quickly reallocate currency among institutions. For example, the server computer 205 identifies the liquidity amount of available digital currency by querying the ledger and compares this available amount with the requested amount of fiat currency or the amount converted into the implemented digital currency. In the case of a dollar-backed stablecoin, the conversion is one-to-one, and the server computer 205 determines whether the liquidity pool contains at least X dollars (or X dollars plus a certain threshold).

[0055] At step 230, if at step 228 the server computer 205 determines that the liquidity pool is sufficient, the server computer 205 enables the immediate pairing of the amount of fiat currency with the equivalent amount of digital currency. If the amount is already in the liquidity pool, the server computer can adjust the records in the ledger to move the digital currency, thereby immediately executing the transfer.

[0056] At step 234, if at step 228 the server computer 205 determines that the liquidity pool is insufficient, the server computer 205 attempts to mint new digital currency with the available fiat currency. The server computer 205 can use funds deducted from the account balance of the first user to mint digital currency.

[0057] Alternatively, at step 234, if at step 228 the server computer 205 determines that the liquidity pool is insufficient and the server computer 205 is unable to mint new digital currency with the available fiat currency, the server computer routes the request to an alternative payment method, such as Figure 1 the exchange 107B depicted in. For example, if digital currency is unavailable, a fiat currency transfer service can be used as a backup. For example, push payments or ACH transfers can be used as a backup. This provides the benefit of avoiding discarded transactions due to digital currency liquidity issues, as without such a backup, the transaction would be terminated.

[0058] At step 236, if the server computer 205 transfers digital currency to a wallet associated with the second issuer 207, the transaction is recorded in a sub-ledger associated with the second issuer 207. In some aspects, the server computer 205 holds a consolidated wallet on behalf of each issuer. The consolidated wallet includes sub-ledgers that specify the funds allocated to each user (e.g., $50 belongs to user A, $100 belongs to user B, etc.). Alternatively or additionally, the server computer 205 manages a ledger of sub-ledgers with different issuers. The ledger can include interactions in both fiat currency form and digital currency form. The server computer records the transaction into a sub-ledger associated with the second issuer 207 that can be used to identify the net settlement amount across issuers, as described below with respect to Figure 6 andFigure 7 as further described in detail in the example shown.

[0059] The server computer 205 can adjust the balance of the daily consolidated sub-ledger by using a blockchain (e.g., Figure 1 blockchain 107A of ) through the net settlement process between issuers. This adjustment of the balance can be performed substantially immediately. By performing net settlement on the blockchain periodically (e.g., daily) using the pooled amount, the server computer 205 can reduce the interaction with the blockchain, thereby reducing processing and network communication as well as costs.

[0060] At step 238, the second issuer 207 is notified that the digital currency has been received. Then, the second issuer 207 can confirm that the second issuer 207 has the equivalent amount of fiat currency (e.g., the second currency corresponding to the location of the second user) requested by the first user 201. For example, the user has requested to send X dollars to the second user in euros. The second issuer 207 can determine the euro amount equivalent to the amount of the received digital currency and confirm that the second issuer 207 holds the euro amount.

[0061] At step 240, the second issuer 207 determines whether to request the conversion of the digital currency into fiat currency. For example, if the second issuer holds a sufficient amount of the second fiat currency, the second issuer can avoid requesting a conversion from the server.

[0062] At step 242, when it is determined at step 240 that the digital currency should be converted into fiat currency, the second issuer 207 invokes the API exposed by the server computer 205.

[0063] At step 243, when it is determined at step 240 that the digital currency should not be converted into fiat currency, the second issuer 207 holds the digital currency in the integrated wallet. The second issuer 207 can hold the digital currency and use the local currency reserve held by the second issuer 207 to pay the second user 209.

[0064] At step 254, an amount is deposited into the account of the second user 209, and a notification that the funds have arrived is sent. The account of the second user can be updated to reflect the amount transferred to the second user 209.

[0065] At step 244, the server computer 205 determines whether the liquidity pool associated with the digital currency is sufficient to support the conversion of the digital currency into the amount of fiat currency. For example, the server computer 205 identifies the liquidity amount of the digital currency available in the liquidity pool and compares this available amount with the requested fiat currency amount.

[0066] At step 246, if at step 244 the server computer 205 determines that the liquidity pool is sufficient, the server computer 205 enables an immediate pairing of an amount of digital currency with an equivalent amount of fiat currency. The server computer 205 can, for example, reallocate fiat currency (e.g., a second currency) and digital currency in the ledger to account for the exchange of an amount from fiat currency to fiat currency.

[0067] At step 248, if at step 244 the server computer 205 determines that the liquidity pool is insufficient, the server computer 205 attempts to exchange digital currency for fiat currency (e.g., destroying the digital currency, which involves removing a certain amount of digital currency from circulation and receiving available fiat currency). The server computer 205 can transmit a request to an entity managing the digital currency to exchange an amount of digital currency for an amount of fiat currency. In some embodiments, the server computer 205 transmits an amount of digital currency to the entity managing the digital currency. In some cases, the entity managing the digital currency then provides an amount of fiat currency to the server computer and deletes the amount of digital currency from the blockchain record.

[0068] At step 250, upon converting digital currency to fiat currency, fiat currency is transferred to the second issuer 207. As described above, the second issuer 207 can then deposit an amount into the second user's account at step 254.

[0069] Figure 3 A block diagram of a server computer 300 according to some embodiments is shown. The server computer 300 can include a processor 302, a network interface 304, an interactive ledger 314, an API 316, and a computer-readable memory 306 storing code executable by the processor 302.

[0070] The processor 302 can be any suitable processing device or apparatus as described above. The processor 302 can be coupled to the network interface 304 and the computer-readable memory 306.

[0071] The network interface 304 may include an interface that can allow the server computer 300 to communicate with external computers. The network interface 304 may enable the server computer 300 to transfer data with another device (such as a user device, an issuer computer, etc.). Some examples of the network interface 304 may include a modem, a physical network interface (such as an Ethernet card or other network interface card (NIC)), a virtual network interface, a communication port, a Personal Computer Memory Card International Association (PCMCIA) slot and card, and so on. The wireless protocols enabled by the network interface 304 may include Wi-Fi TM . The data transferred via the network interface 304 may be in the form of a signal, which may be an electrical signal, an electromagnetic signal, an optical signal, or any other signal that can be received by an external communication interface (collectively referred to as "electronic signals" or "electronic messages"). These electronic messages that may include data or instructions may be provided between the network interface 304 and other devices via a communication path or channel. As described above, any suitable communication path or channel may be used, such as wires or cables, optical fibers, telephone lines, cellular links, radio frequency (RF) links, WAN or LAN networks, the Internet, or any other suitable medium. The network interface 304 may utilize a telecommunication channel and / or a short-range communication channel.

[0072] The computer-readable memory 306 can be a non-transitory computer-readable medium that includes software code stored as a series of instructions or commands. The computer-readable memory 306 can include a communication module 308, an authentication module 310, a pooling module 312, and / or other suitable software modules. One or more of these software modules can include code executable by the processor 302 to perform functions including receiving, by the server computer, via an application programming interface (API), a request from a first issuer computer to transfer an amount of a first currency to a recipient; obtaining, by the server computer, an amount of digital currency corresponding to the amount of the first currency; recording, by the server computer, a transfer record of the amount of digital currency to an interaction ledger, where the interaction ledger includes a plurality of records of interactions in both the form of the digital currency and the form of the first currency; causing, by the server computer, a net amount record of a plurality of records including the record in the ledger to be recorded to a blockchain corresponding to the digital currency; transmitting, by the server computer, a notice of the transfer to a second issuer computer; receiving, by the server computer, via the API, a request from the second issuer computer for an amount of a second currency corresponding to the amount of the digital currency; and transmitting, by the server computer, via the API, a request to the second issuer computer to provide the recipient with an amount of the second currency corresponding to the amount of the digital currency.

[0073] The communication module 308 can provide the function of generating and transmitting network communications, which can be in the form of request and response messages, API calls, etc. In some aspects, the communication module works in conjunction with the API 316 exposed by the server computer 300. For example, the server computer 300 exposes a CryptoXB API that facilitates transfers based on cross-border digital currencies (e.g., cryptocurrencies) as described herein. The API 316 can receive requests to transfer, generate, and / or convert digital currencies from an issuer (e.g., a first issuer, a second issuer, etc.).

[0074] The authentication module 310 can provide the function of authenticating information for the remittance techniques described herein. For example, the authentication module 310 can determine the existence and status of an account, the amount of funds held in fiat currency or digital currency, etc.

[0075] The pooling module 312 can provide the function of managing the pooling of digital currencies and fiat currencies across users and institutions. As described above with reference to Figure 2 and as described below with reference to Figure 6 and 7 the server computer 300 can maintain a liquidity pool of digital currencies and fiat currencies across issuers, which is used for performing net settlement of amounts on the blockchain.

[0076] The interactive ledger 314 is a ledger that tracks interactions managed by the server computer 300. In some aspects, the interactive ledger 314 includes multiple sub-ledgers (e.g., sub-ledger A 314A, sub-ledger B 314B, etc., as depicted in Figure 3 ). In some aspects, each sub-ledger corresponds to a different issuer. For example, interactions involving a first issuer are recorded in sub-ledger A 314A, and interactions involving a second issuer are recorded in sub-ledger 314B.

[0077] In some aspects, the interactive ledger 314 is used to manage and consolidate balances of both fiat currency (e.g., a first currency such as the US dollar and / or a second currency such as the euro, etc.) and digital currency. Balances can be consolidated for fiat currency balances and digital currency balances on a single ledger. The interactive ledger 314 can account for the status of fiat currency balances, such as pending, available, settled, in-transit, etc., as well as transfers of digital currency assets. The interactive ledger 314 can account for payments, accounting, and transactions of both digital currency and fiat currency across issuers on a single ledger.

[0078] Figure 4 A block diagram of an issuer computer 400 (e.g., the first issuer computer 104 or the second issuer computer 108 as shown in Figure 1 ) according to some embodiments is shown. The issuer computer 400 can include a processor 402, a network interface 404, and a computer-readable memory 406 that stores code executable by the processor 402.

[0079] The processor 402 and the network interface 404 can be similar to the processor 302 and the network interface 304 described above with reference to Figure 3 .

[0080] The computer-readable memory 406 can include a request management module 408, a transfer management module 410, a swap management module 412, and / or other suitable software modules. One or more of these software modules can include code executable by the processor 402 to perform functions including receiving from a user device a request to transfer an amount of a first currency to a recipient; transmitting the request to transfer the amount to a server computer via an application programming interface (API), whereby the server computer: records a transfer record of the amount of digital currency in an interactive ledger, where the interactive ledger includes multiple records of interactions in both the form of the digital currency and in the form of the first currency; causes the amount of the digital currency to be recorded in a blockchain corresponding to the digital currency; and transmits the amount of the digital currency to a second issuer computer, whereby the second issuer computer provides an amount of a second currency to the recipient.

[0081] The request management module 408 may provide a function for managing transfer requests. The request management module 408 may include functions for receiving and verifying requests to transfer funds from one user to another.

[0082] The transfer management module 410 may provide functions for verifying and coordinating fund transfers. For example, the transfer management module 410 may determine whether a user has sufficient funds for a transfer and, if so, transmit the transfer request to the server computer 300 via an API.

[0083] The exchange management module 412 may provide a function for currency exchange. The exchange management module 412 itself may exchange funds from fiat currency to digital currency and vice versa (e.g., funds held by the issuer computer 400). Alternatively or additionally, the exchange management module 412 may manage the exchange by requesting the server computer 300 to perform the exchange and transmitting and receiving amounts of the associated digital currency and fiat currency.

[0084] Figure 5 A simplified flowchart showing a method 500 for efficient money transfer according to some embodiments is presented. Figure 5 The processes depicted therein may be implemented in software (e.g., code, instructions, programs) executed by one or more processing units (e.g., processors, cores) of the respective system or a combination thereof. In Figure 5 The methods presented and described below are intended to be illustrative and non-limiting. Although Figure 5 various processing steps are depicted as occurring in a particular sequence or order, this is not intended to be restrictive. In certain alternative embodiments, the steps may be performed in some different order, or some steps may also be performed in parallel. In some embodiments, Figure 5 the processes depicted therein may be performed by Figure 1 and 3 the server computers of Figure 1 and other components of the system 100 described above with reference to

[0085] At step 502, the server computer receives a request to transfer an amount of a first currency. For example, as Figure 2As shown at steps 202 - 206, the server computer receives a request that may originate from a user request. The request may include an identifier of the payer or first user for the initiating amount, an identifier of the first issuer from which the request is received, an amount of fiat currency associated with a first currency (e.g., US dollar, peso, rupee, etc.), an identifier of the second issuer that receives the transfer, and / or an identifier of the second user that receives the transfer. The request may specify a first (payee) currency (e.g., US dollar) and a second (recipient) currency (e.g., euro). As a specific example, a first user (payer) orders their issuing bank to send X US dollars in euros to their family in Spain. In some aspects, the request is received via the API exposed by the server computer as described above.

[0086] In some embodiments, the server computer identifies the liquidity amount of the digital currency. For example, the server computer identifies the available liquidity amount of the digital currency by querying the ledger and compares this available amount with the requested fiat currency amount or the amount converted into the implemented digital currency. If the liquidity amount exceeds a threshold, the server computer may proceed to step 504. In some aspects, a threshold liquidity amount is configured.

[0087] At step 504, the server computer obtains an amount of digital currency corresponding to the amount of the first currency. Obtaining the amount of digital currency may include obtaining the amount of digital currency from a liquidity pool held by the server computer.

[0088] Alternatively or additionally, the server computer obtains the amount of digital currency by converting the first currency into digital currency via a remote computing device. For example, the server computer obtains digital currency from a digital currency exchange in exchange for an equivalent amount of fiat currency, such as the amount of the first currency. Alternatively or additionally, the server computer may obtain digital currency by minting digital currency. Minting digital currency may include generating digital currency or causing digital currency to be generated. For example, the server computer transfers an amount of fiat currency (e.g., the amount of the first currency) to an account and requests the entity managing the digital currency to create an equivalent amount of digital currency using a smart contract.

[0089] In some embodiments, if the liquidity amount of the digital currency is insufficient, the server computer can route the request to another channel, such as a push payment or an Automated Clearing House (ACH) transfer. The server computer can receive, via an API, a second request from a first issuer computer to transfer a second amount of a first currency to a recipient. The server computer identifies a second liquidity amount of the digital currency and determines that the second liquidity amount does not exceed a threshold. In response to determining that the second liquidity amount does not exceed the threshold, the server computer routes the second request for a fiat currency transfer (e.g., using a push payment, ACH transfer, etc.). As a specific example, for a digital currency-based transfer, a first request to transfer a first amount can be received and routed, and for a fiat currency-based transfer, a second request to transfer a second amount can be received and routed. For the first request, the first liquidity amount is higher than the threshold, and the digital currency is obtained at step 504. For the second request, the second liquidity amount is lower than the threshold, and the second request is routed for a fiat currency transfer. This provides an alternative channel to ensure that transfers continue regardless of the digital currency liquidity status at a given time.

[0090] At step 506, the server computer records the transfer record to an interaction ledger. The ledger includes records of transactions in the form of the first currency and records of interactions in the form of digital currency, as described above with reference to Figure 3 what is described. In some aspects, the ledger includes corresponding sub-ledgers for corresponding issuers. The server computer can identify the sub-ledger corresponding to the receiving issuer (e.g., Figure 2 the second issuer 207) and record the first record to the identified sub-ledger. As described in step 236 above with reference to Figure 2 what is described, in some aspects, the sub-ledger corresponds to a consolidated wallet held by the receiving issuer. The ledger can store interaction data for multiple interactions including transfers, purchases, and sales.

[0091] At step 508, the server computer causes an amount of the digital currency to be recorded to the blockchain corresponding to the digital currency. As described above with reference to Figure 2 what is described, the server computer can use the ledger and sub-ledgers to identify the net amount of the digital currency in circulation across one or more issuers over a period of time (such as a day). The server computer can then perform a net settlement of this amount by periodically (e.g., daily) recording the interactions of the net pooled amount to the blockchain. In other words, the server computer can calculate the net amount of a plurality of records in the ledger including the said record, where the net amount is recorded to the blockchain.

[0092] In some instances, the server computer records the net amount to the blockchain by storing the data payload as a record in the current block of the blockchain. Alternatively or additionally, the server computer causes the net amount to be recorded to the blockchain by another entity, e.g., by sending a request to the entity that manages the blockchain. According to some embodiments, the blockchain may be organized into blocks, and each block may contain one or more records. Each block may include a block identifier, which may be used to query the blockchain for records. The block identifier may be a sequence number, a random number, or the hash of a previous block of the blockchain, etc.

[0093] At step 510, the server computer transmits a notification of the transfer to the second issuer computer. The server computer may notify the second issuer computer that the integrated wallet associated with the second issuer computer has received an amount of digital currency. The notification may be transmitted, e.g., in a message over a network.

[0094] The second issuer computer may determine the reserve amount of the second currency held by the second issuer computer. If the amount of the second currency available is at least equivalent to the amount of the digital currency (or some other threshold amount), then the second issuer computer may hold the digital currency and provide it to the second user using the amount of the second currency. Otherwise, the second issuer computer invokes the API exposed by the server computer to request an amount of the second currency corresponding to the amount of the digital currency, and the process proceeds to step 512.

[0095] At step 512, the server computer receives, via the API, a request from the second issuer computer for an amount of the second currency corresponding to the amount of the digital currency. The server computer may receive an API call from the second issuer computer that may specify the amount of the second currency requested. Alternatively or additionally, the API call may specify the amount of the digital currency and / or the identifier of the second user.

[0096] In response to receiving the request for the amount of the second currency at step 512, the server computer may check the amount of digital currency available in the liquidity pool and attempt to burn the digital currency to receive the second currency, or pair the amount of digital currency held in the liquidity pool with an equivalent amount of the second currency, as described in steps 244-248 above with reference to Figure 2 of.

[0097] At step 514, the server computer transmits to the second issuer computer an amount of the second currency corresponding to the amount of the digital currency. For example, the server computer transmits electronically over a network to send the second issuer computer the amount of the second currency. In response to the request received at step 512, when converting the digital currency to the second currency, the server computer may send the second issuer computer the amount of the second currency.

[0098] Transferring an amount of a second currency to a second issuer computer to cause the second issuer computer to provide the amount of the second currency to a recipient. Receiving the amount of the second currency and / or a notice thereof at step 514 may cause the second issuer computer to provide the amount of the second currency to the recipient, such as by updating account information associated with the recipient.

[0099] As described above, method 500 may provide for an immediate or near - immediate movement of funds (even across borders and between different currencies). In some embodiments, the recipient receives the amount of the second currency in less than ten seconds, less than five seconds, or less than one second after a request to transfer the amount of the second currency is received.

[0100] Figure 6 An example of a data structure 600 for ledger management in accordance with some embodiments is shown. The data structure includes a user key table 602, a transaction ledger 604, an issuer sub - ledger 606, and an issuer central ledger 608. Although Figure 7 USDC is shown as an example of a digital currency, any suitable digital currency may be implemented.

[0101] The user key table 602 includes information associated with a group of users. For each user (e.g., a bank customer), a user identifier 612 is stored in a data store. The user identifier 612 may be, for example, a numerical identifier, the user's first and last name, or any other suitable identifier of the user. In some aspects, the user key table 602 includes multiple user identifiers 612, 613, such as a numerical identifier and a name. The user key table 602 maps an issuer identifier 614 (such as a bank identifier and a country code 616) to a given user. The information in the user key table 602 may be used to identify the issuer associated with a particular user. The information in table 602 may also be used to identify the appropriate currency for a given user based on the country code 616.

[0102] The transaction ledger 604 includes information associated with a group of transactions. In some cases, the transaction ledger 604 includes pre - settlement transactions. In Figure 6 the example shown, the transaction ledger 604 includes a payer identifier 622, a payee identifier 624, and a transferred value 626. The transaction ledger 604 tracks the total value transferred between a group of users associated with different issuers. For example, user A.W.1 from issuer W sends $100 to user B.X.2 at bank X, and the send is recorded on the transaction ledger 604 during a pre - settlement period.

[0103] The issuer sub-ledger 606 records transfers to the sub-ledgers of the respective issuers. The issuer W sub-ledger 632 records transfers to or from issuer W. The issuer X sub-ledger 634 records transfers to or from issuer X. The issuer Y sub-ledger 636 records transfers to or from issuer Y. The issuer Z sub-ledger 638 records transfers to or from issuer Z. The total transfer 639 is also recorded for each respective issuer.

[0104] The issuer central ledger 608 records the digital currency liquidity required in the liquidity pools of each of a group of issuers W, X, Y, and Z. The issuer central ledger 608 further records the total digital currency pool change 642. Figure 7 The examples shown and described below further explain the digital currency liquidity pool.

[0105] Figure 7 An example 700 showing liquidity pooling according to some embodiments is depicted. In Figure 7 the depicted example, the digital currency liquidity of a group of issuers 702 - issuer W, issuer X, issuer Y, and issuer Z is recorded. Although Figure 7 USDC is shown as an example of the digital currency, any suitable digital currency can be implemented.

[0106] For each issuer 702, a corresponding USDC target 704 is recorded. An agreed-upon USDC starting balance is allocated to each issuer, and the agreed-upon USDC starting balance determines the amount required for the overall liquidity pool. In this example, each issuer 702 has a USDC target 704 of $1,000.

[0107] USDC transactions 706 are recorded over a given period of time, such as a day. When a transaction occurs, the corresponding USDC allocation for each issuer 702 changes according to the transaction. For example, as Figure 7 shown, issuer W has a transaction of -$250, issuer Y has a transaction of +$600, etc.

[0108] The overall end-of-period USDC balance 708 is calculated for the given period. For example, for a given date, the USDC transactions 706 are added to or subtracted from the USDC target 704 of a given issuer 702. For example, at the end of the date, the USDC balance is finally determined based on the transactions across all users associated with the given issuer.

[0109] The USDC reconciliation 710 back to the target tracks the amount to be reallocated between the issuers 702 on the ledger so that all issuers 702 return to their respective target USDC allocations 704. Figure 1 and3 The server computer depicted in 3 can mint additional USDC or remove USDC from the pool by converting to fiat currency in order to maintain the USDC target 704.

[0110] Embodiments of the present invention provide several advantages. Compared to traditional remittance techniques that may take hours or even days, using the techniques described herein, funds can be transferred from one user to another within seconds or even immediately. The system generally does not require traditional intermediaries for fiat currency transfers, which reduces the amount of network transmissions and processing required. By using digital currency as the transfer medium between sending and receiving fiat currency, cross-border remittances can be processed immediately or within seconds. On the other hand, traditional cross-border bank transfers require the involvement of multiple payment systems, cooperating banks, and regulatory processes, which makes the traditional remittance process take several days. Using stablecoins as the digital currency medium provides the additional benefits of stability, reliability, and seamless conversion (e.g., from US dollars to USDC or from euros to Euro Coin). Thus, compared to traditional remittance techniques, the techniques described herein can provide significantly faster results and reduce computational resource usage.

[0111] Furthermore, by pooling transactions prior to positions between the settlement blockchain and the issuer, network transmissions and messages for processing the transfer are reduced, thereby saving additional computation and time. The reduction in blockchain and issuer interactions also reduces fees, resulting in a more desirable user experience.

[0112] Additional benefits can be obtained by using a dedicated API. The server computer exposes an API (e.g., a cryptographic API) to each issuer computer, which can be used to transfer data quickly and securely between computing devices. Using a dedicated cryptographic API, the issuer and the server computer can efficiently push and pull data through a secure channel without the need for additional verified transmissions.

[0113] The ability to use existing digital currencies, mint new digital currencies, or route to alternative payment methods (such as ACH transfers) where appropriate provides additional advantages. In this way, the most efficient method can be implemented without failed transactions, as would be the case without a backup.

[0114] Any software component or functionality described in this application can be implemented as software code executed by a processor using, for example, conventional or object-oriented techniques and using any suitable computer language (e.g., Java, C++, or Perl). The software code can be stored as a series of instructions or commands on a computer-readable medium such as random access memory (RAM), read-only memory (ROM), magnetic media (e.g., a hard disk drive or a floppy disk), or optical media (e.g., a CD-ROM). Any such computer-readable medium can reside on or within a single computing device and can exist on or within different computing devices in a system or network.

[0115] The foregoing description is illustrative and not restrictive. Many variations of the invention will become apparent to those skilled in the art upon review of this disclosure. Accordingly, the scope of the invention is not to be determined by reference to the foregoing description, but instead is to be determined by reference to the pending claims and their full scope of equivalents.

[0116] Without departing from the scope of the invention, one or more features of any embodiment can be combined with one or more features of any other embodiment.

[0117] Unless specifically stated to the contrary, the recitation of "a / an" or "the" is intended to mean "one or more."

[0118] All patents, patent applications, publications, and descriptions mentioned above are incorporated by reference in their entirety for all purposes. They are not admitted to be prior art.

Claims

1. A computer - implemented method, comprising: Receiving, by a server computer via an application programming interface (API), a request from a first issuer computer to transfer an amount of a first currency to a recipient; Obtaining, by the server computer, an amount of digital currency corresponding to the amount of the first currency; Recording, by the server computer, a transfer record of the amount of digital currency to an interactive ledger, wherein the interactive ledger includes a plurality of records of interactions in both the form of the digital currency and the form of the first currency; Causing, by the server computer, a net amount record of a plurality of records including the record in the ledger to be recorded to a blockchain corresponding to the digital currency; Transmitting, by the server computer, a notification of the transfer to a second issuer computer; Receiving, by the server computer via the API, a request from the second issuer computer for an amount of a second currency corresponding to the amount of the digital currency; And Transmitting, by the server computer, the amount of the second currency corresponding to the amount of the digital currency to the second issuer computer, Thereby causing the second issuer computer to provide the amount of the second currency to the recipient.

2. The method according to claim 1, wherein the amount of the second currency is received by the recipient in less than ten seconds after the request for transferring the amount of the second currency is received.

3. The method according to claim 1, wherein: The interactive ledger includes a plurality of sub - ledgers, a sub - ledger among the plurality of sub - ledgers corresponds to the second issuer computer, and The server computer identifies the sub - ledger corresponding to the second issuer computer among the plurality of sub - ledgers and records the record to the sub - ledger corresponding to the second issuer computer.

4. The method according to claim 1, further comprising: Identifying, by the server computer, a liquidity amount of the digital currency; And Determining, by the server computer, that the liquidity amount exceeds a threshold, wherein the amount of the digital currency is obtained in response to the determination.

5. The method according to claim 4, wherein the request is a first request, the amount of the first currency is a second amount, and the liquidity amount is a first liquidity amount. The method further comprises: Receiving, by the server computer via the API, a second request from the first issuer computer to transfer a second amount of the first currency to a recipient; Identifying, by the server computer, a second liquidity amount of the digital currency; Determining, by the server computer, that the second liquidity amount does not exceed the threshold; And Routing the second request for a fiat currency transfer in response to determining that the second liquidity amount does not exceed the threshold.

6. The method according to claim 1, wherein obtaining the amount of the digital currency includes converting the first currency into the digital currency via a remote computing device.

7. The method according to claim 1, wherein obtaining the amount of the digital currency includes minting the digital currency by the server computer.

8. The method according to claim 1, further comprising: calculating, by the server computer, a net amount of a plurality of records in the ledger including the record.

9. The method according to claim 1, wherein the ledger stores interaction data of a plurality of interactions including transfers, purchases, and sales.

10. A server computer, comprising: a processor; and a computer-readable medium operatively coupled to the processor to execute a method, the method including: receiving, by the server computer via an application programming interface (API), a request from a first issuer computer to transfer an amount of a first currency to a recipient; obtaining an amount of digital currency corresponding to the amount of the first currency; recording a transfer record of the amount of the digital currency to an interaction ledger, wherein the interaction ledger includes a plurality of records of interactions in both the form of the digital currency and the form of the first currency; causing the amount of the digital currency to be recorded to a blockchain corresponding to the digital currency; transmitting, by the server computer, a notice of the transfer to a second issuer computer; receiving, by the server computer via the API, a request from the second issuer computer for an amount of a second currency corresponding to the amount of the digital currency; and transmitting, by the server computer, the amount of the digital currency to the second issuer computer, whereby the second issuer computer provides the amount of the second currency to the recipient.

11. The server computer according to claim 10, wherein the amount of the second currency is received by the recipient in less than ten seconds after the request to transfer the amount of the second currency is received.

12. The server computer according to claim 10, wherein: the interaction ledger includes a plurality of sub-ledgers, a sub-ledger in the plurality of sub-ledgers corresponding to the second issuer computer, and the server computer identifies the sub-ledger in the plurality of sub-ledgers corresponding to the second issuer computer and records the record to the sub-ledger corresponding to the second issuer computer.

13. The server computer according to claim 10, the method further comprising: identifying a liquidity amount of the digital currency; and determining that the liquidity amount exceeds a threshold, wherein the amount of the digital currency is obtained in response to the determination.

14. The server computer according to claim 13, wherein the request is a first request, the amount of the first currency is a second amount, and the liquidity amount is a first liquidity amount, the method further comprising: receiving, by the server computer via the API, a second request from the first issuer computer to transfer a second amount of the first currency to a recipient; identifying, by the server computer, a second liquidity amount of the digital currency; The server computer determines that the second liquidity amount does not exceed the threshold; and in response to determining that the second liquidity amount does not exceed the threshold, route the second request for fiat currency transfer.

15. The server computer according to claim 10, wherein obtaining the amount of the digital currency comprises one of the following: obtaining the amount of the digital currency from a liquidity pool held by the server computer; converting the first currency into the digital currency via a remote computing device; or minting the digital currency by the server computer.

16. The server computer according to claim 10, the method further comprising: calculating a net amount of a plurality of records in the ledger including the record, wherein the net amount is recorded to the blockchain.

17. The server computer according to claim 10, wherein the ledger stores interaction data of a plurality of interactions including transfers, purchases, and sales.

18. A computer-implemented method, comprising: receiving, by a first issuer computer, a request from a user device to transfer an amount of a first currency to a recipient; transmitting, by the first issuer computer via an application programming interface (API), the request to transfer the amount to a server computer, whereby the server computer: records a transfer record of an amount of digital currency to an interaction ledger, wherein the interaction ledger includes a plurality of records of interactions in both the form of the digital currency and the form of the first currency; causes the amount of the digital currency to be recorded to a blockchain corresponding to the digital currency; and transmits the amount of the digital currency to a second issuer computer, whereby the second issuer computer provides an amount of a second currency to the recipient.

19. The method according to claim 18, further comprising: determining, by the first issuer computer, that an account associated with a user of the user device has at least the requested amount, wherein the request is transmitted to the server computer via the API in response to the determination.

20. The method according to claim 18, wherein the amount of the second currency is received by the recipient in less than ten seconds after the request to transfer the amount of the second currency is received.

21. An issuer computer, comprising: a processor; and a computer-readable medium operatively coupled to the processor to execute the method according to any one of claims 18 to 20.

22. A computer program product comprising instructions executable to execute the method according to any one of claims 1 to 9 or 18 to 20.

Images