Category: AML & Financial Crime

New fintechs and payment startups need AML controls early — regulators expect it, and retro-fitting compliance is painful and expensive. But “early” doesn’t mean copying a tier-1 bank’s programme; it means building controls proportionate to your actual risk. Here is where to begin without over-engineering, from someone who has seen both sides.

Start risk-based

Assess the money-laundering risk of your products, customer types and geographies before you buy or build anything. Concretely: can your product move value fast or anonymously? Do you onboard remotely? Do you serve higher-risk industries or corridors? Write the assessment down, have leadership own it, and let it drive every control decision that follows. Your controls should be proportionate to that documented risk — not to a template.

KYC and customer due diligence

Verify identity at onboarding, apply enhanced due diligence to higher-risk customers, and capture beneficial ownership for business accounts. The design challenge is balance: friction kills conversion, but gaps create risk. Modern eKYC (document capture plus liveness) keeps onboarding smooth while meeting the requirement — provided you tune it and test it like any other control, and treat the identity data it produces as the foundation your monitoring and screening will later depend on.

Monitoring and screening

Add transaction monitoring and sanctions/PEP screening sized to your risk. Start with a handful of well-tuned scenarios rather than dozens that generate noise — and plan for evidence-based tuning from day one, because your first thresholds will be wrong in both directions. The same goes for screening: calibrate matching and use secondary identifiers early, or analyst time disappears into false hits.

Governance: the part startups skip

• Name an accountable owner (MLRO or equivalent) with real authority and access to the board.
• Write the policy you actually follow — a short, honest AML policy beats a 60-page template nobody has read.
• Train the team — especially engineering and support, who see the product’s abuse patterns first.
• Keep records — onboarding evidence, alerts, decisions and reports, retained per your regulator’s rules.
• Review independently — an annual health check catches drift while it’s still cheap to fix.

Tooling and RegTech

Decide buy vs build early. For most startups, buying screening and monitoring and building the integration is the right split — your engineers’ time belongs in your product. Plan integrations properly and validate them with real API testing: a screening service your checkout never actually calls is an expensive false comfort. The right RegTech, configured well, scales with you; the wrong one, configured badly, is a compliance incident on a subscription.

Mistakes that cost startups later

• Treating AML as a launch blocker to minimise rather than a control to design — regulators read that story in your file later.
• Buying tools before writing the risk assessment — you’ll configure them to the vendor’s defaults, not your risk.
• No plan for growth — thresholds and headcount that work at 10k customers collapse at 100k. Build the tuning habit early.
• Ignoring security — your KYC data is exactly what attackers want. Compliance and information security mature together or not at all.

These notes are educational — shared so founders know what “good” looks like before the first regulator meeting. If you’re weighing up outside help, here’s what to look for when hiring a consultant. And for the cybersecurity, GRC and data-protection side of your build — securing the stack that holds all this data — see my services or get in touch.

Sanctions and PEP screening stops your business from dealing with prohibited or high-risk parties. Done poorly, it buries analysts in false hits; done well, it catches real risk without the noise. Striking that balance is a design problem, not a staffing problem — here is how it’s done, from practice.

Why false hits pile up

Fuzzy name matching, transliteration across scripts, common names and out-of-date lists all generate alerts that aren’t true matches. Arabic names are a textbook case: one name may be romanised half a dozen ways (Mohammed, Muhammad, Mohamad…), so engines widen their nets — and every widening multiplies noise. Left untuned, teams spend their day clearing hits that a better configuration would never have raised.

Tune the matching logic

• Calibrate fuzzy-match thresholds to your risk appetite. A remittance business and a private bank should not run the same similarity score. Test candidate thresholds against historical hits before committing.
• Use secondary identifiers. Date of birth, nationality and country of residence auto-discount weak name-only matches. A “John Smith” hit with a mismatched birth year should never reach an analyst.
• Match on the right fields. Screen the parties that matter (originator, beneficiary, their banks) and normalise the data first — trimmed whitespace, consistent casing, resolved abbreviations.
• Maintain governed whitelists (“good guys”) with owners and review dates — not ad-hoc suppressions that quietly accumulate risk.

A disposition workflow that scales

Structure the analyst’s decision, don’t leave it to style: confirm the name similarity, check secondary identifiers, check the list entry’s context (is the sanctioned party even plausible for this customer type?), then disposition with a reason code. Consistent reason codes are what let you tune later — they tell you why hits are false, which is the raw material for threshold and rule changes.

Keep your lists current

Coverage matters: OFAC, UN, EU, UK and your local regulator’s lists, refreshed on a defined cadence, with evidence the updates were applied. The strongest programmes treat list updates like patch management — automated where possible, monitored, and alarmed when a feed fails. An out-of-date list is a silent control failure: everything looks green while the screen misses new designations.

Governance and audit

