Mobile Money AML Reporting in Kenya: M-PESA, Airtel Money & Beyond

Kenya's mobile money ecosystem is one of the most sophisticated and deeply embedded in the world. With over $85 billion transacting annually across M-PESA alone, and mobile money penetration rates that exceed conventional banking reach in rural Kenya, the mobile money channel is not just a payment method — it is the primary financial infrastructure for the majority of Kenyans.

For compliance officers at Kenyan financial institutions, this scale creates an AML challenge that most are significantly under-addressing. Mobile money transactions are often treated as a separate data stream from branch and ATM transactions, monitored with different tools (or not monitored systematically at all), and rarely integrated into the CTR threshold aggregation that determines filing obligations. The result is that one of Kenya's largest AML risk vectors is also one of the most underreported to the Financial Reporting Centre.

This article addresses the regulatory obligations, technical challenges, typology landscape, and best practices for mobile money AML reporting in Kenya — including what financial institutions need to understand about their obligations when they operate M-PESA Pay Bill or Till Numbers, how to classify mobile money transactions in goAML XML, and how to build the technical integration that makes systematic compliance possible.

---

The Scale of Mobile Money in Kenya

M-PESA: 60M+ Registered Users, a Dominant Share of GDP

M-PESA is not simply Kenya's largest mobile money platform — it is a foundational piece of Kenya's economic infrastructure. Safaricom's M-PESA platform serves more than 60 million registered users across Kenya and a growing number of African markets. In Kenya specifically, the value of M-PESA transactions represents a significant proportion of the country's GDP on an annual basis, making it one of the highest mobile money penetration rates in the world relative to economic size.

The platform processes millions of individual transactions per day. These range from KES 10 person-to-person transfers between informal traders to multi-million-shilling business-to-business settlement transactions through M-PESA Business APIs. The sheer volume and diversity of mobile money activity means that illicit transactions — structuring, layering, and agent-assisted fraud — can be masked within legitimate transaction patterns unless monitoring is systematic and sophisticated.

Airtel Money and T-Kash: Secondary but Significant

Airtel Money is Kenya's second largest mobile money operator, serving tens of millions of users with domestic transfer, payment, and savings products. While M-PESA dominates by market share, Airtel Money's scale is sufficient to be a material AML risk vector, particularly for structuring schemes that deliberately fragment transactions across multiple mobile money platforms to stay below any single platform's monitoring threshold.

T-Kash, operated by Telkom Kenya, is the smallest of the three platforms but relevant for institutions with Telkom business account integrations. As the mobile money market continues to evolve — with new payment service providers entering under CBK's updated PSP licensing framework — the universe of mobile money channels requiring integration into AML monitoring is expanding.

Bank-Linked Mobile Money vs. MNO Wallets — Who Is the Reporting Entity?

This is one of the most important — and most frequently misunderstood — regulatory questions in Kenyan mobile money AML compliance.

MNO wallets (M-PESA float held at Safaricom, Airtel Money wallets held at Airtel): The Mobile Network Operators are themselves reporting entities under POCAMLA. Safaricom and Airtel have their own AML compliance obligations, their own FRC reporting credentials, and their own transaction monitoring systems. When a customer conducts a purely wallet-to-wallet transaction that never touches a bank account, the reporting obligation lies with the MNO.

Bank-linked mobile money: When a customer uses M-PESA Pay Bill to deposit funds into their bank account, or when a bank uses M-PESA APIs for bank-to-wallet transfers, the transaction touches the bank's regulated account. The bank becomes a reporting entity for the portion of the transaction that is in its custody. If a cash-equivalent transaction in that flow reaches the USD 15,000 equivalent CTR threshold, the bank has an obligation to file.

The practical implication is that a Kenyan bank operating a Pay Bill short code is responsible for monitoring and reporting on the mobile money flows through that Pay Bill — not just the branch and ATM transactions. Many institutions have not fully implemented this reporting obligation.

---

Mobile Money AML Risks and Typologies

Structuring: Multiple M-PESA Transactions Below the USD 15,000 Threshold

