Ogowkey v1
← All articles
10 min read Ogowkey team

AML compliance for East African fintechs: sanctions, PEPs and adverse media

What AML actually looks like for an East African fintech - which lists matter, how to handle false positives, and the screening pipeline that survives a regulator's audit.

amlcomplianceeast-africafintech

Anti-money-laundering compliance is the difference between a fintech that scales and a fintech that gets de-banked. In East Africa, where the regulatory environment is maturing fast and the cross-border flows are large, AML is also one of the operational tasks most often done badly. The screening services are uneven, the false-positive rates are punishing, and the rules vary materially between Somalia, Kenya, Uganda, Tanzania and Ethiopia.

This guide walks through what AML compliance actually looks like for an East African fintech in 2026: which lists matter, how to design a screening pipeline that won't break under real volume, and how to handle the false-positive problem that consumes most compliance teams.

What AML is and isn't

AML compliance has three operational pillars:

  1. Customer due diligence (CDD) - knowing who your customer is. This is where KYC lives. See our KYC in Somalia guide for the East African specifics.
  2. Sanctions and PEP screening - checking your customer (and their counterparties) against lists of sanctioned persons, politically exposed persons, and people in adverse media.
  3. Transaction monitoring - watching for patterns that look like layering, structuring, or terrorist financing, and filing suspicious activity reports when you see them.

This article focuses on the second pillar - the screening side - because that's where the most fintechs trip up on day one.

Which sanctions lists matter

Sanctions screening is a coverage problem. You need to be checking against every list that's relevant to your business and your jurisdiction.

Hard-required lists

  • OFAC SDN (US) - the Specially Designated Nationals list. Most consequential globally because of the secondary-sanctions exposure for any institution touching the dollar.
  • OFAC SSI (US) - Sectoral Sanctions Identifications.
  • OFAC consolidated - includes non-SDN lists like the Foreign Sanctions Evaders.
  • EU consolidated - the European Union financial sanctions list.
  • UK HMT - the UK consolidated list.
  • UN consolidated - UN Security Council sanctions.

If you skip any of these, you're betting your fintech that no customer or counterparty appears on them. That's not a bet worth making.

Strongly recommended

  • Switzerland SECO, Australia DFAT, Canada OSFI - useful for breadth and often catch names the others miss for a few days.
  • OpenSanctions - a free aggregated dataset that consolidates the above plus dozens of others. Practical for low-budget startups.

Africa-specific

  • East African Community (EAC) lists where they exist.
  • National lists for the countries you operate in (Bank of Somalia issues circulars naming specific entities; Bank of Uganda likewise).

Politically Exposed Persons (PEPs)

PEPs are not sanctioned, but transactions involving them require enhanced due diligence under FATF guidance. The PEP universe is much larger than the sanctions universe (think: every cabinet minister, judge, central bank governor, parastatal CEO, and their close family members, across every country). You need a curated PEP dataset. We use a combination of OpenSanctions PEP data and a commercial provider for specific country depth.

Adverse media

Searches against news media for negative coverage - fraud, corruption, organised crime - that doesn't yet appear on sanctions lists. This is where the genuinely sophisticated AML programmes catch threats early. It's also where false positives proliferate, because a name match against a news article is almost always wrong.

The matching problem

The hard problem in screening is not finding the lists. It's matching names against them in a way that catches real hits without drowning your compliance team in false positives.

Why exact match isn't enough

Sanctions lists publish names in transliterated English. Your customer's name comes in via OCR from a Somali ID card, in Somali transliteration. "Maxamed Cabdullaahi" and "Mohamed Abdullahi" are the same person. Your name-matching has to handle:

  • Transliteration variants - Somali uses X for Kh, C for the glottal stop, Q for K (sometimes). A naive comparison treats these as different people.
  • Name order - surname-first in some lists, given-name-first in others.
  • Compound names - Arabic-derived names with multiple components. Which one is the "surname"?
  • Spelling variants - Mohammed, Mohamed, Muhammad, Mahomed all match.
  • Initials - "M. A. Abdullah" should match "Mohamed Ahmed Abdullah".
  • Missing components - the sanctioned individual is "Mohamed Ahmed Hassan Ali"; your customer presents as "Mohamed Hassan". Is that the same person?

A good matcher uses fuzzy comparison (Jaro-Winkler, edit distance, phonetic algorithms) tuned with thresholds that vary by name length and rarity. A common name like "Mohamed" matched at 0.85 is meaningless; an uncommon name like "Mohamed Said Barre" matched at 0.85 is almost certainly the same person.

