J
Juan Manuel Sobral
Guest
Imagine a corporate treasury holds $10 million in a tokenized money-market fund. Somewhere else, a lender is willing to accept $2 million of that position as collateral, except the lender operates through a different blockchain environment. On a whiteboard, the transaction is easy to draw: the token leaves Network A, crosses an interoperability layer and becomes available on Network B.
The financial version requires considerably more ink. The fund has an issuer, a custody arrangement and rules governing who can own it. The lender needs to understand what the token represents, how it can be redeemed and whether the collateral is actually under its control. Somewhere along the route, money also has to settle.
The token, in other words, travels with an entourage. This is becoming one of the harder problems in blockchain interoperability as financial institutions begin connecting tokenized systems rather than simply experimenting with them. In July, Swift announced that 17 banks across six continents were preparing to pilot live transactions using tokenized deposits on its blockchain-based ledger. Once financial value crosses a network boundary, moving the balance is only part of the job.
For developers, interoperability begins with communication: can a contract on one network send a message to another, and can the receiving system trust what it sees? Institutional assets make the picture broader because several kinds of information have to remain coherent as the transaction moves.
There is the technical layer, where systems exchange messages and state. The asset layer concerns whether a token continues to represent the expected economic and legal claim, while identity and policy determine who can transact and under what conditions. Settlement then establishes when the exchange of value has actually become final.
These layers bleed into one another. A system may correctly report that 2,000 tokens moved while leaving the receiving institution uncertain about who can redeem them or whether the transfer satisfied the asset's rules. The BIS describes tokenization as the recording of claims on real or financial assets on programmable platforms, where messaging, reconciliation and asset transfer can be brought into the same operation. Once those functions begin sharing infrastructure, interoperability acquires a much larger job description.
A money-market-fund token is an unusual object when viewed only as software. Its contract can record balances and enforce transfer logic, while the economic value behind those balances depends on an issuer, underlying securities and the legal arrangements governing ownership.
Suppose our company transfers the fund position through a burn-and-mint mechanism. Tokens disappear from the source network and an equivalent amount is created at the destination, keeping supply consistent. The code has performed its task, but the lender still needs to know what the newly minted token entitles its holder to do.
One useful way of describing this problem is claim portability. For a financial token to travel meaningfully, the institutions involved need to continue recognizing the claim it represents under the conditions relevant to that transaction. Redemption rights might matter in one case, while investor eligibility or an authoritative ownership register might dominate another.
The distinction becomes sharper as markets move toward digitally native assets. In a 2026 speech at the Hong Kong Digital Finance Summit, HKMA Deputy Chief Executive Howard Lee described today's common “digital twin” model, where a token represents an asset whose primary ownership record remains off-chain. He contrasted it with digitally native issuance, where the token itself becomes the primary ownership record. The difference sounds technical until an asset starts moving between systems; then the question of which record ultimately counts becomes fundamental.
Now imagine Alice is the person at our fictional company authorized to manage the fund position. She passed KYC months ago and belongs to an investor category permitted to hold the asset, but her wallet address tells the destination system very little about either fact.
The receiving environment may need to establish that Alice still represents the company and that the company remains eligible to pledge the asset. It may also need to apply jurisdictional restrictions or issuer-defined transaction limits. These facts have a shelf life: permissions change, counterparties change status and compliance information has to remain current.
This pushes compliance closer to transaction execution. Chainlink's September release of CCIP 2.0, for example, introduced optional Cross-Chain Verifiers and built-in integration with its Automated Compliance Engine. Chainlink describes uses that include eligibility checks, transaction limits and issuer-defined policy controls.
Financial rules are becoming increasingly machine-readable. An interoperability layer that carries policy context along with asset data can evaluate whether the same transfer remains valid as it passes into a different environment, turning what used to be a separate compliance process into part of the transaction's executable logic.
Give our tokenized fund a wider distribution and another complication appears. Suppose $500 million is held on Network A, $180 million on Network B, and $90 million on Network C, with smaller positions scattered elsewhere. Transfers among the networks may work perfectly while a trader on the smallest venue still struggles to move $30 million without affecting the market.
Connectivity and liquidity therefore describe different properties. Interoperability can open a path toward another market, but it does not automatically combine every connected venue into a single pool of buyers and sellers. Easier multichain issuance can even spread an asset across additional markets, each with its own depth and settlement conditions.
This concern has already reached central-bank discussions. In August, BIS General Manager Pablo Hernández de Cos described interoperability as necessary to avoid “walled gardens” and trapped liquidity, particularly as tokenized deposits develop across platforms.
That changes the long-term ambition for routing. The useful question gradually shifts from whether a token can reach another network to where it can actually be put to work once it gets there. Available liquidity, collateral conditions and transaction cost may all influence the route, giving interoperability an economic dimension alongside its technical one.
Our $2 million collateral transfer is now almost ready, and the sender expects the button to behave like any other instant digital service. Underneath that button, however, the infrastructure has to decide how certain Network A should be before Network B acts on what happened there.
Different blockchains reach transaction certainty in different ways. Some provide deterministic finality, while others accumulate confidence as more blocks are added. An interoperability protocol can wait for the strongest available assurance, although doing so may add latency in applications where speed matters.
CCIP 2.0 makes this trade-off explicit through an opt-in faster-than-finality mode. The default still waits for full source-chain finality, while applications can choose a lower confirmation threshold according to their risk tolerance. Chainlink's documentation notes that doing so introduces exposure to chain reorganizations, which can alter or remove a source transaction after the destination has already acted on it.
What appears in the interface as a question of speed is therefore partly a question of risk allocation. If a transaction appears to complete before every underlying uncertainty has disappeared, some part of the system has accepted the possibility that later events may require correction. Blockchain infrastructure is useful here because it makes that otherwise invisible bargain unusually easy to inspect.
Following the asset only gets our imaginary transaction halfway home. The lender also needs a means of payment, and a dollar can now enter blockchain infrastructure in several forms, including a conventional bank deposit, a tokenized deposit or a stablecoin. Central-bank money may sit underneath the eventual settlement as well.
Those instruments can share a unit of account while representing different claims. Once transactions begin crossing systems, interoperability may therefore involve movement between forms of money as much as movement between blockchains.
The experiments around tokenized deposits already point in this direction. The Clearing House announced its On-Chain Money Initiative in June and selected Quant in September to build its interoperability and orchestration layer. The planned network is intended to let financial institutions clear and settle tokenized deposits while connecting with established U.S. payment infrastructure such as RTP and CHIPS, with availability to participating institutions expected in the first half of 2027.
The BIS's Project Agorá approaches the problem at the wholesale and cross-border level. Its prototype combines tokenized commercial-bank deposits with tokenized central-bank reserves and has demonstrated atomic multi-currency settlement across jurisdictions. More than 40 private-sector financial institutions have participated in the project, and real-value testing conducted in July 2026 involved 28 financial institutions and central banks.
A future payment could therefore pass through several monetary representations while remaining, from the customer's perspective, a single transaction. Making that experience uneventful will require the underlying systems to coordinate claims and settlement conditions across boundaries the user may never see.
Return to our $2 million position and the simple arrow we drew at the beginning. By now, the infrastructure surrounding that arrow has had to make sense of ownership, policy and liquidity before dealing with finality and payment.
The object in the middle begins to resemble a financial router. Swift uses similar language for its blockchain ledger, which acts as an orchestration layer for bank-issued tokenized deposits held on participating banks' own ledgers. Funds can move through the shared layer before final settlement takes place through existing systems.
That architecture is revealing—it allows different systems to keep doing different jobs. A bank does not have to surrender its ledger, and an existing payment rail does not have to disappear for tokenized infrastructure to become useful. Public chains, permissioned platforms and conventional financial systems can instead meet through layers designed to coordinate them.
A more mature router could eventually weigh where sufficient liquidity is available and whether the recipient satisfies the asset's rules. It might also choose an acceptable settlement instrument and determine how much finality the transaction requires. From the outside, the instruction remains almost comically simple: move $2 million from here to there.
The hard part is making sure that everything attached to those $2 million arrives in recognizable form. As interoperability develops, the token itself may turn out to have been the lightest piece of luggage.
The financial version requires considerably more ink. The fund has an issuer, a custody arrangement and rules governing who can own it. The lender needs to understand what the token represents, how it can be redeemed and whether the collateral is actually under its control. Somewhere along the route, money also has to settle.
The token, in other words, travels with an entourage. This is becoming one of the harder problems in blockchain interoperability as financial institutions begin connecting tokenized systems rather than simply experimenting with them. In July, Swift announced that 17 banks across six continents were preparing to pilot live transactions using tokenized deposits on its blockchain-based ledger. Once financial value crosses a network boundary, moving the balance is only part of the job.
Layers
For developers, interoperability begins with communication: can a contract on one network send a message to another, and can the receiving system trust what it sees? Institutional assets make the picture broader because several kinds of information have to remain coherent as the transaction moves.
There is the technical layer, where systems exchange messages and state. The asset layer concerns whether a token continues to represent the expected economic and legal claim, while identity and policy determine who can transact and under what conditions. Settlement then establishes when the exchange of value has actually become final.
These layers bleed into one another. A system may correctly report that 2,000 tokens moved while leaving the receiving institution uncertain about who can redeem them or whether the transfer satisfied the asset's rules. The BIS describes tokenization as the recording of claims on real or financial assets on programmable platforms, where messaging, reconciliation and asset transfer can be brought into the same operation. Once those functions begin sharing infrastructure, interoperability acquires a much larger job description.
The Claim
A money-market-fund token is an unusual object when viewed only as software. Its contract can record balances and enforce transfer logic, while the economic value behind those balances depends on an issuer, underlying securities and the legal arrangements governing ownership.
Suppose our company transfers the fund position through a burn-and-mint mechanism. Tokens disappear from the source network and an equivalent amount is created at the destination, keeping supply consistent. The code has performed its task, but the lender still needs to know what the newly minted token entitles its holder to do.
One useful way of describing this problem is claim portability. For a financial token to travel meaningfully, the institutions involved need to continue recognizing the claim it represents under the conditions relevant to that transaction. Redemption rights might matter in one case, while investor eligibility or an authoritative ownership register might dominate another.
The distinction becomes sharper as markets move toward digitally native assets. In a 2026 speech at the Hong Kong Digital Finance Summit, HKMA Deputy Chief Executive Howard Lee described today's common “digital twin” model, where a token represents an asset whose primary ownership record remains off-chain. He contrasted it with digitally native issuance, where the token itself becomes the primary ownership record. The difference sounds technical until an asset starts moving between systems; then the question of which record ultimately counts becomes fundamental.
Identity
Now imagine Alice is the person at our fictional company authorized to manage the fund position. She passed KYC months ago and belongs to an investor category permitted to hold the asset, but her wallet address tells the destination system very little about either fact.
The receiving environment may need to establish that Alice still represents the company and that the company remains eligible to pledge the asset. It may also need to apply jurisdictional restrictions or issuer-defined transaction limits. These facts have a shelf life: permissions change, counterparties change status and compliance information has to remain current.
This pushes compliance closer to transaction execution. Chainlink's September release of CCIP 2.0, for example, introduced optional Cross-Chain Verifiers and built-in integration with its Automated Compliance Engine. Chainlink describes uses that include eligibility checks, transaction limits and issuer-defined policy controls.
Financial rules are becoming increasingly machine-readable. An interoperability layer that carries policy context along with asset data can evaluate whether the same transfer remains valid as it passes into a different environment, turning what used to be a separate compliance process into part of the transaction's executable logic.
Liquidity
Give our tokenized fund a wider distribution and another complication appears. Suppose $500 million is held on Network A, $180 million on Network B, and $90 million on Network C, with smaller positions scattered elsewhere. Transfers among the networks may work perfectly while a trader on the smallest venue still struggles to move $30 million without affecting the market.
Connectivity and liquidity therefore describe different properties. Interoperability can open a path toward another market, but it does not automatically combine every connected venue into a single pool of buyers and sellers. Easier multichain issuance can even spread an asset across additional markets, each with its own depth and settlement conditions.
This concern has already reached central-bank discussions. In August, BIS General Manager Pablo Hernández de Cos described interoperability as necessary to avoid “walled gardens” and trapped liquidity, particularly as tokenized deposits develop across platforms.
That changes the long-term ambition for routing. The useful question gradually shifts from whether a token can reach another network to where it can actually be put to work once it gets there. Available liquidity, collateral conditions and transaction cost may all influence the route, giving interoperability an economic dimension alongside its technical one.
Finality
Our $2 million collateral transfer is now almost ready, and the sender expects the button to behave like any other instant digital service. Underneath that button, however, the infrastructure has to decide how certain Network A should be before Network B acts on what happened there.
Different blockchains reach transaction certainty in different ways. Some provide deterministic finality, while others accumulate confidence as more blocks are added. An interoperability protocol can wait for the strongest available assurance, although doing so may add latency in applications where speed matters.
CCIP 2.0 makes this trade-off explicit through an opt-in faster-than-finality mode. The default still waits for full source-chain finality, while applications can choose a lower confirmation threshold according to their risk tolerance. Chainlink's documentation notes that doing so introduces exposure to chain reorganizations, which can alter or remove a source transaction after the destination has already acted on it.
What appears in the interface as a question of speed is therefore partly a question of risk allocation. If a transaction appears to complete before every underlying uncertainty has disappeared, some part of the system has accepted the possibility that later events may require correction. Blockchain infrastructure is useful here because it makes that otherwise invisible bargain unusually easy to inspect.
Money
Following the asset only gets our imaginary transaction halfway home. The lender also needs a means of payment, and a dollar can now enter blockchain infrastructure in several forms, including a conventional bank deposit, a tokenized deposit or a stablecoin. Central-bank money may sit underneath the eventual settlement as well.
Those instruments can share a unit of account while representing different claims. Once transactions begin crossing systems, interoperability may therefore involve movement between forms of money as much as movement between blockchains.
The experiments around tokenized deposits already point in this direction. The Clearing House announced its On-Chain Money Initiative in June and selected Quant in September to build its interoperability and orchestration layer. The planned network is intended to let financial institutions clear and settle tokenized deposits while connecting with established U.S. payment infrastructure such as RTP and CHIPS, with availability to participating institutions expected in the first half of 2027.
The BIS's Project Agorá approaches the problem at the wholesale and cross-border level. Its prototype combines tokenized commercial-bank deposits with tokenized central-bank reserves and has demonstrated atomic multi-currency settlement across jurisdictions. More than 40 private-sector financial institutions have participated in the project, and real-value testing conducted in July 2026 involved 28 financial institutions and central banks.
A future payment could therefore pass through several monetary representations while remaining, from the customer's perspective, a single transaction. Making that experience uneventful will require the underlying systems to coordinate claims and settlement conditions across boundaries the user may never see.
Routing
Return to our $2 million position and the simple arrow we drew at the beginning. By now, the infrastructure surrounding that arrow has had to make sense of ownership, policy and liquidity before dealing with finality and payment.
The object in the middle begins to resemble a financial router. Swift uses similar language for its blockchain ledger, which acts as an orchestration layer for bank-issued tokenized deposits held on participating banks' own ledgers. Funds can move through the shared layer before final settlement takes place through existing systems.
That architecture is revealing—it allows different systems to keep doing different jobs. A bank does not have to surrender its ledger, and an existing payment rail does not have to disappear for tokenized infrastructure to become useful. Public chains, permissioned platforms and conventional financial systems can instead meet through layers designed to coordinate them.
A more mature router could eventually weigh where sufficient liquidity is available and whether the recipient satisfies the asset's rules. It might also choose an acceptable settlement instrument and determine how much finality the transaction requires. From the outside, the instruction remains almost comically simple: move $2 million from here to there.
The hard part is making sure that everything attached to those $2 million arrives in recognizable form. As interoperability develops, the token itself may turn out to have been the lightest piece of luggage.