When screening produces constant false positives: what to do first
Stop treating every alert as a fresh investigation. Pull the last ninety days of hits, group them by the field that keeps matching — name spelling, date of birth format, jurisdiction code — and fix that field before touching the queue itself. A screening list that flags the same non-match repeatedly is a data problem, not a client-risk problem, and a data problem is fixed at the input, not at the alert.
The legal basis for screening
Screening exists to satisfy a verification duty. Under Regulation (EU) 2023/1113 (TFR), information about the originator and the beneficiary has to accompany a transfer of crypto-assets, and a provider must check that information before the transfer settles. Regulation (EU) 2023/1114 (MiCA) sets the authorisation a crypto-asset service provider operates under, and that authorisation depends on a working verification process, not on how many alerts the process happens to generate.
A screening tool that produces constant false positives is still discharging the duty — badly. The obligation does not lift because the tool is noisy. The noise has to come under control without a gap in coverage while the fix is applied.
What changes in risk and deadlines
A constant stream of false positives changes two things immediately: the backlog and the audit trail. Every unresolved alert stays open, and an open alert is a live exposure until someone closes it with a documented reason attached.
If the provider has just When cross-border services are added in practice, alert volume tends to rise further, because more counterparties are checked against more lists before anyone recalibrates the matching thresholds for the new mix. Left alone, the backlog grows faster than the team clearing it, and that widening gap is the first thing a supervisor reviews.
What to do first
- Compliance officer: freeze new watchlist updates for a short window and export the last ninety days of alerts.
- Compliance officer or data lead: group the alerts by the field driving the repeat match — name transliteration, date format, or jurisdiction code.
- Data or IT team: correct that field at source, not inside the alert-handling tool.
- Compliance officer: reclassify the already-closed alerts with a documented reason code, not a blanket dismissal.
- MLRO: run the fix against a control batch before the full queue reopens.
- Compliance officer: log the change and the date, so the next audit can trace why the volume dropped.
| Signal | Likely cause | First move |
|---|---|---|
| Same name matches repeatedly | Transliteration or date-of-birth format mismatch | Standardise the input field |
| Volume rose after a product change | New counterparty type or jurisdiction added | Recalibrate thresholds for the new segment |
| One counterparty triggers every time | Genuine risk factor, not noise | Escalate to enhanced due diligence, not IT |
| Alerts cluster after a list update | Vendor list refresh introduced new fuzzy matches | Test the update on a control batch first |
Who decides, and how
The compliance officer or the MLRO decides whether an alert closes as a false positive, based on the documented match reason and the corrected field. Escalation above that level happens when the underlying risk assessment changes, not when the volume of alerts changes.
If the entity is separately going through When a change of control triggers termination of other agreements, the escalation chain itself may shift, because the person who normally signs off may no longer hold that authority. Check the internal mandate before relying on a prior sign-off.
If your situation differs
If the false positives cluster on one counterparty rather than on a field, the issue is client risk, not data quality. Escalate to enhanced due diligence rather than to the data team.
If the provider is not yet authorised as a crypto-asset service provider under MiCA, the fix is not a screening recalibration at all — it is an authorisation gap, and that is a different first step.
Teams working through a screening backlog sometimes surface other loose threads in the same review cycle. One is a filing where When an ex-employee appears as an inventor elsewhere shows up during the same document pull.
Another is a discovery that When open source is found in the delivery of the software the screening tool itself runs on. Neither changes the first step here, but both deserve their own file rather than being folded into this one.
What this page does not cover
This page does not set the matching thresholds for a specific screening tool, and it does not replace the risk assessment that decides how much friction a given relationship should carry. It does not answer the separate question of whether the provider needs a MiCA authorisation at all — that is a prior step, not a symptom of noisy screening.
Verified
Checked on 10 June 2025 against Regulation (EU) 2023/1114 (MiCA) and Regulation (EU) 2023/1113 (TFR), both as published in the Official Journal of the European Union.
Related situations
A related operational trigger: When a beneficial owner cannot be identified. The same escalation logic applies when the missing piece sits on the ownership side of the file rather than on the transaction side.
If the backlog is already affecting a live transfer, put the facts in writing and send them across. Requests logged during business hours get a first response from the responsible partner within minutes; the practical plan for clearing the queue follows once the file is in hand.
Frequently asked questions
What is the first step when screening produces constant false positives?
Group the last ninety days of alerts by the field that keeps repeating, and fix that field before touching the alert queue itself. Reclassifying alerts without fixing the underlying field only resets the same backlog.
Which deadline is already running?
There is no separate clock for closing a false positive. The deadline that matters is whichever transaction, onboarding step, or transfer the open alert is holding up. Identify that step, and treat its own timeframe — not a number invented for this page — as the deadline.
Who decides, and on what evidence?
The compliance officer or the MLRO decides, on the strength of a documented match reason and the corrected input field. A decision without that documentation is not a closed alert; it is an open one with a note attached.