30.

The system may include transferor/transferee accounts 10-13. While only two transferor/transferee accounts are shown in FIG. 1, the system 100 may include any number of such accounts. The transferor/transferee accounts 10-13 may be accounts from which assets are transferred and/or accounts that receive such assets. A transferor account may be an account in which an asset is transferred to a conventional account stored in the set of applications 40 and a transferee account may be an account to which an asset is transferred from a conventional account in the set of applications 40. The transferor/transferee accounts 10-13 may be conventional user financial accounts (e.g., accounts stored in a static database) that are stored on the servers of their respective financial institutions and that keep records of asset ownership by the respective account's owners. In one non-limiting example, the transferor/transferee account 10 may be a conventional securities account and the transferor/transferee account 13 may be a conventional cash account (e.g., an account for holding fiat currency balances such as a Demand Deposit Account offered by a commercial bank). The accounts may perform asset transfers through the FMI 30 or through another network or infrastructure.

In some cases, to perform any transfers, the transferor/transferee accounts 10 or 13 may transfer the securities or money to accounts that are stored on one or more financial institutions' set of financial applications 40 or 50. For instance, the financial institutions' sets of financial applications 40 and 50 may each include one or more applications for different financial assets that store conventional accounts 41-44. The conventional accounts 41 and 42 may be securities accounts and conventional accounts 43 and 44 may be cash accounts. While only four accounts are shown, the sets of financial applications 40 and 50 may include any number of accounts for any type of asset. The conventional accounts 41-44 can store assets received from the transferor/transferee accounts 10 and 13 and transfer assets to such accounts. A DLT application 60 may have established connections with the sets of financial applications 40, 50, and/or any number of other applications of other financial institutions.

In one example, the transferor/transferee account 10 may send an instruction 21 to the FMI 30 for an asset transfer to/from an application-linked conventional account 41 (e.g., an application linked to the DLT application 60) of the set of financial applications 40. As described herein, actions by transferor/transferee accounts 10-13 should be understood to mean actions by the owner or authorized operator of the respective account. The FMI 30 may then send one or more instructions 31 that correspond to the instruction 21 to the conventional account 41. The set of financial applications 40 may then transmit one or more instructions 32 to the FMI 30 confirming the status of the transfer to account 41; the FMI may in turn transmit a corresponding instruction 22 to transferor account 10. The instructions and messaging of the sets of instructions 21, 22, 31, and 32 may be transmitted using conventional communication channels such as SWIFT using standards like ISO15022 or ISO20022.

In some cases, a transferor account and/or a transferee account may be stored on the set of financial applications 40 (i.e., transferors and transferees hold accounts at the financial institution that has a set of financial applications that are coupled with the DLT application 60). In such cases, transactions may be performed without transmitting any messages through the FMI 30.

The sets of financial applications 40 and 50 may be applications that are hosted by servers or other computing devices of different financial institutions. For example, the set of financial applications 40 may store accounts for different types of assets (e.g., securities accounts 41 or 42, or cash or demand deposit accounts 43 or 44). The set of financial applications 40 may also include other applications 45 which may include accounting modules, sanctions screening, reconciliation report uploading, reference and pricing data for assets, etc. The DLT application 60 may integrate with the other applications 45 to avoid duplicating their functionality within the DLT application 60. In another embodiment, the DLT application 60 would build some or all these modules itself or rely on third party modules instead of integrating with the other application 45.

As briefly mentioned above, conventional securities account 41 and 42 may be linked to the DLT application 60. The accounts 41 and 42 may hold one or more than one kind of security. One or more of the conventional securities accounts 41 and 42 may serve as omnibus accounts (wherein the holdings in these accounts map to the holdings of multiple underlying user accounts; in which case a DLT network 90 may operate as a sub-ledger for balances held by client wallets, with the aggregate balances matching the assets held in the corresponding omnibus accounts from amongst the accounts 41 and 42). In other cases, one or more of the accounts 41 and 42 may belong to individual end clients (e.g. clients operating client device 70 or client device 80, described below), and map one-to-one to the account balances held on the DLT network 90 (e.g., the DLT application 60 may maintain DLT wallets 61-63 that maintain a record of the current balance for different client accounts (e.g., 41 and 42)). The DLT application 60 may be authorized to convey instructions to accounts 41 and 42, and to receive status messages and other notifications on these accounts. In some instances, the accounts 41 and 42 may have restrictions so that transfers to other conventional accounts can only be instructed via the DLT application 60. The cash accounts 43 and 44 may operate similarly to the accounts 41 and 42, but may store balances for cash instead of securities. In some embodiments, securities accounts may be omnibus accounts, as described herein, and cash accounts may be per client accounts.