Structuring — deliberately breaking up transactions to stay below the USD 15,000 equivalent CTR threshold — is the most prevalent mobile money AML typology in Kenya. With M-PESA's simple user interface and the widespread familiarity Kenyans have with the platform, structuring via M-PESA is accessible to anyone who understands that there is a reporting threshold.

A structuring pattern might look like: the same individual (identified by MSISDN or national ID) making several M-PESA transfers to a business Pay Bill account on successive days, each for an amount just below the USD 15,000 equivalent. Individually, each transfer is below the reporting threshold. Cumulatively, the pattern suggests a single large cash movement being disaggregated — an STR trigger under FRC Circular No. 4 of 2023 paragraph 4.4, not a basis for a consolidated CTR.

Detecting this pattern requires surveillance logic that operates over a rolling time window, across multiple transactions from the same originator, to the same destination. Rule-based monitoring that evaluates individual transactions in isolation is structurally incapable of detecting it.

Layering: M-PESA Receive → Bank Deposit → RTGS Transfer

A more sophisticated typology combines multiple financial channels in a rapid sequence designed to obscure the origin of funds. In the East African context, a common pattern is:

1. Multiple M-PESA receives from multiple senders (placement — may be cash placed via M-PESA agents)
2. Rapid transfer of aggregated M-PESA balance to a bank account via Pay Bill
3. Bank transfer via RTGS to a business account at another bank
4. Outward international wire transfer for trade payment or personal remittance

Each individual transaction in this sequence may not breach any single alert threshold. The AML significance lies in the pattern: the speed of the sequence (all steps within 24 to 72 hours), the round-trip nature of the funds movement, and the inconsistency with the account holder's known business activity.

Identifying this pattern requires data from multiple systems — M-PESA transaction data, bank account transaction history, and RTGS/SWIFT outward transfer records — correlated by customer identity.

Agent-Assisted Fraud: Corrupt M-PESA Agents Facilitating Illicit Deposits

Kenya's M-PESA agent network is one of the largest financial services agent networks in the world, with over 300,000 registered agents providing cash-in and cash-out services. The overwhelming majority of agents operate legitimately. A small number facilitate illicit transactions, either knowingly (corrupt agents helping criminals convert cash to electronic form while recording fictitious transaction details) or unknowingly (agents whose SIM-swap-compromised devices are used by criminals).

Agent-assisted cash placement is particularly difficult to detect because the M-PESA transaction records show the agent's business number as the transaction origin, not the actual individual who provided the cash. Compliance monitoring that does not flag unusual transaction patterns from specific agent codes is missing a key data dimension.

SIM Swap Fraud and Identity-Linked AML Risk

SIM swap fraud — where a criminal convinces a mobile operator to transfer a victim's mobile number to a SIM card controlled by the criminal, then accesses M-PESA and mobile banking accounts linked to that number — is a significant and growing problem in Kenya. From an AML perspective, SIM swap attacks blur the link between mobile money transactions and verified customer identity: the transactions appear to originate from a legitimate, KYC-verified customer but are actually conducted by an unverified third party.

For institutions linking M-PESA transaction data to KYC customer records by MSISDN, SIM swap attacks create false identity associations that can both generate false positive AML alerts (flagging legitimate customers whose accounts have been attacked) and generate false negative outcomes (failing to flag criminal transactions that appear legitimate because they are linked to a clean identity).

Cross-Border Remittance Through M-PESA Global

M-PESA's integration with international remittance services including Western Union and WorldRemit creates a cross-border channel that is particularly relevant for AML monitoring. Inbound international remittances received via M-PESA and immediately converted to cash via agent withdrawal, or rapidly transferred to multiple recipient accounts, warrant monitoring as potential trade-based money laundering or remittance layering.

The cross-border dimension means that the source jurisdiction's AML regime applies to the sender, while the Kenyan bank or MNO that receives the funds has an obligation to monitor the receiving-end pattern. FRC guidance on cross-border remittance reporting is an area where many institutions have compliance gaps.

---

Regulatory Requirements for Mobile Money AML Reporting

Who Must File: Banks with Pay Bill/Till vs. Safaricom M-PESA

