FX rate API security testing Nigeria: How attackers exploit currency conversion APIs

Akande Simpa Lead Security Engineer & Cofounder, Simpa Labs CEH (Certified Ethical Hacker)

Why FX rate integrity is a financial security problem

In a pure naira payment system, the amount a user sends is the amount that moves. In an FX conversion, the naira amount a user sends is converted to a foreign currency amount using a rate determined at a specific moment. If that rate can be manipulated — either by changing the rate value or by changing the moment at which the rate is applied — the economics of the transaction change. The platform either pays out more foreign currency than the naira received covers, or the attacker receives more naira than the foreign currency they sent is worth at the real rate.

Nigerian fintechs operating FX products tend to have thin margins by design — they compete on rate. This means that even a small rate manipulation applied to a large transaction can produce a loss that exceeds the platform's margin on that trade. A vulnerability that allows one attacker to submit one large transaction at a manipulated rate can produce a loss that outweighs the platform's profit on hundreds of legitimate transactions.

1. Rate parameter accepted in the conversion request body

The most direct FX rate attack is submitting a conversion request with the rate as a client-controlled parameter. We test every currency conversion endpoint for the presence of a rate field in the request body and whether the backend uses the client-submitted rate or derives the rate from a server-side lock. The correct implementation: the conversion request contains only the amount and the currency pair. The backend retrieves the locked rate for the user's active quote session and uses it exclusively.

// VULNERABLE: rate accepted from client
POST /api/convert
{
  "from_currency": "NGN",
  "to_currency": "USD",
  "amount": 500000,
  "rate": 500  // attacker submits a favourable rate instead of the quoted 1600
}

// CORRECT: rate derived server-side from the quote session
POST /api/convert
{
  "from_currency": "NGN",
  "to_currency": "USD",
  "amount": 500000,
  "quote_id": "qte_7f3a9c"  // server looks up the locked rate from this session
}

2. Rate lock expiry bypass

Even when rates are locked server-side, many platforms implement the lock expiry check incorrectly. The quote record has an expiry timestamp. We test whether the expiry is checked at execution time or only at the time of quote display. An attacker who obtains a favourable rate quote when the naira is strong, waits for the naira to weaken, and then executes the transaction minutes or hours later can receive the conversion at the outdated rate if the expiry check is not enforced at execution.

3. Quote session reuse across multiple transactions

A rate quote should be single-use. Once a conversion is executed against a quote, that quote ID should be marked as consumed and rejected for any subsequent transaction. We test whether a quote ID can be reused to execute multiple conversions at the same locked rate. If it can, an attacker who receives a favourable rate quote at a moment when the market is in their favor can execute the same conversion multiple times at that rate, arbitraging the difference on each transaction.

4. Parallel quote session arbitrage

Rate engines quote rates that reflect the current market. If an attacker can obtain multiple simultaneous rate quotes for the same or different currency pairs, they can select the most favourable quote at execution time and discard the rest. We test whether the platform limits the number of active quote sessions per user and whether executing against one quote automatically invalidates the others. Platforms that allow unlimited parallel quotes without invalidation are vulnerable to cherry-picking the best rate across multiple simultaneous market observations.

Related reading

Blog: Remittance platform penetration testing · Race conditions in Nigerian fintech · Business logic flaws in payment platforms

Services: Penetration testing · API security