For many Electronic Money Institutions (EMIs), the following scenario will ring uncomfortably true: a screening tool flags a customer; moments later, the monitoring engine raises a separate alert on the same individual.
Two analysts pick up the case from different queues, unaware of the overlap, and before anyone joins the dots, an instant payment is already en route to a mule account in another jurisdiction.
According to Salv, the root cause is the AML stack most EMIs have inherited from a simpler era — one that no longer fits the realities of the business, and that regulators are increasingly starting to notice.
Salv recently discussed why EMIs are rethinking how AML screening and monitoring fit together.
What changed for EMIs
EMIs are no longer treated as a lighter-touch alternative to banks. Under the EU Anti-Money Laundering Directive (AMLD) framework and the UK Money Laundering Regulations, they carry the same customer due diligence (CDD), monitoring, suspicious activity report (SAR) and governance obligations as a fully-licensed bank — but operate in an entirely different environment.
Four structural problems stand out. First, instant payment rails leave no buffer: SEPA Instant and Faster Payments both settle in seconds, meaning a T+1 monitoring rule fires long after the funds have already moved. Second, the boundary between fraud and AML has all but disappeared — account takeover feeds into mule payouts, romance scams end in laundering chains, and regulators now expect EMIs to detect the AML dimension of fraud, not simply process chargebacks. Third, most EMIs operate across multiple jurisdictions, each with its own supervisory risk appetite and typology focus, which a single global rule set cannot meaningfully address. Fourth, customer expectations leave little room for friction: any payment hold or verification request generates support tickets and negative reviews, yet regulators are unmoved by customer experience as a justification for weak controls. The net result is that bank-grade AML must run on EMI infrastructure, with fewer staff and higher customer expectations.
What good architecture looks like
The EMIs that consistently pass regulatory audits are those that run screening, monitoring and risk scoring as a single, unified decision layer, with each component feeding the others. Real-time, zero-tolerance sanctions screening is table stakes. PEP and adverse media screening conducted on a risk-based basis is equally standard. What sets high-performing institutions apart is the quality of context that screening produces — not a binary hit or no-hit, but match confidence, which list was triggered, whether the customer has previously been cleared, and how their screening profile has evolved over time.
Crucially, this does not require new data. It requires using the data EMIs already collect in the right context. Device identifiers, IP ranges, login anomalies, recent profile changes, velocity spikes, beneficiaries added moments before a high-value transfer, customers who contacted support in distress and then attempted to raise their transaction limits — this intelligence sits across fraud systems, product logs and CRM tables. For most EMIs, little of it ever reaches the AML monitoring engine.
Those that route it there are able to build far sharper scenarios. Rather than a broad rule such as “high-value payment to a high-risk country” — which fires constantly and to limited effect — a more surgical approach might read: new device, plus unusual destination country, plus first high-value outgoing instant payment within 30 minutes of a phone number change, equals block and escalate. That rule catches account takeover reliably while generating minimal friction for legitimate customers.
Risk scoring must also be treated as a live input, not a static snapshot. An onboarding risk rating that never updates is a compliance fiction. Customers’ circumstances change, and fraud does happen, so scores need to recalculate as new signals arrive and feed directly back into the monitoring engine. A risk score sitting dormant in a CRM record, unread by any downstream system, serves no operational purpose.
Screening context belongs inside monitoring rules
Most vendors still treat screening and monitoring as separate products: screening sees the customer’s name and identity details; monitoring sees the transaction; the resulting alerts land in separate queues. The more valuable approach is to treat these signals as a combined input.
A near-miss PEP match is interesting on its own. Combined with a sudden tenfold increase in outgoing volume to a new beneficiary in a higher-risk corridor, it becomes actionable. A sanctions match confidence score of 62% on a common name is usually a false positive — but if that same counterparty appears in payments from three other unconnected customers in the same week, a mule network is beginning to take shape.
The rule pattern that unlocks this is straightforward: if a customer has any screening context in the past 90 days — a cleared PEP flag, an adverse media hit, a near-miss sanctions match — and a transaction then crosses defined velocity or counterparty thresholds, elevate the risk score and route to enhanced review. A monitoring engine that cannot read screening outcomes as a structured data field cannot run that logic. Those that can, in practice, cut false positives by 80–90% while surfacing patterns that would otherwise go undetected.
The practical case for one decision layer
For a money laundering reporting officer (MLRO), the operational benefits of consolidating screening, monitoring and risk scoring into a single engine are significant. A cleared sanctions near-miss from last quarter remains visible as context rather than disappearing as noise.
New fraud signals — a device change, a SIM swap, a distressed customer complaint — immediately raise the risk score and tighten the rules applied to the customer’s next payment. Counterparty-level patterns emerge at network level: a receiving account targeted by multiple unconnected victims surfaces as a ring, not four disconnected alerts. Jurisdiction-specific logic runs in parallel, with UK customers evaluated against UK expectations and Baltic customers against Baltic, all within a single audit trail.
None of this depends on consortium data-sharing arrangements, machine-learning black boxes or multi-year technology programmes. It requires only a platform flexible enough to treat the institution’s own data as a first-class input.
The honest test for any MLRO is whether their current tooling can run a monitoring scenario that references last month’s screening outcome against a live transaction. If it cannot, that gap will become an increasingly difficult conversation with the supervisor over the next 12 months. The EMIs already ahead have got there through architecture rather than headcount: AML operating as one decision layer that grows more effective as more data flows through it. That is the shift worth making now, before regulators set the timeline.
Read the full post from Salv here.
Copyright © 2026 RegTech Analyst
Copyright © 2018 RegTech Analyst