The FRC-mandated reporting obligation framework for mobile money can be summarised as follows:

Banks with M-PESA Pay Bill or Till Number integrations must apply the CTR threshold to every cash-equivalent transaction flowing through their registered short codes. Any single M-PESA Pay Bill cash-in, branch cash deposit, or ATM cash transaction by an identified customer that reaches the USD 15,000 equivalent triggers a CTR filing obligation. Where same-day sub-threshold activity forms a pattern indicative of structuring, the correct response under FRC Circular No. 4 of 2023 is to file an STR, not a consolidated CTR.

For STR obligations, the bank must apply its transaction monitoring rules to M-PESA-sourced transaction data with the same rigour as branch transactions. Suspicious patterns identified in mobile money data require the same STR workflow as suspicious patterns identified in conventional banking channels.

Safaricom (M-PESA) is a reporting entity in its own right and files reports for suspicious activity and large transactions that are purely within the M-PESA wallet ecosystem. Safaricom's compliance obligations and the bank's compliance obligations are separate but complementary.

CBK Guidance on Mobile Money AML Reporting Obligations

The Central Bank of Kenya's AML/CFT supervisory framework includes specific guidance on mobile money AML obligations under CBK's revised Proceeds of Crime and Anti-Money Laundering (Amendment) Regulations. Key provisions relevant to banks with mobile money integrations include:

• The obligation to monitor mobile money transaction data alongside conventional banking transactions for per-transaction CTR threshold determination and structuring-pattern STR surveillance
• The requirement to apply customer due diligence to mobile money customers at the same standards as conventional banking customers, where identity can be verified
• The obligation to file STRs based on suspicious patterns identified in mobile money data, regardless of whether the suspicion originates from a branch transaction or a mobile money transaction

How to Classify Mobile Money Transactions in goAML XML

Kenya FRC's extended goAML validation profile requires mobile money transactions to be classified using FRC-specific transaction type enumerations. The correct classifications are:

Using generic transaction type codes (CASH_DEPOSIT, ELECTRONIC_TRANSFER) for mobile money transactions, rather than the FRC-specific enumerations, results in XML validation failures under the Kenya FRC validation profile. This is one of the most common causes of goAML rejection errors for institutions that have added mobile money data to their reporting without updating their transaction type mapping.

Agent Code Capture — Why It Matters for Investigations

When an M-PESA transaction is conducted through an agent (cash-in via an M-PESA agent rather than direct bank-to-M-PESA transfer), the Daraja API transaction record includes the agent's business code. Capturing and storing this agent code in the AML platform's transaction record is important for two reasons:

First, unusual agent code patterns are a risk indicator. A customer consistently making large deposits through agents in a specific geographic cluster, or through the same agent at unusual times, is a pattern worth examining.

Second, in an FRC investigation, the agent code is a critical piece of evidence linking a mobile money transaction to a physical location and a specific point-of-sale device. STR narratives that include agent codes provide FRC investigators with an investigative lead that is not available if the agent information was not captured.

---

Technical Challenges of Mobile Money Data for goAML

M-PESA Transaction Data Structure

M-PESA's Daraja API returns transaction records with a specific data structure that must be mapped to the goAML schema. Key fields in the Daraja C2B callback notification include:

• TransactionType: C2B, B2C, B2B, or inter-bank
• TransID: M-PESA's unique transaction identifier (alphanumeric, 10 characters)
• TransTime: Timestamp in YYYYMMDDHHMMSS format (requires normalisation to YYYY-MM-DD for goAML)
• TransAmount: Transaction amount as a numeric string (requires conversion to decimal with 2dp)
• BusinessShortCode: The Pay Bill or Till number receiving the payment
• BillRefNumber: The customer's account reference (what they enter as the account number — maps to the customer's bank account number if properly instructed)
• MSISDN: The sender's M-PESA phone number (key customer identity link)
• FirstName, MiddleName, LastName: The sender's M-PESA-registered name (may differ from bank KYC name)

