Why EMIs are rethinking how AML screening and monitoring fit together

It’s a familiar scene for Electronic Money Institutions (EMIs): a screening tool fires a hit on a customer; minutes later, the monitoring engine fires a separate alert on the same person. Two analysts work the case from different queues without realising, and before anyone connects them, an instant payment is halfway to a mule account in another jurisdiction.

This is because of the AML stack most EMIs inherited from a simpler era. It doesn’t fit the business anymore, and that’s beginning to be a concern for regulators.

What changed for EMIs

EMIs are no longer treated as “fintech lite”. Under the EU AMLD framework and the UK Money Laundering Regulations, they carry the same CDD, monitoring, SAR and governance obligations as a bank, but operate nothing like one.

There are four key problems:

• Instant rails have no buffer: SEPA Instant and Faster Payments both clear in seconds, so by the time a T+1 monitoring rule fires, the money has hopped twice.
• Fraud and AML have merged: account takeover flows into mule payouts, romance scams end in laundering chains, and regulators expect EMIs to detect the AML side of fraud, not just process chargebacks.
• Most EMIs operate across several jurisdictions: a Lithuanian licence, a UK partnership, customers in the Baltics and beyond, with each supervisor’s risk appetite, expectations and typology focus defying a single global rule set.
• Customer expectations are brutal: any hold or “please verify” message becomes a support ticket and Trustpilot review, while regulators reject customer experience as an excuse for weak controls.

In short, bank-grade AML must run on EMI rails, with the constraints of fewer staff and higher customer expectations.

What good architecture looks like

The EMIs that pass audits run screening, monitoring and risk scoring as one decision layer, with each capability fed by the others. For them, sanctions screening is zero-tolerance and real-time; PEP and adverse media screening is risk-based. That’s standard. What’s less so is screening that produces usable context, not just a binary hit/no-hit, but match confidence, which list triggered it, whether the customer has been cleared before, and how their screening behaviour has shifted.

This doesn’t require new data. It uses data they already collect, but in the correct context. Device IDs, IP ranges, login anomalies, recent profile changes, velocity spikes, new beneficiaries added minutes before a high-value transfer, customers who contacted support in distress then tried to increase their limit — all sits in fraud systems, product logs and CRM tables, but for most EMIs, little reaches the AML monitoring engine.

Smart EMIs use it to make scenarios sharper. Instead of “high-value payment to high-risk country,” which fires constantly to little effect, the rule can be: new device + unusual country + first high-value outgoing instant payment within 30 minutes of a phone number change → block and escalate. That rule catches account takeover but barely fires for legitimate customers.

Risk scoring must keep up. Static onboarding ratings are a compliance fiction. Customers drift and fraud happens, so the score should recalculate as new signals arrive and feed back into the monitoring engine so a customer crossing a threshold automatically picks up tighter scenarios. A risk score in a CRM record that isn’t read by anything downstream is useless.

Screening context belongs inside monitoring rules

Most vendors treat screening and monitoring as separate products: screening sees the customer’s name and details, monitoring sees the transaction, and the alerts go into separate queues. What I wish I’d understood earlier is that the signals are most valuable together.

A near-miss PEP match is interesting. Combine it with a sudden 10x increase in outgoing volume to a new beneficiary in a higher-risk corridor and it becomes actionable. A sanctions match confidence score of 62% on a common name is usually a false positive, but if that counterparty appears in three other customers’ outgoing payments that week, a mule ring is lighting up.

Here’s the rule pattern that unlocks this:

IF customer has any screening context in the last 90 days (cleared PEP, adverse media hit, near-miss sanctions) AND transaction crosses velocity/counterparty thresholds → elevate risk score and route to enhanced review.

A monitoring engine can’t run that unless it can read screening outcomes as a data field. Those that can, in my experience, cut false positives by 80–90% while catching patterns they once missed.

The point for an MLRO: screening and monitoring should sit in one decision layer where screening outputs feed monitoring scenarios and risk scoring reads from both.

What this looks like in practice

With screening, monitoring and risk scoring in one engine, a cleared sanctions near-miss from last quarter stays visible as context, not noise. New fraud signals — a device change, a SIM swap, a support complaint — raise the risk score immediately and tighten rules evaluating the next payment. Counterparty-level patterns surface at network level; a receiving account hit by unrelated victims appears as a ring, not four disconnected alerts. Jurisdiction-specific logic runs in parallel: UK customers evaluated against UK expectations, Baltic against Baltic, with one audit trail.

This doesn’t depend on consortium data sharing, an ML black box or a multi-year build, only a platform flexible enough to treat the institution’s own data as first-class inputs.

The honest test for an MLRO is whether their current tool can run a monitoring scenario that references last month’s screening outcome against a current transaction. If it can’t, that gap becomes a harder conversation with the supervisor over the next 12 months. The EMIs already ahead got there through architecture, not compliance headcount: AML running as one decision layer that gets smarter as more data flows through it. That’s the shift worth making now, before regulators force the timeline.

If you have any questions, don’t hesitate to reach out today — we’d