• Document every tuning decision — the analysis, the testing, the approval — just as you would for transaction-monitoring thresholds.
• Apply four-eyes approval to whitelist entries and rule changes; they are exactly where a bad actor or an error hides.
• Report KRIs — hit volumes, false-hit rates, clearance times and list-update timeliness — so management and auditors can see the control working.
• Re-screen on list updates, not just at onboarding. Designations change; your exposure does too.

Common mistakes to avoid

• Chasing a zero-hit queue. A screen that never alerts is a screen that misses; the goal is signal, not silence.
• Suppressing by name string alone. Whitelist specific parties with identifiers, or you’ll suppress the next genuine match too.
• Ignoring data quality. Screening inherits every defect in your KYC data — fix the identifiers and the matching improves for free.

These notes are educational — practitioner lessons for teams running their own screening. If you’re building a programme from scratch, start with AML compliance for fintechs and startups. And when the challenge is cybersecurity, GRC or data protection, that’s what I do — see my services or get in touch.

Every AML team knows the pain: a transaction-monitoring system that fires thousands of alerts, most of which turn out to be nothing. Left unchecked, false positives bury analysts, delay genuine investigations and inflate cost — without improving detection. The good news is that tuning is a structured, repeatable discipline, not guesswork. These are the lessons I’ve learned doing it in practice, written up so your team can apply them.

Why false positives pile up

Most monitoring scenarios ship with conservative, one-size-fits-all thresholds. They ignore customer segmentation, expected behaviour and the institution’s actual risk appetite. The result is alerts on perfectly normal activity — salary payments flagged as “structuring”, routine remittances flagged as “high-velocity”. Three patterns show up in almost every noisy system:

• Global thresholds — one limit applied to a student account and a trading company alike. Neither is monitored well.
• Scenarios nobody retires — rules added after every audit finding or typology paper, never reviewed again, overlapping and re-alerting on the same behaviour.
• Data quality gaps — missing occupation codes, stale expected-turnover figures and unmapped transaction types force scenarios to fire “just in case”.

A tuning workflow that holds up

1. Baseline — measure each scenario’s alert volume and true-positive rate over the last 6–12 months. You cannot improve what you haven’t measured.
2. Segment — group customers by risk band, product and expected behaviour. Thresholds belong to segments, not to the whole bank.
3. Hypothesise — propose a specific change (“raise threshold X for retail salary accounts”) with the expected effect on volume and detection.
4. Test on history — replay the proposed setting against historical data and compare outcomes before touching production.
5. Deploy and monitor — apply the change under change-control, then watch volumes and dispositions for a full cycle to confirm the effect matched the hypothesis.

Tune with evidence, not instinct

• Segment first. Tune thresholds per customer risk band and product, not globally. The same scenario can be quiet and accurate in one segment and useless in another.
• Use historical alert outcomes. Pull 6–12 months of alerts and their dispositions to see where productivity (true positives) actually lives — it is rarely where the noise is loudest.
• Change one variable at a time so you can attribute the effect. Simultaneous changes make results unreadable and un-defendable.

Above-the-line and below-the-line testing

Before you move a threshold, sample alerts just above and just below the proposed line. Above-the-line testing confirms you still catch the risk you care about; below-the-line testing proves you are not about to miss productive alerts. Size the samples so the conclusion is statistically defensible, disposition them with your normal investigation standards, and record the results. This evidence is exactly what regulators and auditors expect to see behind every threshold change.

Data quality is half the battle

A surprising share of “tuning” problems are really data problems. If customer segments are stale, occupation and expected-activity fields are empty, or transaction codes are mapped inconsistently, no threshold will behave sensibly. Fix the feeds — and the KYC data they depend on — alongside the scenarios, or you’ll tune yourself into a corner. The same discipline applies to sanctions and PEP screening, where matching quality lives and dies on identifiers.

Make it audit-ready

Document the rationale, the data sample, the testing and the sign-off for every change in a scenario register. When the regulator or internal audit asks “why is this threshold set here?”, the answer should already be written down. A good register carries, at minimum:

• Scenario purpose — the typology or risk it exists to detect, in one sentence.
• Current parameters — thresholds, segments and the date they took effect.
• Evidence — the analysis and above/below-the-line results behind each change.
• Approvals — who proposed, who reviewed, who signed off, under which governance forum.
• Review date — when this scenario will next be re-validated.

This is the same “understand your risks, manage them deliberately, prove it” discipline that underpins an ISO 27001 ISMS — good governance looks the same whichever control you point it at.

Common mistakes to avoid

• Tuning to reduce volume alone. The goal is better detection per analyst hour, not a smaller queue at any cost.
• Skipping below-the-line testing because “the change is obviously safe”. That sentence appears in a lot of audit findings.
• One-off projects. Behaviour, products and typologies drift; tuning is an annual-at-least cycle, not a rescue mission.

These notes are educational — the field lessons of a practitioner, shared for teams building the same muscles. If you’re a fintech starting from zero, begin with AML compliance for fintechs and startups. And if your challenge is on the cybersecurity, GRC or data-protection side, that’s exactly what I offer — see my services or get in touch.