The BillRefNumber field is critical for customer matching: if customers are instructed to use their bank account number as the Pay Bill reference, the AML platform can directly link the M-PESA transaction to the bank account and customer record. If customers use arbitrary references, automated customer matching requires fuzzy matching against the MSISDN-to-customer cross-reference table.

Matching M-PESA Transactions to KYC-Verified Bank Customers

The identity matching challenge is the most technically complex element of mobile money AML integration. M-PESA identifies customers by MSISDN; the bank's core banking system identifies customers by account number and customer ID. The two systems do not share a common key by default.

Effective matching requires maintaining a customer cross-reference table that maps MSISDN to bank customer ID, populated from the bank's mobile banking enrollment records (customers who have linked their M-PESA account to their bank account), from Pay Bill transaction history (where BillRefNumber is an account number), and from KYC records where national ID is linked to both M-PESA and bank accounts.

Unmatched transactions — where the M-PESA originator cannot be linked to a bank customer — are not exempt from AML monitoring. They must be monitored as anonymous mobile money transactions, with unusual patterns triggering STR consideration.

Multi-Channel Surveillance: Bank + Mobile Money

Cross-channel monitoring is technically demanding but conceptually clear. For each identified customer, the AML platform must track cash-equivalent activity across branch cash, ATM cash, M-PESA, Airtel Money, agent banking, and any other cash-equivalent channels — for two distinct purposes:

1. Per-transaction CTR detection: each individual cash transaction is evaluated against the USD 15,000 equivalent threshold in real time.
2. Structuring-pattern STR surveillance: sub-threshold activity across channels is analysed for splitting patterns that suggest deliberate threshold avoidance.

The technical requirements are:

1. All channels must be ingested into a unified transaction store
2. Customer identity must be resolved across channels (the same individual must be identified as the same customer regardless of which channel generated the transaction)
3. Detection must run in near-real-time so CTR cases can be filed within the Friday-of-week deadline
4. The detection logic must be auditable — for CTRs, the triggering transaction and applied exchange rate; for STRs, the set of transactions and the structuring pattern indicators

An institution that monitors branch and ATM transactions for threshold-reaching cash transactions but has not extended that detection to mobile money channels will systematically miss CTRs executed through M-PESA, Airtel Money, or agent cash-in/out.

SIM Card to Customer Identity Verification Challenges

The weakest link in mobile money identity matching is the reliability of SIM card-to-identity association. Kenya's National Identity and Registration Bureau has made significant progress in requiring national ID verification for SIM card registration, and Safaricom's KYC requirements for M-PESA account activation are among the most rigorous in sub-Saharan Africa.

However, SIM cards can be transferred between individuals (informal SIM lending), accounts can be operated by agents on behalf of beneficial owners, and SIM swap fraud can sever the link between a mobile number and its registered owner. AML monitoring that treats MSISDN as a reliable customer identity proxy without corroborating cross-checks against national ID will encounter accuracy limitations.

---

Best Practices for Mobile Money AML Compliance

Real-Time M-PESA Daraja API Integration for Threshold Monitoring

The most effective technical architecture for M-PESA AML monitoring uses the Daraja API's C2B callback mechanism to receive real-time notification of every M-PESA payment to the bank's Pay Bill. As each payment is received, it is logged in the AML platform, converted to USD equivalent using the documented exchange rate policy, and evaluated against the USD 15,000 threshold. If a single payment reaches the threshold, a CTR case is initiated intraday rather than at overnight batch. In parallel, the payment is contributed to the customer's structuring-surveillance window for STR-pattern detection.

Real-time integration also enables intraday STR alert generation for velocity patterns: if a customer receives ten M-PESA payments in a two-hour window from different senders, all of small amounts, the pattern can be flagged for investigation before end-of-day.

Cross-Channel Aggregation Engine

A cross-channel aggregation engine is the technical capability that makes unified mobile money AML monitoring possible. At minimum, the aggregation engine must:

