Three Analysts, 900 Alerts a Week: How a Microfinance Lender Broke Its False-Positive Backlog

Composite scenario drawn from typical East African deployments. Institution details are anonymised and figures are representative rather than attributable to a single client.

A queue nobody could finish

A microfinance institution operating across Kenya and Uganda had grown from 40,000 to 210,000 customers in three years. Its AML controls had not grown with it.

Screening ran nightly against a sanctions and PEP list. Every morning the compliance team — three analysts and a manager — found somewhere between 700 and 900 new alerts waiting. Almost all were name matches: a customer called Mohamed Ali matching a listed Mohamed Ali in another country, born in another decade, with no other attribute in common.

The team cleared what it could. The backlog grew anyway. By the time we were called in, alerts older than six weeks were being closed in bulk with a standard comment, because the alternative was never closing them at all.

That is the failure mode worth naming: the control had not been switched off. It had been rendered meaningless by volume, which is worse, because the board still believed it was working.

Why the noise was so loud

Three design decisions were producing it.

Screening compared strings, not entities. The matching logic looked at name similarity and little else. Date of birth, nationality, identifier numbers and address were captured in the core system but never reached the screening engine. A match on two common Swahili or Arabic given names scored the same as a match on a full name plus a matching passport number.

Transliteration was unhandled. Customers appeared as "Mohammed", "Mohamed", "Muhammad" and "Mohammad" across different onboarding channels. The list had its own variants. The engine treated every pairing as a distinct potential hit.

There was no risk context. A dormant savings customer with a KES 3,000 balance generated the same alert, with the same urgency, as a corporate borrower moving significant volumes. Nothing in the queue told an analyst where to start.

Underneath all three sat a fourth problem: no memory. An alert cleared in March reappeared in April, and was worked again from scratch.

What we built

The institution moved onto the Creodata AML Platform, deployed on Kubernetes in its own data centre to satisfy a data-residency requirement. The rebuild had four parts.

Entity resolution before screening. Customers are resolved into entities that carry every available attribute — identifiers, dates of birth, nationality, related parties and beneficial-owner links — and it is the entity, not the name string, that is screened. Multi-script matching handles transliteration variants natively rather than treating them as separate candidates.

Risk-weighted alerting. Customer risk is assessed across six factors, and alerts inherit that context. The queue is ordered by risk, so the analyst opening it at 8am sees the corporate borrower before the dormant savings account.

Decision memory. Dispositions persist. A cleared false positive does not return next month unless something about the entity or the list entry has materially changed — and when it does return, the analyst sees what changed and what was decided last time.

Explainable scoring. Where the platform's models contribute to a score, the reasoning is exposed with SHAP-based attribution and logged. This was not a nice-to-have. The institution's regulator had made clear it would not accept a model whose output could not be explained to a customer or an examiner, and the platform's four-eyes approval and kill-switch controls on model changes were what made the risk committee comfortable signing off.

Transaction monitoring was layered on afterwards, using the rule DSL to encode typologies the team already understood — structuring below reporting thresholds, rapid pass-through, unusual cross-border corridors — rather than importing a generic rule pack.

Where it landed

Alert volume fell to roughly 60 to 90 per week. That is not a 90% reduction in risk coverage; coverage went up, because transaction monitoring was added. It is a reduction in the ratio of noise to signal.

More useful than the volume number: the team began closing alerts within the same week they were raised, and the manager could tell the board, accurately, that the queue was current. Enhanced due diligence cases that would previously have been buried in the backlog got worked properly, and two of them produced STRs the institution would not otherwise have filed.

Reporting closed the loop. SARs and STRs are drafted from the case file itself and submitted through the platform's FRC Kenya integration, with goAML as the fallback path for the Uganda entity. The narrative, the linked transactions and the screening evidence stay together.

The lesson worth taking

A screening system that produces alerts nobody can work is not a partially effective control. It is an ineffective control with a compliance cost attached, and examiners increasingly treat it that way.

If your team is closing alerts in bulk to keep pace, the honest first question is not "how many more analysts do we need". It is "why is this queue full of matches that were never plausible" — and the answer is almost always that the engine is comparing names when it should be comparing entities.

Further reading: The Complete AML Platform Guide · How to Reduce False Positives in AML Screening Without Missing Real Risk

---

Working through an alert backlog? Book a consultation or explore the AML Platform to see how entity resolution and risk-weighted alerting change the shape of the queue.