How to settle an OTC trade across two different wallets
When an OTC trade closes, the price and the size are already agreed. What remains — and what can go wrong — is the routing. Two parties, two wallets, two different assets moving in opposite directions, and the trade is only truly done when both legs land correctly. For the broker or advisor who structured the deal, the moment of settlement is also the moment of exposure: if one side moves and the other doesn’t, someone is holding a loss they didn’t sign up for. This article is about the mechanics of getting each side’s value to the right wallet cleanly, in the right order, with certainty — not theory, but the actual execution architecture of a two-wallet OTC settlement.
What “two wallets” actually means in an OTC settlement
The phrase sounds obvious until you work through the permutations. In a bilateral OTC deal, there are at minimum two counterparties and two destination wallets. But the asset types being exchanged determine almost everything about how settlement unfolds. The most structurally distinct case is crypto-to-fiat, where a bank wire moves in one direction — often same-day via domestic rails — against an on-chain transfer in the other. Crypto-to-crypto settlement works differently: it can be executed as an atomic swap or handled as an internal ledger transfer. Each of those paths has a different risk profile, a different timing dependency, and a different set of failure modes.
Settlement is where the transaction becomes real. Crypto is transferred, fiat is paid out if applicable, and the operational side of the deal is finalized. This step is especially important in OTC because settlement may involve more than a standard exchange withdrawal. There may be custom timing, specific payment rails, agreed wallet procedures, or local fiat requirements.
What the desk or broker needs to know before confirming a settlement path is exactly which wallet each leg is going to — and why. A counterparty’s “wallet” in a large OTC deal is rarely a single address. An institutional buyer might hold BTC in cold storage at a qualified custodian while their USDC lives in a hot wallet managed by their treasury team. The seller’s receiving wallet for fiat proceeds might be a bank account in a completely different jurisdiction from their crypto delivery address. These distinctions are not administrative noise — they govern which settlement method is technically possible and which carries risk.
Settlement is one of the most important parts of the OTC operating model. The desk needs to define how fiat, stablecoins, and digital assets move before and after execution. This includes wallet setup, bank account flows, custodian relationships, transaction approvals, reconciliation, and confirmation procedures.
Getting all of that confirmed before execution — not during it — is what separates a clean close from a frantic renegotiation over telegram.
The core problem: two legs, no guarantee of simultaneity
The structural difficulty in any OTC trade across two different wallets is that the two legs of the exchange are not naturally simultaneous. One side has to move first, or both sides move under some coordination mechanism, or a trusted intermediary holds value in the gap. In traditional OTC securities settlement, the principle used to solve this is Delivery versus Payment (DvP), where asset and cash movement happen simultaneously to eliminate principal risk. Crypto OTC markets have developed their own equivalents of DvP, but they are less standardized and more dependent on the specific setup of the deal.
The gap between trade agreement and settled funds landing in both wallets is the window of settlement risk. The desk needs to know when clients must deliver funds, when assets are released, how failed settlement is handled, and who approves each step. Poorly defined settlement processes can create delays, credit exposure, and client dissatisfaction.
For the professional managing an OTC close, that window is the entire job. The negotiation is over. The price is locked. What remains is a pure operational execution problem.
Crypto-to-crypto: the cleanest path
When both sides of the exchange are on-chain assets — say, BTC on one side and USDC on the other — the two-wallet settlement can, in theory, happen in a single atomic transaction. Atomic execution means the smart contract logic is designed to ensure that both sides of a trade occur simultaneously in a single atomic operation, so that if any part of the transaction fails, the entire transaction is rolled back and neither party’s assets are transferred.
That is the cleanest architecture. In practice, fully atomic on-chain OTC settlement is common in structured environments — purpose-built smart contracts, DeFi OTC protocols — but less common when one or both counterparties are using institutional custody, multi-sig wallets, or custodians who require internal approval workflows before an outbound transfer can be authorized. In those cases, the desk is managing what is effectively a sequenced exchange, not a simultaneous one.
Crypto OTC trading benefits from blockchain-based settlement mechanisms. Transactions settled on-chain can offer faster and more predictable finality compared to traditional financial infrastructure, as they are not constrained by banking hours or correspondent networks. On-chain settlement additionally provides verifiable transaction records, supporting reconciliation and audit processes.
The specific mechanics of a sequenced crypto-to-crypto settlement across two wallets typically look like this: the selling party initiates the outbound transfer of their asset to the buyer’s designated receiving wallet; the buying party, upon seeing the transaction confirmed (or sometimes simultaneously via a pre-agreed protocol), initiates the counter-transfer. Network confirmation time — one block, three blocks, however many the counterparty’s custodian requires for “finality” — sets the pace.
Where brokers run into friction is when one counterparty’s wallet is managed by a custodian who won’t release funds until they see an inbound confirmation, and the other counterparty has the same policy. That is the classic standoff. The resolution is either a tripartite coordination with the custodians, a trusted desk acting as temporary intermediary, or a pre-agreed sequencing commitment where one side accepts the credit exposure of moving first.
The role of pre-confirmed wallet addresses
Before any asset moves, every receiving address needs to be confirmed and whitelisted. This is not formality — it is the mechanism by which the settlement stays clean. Before any trade can happen, the full KYC and KYB verification process covers identity verification, sanctions screening, source-of-funds review, and whitelisting the bank accounts and wallets to be used for transactions.
The broker’s job here is to collect the verified receiving addresses from both counterparties before the trade executes — not at settlement time. A counterparty who sends an amended wallet address at the last minute should trigger a pause in the process. Address substitution at the point of settlement is one of the most common vectors for social engineering attacks in OTC crypto deals, and the financial magnitude involved makes it worth an extra confirmation call, not just a message.
For a deal where side A is delivering 500 BTC and side B is delivering $48 million USDC, the wallet confirmation process deserves the same attention as the term sheet. The address is the destination. Getting that wrong is a final error with no recourse.
Crypto-to-fiat: the harder path
Crypto-to-fiat settlement across two wallets is structurally more complex because the two legs exist on different rails entirely. The crypto leg moves on-chain. The fiat leg moves through banking infrastructure — wire transfer, correspondent banking, ACH, SEPA, or a stablecoin proxy for fiat like USDC or USDT.
OTC trading can offer flexible settlement options, so buyers and sellers can choose their preferred method of transaction finalization, like bank transfers, stablecoin payments, or direct token swaps.
The timing mismatch between these two systems is real. An on-chain transfer on a liquid network like Ethereum or Bitcoin can reach finality in minutes. A wire transfer on the correspondent banking network can take same-day if sent early enough, but can also hang for 24 hours if it crosses a cutoff or requires additional compliance screening at the receiving bank. Settlement options through OTC desks tend to be more flexible than exchange withdrawals. Many offer same-day settlement via bank wire, stablecoins like USDC, or direct transfer to custodial wallets. This flexibility contrasts with exchange withdrawals, which often involve delays and daily limits.
This mismatch is why many experienced desks and advisors have converged on stablecoins as the fiat-leg substitute in institutional OTC deals. USDC or USDT on a fast settlement chain arrives in a wallet with the same finality properties as other on-chain assets. When combined with stablecoins, blockchain settlement can further enhance liquidity management and reduce settlement risk in cross-border transactions. Both legs are now on-chain. The timing problem collapses. The routing problem remains, but it is now a pure wallet-to-wallet problem rather than a cross-rail coordination problem.
Cross-border complications
When one wallet is in a jurisdiction with exchange controls, or when the receiving bank requires additional screening of inbound wire transfers above a threshold, the clean two-wallet picture gets messier. The fiat leg may stop in a correspondent account, require additional documentation, or simply queue behind other payments. Meanwhile the crypto leg has already settled — irreversibly.
This is the scenario where the professional handling the deal earns their position. The answer is not to move the crypto until there is reasonable certainty the fiat will clear, and for “reasonable certainty” to mean something, there needs to be a pre-agreed timeline and a confirmation mechanism. In practice this often means the sending bank issues a SWIFT confirmation or payment reference before the crypto is released, rather than waiting for full cleared funds.
Settlement flexibility matters more than many first-time users expect. A transaction may involve crypto-to-fiat conversion, a specific banking flow, documentation requirements, or timing constraints. OTC arrangements are often better suited to these realities than standard exchange mechanics.
Multi-wallet deals: when one side has more than one destination
The two-wallet framing covers the basic case — one wallet per counterparty. But a significant number of OTC deals at the institutional level involve more complex distribution on one or both sides. A family office selling BTC might want proceeds split between an operating account and an investment account. A fund taking delivery of crypto might want it routed across three cold storage addresses to stay within per-wallet security policies. A broker who has multiple principals on one side of the deal might need the incoming consideration allocated across each principal’s separate wallet.
This is where the payment routing layer of the deal becomes its own piece of structured work. Once a trade is executed, the platform should automatically generate trade confirmations, calculate settlement obligations, and initiate asset transfers. For institutions that trade across multiple custodians, the platform needs to support flexible settlement routing.
In most traditional desk workflows, multi-wallet distribution is handled in sequential steps: the primary settlement sends value to a single receiving wallet, and internal transfers then distribute it downstream. That approach works, but it adds time, introduces additional transaction costs on the on-chain legs, and creates a reconciliation challenge if any step in the chain fails partway through.
The cleaner approach — and the one that becomes increasingly practical as on-chain payment infrastructure matures — is to build the distribution logic into the settlement itself. Rather than settling to one wallet and then redistributing, the deal closes with value flowing directly to each final destination in the same transaction. For the broker advising a client with three receiving wallets, this means providing the distribution map at the point of deal setup, not as an afterthought at close. When a deal is structured in Shaka, this is exactly what the payment link captures: the recipient wallets, the split percentages, all defined before execution, so when the deal closes, funds move straight to each destination in one transaction. The broker doesn’t chase distributions after the fact. The routing is the settlement.
The confirmation and reconciliation layer
Settlement across two wallets is not complete when the sending party initiates the transfer. It is complete when both wallets contain the correct amounts and both counterparties have confirmed receipt. Both parties confirm the successful transfer of funds and cryptocurrencies. The trade is considered complete once both parties have confirmed the transaction.
For the professional managing the deal, that confirmation has to be actively collected — it is not automatic. The on-chain transaction hash gives the broker verifiable proof that the crypto leg settled, timestamped and immutable. The fiat confirmation is typically a bank statement screenshot, a SWIFT MT103 reference, or a SEPA receipt from the receiving institution. Both need to be documented.
Institutional OTC desks must produce detailed audit trails, transaction cost analysis, and regulatory reports. The platform should log every quote received, every execution, and every settlement event in an immutable record that compliance teams can query.
For brokers and advisors who handle OTC deals regularly, this documentation layer is what protects them when a counterparty disputes the settlement or when a regulator asks for records. The hash of the on-chain transaction, combined with the block confirmation timestamp and the receiving wallet address, is proof that cannot be amended. It is worth keeping a clean record of each of these alongside the deal file.
Settlement workflows should be configured alongside trading permissions and account structure. The goal is to make the post-trade process as controlled as the execution process: clear instructions, verified counterparties, auditable activity, and reliable reporting.
Timing and the locked-price problem
One of the defining features of an OTC deal is that the price is fixed at the moment of agreement, not at the moment of settlement. While exchange trades are often near-instant market orders, OTC execution is the controlled finalization of the pre-agreed quote. The locked price is a feature — it gives both sides certainty. But it creates an operational tension: the longer the gap between price lock and settlement, the more both parties are exposed to market movement in the asset they are delivering.
What matters to the client is that execution happens under agreed terms, rather than being exposed to the uncertainty of a large visible market order.
This tension drives everything about settlement urgency in OTC. A deal priced at 11 AM that doesn’t settle until the following morning has given both sides sixteen hours of basis risk. The seller who agreed to deliver BTC at $98,000 is watching a market that may have moved to $101,000 by the time they can actually send the funds. Neither side is protected. The remedy is fast settlement — not just as a preference, but as a structural discipline.
Fast settlement is also the practical argument for pre-configured wallet infrastructure. When the receiving addresses are confirmed, when the wallet authorization workflows are already completed, when the outbound transfer approvals are in place before the quote is locked, settlement can happen in the window of minutes rather than hours. Every step that has to be resolved after price lock is a step that bleeds value.
The desk issues a locked quote before execution — once accepted, the rate is fixed regardless of market movement, eliminating crypto slippage entirely. But that rate guarantee only holds operationally if the settlement infrastructure is ready to go at the moment of execution.
Scenarios where the routing goes wrong
Understanding the failure modes of two-wallet OTC settlement is as important as understanding the ideal path. Several specific failure scenarios recur across professional OTC deal histories.
Wrong network. USDC on Ethereum and USDC on Polygon are the same asset with the same name but incompatible delivery addresses. Sending to the right address on the wrong network results in funds that are technically traceable but operationally stranded. Recovery depends on whether the receiving party controls the private key for the same address on the receiving network. Often they don’t. This is one of the most common and most preventable errors in crypto OTC settlement, and it is entirely eliminated by specifying not just the wallet address but the network in the trade confirmation.
Address substitution. As noted earlier, a wallet address change submitted at the point of settlement by email or messaging app is a red flag, not a routine request. The counterparty whose wallet address changes between confirmation and execution should be called, not messaged. The call should be to a previously verified number, not one supplied in the same communication thread as the address change.
Custodian delay. When one party’s assets are held in institutional custody with outbound transfer requiring compliance sign-off, the settlement timeline is not controlled by the counterparties — it is controlled by the custodian’s internal workflow. Many OTC trades use third-party custodians to boost security. These arrangements keep assets safe until both sides meet the agreed conditions. Some platforms also use multi-signature wallets and advanced custody solutions to protect funds during trades. The professional who knows their client’s custodian has a four-hour outbound approval window plans around it. The one who doesn’t finds out at the worst possible time.
Partial settlement. Some multi-wallet deals fail partway through because one of the destination wallets turns out to be on a different network, or has a receiving limit, or is temporarily inaccessible. A partial settlement — where some wallets receive and others don’t — creates reconciliation complexity that is far more expensive to resolve than it was to prevent. Pre-flight checks on all receiving wallets before execution are not optional.
What clean settlement looks like
A clean two-wallet OTC settlement is unremarkable. Both legs move. Both wallets receive the correct amounts. The confirmation hashes are documented on both sides. The broker has a record of the settlement that matches the trade confirmation. Nothing needs to be chased, renegotiated, or explained.
That outcome is not the result of luck. It is the result of treating wallet routing as a first-class element of deal structure — something established and confirmed before the quote is locked, not assembled under time pressure once the price is agreed. The desk also needs to decide whether clients must pre-fund trades, whether settlement is handled after execution, and how exposure is controlled between trade agreement and final settlement. These choices affect both client experience and risk management.
The professionals who close OTC deals cleanly, deal after deal, have one thing in common: they treat the settlement instruction as part of the deal structure, not as a post-trade administrative step. The counterparty wallet addresses are confirmed before the term sheet is signed. The network is specified alongside the asset. The internal custodian or multi-sig approval workflows are pre-cleared. When the price is locked, the only thing left is execution — and execution, at that point, is a formality.
That is the standard. Two wallets, two legs, one clean close. Everything else is working backwards from a problem that could have been avoided at the beginning of the deal.
