What makes remittance platform security different
Domestic fintech sends naira between Nigerian accounts. A failed or fraudulent transaction goes through CBN dispute channels. Cross-border remittance involves two financial systems, two regulatory frameworks, and in most cases an intermediate correspondent bank. When funds leave Nigeria through a remittance platform and are redirected by an attacker to the wrong beneficiary, the recovery process requires cooperation from the Nigerian partner bank, the foreign correspondent bank, and the recipient bank — sometimes across three different jurisdictions with different regulatory timelines and priorities.
The AML and sanctions risk compounds this. If an attacker uses a compromised remittance account to send funds to a sanctioned entity or country, the platform — not the attacker — faces the regulatory consequence. OFAC does not accept "our account was compromised" as a complete defence without demonstrating that appropriate controls were in place and operating.
1. FX rate parameter injection and arbitrage window testing
Every remittance platform shows the user an exchange rate before confirming the transfer. The security question is: where is that rate stored between the quote and the execution? We test three failure modes:
- Client-side rate storage: The quoted rate is stored in the browser's sessionStorage or in a hidden form field. An attacker intercepts the transfer request and modifies the rate field before submission. The backend uses the client-submitted rate without re-validating it against the current live rate.
- Rate parameter accepted in API body: The transfer API accepts a
fxRateparameter in the JSON body. The platform intended this for internal use but neglected to strip it from public-facing endpoints. Submitting a more favourable rate is as simple as adding the parameter to the request. - Rate lock expiry not enforced: The rate is locked server-side correctly but the lock expiry is not validated at execution time. An attacker who initiates a transfer when the naira is strong, waits for the rate to weaken, then executes the transfer using the expired lock claims an exchange rate that no longer exists.
2. Corridor authorization bypass
Remittance platforms are licensed for specific corridors. A platform licensed to transfer funds to the UK and Canada may not be licensed for transfers to certain other countries. We test whether the corridor restriction is enforced server-side or whether a user can initiate a transfer to an unauthorized destination by submitting a valid-format beneficiary account in a country the platform is not licensed to serve. An unauthorized corridor transfer is both a financial risk and a direct regulatory violation.
3. Beneficiary account manipulation and cooling period bypass
We test every step of the beneficiary addition workflow. After adding a beneficiary, most platforms impose a cooling period (typically 24 to 48 hours) before the first transfer can be sent. We test whether this cooling period is enforced as a database timestamp comparison or as a session flag that can be reset. We also test whether the beneficiary verification (name matching against the recipient bank record) can be bypassed by exploiting the timing between the NIBSS or SWIFT name lookup and the transfer submission.
4. Transfer limit bypass via request splitting
Regulatory transfer limits (CBN caps on outbound transfers, platform-level daily limits) are a compliance requirement. We test whether limits are enforced per-request or per-day across all requests. The attack pattern is to split a single large transfer into multiple smaller requests that each fall below the per-transaction limit but collectively exceed the daily limit. If the limit is checked only at the transaction level without aggregating the day's total, the attacker transacts at multiples of the permitted daily amount.
5. Inbound payment credit manipulation
For platforms that allow international recipients to receive naira, we test the inbound payment credit flow. The platform receives a notification from a foreign partner that a payment has been received, then credits the Nigerian recipient's wallet. We test whether the credit amount can be manipulated by replaying or forging the inbound notification, and whether the platform re-validates the credited amount against an independently verified source before crediting the wallet.
FX rate accepted as request body parameter on live transfer endpoint
During a penetration test of a Nigerian cross-border remittance platform serving the Nigeria-UK corridor, we intercepted a transfer initiation request using Burp Suite. The POST body contained a quotedRate field that the backend accepted and used directly to compute the GBP amount to pay out. We modified the rate from the live quoted value of 2,050 NGN per GBP to 500 NGN per GBP and submitted the transfer. The backend computed the GBP payout at our submitted rate and initiated payment of four times the intended GBP amount for the same naira debit. Fix priority: critical. Remediated by removing the rate parameter from the public API, computing all FX amounts exclusively from the server-side locked rate keyed to the transfer session ID.
Operating a cross-border remittance or FX transfer platform in Nigeria? Book a security assessment that covers your full corridor and compliance risk.
Book a Remittance Platform PentestFrequently asked questions
What regulatory bodies govern remittance app security in Nigeria?
CBN governs the Nigerian side of international remittances under its International Money Transfer Operator (IMTO) licensing framework and the Payment Service Providers regulation. On the receiving end, OFAC compliance (for US corridors), FCA requirements (for UK corridors), and FinCEN obligations apply depending on the corridor. A security breach in a Nigerian remittance app can trigger compliance consequences in multiple jurisdictions simultaneously.
What is the FX rate locking vulnerability in remittance platforms?
When a user initiates a transfer, the platform quotes an FX rate. That rate should be locked server-side for a limited time window. If the rate is stored client-side or if the transfer API accepts the rate as a parameter, an attacker can submit a transfer at a more favourable rate than was actually quoted — sending the same naira amount while the recipient receives more foreign currency than the platform intended to pay.
How do attackers exploit remittance beneficiary management?
Attackers who compromise a remittance account do not always change the account's password immediately. Instead, they add a new beneficiary in a country the platform supports, wait for the added-beneficiary cooling period to expire, then initiate a transfer to the new beneficiary. If the platform does not send a real-time notification for beneficiary additions or does not require step-up authentication for new beneficiary creation, this attack is undetected until the user checks their transfer history.
Related reading
Blog: FX rate API security · NIBSS name enquiry exploits · Rate limiting and anti-fraud
Services: Penetration testing · API security