# How to settle an OTC trade across three or more parties

A practical guide to the mechanics, risks, and coordination challenges of multi-party OTC settlement, and how onchain payment routing delivers simultaneous, final distribution in one transaction.

---


Most OTC settlement literature is written for a world of two: a buyer, a seller, a wire transfer, and a confirmation. In practice, the trades that demand the most careful operational thinking are the ones involving three, four, or five parties — each with a legitimate, documented claim on proceeds, each expecting to receive their share on the same day, and each with their own banking instructions, their own counsel, and their own version of what "settled" means.

These are not edge cases. Syndicated commodity trades, multi-tranche real estate closings, structured debt placements, and large digital asset OTC transactions all involve payment architectures that go well beyond the bilateral model. OTC trade settlements can be more complex than exchange-traded settlements due to customized contracts and the need for bilateral coordination — and when you multiply that coordination across three or more parties, the operational surface area grows sharply.

This article is written for the professionals who manage that surface area: settlement agents, OTC desk operators, closing attorneys, brokers, and the treasury teams who sit at the center of complex closings. The goal is to map the problem precisely and then show how onchain payment routing, specifically the architecture behind [shaka.deal](https://shaka.deal), resolves the core mechanical challenge in a way that sequential wire transfers simply cannot.

<figure class="keyfacts">
<div class="keyfacts-grid">
<div><b>$8,400,000</b><span>one incoming payment in the worked example of this article</span></div>
<div><b>4</b><span>destinations paid out of that single payment, each at its preset share</span></div>
<div><b>1</b><span>onchain transaction and one hash to reconcile, instead of four outgoing wires</span></div>
</div>
<p class="fig-src">Worked example of a commodity closing detailed below: a Seller, a Facilitating Desk, a Regional Broker and a documentation service paid from one buyer payment.</p>
</figure>

## Why Two-Party Settlement Logic Fails at Three Parties

To understand the multi-party settlement problem, it helps to start with why the two-party model is already imperfect — and then observe how its weaknesses amplify with each additional party.

Pre-settlement risk arises between trade execution and final settlement. During this window, one party can default before the exchange of assets is complete. In a simple bilateral trade, that risk is uncomfortable but bounded: you are exposed to one counterparty, and the exposure lasts for however long the settlement window runs. If you agree a large trade against a liquidity provider and that provider becomes insolvent before settlement, you are exposed to the full notional value of the trade. The longer the settlement window, the larger the potential exposure.

Now introduce a third party. Say the trade involves a selling entity, a buying entity, and a referral broker who has a contractual right to a commission out of the proceeds. The settlement agent must now decide: does the seller receive the full gross amount and pay the broker from their own account? Does the buyer wire separately to the broker? Does the settlement agent distribute from a pooled account in sequence? Each intermediary in OTC trading may have its own settlement process. There is no standard answer, and the operational choices made in the absence of one carry real consequences.

Add a fourth party — a co-broker, a sub-agent, a consultant with a documented success fee — and the sequential payment model begins to buckle under its own weight.

Every open settlement day is a day the counterparty could fail to perform. The longer the window, the larger the exposure. When you are making three or four separate wires across two or three business days to satisfy all the parties in a deal, you are not settling one trade — you are running three or four overlapping pre-settlement risk windows simultaneously, each one potentially defeating the others.

## The Anatomy of a Three-Party OTC Closing

Consider a concrete scenario that settlement professionals encounter regularly.

A commodity trading firm — call it the Principal Buyer — agrees to purchase a large block of refined metals from a Seller through a Facilitating Desk. The Facilitating Desk sourced the transaction, structured the terms, and is contractually owed a margin of 1.2% of the gross transaction value. The Seller has a contractual arrangement with a regional broker who introduced the principal and is owed a finder's fee equivalent to 0.4% of the total value. The closing attorney is holding a retainer but also has a small disbursement to make to a title or documentation service.

In USD terms, the transaction is $8,400,000 (approximately AUD 12,900,000 at current rates). The simplified breakdown might look like this:

| Destination | Basis | Amount |
| --- | --- | --- |
| Seller net proceeds | Gross value less the three amounts below | $8,247,200 |
| Facilitating Desk margin | 1.2% of the gross transaction value | $100,800 |
| Regional broker fee | 0.4% of the total value | $33,600 |
| Documentation/service disbursement | Flat amount | $18,400 |
| **Total** | **One incoming payment** | **$8,400,000** |

Four destinations. One incoming payment. A deal that is legally complete the moment the buyer's funds clear.

Under a conventional wire-based settlement process, the sequence typically works as follows:

1. The Principal Buyer wires $8,400,000 to the settlement account.
2. The settlement agent confirms receipt and begins the disbursement process.
3. Wire one goes out to the Seller — confirmed same-day if the agent is efficient, but potentially T+1 depending on the bank's cut-off.
4. Wire two goes out to the Facilitating Desk — same-day or next-day.
5. Wire three goes out to the Regional Broker — potentially delayed if the banking instructions require an intermediary bank or cross-border routing.
6. The documentation disbursement is processed last.

The Seller cannot confirm their receivable until wire one settles. The Facilitating Desk is watching their account. The Regional Broker, often the most lightly resourced party, is following up by email. The closing attorney is managing four separate confirmations across potentially three banking relationships and two or three time zones.

Disputed settlements, documentation gaps, and reconciliation failures carry their own cost in management time, legal exposure, and counterparty relationship damage. In the scenario above, every hour the Seller's funds sit in transit is an hour their working capital is committed to this deal rather than the next. Every day the broker's fee is unresolved is another day of follow-up calls that consume the settlement agent's bandwidth.

## Where the Coordination Risk Actually Lives

Settlement professionals understand this instinctively, but it is worth naming the risk categories explicitly so they can be addressed in a structured way.

**Sequential settlement risk.** When distributions are made in order, later recipients are implicitly subordinated to earlier ones — not by contract, but by operational reality. If the settlement account encounters a technical hold, a compliance flag, or a bank-level delay on wire two, parties three and four are exposed to the consequences of a problem that is not theirs. If incoming payments are delayed, outgoing obligations do not pause. Firms carry the timing gap on their own liquidity.

**Confirmation asymmetry.** In a sequential disbursement, the Seller has confirmed funds before the broker or the desk. If there is a subsequent dispute about the deal terms — the contract amount, the applicable percentage, the currency of payment — the Seller's receipt is already complete and cannot be revisited. The settlement agent is then left managing a partial dispute without the ability to hold any remaining amount as leverage, because the remaining amount may already be disbursed.

**Reconciliation overhead.** Trade details are matched internally and externally to ensure accuracy. Any breaks are investigated and resolved. In a four-wire settlement, the settlement agent must reconcile four separate outgoing transactions against the one incoming transaction, track four separate acknowledgment timestamps, and maintain four separate records for any subsequent audit or dispute. Each wire is its own paper trail, and inconsistencies between them — a slightly incorrect reference number, a mismatched amount due to a rounding difference, a bank fee withheld at the correspondent level — create reconciliation breaks that consume time and introduce legal uncertainty.

**The float problem.** Between the time the incoming wire clears and the time all outgoing wires are confirmed, the settlement agent holds the gross amount minus whatever has already been disbursed. This creates an inadvertent custodial position that may have regulatory implications, creates liability exposure, and puts the agent in an awkward position if any party questions the timing or sequence of distributions.

## The Case for Simultaneous Distribution

The alternative to sequential settlement is simultaneous distribution — a single incoming payment that routes to all designated parties at their preset shares in one action, with the same timestamp and the same finality.

Traditional settlement frameworks rely on sequenced processes — execution, clearing, and eventual settlement — that are separated in time. The onchain model collapses that sequence. On a blockchain, settlement is immediate and probabilistically final. When a transaction is confirmed onchain, the ledger updates universally for all participants.

The implication for multi-party OTC settlement is significant. Rather than four outgoing wires with four separate confirmation windows, the entire distribution can be encoded as a single transaction. The incoming amount arrives. The routing logic — preset at the time the deal is agreed, with each party's wallet address and percentage share embedded in the contract — executes immediately. There is no separation between the message and the movement of value.

Every party receives their share in the same block. The Seller does not wait for the broker's wire to clear before they know their funds are final. The broker does not depend on the settlement agent manually initiating their disbursement after all prior distributions are confirmed. The Facilitating Desk does not need to follow up.

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. Onchain transactions are permanent and cannot be recalled or reversed — this is the property that makes them genuinely final rather than provisionally final the way a bank wire can be.

## How Shaka.deal Handles Multi-Party Routing

This is exactly the problem that [shaka.deal](https://shaka.deal) is built to solve. Shaka.deal is a B2B onchain payment router on Ethereum. It accepts one incoming payment and distributes it instantly to every party at their preset shares, in one transaction, with finality. It is non-custodial: it routes, it never holds funds.

The workflow for a multi-party OTC closing using shaka.deal looks like this:

**Before the trade executes:** The settlement agent, broker, or deal coordinator creates a deal on shaka.deal. Each party's receiving address and their percentage share of the total are specified and agreed upon by all parties. This is the pre-agreed distribution table, encoded onchain. Nothing moves yet — the routing contract simply holds the agreed parameters.

**At closing:** The Principal Buyer sends the agreed total — $8,400,000 (approx. AUD 12,900,000) — to the deal's routing address in a single transaction. The routing logic executes in the same block. The Seller receives $8,247,200. The Facilitating Desk receives $100,800. The Regional Broker receives $33,600. The documentation service receives $18,400. All in the same transaction. All with the same onchain timestamp. All final.

There is no sequential exposure window. There is no float. There is no reconciliation problem between outgoing wires, because there is only one transaction to reconcile. Every party can verify their receipt by examining the same block on Ethereum — the record is public, permanent, and identical for all participants.

The settlement agent's role does not shrink; it changes in character. Rather than spending the back half of a closing day processing four outgoing wires and tracking four separate acknowledgments, the agent's post-close work becomes verification: confirm the single routing transaction hash, confirm the correct amounts arrived at each address, file the record. The legal and structural work — the contract, the allocation table, the deal terms — remains the agent's domain. The execution becomes a single mechanical step.

## A More Complex Scenario: Five Parties, Cross-Jurisdictional

The benefits scale nonlinearly with the number of parties. Consider a slightly more complex scenario: a digital asset OTC block trade involving a Buyer, a Seller, two broker-dealers who split the deal's facilitation fee, and a compliance and reporting service that is paid a flat amount out of proceeds.

In conventional settlement, this is five separate payment instructions. The compliance service, being paid a flat fee rather than a percentage, needs to be handled as a special case. One of the broker-dealers is in a different jurisdiction, which means their wire may require an intermediary bank, adding a correspondent leg and a potential for a fee deduction at the intermediary level. The second broker-dealer and the compliance service may be in yet another jurisdiction.

The settlement agent is now coordinating four disbursements, potentially across three correspondent banking relationships, with the risk that a fee deducted by a correspondent bank means a party receives slightly less than their contractual entitlement — triggering a dispute, a top-up wire, and a reconciliation cycle.

On shaka.deal, the four recipients are specified upfront. The flat fee for the compliance service is expressed as a fixed address with a computed share of the total. The two broker-dealers each have their own address and their own percentage. The routing executes in one transaction: four recipients, one block, simultaneous, final. The correspondent bank problem is a characteristic of legacy rail infrastructure and does not apply. Every party receives exactly what the distribution table specifies, with no intermediate deductions and no sequencing risk.

Regulated digital asset rails, including stablecoin settlement infrastructure, can compress settlement timelines from T+2 or T+3 to near-instant finality. This directly reduces the counterparty exposure window, frees working capital faster, and provides an auditable transaction record for compliance purposes.

## Setting Up the Distribution Table: Practical Mechanics

The distribution table — the list of parties, addresses, and percentage shares — is the foundational document of a multi-party closing on shaka.deal. Getting it right before the closing is the operational equivalent of ensuring all wire instructions are confirmed before a conventional settlement.

A few practical considerations:

**Percentage precision.** Shares should be expressed with sufficient decimal precision to avoid rounding differences that, at large notional values, become material. A 1.2% share on an $8.4m transaction is $100,800 — express this precisely, not as a rounded approximation. Shaka.deal's routing contract enforces the exact shares as specified.

**Address verification.** Each party's receiving address should be independently verified before the deal is created. The settlement agent should treat address confirmation with the same care as confirming wire instructions: obtain the address from the party directly, verify it on a second channel, and confirm the network (Ethereum mainnet).

<aside class="callout">
<span class="callout-label">Before the deal is created</span>
<h4>A wrong address is as final as a right one</h4>
<p>An address error in the distribution table will route funds to the wrong destination with the same finality as a correctly routed payment.</p>
</aside>

**Total must equal 100%.** The sum of all preset shares must cover the full incoming amount. Partial routing — where some portion of the total is left unallocated — is an error state. The deal structure should specify 100% of the incoming amount across all recipients before the closing initiates.

**Timing the payment.** The buyer should be clearly instructed that the routing address on shaka.deal is the sole payment destination. Sending to an individual party's address instead of the deal routing address — an easy error in a multi-party context — bypasses the distribution logic. The deal's routing address should be treated exactly as a settlement account number in conventional practice: the one destination to which the full gross amount is sent.

## The Role of the Settlement Professional in an Onchain Close

The introduction of onchain routing into a multi-party OTC closing does not reduce the need for experienced settlement professionals. It redistributes where their expertise is applied.

The legal work — drafting the distribution agreement, ensuring each party's allocation is contractually documented, handling representations and warranties — remains unchanged. Standard legal agreements and confirmation templates are used to document most transactions. The agreement that specifies what each party is owed is still a legal instrument, negotiated, signed, and filed.

The pre-close coordination — confirming that all parties have active, verified receiving addresses, that the distribution table is agreed upon and signed off, that the buyer has been instructed correctly — becomes the settlement agent's primary operational task. This is analogous to the pre-wire preparation in a conventional closing, but it happens once rather than being replicated for each outgoing wire.

The post-close verification is simpler and faster. Rather than waiting for four wire confirmations to arrive from four different banking relationships, the agent provides one transaction hash. Every party can independently verify their receipt on the Ethereum block explorer. The record is available immediately, requires no follow-up from the agent, and is identical for all parties regardless of their jurisdiction.

The settlement professional becomes the architect of the distribution table and the guarantor of its accuracy, rather than the operator of sequential wire disbursements. That is a more valuable role, not a diminished one.

## When Sequential Wires Are Unavoidable — and How to Contain the Risk

There are circumstances in which onchain simultaneous distribution is not available for all legs of a transaction. A counterparty may require fiat settlement for their portion. Regulatory constraints in a particular jurisdiction may require funds to pass through a licensed custodian or payment institution before reaching the end recipient. One party may be unwilling or unable to receive stablecoin proceeds.

In these cases, the settlement professional should aim to isolate the sequential leg and treat it as a separate, bounded risk — rather than allowing it to create exposure across the entire distribution. A practical approach: route onchain to all parties who can receive onchain, and handle the fiat disbursement as a separate instruction with its own confirmation workflow. This limits the sequential exposure to the fiat leg only, rather than allowing a single delayed wire to hold up confirmation for all parties.

Regulated OTC desks reduce risk through several mechanisms: verified counterparty onboarding, pre-funded account structures, and, in some cases, simultaneous or atomic settlement, where both sides of the trade settle at the same time. The goal, in any multi-party closing, is to push as much of the settlement as possible toward simultaneity, and to structure any remaining sequential elements so that their delay window is minimized and their exposure is contained.

## Documentation and Audit Trail Considerations

One of the less-discussed advantages of onchain settlement for multi-party trades is the quality and completeness of the audit trail it generates automatically.

In a conventional multi-party closing, the settlement record is assembled from multiple sources: the incoming wire confirmation, four outgoing wire receipts, SWIFT messages or bank acknowledgments, email confirmations from each party that funds were received, and the settlement statement that the agent prepares reconciling all of these. Each of these documents is produced by a different system, in a different format, at a different time.

Onchain, the single transaction hash contains the complete record. The input amount, the output amounts, the destination addresses, the timestamp, and the block number are all verifiable by any party with the hash. There is no possibility that the settlement agent's record and the broker's record reflect different timestamps, because both are reading from the same immutable ledger.

For deals that require post-close reporting — regulatory filings, fund administration records, tax documentation — the onchain record is a single source of truth. It does not need to be assembled from multiple banking statements. It does not require confirmation from each counterparty that funds were received. It is available immediately after the transaction is confirmed, and it cannot be altered.

## Structuring the Pre-Deal Conversation

Getting to a clean onchain multi-party closing requires that all parties agree on the distribution table before the buyer initiates payment. This is the conversation that the settlement professional needs to lead, and it is worth being deliberate about how it is framed.

The agenda for the pre-close alignment call in a multi-party OTC deal should cover:

<figure class="fig">
<figcaption><b>Pre-close alignment call</b><span>Agenda for a multi-party OTC deal settled through a routing address</span></figcaption>
<ol class="steps">
<li><b>Distribution table confirmation</b>Each party confirms their share percentage and their receiving address. The settlement agent reads back each entry. Discrepancies are resolved before the deal is created.</li>
<li><b>Gross amount and payment instruction</b>The total amount the buyer will send is confirmed. The routing address on shaka.deal is communicated to the buyer as the sole payment destination. The buyer confirms they will send the full gross amount to this address.</li>
<li><b>Timeline</b>The parties agree on the expected payment time. Since settlement is simultaneous on confirmation of the routing transaction, there is no need to coordinate separate disbursement timing — all parties will receive at the same moment.</li>
<li><b>Contingency</b>If the incoming payment is incorrect in amount, or if it is sent to the wrong address, the parties agree in advance on the correction procedure. Onchain transactions are permanent, so an incorrect amount requires a separate corrective transaction rather than a recall — all parties should understand this before the closing.</li>
<li><b>Record-keeping</b>The settlement agent will distribute the transaction hash immediately upon confirmation, along with the block explorer link that allows each party to independently verify their receipt.</li>
</ol>
</figure>

This conversation takes no longer than the pre-wire confirmation call in a conventional closing. Its output is cleaner, because it produces a single action — the buyer's payment to the routing address — rather than a cascade of sequential wires that each require their own tracking and follow-up.

## Closing Thoughts

Multi-party OTC settlement is not a niche operational problem. It is the standard operating environment for any OTC desk, broker, or settlement agent working on transactions with structured distributions — and the list of deal types that involve structured distributions is long: commodity trades with brokerage layers, real estate closings with multiple fee parties, digital asset block trades with split facilitation, private placements with placement agent and sub-agent arrangements.

Efficient settlement is crucial to reduce risks such as default or errors, and to ensure timely transfer of assets. The conventional response to multi-party settlement complexity has been to add more process: more wire instructions, more confirmation calls, more reconciliation steps, more waiting. This scales poorly.

The onchain model — one incoming payment, preset shares, simultaneous payout, permanent record — is not a simplification of the settlement professional's role. It is a better tool for executing the distributions that their expertise has already designed. The legal work, the contractual clarity, the pre-close coordination: all of that remains. What changes is the execution layer. Instead of four wires and four confirmation windows, there is one transaction and one hash.

[Shaka.deal](https://shaka.deal) is built specifically for this: B2B payment routing on Ethereum that splits and distributes in a single onchain transaction, with no custodial holding period, no sequential exposure, and finality that every party can verify independently the moment the block is confirmed. For settlement professionals managing multi-party OTC closes, that is not a feature — it is the entire point.