1. The Limits of the Messaging Paradigm
The global financial system is a marvel of connectivity, yet it suffers from a fundamental flaw in its “grammar.” For decades, we have relied on a system of imperative commands—instructions sent from one institution to another, hoping the other side has the capacity and liquidity to execute them. We call this “messaging,” and while it has served us well, it has hit a ceiling of efficiency.
To understand the future of cross-border payments, we must first dissect why the current “fire and forget” model creates the very friction we are trying to solve.
The “Stateless” Trap
At its core, the current correspondent banking network acts like a global game of “Telephone.” Bank A sends a formatted instruction (a SWIFT MT or ISO 20022 message) to Bank B. Bank A then waits. It has no visibility into Bank B’s internal state. Is Bank B’s liquidity insufficient? Is their compliance team holding the door shut? Is the FX desk closed?
Bank A does not know. It simply fires the message into the void and hopes for a confirmation (ack) or, worse, fears a rejection (nack) days later.
This architecture is stateless. The “state” of the transaction—where the money is, who has agreed to what, and what happens next—does not exist in a shared space. Instead, it is fragmented, duplicated across the internal ledgers of every bank in the chain. Each participant maintains their own version of the truth, and we spend billions of dollars annually trying to reconcile these fragmented truths.
The Cost of Uncertainty
This lack of a shared context is not just an abstract architectural complaint; it is a massive operational tax on the global economy.
Exceptions and Investigations (E&I): When a payment stalls, it triggers a manual investigation. Banks must send free-format messages (queries) back and forth to locate the funds or identify the missing data. This is the financial equivalent of calling a courier to ask, “Where is the package?”
Trapped Liquidity: Because banks cannot be certain when a payment will settle, they must maintain bloated nostro accounts—buffers of idle capital sitting in correspondent banks just to ensure transfers don’t fail. This is capital that could be deployed productively elsewhere.
The Reconciliation Burden: Every message sent requires a counter-message to confirm it. The entire industry is essentially double-entry bookkeeping on a global scale, but done manually, slowly, and error-prone.
While innovations like SWIFT gpi (Global Payments Innovation) have improved visibility—adding a “tracking number” (UETR) to the package—they haven’t solved the underlying problem. Knowing where your package is stuck is better than not knowing, but it doesn’t prevent it from getting stuck in the first place.
The Evolutionary Approach
The solution is not to tear down the cables. SWIFT and the correspondent banking network provide a robust, legally binding, and universally connected set of rails. “Rip and replace” strategies, often proposed by blockchain maximalists, ignore the immense complexity and regulatory weight of these legacy systems.
Instead of replacing the rails, we need to upgrade the coordination. We need to move from a system of imperative messaging (sending blind commands) to a system of shared context (establishing agreement).
We need an Internet Trust Layer (ITL), or if that sounds too grandiose and impossible, an Interbank Agent Network. (Technically speaking, they are the same thing: a banking-grade trusted transaction network between banks.)
By introducing a “Context Agent”—a shared digital environment where parties, each represented by their own agents, can coordinate before and during the payment process—we can cure the inefficiencies of the messaging paradigm without discarding the infrastructure that runs the world.
What follows is a pragmatic, four-phase roadmap to transition the global financial system from stateless messaging to shared, atomic reality. It starts not with a revolution, but with a simple, intelligent assistant.
2. The Solution: The Context Agent
If the problem with the current system is that it is “stateless”—a series of disconnected messages fired into the void—then the solution is to create a shared, persistent state for every transaction. We call this the Context Agent.
To understand the Context Agent, we must stop thinking in terms of “sending money” and start thinking in terms of “coordinating agreement.”
Defining the Context
In the traditional model, a payment is defined by the message currently moving through the wires. If the message is lost, the definition of the payment is lost.
In the Internet Trust Layer (ITL) model, a payment is an independent digital entity—a Context Agent.
Imagine a secure, digital meeting room created specifically for one transaction. When a payment is initiated, the originating bank doesn’t just send a message; it instantiates this room. It then invites the agents of the necessary parties: the liquidity providers, the correspondent banks, and the beneficiary institution.
Inside this Context, the parties, each represented by their own agents, do not exchange imperatives (”Do this!”); they exchange commitments (”I will do this”).
It is persistent during the life cycle of the contract: The Context exists before the first penny moves and remains active until the final settlement.
It is shared: The agents of all invited parties look at the same “screen.” There are no separate versions of the truth.
It is active: Unlike a passive ledger entry, the Context Agent is a programmable entity capable of validating logic, checking conditions, and eventually, issuing instructions.
The Grammar of Agreement
This shift enables us to rewrite the “grammar” of the economic transaction.
Our current financial infrastructure speaks in the imperative mood. Bank A commands Bank B to debit an account. This is fragile because if Bank B cannot obey the command (due to liquidity, compliance, or technical failure), the command fails, and the process breaks.
The Context Agent speaks in the declarative mood. It allows the parties to collaboratively build a statement of fact: “We, the participants, agree that this payment path is valid, compliant, and funded.”
Only when the grammar changes from a command to an agreement does the money actually move. This inversion—agreement before execution—eliminates the vast majority of reconciliation errors that plague the industry today.
The Bridge: The UETR Anchor
The most critical question for any innovation in banking is backward compatibility. How does this futuristic “Shared Context” talk to a 40-year-old mainframe software processing COBOL?
The answer lies in a standard that banks have already adopted: the UETR (Unique End-to-end Transaction Reference).
The UETR is a 36-character string used in SWIFT gpi to track payments. Currently, it is just a tag—a luggage label. In our proposal, the UETR becomes the link between the Context Agent (the brain) and the SWIFT message (the body).
Generation: The Context Agent generates the UETR when the transaction is first planned.
Embedding: When the banks eventually execute the payment via legacy rails (in the early phases), they include this specific UETR in their SWIFT MT or ISO 20022 messages.
Reconciliation: The Context Agent “listens” for this UETR. When it sees the message move across the SWIFT network, it instantly links that physical action back to the digital plan.
By anchoring the high-level shared state to the low-level unique identifier, we allow the new world of ITL to coexist with, and eventually control, the old world of messaging. We do not need to replace the pipes; we simply need to give them a memory.
3. Phase 1: The Context as an Intelligent Assistant (The “Shadow” Layer)
The journey to a seamless financial network begins not with a radical switch-over, but with a parallel process. In Phase 1, the Internet Trust Layer (ITL) operates as a “Shadow Layer”—a digital twin of the physical payment process.
At this stage, the ITL does not hold the money, nor does it legally force the movement of funds. Instead, it acts as a hyper-efficient executive assistant, coordinating the logistics so that the existing SWIFT rails can operate without friction.
Step 1: Invite and Commit
The process begins before a single message is sent. When a bank prepares a complex cross-border payment involving FX legs, it instantiates a Context Agent.
The Invitation: The Context Agent identifies the necessary participants—the beneficiary bank, the intermediary correspondents, and the specific providers for the FX leg. It “invites” them into the shared context.
The Commitment: Each invited party reviews the proposed transaction details within this secure environment. They check their internal ledgers for liquidity, compliance, and operational capacity.
The Handshake: If a party is ready, they issue a digital commitment to the Context. This is a signal: “I have reviewed my part of this process, and I am ready to execute.”
This step effectively acts as a pre-validation check for the entire payment chain. If an intermediary bank is offline or lacks liquidity, they cannot commit. The Context halts, and the originating bank knows immediately that the payment will fail—before they have sent the funds into a black hole.
Step 2: The Green Light and the UETR
Once all parties have committed, the Context “finalizes.” It locks the plan and generates the UETR (Unique End-to-end Transaction Reference).
The Context now instructs the participants to execute their parts. In Phase 1, this instruction is essentially a “Green Light.” It tells the bank’s operations team (or middleware): “The path is clear. Send the SWIFT message now, and make sure you attach this specific UETR.”
The banks then send their standard SWIFT MT or ISO 20022 messages via the legacy network. To the outside observer, nothing has changed. But to the participants, everything has changed.
The Assistant’s Role: Sorting Out Manual Work
This is where the “Assistant” role shines. Because the Context Agent knows exactly what should happen (the plan) and knows the identifier (the UETR) to look for, it can monitor the execution in real-time.
Automated Reconciliation: As the SWIFT messages flow through the network, the Context Agent detects them via the UETR. It automatically reconciles the message against the plan. “Bank B sent the payment? Check. FX Provider converted the currency? Check.”
Exception Handling: If a planned step is not detected within the agreed timeframe, or if a message arrives with mismatched data (e.g., the wrong amount), the Context Agent alerts the participants instantly.
In this phase, the ITL is a tool for Exceptions and Investigations (E&I) reduction. It sorts out the manual work of tracking payments and reconciling ledgers. It doesn’t yet move the money, but it ensures that the money moves correctly, drastically reducing the operational cost of the “fire and forget” model.
4. Phase 2: The Context as the Orchestrator (The Binding Instruction)
In Phase 1, the Context Agent acted as a helpful assistant—watching, verifying, and alerting. It reduced friction, but it didn’t fundamentally change who was in charge. The bank’s internal system was still the master; the Context was just the mirror.
In Phase 2, the hierarchy flips.
We move from “Assisted Coordination” to “Binding Orchestration.” The money still travels over the legacy SWIFT rails, but the decision to move that money is no longer made by a human operator hitting a button. It is made by the Context.
Flipping the Hierarchy
To understand this shift, we have to look at the legal and technical “source of truth.”
Today: The SWIFT message is the instruction. It is the primary document.
Phase 2: The ITL Contract is the instruction. The SWIFT message is merely the output—a technical artifact generated to satisfy the legacy infrastructure.
In this phase, the ITL Context evolves into a binding instruction layer. When banks join the Context, they are not just signaling intent; they are signing a digital contract. They agree that if the conditions of the Context are met (e.g., all parties are present, rates are locked, compliance is cleared), then the payment instruction is valid and binding.
Automated Integration (STP 2.0)
This legal shift enables a profound technical shift: deep automation.
In the previous phase, the Context gave a “Green Light” to a human operator or a disconnected system. In Phase 2, the Context is integrated directly into the bank’s Payment Engine via APIs.
Here is the workflow:
The Lock: The Context Agent gathers the commitments. Once the final condition is met, the state changes to “EXECUTING.”
The Trigger: The Context Agent sends a secure API signal to the participating banks’ internal systems.
The Generation: The bank’s system receives the trigger and automatically generates and releases the SWIFT message (MT103 or ISO 20022).
The SWIFT network is still the rail, but the ITL is now the engine.
The “Binding” Difference
Why is this distinction important? It eliminates the “execution gap.”
In Phase 1, there was still a tiny risk: a bank could commit to the plan but then fail to send the message due to a manual error or a sudden change of heart. In Phase 2, the commitment is the execution.
By treating the ITL Contract as the binding instruction, we achieve a new level of Straight-Through Processing (STP). We aren’t just automating the formatting of the message; we are automating the agreement that generates the message.
This prepares the ecosystem for the next leap. The banks are now accustomed to the Context being the source of truth. The SWIFT message is becoming a formality—a legacy echo of the real digital agreement. The stage is set to start phasing out the echo.
5. Phase 3: The Hybrid Network (Introducing Claims and Proofs)
In Phases 1 and 2, the Internet Trust Layer (ITL) was a “meta-layer”—a brain sitting on top of the existing SWIFT body. It coordinated and instructed, but the actual movement of value still happened via the traditional exchange of messages and the updating of isolated nostro/vostro ledgers.
Phase 3 marks the beginning of the physical transformation. This is where we stop just instructing the old rails and start replacing them—but gradually, link by link.
The Rise of Claims and Proofs
In this phase, forward-thinking banks begin to use ITL Claims to execute steps of the payment process, particularly in Foreign Exchange (FX) legs.
A “Claim” in the ITL is not a message; it is a digital asset. It represents a verifiable right to a specific asset or outcome. Instead of Bank A sending a message to Bank B saying “I promise to pay you,” Bank A issues a cryptographically secure Claim that is the payment obligation.
When two ITL-enabled banks interact:
No Message: They do not send a SWIFT MT/ISO message to each other.
Atomic Exchange: They swap Claims (e.g., Currency A Claim for Currency B Claim) within the shared Context.
Instant Finality: The settlement is technically final the moment the Proof is committed to the Context.
This offers a glimpse of the endgame: zero reconciliation, real-time liquidity management, and total transparency. But the world is big, and not everyone will upgrade at once.
The Hybrid Chain: “Islands of Trust”
The genius of Phase 3 is its tolerance for asymmetry. It allows for a Hybrid Chain.
Imagine a payment going from New York (Bank A) to London (Bank B) to Singapore (Bank C).
Bank A and Bank B are ITL-native.
Bank C is still on legacy infrastructure.
In a “rip and replace” blockchain model, this payment would fail or require complex gateways. In the ITL model, the Context Agent acts as the bridge.
Leg 1 (A to B): The Context executes an atomic swap of ITL Claims. It is instant and frictionless.
Leg 2 (B to C): The Context recognizes that Bank C is a legacy participant. It automatically takes the result of the previous step and “translates” it. It instructs Bank B’s legacy gateway to generate a standard SWIFT message for Bank C.
Bank C receives a standard MT103. They have no idea that the first half of the journey was executed on a futuristic trust layer. They just know the money arrived on time.
The Gravity of Efficiency
This hybrid approach solves the “network effect” problem that kills most payment innovations. Banks don’t have to wait for the whole world to join before they see value.
If two banks in a high-volume corridor (e.g., USD/EUR) switch to Phase 3, they immediately slash their operational costs and liquidity requirements for that corridor. They become an “Island of Trust.”
As these islands grow, they create a gravitational pull. Non-ITL banks will see their competitors settling faster and cheaper. The pressure to upgrade comes not from a mandate, but from the market. The legacy rails aren’t turned off; they are simply outcompeted, one link at a time.
6. Phase 4: The Shared State Reality (Phasing Out the Message)
We arrive at the final destination.
In Phase 3, the ecosystem operated as a hybrid network. Islands of high-speed ITL trust—perhaps specific currency corridors or intra-group transfers—were connected to the broader world by the bridges of legacy messaging. But as the network effects take hold, these islands inevitably merge. The efficiency gains of the “Islands of Trust” create a gravitational pull that compels remaining participants to upgrade. Eventually, we reach a tipping point where every participant in a specific payment chain—the originator, the correspondents, the liquidity providers, and the beneficiary—is fully integrated into the Internet Trust Layer.
When this saturation point is reached, the “message” does not just become faster; it becomes obsolete.
The Death of the Notification
To understand why messaging disappears, we must examine why it exists. Why do we send SWIFT messages today? We send them to notify a counterparty that an event has occurred on our internal ledger, or to request that an event should occur on theirs. It is a communication mechanism born of isolation. In the legacy world, Bank A has its truth, and Bank B has its truth. The message is the fragile, asynchronous attempt to synchronize these two separate realities.
In Phase 4, the Context Agent becomes the single, immutable source of truth for the transaction. The need for synchronization vanishes because the state is already shared.
No More “Fire and Forget”: Bank A doesn’t need to “tell” Bank B that funds are coming via a formatted instruction. Bank B is already a participant in the Context; they observe the commitment of funds the moment it happens.
The End of the “Nack”: In the messaging world, a bank might send an instruction only to receive a “Negative Acknowledgement” (Nack) hours later due to a formatting error or invalid account data. In the Shared State reality, it is impossible to construct an invalid transaction. The Context enforces the rules before the commitment is finalized.
Redundancy Removed: Bank B doesn’t need to “tell” Bank A that the FX trade is executed. The execution is an atomic event recorded in the Context, visible to all permitted parties simultaneously.
In this native state, sending a SWIFT message to confirm a transaction would be like sending a fax to confirm you have sent an email. It is redundant data. It adds no value, only noise and potential confusion. Therefore, the legacy messaging layer is quietly phased out. The UETR, once the vital bridge between the old world and the new, evolves into simply the unique identifier of the digital asset itself—the license plate of the transaction, rather than the tracking number of the package.
The Atomic Reality
With the friction of messaging removed, we achieve the holy grail of financial logistics: Atomic Settlement.
The current financial system is plagued by settlement risk (often called Herstatt risk), where one party pays out a currency (e.g., Sold EUR) before receiving the counter-currency (e.g., Bought USD), usually due to time zone differences. This gap creates a window where a counterparty could default after receiving funds but before paying out, potentially triggering systemic failure.
In Phase 4, the ITL eliminates this gap through atomicity:
PvP (Payment vs. Payment): The exchange of value is coupled in the shared code. Currency A and Currency B swap instantly within the Context. The logic is binary: either both sides settle simultaneously, or neither side settles at all. The risk window closes completely.
DvP (Delivery vs. Payment): This logic extends beyond cash. Securities, trade finance documents, or tokenized assets move simultaneously with the payment. Ownership transfers in the exact same block of time that the funds move.
Liquidity Efficiency: Because settlement is instant and guaranteed, banks no longer need to park massive amounts of idle liquidity in pre-funded nostro accounts “just in case.” Capital is released to be productive, rather than acting as a buffer against uncertainty.
This is the end of the reconciliation industry. Today, banks employ armies of staff and sophisticated software solely to check if Ledger A matches Ledger B. In Phase 4, there is nothing to reconcile because there are no longer two separate records of the event. There is only the event itself, shared in real-time.
7. Conclusion: A New Grammar for Global Finance
The vision of a frictionless global economy is often sold as a revolution—a sudden “big bang” where blockchain replaces banking overnight. This is a dangerous fantasy. The global financial system is too heavy, too regulated, and too critical to be rebooted like a crashed laptop. “Rip and replace” strategies ignore the trillions of dollars of value that rely on the stability of existing rails.
The path we have outlined here is different. It is a pragmatic, four-step evolution that respects the legacy while building the future.
Phase 1 (The Assistant): We fix the immediate pain of “Exceptions and Investigations” without touching the payment rails. By creating a shadow context, we buy Visibility. We stop the bleeding of operational costs by ensuring that no payment starts unless it can finish.
Phase 2 (The Orchestrator): We automate the chaos. By making the ITL Context the binding instruction that triggers the legacy message, we buy Certainty. We move from manual inputs to Straight-Through Processing (STP) 2.0.
Phase 3 (The Hybrid): We introduce the new asset class—ITL Claims. By allowing forward-thinking banks to settle atomically between themselves while bridging to legacy peers, we buy Liquidity. We create “Islands of Trust” that outperform the old network, driving adoption through market forces rather than mandates.
Phase 4 (The Native State): We retire the old grammar. We phase out the messaging layer entirely, leaving us with a pure, shared context. We buy Stability. We achieve a financial network that is real-time, atomic, and mathematically verifiable.
This journey is not just about upgrading technology; it is about upgrading the grammar of our economy.
For fifty years, we have operated in the imperative mood. We have built systems based on commands: “Do this,” “Pay that,” “Debit this account.” This grammar is inherently fragile because it relies on the hope that the recipient can and will obey. It is a grammar of uncertainty.
We are now moving to the declarative mood. We are building systems based on agreement: “We agree that this is done,” “We declare this state is valid.” This grammar is robust because it relies on shared verification before execution.
By shifting from stateless messaging to shared context, we don’t just fix the inefficiencies of the correspondent banking system. We transform the very nature of how the world agrees on value, moving from a system of disconnected islands to a single, cohesive continent of trust.
