How to verify a counterparty actually paid before you release
Every OTC professional has felt the moment: you have your side of the trade staged, the counterparty says the funds are on the way, and you are deciding whether to release. That moment — the gap between “they say they paid” and “they actually paid” — is where OTC fraud lives, where settlement fails happen, and where your own credibility as a reliable closer gets tested. This article is about eliminating that gap entirely. Not through trust, not through intuition, and not through increasingly elaborate verbal assurances — but through a concrete verification workflow that you run before you move a single dollar or a single satoshi of your side.
Why the gap exists in the first place
Counterparty risk is the most prominent concern in OTC trading. When two parties agree to a trade, there is a window between execution and settlement during which one party might default. In voice-based OTC, this window can stretch to hours or even days, depending on settlement workflows.
That gap is structural. OTC trades don’t clear through a central venue that atomically matches delivery with payment. They are privately negotiated, privately executed, and often privately settled — which means the two sides of the transaction move independently, on separate rails, at separate times. Without a central clearing house, a failure to deliver, late funding, or a last-minute credit event can turn a good quote into a realized loss, especially on T+0/T+1 or cross-border deals where cash and assets move on tight timelines.
In traditional equities, post-trade infrastructure handles a lot of this automatically. For OTC securities, Delivery vs. Payment (DvP), where asset and cash movement happen simultaneously, is used to eliminate principal risk. But in the crypto-native OTC world — and in any bilateral deal that doesn’t run through a central counterparty — that atomic linkage doesn’t exist by default. One side goes first, then the other side follows. Whoever goes second holds the risk. And whoever goes second is standing in exactly the position this article is about.
The desk also needs to decide whether clients must pre-fund trades, whether settlement is handled after execution, and how exposure is controlled between trade agreement and final settlement. How you answer that question defines your entire verification workflow. If pre-funding is required, you verify before you even begin. If settlement is sequential, you verify at the moment you receive before you send. Either way, the obligation falls on you: confirm receipt before you release.
What “confirmed” actually means — and what it doesn’t
Before building a verification workflow, you need a precise definition of what you are verifying. The word “confirmed” is used loosely in OTC, and that looseness causes problems.
In onchain transactions, confirmation has a technical meaning. A transaction broadcast to a blockchain exists in an unconfirmed state — visible in the mempool — before it is included in a block. Once it is included in a block, it has one confirmation. With each subsequent block added on top of it, it gains another. A transaction with zero confirmations can still be reversed through a double-spend attack under certain conditions. A transaction with one confirmation is far harder to reverse. A transaction with six confirmations on Bitcoin is, for all practical purposes, final.
The question you need to ask yourself before release is not “did they send something?” It is: “is the transaction confirmed to a standard I consider final, at the address I specified, for the exact amount I agreed to receive?”
This distinction matters because the three most common failures in the verify-before-release workflow are not exotic attacks — they are elementary mistakes:
Releasing on a screenshot. The counterparty sends you a screenshot of their interface showing a pending send. You release. The screenshot is fabricated, or the transaction is not yet broadcast, or it is broadcast to the wrong address. You have no asset, and you have no recourse.
Releasing on one confirmation. For a $25,000 USDC trade on Ethereum, one confirmation may be adequate. For a $2 million BTC trade, your threshold should be materially higher, because the fee incentive to attempt a reversal scales with trade size.
Releasing on a wire receipt. A domestic wire is not final at the moment of receipt notification. Federal Reserve wire (Fedwire) is same-day final, but only once the receiving bank has actually posted the credit to your account — not when you receive a notification email, and not when you see the transaction in a pending queue. SWIFT wires are a separate matter entirely: they can be recalled in certain fraud scenarios for a meaningful window after transmission.
This is the discipline of verification: you define “final” for each rail you use, and you do not release until that standard is met, regardless of pressure, regardless of the counterparty’s insistence that everything is fine, and regardless of the market moving against them while they wait.
The verification standard by rail
Different settlement rails have different finality profiles. Your release checklist should be built around the rail being used, not around a single universal threshold.
Onchain stablecoin (USDC, USDT, USDC on Base, etc.)
This is the most verifiable rail available. The blockchain is public. The transaction hash is immutable. The goal is to make the post-trade process as controlled as the execution process: clear instructions, verified counterparties, auditable activity, and reliable reporting.
Your standard for a stablecoin receipt should be:
One — you receive the transaction hash directly from the counterparty before or immediately at the point they claim to have sent. Not a screenshot of the hash. The hash itself, in text, in your chat or email thread.
Two — you independently look up that hash on the appropriate block explorer (Etherscan for ERC-20, Basescan for Base, Solscan for Solana, Tronscan for TRC-20 USDT). You verify: the destination address matches yours exactly, character by character. You verify: the amount matches the agreed trade amount exactly, not approximately. You verify: the token contract address is the legitimate token contract, not a honeypot or spoofed token with a similar ticker.
Three — you wait for the confirmation count to reach your threshold. For trades under $100,000, one confirmation on Ethereum is typically adequate. For trades above $500,000, consider waiting for six or more. On a high-throughput chain like Base, finality is faster but the same principle applies — let the chain close behind the transaction.
Four — you note the block height and timestamp. This creates your own audit record, independent of anything the counterparty provides.
The single most important step is step two: independent lookup. You are not trusting the counterparty’s interface, their screenshot, or their word. You are checking the canonical source — the chain itself.
Bitcoin
Bitcoin’s confirmation standard depends on trade size. A typical structure includes per-transaction caps for standard and institutional clients, daily aggregate limits, and velocity checks that flag unusual patterns. Your confirmation policy should be calibrated similarly.
For a Bitcoin OTC trade, the verification workflow follows the same logic: hash in text, independent lookup on a Bitcoin block explorer, verification of address and amount, and a confirmation threshold commensurate with size. The difference from stablecoins is block time — Bitcoin averages ten minutes per block, so six confirmations take roughly an hour. On a $3 million BTC trade, an hour’s wait for finality is entirely reasonable and should be agreed upon upfront with your counterparty as part of the settlement terms. Build it into the timeline. Don’t let urgency compress it.
Fiat wire — domestic (Fedwire)
Fedwire is the gold standard for fiat finality in the US. A Fedwire transfer is irrevocable and final on the day it is sent. However, “final” means posted to your account at your bank — not when your bank notifies you, not when you see it in your online banking as “pending,” and not when the sending bank provides you a confirmation number.
The correct verification step for a Fedwire is to call your bank’s treasury services desk or operations line and confirm that the funds have posted to your account as a final credit, before you release. If you have real-time access to your account via your bank’s treasury portal, you can confirm this yourself. The key word is “posted” — not “in transit,” not “expected today,” not “the sender says it went.” Posted.
For a $5 million fiat wire on a crypto OTC trade, this call to your bank takes three minutes. Make it.
SWIFT / international wire
International wires carry more settlement risk than domestic. A SWIFT message is an instruction, not a payment. The funds move through correspondent banking chains, and depending on the currency pair and the intermediary banks involved, the credit to your account can lag the SWIFT transmission by hours or more. There are also specific fraud scenarios — and regulatory frameworks in some jurisdictions — under which SWIFT transfers can be recalled or clawed back within a window after transmission.
Your standard here: funds must be posted to your account as a cleared, available credit before you release. If your bank marks them as “held for collection” or “subject to confirmation,” they are not final. If your bank posts them as available funds, they are as close to final as SWIFT gets. Call and confirm. Get the name of the person you spoke to.
ACH
Do not release against an ACH receipt. ACH is not final. It can be reversed. For OTC transactions of any meaningful size, ACH is the wrong rail entirely, and if a counterparty proposes ACH as their payment method for a multi-hundred-thousand-dollar trade, that is itself a signal worth noting.
How to structure the conversation before the trade
Verification at settlement is much easier when the settlement terms are agreed explicitly before execution. Examine the transaction mechanics. Before moving funds, a client should understand: how pricing is provided, how long a quote remains valid, what the settlement sequence looks like, which side sends what, and when, and what documentation or verification is required.
The settlement sequence — who goes first, what rail is used, what confirmation standard applies, how long the recipient will wait before releasing — should be documented in your trade confirmation, not improvised at settlement time. When everyone agrees to the terms upfront, there is no ambiguity at the moment that matters most.
For larger trades, the standard professional approach is to agree on a specific wallet address in advance, verify that address by sending and receiving a nominal test amount first, and then agree on the release protocol: “I will release my side within thirty minutes of the transaction reaching six confirmations on Ethereum at address 0x[…]. I will confirm the hash independently via Etherscan before I release.” That sentence, in writing, in your deal record, is worth more than any amount of verbal assurance at settlement time.
The desk needs to know when clients must deliver funds, when assets are released, how failed settlement is handled, and who approves each step. If you don’t have answers to those questions in writing before the trade executes, you are improvising your risk controls in real time.
The specific scenarios where verification breaks down
Understanding where the workflow tends to fail helps you shore up the exact right points.
Pressure to release before confirmation
The most common manipulation tactic in OTC is not technical — it is social. The counterparty tells you the market is moving, the price is changing, their client is demanding the asset now, they’ve been doing this for years and this is insulting. All of that is pressure designed to compress your verification window.
Your answer is simple: “My process requires confirmed receipt before I release. I am checking now. I’ll be ready to release the moment I see it confirmed.” That answer protects both parties — including honest counterparties who simply don’t understand your workflow. If a counterparty treats your verification process as an obstacle rather than a reasonable professional standard, that tells you something important about them.
Address substitution at the last moment
A common fraud pattern is for the counterparty — or someone impersonating the counterparty — to substitute the destination wallet address at the final moment of settlement. They send to an address you did not verify. By the time you notice, the funds are gone.
Prevention: the destination wallet addresses for both sides of the trade must be confirmed in writing, over authenticated communication channels, before settlement begins. Treat any last-minute address change as a red flag that requires re-verification of the counterparty’s identity before proceeding.
”Same token, wrong contract” on stablecoins
A technically sophisticated fraud involves sending a token that looks like USDC or USDT on your block explorer at a glance — same name, same ticker — but is actually a worthless token deployed on a different contract address. You see the right amount arriving at the right address and release. The token is worthless.
Prevention: on your block explorer, click through to the token contract address of what you received. Verify it against the canonical contract address for that stablecoin. For USDC on Ethereum, the legitimate contract address is publicly documented by Circle. For USDT on Ethereum, by Tether. Bookmark those addresses. Check them on every trade.
Parallel settlement timing failures
When two parties agree to a trade, there is a window between execution and settlement during which one party might default. In voice-based OTC, this window can stretch to hours or even days, depending on settlement workflows.
In large bilateral OTC deals, especially those with multiple legs — a fiat-to-crypto conversion that also involves splitting proceeds among multiple parties — the risk of a timing failure compounds. Party A sends fiat. Party B is waiting to send crypto. But the fiat hits a correspondent bank and won’t post for four hours. Party B doesn’t know whether Party A defaulted or whether the system is slow. The trade hangs in an unresolved state, and the price moves twenty basis points against someone in the interim.
The solution to this is not to rush anyone’s verification — it is to agree on maximum wait times before the trade, and to communicate proactively throughout. “Our bank says the wire will post by 3pm. I’ll confirm the moment it does.” Active status updates during a settlement window are a professional standard, not an act of courtesy.
Building verification into the deal structure itself
The most resilient version of this workflow doesn’t put the entire verification burden on one person’s checklist at settlement time. It embeds the structure of verification into how the deal is constructed.
For large onchain trades, this means agreeing on a specific settlement address that both parties can monitor, agreeing on a block confirmation threshold in advance, and defining precisely what “I’m ready to release” means — not “I think I saw it” or “I got a notification,” but “I checked [specific block explorer], the hash is [hash], it has [number] confirmations, the amount is [exact amount], the token contract matches.”
Settlement workflows should be configured alongside trading permissions and account structure. The goal is to make the post-trade process as controlled as the execution process: clear instructions, verified counterparties, auditable activity, and reliable reporting.
When funds move onchain, Shaka’s payment routing brings an additional dimension to this structure. Rather than a single bilateral release where one party is watching a wallet and manually approving, the broker or dealmaker builds the settlement terms into the payment link itself — recipient wallets, split percentages, and routing logic — so that when the deal closes, the funds land where they are supposed to land in one transaction, with one hash, with one confirmation chain to verify. The professional checks that one hash. Everything either happened or it didn’t. There is no “partial release” ambiguity, no follow-up disbursement to track, no lag between receiving funds and distributing them to the right parties.
Your audit record is part of your professional protection
Every verification step you take should leave a record. This is not bureaucracy — it is professional self-defense. If a deal later becomes disputed, if a counterparty claims they sent funds that you deny receiving, or if a client of yours questions why you released when you did, your documentation is what separates you from someone who acted on guesswork.
Your verification record for each OTC settlement should include: the transaction hash or wire reference, the block explorer screenshot with timestamp, your confirmation count at the time of release, the name of any bank officer you spoke to for fiat confirmation, and the authenticated message thread in which the settlement terms were agreed. That record should be retained for as long as your professional obligations require — and for crypto OTC, where there is no central custodian recording the trade on your behalf, that record is entirely yours to maintain.
Compliance-ready audit trails, transaction logs, and regulatory reporting are standard expectations for any professional operating an OTC desk. If your current workflow doesn’t produce them automatically, build them manually until it does.
When the other side says “I already sent, just check your wallet”
“Just check your wallet” is not a verification process. Your wallet is a view of your balance, which can be affected by unconfirmed or fraudulent transactions just as easily as real ones. “Checking your wallet” means nothing until you have independently verified the transaction on the chain with a confirmed block count.
Settlement is where the transaction becomes real. Crypto is transferred, fiat is paid out if applicable, and the operational side of the deal is finalized. This step is especially important in OTC because settlement may involve more than a standard exchange withdrawal.
The phrase “just check your wallet” — combined with pressure to release immediately — is consistently present in a high proportion of OTC fraud cases. The wallet shows an inbound transaction. The professional releases their side. The transaction reverses, or it was a test transaction for a fraction of the agreed amount followed by a fraudulent screen-grabbed image. The discipline of the full verification workflow — hash, block explorer, confirmation threshold, token contract, amount — is precisely what stops that scenario from succeeding.
The standard to hold, regardless of counterparty relationship
Newer OTC professionals sometimes relax their verification discipline with counterparties they have traded with before. This is understandable. It is also how people get hurt. A counterparty with ten clean trades behind them is not immune to financial pressure, account compromise, or impersonation fraud. Someone accessing your counterparty’s communication channel is not your counterparty.
The answer is not to distrust repeat partners — it is to make the verification workflow so fast and so automatic that it adds no friction and no implied slight to the relationship. When your process is: receive hash, open block explorer, confirm in thirty seconds, release — nobody reads that as distrust. It reads as the professional standard of someone who settles cleanly, every time.
In large transactions, trust is not a marketing word. It is part of execution quality. The professional who verifies consistently, documents everything, and releases only on confirmed receipt is not the cautious one in the room. They are the reliable one — the person every counterparty wants on the other side of a large trade, because they know the deal will close without ambiguity on either side.
That reliability is the real asset in OTC. Your counterparties don’t remember the trades where everything went fine without process — those blur together. They remember the professional who ran a clean settlement on a $4 million trade in under an hour because their workflow was airtight, because the hash was checked, because the confirmation was certain, and because release happened exactly when it should have: not a minute before, and not a minute after.
