Working through AML hits
A hit is a candidate, not a verdict. Here's how to decide whether it's your customer, whether it matters, and how to record the decision so it stands up to an audit.
Ask two questions in order: is this my customer (the match score), and does it matter (the risk score and category). Most hits fail the first question - shared names against very large lists. Record the reasoning either way; the decision trail is the part an auditor reads.
#A hit is a candidate
The screening engine's job is to surface anyone who might be on a list. Deciding whether they are, and what to do about it, is yours. A POSSIBLE_MATCH_FOUND warning means exactly what it says.
- Filter to the sessions holding hits so the queue is only what needs a decision.
- Once you have judged the match, set the session's outcome here.
- Keep watching a customer you have cleared, so a future listing still reaches you.
#Step 1: is this actually your customer?
Compare the identifying details on the hit against what the verification established:
| Compare | Why it helps |
|---|---|
| Date of birth | The strongest discriminator. A mismatch usually settles it |
| Nationality and country | A hit in a country your customer has no connection to |
| Full name including middle names and patronymics | Partial name matches are the main false-positive source |
| Any identifier on the hit record | Where the list publishes one |
Common names produce large numbers of low-confidence matches against sanctions and PEP lists - that isn't a defect, it's what name-based screening does. If your queue is full of these, your match threshold is set too low. See understanding AML screening results.
Transliteration matters here. A name from a non-Latin script can be romanised several valid ways, so the same person may appear under spellings that don't string-match, and different people may collapse to the same spelling. Weight date of birth and nationality more heavily on those.
#Step 2: does it matter?
If it is your customer, the category decides what you do - and this is where the risk score comes in:
- Sanctions match. The serious one. Handle under your own sanctions procedure; this is not a judgement call to make casually.
- PEP. A PEP is not a criminal. In most regimes, PEP status triggers enhanced due diligence - additional information, source of wealth, senior sign-off - rather than refusal. Automatically declining PEPs is a policy choice, and usually a poor one.
- RCA. A relative or close associate of a PEP, screened for the same reason and normally handled the same way.
- Adverse media. Read the tagged category. An allegation reported once is not a conviction, and your policy should distinguish them.
- Country or geopolitical risk. Usually a risk-rating input rather than a decision.
#Step 3: record the decision
Resolve the hit in the console with a note explaining the reasoning. This is the part that matters later: an auditor is far less interested in your hit rate than in whether your decisions were made consistently and evidenced.
Write the note as though someone else will read it in two years without you there, because they will. "DOB differs by 14 years, different nationality, discounted" is useful. "Not a match" is not.
Every action is captured in the audit log for 365 days. See using audit logs.
#Reducing false positives without going blind
In order of leverage:
- Raise the match threshold to whatever your measured false-positive rate justifies - and measure it before deciding.
- Pass more identifying data when creating the session. Screening with a date of birth is dramatically more precise than screening on a name alone.
- Route rather than decline. A candidate hit should almost always go to review, not to an automatic decline.
- Separate your thresholds by risk. A high-value onboarding flow and a low-risk age check don't need the same AML settings.
#Four-eyes sign-off
If your process requires two reviewers on an AML decision, Didit supports a four-eyes flow where a second person must confirm. See four-eyes review.
#Monitoring will bring hits back
With ongoing monitoring enabled, a previously approved customer can produce a new hit later and move back to In Review. That's the feature working, not a regression - and it means hit resolution is a recurring process to staff, not a one-off task at onboarding. See ongoing AML monitoring.
#Practising before it's real
Sandbox has two AML scenarios: decline_aml_hit produces a hit that declines, and review_aml_possible_match produces a lower-confidence hit that lands In Review with a populated hit record - same schema as a live hit, including the score breakdown. Use them to walk your team through the resolution process before a real customer is waiting on it. See testing in sandbox.