The DLT application 60 may be an application that is configured to accept and process one or more of tokenization, detokenization, and token transfer instructions. As described herein, tokenization refers to creation of an asset on the distributed ledger. In the case of conventional securities or cash, this is on the back of an asset received in a conventional ledger. In the case of omnibus accounts represented on a conventional ledger, a credit into an omnibus account leads to a credit into one of the multiple wallets the balances of which together add up to the balance in the omnibus account. Detokenization refers to destroying an asset on the distributed ledger. In the case of cash and conventional securities, this is usually accompanied by debiting of an asset from a token in a conventional ledger (the sequence of the two debits could change depending on the process). These processes are described in detail below with respect to FIGS. 2 and 3. Token transfers refers to transferring tokens from one account to another account.

The DLT application 60 may, in addition, connect with the conventional accounts 41-44 and other conventional financial applications (e.g., other applications 45). The DLT application 60 may be stored on a server external to any financial institution network and operate as an intermediary application, a ledger (e.g., a distributed ledger), middleware, or a combination of middleware and a ledger between client devices (e.g., the client device 70 or the client device 80) and financial institution applications (e.g., the set of financial applications 40 or the set of financial applications 50). For instance, the DLT application 60 may have or be associated with its own routing address (e.g., a BIC code 64) that can be used to route messages in a conventional financial network. When performing transactions, client devices may include the BIC code 64 in a message header to indicate to route the messages for the transaction to the DLT application 60.

The DLT application 60 may include DLT wallets 61, 62, and 63. The DLT application 60 may include any number of wallets. The DLT wallets 61, 62, and 63 may maintain the balances of the assets that their respective owners have on the DLT network 90 and/or another distributed ledger that may be outside of the financial institution network. The DLT application 60 may update the DLT wallets 61, 62, and 63 periodically based on tokenization, detokenization, token transfers or any other authorized transactions that the clients perform through their respective accounts.

For assets for which the DLT network 90 operates as a sub-ledger, the DLT wallets 61, 62, and 63 may be the ‘golden source’ of client balances given the standard immutability of distributed ledger technology. The DLT wallets 61, 62, and 63 may be mapped (e.g., have a stored relationship in a relational database) to one of more account numbers for the different assets. In cases where a client-specific conventional account is used (in the set of financial applications 40 or the set of financial applications 50), the conventional account number may be mapped to the wallet (e.g., mapped to an identification of the wallet). For all assets where omnibus accounts are used (in the set of financial applications 40 or the set of financial applications 50), the same client account number could be used (but there may be different numbers for different omnibus accounts) to track sub-ledger balances across different conventional omnibus accounts. This account number, like any conventional account, along with the BIC code 64 for the DLT application 60 can be used to route transactions correctly. This (same) client account number could also be the wallet identification, or may have a one-to-one mapping with the wallet identification.

Advantageously, because of the client account number assigned to each wallet, the BIC code assigned to the DLT application 60, and the ability of the DLT application 60 to process incoming conventional messages sent via the Swift network and to generate outgoing messages, clients can configure new accounts on their internal systems using the BIC code 64 and a client account number mapping to their respective wallets (with such mapping being stored in the DLT application 60) just as they would for any other conventional account they hold at a conventional financial institution. For example, client devices may communicate with the DLT application 60 using the BIC code 64 and the client account number mapping to DLT wallets 61, 62, or 63. This would typically apply in the case of institutional clients which may maintain accounts at multiple financial institutions and may use the BIC code and account number to route their instructions to the appropriate destination. The DLT application 60 has further advantages as described above.

