Mobile money security testing: MoMo, M-Pesa and USSD platforms

On this page

Mobile money is the backbone of consumer finance across much of Africa, and East Africa is its deepest market. The GSMA's State of the Industry Report on Mobile Money 2026 counts 2.3 billion registered accounts globally and more than USD 2 trillion in transaction value in 2025, with East Africa the largest regional market at USD 806 billion. Safaricom's FY25 results alone put M-Pesa at 35.8 million one-month active customers and KSh 38.3 trillion in annual transaction value. That scale, combined with fast settlement and several access channels (USSD, apps, APIs), makes mobile money a rich target for attackers and forces difficult security trade-offs on operators.

This article sets out how we approach security testing for mobile money platforms: the attack surface specific to mobile money, the vulnerabilities that come up most often and what a thorough assessment covers.

Why mobile money is a high-value target

Mobile money platforms are attractive to attackers for several reasons:

  • Transaction speed: Unlike bank transfers, mobile money transactions settle in seconds. Fraudulent transactions can be irreversible before anyone notices.
  • Scale: Millions of daily users and transactions mean that even a small per-transaction weakness can be exploited at massive scale.
  • Agent network complexity: Mobile money relies on extensive agent networks with variable security controls, creating entry points that are hard to secure centrally.
  • Multiple access channels: USSD, mobile app, web portal, merchant API and agent interface each need their own security assessment.
  • SIM swap vulnerability: SIM-based authentication is fundamental to mobile money, but SIM swap fraud is prevalent across African markets.

The mobile money architecture

A typical mobile money platform consists of several interconnected components, each with its own attack surface:

  • USSD gateway: The core interaction channel for feature phone users. Sessions are short-lived and text-based, but transaction logic runs through this channel.
  • Mobile application (Android/iOS): A higher-capability interface with more features and more attack vectors.
  • Core platform (transaction engine, wallet management): The backend system that processes every transaction, usually vendor-supplied (for example, Huawei Mobile Money Platform or Comviva mobiquity).
  • Management API: Used by agents, merchants and internal systems, and often the highest-risk API endpoint.
  • Third-party integrations: Bank partner APIs, merchant payment APIs, government service integrations.
  • Telco infrastructure: SIM card management, subscriber databases and the Home Location Register (HLR), under the telco's control but in scope for a full-platform assessment.

USSD-specific vulnerabilities

USSD is a critical and often overlooked attack surface. Our dedicated USSD testing methodology covers:

Session management flaws

USSD sessions are stateful but short-lived. Weak session ID generation, failure to invalidate sessions after timeout and session fixation can let attackers inject themselves into an active transaction. A session ID format predictable enough to guess lets an attacker hijack a session mid-transaction.

Transaction flow manipulation

USSD menus implement complex multi-step transaction flows. Crafted USSD strings that skip expected menu states, or that replay confirmed transactions, can bypass authorisation steps or cause a transaction to be processed twice.

Enumeration attacks

USSD balance-check and account-lookup features often leak whether a phone number is a registered customer, enabling mass enumeration of account holders for targeted fraud campaigns.

PIN brute-forcing

Many USSD platforms have weak rate limiting on PIN verification, which allows automated brute-force attacks against four-digit PINs (only 10,000 combinations).

For a deep dive, see our dedicated article: USSD security testing: how we assess mobile USSD and mobile money platforms.

Mobile application security testing

The mobile app (Android, iOS or both) is tested the same way as in a standalone mobile application penetration test: a combination of static analysis, dynamic analysis and traffic interception.

Static analysis

We decompile and analyse the application code and resources, looking for hardcoded credentials, API keys, sensitive strings in the APK or IPA package, insecure cryptographic implementations and debug features left enabled in production builds.

Dynamic analysis

Running the application on a controlled device (rooted Android, jailbroken iOS), we observe runtime behaviour: file system writes, memory contents, network traffic and inter-process communication. We test for insecure data storage, such as PINs, session tokens or transaction data written to the device in cleartext. The same methodology applies to banking apps; see our article on mobile banking security assessments.

Traffic interception

All API traffic between the app and the backend is intercepted and analysed. We test the app's certificate pinning implementation and attempt to bypass it. We then replay and modify captured requests to test for authorisation bypass and business logic flaws.

API and backend testing

