A true match is a confirmed, correct match between a screened party or transaction and a list entry, established after an analyst reviews and dispositions the alert. Confirming it triggers the required action, usually blocking or rejection plus reporting, so disciplined disambiguation is everything.
What is a true match, in plain English?
A true match is what you have when a screening alert turns out to be the real thing: the customer or transaction genuinely corresponds to the party on the list. It is not the raw alert the system fired; it is the confirmed conclusion an analyst reaches after review, having weighed the name, date of birth, address, and other identifiers against the list entry and decided the two are the same party.
The opposite outcome is a false positive, an alert that looked like a hit but, on review, turns out to be a coincidence, usually a common-name collision, and gets cleared. Every alert lands in one of these two buckets after an analyst dispositions it, and calling it correctly is the entire job of the review.
Confirming a true match is not the end; it is a trigger. It sets off the required action, typically blocking or rejection, plus any reporting the regime demands, along with solid documentation of the decision and the evidence behind it. The decision has to hold up later, so the reasoning matters as much as the outcome.
How an alert becomes a true match
- Alert — System raises a hit. Matching logic flags a party or payment as a possible match to a list entry.
- Compare — Check the identifiers. The analyst compares name, date of birth, address, and other data against the list entry.
- Decide — Match or clear. Weigh whether the identifiers confirm the same party or rule it out.False positiveClear itIdentifiers do not line up; document and close.True matchConfirm itIdentifiers confirm the party; act and report.
- Act — Block, reject, report. On a true match, take the required action and document the decision and evidence.
True match vs false positive
What changes | False positive | True match |
Conclusion | Not the listed party; a coincidence. | Confirmed to be the listed party. |
Action | Clear and close the alert. | Block or reject, plus report. |
Evidence | Identifiers do not line up. | Identifiers corroborate the match. |
Cost of error | Clearing a real hit becomes a false negative. | Over-confirming disrupts a legitimate customer. |
What it looks like in practice
In practice
An alert fires on an outgoing payment where the beneficiary shares a name with an SDN entry. Under pressure to clear a growing queue, an analyst glances at it, sees a common surname, and is tempted to close it as noise. Instead they pull the identifiers: the date of birth, the city, and a passport fragment all align with the list entry.
This is a true match. The analyst blocks the funds, files the required report, and writes up the corroborating identifiers so the decision is defensible. Had they rushed and cleared it as a false positive, a genuine hit would have become a false negative, letting a blocked party through and exposing the institution to a strict-liability breach.
Why it matters for operators
The whole screening pipeline exists to surface true matches, and everything downstream, the block, the report, the legal exposure, hangs on getting the confirmation right. A true match confirmed correctly protects the institution; a true match wrongly cleared becomes a false negative, which in a strict-liability regime is a violation regardless of intent.
The pressure runs the wrong way. Most alerts really are false positives, so analysts learn to expect noise and can start dismissing hits reflexively, especially when a backlog is building. The discipline is to disambiguate every alert on its identifiers, document the reasoning, and never let queue pressure turn a genuine hit into a quiet miss.
What to watch in the data
- Rushed clears. High clear rates during backlogs can hide true matches dismissed as noise under time pressure.
- Thin documentation. A true match without recorded corroborating identifiers is hard to defend and easy to challenge.
- Identifier discipline. Confirm on date of birth, address, and secondary identifiers, not on the name alone.
- Reflexive dismissal. Analysts conditioned by mostly-false-positive queues may under-weight genuine hits.
- Cleared-then-recurring. A party cleared as a false positive that keeps re-alerting deserves a second, closer look.
Quick questions
Who decides that an alert is a true match?
An analyst, during review. The system only raises a possible match; a true match is the confirmed conclusion after a person compares the identifiers against the list entry and dispositions the alert.
What happens once a true match is confirmed?
It triggers the required action, usually blocking or rejection depending on the prohibition, plus any reporting the regime demands. The analyst also documents the decision and the supporting evidence so it holds up on review.
What is the danger of misjudging a true match?
Clearing a real match as a false positive turns it into a false negative, letting a blocked party through. In strict-liability regimes that is a serious violation, which is why disciplined disambiguation matters so much.
How do analysts tell a true match from a false positive?
By comparing secondary identifiers, date of birth, address, nationality, and ID numbers, against the list entry. A shared name alone is not enough; corroborating identifiers are what confirm or rule out the same party.
Why is alert pressure a risk to true matches?
Because most alerts are false positives, analysts get used to clearing noise and can start dismissing hits reflexively. Under a backlog, that habit can lead someone to close a genuine match without properly checking the identifiers.
Go deeper
- OFAC, US Treasury ↗ — Administers US sanctions programs, the SDN list, and licensing.
- European Banking Authority ↗ — EU banking regulator. Strong Customer Authentication under PSD2 and AML guidance.