In some cases, the operators of the client devices 70 and 80 might be the same as the owners of the transferor/transferee accounts 10 or 13 (e.g. if “Client I” owns the conventional account 10, and moves assets from the conventional account 10 to the securities account 41 for credit to its wallet on the DLT application 60, then it also plays the role of transferor).

The sets of financial applications 40 and 50 may communicate with the DLT application 60 via sets of instructions 46 and 47 using conventional messaging protocols (e.g., ISO15022 messages sent over a SWIFT network or other standard interfaces (e.g., API's) made available by set of financial applications 40 to its clients). The sets of instructions 46, 47, may be asset transfer instruction messages, status messages, credit or debit confirmations, intraday or end of data balance updates, etc.

The sets of financial applications 40 and 50 may also communicate with the DLT application 60 via custom messaging methods via sets of instructions 48 and 49. The sets of instructions 48 and 49 may have been developed or configured to integrate the DLT application 60 with the set of financial applications 40. For example, the sets of instructions 48 and 49, may include messages to screen for sanctions, retrieve security data attributes, or to reconcile aggregate of balances on DLT wallets and on conventional accounts, etc. The level and functionality of the integration of custom messaging between the DLT application 60 and different financial applications may vary by financial institution (e.g., the financial institution running the set of financial applications 40 may have established a custom messaging protocol with the DLT application 60 but the financial institutions running the set of financial applications 50 may only rely on a conventional messaging protocol, and would thus not use custom messaging except for integration with a smaller set of internal applications). In another embodiment, a financial institution may send sets of instructions 46 or 47, referred to earlier, via custom messaging. As described herein, the sets of instructions 46, 47, 48, and 49 that are exchanged between the DLT application 60 and the set of financial applications 40 are exchanged only with the appropriate or applicable application (e.g., internal application or sub-application) or interface of the set of financial applications 40 and/or the DLT Application 60.

In initiating a transaction that is facilitated by the DLT application 60, a user may access one of two categories of user interfaces (e.g., a conventional user interface 71 or a user interface 72 for a cryptographic wallet) at a client device 70. Similarly, client device 80 could use a conventional user interface 81 or a user interface 82 for a cryptographic wallet. For example, a user may access a financial institution-provided user interface 71 that the client device 70 may present in response to executing a client application that was provisioned to the client device 70 or via a browser. The user interface 71 may be provided by the financial institution at which the client maintains its securities or cash accounts or sourced by the client otherwise (e.g., developed internally by the group entity (e.g., a business or organization) that owns or otherwise operates the client device or sourced from other providers) for viewing account balances or activity, initiating transaction instructions, receiving end-of-period or intra-period (e.g. intra-day reports), monitoring status of earlier requests, carrying out other account-related operations, etc. In some cases, there may be multiple financial-institution provided (or client-sourced) interfaces 71 for accessing different assets or for carrying out different operations related to the same asset. For instance, one interface may be configured to present cash balances, another interface may be configured to present securities balances, etc. Alternatively, one interface may be used to initiate transactions, and another may be used to retrieve and reconcile end of day balances. Such interfaces may allow a user at the client device 70 to configure standard routing details for messages to send to their respective financial institutions (e.g. using BIC code and account number for their cash or securities accounts), and then exchange messages with their financial institution using conventional messaging protocols (including but not limited to ISO15022, ISO20022 messages sent via Swift, or via API's). In one embodiment, the user interfaces route these messages to the DLT application 60 using the client account number and the BIC code of the DLT application 60, and validates received messages from the DLT application 60 using the same BIC code.

When using interfaces 71 or 81, the client devices 70 or 80 may communicate with the DLT application 60 via sets of instructions 73, 74, 83, and 84. The sets of instructions 74 and 84 are instructions sent by the client devices 70 and 80, respectively, and may be instructions to initiate standard asset transfers (i.e., asset transfers types available in conventional networks e.g., cash transfers initiated using MT202). The sets of instructions 73, 74, 83, and 84 may represent groups of instructions or messages that are sent via a conventional protocol between interfaces 71 or 81 and the DLT application 60. Such sets of instructions may include any number of exchanged instructions. The standard asset transfer requests may also be used to initiate detokenization (i.e., destroy a token and transfer the destroyed token's underlying asset to a conventional account that is unlinked from the DLT application (e.g., transferor/transferee accounts 10 or 13)). In operation, the DLT application 60 may be authorized by the different account owners to send and receive conventional sets of instructions to various financial institutions on the account owners' behalf. In cases in which a user does not wish to provide the DLT application 60 with authorization to send such sets of instructions and the DLT application 60 has settings that indicate it is not permitted to transmit sets of instructions for the user, the DLT application 60 can still be configured to receive the sets of instructions 73 and 83 on the user's behalf.

In some cases, the sets of instructions 73 and 83 may represent the sets of instructions received by clients as described above, and may include messages with status updates and EOD messages for various transactions. Advantageously, the sets of instructions 73 and 83 may even be related to transactions that are initiated via one of the application interfaces 72 or 82 (i.e. not just to transactions initiated via the sets of instructions 74 and 84). Accordingly, the DLT application 60 may allow clients the flexibility to specify preferences as to which sets of instructions they receive, and via which channels. A benefit of this feature is that while some advanced users may initiate non-standard or standard transfers (via DLT Application interface 72, using the sets of instructions 76), settlement teams can receive confirmations via conventional channels (e.g., via the sets of instructions 73).

For example, if an entity is an organization, it is not uncommon to have different employees that have different responsibilities in the transaction life cycle, including transaction booking (booking transactions/accepting transactions initiated by counterparty) and reconciliation (based on transaction confirmations and/or EOD or other balance or transaction statements). Thus, some employees responsible for transaction booking may continue using the conventional user interfaces 71 or 81 to initiate standard transactions without changing transaction protocols, some may adopt new interfaces (e.g., the application interfaces 72 or 82) to initiate standard or non-standard transactions (for the avoidance of doubt, use of application interfaces 72 and 82 could be referred to as using a digital wallet that is stored in application 60 or in the client devices 70 or 80), but the employees responsible for reconciliation could still choose to use existing protocols for their reconciliations (messages received in the sets of instructions 73 or 83). Even in the case of non-standard transactions (e.g. transfer out Security A and receive Security B at the same time), the user may receive standard messages on transaction status for each individual asset during the transaction lifecycle (e.g. a credit message for Security B, and a debit message for Security A).

The client devices 70 or 80 may communicate with the DLT application 60 from application interface(s) 72 or 82. The application interface(s) 72 and 82 may be one or more custom interface(s) provided by the DLT application 60 for clients to view wallet balances or activity, initiate transactions, receive end-of-period or intra-period (e.g. intra-day reports), monitor status of earlier requests, and carry out other account-related operations. The DLT application 60 may provide multiple such interfaces, including but not limited to Graphical User Interfaces (GUI) and API's (also, notifications from the DLT application 60 to client devices 70 and 80 could also be sent via pre-specified channels, e.g. email). The application interface(s) 72 and 82 may also transmit sets of instructions 76 and 86 to the DLT application 60 to initiate and cryptographically sign instructions for standard transfers (which would include outgoing-transfer instructions for detokenization and incoming-transfer instructions for tokenization in addition to outgoing and incoming transfer instructions for assets to other wallets) or non-standard asset transfers (defined further) as well as accept “allegements” as is described in detail below. Non-standard asset transfers are those not available via conventional networks, (e.g. transfer out Security A and receive Security B at the same time; or transfer out a specified asset if a defined condition is satisfied). As described herein, allegements may mean that instead of having to enter all details of a transaction which would be matched with details entered by the other counterparty/counterparties, the party is shown details entered by others (via the application interface 72). The party can then choose to accept, modify or reject the transaction.

In the same embodiment, the application user interfaces 72 and 82 may allow the client devices 70 and 80 to receive messages in the sets of instructions 75 and 85 from the DLT application 60. Examples of such messages include, but are not limited to, status messages for requests initiated via the sets of instructions 76 or 86 and EOD messages, as well as copies of some or all messages which could potentially be sent by the DLT application 60 in the sets of instructions 73 or 83 (e.g., if an EOD MT940 is sent in the sets of instructions 73, the same may be visible via the application interface 72 as well). As described herein, the sets of instructions 73, 74, 75, 76, 83, 84, 85, and 86 that are exchanged between the DLT application 60 and the interfaces 71, 72, 81, and 82 are exchanged only with the appropriate or applicable application (e.g., internal application or sub-application) or interface of the DLT Application 60.

Optionally, the application user interfaces 72 and 82 may be used to send outgoing-transfer instructions (to trigger tokenization) to the transferor/transferee accounts 10 or 13 or to instruct incoming-transfer instructions (in the case of detokenization) to the transferor/transferee accounts 10 or 13 if the client of the DLT application 60 is the same as the transferor or transferee, or is otherwise authorized to instruct on behalf of the transferor or transferee.

The DLT application 60 may communicate and update the DLT network 90 as users perform transactions between each other. The DLT network 90 may be a network of validating nodes (e.g., computing devices) and a distributed ledger that maintains a record of the state and balances of wallets (e.g., the wallets 61-63 that are stored by the DLT application 60). The DLT application 60 may communicate with the DLT network 90 via sets of instructions 91 and 92. For example, the DLT application 60 may update DLT network 90 by transmitting messages in the sets of instructions 91 to the DLT network 90 with updates on the state and balance of the wallets 61-63. The DLT network 90 may transmit the sets of instructions 92 to the DLT application 60 to provide the DLT application 60 with the necessary data to complete an operation, process or instruction, and/or to provide the DLT application 60 with the necessary data from the ledger for the DLT application 60 to present to a user (e.g., to present the current holdings in the wallets 61-63 to their respective owners).

In some cases, the DLT application 60 may maintain wallets to access other DLT networks outside of the DLT network 90. For example, the DLT application 60 may maintain wallets to access DLT network 93, which may be a DLT network outside the DLT application 60's trust network/zone. The DLT network 90 may connect to the DLT network 93 to interact with the ledgers for other applications (and the clients connecting to these applications) outside the trust zone. This is to make sure that the applications (e.g., the applications that communicate and/or manage each distributed ledger) and messages and tokens of each of the applications can flow amongst each other (e.g., among the connected application) and can interoperate.

For instance, the DLT network 90 may exchange sets of instructions 94, 95, with DLT network 93 or with nodes of the same DLT network 90 but outside of the DLT application 60's trust network. Accordingly, the sets of instructions 94, 95, and the underlying mechanisms act as an inter-DLT bridge that enable interoperability.

As described herein, the system 100 may include components and applications that conventional systems use to process transactions as well as non-conventional components that are described herein. For example, conventional systems may include transferor/transferee accounts 10-13, FMI 30, sets of instructions 31 and 32, and sets of financial applications 40 and 50. The components that enable the systems and methods described herein and are not present in conventional systems, however, include the DLT application 60, the wallets 61-64, the BIC code 64, the application interfaces 72 and 82 (including channels or protocol that facilitate transfer of the sets of instruction 75, 76, 85, and 86), and integration of the DLT application 60 with the other applications 45 (via the sets of instructions 47-49). Accounts 41-44 may be reconfigured to operate with DLT application 60, but may otherwise be standard accounts. For example, the accounts 41-44 may be set up to accept incoming instructions from the BIC for the DLT Application 60, send outgoing instructions to the BIC for the DLT application 60, restrict (e.g., disallow) outgoing payment instructions originating from any other applications in the set of financial applications 40, etc.

FIG. 2 illustrates a flowchart depicting operational steps for tokenizing a transaction, according to an embodiment. The method 200 describes how a DLT-enabled application (DLT application) can facilitate a transaction with a conventional account and keep a record of the transaction on a distributed ledger. The DLT application may be the DLT application 60, shown and described with reference to FIG. 1. The method 200 is described below with reference to components (e.g., the FMI 30, the set of financial applications 40, and the DLT application 60) of the system 100 as the system 100 is described with reference to FIG. 1 above. However, it should be noted that the method 200 may be performed by any number of components. Furthermore, other configurations of the method 200 may comprise additional or alternative steps, or may omit one or more steps altogether.

The DLT application may store a plurality of digital wallets connected to a distributed ledger and the second application may store a plurality of conventional accounts linked to the plurality of digital wallets. Additionally, the DLT application may store a mapping of the digital wallets connected to the distributed ledger to the plurality of conventional accounts.

At step 202, the FMI 30 may receive a transaction request from a first client device. The transaction request may be a request to deliver an asset (e.g., a cash or securities asset) from a source account at a financial institution to a destination account on a distributed ledger. The transaction request may include identifications of the source account, a recipient account (e.g., an account hosted by the set of financial applications 40), and the ultimate destination account. The transaction request would be sent using standard asset-specific messages communicated over conventional messages channels (e.g. sets of instructions 31 or 32). Examples of asset-specific messages would include MT542 for securities and MT202 for cash. Such message formats usually allow specification of the source and recipient accounts, and include additional fields which could be used to specify the ultimate beneficiary, i.e. the ultimate destination account. The FMI 30 may receive the transaction request from a server of the financial institution that hosts the transferring account. In some cases, the FMI 30 may receive the transaction from the server after the server carries out a series of validations and checks according to its own internal policies (e.g., balance checks and sanctions screening) and then routes the request to the FMI 30 using conventional messaging.

Optionally, at step 204, the DLT application 60 may receive a “receive instruction” or a “credit pre-advice” from a second client device using conventional messaging (e.g., the sets of instructions 74) or custom messaging (e.g., the sets of instructions 76) depending on the configuration of the established communication channel. The DLT application 60 may receive the instruction or the credit pre-advice based on the type of asset that is being transferred. The receive instruction may include identifiers of the source account and the destination account (which would correspond to the ultimate destination account in the previous step. This corresponds to an individual wallet) and indicate the asset being transferred from the source account to the destination account. In some cases, the receive instruction may also include a BIC code of the DLT application 60 that enables the second client device to communicate with the DLT application 60 using a SWIFT or another conventional communication protocol.

Optionally, at step 206, the DLT application 60 may carry out any necessary validation and then create and send a new “receive instruction” to the set of financial applications 40. The “receive instruction” that the DLT application 60 creates may be distinct from the original “receive instruction” received from the client; that instruction was sent by the authorized client to DLT application. The new receive instruction may be sent by the DLT application 60, which is authorized to send instructions to one or more accounts maintained in the set of financial applications 40. This new receive instruction may set the source account the same as in the original receive instruction, but would set the destination account as the account in the set of financial applications 40 which maps to the wallet for the asset in question, and may also specify the ultimate destination account, which would be the destination account in the original receive request. The DLT application 60 may send the receive instruction to the set of financial applications 40 using conventional messaging or custom message depending on the configuration of the established communication channel between the DLT application 60 and the set of financial applications 40 (e.g., via the sets of instructions 47 or 49).

Optionally, at step 208, the set of financial applications 40 may validate the “receive instruction” that it receives from the DLT application 60. The set of financial applications 40 may do so using internal policies with various rules indicating how to validate such receive instructions. Upon validation, the set of financial applications 40 may route the receive instruction to the FMI 30 using a conventional messaging protocol.

Optionally, at step 210, the FMI 30 may match the receive instruction with the transaction request from the first client device. For example, the FMI 30 may compare the attributes (e.g., the different account identifiers and/or the identification of the asset) of the two requests and determine whether the attributes match. If the FMI 30 determines the assets do not match, the FMI 30 may generate an error message and stop the transaction from occurring. Otherwise, if the FMI 30 determines the instructions match, at step 212, the FMI 30 may settle the transaction by crediting the asset to the recipient account and debiting the asset from the source account. At step 214, the FMI 30 may transmit a debit confirmation of the transaction to the first computing device (e.g., to the source account that the first computing device is accessing) to indicate the transaction was successful. The FMI may also transmit a message to the set of financial applications 40 indicating the credit to the recipient account. The FMI may transmit such messages using a conventional messaging protocol.

At step 216, the set of financial applications 40 may transmit a confirmation of the credit to the DLT application 60. The set of financial applications 40 may transmit the confirmation using conventional messaging (e.g., sets of instructions 46) or custom messaging (e.g., sets of instructions 48). The set of financial applications 40 may create and transmit a new credit confirmation in a message including an identifier of the destination account of the transaction as the ultimate beneficiary of the transaction. At step 218, the DLT application 60 may issue a token for the transaction (e.g., the DLT application 60 may credit the asset of the transaction into the destination account) by exchanging messages to and from the distributed ledger for which the DLT application 60 maintains digital wallets indicating the transaction and the credit into the destination account.

At step 220, the DLT application 60 may transmit a credit confirmation in addition to other messages (e.g., transaction status messages, intraday statement, end of day statements, etc.) to the destination account (e.g., to the second client device accessing the destination account). However, if the settlement fails (e.g., if the receive instructions did not match the transaction request), the DLT application 60 may transmit a message to the destination account to indicate the transaction could not be processed. Additionally, if the DLT application 60 receives a cancellation message for the destination account before the transaction has finished processing, the DLT application 60 may transmit a message to the set of financial applications 40 to cancel and stop the transaction from occurring.

In some cases, the recipient account in the set of financial applications 40 may not be an omnibus account. In such cases, the designation of the ultimate destination account may not be needed at any stage and the recipient account may be the ultimate beneficiary account of the transaction.

In some cases, if the user owns both the source account and the destination account, the user may request the DLT application to initiate the ‘deliver instruction’ which is usually received from a first client device at step 202. The user may only do so, in some cases, if the DLT application is authorized to do so (e.g., has the appropriate account permissions).

Further, in some cases, depending on the asset in question, a transfer over a conventional settlement network may not need matching instructions (for example, for transferring USD, it may suffice to just have a delivery instruction). In such cases, steps 204, 206, 208 and/or 210 may be skipped.

These are just illustrative flows for tokenization. The process for tokenization (and detokenization) may vary based on the underlying financial instrument being tokenized. The above process applies for securities and cash. The DLT application 60 may also be configured for other instruments (e.g. letter of credit). In such cases, the process would change as other asset classes may be get instantiated using different methods. For instance, digital native assets may never have a conventional format and a trade receivable token might get created when party A accepts a liability to pay party B in the future. As described herein, digital native assets may be crypto assets, represented on a DLT (with an assigned ownership), that do not have an equivalent asset representation in conventional financial infrastructure; these digital native assets may or may not represent a physical asset.

FIG. 3 illustrates a flowchart of a process for detokenization, according to an embodiment. The method 300 describes how a DLT enabled application can facilitate a transaction with a conventional account and keep a record of the transaction on a distributed ledger. The DLT application may be the DLT application 60, shown and described with reference to FIG. 1. The method 300 is described below with reference to components (e.g., the FMI 30, the set of financial applications 40, and the DLT application 60) of the system 100 as the system 100 is described with reference to FIG. 1 above. However, it should be noted that the method 300 may be performed by any number of components. Furthermore, other configurations of the method 300 may comprise additional or alternative steps, or may omit one or more steps altogether.

At step 302, the DLT application 60 may receive a deliver instruction from a first client device. The deliver instruction may be an instruction to transfer an asset from a source account hosted by the DLT application (e.g., a digital wallet) into a destination account stored in a conventional system. The deliver instruction may include identifiers of the source account and the destination account. For example, the deliver instruction may be to transfer an asset to a particular transferee account (e.g., transferor/transferee account 10 or 13) from a given wallet (e.g., one of wallets 61-63). In some cases, the deliver instruction may include a BIC code for the DLT application 60 to enable the deliver instruction to be routed to the DLT application 60 using SWIFT messaging (e.g., sets of instructions 84). At step 304, the DLT application 60 may validate the transaction request to verify that it is a valid request.

At step 306, the DLT application 60 may freeze the balance of the source account (e.g., the token). By doing so, the DLT application 60 may make the balance unavailable for any transfers. The DLT application 60 may then create a new delivery instruction. This new delivery instruction may indicate the destination account (which would be the same as the destination account in the original request received from the client), but the source account would now be indicated as the conventional account in the set of financial applications 40 to which the balance in the wallet is mapped for the particular asset in question. This new delivery instruction may include details of the ultimate source account (the wallet Id). The DLT application 60 may then route the transaction request to the set of financial applications 40, wherein the transaction request is routed to the set of financial applications 40. The DLT application 60 may transmit the transaction request to the set of financial applications 40 using conventional or custom messaging (e.g., via the sets of instructions 47 or 49).

Optionally, at step 308, the set of financial applications 40 may validate the request and route the request to the FMI 30. The set of financial applications 40 may validate the request using conventional request validation policies. The set of financial applications 40 may then route the request to the FMI 30. The set of financial applications 40 may do so using conventional messaging protocols (e.g., via the sets of instructions 32).

Optionally, at step 310, the FMI 30 may receive a receive instruction from a second client device. The FMI 30 may receive the receive instruction from the second client device through the financial institution that maintains the destination account that was identified in the transaction request from the first client device. The FMI 30 may receive the receive instruction after the financial institution validates the receive instruction and routes the receive instruction to the FMI 30 via a conventional message protocol). The receive instruction may include identifications of the destination account, the source account, and the ultimate source account. The receive instruction may include a reference to the asset being transferred to the destination account. The FMI 30 may receive the receive instruction via the instruction 21.

Optionally, at step 312, the FMI 30 may match the receive instruction with the transaction request from the first client device. The FMI may match the receive instruction with the transaction request in a similar manner to the manner described above (e.g., compare the attributes (e.g., the different account identifiers and/or the identification of the asset) of the two requests and determine whether the attributes match). If the FMI 30 determines the assets do not match, the FMI 30 may generate an error message and stop the transaction from occurring. Otherwise, if the FMI 30 determines the assets match, at step 314, the FMI 30 may settle the transaction by crediting the asset to the destination account and debiting the asset from the recipient account stored on the set of financial applications 40. At step 316, the FMI may transmit (via the sets of instructions 22) a credit confirmation to the destination account being accessed by the second computing device and transmit (via the sets of instructions 31) a confirmation message for the debit to the set of financial applications 40.

At step 318, the set of financial applications 40 may receive the debit confirmation (i.e., the debit from the conventional account in the set of financial applications 40 which maps to the wallet from which the asset is being transferred) from the FMI 30 and then create and transmit to the DLT application 60 a new confirmation of the debit from the wallet. The set of financial applications 40 may transmit the confirmation to the DLT application 60 using a conventional communication protocol or a custom messaging protocol (e.g., via the sets of instructions 46 or 48). At step 320, the DLT application 60 may receive the confirmation and burn the previously frozen token in the source account (e.g., debit the asset of the transaction from the source account). At step 322, the DLT application 60 may transmit a debit confirmation in addition to other transaction details (e.g., transaction status messages, intraday statement, end of day statements, etc.) to the first computing device (e.g., to the source account that the first computing device is accessing). The DLT application 60 may do so using conventional messaging protocols (e.g., the sets of instructions 84 and 86) or custom messaging protocols (e.g., via the sets of instructions 83 and 85).

In some cases, if the same entity owns both the source account (wallet on 60) and the destination account (e.g., the transferor/transferee account 10 or 13), the user may request the DLT application 60 to initiate the ‘receive instruction’, which is usually received from a second client device at step 310. The user may only do so, in some cases, if the DLT application 60 is authorized to do so (e.g., has the appropriate account permissions).

In some cases, the recipient account in the set of financial applications 40 is not an omnibus account. In such cases, the designation of the ultimate source account may not be needed at any stage.

FIG. 4 illustrates a flowchart of a process for token transfer, according to an embodiment. The method 400 describes how a DLT enabled application can facilitate a token transfer between two wallets of the distributed ledger to which the DLT enabled application is linked. The DLT application may be the DLT application 60, shown and described with reference to FIG. 1. The method 400 is described below with reference to components (e.g., DLT application 60) of the system 100 as the system 100 is described with reference to FIG. 1 above. However, it should be noted that the method 400