• Evaluate every cash-equivalent transaction against the USD 15,000 equivalent CTR threshold in real time, applying the institution's documented exchange rate policy
• Resolve customer identity across channels using the MSISDN-to-customer-ID cross-reference
• Maintain per-customer rolling sub-threshold activity windows for structuring-pattern STR surveillance
• Route unmatched M-PESA transactions to an anonymous monitoring pool for unusual-pattern detection
• Raise STR review cases (not spurious CTRs) when sub-threshold patterns suggest deliberate splitting
• Retain the per-transaction detail required for CTR XML generation and STR case documentation

Mobile Money-Specific STR Indicators

The FRC publishes an indicator code list for use in STR submissions. Several indicators are specifically relevant to mobile money typologies:

• Indicators for structuring behaviour (multiple transactions below threshold in a pattern suggesting deliberate fragmentation)
• Indicators for layering through multiple payment channels (rapid fund movement across M-PESA, bank, and RTGS)
• Indicators for unusual agent banking patterns
• Indicators for mobile money account activity inconsistent with KYC profile

Compliance officers handling mobile money-related STR cases should be familiar with the full FRC indicator list and should select the most specific indicators applicable to the mobile money typology identified. Vague or generic indicator selection is one of the most commonly cited weaknesses in FRC examinations of STR quality.

Enhanced Narrative Requirements for Mobile Money Layering Cases

STR narratives for mobile money layering cases require specific technical detail that goes beyond what is needed for conventional banking STRs. An effective mobile money layering STR narrative should include:

• The specific M-PESA transaction IDs (TransID from Daraja) of the transactions of concern
• The MSISDN(s) involved and the M-PESA name(s) associated with them
• The timeline of the layering sequence with specific timestamps
• The agent code(s) if agent-facilitated transactions are involved
• The total value of the layering sequence and the destination of the funds
• The typology this pattern corresponds to (from FRC's typology guidance)
• The outcome of any KYC review conducted in connection with the case

This level of detail provides FRC investigators with the information they need to pursue the investigation beyond the STR filing itself. STRs that lack this detail are acknowledged by FRC but produce limited investigative value.

---

The Future of Mobile Money Compliance in Kenya

CBK Digital Currency (CBDC) Implications

The Central Bank of Kenya has been actively studying Central Bank Digital Currency (CBDC) as part of its broader digital payments strategy. A Kenyan CBDC, if implemented, would introduce a new programmable electronic payment channel with potentially significant AML implications: the same attributes that make CBDC attractive for financial inclusion (low transaction cost, programmable transfer restrictions) also create design decisions that directly affect AML monitoring capability.

Compliance teams should engage with CBK's CBDC consultation process and understand how digital currency transactions would be reported and classified in goAML XML when the framework is finalised.

New Payment Service Providers Expanding the Reporting Scope

CBK's licensing of additional payment service providers under the National Payment System framework is expanding the universe of regulated mobile money and digital payment channels. Fintechs offering digital wallets, buy-now-pay-later products, merchant payment solutions, and cross-border remittance services are becoming licensed reporting entities.

For banks with partnerships or integration relationships with these PSPs, the AML implication is that the bank's obligation to monitor transactions that flow through partner PSP channels must be assessed and addressed.

Platform-Level AML Requirements for M-PESA

Safaricom implements its own transaction monitoring and suspicious activity reporting on the M-PESA platform, applying AML rules at the platform level before any transactions reach the connected banking layer. As regulatory expectations for MNO-level AML compliance increase, Safaricom's internal AML capabilities are improving — which is positive for the overall integrity of the Kenyan financial system but does not reduce any individual bank's reporting obligation.

Banks should not assume that Safaricom's AML monitoring covers their reporting obligations. The FRC expects each licensed reporting entity to maintain its own AML monitoring and reporting capability for the transactions within its regulatory perimeter.

---

Take the Next Step

Creodata's goAML AML Reporting Platform includes native M-PESA Daraja API integration, Airtel Money API integration, cross-channel aggregation, and Kenya FRC-specific mobile money transaction type support. Compliance teams using the platform monitor M-PESA, Airtel Money, branch, and ATM transactions through a unified threshold monitoring engine — with full goAML XML generation and FRC submission capability for both CTR and STR reports.

See the mobile money integration capabilities in a live demonstration: Request a Demo at creodata.com/demo