In this article
Every OTC desk operator, settlement agent, and institutional broker has lived through a version of the same problem: a large block trade closes, funds land in one account, and then someone has to break that single incoming payment into its rightful pieces. The seller's net proceeds go one way. The desk's spread goes another. And somewhere in the mix — often as an afterthought, sometimes as a source of genuine friction — is the introducer's fee.
This article works through exactly that scenario: what the introducer's role is, why their fee creates a specific settlement complexity that standard bilateral transfer protocols handle poorly, what the traditional workarounds look like and where they fail, and how onchain payment routing can collapse the whole problem into a single, atomic, pre-authorised settlement event.
What an introducer actually does in an OTC trade
The term "introducer" is used loosely in markets, but in the OTC context it has a reasonably precise meaning. An introducer is a licensed professional — a broker, a capital markets advisory firm, a prime brokerage relationship manager, or a specialist intermediary — who originates the relationship between counterparties that would not otherwise have found each other. They do not execute the trade. They do not hold assets. They do not provide the quote. A principal OTC desk takes the other side of a trade itself, quoting a fixed price and managing its own risk; an agency desk acts as a broker, finding a third-party counterparty and charging a commission. The introducer sits upstream of both models: they created the conditions under which either desk type could function at all.
In a typical large-block digital asset or structured OTC transaction, the introducer's fee is agreed before execution and documented in the term sheet or side letter alongside the main trade economics. It is not a discretionary bonus paid later; it is a contractual obligation that crystallises at the moment of settlement. The question is never whether to pay it — that is settled by the agreement — but how to pay it cleanly, provably, and simultaneously with everything else.
The anatomy of a multi-party OTC settlement
Before addressing the introducer fee specifically, it helps to map the full settlement structure. In a straightforward OTC block trade with an introducer in the deal chain, the parties typically are:
- The buyer — the institution or high-net-worth counterparty acquiring the asset.
- The seller — the holder of the asset being sold, who receives net proceeds.
- The OTC desk — the entity quoting the price, absorbing execution risk, and controlling the settlement workflow.
- The settlement agent — sometimes a standalone professional, sometimes a function performed by the OTC desk itself, responsible for verifying that all legs are in place before releasing funds.
- The introducer — the originating broker or relationship party, entitled to a pre-agreed fee on successful close.
An OTC trade often involves several parties. In the simple two-party model, settlement is already operationally demanding. The settlement workflow is where institutional OTC differs most from standard exchange execution. In a prefunded model, the client may need to move assets to an exchange, desk, or counterparty before execution, which introduces exposure to the venue or trading counterparty while the assets are outside the client's preferred custody framework.
When you add an introducer to that structure, you have not merely added one more payee. You have added one more dependency, one more confirmation step, one more potential point of failure — unless the settlement design anticipates all three payouts from the start.
How the conventional approach handles this — and why it strains
The standard approach in bilateral OTC settlement is sequential: the buyer sends funds to the OTC desk or a nominated account, the desk confirms receipt, the seller is paid net proceeds, and then — separately, sometimes hours or days later — the introducer is paid from the desk's own account.
Problems typically arise in the same places: manual data transfer, inconsistent control mechanisms, and post-trade work that occurs in chat rooms, spreadsheets, and people's heads.
The introducer payment in particular tends to fall into this grey zone. Here is why:
Timing mismatch. The desk's priority at settlement is completing the main trade legs — confirming the buyer's funds are clear and releasing the seller's proceeds. The introducer fee is real money but it lives in the desk's operational queue, not in the primary settlement instruction. It gets processed after everything else is confirmed, sometimes well after.
No contemporaneous proof. When all three payments happen sequentially across different banking rails and different time windows, there is no single moment of proof that the introducer received their fee as part of the same settlement event. This matters for audit trails, for compliance records, and for the introducer's own reporting obligations.
Counterparty risk on the introducer's fee. In a sequential model, the introducer's fee depends on the desk having both the intent and the operational capacity to execute a separate outbound wire after the main trade clears. If the desk has a funding or operational disruption between main settlement and the introducer payment — even a temporary one — the introducer bears that risk. One side delivers first, the other settles later, and both parties carry risk during the process. If something goes wrong between confirmation and finality, unwinding the transaction is slow and expensive.
Reconciliation complexity. The moment you introduce additional parties, you add serious layers of complexity, including additional reconciliation effort and tighter operational controls around funding windows, cutoffs, and settlement reversals. Three payees across three separate transactions means three reference numbers, three confirmations, and three entries to reconcile against a single trade ticket.
The "did you get paid?" conversation. Every settlement professional knows this one. The introducer, not having received a simultaneous confirmation, follows up with the desk. The desk, in the middle of the next trade, sends a manual confirmation message. This is administrative noise, but it accumulates — and in high-volume environments it becomes a real operational cost.
Designing the settlement correctly from the term sheet forward
The clean solution begins not at settlement but at documentation. By the time funds move, the allocation should already be unambiguous. This means the term sheet or settlement memorandum should specify:
- The gross amount the buyer will send, expressed as a single total figure.
- The seller's net proceeds as a fixed amount or as a percentage of gross.
- The desk's spread or service fee as a fixed amount or percentage.
- The introducer's fee as a fixed amount or percentage of the gross payment.
- All wallet or account addresses for every payee, confirmed and verified before execution date.
When these five items are documented in writing before settlement begins, the settlement instruction becomes mechanical. There is nothing to negotiate at the moment of payment. Every party has agreed to the numbers. The only question is execution.
Parties agree on price method (fixed, formula, VWAP), notional, settlement currency, collateral, and dates. Adding the introducer's fee to that pre-agreed list of parameters is not a departure from normal practice — it is an extension of the same discipline that already governs OTC deal terms.
One useful structural convention: express all fees and proceeds as percentages of a single gross notional rather than as residual calculations. If the buyer sends $2,000,000 USD (approximately AUD 3,060,000 at a working rate), and the seller is entitled to 95.5%, the desk retains 2.5%, and the introducer receives 2%, those percentages add to 100%. There is no rounding error, no residual ambiguity, no "who keeps the leftover basis points" conversation.
A worked scenario: the three-way split
Let the trade be this: a single buyer wires $2,000,000 USD (approximately AUD 3,060,000) in USDC on Ethereum to initiate settlement of a large digital asset block. The agreed allocation is:
| Payee | Share of gross | Amount |
|---|---|---|
| Seller net proceeds | 95.5% | $1,910,000 |
| OTC desk fee | 2.5% | $50,000 |
| Introducer fee | 2.0% | $40,000 |
| Total | 100% | $2,000,000 |
In the conventional sequential model, the buyer sends $2,000,000 to the desk's nominated wallet. The desk confirms receipt, releases $1,910,000 to the seller. Settlement for the main trade is considered done. The desk then initiates a separate $40,000 transfer to the introducer, typically on the same day, sometimes the next business day.
The problem: at the moment the desk confirms to all parties that "settlement is complete," the introducer has not actually been paid. The seller has. The desk has retained its fee implicitly. But the introducer is in a different state to every other party. Legally the fee is owed. Operationally it has not moved.
If any participant in this chain — a lawyer, an auditor, a compliance officer — asks "confirm that all parties were paid simultaneously at settlement," the honest answer is: they were not.
The alternative: route all three legs in a single transaction. The buyer sends $2,000,000 to a payment routing address. That routing logic, pre-configured with the exact split, disburses $1,910,000 to the seller's wallet, $50,000 to the desk's wallet, and $40,000 to the introducer's wallet — in the same block, with a single transaction hash that references all three outbound legs. Settlement is genuinely simultaneous. Every party receives their funds in the same moment. The transaction hash is the settlement receipt for all three.
This is precisely the architecture that shaka.deal is built for. Stablecoin settlement executes directly on a decentralized blockchain network. The blockchain serves as the underlying settlement layer. It acts as both the execution environment and the immutable ledger of record. Shaka.deal takes that underlying capability and makes it directly accessible to OTC settlement professionals: define the parties, define the shares, receive one inbound payment, and route simultaneously to all destinations.
The specific properties that matter for OTC settlement professionals
When an OTC desk, settlement agent, or closing attorney is evaluating whether onchain routing fits their workflow, the properties that matter most are: certainty of execution, finality, auditability, and custody behaviour. Address each in turn.
Certainty of execution. 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. Shaka.deal extends this to the three-party (or more) case: the split logic is encoded before the transaction is submitted. Once the buyer sends the gross amount to the routing address, the split executes as defined. There is no manual step between receipt and disbursement.
Finality. Onchain payments in USDC on Ethereum reach finality rapidly after confirmation. Once confirmed, the payment cannot be reversed. This is different from a wire transfer, which can be recalled, or a card payment (which in consumer contexts can be disputed). In an OTC settlement context, finality is not a risk — it is the entire point. Every party, including the introducer, knows that their funds are theirs.
Auditability. Every leg of the split is recorded on the Ethereum ledger. The transaction hash is permanent, timestamped, and independently verifiable. A settlement agent can present a single hash to an auditor and that hash contains the complete record of who received what and when. No secondary confirmations, no bank statement cross-referencing, no follow-up communication threads. By using a unified onchain ledger, organisations eliminate the need to reconcile separate, siloed databases.
Custody behaviour. Shaka.deal is non-custodial. It routes, it never holds. Funds pass through the routing logic and reach the designated wallets without the router accumulating a balance. This is a material point for OTC professionals: the routing layer has no exposure to the funds, which means no counterparty risk at the routing layer itself.
What the introducer actually needs from this arrangement
It is worth spending a moment on the introducer's perspective, because their needs are often under-specified in how settlement professionals think about the problem.
An introducer needs three things at settlement:
- Payment on time — ideally simultaneous with the rest of the trade.
- Proof of payment — something they can take to their own compliance team, their accountant, and potentially their regulator to demonstrate the fee was received on the specified date for the specified transaction.
- No dependency on a downstream manual action — the introducer should not have to chase the desk, follow up via email, or wait for an internal accounts payable cycle.
Pricing should be transparent: you should know whether you are looking at a spread embedded in the rate, a fixed fee, or a combination of both. This principle applies equally to the introducer's own economics. When the fee is defined at the outset and the settlement instruction encodes it, there is nothing hidden and nothing to negotiate after the fact.
Onchain routing with pre-set shares satisfies all three requirements. The introducer receives payment in the same block as the seller. They have the transaction hash immediately. And the payment is not contingent on any action from the desk after the trade closes.
A second scenario: tiered introducer arrangements
Some OTC transactions involve more than one introducer — a primary broker who brought the buyer, and a secondary introducer who provided the relationship with the seller. In these arrangements, the economics might look like this on a $5,000,000 USD (approximately AUD 7,650,000) gross trade:
| Payee | Share of gross | Amount |
|---|---|---|
| Seller net proceeds | 94.5% | $4,725,000 |
| OTC desk fee | 2.0% | $100,000 |
| Primary introducer fee | 2.0% | $100,000 |
| Secondary introducer fee | 1.5% | $75,000 |
| Total | 100% | $5,000,000 |
In a sequential wire model, this creates four separate outbound transactions from a single inbound receipt. The operational overhead is significant. Splitting the order across venues converts one problem into several — partial fills, several counterparties, several settlement legs, and a reconciliation exercise afterwards. The same logic applies to fee disbursement: four sequential manual wires is four opportunities for error, delay, or failed confirmation.
With a multi-party routing design, all four payees are defined in the routing configuration before the buyer's funds arrive. When the $5,000,000 hits the routing address, all four disbursements execute in the same transaction. The total adds to 100%. No residual. No second payment run. No "we'll sort the sub-agents later."
This design scales linearly. Whether there are two payees or five, the additional complexity is absorbed at the configuration stage — where it should be — not at the settlement stage, where it cannot be.
Integration with existing OTC desk operations
OTC desks and their settlement agents do not need to rebuild their workflows around onchain routing. The documentation, the negotiation, the trade confirmation, the pre-settlement verification — all of that continues to happen in existing systems and channels. Parties involved, such as institutional investors, hedge funds, or banks, negotiate the terms of the trade; this negotiation is typically facilitated through electronic trading platforms or over-the-phone communication. None of that changes.
What changes is the final step: instead of the desk issuing multiple outbound wires, the desk configures a routing address with the agreed split, and the buyer sends the gross amount to that address. Settlement then executes automatically, simultaneously, and permanently.
The configuration step is the critical one. Before the buyer transfers funds, the desk should share the routing configuration with all parties for verification: confirm that the seller's address is correct, confirm the desk's address, confirm the introducer's address. Standard legal agreements and confirmation templates are used to document most transactions. The routing configuration is the technological counterpart to that confirmation template — it is the machine-readable version of the agreed allocation.
This verification step should be completed on the same day the trade confirmation is signed. Any discrepancy between what is in the trade confirmation and what is in the routing configuration should be resolved before funds move. The first and most critical task is to achieve exact match with the counterparty. Any discrepancy in notional, rate, or date triggers an immediate investigation and break resolution.
Common objections and how to address them
"Our introducers don't have wallets."
This is the most common operational objection. If an introducer does not already hold a stablecoin wallet, they need to establish one before settlement. This is not materially more complex than providing a bank account number for a wire. A self-custody wallet address, a custodial account at a regulated digital asset platform, or an institutional treasury wallet all work. The barrier is not technical; it is familiarity. Most introducers who understand that payment will be simultaneous and verifiable are strongly motivated to set up the necessary infrastructure promptly.
"We need to be able to reverse the payment if something goes wrong before the trade is fully executed."
This is a valid structural concern, and it speaks to the importance of getting the verification sequence right.
Settlement professionals who understand this will recognise that the discipline required is the same discipline they already apply to releasing wire instructions from escrow: you do not release until everything is in order.
"We run high-frequency OTC desks with many trades per day. Is this model practical at volume?"
At volume, the configuration and verification step becomes routine. Each trade has its own routing address with its own pre-set split. The workflow for the desk's operations team is to configure the address, share it for verification, and then monitor the inbound payment. Settlement speed and workflow design can influence how efficiently a treasury team manages funds. The reduction in outbound payment operations — from multiple sequential wires per trade to zero (the routing executes automatically) — is itself a meaningful efficiency gain at volume.
The documentation that should accompany every routed settlement
When a settlement uses onchain routing, the post-trade documentation package for each party should include:
- The trade confirmation — the legal record of the trade terms, including the gross notional and the agreed allocation to each party.
- The routing configuration record — a written record showing each payee address and the corresponding share percentage or fixed amount, signed off by all parties before execution.
- The transaction hash — the onchain reference linking the inbound gross payment to all outbound disbursements, included in the settlement confirmation sent to each party.
- Timestamped wallet confirmations — each party can independently verify receipt at their own address using any standard blockchain explorer, providing a self-verifiable record that does not depend on a counterparty's confirmation message.
This package replaces what would otherwise be four or five separate documents: the main settlement confirmation, individual wire confirmation receipts to each payee, and any follow-up correspondence confirming the introducer was paid. A single transaction hash, combined with the routing configuration record, carries all of that information in verifiable form.
Why this matters beyond individual transactions
The OTC market for digital assets is maturing rapidly. This bespoke service caters to the needs of OTC desks, banks, payment gateways, fund managers, high net worth individuals, and VIPs. As the range of participants broadens and trade sizes increase, the operational and audit standards applied to OTC settlement are following those applied to traditional capital markets. Choosing among OTC desks, prime brokers, and electronic communication networks is as much an operational decision as a pricing one. The right provider depends on settlement method requirements, compliance obligations, and how the desk integrates with existing treasury infrastructure.
Introducer fees are a normal part of how institutional deal flow is originated and maintained. They are not informal payments or grey-area arrangements — they are contractual, they are documented, and they need to be settled with the same rigour as the main trade proceeds. The settlement infrastructure that serves the main trade should serve the introducer fee equally well.
Shaka.deal provides OTC desks and their settlement agents with an Ethereum-native routing layer that applies exactly that logic: one inbound payment, preset shares, simultaneous disbursement, onchain finality. The introducer is not an afterthought paid from a second queue. They are a pre-configured party in the settlement instruction, paid in the same moment as everyone else, with the same verifiable receipt.
That is what clean settlement looks like. It is also what professional counterparties — sellers, buyers, auditors, and introducers — should expect.
Getting started with shaka.deal for OTC settlement
For OTC desks, settlement agents, and brokers who want to implement this model, the starting point is the same as any other settlement workflow: agree the economics, document them, and verify the receiving addresses before funds move.
The addition that shaka.deal makes to that workflow is the routing configuration: instead of issuing multiple outbound payment instructions, a single routing address is configured with the agreed split before the buyer sends funds. The buyer's payment triggers automatic disbursement to every party simultaneously.
Visit shaka.deal to explore how the routing configuration works for multi-party OTC settlements, including the introducer fee case. The product is designed for professionals who already understand how OTC settlement works and want a faster, more certain, and more auditable way to close the payment leg.
The deal is done when everyone is paid. Routing makes that one moment rather than several.
