The OTC desk attack surface
An OTC trade on a typical Nigerian platform follows this sequence: buyer posts a buy order, seller accepts, platform locks seller's crypto in escrow, buyer sends naira to seller's bank account, buyer uploads payment confirmation, platform releases crypto to buyer. The security of the entire transaction rests on two controls: the escrow lock (preventing the seller from withdrawing crypto while a trade is active) and the payment verification (confirming the naira was actually transferred before releasing the crypto).
Both of these controls are routinely tested by attackers through the API. The escrow lock is an API call that changes the trade status. The payment confirmation is an API call that triggers the crypto release. If either of these can be manipulated — the lock bypassed or the payment confirmation spoofed — the attacker walks away with crypto without delivering fiat. This is the most common fraud pattern we see in Nigerian OTC desk assessments.
1. Escrow release without payment verification
We test every pathway to the escrow release endpoint. The release should only be triggerable by: an authorized platform operator after manual verification, or an automated system after confirming fiat receipt through a bank API (not a screenshot). We test whether the release endpoint can be called directly by an authenticated buyer without a payment confirmation event, whether the payment status in the trade record can be modified through a separate API call before the release is triggered, and whether the dispute resolution flow has a path that can be manipulated to trigger a release in favor of the attacker.
2. Trade amount manipulation between acceptance and execution
When a buyer accepts a seller's offer, the trade amount and rate are fixed. We test whether these values remain immutable until settlement or whether they can be modified after acceptance. The attack: accept a trade for 100 USDT at a specific rate, then modify the trade amount in the API to 1,000 USDT before the payment confirmation step. If the escrow system releases the new amount rather than the originally agreed amount, the seller loses 900 USDT that they did not agree to sell.
3. Payment proof bypass and manipulation
Screenshot-based payment confirmation is inherently unverifiable. We test whether the payment confirmation endpoint that triggers the crypto release validates the payment against a real bank transaction or only records that a screenshot was uploaded. For platforms that use bank verification APIs (Paystack bank statement verification, Mono, or similar), we test whether the bank confirmation response can be replayed from a previous legitimate transaction to confirm a fraudulent trade.
4. Dispute mechanism exploitation
OTC platforms have dispute resolution mechanisms for when a buyer claims they have paid and the seller denies receipt. We test the dispute flow for: ability to open a dispute on a trade where payment was never sent (to use the dispute hold as a denial-of-service against the seller's escrowed funds), ability to manipulate the evidence submission in a dispute (uploading evidence after the dispute resolution window has closed), and whether a dispute decision in the attacker's favor can be triggered by manipulating the dispute status in the API before the human review is completed.
Escrow release triggerable by buyer without payment verification
During a penetration test of a Nigerian P2P OTC platform, we identified that the escrow release API endpoint accepted a PATCH request from the authenticated buyer user with a trade status update. By changing the trade status from "payment_pending" to "payment_confirmed" directly via the API — without uploading any payment screenshot and without triggering any bank verification — we caused the escrow to release the seller's USDT to our buyer account. The platform's escrow logic trusted the client-submitted status change rather than deriving the release condition from an independently verified payment event. Fix priority: critical. Remediated by removing the status write permission from buyer accounts entirely and enforcing that escrow releases are triggered only by a server-side payment confirmation event from the bank verification service.
Operating a crypto OTC desk or P2P trading platform in Nigeria? Book a security assessment of your escrow logic and trade flow before a manipulation loss occurs.
Book a Crypto OTC PentestFrequently asked questions
What makes crypto OTC platforms different from centralized exchanges for security purposes?
Centralized exchanges hold user funds in custodial wallets managed by the platform. OTC desks facilitate peer-to-peer trades where the platform acts as an escrow agent. The security risk shifts from protecting a centralized hot wallet to protecting the escrow logic — specifically, the conditions under which escrowed crypto is released and the binding between the fiat payment confirmation and the crypto release. Failures in this binding are the primary attack vector on P2P OTC desks.
What is the wallet address substitution attack?
During an OTC trade, the buyer and seller exchange wallet addresses for the crypto leg of the transaction. A man-in-the-middle attacker who has compromised the platform's messaging or trade detail system can substitute the legitimate seller's wallet address with their own address. The buyer sends crypto to the attacker's wallet, the seller receives the fiat payment from the buyer, and the escrow system has no mechanism to detect that the crypto went to the wrong address.
How does fake payment confirmation fraud work on P2P platforms?
Many P2P OTC platforms rely on a screenshot upload as proof of fiat payment. An attacker uploads a fabricated or edited payment screenshot, the escrow releases the crypto to the attacker, and the seller later discovers the payment was never made. We test whether platforms have automated bank confirmation (checking actual transaction records rather than screenshots) or whether the release mechanism can be triggered through a verified payment status manipulation in the API.
Related reading
Blog: P2P escrow logic flaws · Crypto exchange hot wallet exploits · Webhook race conditions
Services: Penetration testing · API security