Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/38—Payment protocols; Details thereof
  • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
  • G06Q20/3827—Use of message hashing
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
  • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
  • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
  • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
  • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/08—Payment architectures
  • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
  • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
  • H04L9/0643—Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
  • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
  • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
  • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
  • H04L9/3297—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving time stamps, e.g. generation of time stamps
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
  • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
  • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Definitions

• a user may interact with a variety of computer systems to initiate a transaction, which may include any exchange or interaction between two or more entities (e.g., between the user and a resource provider).
• the transaction can include the exchange of specific resources, goods, services, financial instruments, access (e.g., to a secure resource or area), and so forth.
• the contractual obligations in the transaction may not all occur simultaneously.
• a user interacting with a computer system to purchase coffee may actually be exchanging a promise to pay for the coffee, since the user may receive the coffee before the transaction clears and the coffee vendor receives payment for the coffee.
• the coffee vendor does not receive payment until the transaction is settled and the funds have been transferred into the vendor's account.
• the payment can take anywhere from 24 hours up to three days to process a payment.
• the present disclosure contemplates embodiments of methods and computing systems associated with real-time settlement using a distributed ledger, such as a blockchain ledger. These embodiments may be further directed to a server computer comprising a processor and a memory coupled to the processor.
• the memory can store instructions, executable by the processor, for implementing the methods described herein.
• a computing system may include a first plurality of nodes hosting a first blockchain ledger.
• This first blockchain ledger records transactions between a first set of users that have all deposited (e.g., funds) into a first pool account.
• the users may be banks or financial entities, and each user may have their own individual set of customers.
• the first blockchain ledger may also record deposits and withdrawals of funds associated with each user in the first set of users. By recording transactions, deposits, and withdrawals associated with each user in the first set of users, the first blockchain ledger can also be used to record and track the account values associated with each user.
• first blockchain ledger can also be used to record and track the current total value of the first pool account, which will initially be the aggregate value of all the deposits from the first set of users.
• additional blockchain ledgers that are each associated with additional pool accounts.
• This second blockchain ledger records transactions, deposits, and withdrawals of funds associated with each user in a second set of users that have all deposited (e.g., funds) into a second pool account.
• the second blockchain ledger also records and tracks the current total value of the second pool account, which will initially be the aggregate value of all the deposits from the second set of users.
• the main blockchain ledger may record changes in the current total value of the various pool accounts, such as the current total value of the first pool account and the current total value of the second pool account. This can be implemented in various ways.
• the third plurality of nodes may be configured to periodically obtain the current total value of the first pool account from the first blockchain ledger and the current total value of the second pool account from the second blockchain ledger, and then the third plurality of nodes may update the main blockchain ledger with those retrieved values.
• the first plurality of nodes and the second plurality of nodes may provide updates to the third plurality of nodes for any changes to the current total value of the first pool account and the current total value of the second pool account (e.g., resulting from transactions associated with users in the first set of users or the second set of users).
• a node of the first plurality of nodes hosting the first blockchain ledger may receive a transaction.
• the first blockchain ledger may record transactions between the first set of users associated with the first pool account, for which each user of the first set of users deposited funds for settlement into the first pool account.
• the first blockchain ledger may record, for each transaction between the first set of users, a payer, a payee, and a transaction amount.
• the received transaction may be from a first user of the first set of users to a second user of the first set of users for a first amount.
• the node of the first plurality of nodes may verify that the received transaction is capable of taking place by checking the first blockchain ledger (e.g., to determine the account value associated with the first user).
• verifying that the transaction is capable of taking place includes checking the first blockchain ledger for a history of transactions associated with the first user.
• verifying that the transaction is capable of taking place includes checking an account value associated with the first user. This account value may be an ongoing count that is updated in real-time as the first user carries out transactions, deposits, and withdrawals of funds.
• the node of the first plurality of nodes may then update the first blockchain ledger with the transaction to include a block with data relating to the first transaction.
• the node of the first plurality of nodes may determine that the transaction reduces an account value associated with the first user below a first threshold and then send a communication to the first user to deposit additional funds into the first pool account. Similarly, in some embodiments, the node of the first plurality of nodes may determine that the transaction increases an account value associated with the second user above a second threshold and then send a communication to the second user to withdraw funds from the first pool account.
• the node of the first plurality of nodes hosting the first blockchain ledger may receive a second transaction from the first user of the first set of users to a third user that did not deposit funds for settlement into the first pool account.
• the node of the first plurality of nodes may verify that the second
• verifying that the transaction is capable of taking place includes checking the first blockchain ledger for a history of transactions associated with the first user.
• verifying that the transaction is capable of taking place includes checking an account value associated with the first user. This account value may be an ongoing count that is updated in real-time as the first user carries out
• the node of the first plurality of nodes may then communicate the second transaction to another plurality of nodes associated with another blockchain ledger, such as communicating to a second plurality of nodes hosting a second blockchain ledger.
• the main blockchain ledger may obtain information from the other blockchain ledgers and be used to facilitate real-time settlement between users of different pools.
• any entity managing or hosting the main blockchain ledger e.g., a node of a plurality nodes
• the transaction can be verified to determine that it is capable of taking place by checking an account value associated with the first user at the first pool account.
• the main blockchain ledger may keep track of the account value associated with the first user and receive periodic updates from a first blockchain ledger associated with the first pool account about any changes to the account value associated with the first user. This first blockchain ledger will record transactions between users that deposited funds for settlement into the first pool account and can be used to track changes in account value for those users, including the first user.
• the main blockchain ledger may request the account value associated with the first user from one of the nodes of a first plurality of nodes hosting the first blockchain ledger that is associated with the first pool account.
• transactions between users of different pools will affect the account values associated with those users, as well as the current total value of those pools. For instance, the current total value of the first pool and the current total value of the second pool will both change as funds are transferred from the first user at the first pool to the second user at the second pool.
• a first communication can then be sent to the first plurality of nodes hosting the first blockchain ledger to instruct the first plurality of nodes to update the first blockchain ledger to include a decrease in the account value associated with the first user at the first pool account by the first amount, which may also decrease the current total value of the first pool.
• a second communication can also be sent to a second plurality of nodes hosting a second blockchain ledger.
• This second blockchain ledger will record transactions between users that deposited funds for settlement into the second pool account and can be used to track changes in account value for those users, including the second user.
• the second communication will instruct the second plurality of nodes to update the second blockchain ledger to include an increase in an account value associated with the second user at the second pool account, which may also increase the current total value of the second pool.
• the first pool account and the second pool account may be associated with different currencies.
• the first user may have deposited a first type of currency (e.g., USD) into the first pool account, which is associated with users from the United States.
• the second user may have deposited a second type of currency (e.g., CAD) into the second pool account, which is associated with users from Canada.
• the account value for the second user that is recorded by the second blockchain ledger may be tracked in CAD, and thus, to receive the first amount being sent in the transaction, the second user may actually have to receive the CAD equivalent to the first amount.
• any entity managing or hosting the main blockchain ledger may determine a currency associated with the second pool account and convert the first amount into a second amount based on the determined currency.
• the second communication will further instruct the second plurality of nodes to update the second blockchain ledger to include the increase in the account value associated with the second user at the second pool account by the second amount (e.g., the CAD equivalent to the first amount).
• the transactions, deposits, and withdrawals of funds for each currency account may also be tracked in the corresponding
• the first pool may have a first currency account and the second pool may have a second currency account.
• a first user of the first pool transacts with a second user of the second pool to send a first amount
• funds from the account of the first user need not be directly transferred to the account of the second user.
• a transaction can be recorded in the first blockchain ledger associated with the first pool indicating the first amount is to be transferred from the first user to the first currency account of the first pool.
• the second blockchain ledger associated with the second pool can record a corresponding transaction in which the first amount is sent from the second currency account of the second pool to the account of the second user.
• the first communication sent to the first plurality of nodes hosting the first blockchain ledger will further instruct the first plurality of nodes to update the first blockchain ledger to include a corresponding increase in a currency account value at the first pool account by the first amount.
• the second communication sent to the second plurality of nodes hosting the second blockchain ledger will further instruct the second plurality of nodes to update the second blockchain ledger to include a corresponding decrease in a currency account value at the second pool account by the second amount.
• the current total values of the first pool account and the second pool account would not change. However, if the account value of a particular currency account drops too low, additional funds may need to be deposited into that currency account which would increase the current total value of the corresponding pool account. Similarly, the current total value of the pool account would decrease if funds are withdrawn from the corresponding currency account at the pool. In some embodiments, when a currency account at a pool account has too low or too high of an account value, the nodes hosting the corresponding blockchain ledger may provide a communication to a custodian of the pool account to fix that issue.
• the custodian of the first currency account may receive a communication that the currency account value at the first pool account is above a first threshold and withdraw funds from the first currency account at the first pool account to bring the currency account value below the first threshold.
• the custodian of the second pool account may receive a communication that the currency account value at the second pool account is below a second threshold and deposit funds into the second currency account at the second pool account to bring the currency account value above the second threshold.
• FIG. 1 illustrates a system diagram for a distributed ledger settlement system, in accordance with embodiments of the present disclosure.
• FIG. 2 illustrates a blockchain implementation for distributed ledgers used in the distributed ledger settlement system, in accordance with embodiments of the present disclosure.
• FIG. 3 illustrates an example implementation for the distributed ledger settlement system, in accordance with embodiments of the present disclosure.
• FIG. 4 illustrates an example implementation for the distributed ledger settlement system, in accordance with embodiments of the present disclosure.
• FIG. 5 illustrates an example diagram of blocks in a blockchain ledger for the distributed ledger settlement system, in accordance with embodiments of the present disclosure.
• FIG. 6 illustrates an example diagram of blocks in a blockchain ledger for the distributed ledger settlement system, in accordance with embodiments of the present disclosure.
• FIG. 7 illustrates an example diagram of how transactions may be verified in a distributed ledger settlement system, in accordance with embodiments of the present disclosure.
• FIG. 8 illustrates a step diagram for an example cross-pool transaction using the distributed ledger settlement system, in accordance with embodiments of the present disclosure.
• the interbank settlement of funds between the various financial institutions is commonly based on an centralized ledger for recording those transactions, and the ledger provides subtotals for thousands of financial institutions around the world. Funds are then commonly moved between the various financial institutions in the form of a fiat currency or another expungable type of currency. However, this process is slow and is only performed at the end of the day once all the transactions have been made.
• RTP real-time payment
• These new real-time payment schemes post/net transactions against funds that have been pre-funded by the various financial institutions.
• a financial institution has a positive balance available, transactions are debited or credited from that balance. If the balance is insufficient, then the financial institution deposits additional funds (e.g., with the central bank) to increase the balance.
• the primary benefit of a RTP system is that payees in a transaction can receive immediate access to funds sent by payors, as the financial institution implementing the RTP system can provide the payee with funds from the pre-funded settlement account.
• pre-funded RTP approaches also involve the actual movement of funds (e.g., in the form of a fiat currency), which further ties up the working capital of those financial institutions.
• the centralized ledger is replaced with one or more distributed ledgers, which can also be
• the distributed ledgers may be separate and distinct based on business needs, but at the same time the distributed ledgers may also interconnected with one another by being connected to a main ledger.
• the various ledgers may be arranged in a "chain of chains” that is usable for tracking and recording various transactions between different financial institutions.
• This "chain of chains” may be used to facilitate settlement between financial institutions associated with different ledgers (e.g., interbank settlement) and the physical movement of funds from a ledger to a fiat currency or other expungable type of currency (e.g., outside the blockchain).
• This arrangement and implementation of ledgers allows funds to be converted quickly and easily between ledger balances and fiat currency, not just domestically but also internationally - allowing multicurrency, cross-border
• the financial institutions can simply manage their own ledger balance.
• the ledgers can be implemented using blockchain technology which has built-in mechanisms to ensure that the data between the ledgers may automatically be synchronized, and the resulting
• framework may be able to address issues typically associated with the distributed ledgers, such as data privacy, connectivity, and the ability and willingness of financial institutions to manage a distributed ledger.
• each ledger may be associated with a different pool account, which are provided by pool entities.
• Each pool account may be used to aggregate the deposits of one or more users.
• Each ledger is used to track and record in realtime the total aggregate value of the associated pool account, the transactions between users with deposits in that pool account, the balance for each user in that pool account, and any deposits or withdrawals by the users of that pool account. Transactions between users of the same pool account can be performed with the pool entity acting as a clearinghouse and without requiring traditional settlement (e.g., the physical movement of funds from one of the ledgers to a fiat currency or other expungable type of currency).
• each ledger may also be
• main ledger which records the global fund flows among the various pool accounts and can be used to facilitate transactions between users of different pool accounts (or multicurrency, cross-border transactions, in practice).
• a "transaction” may comprise any exchange or interaction between two or more entities.
• the transaction can include the exchange of resources, goods, services, financial instruments, access (e.g., to a secure resource or area), and so forth.
• the transaction may include the exchange of an asset or service in return for payment between a buyer or seller.
• "Settlement" of a transaction may refer to the delivery and fulfillment of contractual obligations associated with that transaction.
• a "ledger” may be a tangible object (e.g., a principal book) or a digital object (e.g., a computer file, a database, a blockchain, and so forth) for recording transactions. As previously mentioned, such transactions can include the exchange of specific resources, goods, services, financial instruments, access (e.g., to a secure resource or area), and so forth.
• Some ledgers may record and total economic transactions, measured in terms of a monetary unit, between various accounts. The ledger may be a permanent summary of all transactions and their amounts, along with the beginning and/or ending monetary balance for each account involved in the transaction.
• a "blockchain” may be a distributed database that is used to maintain a continuously growing list of records, which can be in the form of blocks.
• each block contains a timestamp and a link to a previous block.
• a blockchain is typically managed by a peer-to-peer network collectively adhering to a protocol for validating new blocks. Once recorded, the data in any given block cannot be altered retroactively without the alteration of all subsequent blocks and the collusion of the network. This allows the blockchain to serve as a distributed ledger for recording transactions between parties in a verifiable and permanent way.
• a “node” may refer to any suitable data computation device or devices, which may commonly include a processor and memory for running applications, such as a blockchain client. In some embodiments, a node may be tasked with updating and maintaining a blockchain.
• a "processor” may refer to any suitable data computation device or devices.
• a processor may comprise one or more microprocessors working together to accomplish a desired function.
• the processor may include CPU comprises at least one high-speed data processor adequate to execute program components for executing user and/or system-generated requests.
• the CPU may be a microprocessor such as AMD's Athlon, Duron and/or Opteron; IBM and/or Motorola's PowerPC; IBM's and Sony's Cell processor; Intel's Celeron, Itanium, Pentium, Xeon, and/or XScale; and/or the like processor(s).
• a "memory” may be any suitable device or devices that can store electronic data.
• a suitable memory may comprise a non-transitory computer readable medium that stores instructions that can be executed by a processor to implement a desired method. Examples of memories may comprise one or more memory chips, disk drives, etc. Such memories may operate using any suitable electrical, optical, and/or magnetic mode of operation.
• An "application” may be computer code or other data stored on a computer readable medium (e.g. memory element or secure element) that may be executable by a processor to complete a task.
• a computer readable medium e.g. memory element or secure element
• a "ledger manager” may includeany suitable entity that operates a ledger for recording transactions between users associated with a pool account.
• a ledger manager may also be a pool entity (e.g., such as a bank responsible for providing a pool account) or a business entity (e.g., a financial institution such as a transaction processor).
• the ledger may be a distributed ledger (e.g., a blockchain ledger) and the term ledger manager may refer to any entity that operates one or more full nodes for managing the ledger and recording transactions between users associated with a pool account. In such embodiments, there may not be a single ledger manager and the ledger manager may actually consist of multiple entities.
• pool accounts may be country-specific, and in such embodiments, the ledger manager for each pool account may be referred to as a "country ledger manager".
• a "main ledger manager” may include any suitable entity that operates a main ledger for recording transactions between users associated with different pool accounts.
• the main ledger manager may be a business entity (e.g., a financial institution such as a transaction processor).
• the main ledger may be a distributed ledger (e.g., a blockchain ledger) and the term main ledger manager may refer to any entity that operates one or more full nodes for managing the main blockchain ledger, which interacts with the pool-specific blockchain ledgers in order to facilitate cross-pool transactions.
• a business entity e.g., a financial institution such as a transaction processor
• the main ledger may be a distributed ledger (e.g., a blockchain ledger) and the term main ledger manager may refer to any entity that operates one or more full nodes for managing the main blockchain ledger, which interacts with the pool-specific blockchain ledgers in order to facilitate cross-pool transactions.
• main ledger manager there may not be a single main ledger manager and the main ledger manager may actually consist of multiple entities. For example, there may be one or more entities that operate one or more nodes that collectively manage and host the main ledger based on an established framework.
• pool accounts may be country-specific, and in such embodiments, the main ledger manager may be referred to as a "global ledger manager" as it manages a global blockchain ledger.
• the main ledger manager may also be the ledger manager for one or more of the ledgers associated with the pool accounts.
• a "user” may refer to any entity that may participate as a party to a transaction and deposits funds with a pool entity (e.g., into a pool account).
• a pool entity e.g., into a pool account
• the users described in the examples herein primarily refer to a business entity, such as a bank, that has deposited funds with the pool entity.
• these users may even operate one or more nodes hosting the blockchain ledger associated with the corresponding pool account.
• These users may have customers (e.g., an individual that does banking with the user).
• the real-time payments distributed ledger settlement system can also facilitate transactions between the customers of two different users by recording the transfer of funds between those two users.
• a “pool entity” may be any business entity (e.g., a bank) that issues and maintains a pool account for its users (e.g., one or more entities).
• a bank e.g., a bank
• users e.g., one or more entities.
• a pool account may be associated with a particular country, and the users associated with the pool account may have funds in the pool account in the currency of that country.
• the pool entity may be also be a "settlement entity” that is responsible for handling settlement with the individual users in that pool account.
• a "central bank” may refer to a country's centralized bank or any other entity responsible for the settlement funding mechanism in a country. For example, the Fed is responsible for settlement funding in the United States.
• a "currency account” is an account in a pooled account specifically used to facilitate cross-pool transactions (e.g., transactions between users with accounts at different pools).
• a "custodian of a currency account” may be any business entity (e.g., a bank or transaction processor) that deposits and maintains funds into a currency account in a pool account.
• the same custodian can maintain currency accounts at many, or even all, of the pool accounts in order to facilitate ease of settlement.
• the custodian may also be the main ledger manager and/or the ledger manager of one or more pool accounts.
• FIG. 1 illustrates a system diagram for a distributed ledger settlement system, in accordance with embodiments of the present disclosure.
• ledger managers and/or pool entities there may be any number of ledger managers and/or pool entities. For the sake of simplicity, three ledger managers are shown with each manager in electronic communication with a single pool entity. In practice, a ledger manager may communicate with multiple pool entities, or they could be multiple ledger managers for each pool entity.
• one or more users 102 may deposit funds with a pool entity 104.
• one or more users 1 12 may deposit funds with a pool entity 1 14, and one or more users 122 may deposit funds with a pool entity 124.
• Each pool entity may provide a pool account that aggregates the funds deposited by its users. For example, all of the users 102 may deposit funds into one pool account of the pool entity 104.
• a pool entity may be a central bank (e.g., the Federal Reserve) and the users may be financial institutions (e.g., commercial banks) that deposit funds with the pool entity. In some embodiments, those funds may be stored by the pool entity (e.g., the central bank may physically store those funds).
• a central bank e.g., the Federal Reserve
• financial institutions e.g., commercial banks
• those funds may be stored by the pool entity (e.g., the central bank may physically store those funds).
• transactions between users with deposits in the same pool account may be managed and facilitated by a ledger manager.
• transactions between users 102 with deposits in the pool account provided by the pool entity 104 may be managed and facilitated by the ledger manager 106.
• the ledger manager 106 may maintain a ledger for recording the transactions between the users 102 and the amount of funds available to each of the users 102.
• the ledger manager 1 16 may do the same for users 1 12, while the ledger manager 126 may do the same for users 122.
• a ledger manager may be one or more financial institutions tasked with maintaining the ledger (e.g., distributed database).
• each ledger manager may be any entity or set of entities suitable for maintaining a ledger.
• the ledger may be a digital object (e.g., a computer file, distributed database, blockchain, and so forth).
• a ledger manager could be an entity or set of entities that includes one or more computer systems (nodes) to manage, handle, and update the ledger and record transactions between users of that ledger.
• the ledger manager 106 may include a set of nodes that records transactions between the users 102 as blocks in a blockchain.
• each ledger manager may be in communication with a main ledger manager 130 that is tasked with managing a main ledger.
• the main ledger manager 130 may be any entity or set of entities suitable for maintaining the main ledger.
• the main ledger manager could be an entity or set of entities that maintain one or more computer systems to store, handle, and update the main ledger.
• the main ledger manager 130 may be distinct from the other ledger managers, while in some embodiments, the roles of the main ledger manager 130 and each of the other ledger managers may be performed by a singular entity.
• the main ledger may also be in blockchain format (e.g., a distributed database), and the main ledger manager 130 may be one or more entities that provide a set of computer systems (e.g., nodes) for managing the main ledger.
• the main ledger may be associated with each of the ledgers managed by the ledger managers.
• the main ledger may include transaction information from the ledgers maintained by the ledger manager 106, the ledger manager 1 16, and the ledger manager 126. Discussion of the role of each ledger and the main ledger is provided in regards to FIG. 3.
• each ledger and the entities involved with the associated pool account may belong to a certain jurisdiction (e.g., a country or region), resulting in separate ledgers for each jurisdiction.
• a ledger specifically associated with the U.S. that records transactions in U.S. dollars between users that deposited into a U.S. based pool account.
• the main ledger can be used to facilitate cross-border and multi-currency transactions between users associated with different pool accounts and ledgers (e.g., a transaction between a user of the U.S. pool account and a user of a Canada pool account).
• An example of such an embodiment is provided in FIG. 3.
• Data access and security across the ledgers may be of concern, such that various entities are only permitted visibility to data in the ledgers that they are allowed access to. For instance, a user in a pool account may be permitted to use the framework of a ledger corresponding to that pool account in order check their own account balance within the pool account, but that same user may not have access to the account balances of other users in that pool account or the account balances of users in other pool accounts (e.g., other ledgers).
• Data access and security across the ledgers may be of concern, such that various entities are only permitted visibility to data in the ledgers that they are allowed access to.
• a user in a pool account may be permitted to use the framework of a ledger corresponding to that pool account in order check their own account balance within the pool account, but that same user should not be granted access to the account balances of other users in that pool account or the account balances of users in other pool accounts (e.g., other ledgers).
• the level of data visibility for different individuals associated with an entity can be different (e.g., higher ranking employees should have more visibility).
• each ledger may be a private permission based blockchain ledger that utilizes public key infrastructure (PKI) for encryption and role- based access control.
• PKI public key infrastructure
• Role-based access allows for different individuals associated with an entity that perform different roles to have different data visibility based on their role, such that they can perform their assigned role and actions and only those actions. These roles and levels of data access should be assignable through the framework of the ledger (e.g., profile management). An individual who has a participant profile management role within an entity should be able to add, change and delete individuals within their own organization and configure their data access.
• an individual in the finance department of an entity should be able to see the transactions and balances of that entity, but not transactions or balances from other entities.
• issued participants may be provided with public key certificates with which they could access permitted data from the ledger.
• CA certificate authority
• access to data contained in the ledgers and the main ledger may be defined by the various entities associated with the data or by the data owner through a framework dashboard.
• the framework e.g., "chaincode”
• software associated with the ledger may also be set or configured with various business or transaction rules that would be enforced and govern the transactions on the ledger.
• business rules would include the automatic execution of commands such as top-ups (as well as setting the threshold for top-ups) or validity checks, as well as the encryption taken place for
• FIG. 2 illustrates a blockchain implementation for distributed ledgers used in the distributed ledger settlement system, in accordance with embodiments of the present disclosure.
• ledgers there may be one or more ledgers, such as a ledger 202, a ledger 212, and a ledger 222.
• a ledger 202 Three ledgers are shown in the figure for simplicity, but there may be any number of ledgers.
• Each of these ledgers may be stored in blockchain format, which is a distributed database that is used to maintain a continuously growing list of records called blocks.
• the ledger 202 may have any number of blocks in the blockchain with Block N being the current block, Block N-1 being the block preceding Block N, Block N-2 being the block preceding Block N-1 , and so forth.
• each ledger may be managed by a set of nodes.
• the ledger 202 may be managed by any number of nodes in nodes 204, including Node 1 through Node N (collectively, nodes 204).
• the nodes 204 may be configured to maintain and update the blockchain of ledger 202, such as by adding additional blocks to the chain.
• ledger 202 may be managed by any number of nodes in nodes 214, while ledger 222 may be managed by any number of nodes in nodes 224.
• the blockchains may be public and information contained in the blocks may be easily viewed.
• a user who deposits funds into a pool account may be able to access the ledger for the pool account and view the account values or net positions for other users that have funds in the pool account.
• the blockchains may be private and blocks may be updated or viewed only by trusted nodes.
• Each block of a ledger may contain information recorded for one or more transactions.
• ledger 202 could be associated with a pool account (described further in regards to FIG. 3) that holds the deposits of multiple users.
• the blockchain of the ledger 202 could be updated with blocks containing transaction information for transactions between those users, such as transaction amounts, transaction parties/accounts, the values available to various accounts, and the total aggregate value of all the accounts (e.g., the pool value).
• the one or more ledgers may be associated with a main ledger 232.
• the main ledger 232 may also be stored in blockchain format and have any number of blocks in the blockchain, with Block N being the current block, Block N-1 being the block preceding Block N, Block N-2 being the block preceding Block N-1 , and so forth.
• the main ledger 232 may be managed by any number of nodes in nodes 234, including Node 1 through Node N (collectively, nodes 234).
• the main ledger 232 may contain some, or all, of the information recorded in the blockchains of the ledgers associated with it (e.g., ledger 202, 212, and 222).
• the main ledger 232 may serve multiple purposes, such as to facilitate transactions between users of different ledgers (e.g., coordinating a transaction that impacts both ledger 202 and ledger 212).
• the main ledger 232 may be synched to the various ledgers associated with it, such that information in the most recent block of each ledger is reflected in the main ledger 232. This can be implemented in numerous ways.
• nodes 204, 214, and 224 may update the main ledger 300 at the same time they respectively update the ledgers 212, 222, and 232.
• the nodes 204, 214, and 224 may coordinate with and provide the nodes 234 any transaction information recorded in the blockchains of the ledgers 212, 222, and 232 so that the nodes 234 can update the blockchain of the main ledger 232.
• the nodes 234 may periodically retrieve or analyze the most current blocks in the blockchains of the ledgers 212, 222, and 232 in order to obtain the transaction information needed to update the main ledger 232.
• the role of the main ledger 232 is described further in regards to FIG. 3.
• FIG. 3 illustrates an example implementation for the distributed ledger settlement system, in accordance with embodiments of the present disclosure.
• each of the ledgers is used to track transactions associated with one type of currency and the users in the country associated with that currency.
• a U.S. pool entity responsible for providing a U.S. pool account to U.S. users that settles with U.S. dollars.
• U.S. ledger manager for maintaining a U.S. ledger for recording the transactions associated with the users of this U.S. account, although the U.S. ledger manager and U.S. pool entity could be the same entity.
• each ledger could be associated with a different financial institution, such as one ledger for customers of Bank of America, another ledger for customers of Wells Fargo, and so forth.
• each ledger could be associated with a particular transaction scheme, such as one ledger used for SEPA transactions, and so forth.
• a pool account 310 that is maintained by a pool entity.
• the pool account 310 may be associated with a particular type of currency, such as the U.S. dollar (USD).
• USD U.S. dollar
• the pool account 310 may be associated with a ledger 312 for recording transactions, account values, and the pool value (e.g., the total value of the pool account 310).
• This ledger 312 may be maintained and updated by a ledger manager.
• various users may deposit funds with the pool entity that maintains the pool account 310.
• Each of those users may deposit an amount of US dollars with the pool entity (e.g., into the pool account 310).
• Bank A may deposit $3M USD into the pool account 310
• Bank B may deposit $4M USD into the pool account 310
• Bank C may deposit $1 M USD into the pool account 310
• Bank D may deposit $2.2M USD into the pool account 310.
• the pool account 310 will contain all of the deposits from the users and the total account value of the pool account 310 (e.g., the pool value) will be equivalent to the sum of all those deposits.
• the pool account 310 will have a total account value of $10.2M USD.
• the pool account 310 could be provided by the Federal Reserve (the pool entity), with various financial institutions (e.g., banks) that deposit funds with the Federal Reserve.
• the ledger 312 could be used to track transactions between all of these financial institutions that have deposited funds with the Federal Reserve.
• the ledger 312 may continually record individual account values associated with each user based on their deposits, any previous deposits, as well as any transactions that user may have made. Thus, any deposits made by the users may be added to that user's previous individual account value that was recorded in the ledger 312. If the users are depositing for the first time, such as in this case, then the ledger 312 would record $3M USD under Bank A's account value, $4M USD under Bank B's account value, $1 M USD under Bank C's account value, and $2.2M USD under Bank D's account value. Thus, although the funds deposited by the users may be aggregated in the pool account 310, the ledger 312 would still track each user's deposit individually as if those users had deposited funds into their own respective accounts provided by the pool entity.
• pool accounts there may be other pool accounts (besides the pool account 310) that are maintained by other pool entities.
• a pool account 320 that is maintained by a second pool entity.
• the pool account 320 may be associated with a different type of currency, such as the Canadian dollar (CAD).
• CAD Canadian dollar
• the pool account 320 may be associated with a ledger 322 for recording transactions, account values, and the pool value (e.g., the total aggregate value of the pool account 320).
• various users may deposit funds with the pool entity that maintains the pool account 320.
• Each of those users may deposit an amount of Canadian dollars with the pool entity (e.g., into the pool account 320).
• Bank A may deposit $1 M CAD into the pool account 320
• Bank C may deposit $2M CAD into the pool account 320
• Bank E may deposit $1 M CAD into the pool account 320
• Bank F may deposit $3M into the pool account 320.
• the pool account 320 will contain all of the deposits from the users and the total account value of the pool account 320 (e.g., the pool value) will be equivalent to the sum of all those deposits.
• the pool account 320 will have a total account value of $7M USD.
• the ledger 322 would similarly maintain a record of individual account values associated with each user based on their deposits, any previous deposits, as well as any transactions that user may have made. Thus, any deposits made by the users may be added to that user's previous individual account value that was recorded in the ledger 322. If the users are depositing for the first time, such as in this case, then the ledger 322 would record $1 M CAD under Bank A's account value, $2M CAD under Bank C's account value, $1 M CAD under Bank E's account value, and $3M CAD under Bank F's account value. Thus, although the funds deposited by the users may be aggregated in the pool account 320, the ledger 322 would still track each user's deposit individually as if those users had deposited funds into their own respective accounts provided by the pool entity.
• pool account 330 there could be another pool account 330 (and so forth) that is maintained by a third pool entity.
• the pool account 330 may be associated with a different type of currency, such as the Australian dollar (AUD).
• the pool account 330 may be associated with a ledger 332 for recording transactions, account values, and the pool value (e.g., the total aggregate value of the pool account 330).
• various users may deposit funds with the pool entity that maintains the pool account 330.
• Each of those users may deposit an amount of Australian dollars with the pool entity (e.g., into the pool account 320).
• Bank A may deposit $0.8M AUD into the pool account 330
• Bank E may deposit $0.5 AUD into the pool account 330
• Bank G may deposit $1 .2M AUD into the pool account 330
• Bank H may deposit $1 .4M AUD into the pool account 330.
• the pool account 330 will contain all of the deposits from the users and the total account value of the pool account 330 (e.g., the pool value) will be equivalent to the sum of all those deposits. In this case, the pool account 330 will have a total account value of $3.9M AUD.
• the ledger 332 would similarly maintain a record of individual account values associated with each user based on their deposits, any previous deposits, as well as any transactions that user may have made. Thus, any deposits made by the users may be added to that user's previous individual account value that was recorded in the ledger 322. If the users are depositing for the first time, such as in this case, then the ledger 332 would record $0.8M AUD under Bank A's account value, $0.5M AUD under Bank E's account value, $1 .2M AUD under Bank G's account value, and $1 .4M CAD under Bank H's account value.
• the ledger 332 would still track each user's deposit individually as if those users had deposited funds into their own respective accounts provided by the pool entity.
• the pool value for each pool account will typically not change as transactions are conducted between users associated with that pool account and will only change when those users deposit or withdraw funds from that pool account.
• Bank A and Bank C are both users that have deposited with the pool entity that maintains the pool account 310 for transactions in US dollars.
• the ledger 312 records the deposits of both Bank A and Bank C and also provides updated individual account values for both Bank A and Bank C (e.g., $3M USD for Bank A and $1 M USD for Bank C).
• Bank A and Bank C would not actually have individual accounts since their funds are pooled into the pool account 310, and the individual account values are actually
• the pool value of the pool account 310 recorded in the ledger 312 would also be increased by that amount (e.g., a $1 M USD deposit would result in the pool value increasing to $1 1 .2M).
• each user may be required to prefund and deposit with the pool account to place each user in a net positive position.
• the amount that each user may need to prefund may vary based on implementation.
• some users e.g., smaller financial institutions
• some users e.g., larger financial institutions
• the users or participants of the ledger 312 may be trusted and credit can be extended to them on faith.
• the transaction may be conducted and ledger 312 would simply reduce Bank A's account value by $4M USD to become -$1 M USD. Bank A would then be informed and would have to deposit sufficient funds at a later time to cover the balance.
• any user could also withdraw funds from the pool account that they deposited into if they have a positive individual account balance as recorded by the ledger associated with that pool account. For example, if Bank A deposited $3M USD into the pool account 310 and conducted transactions with other users that resulted in Bank A's individual account value of $2M USD, then Bank A could withdraw up to $2M USD from the pool account 310. If, for instance, Bank A withdrew $1 M USD from the pool account 310, then the pool entity that provides the pool account 310 would transfer $1 M USD to Bank A from the pool account 310. The ledger 312 would be updated to reduce Bank A's individual account value by $1 M USD and reduce the pool value of the pool account 310 by the same amount to $9.2M.
• the pool entity e.g., providing the pool account 310
• the pool entity would provide settlement or the delivery of the fiat/digital currency to Bank A.
• This process allows the blockchain of the ledger 312 to be used to manage and record the flow of funds between users for the later settlement or conversion of funds into fiat/digital currency outside of the blockchain.
• a user would be able deposit funds into the pool account as often as they would like by implementing the blockchain of the ledger into their own infrastructure.
• the user would also be able to withdraw funds from the pool account that they deposited into as often as they want, based on their own rules or procedures, so long as there is sufficient balance associated with that user to cover those withdrawals. For example, a user may dictate they only want $1 M USD in balance at all times within the pool account 310 and may structure withdrawals so that funds above that amount are periodically withdrawn. Or the user may dictate that additional funds are to be deposited into the pool account if the account balance falls below X, or withdrawn from the pool account when the account balance becomes greater than Y.
• each user may be able to connect the ledger to their funding mechanisms in order to establish their own rules and procedures, which may define when and how funds are converted out of the ledger and into fiat/digital currency outside of the blockchain.
• This also makes it easier for the user to move funds to and from the pool entities (e.g., central banks) and this movement of funds would not have to incur additional wire fees.
• the main ledger 300 may also be a main ledger 300 that is maintained by a main ledger manager.
• the main ledger 300 may be used to implement global or multicurrency transactions.
• the main ledger 300 may be used to record transactions, account values, and/or pool values across multiple ledgers (and in this instance, multiple currencies).
• the main ledger 300 may maintain records of the total account values of the pool account 310, the pool account 320, and the pool account 330.
• the main ledger 300 may even maintain records of individual account values associated with each user for those pool accounts (e.g., after deposits, Bank A has account values of $3M USD, $1 M CAD, and $0.8M AUD).
• the main ledger 300 may be updated to reflect changes in pool values and any individual account values as transactions, deposits, and withdrawals occur. This can be implemented in numerous ways. For example, in one embodiment, the nodes managing the ledgers 312, 322, and 332 may update the main ledger 300 at the same time they update the ledgers 312, 322, 332. In one embodiment, the nodes managing the ledgers 312, 322, and 332 may instead inform the nodes managing the main ledger 300 when the ledgers 312, 322, and 332 are updated.
• the main ledger 300 may be updated by pulling or retrieving information (e.g., about transactions) from the ledgers 312, 322, and 332 after those ledgers have been updated and using that information to update the main ledger 300 (e.g., by the nodes managing the main ledger 300).
• information e.g., about transactions
• the main ledger 300 would record the various transactions and the movement of funds, but the main ledger manager would not participate in that transfer of funds. Instead, the main ledger manager is facilitating the transfer of funds without actually taking physical possession of funds.
• the main ledger 300 may be used to allow users to utilize funds across individual accounts they may have with various pool entities, such as to enable multicurrency transactions. For example, in the figure shown, Bank A may wish to transact with Bank E using Canadian dollars. This transaction may involve a transfer of $2M CAD from Bank A to Bank E and would normally be handled by the ledger 322. However, it can be seen that Bank A only has $1 M CAD deposited with the pool account 320, which is insufficient for enabling the
• the main ledger manager e.g., the nodes of the main ledger 300 may determine the current exchange rate from US dollars to Canadian dollars that will enable the transaction. For the sake of simplicity, assume that the exchange rate is 1 : 1 . Thus, $1 M USD from Bank A's funds with the pool account 310 would be converted into $1 M CAD and added to Bank A's funds with the pool account 320. More specifically, the ledger 312 would be updated with Bank A's account value decreasing by $1 M USD and the pool value of the pool account 310 would also decrease by $1 M USD.
• the ledger 322 would be updated with Bank A's account value increasing by $1 M CAD and the pool value of the pool account 320 would also increase by $1 M CAD.
• the main ledger 300 would also be updated with these changes.
• the settlement of such a transaction could be implemented in various ways.
• the main ledger manager may maintain pools of various currencies to cover these kinds of transactions. For instance, the main ledger manager may maintain a pool of currency in Canadian dollars to cover this transaction and settlement position with the pool entity (e.g., the Canadian bank) associated with the pool account 320.
• the main ledger 300 may be used to perform cross-border,
• the main ledger 300 can be used to manage the movement of funds between individual ledgers (e.g., between
• blockchains like the movement of US currency to Canadian currency provided in the example.
• pool entities e.g., central banks
• the ledger managers e.g., the entities managing their distributed ledger
• blockchains of the ledgers This would be particularly useful for compliance requirements, such as for measures associated with Know Your Customer (KYC), Customer Identification Program (CIP), Office of Foreign Assets Control (OFAC) screening, and Anti-Money Laundering Laws (AML).
• KYC Know Your Customer
• CIP Customer Identification Program
• OFAC Office of Foreign Assets Control
• AML Anti-Money Laundering Laws
• each transaction would be recorded in the blockchain of a ledger (such as the main ledger 300), it would be simple to filter all the transactions associated with a particular user in various countries or currencies in order to analyze the money flows for money laundering detection.
• the main ledger 300 may be used to allow for transactions to occur between users that are not deposited with the same pool account. For example, in the figure shown, Bank B has only deposited with the pool account 310 while Bank F has only deposited with the pool account 320. Bank B may still be able to transact with Bank F using the main ledger 300. For instance, if Bank B transacts with Bank F to transfer $1 M CAD, the main ledger manager (e.g., the nodes of the main ledger 300) may determine the current exchange rate from US dollars to Canadian dollars that will enable the transaction. For the sake of simplicity, assume that the exchange rate is 1 : 1 .
• $1 M USD from Bank B's funds with the pool account 310 would be converted into $1 M CAD and added to Bank F's funds with the pool account 320.
• the ledger 312 would be updated with Bank B's account value decreasing by $1 M USD and the pool value of the pool account 310 would also decrease by $1 M USD.
• the ledger 322 would be updated with Bank F's account value increasing by $1 M CAD and the pool value of the pool account 320 would also increase by $1 M CAD.
• the main ledger 300 would also be updated with these changes.
• this hierarchy of ledgers involving ledgers linked to a main ledger 300 may allow for faster interbank settlement in both domestic transactions (e.g., between users deposited in the same pool account) and cross-border transactions (e.g., between users of different pools) with fiat currencies that have high fungibility (e.g., funds that are not just posted to a ledger within the distributed ledger network but can also be easily converted/deposited into an account at a central bank and used for other financial instruments that require immediate funds).
• the ledgers are blockchain ledgers
• access to the various types of data within each ledger can be hierarchical and managed by the data owner.
• the main ledger manager may be considered the data owner of all of the data recorded in the main ledger 300. If the main ledger 300 tracks the pool value of the various pool accounts (pool accounts 310, 320, 330) but does not track the account values of individual users at the pool accounts, then the main ledger manager may make the pool value for a particular pool account that is recorded by the main ledger 300 viewable to only certain entities.
• the main ledger manager may individually enable or disable access for the Central Bank in the United States, the pool entity for the pool account 310, and users of the pool account 310 (Banks A, B, C, and D) to see that the pool account 310 has a total pool value of $10.2 M USD.
• the main ledger manager could allow the Central Bank in the U.S. to see the pool value of the pool account 310 while restricting the Central Bank in Canada from viewing the pool value of the pool account 310.
• the main ledger 300 does not track the account values of individual users at the pool accounts, it would be up to the individual users to grant access to the main ledger manager for that information. For instance, Bank A could allow the main ledger manager to view Bank A's individual account balance of $3M in the pool account 310, while Bank B may restrict the main ledger manager to view Bank B's individual account balance of $4M in pool account 310. However, the individual account balance for Bank A and Bank B would still be factored into the total pool value of $10.2M for the pool account 310, which would be provided to the main ledger manager.
• the main ledger manager may utilize the pool values associated with the different pool accounts in order to fund and facilitate transactions (such as individual card transactions) in real-time.
• the ledgers may capture and record certain information associated with deposits, withdrawals, and each transaction during the settlement process, including an updated account balance for both the payor user and the payee user (e.g., the sending and receiving bank) with the transaction applied, the transaction amount, currency information associated with the transaction, any information about why the transaction was declined if it was declined during the settlement process, jurisdiction information (e.g., the U.S.), and a date and time stamp for the transaction.
• the ledgers may also capture and record changes in the pool value resulting from deposits or withdrawals affecting the pool account. Any, or all, of this information recorded in ledgers at the country-level can also be communicated to the main ledger manager.
• the main ledger 300 can be used to record some or even all of the information recorded in the ledgers at the country-level.
• the main ledger 300 may also capture and record information associated with changes in the pool values of all the pool accounts, such as deposits or withdrawals affecting the pool value of the various pool accounts, as well as certain information associated with cross-pool transactions. This may include an updated account balance for both the payor user and the payee user with the transaction applied (unless the main ledger is not permitted visibility for individual user account balances) or at least an identification of the payor user and the payee user, the pool accounts associated with the payor user and the payee user, the transaction amount, currency information associated with the transaction, any information about why the transaction was declined if it was declined during the settlement process, jurisdiction information for the payor user and the payee user, and a date and time stamp for the transaction.
• these data access settings may be easily configured via a data access and security framework that the main ledger manager may establish for all of the entities and their associated individuals to operate within. This data access and security framework may allow entities to perform various
• Some examples of administrative functions that can be performed using the data access and security framework include the ability to manage and support system level functions including software upgrades, connectivity, and so forth.
• administrative functions associated with security such as managing system security rules (e.g. passwords, login timeout, etc.), encryption keys, and digital security elements, (e.g. digital signing authorities, password resets, etc.).
• administrative functions associated with audit such as setting up and accessing system logs, reports (e.g., for performance, profile management, compliance, etc.), regulatory and legal compliance requirements, and source data.
• data classification such as assigning classifications for the transaction and profile data at both a system and an organization level. For data classifications, this may include public, confidential, restricted and restricted personal information both at the system level and at an individual organization level.
• profile management functions that can be performed using the data access and security framework include the ability to change or configure data access settings applicable to different individuals associated with the entity, such as to provide different levels of data access to different roles within a company.
• these profile management functions may be restricted to certain individuals associated with the entity they are applicable to (e.g., each pool entity can only access their own profiles, the main ledger manager can only access its profile, etc.), and some functions may require higher level of access and
• a pool entity e.g., a bank
• the main ledger manager may be able to establish roles within its organization at a regional, multi-regional, and global level. An individual with a role at a global level may be allowed access to more information than another individual with a role at a regional level.
• the entity itself may establish various roles within its organization and define the types of data that could be available to each role.
• the main ledger manager must establish new roles and define the types of data that could be available for each role.
• the other entities may be able to rename those roles to suit their need for data access within the entity.
• profile management functions associated with the role within an entity to manage other individuals within the entity, such as the ability to add, change and delete individuals within the system and assign roles to other individuals. Entities may designate what levels of data classifications the individual would have access to and if they have read, change, delete privileges for each function. Some functions may require higher level of access and commercially reasonable security procedures to add or change individuals.
• rules associated with transactions involving the entity may include transaction size limits, tolerance rates, and alerts (e.g. when a currency account balance goes above/below thresholds, when a velocity threshold is reached, when a large dollar transaction is performed, the confirmation of top- ups/drawdowns/funds transfers, when FX rate information update timing thresholds have been exceeded, and so forth).
• the rules may also include standing orders and scheduling of settlement financial transactions (e.g. top-ups, drawdowns, funds transfers, FX loads, etc.), as well as the linking of funding accounts (e.g., a currency account) and any rules associated with those funding accounts.
• Such rules associated with the funding accounts may include funding type (top-up, drawdown, etc.), what time of day to perform funding, the amount of funding, the associated product type (e.g., provide funding for credit card transactions, etc.), override capability, designation of currency type(s), and so forth.
• profile management functions associated with the role within the entity to verify the identification and authority of individuals involved in financial transactions (draw-down, top-ups, funds transfers) or trying to perform a special action (e.g. changing of funding account data, etc.). These profile management functions may provide individuals carrying out this role to perform commercially reasonable security procedures, such as the linkage of digital signatures, corporate resolutions, and double custody.
• profile management functions associated with the role within the entity for reporting, which may include the ability to define, access and distribute electronic and hardcopy reports. This includes the configuration of reporting endpoints (internal and external), ad-hoc reports, analytics, and
• Some examples of treasury management functions that can be performed using the data access and security framework include functions associated with reporting, which may include providing reports/data associated with user accounts in the pool (e.g. Bank A's $3M) and the pool account (e.g., pool account 310). There may also be aggregation of user accounts for a central bank, settlement agent, transaction processor, or on-behalf of financial service provider.
• treasury management functions associated with forecasting to allow users or custodians of currency accounts to track and forecast their accounts. This may include importing and exporting historical and intraday account balances, along with ability to 'memo post' expected balance/transaction data. Memo data would be similar to a scratchpad area and expire at a pre- designated time.
• treasury management functions associated with the movement of funds and performing the settlement of financial transactions (e.g. top-ups, drawdowns, funds transfers, FX loads, etc.) associated with those accounts. For instance, there may be functions associated with FX loads that allow for the capture of the FX rates used in the settlement of financial transactions and/or individual payment transactions.
• the main ledger manager may be able to restrict which entities are able view/add/change this data, and the data may be updated frequently at ascheduled time or ad-hoc (assigned at the time of one or more settlement funding transactions).
• the main ledger manager may be able to configure different rules and settings associated with the real-time payments settlement system for various groups of users. For instance, in an embodiment in which pool accounts are associated with different countries, the main ledger manager can configure, at a country level (e.g., for each pool account and its associated users), the settlement timing for individual transactions based upon a variety of parameters, such as payment type, participating users, day of the week of the transaction, and so forth.
• the main ledger manager could configure all Visa Debit transactions in the US to settle every 10 minutes while having all Visa Direct transactions in Canada to settle in real-time.
• the main ledger manager may be able to configure different rules and settings to be applied to cross-pool (e.g., cross-border) and multi-currency transactions.
• This transaction request can be sent to the ledger manager of ledger 312 and/or the pool entity of pool account 310 (e.g., to later involve the ledger manager of ledger 312). Or, in the case where Bank A has direct access to the ledger 312 and there is not a single ledger manager of ledger 312 (e.g., if the ledger 312 is implemented using distributed blockchain technology and Bank A operates a node of the ledger 312), then Bank A could even submit the transaction request to the ledger 312.
• the ledger manager of ledger 312 may verify and check the transaction against the rules and configurations of ledger 312 that have been established for at the global level, the country level, for the sending user, and for the receiving user. These rules and configurations can be set within the ledger 312 or the framework used to access the ledger 312, so the verification can be automated and efficient. For instance, the ledger manager may determine if Bank A has sufficient funds in the pool account 310 to cover the transaction. The ledger manager may also determine if the transaction is within transaction size limits that have been established at the global level, at the country level (e.g., for U.S. transactions), for Bank A, and for Bank C. In some embodiments, the ledger manager may check to see if the transaction has an acceptable KYC payment transaction risk score, as assigned by either Bank A or the ledger manager.
• the ledger manager may check to see if the transaction has an acceptable KYC payment transaction risk score, as assigned by either Bank A or the ledger manager.
• the ledger manager may inform Bank C of the funds transfer and Bank C would make the $500 available to Joe in his account with Bank C.
• the ledger manager may have the ledger 312 record the transaction as a $500 debit to Bank A's settlement account balance within pool account 310 and a $500 credit to Bank C's settlement account balance within pool account 310.
• the ledgers in these examples may be blockchain ledgers that are hosted by a plurality of nodes.
• a node of a first plurality of nodes e.g., associated with the ledger manager
• a first blockchain ledger e.g., ledger 312
• the first blockchain ledger records transactions between these first set of users, and would also be tasked with recording this first transaction which may be for a first amount (e.g., $1 M).
• the node may then verify that the transaction is capable of taking place by checking the first blockchain ledger.
• the node may update the first blockchain ledger with the first transaction to include a block with data relating to the first transaction.
• the first blockchain ledger may record, for each transaction between the first set of users, a payer, a payee, and a transaction amount.
• verifying the transaction includes checking the first blockchain ledger (e.g., ledger 312) for a history of transactions associated with the first user (e.g., Bank A) or checking an account value associated with the first user.
• the node of the first plurality of nodes may determine that the transaction reduces an account value associated with the first user (e.g., Bank A's balance) below a first threshold and send a communication to the first user to deposit additional funds into the pool account (e.g., pool account 310).
• the node of the first plurality of nodes may determine that the transaction increases an account value associated with the second user above a second threshold and send a communication to the second user (e.g., Bank C) to withdraw funds from the pool account (e.g., pool account 310).
• the second user e.g., Bank C
• the pool account e.g., pool account 310
• the node of the first plurality of nodes may receive a second transaction between the first user (e.g., Bank A) and a third user (e.g., Bank E) that did not deposit funds for settlement into the first pool account (e.g., pool account 310).
• the node may also verify that this second transaction is capable of taking place by checking the first blockchain ledger and then communicate to a second plurality of nodes hosting a second blockchain ledger (e.g., ledger 322), the second transaction.
• the main ledger manager may receive a transaction between a first user (e.g., Bank A) that deposited funds for settlement into a first pool account (e.g., pool account 310) to a second user (e.g., Bank E) that deposited funds for settlement into a second pool account (e.g., pool account 320), for a first amount.
• the main ledger manager may verify that the transaction is capable of taking place by checking an account value associated with the first user at the first pool account, and send to a first plurality of nodes hosting a first blockchain ledger (e.g., ledger 312) that records transactions between users that deposited funds for settlement into the first pool account (e.g., pool account 310), a first communication.
• a first user e.g., Bank A
• a second user e.g., Bank E
• the main ledger manager may verify that the transaction is capable of taking place by checking an account value associated with the first user at the first pool account, and send to a first plurality of nodes
• the first communication may instruct the first plurality of nodes to update the first blockchain ledger to include a decrease in the account value associated with the first user at the first pool account by the first amount.
• the main ledger manager may also send to a second plurality of nodes hosting a second blockchain ledger (e.g., ledger 322) that records transactions between users that deposited funds for settlement into the second pool account (e.g., pool account 320), a second communication.
• the second communication may instruct the second plurality of nodes to update the second blockchain ledger to include an increase in an account value associated with the second user at the second pool account.
• the main ledger manager may determine a currency associated with the second pool account (e.g., CAD) and convert the first amount into a second amount based on the determined currency, with the second
• the first communication may instruct the first plurality of nodes to update the first blockchain ledger (e.g., ledger 412) to include a corresponding increase in a currency account value at the first pool account by the first amount.
• the second communication may instruct the second plurality of nodes to update the second blockchain ledger (e.g., ledger 422) to include a corresponding decrease in a currency account value at the second pool account by the second amount.
• the custodian may receiving communication that the currency account value at the first pool account (e.g., pool account 410) is above a first threshold and withdraw funds from the currency account at the first pool account to bring the currency account value below the first threshold.
• the custodian may receive a communication that the currency account value at the second pool account (e.g., pool account 420) is below a second threshold and deposit funds into the currency account at the second pool account to bring the currency account value above the second threshold.
• FIG. 4 illustrates an example implementation for the distributed ledger settlement system, in accordance with embodiments of the present disclosure.
• this figure also depicts an example embodiments in which the division of the ledgers is based on various countries and currencies.
• FIG. 4 illustrates how cross-border, multi-currency transactions may also be settled through the use of pre-funded currency accounts within each pool account. Still, the discussion of features associated with the embodiments of FIG. 4 should be assumed to be applicable to the RTP settlement system depicted in FIG. 3 unless otherwise noted.
• pool accounts 410, 420, and 430 are associated with USD, CAD, and AUD, respectively.
• Pool account 410 is associated with ledger 412 for recording transactions, account values, and the pool value (e.g., the total value of the pool account 310).
• Pool account 420 is associated with ledger 422 and pool account 430 is associated with ledger 432.
• pool account 410 has deposits from Bank A, B, C, and D in USD that amount to $3 M, $3.4 M, $1 M, and $2.2, respectively.
• currency account within pool account 410 in which the custodian of the currency account has deposited $2.6 M.
• Pool account 420 has deposits from Bank A, C, E, and F in CAD that amount to $1 M , $2 M, $0.5 M, and $3 M, respectively.
• currency account within pool account 420 in which the custodian of the currency account has deposited $2.5 M.
• Pool account 430 has deposits from Bank A, E, G, and H in AUD that amount to $0.8 M , $0.5 M, $1 .2 M, and $1 .2 M, respectively. There is also a currency account within pool account 430, in which the custodian of the currency account has deposited $2.2 M. In some embodiments, the custodian for all three currency accounts may be the same entity.
• the corresponding ledger may continually record individual account values associated with each user (including the currency account) based on their deposits, any previous deposits, as well as any transactions that user may have made.
• the funds deposited by the users in a pool account are aggregated, but the corresponding ledger would still track each user's account balance as if those users had deposited funds into their own respective accounts provided by the pool entity.
• pool value for each pool account will typically not change as
• the pool value would only change when its users deposit or withdraw funds from that pool account, or when its users enter into transactions with users in another pool.
• Cross-pool transactions would involve the main ledger 400, which is maintained by a main ledger manager to implement global or multicurrency transactions.
• the main ledger 400 may be used to record transactions, account values, and/or pool values across multiple ledgers (and in this instance, multiple currencies).
• the main ledger 400 may maintain records of the total account values of the pool account 410, the pool account 420, and the pool account 430.
• main ledger 400 could also maintain records of individual account values associated with each user for those pool accounts (e.g., Bank A's account value at pool account 410), it is not absolutely necessary to facilitate transactions between users of different pool accounts because the main ledger 400 could always request confirmation from the ledger of pool account with the payor that the payor has enough funds in their account. Furthermore, for data access and security reasons, users may wish to hide their individual account balances from the main ledger 400 and the main ledger manager.
• Bank D in the U.S. may wish to send $2M USD from their balance in pool account 410 to Bank F in Canada, which has funds in pool account 420.
• Bank A would send instructions to the main ledger manager maintaining the main ledger 400.
• the main ledger manager may first check and verify the $2M USD transfer against any rules that have been configured with the ledgers of those pool accounts (e.g. , ledger 412 for the pool account 410 and the ledger 422 for the pool account 420).
• the main ledger manager may directly communicate (or even indirectly, via the main ledger 400) with those ledgers to check and verify the transaction.
• the main ledger manager may communicate with ledger 422 to determine if Bank D already has a CAD RTP settlement account in pool account 420, and if it has sufficient balance for the transaction. In the figure shown, Bank D does not have a CAD RTP settlement account in pool account 420. However, if Bank D did have an account with sufficient balance in pool account 420, then a cross-pool transaction may not even be necessary. The main ledger manager may go back to Bank D to determine which settlement account to use for the transaction or to verify that Bank D does indeed want to perform a cross-pool, cross-border transaction using their settlement account in pool account 410.
• the main ledger manager may communicate with ledger 412 to determine if Bank D has a sufficient balance in pool account 410 in order to perform the transfer. In this case, Bank D has $2.2 M in pool account 410, which is sufficient to cover the $2.0 M transfer.
• the main ledger manager may convert the
• CAD transaction amount into CAD, such as by using the current FX conversion rate for USD to CAD. For instance, if the USD/CAD FX rate is $0.78, the main ledger manager would determine that the $2 M USD transfer is an equivalent of $1.56 M CAD, which is how much that Bank F would receive.
• the main ledger manager may also determine if the transaction is within transaction size limits that have been established at the global level (e.g., by consulting main ledger 400), at the originating country level (e.g., by consulting ledger 410), at the receiving country level (e.g., by consulting ledger 420), by the payor user (e.g., by consulting Bank D's rules established with ledger 410), or by the receiving user (e.g., by consulting Bank F's rules established with ledger 420).
• the rules and transaction limits established at ledger 420 may be involve amounts in CAD, so the main ledger manager would perform the verifications using the $1.56 M CAD equivalent.
• the main ledger manager may check to see if the transaction has an acceptable KYC payment transaction risk score, as assigned by either Bank D or the main ledger manager. In some embodiments, the main ledger manager may also check to see if the transaction complies with legal and regulatory requirements for cross-border transactions. [0127] In some embodiments, in which settlement is performed using currency accounts, the main ledger manager may also check to see if the currency account at the pool account of the receiving user has enough funds to cover the transaction. In this case, the currency account at pool account 420 has $2.5 M CAD, which is enough to cover the transaction.
• the main ledger manager may settle the transaction using the currency accounts associated with the pool accounts 410 and 420.
• the system is performing real-time clearing and settlement, and when a transaction is authorized then that transaction is settled on a per-transaction basis.
• the main ledger manager can send a communication to the ledger manager of ledger 422 (or one of the nodes hosting the ledger) to have $1.56 M CAD transferred from the currency account balance in pool account 420 to Bank F's balance in pool account 420.
• Either the main ledger manager, or the ledger manager of ledger 422 can then inform Bank F that the transfer has completed and disbursed.
• the main ledger manager can also send a communication to the ledger manager of ledger 412 to have $2 M USD transferred from Bank D's settlement account balance in pool account 410 to the currency account in pool account 410.
• the resulting balances will include Bank D having $0.2 M USD in pool account 410, the currency account having $4.6 M USD in pool account 410, Bank F having $4.56 CAD in pool account 420, and the currency account having $0.94 M CAD in pool account 420.
• the pool values of pool account 410 and pool account 420 have not changed.
• the users and/or custodians of the currency accounts in each pool account may have established certain scripts, rules, or configurations to automate certain features or perform certain actions. These scripts and rules may be associated with top-up/drawdown.
• the custodians of the currency accounts in pool account 410 and pool account 420 may have established certain rules or configurations with ledgers 412 and 422, respectively. For example, there may be pre-established thresholds for top-up/drawdown associated with those currency accounts.
• the ledger manager of the ledger may send a communication to the custodian of that currency account to add additional funds (e.g., top-up) to the currency account.
• additional funds e.g., top-up
• the custodian of the currency account may have established a source of funding and the top-up can be performed automatically. This process would be similar for
• the ledger manager of the ledger may send a communication to the custodian of that currency account to withdraw funds (e.g., drawdown) from the currency account, or the drawdown can be performed automatically if there is an established account to withdraw funds to.
• the depositing or withdrawing of funds to a currency account will change the pool value of the pool account which will be recorded in the ledger of that pool account, and in some embodiments, will also be communicated to the main ledger manager to be recorded in the main ledger 400.
• the custodian of the currency account in pool account 420 may have established a rule with ledger 422 to generate an alert whenever the currency account balance drops below $1 M. Since the currency account in pool account 420 ends up with $0.94 M CAD, this alert can be generated and sent to the custodian (e.g., an individual in the Treasury Management department of the custodian receives an email). The custodian can then initiate a deposit of funds to the pool account 420 to bring their account balance above the threshold, such as by making a transfer from their account at the central bank (not shown) to the currency account in pool account 420. Once the transfer is complete, the ledger manager of ledger 422 can be informed to record the deposit and update the custodian's currency account balance in the pool.
• the custodian e.g., an individual in the Treasury Management department of the custodian receives an email.
• the custodian can then initiate a deposit of funds to the pool account 420 to bring their account balance above the threshold, such as by making
• some or all of the information with these account balance changes may be recorded in the main ledger 400.
• the main ledger 400 may capture an updated account balance for both the payor user and the payee user with the transaction applied (unless the main ledger is not permitted visibility for individual user account balances) or at least an identification of the payor user and the payee user.
• the payor is Bank D and the payee is Bank F.
• Additional information recorded may include the pool accounts associated with the payor user and the payee user, the transaction amount, currency information associated with the transaction (e.g., USD/CAD at an exchange rate of $0.78), any information about why the transaction was declined if it was declined during the settlement process, jurisdiction information for the payor user and the payee user, and a date and time stamp for the transaction. Also recorded may be information associated with the subsequent withdrawals and deposits by the custodians of the currency accounts at pool account 410 and pool account 420, such as identification of the currency account, the transaction type, and the change in pool values associated with pool account 410 and pool account 420.
• the ledgers 412 and 422 may also record some or all of this information (e.g., the ledger 412 may record that Bank D made a transfer to Bank F in pool account 420). However, in this case, there has not actually been a direct transfer between Bank D and Bank F. In some embodiments, the ledger 412 may only record that Bank D transferred an amount to the currency account in pool account 410 and any subsequent withdrawals to the currency account that change the pool value of the pool account 410, while the ledger 422 may only record that Bank F received an amount from the currency account in pool account 420 and any subsequent deposits to the currency account that change the pool value of the pool account 420. This would allow the ledgers, at the country-level, to make a record of the transaction without needing to have any knowledge of a payee user in another pool.
• the main ledger manager is able to oversee global settlement, and can establish, monitor, and maintain prefunded settlement requirements for users (e.g., banks) - without even needing to have knowledge of the account balances of those users.
• the ledger manager and/or pool entities of a ledger at a country-level can oversee domestic settlement, and can also establish, monitor, and maintain their own prefunded settlement requirements for users of that pool account.
• legal and compliance related business rules and validations since those rules can be set, configured, or written into the ledgers and/or the framework used to access those ledgers.
• Legal and regulatory compliance checking against rules and validations can even be automated, along with other back-office functions (such as liquidity management, etc.)
• this system can be used to free up funds and collateral for its users.
• a bank may make multiple transactions in which they are the payee and also multiple transactions in which they are the payors.
• the bank may be expected to pre-fund their account with at least enough to cover the total sum of all the expected transactions in which they are the payors prior to settlement.
• RTP settlement system described herein, a bank would need to deposit a smaller amount and would receive a communication if the account requires a top-up.
• the custodians of the currency accounts would have reduced liquidity requirements as they would also top-up when needed.
• Bank A may be expected to make a series of sequential ten $1 M transactions to Bank C, totaling $10 M. In a traditional pre-funded system, Bank A would need to prefund their account with at least $10 M to cover the total of these expected transactions, even if some of the transactions do not occur. With the RTP settlement system described herein, in which settlement occurs at the same time a transaction is cleared, Bank A would only need to keep $1 M in their account to perform the first transaction. Once the transaction occurs and the balance dips below a threshold, Bank A would be notified and would deposit additional funds into the pool (or this may be performed automatically based on configurations), such as another $1 M to perform the next transaction. In this specific example, Bank A would only need to keep $1 M in the account at any time. This system also provides settlement finality with each payment, eliminates systemic risk, and provides all participants with greater visibility into individual and overall (e.g., pool account) settlement positions.
• the system enables the digital ledger to be supported in a centralized or decentralized manner, depending on which approach would be easier to implement.
• Many of the embodiments discussed have involved a decentralized approach with a hierarchy of distributed ledgers.
• the roles performed by the main ledger manager, the ledger managers, and/or the custodians of the various currency accounts may be performed by a single entity, which may simplify the process and reduce the amount of communications taking place.
• the main ledger manager and the ledger managers are combined into a single entity, then all the ledgers can effectively be combined into a centralized ledger. This can make it easier to implement and establish the system all at once, since there is no longer a need to have many different ledger managers (e.g., for each country). This may also provide consistency in terms of interpreting transactions in the ledger.
• the decentralized approach does not require implementation all at once, and allows for implementation on a country-by-country basis.
• a country could establish their own pool and ledger to enable domestic real-time payments and provide their users the ability to remotely manage their settlement position.
• Another advantage of a decentralized ledger is that it works well when different rules, permissions, and approvals are expected. For instance, different countries may likely manage their own separate ledgers and pools (e.g., a central bank which can integrate settlements via direct or indirect access). These different ledgers and pools may have their own framework, rules, and controls. At the same time, there may be a need for a universal, global ledger that serves than more than just a database.
• the main blockchain ledger can be used to facilitate cross-border transactions between users of ledgers that were intended to capture only domestic transactions, while also providing a level of permission-based data visibility and control (e.g., who can see what data, who can use what data) that will be necessary.
• FIG. 5 illustrates an example diagram of blocks in a blockchain ledger for the distributed ledger settlement system, in accordance with embodiments of the present disclosure.
• FIG. 5 illustrates a blockchain 500 to demonstrate how the blocks in a blockchain ledger may look like at the country-level (e.g., for the ledgers 312, 322, and 332 in FIG. 3).
• Blockchain 500 is shown with three consecutive blocks in an exemplary blockchain, blocks 502, block 508, and block 514.
• the blockchain 500 may be a data structure that aggregates transactions for inclusion into the blockchain 500. Each block may include a header and a list of one or more transactions, and a block may have multiple transactions. Blocks 502, 508, and 514 are shown with only one transaction each for the purposes of clarity.
• block 502 may include header 504 and transactions 506.
• Block 508 may include header 510 and
• Block 514 may include header 516 and transactions 518.
• the headers 504, 510, 516 may include at least three sets of metadata: a previous block header hash, a timestamp, and a merkle root.
• the previous block header hash may connect each block to the previous block.
• "00000fh5689” may be a hash of header 504 of block 502.
• a cryptographic hashing algorithm e.g., SHA256
• the timestamp may be the creation time of the block.
• block 508 may have been created on April 1 , 2018 at 5:43:36 PM.
• the merkle root may be a hash of the root of the merkle tree of each block's transactions.
• a merkle tree may be a summary of all of the transactions in a block that is constructed by hashing pairs of nodes until there is only one hash. The last remaining hash is the merkle root.
• the transactions 506, 512, and 518 may incorporate a set of transactions, with certain information associated with each transaction.
• Transactions 506, 512, 518 may be data structures that encode a transaction from an origin or source (e.g., a payor) and a destination (e.g., a payee).
• an origin or source e.g., a payor
• a destination e.g., a payee
• FIG. 5 there may be no cumulative data maintained by the blockchain 500. Instead, the available data may be scattered amongst a plurality of transactions and a plurality of blocks. For example, the transactions associated with a single user may be recorded to separate blocks throughout the blockchain according to when it was recorded.
• transactions 506 may include data associated with a
• the data may include an identifier of the origin (e.g., Bank A) and an identifier of the destination (e.g., Bank B), but does not necessarily need to be in clear text as shown here.
• the identifiers may be an address or a unique series of characters that are associated with a particular user.
• the data may include a transaction type, such as a transfer, deposit, or withdraw.
• the data may further include a transaction amount and a transaction time, as the header 504 of the block 502 only indicates when the data for the transaction was recorded and not the actual transaction time.
• the data may also include a change in the pool value, but this can be omitted because the change in the pool value can be inferred from the transaction itself and the current pool value can be determined by reviewing the history of all the transactions recorded in the
• the data may also include transaction identifiers that can be used to search for this specific transaction in the blockchain and also a digital signature, which in some cases, may be used to verify the identity of the originator (e.g., Bank A) and authenticate the transaction.
• transactions 506 may contain additional data for transactions (which do not have to involve Bank A).
• Transactions 512 and 518 also contain similar kinds of data associated with other transactions.
• the blocks can be stored in the blocks. Some of this data could be encrypted and not available to be viewing without the proper permissions. For example, along with an identifier of the payor and payee, the data may include updated account balances for both the payor user and the payee user with the transaction applied. Also included can be currency information associated with the transaction, any
• the blockchain ledger at the country level may also
• the blockchain 500 is multiaccess and many entities may both have access to the data recorded therein. This may allow for decentralized and/or shared control of the blockchain. Furthermore, the blockchain model has trust and redundancy inherently built into the system. Each participating entity may verify digital signatures for multiple related or unrelated transactions, which allows for transparency associated with the transactions and ecosystem simplification by adding all transactions to a single blockchain. This decentralization also prevents malicious attacks as the blockchain 500 does not have a central point of failure, and data written to the blockchain 500 may be immutable once it is written, reducing the possibility of fraud and errors.
• the blockchain 500 can also be permission based, such that different data is visible to different entities (and individuals associated with those entities) based on
• FIG. 6 illustrates an example diagram of blocks in a blockchain ledger for the distributed ledger settlement system, in accordance with embodiments of the present disclosure.
• FIG. 6 illustrates a blockchain 600 to demonstrate how the blocks in a blockchain ledger may look like at the global level (e.g., for the main ledger 300 in FIG. 3).
• Blockchain 600 is shown with three consecutive blocks in an exemplary blockchain, blocks 602, block 608, and block 614.
• the blockchain 600 may be a data structure that aggregates transactions for inclusion into the blockchain 600. Each block may include a header and a list of one or more transactions, and a block may have multiple transactions.
• block 602 may include header 604 and transactions 606.
• Block 608 may include header 610 and transactions 612.
• Block 614 may include header 616 and transactions 618.
• the headers 604, 610, 616 may include at least three sets of metadata: a previous block header hash, a timestamp, and a merkle root.
• the previous block header hash may connect each block to the previous block.
• "00000rwr2342" may be a hash of header 604 of block 602.
• a cryptographic hashing algorithm e.g., SHA256
• the timestamp may be the creation time of the block.
• block 608 may have been created on April 1 , 2018 at 5:43:36 PM.
• the merkle root may be a hash of the root of the merkle tree of each block's transactions.
• a merkle tree may be a summary of all of the transactions in a block that is constructed by hashing pairs of nodes until there is only one hash. The last remaining hash is the merkle root.
• the transactions 606, 612, and 618 may incorporate a set of transactions, with certain information associated with each transaction.
• Transactions 606, 612, 618 may be data structures that encode a transaction from an origin or source (e.g., a payor) and a destination (e.g., a payee).
• an origin or source e.g., a payor
• a destination e.g., a payee
• FIG. 6 there may be no cumulative data maintained by the blockchain 600. Instead, the available data may be scattered amongst a plurality of transactions and a plurality of blocks. For example, the transactions associated with a single user may be recorded to separate blocks throughout the blockchain according to when it was recorded.
• transactions recorded in blockchain 600 may include most or all of the information recorded in all of the ledgers at the country-level, such as same-pool transactions, deposits, and withdrawals.
• Blockchain 600 may also record cross-pool transactions.
• transactions 606 is shown to include data associated with a same-pool transaction from Bank A to Bank B, which are both users of Pool A.
• the identifiers of the users and pools do not need to be in clear text as shown here, but may be an address or a unique series of characters that are associated with a particular user and/or pool.
• This data includes a transaction type (e.g., transfer, deposit, or withdraw), which in this case is a transfer.
• the data may further include a transaction amount, a transaction time, and changes in pool values.
• the data may also include currency and jurisdiction information, as well as the exchange rate applied to a transaction.
• the data may also include transaction identifiers that can be used to search for this specific transaction in the blockchain and also a digital signature, which in some cases, may be used to verify the identity of the originator (e.g., Bank A) and authenticate the transaction.
• Transactions 612 and 618 also contain similar kinds of data associated with other transactions. For instance, transactions 612 includes a deposit by Bank A which increases the pool value of Pool A by $1 M.
• Transactions 618 shows a cross-pool transaction by Bank A in Pool A to Bank F in Pool B, in which a $1 M amount in USD was debited from Bank A and the equivalent amount of $0.78 M CAD (based on an exchange rate of 0.78) was credited to Bank F.
• the blockchain 600 may optionally record same-pool transactions, optionally record withdrawals and deposits to pool accounts, and optionally record changes in pool value. All of this data can be recorded in the ledgers at the country-level and requested if needed. However, the blockchain 600 may continue to record cross-pool transactions, such as the transaction shown in transactions 618.
• FIG. 7 illustrates an example diagram of how transactions are verified in a distributed ledger settlement system, in accordance with embodiments of the present disclosure.
• the diagram illustrates how a transaction can be verified to ensure that the account value associated with a payor is sufficient to cover the transaction, based on the history of transactions associated with that user recorded in the blockchain.
• the individual blocks in the blockchain do not necessarily correspond to a specific user and are not even necessarily in chronological order (blocks are ordered by when they are recorded, but a particular transaction may be recorded in a block at a later time from when the transaction took place).
• the transaction may list a set of input transactions (e.g., previous transactions adding an equivalent amount of funds into the payor's account). This allows the blockchain to provide a history of all of the transactions and can be used to determine the flow of funds over time.
• transaction 702 with a transaction id #b21 involved a transfer of funds from Bank A to Bank B of $2 M.
• the transaction 702 lists two inputs, transaction id #445 (transaction 704) and transaction #id aa8 (transaction 706). Once a transaction is listed as an input, it is considered spent. Thus, any new transactions being recorded cannot list those two transactions as inputs.
• transaction 704 involved Bank A depositing $1 M into their account and transaction 706 involved Bank C transferring $1 M into Bank A's account. Thus, there was a flow of funds totaling $2 M into Bank A's account, which is enough to cover this
• FIG. 8 illustrates a step diagram for an example cross-pool transaction using the distributed ledger settlement system, in accordance with embodiments of the present disclosure.
• step 802 assume that user A of pool A is attempting to make a cross-pool transaction in order to transfer funds to user B of pool B.
• user A may submit the transaction to the ledger manager of blockchain A associated with pool A.
• the submitted transaction will identify user B, as well as a transaction amount.
• the ledger manager of blockchain A will forward this transaction to the main ledger manager for the main blockchain.
• the ledger manager of blockchain A may first determine that this is indeed a cross-pool transaction (e.g., by determining that user B is not in pool A) and also determine that user A has a sufficient balance in pool A to perform the transaction.
• the user A of pool A may directly submit the transaction request to the main ledger manager for the main blockchain.
• the main ledger manager may determine the corresponding amount to transfer to user B (e.g., for a multi-currency transaction) and verify the transaction against the rules established in the main blockchain. For example, if this is a cross-border transaction, the main ledger manager may first check to see if this transaction is permitted based on international rules, rules associated with the originating country, and rules associated with the receiving country. At step 808, the main ledger manager may further verify the transaction against the rules established with blockchain A. For example, a determination may be made is to whether user A has a sufficient balance in pool A for the transaction, or whether the transaction is within transaction limits applicable to either user A or pool A.
• the main ledger manager would have to decline the transaction and user A would have to be informed of their insufficient balance or that the transaction is above established limits.
• the main ledger manager may also further verify the transaction against the rules established with blockchain B, such as to determine whether the transaction is above established limits applicable to user B or pool B.
• the main ledger manager of the main blockchain may record the transaction in the main blockchain. Furthermore, at step 812, the main ledger manager may send a communication to the ledger manager of blockchain A to permit and record the transaction. The details of the transaction are recorded in blockchain A with user A's account balance being debited, and at step 814, user A may be informed by the ledger manager of blockchain A that their account balance has been debited. Similarly, at step 816, the main ledger manager may send a communication to the ledger manager of blockchain B to permit and record the transaction. This communication may also include a converted transaction amount based on an exchange rate between currency A associated with pool A and currency B associated with pool B (e.g., for a multi-currency transaction).
• the details of the transaction are recorded in blockchain B with user B's account balance being credited with the converted amount, and at step 818, user B may be informed by the ledger manager of blockchain B that their account balance has been credited.
• the transaction may be physically settled by having the pool entity of pool A provide the funds to the pool entity of pool B.
• a computer system may be used to implement any or all of the entities or components described above.
• the subsystems of the computer system may be interconnected via a system bus. Additional subsystems such as a printer, keyboard, fixed disk (or other memory comprising computer readable media), monitor, which is coupled to display adapter, and others may be used.
• Peripherals and input/output (I/O) devices which couple to an I/O controller (which can be a processor or other suitable controller), can be connected to the computer system by any number of means known in the art, such as a serial port.
• a serial port or external interface can be used to connect the computer apparatus to a wide area network such as the Internet, a mouse input device, or a scanner.
• system bus allows the central processor to communicate with each subsystem and to control the execution of instructions from system memory or the fixed disk, as well as the exchange of information between subsystems.
• the system memory and/or the fixed disk may embody a computer readable medium.
• the monitor may be a touch sensitive display screen.
• a computer system can include a plurality of the same components or subsystems, e.g., connected together by an external interface or by an internal interface.
• computer systems, subsystem, or apparatuses can communicate over a network.
• one computer can be considered a client and another computer a server, where each can be part of a same computer system.
• a client and a server can each include multiple systems, subsystems, or components.
• any of the embodiments of the present invention can be implemented in the form of control logic using hardware (e.g. an application specific integrated circuit or field programmable gate array) and/or using computer software with a generally programmable processor in a modular or integrated manner.
• a processor includes a single-core processor, multi-core processor on a same integrated chip, or multiple processing units on a single circuit board or networked. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will know and appreciate other ways and/or methods to implement embodiments of the present invention using hardware and a combination of hardware and software.
• Any of the software components or functions described in this application may be implemented as software code to be executed by a processor using any suitable computer language such as, for example, Java, C, C++, C#, Objective-C, Swift, or scripting language such as Perl or Python using, for example, conventional or object-oriented techniques.
• the software code may be stored as a series of instructions or commands on a computer readable medium for storage and/or transmission, suitable media include random access memory (RAM), a read only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a compact disk (CD) or DVD (digital versatile disk), flash memory, and the like.
• RAM random access memory
• ROM read only memory
• magnetic medium such as a hard-drive or a floppy disk
• an optical medium such as a compact disk (CD) or DVD (digital versatile disk), flash memory, and the like.
• the computer readable medium may be any combination of such storage or transmission devices.
• Such programs may also be encoded and transmitted using carrier signals adapted for transmission via wired, optical, and/or wireless networks conforming to a variety of protocols, including the Internet.
• a computer readable medium according to an embodiment of the present invention may be created using a data signal encoded with such programs.
• Computer readable media encoded with the program code may be packaged with a compatible device or provided separately from other devices (e.g., via Internet download). Any such computer readable medium may reside on or within a single computer product (e.g. a hard drive, a CD, or an entire computer system), and may be present on or within different computer products within a system or network.
• a computer system may include a monitor, printer, or other suitable display for providing any of the results mentioned herein to a user.

Landscapes

• Engineering & Computer Science (AREA)
• Business, Economics & Management (AREA)
• Computer Security & Cryptography (AREA)
• Accounting & Taxation (AREA)
• Theoretical Computer Science (AREA)
• Finance (AREA)
• Physics & Mathematics (AREA)
• General Physics & Mathematics (AREA)
• Signal Processing (AREA)
• Computer Networks & Wireless Communication (AREA)
• Strategic Management (AREA)
• General Business, Economics & Management (AREA)
• Economics (AREA)
• Development Economics (AREA)
• Databases & Information Systems (AREA)
• Power Engineering (AREA)
• Computing Systems (AREA)
• Data Mining & Analysis (AREA)
• General Engineering & Computer Science (AREA)
• Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Priority Applications (4)

Applications Claiming Priority (2)

Publications (1)

Family

ID=64566056

Family Applications (1)

Country Status (5)

Cited By (14)

Families Citing this family (26)

Citations (4)

Family Cites Families (11)

• 2018
  • 2018-06-06 SG SG11201909999R patent/SG11201909999RA/en unknown
  • 2018-06-06 CN CN201880037461.2A patent/CN110709878B/zh active Active
  • 2018-06-06 US US16/611,316 patent/US20200167773A1/en active Pending
  • 2018-06-06 EP EP18813501.6A patent/EP3635665B1/en active Active
  • 2018-06-06 WO PCT/US2018/036318 patent/WO2018226868A1/en unknown

Patent Citations (4)

Non-Patent Citations (2)

Also Published As

Similar Documents

Legal Events