Date of birth and country as filters

Sanctions list entries almost always include date of birth (sometimes a year, sometimes a full date) and country. Use these as filters, not as match requirements:

  • If both DOBs are known and they're more than a few years apart, suppress the match.
  • If countries are both known and don't overlap (and your customer is verified at a specific country of residence), reduce the match score.
  • Never require DOB to match - sanctions data is often partial.

The threshold trade-off

There's no perfect threshold. You're trading false negatives against false positives.

  • High threshold (0.95+): catch only obvious matches, miss subtle ones. False negative risk.
  • Low threshold (0.75): catch everything, but your compliance team drowns. False positive risk.

The realistic operating point for retail East African fintechs is around 0.82–0.88, with multiple per-name signals combined: name similarity + DOB compatibility + country signal + rarity weighting. Your false-positive rate at this operating point will still be 5–15% of all customers. Plan for it.

Building the screening pipeline

A defensible pipeline runs at three points:

1. At onboarding

Every new customer is screened at sign-up, before they can transact. This catches the most obvious case: someone trying to onboard a wallet using a name that's on OFAC.

The screen runs against the full list set. Hits go to a queue for manual review.

2. On every transaction counterparty

For transfers, screen the counterparty - the recipient name, especially for cross-border or large transfers. This is where you catch the case where the customer is clean but is sending money to a sanctioned entity.

For mobile-money wallet-to-wallet transfers within Somalia, this is usually a no-op because the recipient is also a verified customer of one of the local rails. For cross-border, it's mandatory.

3. On a recurring basis

Sanctions lists update. A customer who was clean at onboarding can appear on OFAC tomorrow. You need to re-screen your existing customer base on a recurring schedule - daily for high-risk segments, weekly for the rest is a defensible minimum. Use the list-provider's delta API if available, so you only screen against the day's changes.

Handling false positives

False positives are the single biggest operational drag on AML. You will spend more compliance hours dispositioning false positives than investigating real ones. Two practices keep this under control:

Build a clearance memory

When a compliance officer clears a customer against a specific sanctions entry, store that clearance. The next time the same customer matches the same entry (and the underlying entry hasn't changed), suppress the alert. You do not want your team re-clearing the same false positive every time you re-screen.

Track and tune

Every cleared false positive is a tuning signal. After 1,000 clearances, you should be able to see patterns - specific entries that produce false positives because they're common names, specific match types that are unreliable. Tune your matching parameters in response. A static screening config that runs untouched for a year is a sign of a compliance programme that isn't learning.

What the regulator expects

When a regulator audits your AML programme, they're not looking for zero hits. They're looking for evidence of process. Specifically:

  • A documented policy - your AML policy, signed off by the board.
  • Risk assessment - a written document explaining your risk model (which customer segments, products, geographies you regard as higher-risk).
  • Screening at the right points - onboarding, transactions, recurring.
  • List coverage - which lists you screen, why, how often you update them.
  • Disposition records - every hit, who cleared it, the reasoning.
  • SAR filings - where applicable, evidence you filed suspicious activity reports when you should have.

The audit trail is what matters. A clean compliance file with documented decisions wins audits; a perfect false-positive rate without documentation loses them.

Cost realities

Commercial AML data is expensive. Top-tier providers (ComplyAdvantage, Refinitiv, Dow Jones) charge $30k–$150k+ per year for a startup. For a fintech with 5,000 users on day one, that's a lot.

The pragmatic stack for a starting East African fintech:

  • OpenSanctions (free) for the consolidated sanctions and PEP coverage.
  • A name-matching engine you build or license - this is the load-bearing piece.
  • A simple adverse-media search against major regional outlets (BBC, Reuters, Al Jazeera).
  • Upgrade to a commercial dataset when you're past 50k users and the marginal cost of a missed match is bigger than the licence fee.

Ogowkey's AML screening uses this stack out of the box - OpenSanctions plus a Somali-tuned matcher plus an adverse-media search - so you don't have to build it on day one. The API returns a clear / review / hit decision and an explanation. See the playground to test cases.

Closing

AML compliance is not glamorous, and "ship faster" is rarely the right answer when a regulator is going to ask hard questions in 18 months. The teams that build durable East African fintechs treat AML as a first-class operational system, not a feature. Get the list coverage right, build a name-matcher that handles regional name conventions, and instrument every clearance decision. The rest follows.

If you want to talk through your AML pipeline before launch, [reach out](mailto:olow304@gmail.com?subject=Ogowkey%20 - %20AML). For the broader compliance picture, our KYC in Somalia guide is the companion piece.