crm
How to Set Up a Two-Person Approval Process for Large OTC Transfers
A single compromised OTC desk operator can move six figures before anyone notices. Here's how to build a two-person approval workflow that stops it.
A trader at an OTC desk gets a Telegram message that looks exactly like it's from a regular client. Wallet address, amount, urgency — all there. He sends 40 BTC before anyone else on the team even sees the request. By the time someone flags it, the funds are three hops deep into a mixer.
This is the scenario that kills OTC desks: one person, one approval, one irreversible transfer. No crypto transaction has a chargeback button. If your desk doesn't require a second set of eyes on large transfers, you're one phishing message or one bad judgment call away from a loss you can't undo.
What counts as a "large" transfer that needs dual approval?
Most OTC desks set the dual-approval threshold somewhere between $10,000 and $50,000 per transaction, or at a fixed percentage of daily trading volume — commonly 1-5%. The exact number depends on your desk's size, but the principle is the same: anything above your normal retail-sized trade should require a second signer before it goes out.
Smaller desks sometimes set the bar lower — $5,000 — if a single bad transfer would meaningfully hurt their balance sheet. Larger desks moving millions daily might set it at $100,000+ so approvals don't bottleneck routine flow. Pick a number you can defend to an auditor, write it down, and don't let anyone override it verbally "just this once."
How do you actually structure the two-person approval workflow?
The mechanics matter more than the policy document. A rule that lives only in an employee handbook gets skipped the first time someone's in a hurry. The rule needs to live inside the tool your team actually uses to move money.
Define the trigger — set a hard dollar threshold (or coin-equivalent) that automatically flags a transfer as "requires second approval."
Separate initiator from approver — the person who builds the transfer request can never be the person who signs it off. No exceptions, including the desk owner.
Require independent verification — the approver re-checks the destination wallet address against the client's on-file address, not against what the initiator typed.
Log every step with a timestamp — who requested, who approved, what time, what wallet, what amount.
Set a cooling window for high-risk flags — if the client contact method just changed (new phone, new Telegram handle) in the last 48 hours, require a third verification call before either signer approves.
Rotate the approver role — don't let the same two people always pair up; rotating reduces the chance of collusion or complacency.
How do you manage this when your desk runs on Telegram?
Most OTC desks run client conversations through Telegram because that's where crypto clients actually live — but Telegram DMs have no built-in approval chain, no audit log, and no way to stop a single trader from acting alone. That's the gap that causes losses, not a lack of policy.
CRMChat handles this by putting every OTC client conversation into a shared pipeline where a transfer request becomes a deal card, not a private chat only one person can see. The initiating trader moves the deal to a "Pending Approval" stage, and a second team member has to review and move it forward before anything executes. Nobody is approving from memory or a screenshot forwarded in a group chat — they're looking at the same deal card, same history, same wallet notes.
CRMChat also includes notes and reminders tied directly to each deal, so the approver can see exactly what the initiator flagged: wallet address, client ID, prior transfer history, and any red flags noted by whoever last spoke to the client. If you've read our piece on writing a chatter script that matches your own voice, the same logic applies here — consistency and documentation are what let a second person step in without losing context.
Why a shared pipeline beats a Slack message or a group chat
A lot of desks try to patch this with a Slack ping: "hey, can someone confirm this transfer?" The problem is that Slack messages scroll away, nobody owns the follow-up, and there's no permanent record tied to the specific transaction. When an auditor or a client dispute asks "who approved this, and when," a scrolled-away message isn't an answer.
A pipeline stage is. Every deal card has a history: who touched it, what changed, and when it moved from "Pending Approval" to "Approved" to "Sent." That's the difference between a policy you can point to and a policy you can prove.
What should the approver actually check before signing off?
Dual approval only works if the second person is doing real verification, not just rubber-stamping because they trust their colleague. Give the approver a concrete checklist, not a vague instruction to "double check."
Confirm the destination wallet address matches the client's on-file address exactly — copy-paste errors and address-poisoning attacks both hide in a single mismatched character.
Verify the client's identity through a second channel if the request came in via a new or recently changed Telegram handle.
Check that the transfer amount matches what was quoted and agreed, not a modified figure.
Confirm the client hasn't been flagged for prior chargebacks, disputes, or suspicious activity in their deal history.
Reject and escalate immediately if anything feels off — timing, tone, unusual urgency — rather than approving "to be safe."
How do you prevent the two-person process from becoming a bottleneck?
The common objection to dual approval is speed — OTC clients expect fast execution, and adding a review step feels like friction. The fix isn't skipping the check, it's making the check fast by making the information available instantly.
CRMChat lets teams keep the full CRM context and the client conversation on one screen, so the approver isn't hunting across five apps to verify a wallet address or pull up transfer history. That alone turns a 20-minute manual review into something that takes two minutes, because everything the approver needs is already attached to the deal. You can see how a similar multi-person, multi-account setup plays out in high-volume environments in our case study on managing high-roller VIP relationships on Telegram, where speed and accountability had to coexist without either one losing.
Set your approver availability so there's always at least one backup signer online during trading hours — a two-person system with only one available approver during peak hours just recreates the single-point-of-failure problem you were trying to solve.
What else should you document around the approval process?
Write the dollar threshold and the exact approval steps into a one-page policy every team member signs.
Keep a running log of every dual-approved transfer, exportable for audits or client disputes.
Review the threshold quarterly — if your average trade size grows, your approval bar should move with it.
Train every new hire on the escalation path before they touch a single live transfer.
Test the process periodically with a dry run to confirm nobody has quietly started skipping steps.
If you're building out your broader Telegram-based operations stack, check CRMChat's Help Center for setup details on pipelines and team permissions, or the CRMChat API if you need to connect transfer approvals to an internal ledger or compliance system.
The bottom line
A two-person approval process isn't bureaucracy for its own sake — it's the one control that turns an irreversible crypto transfer into something a second human actually gets to stop before it happens. Set a clear dollar threshold, separate the initiator from the approver, document every step, and run it through a system built for team visibility rather than private DMs. The desks that skip this step don't find out it mattered until the transfer is already gone.
