They called customer support first. Then they needed your OTP.

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

The anatomy of a Nigerian mobile money fraud ring

Modern mobile money fraud in Nigeria relies on a division of labor. Cybercriminals do not work in isolation. Instead, they organize into specialized syndicates that operate with corporate efficiency. To successfully bypass multi-factor authentication and fraud alerts on platforms like OPay, Moniepoint, or PalmPay, a fraud ring typically splits into three distinct roles.

The social engineer (The Caller)

This operator is the voice of the scam. Possessing high verbal agility and acting under scripted scenarios, their sole task is to manipulate the victim. They call the target, impersonate customer support, and establish false credibility. They do not write code or analyze API endpoints. Their role is to manage the human interface: keeping the victim distracted, compliant, and ready to share codes.

The technical operator

This agent handles the technical execution. They run custom automated scripts, manage modified client applications, and interact directly with the target fintech's APIs. The technical operator uses leaked customer databases, configures device fingerprints, triggers authentication requests, and processes sessions. They sit at a computer with their tools open, waiting to input the victim's OTP the instant it is spoken.

The cash-out agent

This person controls the money-laundering network. They buy access to active, pre-verified bank accounts—often tier-1 or tier-2 accounts belonging to university students, or accounts registered using stolen BVN data obtained from identity verification APIs. The cash-out agent ensures that as soon as the technical operator drains the target wallet, the funds are immediately split and routed to different terminals before fraud systems trigger flags.

Phase 1: Intelligence gathering call

The attack does not start with a guess. It starts with structured intelligence. Attackers compile target profiles using details leaked from past fintech database exposures, public directory APIs, or modified Truecaller lookups. When they dial the victim, they do not ask who they are; they call them by name.

The caller states they are from the 'Simpa Bank Fraud Department' or a major commercial bank. They claim that a suspicious transfer of ₦150,000 to an unfamiliar name is currently pending on the account. To verify the caller's identity, they ask the victim to confirm their bank account number, registered phone number, and the approximate value of their last transaction.

Because the attacker already obtained this information from offline leaks or API abuse, the confirmation feels like a routine validation step. The victim drops their guard, convinced they are speaking with legitimate support.

Phase 2: The OTP acquisition

While the victim remains active on the phone call, the technical operator triggers an authentication request on the fintech's application or web API.

The operator targets the login recovery or password reset endpoint. A typical request sent directly to the fintech's auth server looks like this:

POST /api/v1/auth/forgot-password HTTP/1.1
Host: api.simpalabs.com
Content-Type: application/json
User-Agent: SimpaPay/4.2.1 (Android 13; Scale/2.00)

{
  "phone_number": "+2348030001122",
  "channel": "sms"
}

This API call forces the backend to dispatch a six-digit verification code via an SMS gateway like Termii or Twilio to the victim's MTN or Airtel phone line.

The caller, tracking the timer on their side, tells the victim: "We have blocked the unauthorized attempt. We are sending a system cancellation code to your phone. Read it back to us immediately so we can finalize the reversal."

The victim reads the incoming OTP. The technical operator immediately inputs it to authenticate a new device session:

POST /api/v1/auth/verify-otp HTTP/1.1
Host: api.simpalabs.com
Content-Type: application/json

{
  "phone_number": "+2348030001122",
  "otp": "847291",
  "device_id": "attacker-device-fingerprint-99b3",
  "device_name": "iPhone 15 Pro"
}

The verification succeeds. The backend generates a valid session token, giving the attacker total access to the account.

The technical gap: Generic OTP templates

The core issue lies in the design of the verification messages. Most Nigerian fintechs send contextless SMS templates. A common message reads:

"Your verification code is 847291. Do not share this with anyone."

This message fails to explain what action the code authorizes. The victim has no way of knowing whether the OTP is for logging in from a new device, resetting a password, or approving an outbound transfer of ₦200,000.

If the SMS had explicitly stated the action, the victim would have recognized the threat: "WARNING: This OTP is for resetting your password on a new device. If you did not request this, do not share it." The lack of specific copy in transaction and authentication messages is a structural product vulnerability that makes social engineering highly effective.

Phase 3: Session persistence

Once inside the account, the technical operator's goal is to maintain access. They know that if the victim detects the fraud, they might attempt a password reset. To prevent this, the operator immediately extends their control.

They submit a request to link their own device or update the user's primary contact email:

POST /api/v1/user/devices HTTP/1.1
Host: api.simpalabs.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsIn...
Content-Type: application/json

{
  "device_model": "iPhone 15 Pro",
  "os_version": "17.4",
  "push_token": "apns-token-xyz-123",
  "trust_level": "trusted"
}

Because many fintech platforms do not send real-time alerts when a new device profile is added, this operation happens silently. The attacker now has a permanent session on their device, rendering subsequent OTP requests on the victim's phone less relevant.

Phase 4: The drain

With session persistence established, the operator handoffs the session to the cash-out agent. The cash-out agent initiates transfers to several mule accounts.

To bypass basic fraud rules, the transfers are structured. If the platform alerts on transfers above ₦50,000, the attacker executes three transfers of ₦49,500 in quick succession. The cash-out agent distributes the funds to mule accounts across multiple digital banks (like OPay, PalmPay, or Moniepoint).

These mule accounts immediately forward the funds to a second layer of accounts, and then to a third. Within 10 minutes, the money has moved through three different banks and is withdrawn at POS terminals or ATMs.

Reversing these transactions is incredibly difficult. Once the money leaves the ecosystem through NIBSS Instant Payments (NIP) and is cashed out, recovery requires formal court orders, police affidavits, and multi-bank cooperation. By the time the compliance teams respond, the funds are long gone.

What fintechs should implement to break this chain

Fintech engineering teams must implement five specific controls to break this attack lifecycle.

1. Contextual OTP templates

Do not send generic SMS messages. Include the action, amount, and beneficiary details directly in the SMS body.

"Your Simpa Bank OTP is 847291 to authorize a transfer of ₦50,000 to GTB account 0123456789. Valid for 2 mins. NEVER share this code."

This context makes it obvious to the victim that they are authorizing a transfer, not canceling an unauthorized login.

2. Real-time device registration notifications

When a new device registers, send an immediate SMS and email to the user's previously verified contact channels. Include a direct link to revoke the new device immediately.

{
  "notification": "A new device (iPhone 15 Pro) has been added to your account. If this wasn't you, click here to lock your account: https://simpalabs.com/lock?token=xyz"
}

3. Behavioral velocity limits

Set up risk rules that detect high-risk sequences. Flag accounts that initiate multiple transfers within 5 minutes of a password reset, device addition, or email change. Apply temporary blocks or step-up biometrics on these accounts.

4. In-app active call detection

Use mobile SDK APIs to check if the user is on an active cellular call while performing sensitive actions.

On Android, check with the TelecomManager service:

val telecomManager = context.getSystemService(Context.TELECOM_SERVICE) as TelecomManager
if (telecomManager.isInCall) 

On iOS, query CallKit's CXCallObserver to detect active call sessions. If the user is on a call, prompt a fullscreen warning: "You are currently on a phone call. If someone is telling you to read an OTP or password reset code, they are trying to steal your money."

5. Credential-change cooling-off periods

Enforce a mandatory 24-hour cooling-off period on all outbound transfers after an account recovery or password reset. The user can view their history and deposit funds, but outbound transfers are blocked. This allows the real owner time to notice the security alert and contact support to lock the account.

Related reading

Blog: SMS OTP fallback vulnerabilities in Nigerian networks · Defending against SIM swap fraud in agent networks

Services: Authentication and authorization security reviews · Penetration testing