Remittance system using stablecoins

Abstract

The aim is to provide a remittance system that enables international money transfers using stablecoins (SC) without going through correspondent banks, while integrating with the SWIFT system. [Solution] The remittance system 1A consists of a sending-side integration subsystem 10A connected to the sending-side financial institution system of the remitter, a receiving-side integration subsystem 10B connected to the receiving-side financial institution system of the recipient, a blockchain management subsystem 20 connected to the sending-side integration subsystem 10A and the receiving-side integration subsystem 10B via the SWIFT system 2, and a plurality of blockchains 30A, 30B connected to the blockchain management subsystem 20. The blockchain management subsystem 20 and the sending-side integration subsystem 10A transmit information regarding SC movements on the plurality of blockchains to the SWIFT system 2.

Description

Technical Field

[0001] The present invention relates to a remittance system for performing international remittances using stable coins (SCs), and more particularly to a remittance system for performing international remittances using SCs in cooperation with the SWIFT system.

Background Art

[0002] A digital currency called SC has attracted attention. SC is a coin issued on a blockchain and linked (pegged) to a fiat currency. It is expected to be used for international remittances.

[0003] Currently, fiat currencies are mainly used for international remittances between countries. In order to smoothly conduct international remittances, SWIFT (The Society for Worldwide Interbank Financial Telecommunication, the International Bankers' Association for Communication, hereinafter referred to as "SWIFT") provides the SWIFT system. The SWIFT system is a messaging system that connects the financial institution systems of various countries. The SWIFT system does not actually remit money, but transmits transaction orders between financial institutions using SWIFT codes.

[0004] Along with the transmission of this transaction order, the remittance is executed from the account of the remitting bank (sending bank) to the account of the beneficiary bank (receiving bank). However, when the remitting bank and the beneficiary bank do not have each other's accounts during international remittances, a correspondent bank that mediates the remittance is required.

[0005] Patent Document 1 describes a money management system that uses SC for remittance. This remittance management system comprises: a token issuing unit that issues blockchain tokens, which are stablecoins pegged to legal tender, in proportion to the amount of a deposit from a settlor to a trustee; a token transfer processing unit that, in response to a transfer of all or part of the deposit from the trustee, moves an amount of the tokens corresponding to the transfer amount from the trustee's first account on the blockchain to a second account on the blockchain that is the recipient of the deposit; a transaction information acquisition unit that acquires transaction information indicating a transaction between accounts of a financial institution; and a verification processing unit that verifies that the amount of the tokens moved from the first account to the second account corresponds to the amount transferred from the trustee's account to the recipient account as indicated by the transaction information (Claim 1). [Prior art documents] [Patent Documents]

[0006] [Patent Document 1] Japanese Patent Publication No. 6738113 (International Publication 2021 / 234974) [Overview of the project] [Problems that the invention aims to solve]

[0007] In conventional international money transfers using the SWIFT system, transfers were time-consuming when going through correspondent banks.

[0008] International money transfers using the SWIFT system via blockchain have not yet been carried out. Furthermore, the money management system described in Patent Document 1 does not utilize the SWIFT system, but simply uses blockchain to perform transfers, and does not consider integration with the SWIFT system.

[0009] The present invention aims to provide a remittance system that enables international remittances using SC (Securities Chain) without going through correspondent banks, while cooperating with the SWIFT system.

[0010] Furthermore, when conducting international remittances using SC, it is conceivable that the sending and receiving financial institutions may use multiple or different SCs and the underlying blockchains. Currently, there is no system in place to send SCs across multiple or different blockchains (performing cross-chain transfers).

[0011] The present invention aims to provide a remittance system that utilizes the SWIFT system to perform international remittances using SC across multiple blockchains. [Means for solving the problem]

[0012] Each embodiment of the present invention is configured as follows. (Example 1) A remittance system that uses stablecoins (SC) to perform international remittances in conjunction with a SWIFT system connected to a financial institution system, A sending-side integration subsystem connected to the sending-side financial institution system, A receiving financial institution system connected to the receiving financial institution's system, The blockchain management subsystem is connected to the sending-side collaboration subsystem and the receiving-side collaboration subsystem via the Swift system. The blockchain management subsystem is connected to a plurality of blockchains or a single blockchain, The blockchain management subsystem and the sending-side coordination subsystem are a remittance system that transmits information regarding SC movements on the multiple blockchains or the single blockchain to the SWIFT system.

[0013] (Example of the embodiment 2) The remittance system described in Example 1, The information regarding the aforementioned SC movement is related to the SC transaction (Tx), and is part of the remittance system. (Example 3) The remittance system described in Example 1, The aforementioned sending-side linkage subsystem is a remittance system that sends remittance instructions to the blockchain management subsystem via the Swift system. (Example of the pattern 4) The remittance system described in Example 3, The remittance system is such that the aforementioned remittance instruction is a transaction (Tx) signed with the private key of the sending-side interoperation subsystem.

[0014] (Example of the embodiment 5) The remittance system described in Example 1, The aforementioned multiple blockchains consist of a sending blockchain and a receiving blockchain. The blockchain management subsystem, upon receiving the remittance instruction from the sending side cooperation subsystem via the SWIFT system, locks the sending side SC on the sending side blockchain and unlocks the receiving side SC on the receiving side blockchain, thereby providing a remittance system. (Example 6) The remittance system described in Example 5, The locking of the sending SC causes the sending SC to be moved from the sending account to the liquidity pool on the sending blockchain. A remittance system in which, upon unlocking the recipient SC, the recipient SC is moved from the liquidity pool to the recipient account on the recipient blockchain.

[0015] (Example 7) The remittance system described in Example 5, The blockchain management subsystem is a remittance system that detects and verifies packets for verifying the legitimacy of transactions or data related to the locking of the sending blockchain on the sending blockchain, and detects and verifies packets for verifying the legitimacy of transactions or data related to the unlocking of the receiving blockchain on the receiving blockchain. (Example of the embodiment 8) The remittance system according to Embodiment Example 7, wherein the destination-side cooperation subsystem transmits a request for obtaining a remittance status to the blockchain management subsystem via the Swift system. (Embodiment Example 9) The remittance system according to Embodiment Example 8, wherein when the blockchain management subsystem receives the request for obtaining the remittance status, it transmits the remittance status based on the approval of locking the destination-side SC and the approval of unlocking the payee-side SC to the destination-side cooperation subsystem via the Swift system.

[0016] (Embodiment Example 10) The remittance system according to Embodiment Example 1, wherein the destination-side cooperation subsystem transmits the completion of SC remittance to the payee-side cooperation subsystem via the Swift system. (Embodiment Example 11) The remittance system according to Embodiment Example 1, wherein the plurality of blockchains are composed of a destination-side blockchain and a payee-side blockchain, the blockchain management system includes a gas fee manager that processes a destination-side gas fee (commission) generated when moving the destination-side SC in the destination-side blockchain and a payee-side gas fee generated when moving the payee-side SC in the payee-side blockchain, and the gas fee manager substitutes for the payment of the destination-side gas fee using the native token of the destination-side blockchain and substitutes for the payment of the payee-side gas fee using the native token of the payee-side blockchain. (Embodiment Example 12) The remittance system according to Embodiment Example 11, The blockchain management system is a remittance system that requests payment of the sending side SC or sending side legal tender in accordance with the sending side gas fee from the sending side interconnecting subsystem or the sending financial institution system, and also requests payment of the sending side SC or sending side legal tender in accordance with the receiving side gas fee from the sending side interconnecting subsystem or the sending financial institution system.

[0017] (Example 13) The remittance system described in Example 1, The blockchain management subsystem, upon receiving the remittance instruction from the sending-side coordination subsystem via the SWIFT system, executes an SC contract on the single blockchain to move the SC from the sending-side account to the receiving-side account, thereby creating a remittance system. (Example 14) The remittance system described in Example 13, The sending-side linkage subsystem is a remittance system that, via the SWIFT system, sends a request to the blockchain management subsystem to obtain the remittance status.

[0018] (Example 15) The remittance system described in Example 13, The blockchain management system includes a gas fee manager that processes gas fees (transaction charges) incurred when moving SC on the single blockchain. The gas fee manager is a remittance system that uses the native token of the single blockchain to pay the gas fee on behalf of the user. (Example 16) The remittance system described in Example 15, The blockchain management system is a remittance system that requests payment of SC or fiat currency in accordance with the gas fee from the sending-side linkage subsystem or the sending financial institution system. (Example 17) The remittance system described in Example 1, The aforementioned multiple blockchains consist of a sending blockchain and a receiving blockchain. The blockchain management subsystem, upon receiving the remittance instruction from the sending side cooperation subsystem via the SWIFT system, burns (destroys) the sending side SC on the sending side blockchain and mints (issues) the receiving side SC on the receiving side blockchain, thereby providing a remittance system. [Effects of the Invention]

[0019] The remittance system according to the present invention enables international remittances using SC while coordinating with the SWIFT system. [Brief explanation of the drawing]

[0020] [Figure 1] This is a conceptual diagram showing the remittance system according to the first and second embodiments, and the remittance network including the SWIFT system. [Figure 2] This is a configuration diagram showing a remittance system according to the first embodiment. [Figure 3] This is a configuration diagram showing a remittance system according to the second embodiment. [Modes for carrying out the invention]

[0021] Embodiments of the remittance system using SC of the present invention will be described with reference to the drawings. In this embodiment, SC is assumed to be on the "Progmat Coin" platform provided by Progmat Co., Ltd., but the platform and SC of SC are not limited to these. For example, Ethereum, Cosmos, Avalanche, Polygon, etc. can be used as the blockchain that forms the basis of SC. For example, USDT, USDC, JPYC, etc. can be used as SC.

[0022] First, we will explain the terminology used in each embodiment. A "liquidity contract" can be thought of as a place (liquidity pool) for storing a certain amount of SC for supply and demand adjustment. In Ethereum and similar blockchains, it is possible to create an area called a contract account on the blockchain. Tokens (SC in this embodiment) can be held in a contract account. Therefore, a liquidity contract is "a contract account on the blockchain that holds SC as liquidity for supply and demand adjustment."

[0023] A "SC contract" is a contract (program) for creating, managing, and transferring SCs on a blockchain. SC contracts are programmed according to a specific standard (ERC20 compliant) and provide functions such as issuing SCs, transferring ownership, and checking balances. Therefore, SC contracts are programs that are established on each blockchain and have the functions to realize the issuance, management, and transfer of SCs.

[0024] In the first embodiment, the SC contract includes a transfer function. Using this function, the sending blockchain transfers the SC from the sending account's address to the liquidity pool (the SC is locked). On the receiving blockchain, the SC is transferred from the liquidity pool to the receiving account's address (the SC is unlocked).

[0025] IBC (Inter-Blockchain Communication) is a universal interoperability protocol that enables two blockchains performing cross-chain communication to communicate with each other. LCP is middleware that performs Light Client verification on behalf of the sending blockchain for the receiving blockchain, and generates Proof for the sending blockchain to verify its validity at low cost. In the first embodiment, the "IBC / LCP module" on the sending blockchain and the "LCP / relayer" on the blockchain subsystem cooperate with each other to perform communication and data transfer between different blockchains (cross-chain).

[0026] The features of the remittance system according to the embodiment of the present invention are as follows: Feature 1-1: The remittance system is designed for outgoing financial institutions to link with the existing SWIFT system (sending and receiving information). Side-to-side collaboration Provide subsystems and Side-to-side collaboration The subsystem exchanges information related to SC transactions (Tx) with the Swift system. Feature 1-2: The remittance system is designed to work with the existing SWIFT system and the receiving bank. Side-to-side collaboration Subsystems are provided, and the receiving bank Side-to-side collaboration The subsystem exchanges information related to the SC's Tx with the Swift system.

[0027] Furthermore, the remittance system 1 according to each embodiment of the present invention can be divided into a remittance system 1A according to the first embodiment and a remittance system 1B according to the second embodiment, depending on the blockchain situation, as described later.

[0028] [Remittance network including remittance system 1] The remittance network, including the remittance system 1 and SWIFT system 2 according to the first and second embodiments, will be described with reference to Figure 1. The remittance system 1 (1A, 1B) is linked with the SWIFT system 2. The sending side linkage subsystem 10A is connected to the sending financial institution system 3A. The receiving side linkage subsystem 10B is connected to the receiving financial institution system 3B.

[0029] The remittance system 1 consists of a sending-side integration subsystem 10A connected to the SWIFT system 2 to cooperate with the SWIFT system 2 on the sending side, a receiving-side integration subsystem 10B connected to the SWIFT system 2 to cooperate with the SWIFT system 2 on the receiving side, a blockchain management subsystem 20 connected to the sending-side integration subsystem 10A and / or the receiving-side integration subsystem 10B via the SWIFT system, and at least one blockchain 30 (30A, 30B, 30C) connected to the blockchain management subsystem 20.

[0030] As is clear from Figure 1, the remittance system 1 is directly connected to the SWIFT system 2, and the sending financial institution system 3A and the receiving financial institution system 3B are also connected via their respective processing units. Therefore, users on the remittance request terminal device 4A and the recipient terminal device 4B can perform international remittances in the same way as before without changing the conventional user interface UI. Note that although Figure 1 shows only one blockchain 30, it is possible to have multiple blockchains 30A, 30B, etc.

[0031] [First Embodiment (Cross-Chain Case)] In the first embodiment of the remittance system 1A, the sending blockchain 30A and the receiving blockchain 30B are different or multiple.

[0032] As shown in Figure 2, the remittance system 1A consists of a sending-side integration subsystem 10A, a blockchain management subsystem 20, a receiving-side integration subsystem 10B, a sending-side blockchain 30A, and a receiving-side blockchain 30B.

[0033] The sending-side integration subsystem 10A includes a private key manager 12A, a settlement function unit 14A that executes settlement processing, a transaction history storage unit 16A, and SC transaction master data 18A. Liquidity contracts and SC contracts are executed on the sending-side blockchain 30A. IBC / LCP module functions are executed on the sending-side blockchain 30A.

[0034] The blockchain management subsystem 20 comprises an API (Application Programming Interface) server 22 and an LCP / relayer 24. The API server 22 comprises an API manager 22a and a Gas Fee Manager 22b.

[0035] The API manager 22a provides API integration for sending and receiving data between the blockchain management subsystem 20 and the outgoing-side integration subsystem 10A via the Swift system 2.

[0036] The gas fee manager 22b is provided to handle the fees incurred when moving SC between multiple or different blockchains. Gas fees in blockchain are transaction costs incurred on the blockchain, specifically when sending SC.

[0037] The gas fee must be paid in the native token of the underlying blockchain. For example, if the underlying blockchain is Ethereum, it must be paid in the native token, ETH. Therefore, in the first embodiment, the gas fee must be paid in the native token of the sending blockchain 30A and the native token of the receiving blockchain 30B. The blockchain management subsystem 20 holds the sending native tokens and receiving native tokens in the gas fee manager 22b, and can cover the payment of sending gas fees incurred on the sending blockchain 30A and receiving gas fees incurred on the receiving blockchain 30B.

[0038] The sending gas fee generated on the sending blockchain 30A can be paid using one of the following two payment methods: 1 or 2. • Payment Method 1: Payment is received from the sending side integration subsystem 10A in sending side native tokens. Specifically, the blockchain management subsystem 20 sends a payment request to the sending side integration subsystem 10A in sending side native tokens of the sending side blockchain 30A at a predetermined payment request timing. Upon receiving the payment request, the sending side integration subsystem 10A pays the sending side gas fee in native tokens of the sending side blockchain 30A. • Payment method 2: Payment is received in the destination country's legal tender from the destination country's SC or destination country's financial institution system 3A via the destination country's integration subsystem 10A. Specifically, the gas fee manager 22b pays in the native token of the destination country's blockchain 30A, and then the blockchain management subsystem 20 performs a predetermined process to recover the destination country's gas fee from the destination country's integration subsystem 10A or destination country's financial institution system 3A. The predetermined process is, for example, not limited to, the following processes A1 or A2.

[0039] • Process A1: Received from the sending side integration subsystem 10A with the sending side SC. Specifically, the blockchain management subsystem 20 sends a payment request to the sending side integration subsystem 10A at a predetermined payment request timing, using the sending side SC corresponding to the sending side gas fee. Upon receiving the payment request, the sending side integration subsystem 10A moves the sending side SC corresponding to the sending side gas fee from the sending side integration subsystem 10A's SC wallet to the blockchain management subsystem 20's SC wallet. • Process A2: Receive payment in legal tender (JPY, USD, etc.) from the sending financial institution system 3A. Specifically, the blockchain management subsystem 20 sends a payment request to the sending financial institution system 3A in the sending legal tender corresponding to the sending gas fee at a predetermined payment request timing.

[0040] The recipient's gas fee incurred on the recipient's blockchain 30B is paid by the gas fee manager 22b in the native token of the recipient's blockchain 30B, and then the blockchain management subsystem 20 recovers the recipient's gas fee by executing predetermined processes from the sending side integration subsystem 10A or the sending side financial institution system 3A. Predetermined processes include, but are not limited to, the following processes B1 or B2.

[0041] • Process B1: Received from the sending side integration subsystem 10A to the sending side SC. Specifically, the blockchain management subsystem 20 sends a payment request to the sending side integration subsystem 10A at a predetermined payment request timing, using the sending side SC corresponding to the receiving side gas fee. Upon receiving the payment request, the sending side integration subsystem 10A moves the sending side SC corresponding to the receiving side gas fee from the sending side integration subsystem 10A's SC wallet to the blockchain management subsystem 20's SC wallet. • Process B2: Receive payment in the sending financial institution system 3A in the sending legal tender currency (JPY, USD, etc.). Specifically, the blockchain management subsystem 20 sends a payment request to the sending financial institution system 3A in the sending legal tender currency corresponding to the receiving gas fee at a predetermined payment request timing. The aforementioned predetermined payment request timings may be set for each payment request, each predetermined number of payment requests, or each predetermined period of time, for a single outgoing financial institution.

[0042] The recipient-side interoperation subsystem 10B includes a private key manager 12B, a settlement function unit 14B that executes settlement processing, a transaction history storage unit 16B, and SC transaction master data 18B. On the recipient-side blockchain 30B, the liquidity contract and the SC contract are executed as smart contracts. The IBC / LCP module functions are executed on the recipient-side blockchain 30B.

[0043] On the sending blockchain 30A, the liquidity contract is a contract that stores a predetermined amount of sending SC in advance to ensure liquidity. The reason a liquidity contract is necessary is to make a transaction irreversible and final the moment a particular transfer is executed.

[0044] On the receiving blockchain 30B, the liquidity contract is a contract that stores a predetermined amount of receiving SC in advance to secure liquidity. The reason a liquidity contract is necessary is to make the transaction irreversible and final the moment a particular transfer is executed.

[0045] A liquidity contract provides liquidity, enabling the rapid movement of a predetermined amount of outgoing SC and a predetermined amount of incoming SC.

[0046] The LCP / Relayer 24 consists of an LCP execution unit 24a that processes LCP (Light Client Proxy) and a relay 24b that mediates communication between blockchains. The LCP execution unit is middleware provided by Datachain Co., Ltd. and performs processing verification of blockchain interoperability. The LCP / Relayer 24 performs cross-chain SC in cooperation with the IBC / LCP module function on the sending blockchain 30A and the receiving blockchain 30B.

[0047] The LCP execution unit 24a supports IBC (Inter-Blockchain Communication) as a standard protocol for communication between multiple or different blockchains. The relayer 24b requests (creates) the processing packets of the sending blockchain 30A on the sending blockchain 30A and sends a Tx to the receiving blockchain 30B in order to mediate communication between the sending blockchain 30A and the receiving blockchain 30B.

[0048] The features of the SC remittance system according to the first embodiment are as follows: Feature 1-1: The sending side integration subsystem 10A can create transaction information for the sending side SC, and send this transaction information to the sending side blockchain 30A via the Swift system 2 and the API server 22 of the blockchain management subsystem 20.

[0049] Feature 1-2: From the sending account on the sending blockchain 30A, sending SC can be moved to the sending liquidity contract, which is a liquidity pool, using the SC contract.

[0050] Features 1-3: LCP / Relayer 24, using cross-chain technology, can move recipient SC from the liquidity pool on the recipient blockchain 30B to the recipient account using an SC contract, triggered by the detection of packets to verify the legitimacy of transactions and data. The packets include a proposed post-transaction state, including a signature.

[0051] Feature 1-4: Based on a request from the sending side integration subsystem 10A, the blockchain management subsystem 20 can notify the receiving side integration subsystem 10B of the completion of the sending side SC's remittance via the SWIFT system 2. Alternatively, even without a request from the sending side integration subsystem 10A, the blockchain management subsystem 20 can recognize the completion of the sending side SC's remittance from the Tx of the sending side blockchain 30A and notify the receiving side integration subsystem 10B of the completion of the sending side SC's remittance.

[0052] Next, Figure 2 will be used to explain the actual SC remittance processing flow in the remittance system 1A. The following explanation will describe the case where the remittance system 1A executes a lock-unlock method (lock at S002, unlock at S005). First, the remittance request terminal device 4A sends a remittance instruction for a predetermined amount in legal tender or the currency of the sending side, such as SC, to the sending financial institution system 3A. The sending financial institution system 3A sends the remittance instruction to the sending side linkage subsystem 10A.

[0053] In step S001, the sending side cooperation subsystem 10A sends a sending side SC remittance instruction to the blockchain management subsystem 20's API server via the Swift system 2. The sending side SC remittance instruction may preferably be a Tx signed with a private key to verify its legitimacy as a message of the sending side SC, in order to send an amount of sending side SC corresponding to a predetermined amount.

[0054] In step S001, when the API server 22 receives a remittance instruction from the sending SC via the API manager 22a, the gas fee manager 22b takes over the payment of the gas fee, and the process proceeds to step S002.

[0055] In step S002, the blockchain management subsystem 20 sends a lock instruction for the sending SC from the management account address, corresponding to the amount of the transfer. The lock instruction for the sending SC is executed on the sending blockchain 30A by the liquidity contract and the SC contract.

[0056] By executing the SC contract, the sending blockchain 30A From the sending account address above, sending SC (Securities Contribution) corresponding to the transfer amount is moved to the liquidity contract acting as a liquidity pool. The liquidity of the sending SC is secured.

[0057] In step S003, the blockchain management subsystem 20 sends a notification of receipt of the remittance instruction (Tx hash) to the sending-side cooperation subsystem 10A via the SWIFT system 2.

[0058] In step S004, the relayer 24b inside the blockchain management subsystem 20 detects packets to verify the validity of transactions and data. The LCP execution unit 24a verifies the proof. The packets include a proposal for the post-transaction state, including the signature.

[0059] In step S005, the blockchain management subsystem 20 sends an unlock instruction for the recipient SC to the recipient blockchain 30B. On the recipient blockchain 30B, the unlock instruction for the recipient SC is executed by the liquidity contract and the SC contract, and the recipient SC corresponding to the transfer amount is moved from the liquidity pool to the recipient account address.

[0060] In step S006, the relayer 24b inside the blockchain management subsystem 20 detects packets to verify the validity of transactions and data. The LCP execution unit 24a verifies the proof. This completes the transfer from the sending SC to the receiving SC. The packets include a proposal for the post-transaction state, including the signature.

[0061] In step S007, the sending-side integration subsystem 10A sends a request to the blockchain management subsystem 20 via the SWIFT system 2 to obtain the status of the SC transfer using a transfer instruction receipt notification (Tx hash).

[0062] In step S008, the blockchain management subsystem 20 transmits the status of the SC transfer (transfer in progress or transfer completed) to the sending side integration subsystem 10A via the SWIFT system 2. In step S009, the sending side integration subsystem 10A or the blockchain management subsystem 20 exchanges SC information (e.g., Tx) with the SWIFT system 2. Preferably, in step S009, the sending side integration subsystem 10A or the blockchain management subsystem 20 transmits the status of the SC transfer (transfer in progress or transfer completed) to the SWIFT system 2.

[0063] In step S010, the sending-side interoperation subsystem 10A notifies the receiving-side interoperation subsystem 10B of the completion of the SC's remittance via the SWIFT system 2.

[0064] [Modified version of the first embodiment] The first embodiment of the remittance system 1A describes a case where a lock-unlock scheme is used for SC transfers in a cross-chain, but the present invention is not limited thereto. For example, a modified remittance system 1A' can also use a burn-mint scheme instead of a lock-unlock scheme.

[0065] The differences between remittance system 1A' and remittance system 1A are described below. Remittance system 1A' does not have liquidity contracts for the sending blockchain 30A or the receiving blockchain 30B. The LCP / relayer 24 manages the burning of the sending SC and the minting of the receiving SC. Remittance system 1A' includes the following steps S002' and S005' instead of steps S002 and S005 of remittance system 1A.

[0066] In step S002', the blockchain management subsystem 20 sends a burn instruction for the sending SC to the sending blockchain 30A. In accordance with the burn instruction for the sending SC, the burn of the sending SC corresponding to the transaction amount is executed by the SC contract from the sending account address on the sending blockchain 30A.

[0067] In step S005', the blockchain management subsystem 20 sends a mint (new issuance) instruction from the receiving SC to the receiving blockchain 30B. In accordance with the receiving SC's mint instruction, the receiving SC's mint, corresponding to the transfer amount, is executed by the SC contract for the receiving account on the receiving blockchain 30B.

[0068] [Second Embodiment (Single Chain Case)] The remittance system 1B according to the second embodiment is the case where the sending and receiving blockchains are the same (single blockchain 30C). Parts identical to those in the first embodiment are denoted by the same reference numerals and their description is omitted. The gas fee manager 22b in the second embodiment is provided to process the fees (native tokens) incurred when moving SC on the single blockchain 30C.

[0069] Gas fees incurred on a single blockchain, 30C, can be paid using one of the following two payment methods: 1 or 2. • Payment method 1: The sending-side integration subsystem 10A pays with the native token of the single blockchain 30C. • Payment method 2: The gas fee manager 22b pays with the native token of the single blockchain 30C, and then the blockchain management subsystem 20 recovers the gas fee by performing predetermined processing from the sending side integration subsystem 10A or the sending side financial institution system 3A. Predetermined processing is expected to be, for example, the following processing C1 or C2, but is not limited to these.

[0070] Process C1: Receives SC from the sending-side integration subsystem 10A. Specifically, the blockchain management subsystem 20 sends a request to the sending-side integration subsystem 10A to move SC (payment request) according to the sending-side gas fee. In response, SC according to the sending-side gas fee is moved from the SC wallet of the sending-side integration subsystem 10A to the SC wallet of the blockchain management subsystem 20. • Process C2: Receive in fiat currency (JPY, USD, etc.) from the sending financial institution system 3A. Specifically, the blockchain management subsystem 20 sends a payment request in fiat currency corresponding to the gas fee to the sending financial institution system 3A.

[0071] In step S101, the sending side integration subsystem 10A sends a sending side SC remittance instruction to the blockchain management subsystem 20's API server via the Swift system 2. The sending side SC remittance instruction may preferably be a private key signed transaction to move an amount of sending side SC corresponding to a predetermined amount. The private key manager 12A generates a private key signed transaction.

[0072] In step S102, the blockchain management subsystem 20 sends a move instruction for the SC from the management address. The SC move instruction is executed on a single blockchain 30C by the SC contract.

[0073] By executing the SC contract, the amount of SC sent by the sender is transferred from the sender's account address on the single blockchain 30C to the recipient's account address.

[0074] In step S103, the blockchain management subsystem 20 sends a notification of receipt of the remittance instruction (Tx hash) to the sending-side integration subsystem 10A via the SWIFT system 2.

[0075] In step S107, the sending-side integration subsystem 10A sends a request to the blockchain management subsystem 20 via the SWIFT system 2 to obtain the status of the SC transfer using a transaction instruction receipt notification (Tx hash).

[0076] In step S108, the blockchain management subsystem 20 transmits the status of the SC transfer (transfer in progress or transfer completed) to the sending-side communication subsystem 10A via the SWIFT system 2. In step S109, the sending-side communication subsystem 10A or the blockchain management subsystem 20 communicates SC information (e.g., Tx) with the SWIFT system 2. Preferably, in step S109, the sending-side communication subsystem 10A or the blockchain management subsystem 20 sends the status of the SC transfer (transfer in progress or transfer completed) to the SWIFT system 2.

[0077] In step S110, the sending-side interoperation subsystem 10A notifies the receiving-side interoperation subsystem 10B of the completion of the SC's remittance via the SWIFT system 2.

[0078] The features of the remittance system 1B according to the second embodiment are as follows: Feature 2-1: The sending-side integration subsystem 10A can create Tx information for the SC and send it to the single blockchain 30C via the Swift system 2 and the API server.

[0079] Feature 2-2: SC can be sent from the sending account address to the receiving account address on a single blockchain 30C.

[0080] Feature 2-3: Based on a request from the sending side linkage subsystem 10A, the blockchain management subsystem 20 can notify the receiving side linkage subsystem 10B via the SWIFT system 2 of the completion of the sending side SC's remittance. [Explanation of Symbols]

[0081] 1 SC Remittance System 1A SC Remittance System (Cross-Blockchain Type) 1B SC Remittance System (Single Blockchain Type) 2 Swift System 10A Outbound Interoperability Subsystem 10B Receiving side interoperation subsystem 20 Blockchain Management Subsystem 30A Outgoing Blockchain 30B Receiving Blockchain 30C Single Blockchain

Claims

1. A system that executes international remittances using stablecoins (SC) in conjunction with a SWIFT system connected to a financial institution system, wherein the sending financial institution system, the non-sending financial institution system, and the remittance system are connected, and the remittance system is A sending-side integration subsystem connected to the sending-side financial institution system, A receiving financial institution system connected to the receiving financial institution's system, The blockchain management subsystem is connected to the sending-side collaboration subsystem and the receiving-side collaboration subsystem via the Swift system. The blockchain management subsystem is connected to the sending blockchain and receiving blockchain or a single blockchain, The sending-side collaboration subsystem is a system that creates Tx information relating to a transaction (Tx) of the sending-side SC and transmits the Tx information to the sending-side blockchain or the single blockchain via the Swift system and the blockchain management subsystem.

2. The system according to claim 1, The aforementioned outbound-side interoperation subsystem is a system that sends and receives information related to the Tx of the SC to and from the Swift system.

3. The system according to claim 1, The aforementioned sending-side linkage subsystem is a system that sends a remittance instruction to the blockchain management subsystem via the Swift system.

4. The system according to claim 3, The system wherein the remittance instruction is a transaction (Tx) signed with the private key of the sending-side linkage subsystem or the blockchain management subsystem.

5. The system according to claim 1, The blockchain management subsystem, upon receiving a remittance instruction from the sending-side linkage subsystem via the SWIFT system, locks the sending-side SC on the sending-side blockchain and unlocks the receiving-side SC on the receiving-side blockchain.

6. The system according to claim 5, The locking of the sending SC causes the sending SC to be moved from the sending account to the liquidity pool on the sending blockchain. A system in which, upon unlocking the recipient's SC, the recipient's SC is moved from the liquidity pool to the recipient's account on the recipient's blockchain.

7. The system according to claim 6, The blockchain management subsystem is a system that detects and verifies packets for verifying the legitimacy of transactions or data related to locking the sending SC of the sending blockchain, and detects and verifies packets for verifying the legitimacy of transactions or data related to unlocking the receiving SC of the receiving blockchain.

8. The system according to claim 7, The sending-side integration subsystem is a system that sends a request to obtain the remittance status to the blockchain management subsystem via the SWIFT system.

9. The system according to claim 8, The blockchain management subsystem, upon receiving a request to obtain the remittance status, transmits the remittance status, based on the approval of the lock on the sending side SC and the approval of the unlock on the receiving side SC, to the sending side linkage subsystem via the SWIFT system.

10. The system according to claim 1, The sending-side coordination subsystem is a system that notifies the receiving-side coordination subsystem of the completion of the SC's remittance via the Swift system.

11. The system according to claim 1, The blockchain management subsystem includes a gas fee manager that processes the sending gas fee (transaction fee) incurred when moving sending SC on the sending blockchain and the receiving gas fee incurred when moving receiving SC on the receiving blockchain. The gas fee manager is a system that uses the native token of the sending blockchain to pay the sending gas fee and uses the native token of the receiving blockchain to pay the receiving gas fee.

12. The system according to claim 11, The blockchain management subsystem is a system that requests payment of the sending side SC or sending side legal tender in accordance with the sending side gas fee from the sending side interconnecting subsystem or the sending side financial institution system, and also requests payment of the sending side SC or sending side legal tender in accordance with the receiving side gas fee from the sending side interconnecting subsystem or the sending financial institution system.

13. The system according to claim 1, The blockchain management subsystem, upon receiving a transfer instruction from the sending-side coordination subsystem via the SWIFT system, executes an SC contract on the single blockchain to move the SC from the sending-side account to the receiving-side account.

14. The system according to claim 13, The sending-side integration subsystem is a system that sends a request to obtain the remittance status to the blockchain management subsystem via the SWIFT system.

15. The system according to claim 13, The blockchain management subsystem includes a gas fee manager that processes gas fees (transaction charges) incurred when moving SCs on the single blockchain. The gas fee manager is a system that uses the native token of the single blockchain to pay the gas fee on behalf of the user.

16. The system according to claim 15, The blockchain management subsystem is a system that requests payment in SC or fiat currency in accordance with the gas fee from the sending side cooperation subsystem or the sending side financial institution system.

17. The system according to claim 1, The blockchain management subsystem, upon receiving a remittance instruction from the sending side linkage subsystem via the SWIFT system, burns (destroys) the sending side SC on the sending side blockchain and mints (issues) the receiving side SC on the receiving side blockchain.

Images