# Working through AML hits Source: https://help.didit.me/aml-screening/resolving-aml-hits Updated: 2026-10-12 A hit is a candidate, not a verdict. Decide whether it is really your customer and whether it matters, then 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. ![The Needs review view of User verifications in the Didit console with rows selected and the bulk actions](https://help.didit.me/screenshots/sessions-bulk-light.webp) *Find the sessions holding hits, judge each match, then decide the session.* ## 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](https://help.didit.me/aml-screening/how-aml-screening-works). > **Tip:** 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 Open the verification's **AML** section and mark each hit **Confirm match** or **Not a match** (select several to **Mark not a match** in one go). Your choice is logged in **Reviews**, and needs write access to verifications. Then decide the session, and write the reasoning in the note that goes with the decision. 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. See [using audit logs](https://help.didit.me/account-organization/audit-logs). ## Reducing false positives without going blind In order of leverage: 1. **Raise the match threshold** to whatever your measured false-positive rate justifies - and measure it before deciding. 2. **Pass more identifying data** when creating the session. Screening with a date of birth is dramatically more precise than screening on a name alone. 3. **Route rather than decline.** A candidate hit should almost always go to review, not to an automatic decline. 4. **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, put it in a case whose blueprint requires **4-eyes review**: a second teammate confirms the resolution before it applies. Cases are rolling out and may not be available to your organization yet. See [cases](https://help.didit.me/investigations/cases). ## 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](https://help.didit.me/aml-screening/ongoing-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](https://help.didit.me/getting-started/sandbox-and-testing).