# How an OTC desk handles a trade for a first-time counterparty A detailed walkthrough of every stage an OTC desk runs through when trading with a new counterparty, and how onchain payment routing removes the settlement uncertainty that survives every other control. --- Running a new counterparty through their first trade is one of the most operationally dense things an OTC desk does. Every established relationship on the book started here — with a conversation, a dossier, a set of negotiated terms, and a settlement that either arrived cleanly or didn't. The way a desk handles that first trade tells the counterparty more about its quality than any marketing material ever could, and it tells the desk more about its own operational rigour than any internal review. This article walks through the full lifecycle — onboarding intake, compliance review, account configuration, quote mechanics, execution, and settlement — with particular attention to where uncertainty accumulates and where it can be designed out. The final stage is where onchain payment routing, specifically the kind of simultaneous multi-party distribution that shaka.deal provides, changes the settlement picture for desks that need certainty rather than hope. ## Why the first trade is structurally different A repeat counterparty arrives at the trade with everything below already in place. When the quote is accepted, the desk can move. A first-time counterparty carries none of that context. | What the desk needs | Repeat counterparty | First-time counterparty | | --- | --- | --- | | Identity | Verified identity on file | Entity and beneficial owners to verify; source-of-funds and source-of-wealth review | | Wallet addresses | Whitelisted | Addresses the assets will arrive from must be screened | | Master agreement | Signed | Master terms must be signed | | Credit or pre-funding | Arrangement established | No established credit relationship; pre-funding is the standard arrangement | | Settlement instructions | Known by memory to the ops team | Bank accounts and wallet addresses to register and whitelist before any quote is given | Until that groundwork is done, no quote is possible — and no quote should be given. The practical consequence is that a first-trade counterparty requires the desk to run two parallel tracks: the commercial track, where the two sides agree on what they want to do, and the operational track, where compliance, legal, and treasury build the infrastructure to make it happen safely. Both tracks must complete before the trade can execute. ## Stage one: the introductory consultation Before any documentation is requested, a good desk starts with a structured conversation. The first step involves a detailed consultation to understand the investor's trading goals and operational needs. This phase includes defining the desired trade size, discussing specific crypto assets or trading pairs, and determining the preferred settlement options, such as fiat or crypto. This isn't a sales call. It's operational due diligence in conversational form. A desk needs to know enough about the counterparty's structure to assess what documentation will be required, what settlement rails will be available, and whether the trade size and asset type fall within the desk's own risk limits. A family office wanting to move $4 million USD (~$6.1 million AUD) of ETH against USDC has a very different compliance and settlement profile than a corporate treasury converting stablecoin proceeds into fiat. The consultation surfaces those differences early, before anyone has invested time in a document pack that won't be fit for purpose. The desk should also use this stage to set expectations plainly. How long will onboarding take? What documentation will be required? What happens if the price has moved by the time onboarding clears? Counterparties who arrive with urgency — which is almost all of them — need to understand that the timeline is set by the completeness of their documentation, not by the speed of the desk. ## Stage two: entity verification and compliance review Once the counterparty decides to proceed, the compliance review begins. This covers verification of the entity and its beneficial owners, source-of-funds and source-of-wealth review, and screening of the addresses the assets will arrive from. OTC desks must comply with anti-money laundering requirements, know-your-customer procedures, and, increasingly, transaction reporting obligations. A well-designed OTC platform embeds these compliance requirements into the onboarding and trading workflow rather than treating them as separate, manual processes. For a corporate counterparty, the document pack typically includes: certificate of incorporation, proof of registered address, ownership structure chart down to beneficial owners, government-issued identification for authorised signatories, source of funds declaration, and — critically — the wallet addresses from which assets will be sent and to which they will be received. Wallet addresses, timestamps, and platform confirmations alone do not establish the compliance trail that correspondent banks and institutional auditors require. The narrative around those addresses — who controls them, what jurisdiction, what custody model — is what makes the dossier usable downstream. On-chain address screening is now standard. Blockchain analytics tools flag addresses with sanctioned-entity exposure, mixing history, or known darknet association. A clean address screen is a prerequisite for proceeding, not a formality. Beyond onboarding, ongoing compliance includes screening every trade against sanctions lists, monitoring for unusual patterns, and reporting large transactions to relevant authorities. Desks that treat the compliance review as a bureaucratic hurdle to clear as fast as possible invite problems. Desks that treat it as genuine risk management produce a cleaner audit trail when the trade is done — one that matters to both the counterparty's auditors and the desk's own regulatory obligations. ## Stage three: account configuration and settlement instructions Compliance clearance unlocks account configuration. This means setting trade thresholds, asset limits, fiat preferences, and margin agreements if needed. But for a first-trade counterparty, the most important work here is establishing and whitelisting settlement instructions. Platforms should automate settlement instruction generation immediately upon trade execution. Both counterparties should receive clear, unambiguous instructions detailing what to deliver, where to deliver it, and when. Those instructions can only be generated once the settlement details are locked: the counterparty's receiving wallet address for the crypto leg, and the bank account details for the fiat leg if applicable. The first trade is exactly the moment when this control matters most, because the desk has no prior pattern of behaviour to detect against. The account configuration stage also sets the credit or pre-funding structure. Treasury teams typically pre-fund their OTC account or use a pre-agreed settlement window that minimises the gap between execution and delivery. For a first-time counterparty where the desk has no established credit relationship, pre-funding is the standard arrangement — the counterparty funds their account before the quote is given, and the desk knows it is quoting against confirmed availability rather than a promise. This is operationally straightforward but requires the counterparty to move capital ahead of knowing the exact price, which is a reasonable ask in exchange for execution certainty. ## Stage four: the RFQ and quote mechanics With onboarding complete and the account configured, the counterparty can request a quote. Everything starts with an RFQ. The client sends a structured request specifying the asset, direction, and size. A typical RFQ looks like: "I am a taker, want to buy 150 BTC for USDT, settled today." The desk does not know the client's exact strategy but does know the trade ticker, which is enough to price it. The desk returns a firm, all-in price for the full size, live for a short hold window. The window is short because the desk is quoting a price it must be able to cover. That quote includes the spread; there is no separate commission line. The counterparty sees one number for the full trade. This is the key structural advantage of OTC over exchange execution. A desk replaces an uncertain average fill with one number. The counterparty knows the price for the full size before it commits, and the execution risk moves to the desk, which is paid for taking it inside the spread it quotes. Acceptance inside the window creates a binding bilateral contract. The desk books the position and hedges or warehouses it; if that hedge goes badly, the agreed price does not change. This is principal-model execution. The desk stands between the counterparty and the market; whatever happens in the minutes between acceptance and hedge completion is the desk's problem, not the client's. For a first-time counterparty, the desk may also spend a moment on the mechanics of acceptance — confirming that the counterparty's authorised signatories understand the binding nature of quote acceptance and that their internal approval process is complete before they click accept. A first trade that falls apart because an unauthorised trader accepted a quote wastes everyone's time and signals an internal control gap that will come up in the next review. ## Stage five: pre-settlement checks and the window of exposure The trade is agreed. Both sides know the asset, the size, the price, and the settlement terms. Now comes the period that nobody on either side enjoys: the window between agreement and confirmed receipt. The time between agreeing a price and both sides receiving their assets is where most settlement risk lives. The longer this window, the more exposure both parties have to price movement, counterparty default, or operational delay. From the moment a trade is agreed to the moment settlement is confirmed, you carry full bilateral exposure. The counterparty could default, delay, or deliver the wrong asset. In a traditional bilateral OTC trade, the two legs — asset delivery and cash payment — do not move simultaneously. One side moves first and waits for the other. The cargo moves on one timeline. The cash moves on another. Compliance verification runs on a third. When those three timelines fail to converge at the right moment, the result is not just an operational inconvenience — it is trapped working capital, widening counterparty exposure, and a risk position the balance sheet is quietly carrying every day the settlement window stays open. For a first-time counterparty, this window is especially fraught. The desk has no prior settlement history to calibrate against. It does not know whether the counterparty's treasury team moves quickly or slowly. It does not know whether their bank will flag the outbound wire for compliance review. It does not know if the authorised signatory for the crypto wallet is available on the day of settlement. Each of these unknowns adds time to the window and exposure to the position. The settlement process begins with initial trade verification — confirming the identities of all involved parties and ensuring trade details align, including verifying trade amounts, pricing, and matching details. For a pre-funded account, the cash leg is already resolved at this point; the desk knows the funds are available. For a T+0 or T+1 arrangement, this verification step can take time and introduce uncertainty if the counterparty's bank is slow or the wire reference is misformatted. ## Stage six: where multi-party settlement gets complicated Many institutional OTC trades are not simple two-party exchanges. There may be a broker who introduced the counterparty and is owed a share of the deal. There may be a fund administrator or custodian involved in the receipt leg. There may be a referral relationship between the counterparty and a third party that entitles that party to a distribution. The desk itself may have revenue-sharing arrangements with affiliated entities. In practice, this means a single trade settlement often involves distributing proceeds to three, four, or more addresses simultaneously. Doing this sequentially — paying the desk's account first, then the broker, then the fund — creates exactly the timing risk described above, multiplied. Each sequential payment is a new exposure window. Each carries the possibility of error: wrong amount, wrong address, wrong timing. The operational burden of manual multi-party distribution is significant. Settlement is where many OTC operations encounter friction. A platform with excellent execution but manual settlement workflows creates a bottleneck that limits scale and introduces operational risk. For a first-trade counterparty, manual distribution also creates an audit trail problem: if the three outgoing payments are timestamped differently, proving that all parties were paid in accordance with the agreed terms requires reconciling multiple records rather than reading a single transaction. This is precisely the problem shaka.deal was built to resolve. Rather than routing settlement proceeds to one account and relying on that account holder to distribute to others — a process that introduces custody, delay, and reliance on a single party's operational accuracy — shaka.deal routes the total amount in one transaction on Ethereum, splitting it to every designated address simultaneously, at preset proportions, with finality. The desk configures the splits in advance: 72% to the desk's treasury wallet, 18% to the broker, 10% to the fund administrator, for example. When the settlement payment arrives, the distribution happens in the same block. No second step. No waiting for a downstream payment. No possibility of one party receiving their share before another. Critically, shaka.deal is non-custodial. It routes; it does not hold. The funds do not sit in a shaka.deal account waiting for distribution. The contract receives the incoming payment and forwards each share in the same transaction. For a first-time counterparty watching where their counterparty risk lives, this architecture is materially different from arrangements where proceeds pool in a desk-controlled account before redistribution. ## Stage seven: final settlement and post-trade documentation Settlement is not complete when the payment leaves. It is complete when the receiving party confirms receipt, amounts match, and the trade is marked closed in both systems. For a first-time counterparty, this post-settlement confirmation step is more important than it is for established relationships, because there is no prior history to serve as a check. If the amounts don't match, this is the moment to catch it. The final documentation step involves recording timestamps for the settlement, storing compliance-related documentation, and updating trade reporting systems. A full trade confirmation package — the executed trade ticket, the settlement instruction confirmations, onchain transaction hashes where applicable, and the compliance sign-off — serves multiple downstream purposes. This is what the counterparty's bank needs to accept a large incoming transfer from a crypto-related source without flagging it. It is also what their auditors need to sign off on the trade as part of an annual compliance review. On-chain settlement provides an immutable record, simplifying reconciliation and compliance audits without relying solely on bank statements. When settlement flows through an onchain router like shaka.deal, the transaction hash is the settlement record — public, timestamped, and unambiguous about amounts and addresses. There is no need to reconcile four separate internal payment confirmations. The hash references all legs simultaneously. For the counterparty's compliance team, this is cleaner than a stack of bank confirmations. For the desk's compliance team, it reduces the time spent assembling post-trade documentation. For any audit or regulatory review, an onchain transaction is a primary source — not a derived report. ## Stage eight: what happens if something goes wrong No discussion of first-trade mechanics is complete without addressing failure scenarios. Settlement can fail for many reasons: the counterparty's bank wire arrives with the wrong reference and is held for manual review; the wallet address confirmation email was spoofed and the receiving address is wrong; the authorised signatory for the crypto release is unreachable; the stablecoin transfer hits an unexpected network delay. On a traditional bilateral settlement, a failure in one leg freezes the entire position. Counterparty risk in OTC is the risk that the other party fails to deliver what was agreed. In a bilateral trade, there is a window between execution and final settlement during which one side has committed, but the other has not yet delivered. If the desk has already released the crypto leg and the fiat wire does not arrive, the desk is exposed to the full notional value of the trade until the situation is resolved. Pre-settlement risk arises between trade execution and final settlement. During this window, one party can default before the exchange of assets is complete. The desk's response to a first-trade settlement failure matters enormously to the relationship. A desk that escalates calmly, communicates clearly, and documents every step of the resolution builds trust with a counterparty in a way that a smooth first trade never quite can. A desk that goes silent or redirects blame does the opposite. From a system-design perspective, the best outcome is to engineer scenarios where the most common failures cannot happen. Pre-funding removes the fiat-leg-arrival risk. Whitelisted addresses remove the spoofed-address risk. Onchain routing removes the sequential-distribution risk. None of these are substitutes for legal documentation and operational discipline; they are complements to them. Managing OTC settlement well means more than finding a good price. A team needs a clear view of counterparty risk, a defined custody approach, and internal controls that match the approval requirements the organisation already applies to large financial transactions. ## What the first trade should leave behind The goal of a first trade is not just to settle cleanly. It is to produce, as a by-product of executing well, the complete infrastructure for every subsequent trade with that counterparty. After a well-executed first trade, the desk has: a fully verified entity dossier; whitelisted and screened wallet addresses; a signed master agreement with settlement terms on record; a tested pre-funding or settlement workflow; an established post-trade documentation standard; and — if the desk uses onchain routing — a configured shaka.deal payment route that reflects the agreed distribution of proceeds for future trades of the same structure. That last point is worth dwelling on. A shaka.deal route is preset. The splits — between the desk, any brokers, any affiliated parties — are encoded once, at configuration. When the next trade settles, the same distribution logic executes in the same single transaction, with the same finality, at the same speed. The desk does not re-enter the amounts. The broker does not need to wait for a separate payment. The onchain record of every settlement is consistent and comparable across trades. For market makers and institutional desks, settlement speed and certainty are directly tied to trading performance. A counterparty who receives their assets the moment settlement executes — not an hour later, not after a batch run, not pending a manual approval — is a counterparty who can redeploy capital immediately. Once an onchain transfer executes, it settles without a need to wait hours or days for bank wires to clear. This reduces the settlement window from days to minutes, enabling counterparties to redeploy capital immediately. That is the competitive advantage of a desk that has modernised its settlement infrastructure: not faster pricing, not tighter spreads, but the certainty that when a trade is done, it is actually done. For a first-time counterparty deciding which desk to build a relationship with, that certainty is the most persuasive thing a desk can offer. ## The desk's operational reputation is built here Every OTC desk has a story about a first trade that cemented a long relationship and a story about one that didn't. The variables that determine which story gets told aren't the spread, the price, or the asset selection. They are the quality of the onboarding intake, the clarity of the settlement instructions, the speed of the compliance review, and the reliability of the distribution at the end. Institutional participation continues to grow as a share of spot volume on major OTC desks. The practical reading for a counterparty: a desk is now judged on its settlement and credit terms rather than on headline liquidity, because liquidity is the part everyone has. Desks that have resolved their settlement infrastructure — that have pre-funded accounts, whitelisted addresses, and onchain routing configured for simultaneous multi-party distribution — can focus the first-trade conversation on what the counterparty actually cares about: price, capacity, and the certainty that when they accept a quote, the settlement will be exactly what they expected. Everything else is operational table stakes, and table stakes should be handled by systems that don't require human intervention to get right. That is what shaka.deal provides in the settlement layer: one incoming payment, preset shares, simultaneous payout, and a final onchain record that closes the loop. The desk configures it once. Every trade thereafter settles on the same logic, with the same speed, and with the same certainty. For a first-time counterparty who has never watched your desk settle before, that is a stronger signal of operational quality than anything you could say in an introductory call.