In this article
Every OTC trade begins with a handshake — a price agreed, a quantity confirmed, a settlement method understood. The problem is that a handshake leaves two separate memories, two internal booking systems, and two file folders that will need to tell exactly the same story when the settlement date arrives. When they do not, the friction that follows is expensive: phone calls, amended confirmations, delayed wires, and, in the worst cases, a failed trade that creates market risk and reputational damage for everyone involved.
This article is a practical reference for the settlement agents, brokers, OTC desk operators, closing attorneys, and operations teams who live inside that friction every day. It walks through why matching proof is hard to achieve in a bilateral OTC context, what a complete documentation stack looks like at each stage of the trade lifecycle, where the classic breakdowns happen, and how onchain payment routing changes the evidentiary quality of the settlement record itself.
Why OTC documentation is uniquely difficult
Exchange-traded instruments have a natural advantage: a central venue captures both sides of every trade simultaneously into a shared ledger, so there is no moment when the buyer's record and the seller's record can diverge. In OTC trading, where trades are agreed directly between two traders rather than on an exchange, the confirmation is the safeguard that ensures both sides truly agree to the same legal and economic terms.
Without that exchange-provided single source of truth, the responsibility for building a shared record falls entirely on the two counterparties and their intermediaries. Each OTC trade may have bespoke terms, requiring customised confirmations, and many teams still use spreadsheets or emails, which leaves more room for error. The more customised the deal — a block trade with partial payments, a commodity forward with price adjustment triggers, a private securities transfer with a broker split — the more fields there are for the two sides to record slightly differently.
A potential weakness in OTC practices is the existence of significant backlogs of unsigned master agreements and outstanding confirmations, and the failure to confirm transactions also exacerbates market risks and credit risks in those instances when it allows material errors in a firm's records to go undetected.
The downstream consequences of that divergence compound quickly. If something is missed in the confirmation stage, it does not just stay in the back office — it can affect risk reports, accounting entries, and even compliance checks. A single transposed digit in a wire amount, a settlement date recorded one business day apart, or a fee split noted differently on each side can trigger a reconciliation break that takes days to unwind.
The five layers of a complete OTC documentation stack
Good recordkeeping for an OTC trade is not a single document. It is a stack of five interlocking layers, each serving a different purpose and each needing to match across both counterparties.
Layer 1: The trade capture record
The trade capture record is created at the moment of execution. The trade date is the exact date when the trade agreement took place — it marks when the price and terms were locked in between both parties. At minimum, this record must include:
- Asset or instrument being transferred (ISIN, ticker, contract description, or asset type)
- Notional amount in agreed currency — expressed clearly and without abbreviation
- Agreed price or rate, including any floating-rate convention if applicable
- Buy/sell direction from each counterparty's perspective
- Settlement method (wire, onchain, DvP, or combination)
- Value date or settlement date
Both sides should capture this independently and then compare. Any deviation at this stage — before a single dollar (or cent) moves — is far cheaper to resolve than a deviation discovered at settlement.
Layer 2: The trade confirmation
The confirmation is the executing party's communication of what was traded — a contractual record. Affirmation is the counterparty's operational acceptance that the confirmed details are correct and ready for settlement. Both are necessary to minimise disputes and settlement failures.
A confirmation is the point where both counterparties align on the trade's details. It becomes the agreed, authoritative record of the trade's economics and legalities — the same version everyone works from, because every downstream process relies on both sides having that.
In practice, confirmations range from ISDA-template documents for derivatives to simple signed emails for private asset transfers. The form matters less than the content and the matching. Standard legal agreements and confirmation templates are used to document most OTC transactions. The confirmation should be exchanged promptly: most trades need confirmation within a day, and delays impact settlement and increase risk.
A signed confirmation that both counterparties retain is not a bureaucratic nicety — it is the first piece of proof that would be produced in any dispute, audit, or regulatory review.
Layer 3: The settlement instructions record
Settlement instructions are the operational complement to the confirmation. Where the confirmation records what was agreed, the settlement instructions record how the money will actually move. For a traditional wire-settled OTC trade, this means:
- Bank name and SWIFT/BIC for each receiving account
- Account number and routing details
- Currency and exact amount
- Reference or memo field — populated identically on both sides
- Timestamp of instruction issuance
Every OTC trade should produce a trade confirmation document that a finance team can reconcile against internal records. This should include the executed price, the notional amounts on both sides, settlement timestamps, and any onchain transaction references.
The reference field on a wire is consistently underestimated. When a payment arrives at the receiving bank with a vague memo — "payment per agreement" — the operations team on the receiving side must manually chase the sender to confirm which trade the funds apply to. That chase introduces delay and creates a gap in the matching record. The reference should contain a unique trade identifier that both parties have already agreed on in the confirmation.
Layer 4: The payment proof record
Payment proof is the documentation that funds actually moved in the agreed amount on the agreed date. For a bank wire, this is the MT103 SWIFT message or an equivalent remittance advice. For an onchain transfer, it is the transaction hash and the block it was confirmed in.
This is the layer where the most disputes originate in practice. Common failure modes include fiat wires that miss banking cut-off times, onchain transactions delayed by network congestion, and counterparties that fail to deliver assets after execution. A payment proof record must answer four questions unambiguously: Who sent it? To whom? How much? When?
Layer 5: The reconciliation sign-off
Trade confirmation is the point where both sides of a trade stop and agree on the deal. It is not just about matching numbers — it is about making sure every part of the transaction lines up (price, quantity, settlement date, etc.). This step gives both parties a clear record of what was agreed and helps avoid disputes later.
The reconciliation sign-off is the formal close of the documentation stack. It is a brief record — it can be as simple as a signed email — that both counterparties acknowledge receipt of funds, confirm that the amount matches the agreed notional, and mark the trade as settled. Without this final layer, a trade that has technically settled can still generate disputes weeks later when a back-office team questions whether the payment covered a fee, a partial amount, or the full notional.
The best approach to maintaining good records is to reconcile data regularly, and portfolio reconciliation is the proactive process of ensuring trade details remain aligned between counterparties in order to highlight discrepancies that need to be addressed to prevent disputes.
Where the matching breaks down: three concrete scenarios
Scenario 1: The split-payment confusion
A broker arranges a USD $4,500,000 (AUD ~$6,900,000) private equity block. The seller's internal system records the total as a single payment to the seller. But the deal has a 2% broker commission, meaning the actual wire should split into a payment to the seller and a separate payment to the broker's account. The buyer sends both payments as two separate wires on the same day. The seller's operations team, expecting one wire for the full amount, flags the incoming amount as short. The broker's payment sits unreconciled because no one at the seller's firm was expecting it. Two days of emails follow before the confusion is resolved.
The root problem is not the split itself — it is that the split was agreed verbally and documented differently on each side. The buyer's confirmation referenced the net seller amount; the seller's confirmation referenced the gross amount. Neither matched the actual payments made.
Scenario 2: The timezone settlement date mismatch
Two OTC desk operators agree on a USD $12,000,000 (AUD ~$18,400,000) FX forward with a settlement date of "end of month." One desk is in London; the other is in Sydney. End of month in Sydney is twelve to thirteen hours earlier than end of month in London. One desk sends funds at their end of business; the other does not receive them until their "next business day" by their own internal clock. The receiving desk's system auto-books the settlement as a day late and applies a late-settlement flag. The sending desk has confirmation it was on time. The reconciliation break takes a week to clear because both sides have internally consistent proof that they are correct.
Scenario 3: The multi-party disbursement gap
A real estate syndication closes at USD $8,750,000 (AUD ~$13,400,000). The closing attorney has a distribution schedule:
| Recipient | Share | Amount (USD) |
|---|---|---|
| Seller | 83% | $7,262,500 |
| Senior lender | 10% | $875,000 |
| Co-investor | 5% | $437,500 |
| Arranger | 2% | $175,000 |
| Total | 100% | $8,750,000 |
The buyer sends a single wire to the closing attorney. The attorney then makes four separate outgoing wires over the course of several hours. Each recipient receives their own payment, but there is no single document that records all four disbursements as one coordinated act. The co-investor receives their payment last and, seeing the timestamp, questions whether they received interest on a delay. The arranger's compliance team asks for documentation of the full distribution before they can book the receipt. The closing attorney spends several working days assembling a reconstruction of the transaction from four separate wire advices.
This scenario is precisely where a payment router changes the documentation quality entirely — more on that below.
The structural problem with sequential wire settlement
All three scenarios share the same underlying architecture: the payment is made in sequential steps, each generating its own proof document, with no single record that describes the full transaction as one event.
Traditional settlement frameworks rely on sequenced processes — execution, clearing, and eventual settlement — that are separated in time. When those steps are separated, the proof of each step is also separated. The buyer has proof they sent a wire. The attorney has proof they received it. The four recipients each have proof of their own incoming payment. But no one has a single document that says: at this moment, this amount was received, and simultaneously distributed at these exact shares to these exact parties.
Another factor contributing to failed trades is inefficient manual processes — many firms still rely on outdated systems, which can lead to errors in confirming or matching trades before the settlement date. The assembly of sequential proof documents after the fact is not just administratively burdensome; it is also vulnerable. Any one of the intermediate steps can be questioned, amended, or disputed without the others changing. A revised wire advice from the attorney does not automatically update the buyer's internal ledger.
Differences between counterparties and internal systems can create valuation risk, margin disputes, and reporting issues. The more parties there are in a distribution, the more systems there are, and the more surfaces for divergence to occur.
What onchain routing changes about the proof record
Onchain settlement is the process of transferring final ownership of an asset and its payment on a blockchain, where the ledger update itself is the settlement — replacing the multi-day, intermediary-heavy process of moving money and assets with a single blockchain transaction that transfers value and records final ownership at the same time.
The evidentiary implication of this is significant for OTC settlement professionals. Once the block is finalized, the transfer is done, and no separate reconciliation is required to prove who owns what. Every party to the transaction can independently query the same public ledger and see the same event record without needing to compare PDF attachments or cross-reference email threads.
Finality is the guarantee that past transactions in a blockchain network cannot be altered, reversed, or canceled. Its primary purpose is to provide absolute certainty to users, merchants, and smart contracts that a transaction is permanently settled and digital assets are secure. For settlement documentation purposes, this means the payment proof record at Layer 4 is not a document someone produced — it is an entry in a shared, append-only ledger that neither party can unilaterally amend.
This is where shaka.deal addresses the structural problem described in the multi-party disbursement scenario directly. Shaka.deal is an onchain payment router on Ethereum. A deal is configured with a total amount and a set of preset shares — seller percentage, broker percentage, lender percentage, arranger percentage — and when the buyer's payment arrives, the router distributes the full amount simultaneously to every recipient in a single transaction. One incoming payment, preset shares, simultaneous payout, final settlement.
The proof record that results is qualitatively different from four sequential wire confirmations. Every party receives not just evidence of their own incoming payment but a pointer to a single transaction hash that shows the entire distribution event: who received what, in what proportions, at what precise timestamp, in a record that is publicly verifiable on Ethereum and that no one — not the buyer, not the broker, not the closing attorney — can retroactively alter.
Onchain settlement makes the blockchain ledger the authoritative record of that change, rather than a downstream copy of it. That distinction matters enormously for post-trade documentation. A bank wire confirmation is a copy of a record that lives in a private banking system. An Ethereum transaction is a primary record that lives in a shared, decentralised ledger. The closing attorney who previously spent days assembling four wire advices into a coherent reconstruction now has a single transaction hash to attach to the closing file.
Because shaka.deal is non-custodial, it routes funds rather than holding them. The router never takes custody of the payment; it simply enforces the distribution logic in a single onchain execution. This means the settlement agent retains their role as the coordinator of deal terms — the party who sets the shares, approves the configuration, and confirms the payment destination addresses — while the routing itself is handled with the precision and permanence of a smart contract.
Building the matching documentation package in practice
For a settlement professional running an OTC trade today, whether or not the payment leg is onchain, the goal is to ensure both parties can produce an identical documentation package at every stage. Here is a practical checklist.
At execution:
- Agree on a unique trade ID and use it in every subsequent document
- Record asset, notional, price, direction, currency, settlement date (with timezone), and payment method
- Exchange and countersign the confirmation within 24 hours
At instruction issuance:
- Confirm wire details or wallet addresses in writing before funds move
- Include the trade ID in the reference field of every payment instruction
- For multi-party distributions, document the full distribution schedule — not just your own share — so every recipient understands the full transaction
At settlement:
- Obtain and retain the payment proof that corresponds to the agreed amount
- For onchain settlements, record the transaction hash, block number, and timestamp
- Confirm receipt with the counterparty in writing on the same day funds arrive
Post-settlement:
- Issue a reconciliation sign-off that references the trade ID, the confirmed amount, the payment reference, and the settlement date
- File all five layers — capture record, confirmation, settlement instructions, payment proof, reconciliation sign-off — together under the same trade ID
Keep everything on record. Store confirmation details in one place. If there is an audit or dispute later, you will need a clear trail.
The audit trail question
Settlement documentation is not only for the parties immediately involved. It is also for every regulator, auditor, counterparty counsel, or compliance reviewer who may examine the transaction months or years later. The quality of the audit trail determines how quickly those reviews resolve.
Settlement finality means the transfer is irreversible and both parties have received what was agreed. For onchain transfers, finality is typically confirmed after a defined number of block confirmations on the relevant blockchain network, usually within minutes. An audit trail built on onchain payment records has a property that wire-based trails do not: the timestamps are set by the network, not by the sender, and cannot be retroactively adjusted. When a compliance reviewer asks "was this payment made before or after the close of business on that date," the answer comes from the blockchain's block timestamp — a consensus-determined, globally observable value — rather than from a PDF that a counterparty's treasury team prepared and could theoretically revise.
For OTC desks handling significant transaction volumes, this changes the economics of record management. OTC gives parties a single firm price for the full conversion, clean documentation per trade, and settlement directly to a custody solution or bank account — keeping the transaction out of the exchange environment and producing a record that is useful to an accounting team. When that record is anchored onchain, the accounting team does not need to cross-reference email chains and banking portals; they query the ledger.
A note on the settlement agent's role in onchain transactions
Nothing in an onchain payment workflow diminishes the role of the settlement agent, closing attorney, or OTC desk operator. Those professionals are not in the business of moving money for its own sake — they are in the business of ensuring that the correct money moves to the correct parties on the correct terms. The router enforces distribution mechanics; the settlement professional defines those mechanics, ensures the legal terms behind them are sound, and coordinates the deal from execution through close.
What changes is the quality of the proof that professional can give their client. Instead of assembling a reconstruction from multiple banking portals and email archives, the settlement professional can attach a single transaction hash to the closing file and say: this is when it settled, this is what each party received, and this record will remain unchanged for as long as Ethereum exists.
Settlement plays a key role in reducing counterparty risk and ensuring payment finality. Once a transaction is settled, ownership is transferred and the transaction is irreversible. This eliminates ambiguity and reinforces trust between parties. That trust, extended to every party in a multi-counterparty OTC deal, is the outcome that good documentation is meant to produce. Onchain routing makes it automatic.
Closing: the discipline that eliminates the dispute
The matching proof problem in OTC settlement is not a technology problem at its root — it is a discipline problem. Most disputes originate not from bad faith but from the simple fact that two parties, each doing their jobs diligently, captured the same trade in ways that diverge slightly at execution and then diverge further at each subsequent step.
The discipline required is straightforward: agree on a unique trade identifier before anything else, use it in every document, exchange confirmations promptly, specify every payment reference field, and close the loop with a signed reconciliation at settlement. Most experienced settlement professionals know this already. The gap is implementation under the pressure of high deal flow and the inconvenience of coordinating across multiple counterparties and time zones.
Onchain routing tools like shaka.deal do not remove the discipline requirement — they make it easier to meet, and they elevate the evidentiary quality of the result. When a single transaction handles the split, instant, and certain distribution of a deal's full proceeds, both sides of the trade have a matching proof record that requires no reconstruction, no assembly, and no trust in the other party's filing system. The ledger holds it. That is not a small improvement. In high-value OTC transactions where a single disputed settlement can tie up legal resources for months, it is the difference between a closed file and an open one.
