OTC on-ramps and off-ramps: from quote to final receipt

From the customer’s perspective, on-ramp moves fiat into digital assets, such as buying USDC with dollars through an eligible service. Off-ramp moves digital assets into fiat, such as selling USDT on an agreed quote and receiving a bank payment. OTC counterparties trade on agreed quotes, subject to regional eligibility, business permissions, customer onboarding and funds requirements.

This framework describes system and operational responsibilities. Appropriately authorized providers carry out actual exchange, custody and payments. This site accepts no funds, provides no trading quotes and executes no transactions.

Identify the counterparties and funds handlers

Map the customer, counterparty, banks, liquidity providers, wallets and custodians. Specify which entity receives fiat, who controls the onchain address, who executes the trade and payout, and who handles returns and disputes. Naming a payment channel does not establish the funds flow.

Confirm operating regions, permissions, eligible customers and currencies, account purposes and provider agreements. Customers need the relevant KYC / KYB, beneficial ownership and source-of-funds checks. Review unclear same-name relationships before proceeding. The OTC label does not remove these requirements.

Define when a quote locks and expires

A quote needs direction, fiat and digital assets, network, quantities, rate, fee responsibility, net delivery, expiry and execution conditions. Specify whether pricing locks on bank receipt, chain confirmation or human approval. Otherwise, the parties may mean different things by received.

Preserve asset quantity, fiat amount and fees separately at their respective precision. Expiry, underpayment, overpayment or fee changes require the agreed reconfirmation process. Do not unilaterally change delivery or show an old quote while executing a new one.

On-ramp: verify the fiat before delivering the assets

A typical sequence is eligibility, same-name account checks, quote and order acceptance, fiat receipt verification, destination screening, approval and onchain delivery, followed by reconciliation of delivery and fees.

Verify fiat against bank or provider records, not a chat screenshot. Check payer, amount, currency, purpose and availability, with the return risks of that payment method in mind. Third-party payers require review; matching amounts alone must not automatically assign the payment to a customer.

A destination change requires fresh checks of control, network and KYT. An earlier approval does not automatically cover a new address. After controlled signing, record the hash, actual delivery, network fee and confirmation status. Broadcast still needs finality follow-up. Query unknown outcomes before any further send.

Off-ramp: verify the assets before arranging fiat payout

A typical sequence is eligibility and same-name beneficiary checks, quote and deposit instructions, onchain receipt and KYT, confirmation policy and human review, trade and payout approval, then bank payment and final reconciliation.

Link the order to a controlled receiving address, token contract, network and any required memo or tag. When a transfer appears, verify the actual token, recipient, amount, success and confirmation status. Source analysis must refer to the actual incoming transfer.

Separate assets received from permission to trade or pay. Keep the order pending when KYT is incomplete, labels need resolution, source evidence is insufficient or the beneficiary does not match. Bank or provider acceptance is also distinct from beneficiary receipt. Use evidence, result queries and financial reconciliation.

Returns and unknown outcomes need their own workflow

Wrong networks, incorrect tokens, third-party payers, expired quotes and bank returns each need a pause point, owner and evidence requirements. Do not promise recovery of every wrong-network deposit.

An onchain return requires checking the original payer relationship, destination, provider capabilities and applicable restrictions. An exchange hot wallet may not recognize a direct return. A chat message must not redirect assets to an arbitrary address. Fiat returns also need the original payer account, bank requirements and approval records.

A payment timeout leaves an unknown outcome. Check the original order reference, chain, provider and bank records before deciding the next action. Local controls must prevent one obligation from being settled twice through duplicate requests, callbacks or cross-provider retries. Each provider’s own idempotency key cannot solve that alone.

Completion means orders, chain and bank records reconcile

Every order should answer who bought and sold, which quote was accepted, what actually arrived, which checks finished and when, who approved, where delivery went, the final fees and what remains pending. Preserve original chain and banking references. Unresolved exceptions keep their reasons and owners.

Acceptance should cover normal trades in both directions, quote expiry, underpayment and overpayment, third-party payers, destination changes, incorrect assets, unknown KYT and human rejection, chain reorganizations, broadcast timeouts, failures after bank acceptance, returns and duplicate notifications. Validate in a provider-approved test environment before deciding real-business launch conditions.

Switch between both workflows in the digital asset feature. Read the stablecoin network checklist and KYT funds compliance guide, or discuss a specific project through OTC ramp workflows.