Transaction Monitoring Software in Kenya: Channels, Typologies and What the FRC Expects

Short answer: Transaction monitoring software checks every transaction against rules and models that describe money-laundering patterns, and raises alerts for analysts to investigate. In Kenya it has to see cash, mobile money and agent transactions as well as bank transfers, detect local patterns such as structuring below the cash reporting threshold, and carry an alert through to a suspicious transaction report to the Financial Reporting Centre (FRC) with the evidence intact.

Monitoring is a legal duty in Kenya. Section 44(1) of the Proceeds of Crime and Anti-Money Laundering Act (POCAMLA) requires reporting institutions to monitor complex, unusual, suspicious and large transactions on an ongoing basis, and section 44(2) requires a report to the FRC within two days after a suspicion arises. Separately, cash transactions of US$15,000 or more must be reported by the Friday of the week in which they occurred (section 44(6) and regulation 40 of the POCAML Regulations, 2023). The law does not prescribe automated monitoring, and the Central Bank of Kenya's 2025 guidance on customer due diligence accepts manual or automated systems, but manual review struggles to keep pace once volumes and channels grow.

This guide is for MLROs, compliance analysts and the IT teams that support them at Kenyan banks, SACCOs, microfinance institutions, payment providers and digital lenders. It is a practical guide, not legal advice. Creodata sells transaction monitoring software as part of its AML suite, and we say where it fits near the end.

What transaction monitoring software does

Monitoring sits between your transaction data and your analysts:

1. Data comes in from core banking, mobile money, card and payment systems, in batches or as a stream.
2. Rules and models run over each transaction and over patterns across many transactions, compared with what is normal for that customer or segment.
3. Alerts are raised where a pattern matches, with the data that triggered them.
4. Analysts investigate in a case, request information, and decide whether the activity is suspicious.
5. The MLRO decides whether to report, and a suspicious transaction report goes to the FRC through goAML.

Monitoring is different from screening. Sanctions and PEP screening checks who a customer or counterparty is; monitoring looks at what they do. Most institutions need both, sharing one record of the customer.

The channels a Kenyan system has to see

Money moves quickly between channels in Kenya, and a pattern that is invisible in one channel is often obvious across several. The first question for any vendor is which of your channels its data model covers.

Our guide to mobile money AML reporting in Kenya looks at the wallet channel in more detail.

Kenyan typologies to encode

A typology is a known method of laundering money. Rules should be written for the typologies that match your products and customers, not copied from a generic library. Patterns that Kenyan institutions commonly monitor include:

• Structuring below the cash reporting threshold. Several cash deposits just under US$15,000, split across days, branches or agents, or made by different people into one account. The FRC's Circular No. 4 of 2023 says same-day cash transactions below the threshold in a single account are not added together for a cash transaction report, but institutions should understand why and file a suspicious transaction report if the pattern is unusual.
• Rapid pass-through. Funds arrive and leave within hours, often moving between bank accounts and mobile wallets, leaving a near-zero balance.
• Mule accounts. A new or dormant account suddenly receives many transfers from unrelated senders and sends the money on quickly.
• Activity out of line with the profile. Turnover far above the declared income or business type, such as a salaried member moving business-sized volumes.
• Third-party cash into member or customer accounts. Deposits by people with no evident relationship to the account holder.
• Early settlement of loans with cash or third-party funds. A way to give illicit money the appearance of a repaid loan.
• Cross-border flows to or from higher-risk jurisdictions that do not fit the customer's profile.
• Round-tripping between related accounts or companies to create the appearance of legitimate turnover.

The STR indicator library for Kenya and the guide to money laundering typologies describe these patterns and the indicators behind them.

Rules, behavioural analytics and machine learning

Rules are explicit conditions, such as "three or more cash deposits totalling more than a set amount within five days". They are transparent and easy to explain to an examiner, but a single threshold for every customer creates noise. Segmenting rules by customer type, such as individuals, SMEs and SACCO members, helps.

Behavioural analytics compare a customer's activity with their own history and with peers, so a sudden change stands out even when no fixed threshold is crossed.

Machine learning can prioritise alerts or find patterns that rules miss, but only if every score can be explained and a human makes the decision. Ask vendors how a model's output is explained, who approves a model before it goes live, and how it is switched off. The guide to explainable AI in AML sets out the controls.

Most institutions start with well-tuned rules and add analytics once their data is reliable.

Back-testing and tuning: where most monitoring fails

A rule that has never been tested against your data is a guess. Before a rule goes live, run it over historical transactions to see how many alerts it would have produced and how many of those were useful. After go-live, review each rule's alert volumes and outcomes on a regular cycle, adjust thresholds with documented reasons, and keep the old version.

