Building an Exchange for Real-Time Cross-Border Payment Routing
How standardized remittance contracts, competitive execution, intelligent routing, and stablecoin settlement could create a more efficient market for international money transfers
Executive Summary
The international remittance industry has an unusual structural problem.
When a customer asks an International Money Transfer Operator, or IMTO, to send money from one country to another, the IMTO generally does not search the entire market at that moment for the best possible way to execute the payment. Instead, it routes the transaction through one of the correspondent relationships it has already negotiated.
That correspondent may offer a perfectly acceptable service. But somewhere else in the market there may be another licensed provider capable of delivering the same transaction faster, at a better FX rate, through a more appropriate payout method, or at a lower overall cost.
The problem is that the sending IMTO may have no contractual relationship with that provider.
Creating one can require commercial negotiations, compliance reviews, technical integration, settlement arrangements, limits, legal agreements, testing, and operational approvals. For a single transaction, or even a relatively small flow of transactions, establishing another bilateral relationship may make little commercial sense.
The result is an inefficient market.
We have competition among remittance companies, but comparatively little real-time competition for the execution of an individual remittance contract.
This article proposes a different architecture: the Tradable Remittance Contract Exchange.
Under this model, the sending IMTO would convert its customer obligation into a standardized, machine-readable remittance contract containing the transaction requirements. Licensed and approved exchange participants could compete to execute that contract by submitting offers that meet or exceed its requirements.
A matching and routing engine could then compare FX rate, payout speed, payout method, reliability, cost, available capacity, compliance eligibility and other variables before awarding the contract to the most appropriate execution provider.
Settlement could occur using stablecoins held in escrow, allowing value to move just in time rather than requiring every sending institution to maintain large pools of dormant pre-funded capital across multiple correspondent relationships.
Proof of successful beneficiary delivery would trigger settlement release.
The result would effectively be a marketplace for cross-border payment execution.
Instead of asking:
“Which correspondent do I already have?”
the sending institution could begin asking:
“Who in the approved market can execute this particular payment best, right now?”
That is a fundamentally different model for international money movement.
The Fundamental Problem With Remittance Routing
Consider how ordinary commerce works.
Suppose somebody asks you to purchase a particular computer mouse.
You might search several websites and discover five vendors selling essentially the same product.
One vendor may charge $50 with free shipping.
Another might charge $47 but require $8 shipping.
Another could deliver tomorrow.
Another may take five days.
One might have the exact color you want.
Another may offer a slightly different specification.
If all this information were displayed in a single table, the decision would become relatively straightforward.
You could compare:
Variable | Vendor A | Vendor B | Vendor C |
|---|---|---|---|
Product price | $50 | $47 | $52 |
Shipping | Free | $8 | Free |
Delivery | 2 days | 5 days | Same day |
Exact specification | Yes | Yes | Yes |
Availability | Available | Available | Limited |
There is no universally correct answer.
Different buyers may optimize for different things.
One person wants the lowest total cost.
Another wants immediate delivery.
Another wants a precise specification.
What matters is that the buyer can see competing alternatives and make a routing decision.
Now consider a remittance.
A customer walks into or logs into an IMTO and says:
I want to send $1,000 to Nigeria.
Conceptually, the variables are remarkably similar.
There is an FX rate.
There is a fee.
There is a payout method.
There is a delivery timeframe.
There is a receiving network.
There may be a bank deposit option, cash payout option, mobile wallet option or other delivery mechanism.
There is also reliability, transaction status visibility, beneficiary experience and settlement risk.
Yet the sending IMTO generally does not place that individual transaction into a competitive marketplace.
It normally sends it through a correspondent with which it already has a relationship.
And therein lies the structural problem.
The Market Is Competitive, but the Individual Transaction Often Is Not
International money transfer is already a competitive industry.
Hundreds of banks, money transfer operators, payment companies, fintechs, payout networks, FX providers, wallets and aggregators compete globally.
But their connectivity is fragmented.
Provider A may have excellent capabilities in Nigeria.
Provider B may have exceptional pricing in India.
Provider C may dominate cash payout in the Philippines.
Provider D may have excellent mobile-money connectivity in Africa.
Provider E may have access to superior local FX liquidity in Pakistan.
The problem is not necessarily the absence of capable providers.
The problem is connectivity between them.
A sending IMTO cannot ordinarily wake up one morning, discover that another company has a better Nigerian payout rate and immediately start routing customer transactions through that company.
Before that can happen, both organizations typically need some form of commercial and compliance relationship.
That creates friction.
A new corridor relationship may involve legal agreements, KYB, compliance approvals, technical integration, transaction monitoring arrangements, reconciliation procedures, settlement terms, operational limits and commercial negotiations.
Consequently, the number of execution options available for a transaction is usually much smaller than the number of companies theoretically capable of executing it.
That is an important distinction.
There may be hundreds of possible delivery providers in the market.
But if the sending IMTO has agreements with only three of them, then for practical purposes its market consists of three providers.
The rest might as well not exist.
Bilateral Correspondent Agreements Create Routing Silos
The current architecture therefore produces what can be thought of as bilateral routing silos.
An IMTO builds Corridor A with Provider A.
Another relationship covers Corridor B.
Another covers Corridor C.
Each relationship may have different pricing, settlement mechanics, limits and technical requirements.
Once those integrations have been established, transactions naturally flow through them.
The infrastructure begins determining the route rather than the transaction determining the route.
That is backwards.
Ideally, the characteristics of the transaction should determine the most appropriate execution route.
Instead, the most important question often becomes:
Who are we already connected to?
That can create several inefficiencies.
The IMTO may not receive the best available FX rate.
The beneficiary may not receive the fastest available delivery.
A better payout method may exist elsewhere.
Liquidity may be unnecessarily fragmented between corridors.
Smaller providers may be unable to access transaction flows despite having competitive capabilities.
And smaller sending institutions may struggle to offer broad geographic coverage because establishing dozens or hundreds of correspondent relationships is expensive.
What we have created is not necessarily an inefficient payment network.
It is an inefficient market structure around payment execution.
What If the Remittance Contract Could Be Detached From the Original Pipeline?
This leads to the central idea.
When a customer instructs an IMTO to make a remittance, the IMTO has effectively acquired an obligation.
For example:
Receive $1,000 from Sender A in the United States and deliver the corresponding amount to Beneficiary B in India under a defined set of conditions.
Those conditions can be described.
The sender is known.
The beneficiary is known.
The send amount is known.
The destination is known.
The payout method is known.
The expected FX outcome can be defined.
The maximum delivery time can be defined.
The compliance characteristics can be transmitted.
In other words, the transaction can be represented as a standardized remittance contract packet.
Conceptually, that contract might contain:
Sender information and applicable KYC data.
Beneficiary information.
Send amount and currency.
Destination amount or minimum acceptable FX rate.
Destination country and currency.
Required payout method.
Maximum permissible delivery time.
Transaction purpose and regulatory metadata.
Compliance and sanctions information.
Settlement requirements.
Service-level requirements.
Proof-of-delivery requirements.
Once standardized, something interesting becomes possible.
The execution of that contract no longer necessarily needs to remain permanently attached to the sending IMTO's original correspondent pipeline.
It could become routable.
From a Remittance Instruction to a Tradable Execution Contract
Suppose the sending IMTO has promised its customer that $1,000 will be converted at a minimum effective rate of 100 units of destination currency per dollar and delivered within two hours.
The sending IMTO now possesses an execution requirement.
Several exchange participants could compete for it.
Provider A might say:
100.00, delivery within two hours.
Provider B:
101.00, delivery within two hours.
Provider C:
100.00, delivery within 30 minutes.
Provider D:
100.75, delivery within five minutes.
Provider E:
102.00, delivery within two hours.
Every offer satisfies the basic customer contract.
But they optimize differently.
Provider D offers exceptional speed.
Provider E offers superior economics.
Provider B improves the FX outcome while maintaining the required SLA.
Which offer should be selected?
That depends on the sending IMTO's objective.
And that is precisely where a trading and routing engine becomes valuable.
The Tradable Remittance Contract Exchange
Imagine an exchange whose members consist only of approved financial institutions and payment companies.
Participants might include:
International Money Transfer Operators
Banks
Payment Service Providers
FX companies
Fintech platforms
Mobile-wallet operators
Payout networks
Local payment aggregators
Liquidity providers
Before participating, each institution would undergo onboarding and verification.
Licensing status could be checked.
KYC and KYB would be completed.
Permitted countries and currencies could be recorded.
Transaction limits could be established.
Payout capabilities could be mapped.
Settlement requirements could be configured.
Compliance responsibilities could be assigned.
Only after being approved would the participant become eligible to submit or execute contracts.
This changes the unit of integration.
Today, IMTO A may need separate relationships with Providers B, C, D, E and F.
Under an exchange model, IMTO A establishes a relationship with the exchange framework.
Providers B through F do the same.
The exchange becomes the standardized marketplace through which eligible execution relationships can be formed transaction by transaction.
The Exchange Is More Than a Marketplace
The exchange should not simply be thought of as a notice board where somebody posts:
$1,000 to India. Who wants it?
That would vastly understate what is required.
The real value lies in the infrastructure underneath the marketplace.
A functional Tradable Remittance Contract Exchange would require several interconnected engines.
1. Participant Registry
Every exchange member would have a structured capability profile.
The platform would know, for example:
Provider X can deliver INR bank deposits in India.
Provider Y can deliver PHP cash pickup in the Philippines.
Provider Z can deliver NGN into Nigerian bank accounts.
The registry would also maintain limits, licensing information, currencies, payout methods, service levels and other eligibility information.
This means contracts would never be indiscriminately broadcast to the entire exchange.
Only institutions capable and permitted to execute a particular transaction would receive it.
2. Contract Normalization Engine
Different payment companies describe transactions differently.
Before contracts can be traded or routed efficiently, they need a common structure.
The normalization engine converts the originating IMTO's transaction into a standardized exchange instrument.
For example:
Send Amount: USD 1,000
Destination: India
Currency: INR
Payout: Bank account
Maximum Delivery: Two hours
Minimum Effective FX: 100.00 INR/USD
Required Compliance Data: Complete
Settlement: Stablecoin escrow
This standardized object becomes the instrument processed by the exchange.
3. Eligibility and Compliance Engine
Before price discovery begins, the exchange needs to determine who is actually eligible to execute the transaction.
This engine could evaluate factors such as jurisdiction, participant permissions, corridor eligibility, payout capability, transaction limits, sanctions restrictions and exchange rules.
A provider incapable of serving the corridor would never reach the bidding stage.
Neither would a participant whose available capacity had been exhausted.
Compliance therefore becomes part of routing rather than something checked only after routing.
The Order Book for Remittance Execution
Once eligibility has been determined, the contract enters the exchange's matching environment.
This resembles an order book, although the instrument being matched contains more dimensions than a traditional financial order.
A conventional securities order might primarily optimize price and quantity.
A remittance contract may optimize:
FX + Cost + Speed + Payout Method + Reliability + Capacity + Compliance Eligibility + Settlement Terms.
This is fundamentally a multi-dimensional market.
The cheapest provider is not necessarily the best provider.
Neither is the fastest.
The optimal provider is the participant that best satisfies the originating IMTO's routing objective.
The Matching Engine
This is the heart of the exchange.
Providers submit executable offers.
The matching engine compares those offers against the contract's minimum requirements.
Offers falling below those requirements are rejected.
Offers meeting or exceeding them proceed to ranking.
Suppose the contract requires:
Minimum rate: 100.00
Maximum delivery: two hours
Payout method: bank deposit
And the exchange receives:
Provider | FX Rate | Delivery |
|---|---|---|
A | 100.00 | 2 hours |
B | 100.25 | 1 hour |
C | 100.50 | 30 minutes |
D | 100.70 | 15 minutes |
E | 100.75 | 5 minutes |
Every provider satisfies the contract.
But the originating IMTO may not necessarily want Provider E.
Perhaps Provider D historically has better reliability.
Perhaps Provider C has lower settlement costs.
Perhaps Provider B has considerably more available capacity.
The matching system therefore hands the eligible offers to another component.
The Ranking and Routing Engine
The originating IMTO should be able to program its preferred execution logic.
For one company, the instruction might be:
Always maximize FX margin provided delivery occurs within 60 minutes.
Another may say:
Always choose the fastest route if the FX difference is less than five basis points.
Another may prioritize customer experience.
Another may prioritize payout reliability.
Another may prefer a particular provider until that provider's available capacity falls below a defined level.
Routing could therefore be based on:
Best FX
Lowest execution cost
Fastest delivery
Highest expected profit
Historical delivery reliability
Failure rate
Available provider capacity
Payout method
Customer preference
Corridor preference
Risk weighting
Settlement cost
Concentration limits
The routing engine could calculate an execution score and either award the transaction automatically or present ranked alternatives to the sending IMTO.
At sufficient scale, millions of these decisions could eventually be automated.
This is effectively least-cost routing for regulated cross-border payment contracts, except that cost becomes only one dimension of the decision.
The Agent Becomes the Financial Router
This architecture also creates an obvious role for autonomous decision agents.
The sending IMTO does not need a human operator comparing five bids for every $500 transaction.
Instead, it programs its execution policy once.
For example:
Never accept less than the contractual FX rate.
Never exceed the promised delivery time.
Prefer providers with a success rate greater than 99.7%.
Optimize net margin after settlement cost.
Avoid placing more than 20% of today's corridor volume with one provider.
If two offers are economically equivalent, choose the faster route.
The software agent continuously applies those instructions.
When a contract arrives, it queries the exchange, evaluates eligible providers, selects the best route and awards execution.
The agent becomes a financial router.
It performs for cross-border payments something conceptually similar to what routing engines already do throughout telecommunications, computing, logistics and card-payment infrastructure.
Stablecoins Change the Settlement Architecture
Execution is only half the problem.
The other half is settlement.
Traditional remittance networks frequently rely heavily on pre-funded liquidity.
If an IMTO sends payments into several countries, capital may need to be positioned across multiple relationships to ensure payouts can occur.
This creates idle liquidity.
A smaller IMTO may therefore face an unpleasant tradeoff.
To offer more countries, it needs more correspondents.
More correspondents mean more integrations.
More correspondents may also mean more liquidity relationships.
More liquidity relationships mean more capital fragmentation.
This is one reason the exchange model becomes particularly interesting when combined with stablecoins.
Stablecoins provide a highly portable settlement asset that can potentially move between approved participants extremely quickly.
Instead of permanently parking significant amounts of capital with numerous corridor partners, the sending IMTO could fund an awarded contract at the moment execution occurs.
That is just-in-time settlement.
There is, however, an important distinction.
Stablecoins do not eliminate liquidity.
The receiving provider still needs the ability to make the beneficiary payout in local currency, or needs immediate access to somebody who can.
What stablecoins potentially eliminate is much of the need for the sending institution to maintain static bilateral pre-funding balances across every individual corridor relationship.
That distinction matters.
The innovation is not zero liquidity.
The innovation is portable liquidity with substantially faster capital recycling.
Stablecoin Escrow
Consider a $1,000 remittance.
Provider X wins the contract.
The sending side transfers $1,000 of approved stablecoin into an exchange-controlled escrow arrangement.
Provider X sees that the value is committed.
Provider X executes the beneficiary payment locally.
The beneficiary receives the money.
Provider X submits proof of delivery.
The exchange verifies that proof.
Once verification succeeds, escrow releases the $1,000 stablecoin settlement to Provider X.
The process becomes:
Contract Awarded → Stablecoin Reserved → Local Payout → Proof of Delivery → Verification → Stablecoin Released
This can dramatically reduce settlement uncertainty between participants that may never previously have maintained a direct bilateral relationship.
Capacity and Risk Limits
No provider should be allowed to accept unlimited contracts merely because it is an exchange member.
Each participant needs exposure limits.
Suppose Provider X commits $5,000 of collateral or settlement capacity.
The exchange applies an 80% utilization limit.
Provider X therefore has $4,000 of available execution capacity.
If Provider X accepts a $1,000 contract, its remaining capacity falls to $3,000 until the transaction settles.
Once delivery has been verified and the settlement cycle completes, capacity becomes available again.
This creates a continuously recycling execution limit.
A participant with relatively modest capital could potentially process significantly more than its static balance during a day if settlement cycles are sufficiently fast.
For smaller providers, that is particularly important.
Capital velocity becomes almost as important as capital size.
Proof of Delivery Becomes a Settlement Event
The exchange also requires a robust verification engine.
A simple assertion that the beneficiary was paid cannot be sufficient.
Depending on the payout method, evidence might come from APIs, bank-confirmation messages, wallet confirmations, payout-network acknowledgements or other machine-verifiable events.
Once the required evidence satisfies the exchange's rules, the contract moves from executed to completed.
Settlement is then released.
This creates an important conceptual link:
Payment execution and settlement finality become connected through verifiable delivery events.
The exchange therefore does not simply match counterparties.
It manages the lifecycle of the contract.
The Complete Transaction Flow
The entire process could operate as follows:
A customer asks an IMTO to send $1,000 from the United States to India.
The IMTO performs the required customer onboarding and accepts the remittance.
The IMTO creates a standardized remittance contract.
The contract is submitted to the exchange.
The exchange identifies eligible India payout providers.
Those providers submit executable offers.
The matching engine eliminates offers that fail the contract requirements.
The ranking engine scores the remaining offers.
The routing engine selects the preferred provider.
The contract is awarded.
Stablecoin settlement value moves into escrow.
The selected provider delivers INR to the beneficiary.
Delivery evidence is submitted.
The exchange validates proof of payment.
Stablecoin settlement is released to the executing provider.
Records are reconciled and the transaction is closed.
What previously required a fixed correspondent path becomes a real-time market decision.
Why Smaller IMTOs Could Benefit Disproportionately
Large international money transfer companies already maintain extensive correspondent networks.
Smaller operators usually cannot.
For them, every new destination can require another relationship, another integration, more compliance work and potentially more settlement capital.
The exchange changes that equation.
A small licensed IMTO could theoretically join one standardized ecosystem and gain execution access to many corridors.
Meanwhile, a small payout operator in a particular country might gain access to transaction volume originating from dozens of sending institutions that it could never economically acquire individually.
That creates network effects on both sides.
More originating IMTOs create more contracts.
More executing providers create better competition.
Better competition improves rates and delivery options.
Improved economics attract more originating volume.
More volume attracts additional liquidity and payout providers.
The exchange could therefore become more valuable as participation grows.
The Receiving Side Suddenly Becomes a Marketplace
The model is equally important for receiving institutions.
Imagine a Nigerian payout company with exceptional local banking connectivity but limited international business development capability.
Today, that company must individually negotiate with foreign IMTOs to receive remittance volume.
Under an exchange model, it could publish its capabilities once.
Nigeria: supported.
NGN: supported.
Bank payout: supported.
Mobile wallet: supported.
Maximum transaction size: defined.
Available capacity: defined.
Pricing: dynamic.
Delivery SLA: five minutes.
It could then compete automatically for eligible Nigerian contracts appearing on the exchange.
Its distribution problem becomes a market-access problem solved through infrastructure.
This could unlock considerable latent capacity throughout the global payment industry.
Competition Moves From the Company Level to the Transaction Level
This may be the most significant consequence of the idea.
Today, consumers compare remittance companies.
Tomorrow, remittance companies themselves could compare execution providers transaction by transaction.
Competition moves one layer deeper into the payment stack.
The customer might still see one brand.
But underneath that brand, each individual payment could potentially travel through a different optimal provider.
A $500 Indian transaction may go through Provider A.
The next $3,000 transaction may go through Provider B.
A bank payout may route one way.
A mobile-wallet payout may route another.
A transaction requiring immediate delivery may select a premium provider.
A customer choosing slower delivery may allow the routing engine to optimize economics.
The visible money transfer company becomes an intelligent orchestration layer sitting above a competitive execution market.
Why This Could Produce Better Economics
If multiple providers compete for the same contract, price discovery improves.
An IMTO currently receiving 100 units of destination currency per dollar might discover another provider willing to execute at 100.75.
Another might offer 101.00.
That difference can be shared in several ways.
The IMTO could keep it as additional margin.
It could pass it to the customer.
It could split the improvement between itself and the customer.
Or the routing system could optimize some transactions for rate and others for speed.
This creates something the bilateral correspondent model struggles to produce:
continuous price discovery at the transaction level.
The Exchange Could Also Create Better Reliability
Price alone should never determine execution.
An apparently excellent FX rate is meaningless if payouts frequently fail.
The exchange could therefore maintain historical performance data for every participant.
Delivery success rates.
Average completion times.
Rejected transactions.
Reversals.
Failed payouts.
SLA breaches.
Disputes.
Compliance incidents.
Liquidity utilization.
These metrics could become inputs into the ranking engine.
Over time, the exchange develops something extremely valuable:
market-wide execution intelligence.
A provider's reputation becomes measurable through actual performance.
That improves routing.
It also creates an incentive for participants to improve service quality because superior performance could directly translate into additional contract awards.
The Real Commercial Question Is Liquidity of the Exchange
The objection to this concept will inevitably be:
Would enough people actually use it?
That is the correct question.
An exchange without liquidity is simply software.
A tradable remittance market needs sufficient supply and demand.
There must be enough originating contracts.
There must be enough providers willing to execute them.
There must be enough corridor overlap.
There must be sufficiently standardized compliance and settlement rules.
The sensible approach therefore would not be to begin by attempting to create a global exchange covering every country.
Start narrow.
One originating market.
A handful of destination markets.
A small number of approved IMTOs.
A group of credible payout providers.
A standardized contract.
A narrowly defined payout method.
A stable settlement mechanism.
Then observe whether competitive execution actually produces measurable improvements.
Does FX improve?
Does settlement capital decline?
Does provider utilization increase?
Does delivery become faster?
Do smaller IMTOs gain meaningful corridor access?
If the answer is yes, expand.
The concept does not need to prove the entire global architecture on Day One.
It merely needs to prove that a remittance obligation can be separated from a fixed bilateral execution route and competitively fulfilled inside a controlled market.
“Tradable” Does Not Necessarily Mean an Unregulated Free Market
The word tradable can easily create the wrong impression.
The proposal is not that personally identifiable remittance instructions should be anonymously bought and sold on an open public marketplace.
Quite the opposite.
This would need to be a tightly permissioned environment populated by institutions whose identities, regulatory status, capabilities and limits are known.
Furthermore, the legal mechanism by which execution responsibility moves between participants would need to be precisely designed.
Depending on the jurisdiction and contractual architecture, what is commercially described as “trading” could ultimately be implemented through assignment, novation, subcontracted execution, agency or another legally recognized structure.
The terminology is secondary.
The important architectural principle is this:
The originating IMTO's customer obligation should be capable of being fulfilled by the best eligible execution provider available within a controlled network, rather than automatically remaining attached to one predetermined bilateral pipeline.
That is the innovation.
From Remittances to Larger Cross-Border Payments
Remittances provide the logical starting point because they are relatively standardized.
But the concept does not necessarily end there.
Suppose a business needs to send $50,000 to a supplier.
Or $100,000.
Or $500,000.
The contract becomes more complex.
There may be invoice verification.
Purpose-of-payment requirements.
Beneficiary ownership information.
Trade documentation.
Enhanced due diligence.
Treasury requirements.
More sophisticated FX execution.
Nevertheless, the fundamental architecture remains recognizable.
There is still an originating payment obligation.
There are still execution requirements.
There are still multiple potential providers.
There is still a price.
There is still a delivery SLA.
There is still settlement.
There is still proof of completion.
The exchange could therefore eventually support different classes of payment contracts.
Retail remittance contracts.
SME cross-border payment contracts.
B2B supplier-payment contracts.
Larger FX execution contracts.
Rather than building a remittance exchange, we may ultimately be describing the foundations of a cross-border payment execution exchange.
Stablecoins May Be the Connectivity Layer That Makes This Practical
Many elements of this concept could theoretically have been attempted years ago.
Matching engines are not new.
FX marketplaces are not new.
Payment aggregators are not new.
Electronic contracting is not new.
What has materially improved is the ability to move settlement value rapidly between participants using programmable digital assets.
That matters because the exchange cannot function efficiently if every provider still requires every other provider to maintain separate funded bilateral accounts.
We would simply recreate the old correspondent architecture underneath a new interface.
Stablecoins provide the possibility of a common settlement asset moving alongside the contract.
The contract tells us:
what must be done.
The stablecoin provides:
the value required to settle what has been done.
The exchange connects the two.
That combination is what makes the architecture particularly interesting.
A New Mental Model for Cross-Border Payments
For decades, international payment businesses have generally thought in terms of corridors.
We need India.
Find an India correspondent.
Negotiate.
Integrate.
Pre-fund.
Launch.
Then Nigeria.
Repeat.
Then the Philippines.
Repeat.
Then Pakistan.
Repeat again.
The Tradable Remittance Contract Exchange proposes another mental model.
Instead of constructing a separate pipeline for every corridor, create a standardized execution market.
The sender creates an obligation.
The obligation becomes a routable contract.
Eligible providers compete.
A routing engine selects the best execution path.
Settlement value is reserved.
The beneficiary is paid.
Proof is verified.
Settlement is released.
The transaction closes.
That is no longer simply correspondent banking or bilateral remittance routing.
It is market-based payment orchestration.
The Bigger Idea: De-Tether the Contract From the Rail
The most important idea in this entire proposal can be expressed in one sentence:
De-tether the payment contract from the original payment pipeline.
The customer bought an outcome.
The customer wants $1,000 converted and delivered to a beneficiary under specified conditions.
The customer does not necessarily care which approved institutional pathway underneath the transaction produces that outcome.
If multiple regulated providers can satisfy the same obligation, those providers should potentially be allowed to compete for its execution.
Once we accept that premise, the architecture changes dramatically.
Correspondent relationships become less important.
Standardization becomes more important.
Routing intelligence becomes more important.
Provider performance data becomes more important.
Liquidity efficiency becomes more important.
Real-time price discovery becomes possible.
And previously disconnected pockets of payment infrastructure can begin functioning as one larger market.
Conclusion: It Is Time to Experiment With Tradable Remittance Contracts
The global payments industry spends enormous amounts of money trying to make individual payment rails faster.
That work is necessary.
But perhaps another source of inefficiency deserves equal attention.
The problem may not simply be how quickly money travels through a particular rail.
The problem may be that the transaction is placed on the wrong rail in the first place because the originating institution has only a limited number of commercially available routes.
A Tradable Remittance Contract Exchange attacks that problem at a different layer.
It does not attempt to replace every bank.
It does not attempt to replace every IMTO.
It does not attempt to replace every payout network.
Instead, it attempts to connect them through a common market for execution.
The sending IMTO creates the contract.
The exchange standardizes it.
Eligible institutions compete for it.
The matching engine discovers alternatives.
The routing engine determines the optimal provider.
Stablecoin escrow enables just-in-time settlement.
The payout provider executes.
Proof of delivery releases value.
The transaction completes.
For smaller IMTOs, this could mean access to corridors they could not economically build themselves.
For payout providers, it could mean access to transaction flows they could not individually acquire.
For larger operators, it could create real-time route optimization.
For customers, it could eventually translate into better FX, faster delivery, more payout choices and greater reliability.
And for the industry as a whole, it could create something that has been largely missing from cross-border retail payments:
a genuine market for the execution of individual payment obligations.
We already trade currencies.
We trade securities.
We trade commodities.
We dynamically route internet traffic.
We automatically route card transactions.
We continuously optimize logistics networks.
Perhaps it is time to ask a more fundamental question about international payments:
Why should a remittance contract remain permanently attached to the first pipeline that received it?
Maybe it should not.
Maybe the contract itself should become routable.
And eventually, tradable.