The most critical component of a mobile money security assessment is the backend API. Transaction logic lives there, so vulnerabilities in it do the most damage. Our API security testing for banking and fintech article covers the methodology in depth; for mobile money platforms we test for:

  • Broken object-level authorisation (BOLA), also called insecure direct object reference (IDOR): Can one customer query or modify another customer's account by changing a parameter?
  • Broken function-level authorisation: Can a regular user access admin or agent-level functions?
  • Mass assignment: Can a request manipulate object properties (the transaction amount, for example) through parameters that were never meant to be user-controlled?
  • Replay attacks: Can a completed transaction request be resent to duplicate a payment?
  • Rate limiting: Are transaction endpoints protected against automated fraud scripts?
  • Authentication weaknesses: Are token expiry, refresh token security and the OAuth implementation sound?

What our mobile money assessment covers

A full mobile money security assessment from IMIZI Cyber includes:

  1. Scope definition and threat modelling: understanding your platform architecture and the attacker personas relevant to your environment
  2. USSD gateway testing (session management, flow manipulation, enumeration)
  3. Mobile application testing for Android (and iOS if applicable)
  4. Backend API penetration testing (OWASP API Security Top 10)
  5. Agent portal and merchant API testing
  6. Integration testing (bank partner APIs, payment processors)
  7. Authentication and authorisation deep-dive
  8. Detailed report with severity ratings, proof of concept and remediation guidance
  9. Debrief call with your technical team
  10. One re-test round included: every Critical and High finding, plus any Medium fixed by the re-test date, followed by a closure letter

Regulatory requirement: Regulation N° 50/2022 of the National Bank of Rwanda (BNR) requires BNR-supervised institutions, including licensed payment service providers and mobile money operators, to run a penetration test at least annually and vulnerability assessments at least twice a year, with results filed with BNR within 15 days. A mobile money security assessment from IMIZI Cyber supplies the technical evidence this regulation requires, in a report your compliance team can file.

For the full picture of what the regulation asks of supervised institutions, see our guide to BNR cybersecurity requirements.

Common findings in mobile money assessments

The Critical and High findings that recur in mobile money assessments include:

  • IDOR on account balance and transaction history endpoints: accessing other customers' data by changing a phone number or account ID parameter
  • Lack of rate limiting on PIN verification, enabling brute-force attacks
  • Sensitive data (session tokens, transaction logs) stored in cleartext on the device
  • Broken certificate pinning, allowing easy traffic interception with basic tools
  • Missing transaction idempotency checks, enabling transaction replay
  • USSD session fixation allowing mid-transaction hijacking
  • IDOR in agent management APIs

How we can help

IMIZI Cyber provides manual penetration testing for banks, fintechs, telecoms, government and healthcare institutions across Africa, including the mobile money platforms that operators and banks run. Our testing is led by an OSCP-credentialled practitioner with engagement history inside financial institutions, including a pan-African banking group. Our team understands USSD gateway architecture, agent network security and the business logic that attackers exploit in mobile money environments. We test it, and we write the report that maps every finding to a fix.

For details on our testing methodology and deliverables, see our penetration testing service page. If your platform has not been tested by people who understand these systems from the inside, contact us to scope an assessment.

Frequently asked questions

What security vulnerabilities are common in mobile money platforms?
The most common critical findings are insecure direct object references (IDOR) on account balance and transaction endpoints, no rate limiting on PIN verification (which enables brute-force attacks), broken certificate pinning, missing transaction idempotency checks (which enable replay attacks) and USSD session fixation.
How is mobile money security testing different from regular app testing?
Mobile money platforms have attack surfaces of their own, such as USSD gateways, agent network interfaces and merchant APIs, that need a specialised testing methodology. The USSD channel in particular calls for expertise in session management, transaction flow manipulation and enumeration attacks, which standard web testing does not cover.
Does BNR require security testing for mobile money operators?
Yes. BNR Regulation N° 50/2022 requires BNR-supervised institutions, including licensed payment service providers and mobile money operators, to run a penetration test at least annually and vulnerability assessments at least twice a year, with an executive summary of findings filed with the National Bank of Rwanda within 15 days of the test. Testing should cover all customer-facing channels, including USSD, mobile apps, APIs and agent interfaces.

This article is general information, not legal advice. Check the current text of any regulation with your counsel or regulator.

Talk to us about your next test

IMIZI Cyber is a Kigali-based penetration testing firm working with banks, fintechs and regulated institutions across Africa. Our testing is led by an OSCP-credentialled practitioner. After a free scoping call, you get a fixed-price proposal within 48 hours.