Examiners ask why thresholds are set where they are. A monitoring system should let you answer with the back-test, the approval and the version history, rather than with the vendor's default settings. Our guide to reducing false positives covers the same discipline for screening alerts.

From alert to suspicious transaction report

The monitoring system is only as good as what happens after the alert:

• Triage and case creation with an owner, a deadline and the transactions that triggered the alert.
• Investigation, including requests for information from branches or relationship managers and, where needed, enhanced due diligence.
• An MLRO decision on whether the activity is suspicious, recorded with reasons.
• Restricted access to suspicion-related cases, because disclosing that a report is being prepared or has been sent is a tipping-off offence under section 8 of POCAMLA.
• Reporting through goAML, with the report tracked to acknowledgement; see the goAML Kenya guide.
• Records of the alert, the investigation and the decision, kept for at least seven years (POCAMLA section 46(4)) and retrievable for an inspection.

The AML case management guide walks through this workflow in detail.

Data requirements

Monitoring fails quietly when data is incomplete. Before you buy, check that you can supply:

• A customer master with risk rating, customer type, occupation or business type and expected activity.
• Account data linking accounts, wallets and cards to customers.
• Transaction data with amount, currency, date and time, channel, direction and counterparty details.
• Agent, branch and device identifiers where the channel has them.
• Reliable, complete feeds, with a way to detect and replay a failed load.

The guide to AML data quality and ingestion explains how to test this.

Questions to ask transaction monitoring vendors

Our free AML vendor RFP checklist includes these questions with a scoring spreadsheet, and the buyer's guide to AML compliance software in Kenya covers the rest of the evaluation.

Where Creodata fits

Creodata's AML compliance software built for Kenya includes transaction monitoring with its own rule language, running in batch and streaming, with typology-aligned starter rules, a back-test harness, a tuning lab and versioned rule promotion. Data arrives through REST, SFTP, Kafka, change data capture or ISO 20022 connectors with replay and a dead-letter queue, so a failed load is visible. Alerts flow into case management with enhanced due diligence and MLRO approval, and suspicious transaction reports hand off to our goAML Reporting Platform for the FRC filing. Where AI is used, every score shows its reasons and a human decides. If monitoring is your priority, book a demo and bring a week of anonymised transactions.

For institution-specific angles, see AML software for SACCOs in Kenya and AML compliance for fintechs and digital credit providers.

Frequently asked questions

What is transaction monitoring in AML?

Transaction monitoring is the ongoing review of customers' transactions to detect activity that may involve money laundering or terrorist financing. Software applies rules and models to transaction data, raises alerts on suspicious patterns, and routes them to analysts, who investigate and decide whether a suspicious transaction report is needed.

Is transaction monitoring mandatory in Kenya?

Yes. POCAMLA section 44(1) requires every reporting institution to monitor complex, unusual, suspicious and large transactions on an ongoing basis. The law does not require a particular technology, and the CBK's 2025 guidance on customer due diligence accepts manual or automated systems. Some sector rules go further: SASRA's 2024 guidelines require regulated SACCOs to monitor member transactions continuously against their risk profile, supported by an integrated ICT systems module.

Should transaction monitoring be real-time?

It depends on the channel and the risk. Real-time monitoring matters where money can leave before a batch runs, such as instant transfers and mobile money. Many patterns, such as structuring over several days, are better detected in scheduled runs across a longer window. Most institutions use both, and good software lets the same rule logic run in either mode.

How do we reduce false positives in transaction monitoring?

Segment rules by customer type, set thresholds from back-tests on your own data rather than vendor defaults, and review each rule's alert outcomes on a regular cycle. Improve the data behind the rules, because missing occupation or expected-activity fields create alerts that analysts close immediately. Document every threshold change so the tuning itself can be defended.

Can transaction monitoring software detect structuring below the cash reporting threshold?

Yes, if it can aggregate a customer's cash activity across days, branches, agents and depositors. That matters because a cash transaction report only covers transactions of US$15,000 or more, and the FRC expects splitting below that line to be assessed for a suspicious transaction report instead. Ask vendors to demonstrate structuring detection on sample data that splits deposits across locations and people, and to show how the resulting alert reaches a case and, if needed, a report to the FRC.

What data does transaction monitoring software need?

At minimum, a customer master with risk information, the links between customers and their accounts or wallets, and transaction records with amount, date, channel, direction and counterparty. Agent, branch and device identifiers add value where available. Feeds need to be complete and monitored, because a failed load is a gap in monitoring.

---

See Creodata's transaction monitoring software run on your own scenarios in a 30-minute demo, or score vendors with the free AML vendor RFP checklist.