False Positive, Potential Match and True Match

Sanctions operations depends on precise decision language. A screening engine produces candidates. Analysts investigate those candidates. The bank then decides whether the alert is a false positive, an unresolved or potential match, or a true match. Those states are not interchangeable, and collapsing them into a single word such as “hit” can create operational and legal confusion.

The discipline begins with one principle: similarity is not identity, and identity is not yet the same as legal disposition. A customer can be the same person as a listed party and still require additional legal analysis to determine which restrictions apply to the bank, product or transaction. Likewise, a company may be unlisted but subject to restrictions through ownership or control.

Candidate alert

A candidate alert is created when screening logic determines that customer or payment data is similar enough to sanctions data to require review. The alert contains evidence about the comparison, not a legal finding.

The first operational question should be: what exactly matched? Name, alias, date of birth, address, registration number, vessel identifier, ownership data or another field?

False positive

A false positive is a candidate that can be resolved as not being the sanctions target or otherwise not subject to the relevant restriction.

A strong false-positive closure explains why. It might show different date of birth, different company registration number, incompatible nationality, different ownership or another decisive identifier.

The closure should be reproducible by another analyst or QA reviewer.

Potential match

A potential match exists when available evidence is not sufficient to safely clear or confirm the candidate. It is a valid control state, not analyst failure.

The bank may need more KYC information, additional sanctions research, an RFI, secondary review, ownership analysis or legal interpretation.

Forcing uncertain cases into false-positive status merely to meet SLA is dangerous.

True match

A true match means the evidence supports that the person, entity, vessel, aircraft or other screened object is the sanctions target or subject to the relevant restriction.

The next question is legal disposition. The bank may need to block or freeze property, reject a transaction, refuse service, report to an authority or take another programme-specific action.

Identity versus legal effect

A true identity match does not by itself tell the operator which legal consequence applies. Different lists contain different restrictions.

A non-SDN programme can impose targeted restrictions that differ from full blocking. UK or EU measures can also vary by regime. The decision should therefore retain list and programme context.

Evidence hierarchy

Evidence has different strength. A unique government identifier can be more probative than a common name. Matching date of birth and nationality can strengthen a candidate; conflicting passport details can weaken it.

Analysts should avoid a rigid formula because list data can itself be incomplete or approximate.

Strong identifiers

Strong identifiers can include passport numbers, national IDs, registration numbers, IMO numbers or other unique identifiers.

A unique identifier match should be treated seriously, but the analyst should still confirm data quality and source.

Contextual identifiers

Date of birth, place of birth, nationality, address and occupation can help resolve identity. They are not always unique.

An address mismatch should not automatically clear a person because people move.

Ownership and control evidence

In entity cases, the question may not be direct list identity but whether the customer is owned or controlled by a designated person.

The analyst should preserve the ownership chain, effective dates, source documents and legal rule applied.

Common-name cases

Common names produce large alert populations. Analysts should use secondary identifiers efficiently without assuming that common names are harmless.

A well-designed investigation screen surfaces the most discriminating identifiers first.

Thin-data cases

Payments often contain fewer identifiers than customer records. A beneficiary name may be the only usable field.

Thin data can justify a potential-match state and further information request rather than a premature conclusion.

Customer versus payment evidence

Customer KYC can sometimes resolve a payment alert. However, analysts should verify that the screened payment party is actually the bank's customer and not a third party with a similar name.

Data should be linked correctly before KYC evidence is reused.

Escalation tiers

Many banks use L1, L2 and specialist/legal review. The exact model varies, but escalation should be triggered by evidence complexity rather than arbitrary hierarchy.

L1 can resolve obvious false positives. Complex ownership, ambiguous identifiers or novel legal issues may require specialist review.

Dual control

High-impact dispositions can require four-eyes review. The control should define which actions need second approval and which routine false positives can be closed by one analyst.

Dual control should reduce risk without creating meaningless rubber-stamping.

SLA and ageing

Sanctions cases are time-sensitive, especially for payments. SLA should reflect legal and operational risk.

A queue metric should never encourage analysts to release unresolved payments simply to avoid ageing.

Documentation quality

Good notes separate facts from conclusions. “DOB differs by 37 years; nationality and passport also differ” is stronger than “not same person.”

For true matches, notes should identify list source, record ID, programme, matched identifiers, legal escalation and disposition.

Good-listing

Repeated false positives can be suppressed through approved good-list rules. The rule should be narrow and linked to evidence.

Good-listing should not eliminate visibility of future material changes. A new sanctions alias, customer ownership change or different identifier can require the rule to be reconsidered.

False-positive quality metrics

False-positive rate is useful but can be misleading. A very low rate can mean excellent tuning or dangerously high thresholds.

The bank should measure detection effectiveness alongside operational efficiency.

True-match quality

A true match is rare in many portfolios, so each one deserves careful post-event review. Did the control detect promptly? Was the list version current? Were assets correctly handled? Was reporting timely?

These cases provide valuable evidence of control effectiveness.

Unresolved-match governance

Unresolved cases should not disappear into generic pending status. They should have owner, next action, deadline and escalation path.

For customer onboarding, unresolved sanctions risk may prevent activation. For payments, it may maintain a temporary hold according to policy and law.

Scenario: same name, different identity

A customer and listed individual share a full name. Their dates of birth, nationalities and passport numbers differ. The analyst closes the alert as false positive with evidence.

Scenario: partial identity alignment

A customer name, date of birth and nationality match, but passport information is unavailable. The analyst escalates as potential match rather than clearing solely because address differs.

Scenario: exact unique identifier

A vessel has a different current name but the same IMO number as a listed vessel. The identifier supports a true-match conclusion despite the name change.

Scenario: owned entity

The customer company is not listed. Ownership research shows it is owned above the applicable threshold by a designated entity. The sanctions team records an ownership-based true exposure rather than calling it a name match.

Scenario: list category with limited restriction

A party is confirmed on a non-blocking restrictions list. The bank should apply the actual programme restriction rather than automatically freeze assets as if the party were an SDN.

Decision codes

Case systems should use controlled codes such as false positive, unresolved, true listed party, true ownership/control exposure and other legally meaningful outcomes.

Free-text-only decisions make MI and QA difficult.

Alert reopening

A previously closed false positive may need reopening after customer-data change, list amendment or new intelligence.

The system should retain the previous evidence while showing why the new review occurred.

Reporting and audit

Regulators may ask the bank to explain why an alert was cleared. The answer should be reconstructable from stored data, list version, analyst notes and approvals.

Screenshot-only evidence is fragile; structured data is preferable.

QA sampling

QA should sample both false positives and escalations. It should look for unsupported closures, inconsistent identifier weighting, weak documentation and missed ownership/control issues.

Sampling only true matches misses the much larger risk in everyday false-positive decisioning.

Analyst training

Training should include difficult names, incomplete data, multiple list programmes, ownership cases and sanctions versus AML distinctions.

Memorising definitions is not enough; analysts need case judgement.

Automation

Automation can auto-close highly repeatable false positives if governance is strong. It should not hide why the closure happened.

Automated decisions need rules, testing, monitoring, override and audit evidence.

AI assistance

AI can summarise evidence or suggest comparisons, but a probabilistic model should not make unreviewed legal sanctions determinations unless the bank has explicitly designed and governed that use.

Human accountability remains critical for high-impact outcomes.

Business analyst view

A BA should model candidate, evidence item, investigation, escalation, decision, disposition and report as separate objects. Acceptance criteria should include uncertain data, multiple matches, ownership cases, list changes, reopening and dual approval.

Metrics

Useful metrics include false-positive rate, potential-match ageing, true matches, escalation rate, good-list coverage, reopening rate, QA error rate and time to disposition.

The metrics should be interpreted together rather than optimised independently.

Common mistakes

Common mistakes include calling every system alert a hit, treating identity confirmation as the same as legal disposition, clearing on address mismatch alone, using unsupported free-text conclusions, forcing unresolved cases into false-positive status and assuming every true match requires identical action.

Learning checkpoint

A reader should be able to distinguish candidate alert, false positive, potential match and true match; explain the role of identifiers and ownership evidence; design escalation and case states; and show how legal disposition follows—but is not identical to—the identity decision.

Reference links

• OFAC — Sanctions List Search Tool: https://ofac.treasury.gov/sanctions-list-search-tool
• OFAC — Sanctions List Service: https://ofac.treasury.gov/sanctions-list-service
• OFSI — UK financial sanctions general guidance: https://www.gov.uk/government/publications/financial-sanctions-general-guidance
• UK Government — UK sanctions collection: https://www.gov.uk/government/collections/uk-sanctions

Educational note: terminology differs across institutions. What matters is that the bank's states, evidence requirements and legal actions are defined precisely and applied consistently.

Operational deep dive: decision quality in sanctions alert handling

The greatest operational risk in sanctions screening often sits not in the algorithm but in everyday analyst judgement. Millions of alerts can be generated over time, and most will be false positives. The bank therefore needs a repeatable method for resolving ordinary cases quickly while making uncertainty visible and escalating the cases that matter.

Evidence table

For each candidate, record matched attribute, customer value, list value, source, confidence and interpretation. This creates a transparent evidence table rather than a narrative written after the conclusion.

Decisive differences

A decisive difference should be materially inconsistent with identity. A clearly different passport number can be more useful than a different address. Analysts should learn which fields are stable and which can change.

Incomplete list data

Sanctions records can contain approximate ages, multiple dates of birth or limited identifiers. Absence of matching information should not be misread as contradictory evidence.

Confidence and uncertainty

The case tool should allow uncertainty to be expressed. A potential match can be routed to secondary review with a clear list of missing evidence.

Second-line escalation

Complex legal interpretation, ownership/control, novel list categories and high-impact customer cases should have an escalation path to sanctions specialists or legal counsel.

Four-eyes design

Define which decisions require a second reviewer. Examples can include true matches, release of a high-confidence payment alert, ownership/control conclusions or override of automated blocking.

Closure templates

Templates can improve consistency but should not become copy-paste substitutes for reasoning. Require analysts to populate the material identity differences.

Repeated false positives

If the same customer repeatedly matches the same target, good-listing can reduce operational load. Before suppression, QA should confirm that the customer identity is stable and that the rule will be invalidated by relevant customer or list changes.

Escalation ageing

Track unresolved cases separately from ordinary alert ageing. A complex potential match should not be hidden inside the same KPI as routine false positives.

True-match rehearsal

Because true matches are infrequent, operations should run tabletop exercises. Teams should know who contacts legal, who applies restrictions, who reports externally and who handles customer communication.

Ownership match case

A company name has no list match, but ownership data identifies a designated parent. The case should be classified as ownership/control exposure, not false-positive name screening. This distinction improves MI and future testing.

Non-blocking restrictions case

A party is confirmed on a list that imposes limited transaction restrictions. The analyst should route to programme-specific legal analysis rather than applying a full asset freeze automatically.

QA error taxonomy

Classify QA errors: missed identifier, unsupported closure, wrong list interpretation, ownership not checked, incorrect disposition, inadequate notes, SLA breach or data issue. Error categories help remediation target the real weakness.

Practitioner checkpoint

High-quality sanctions operations makes uncertainty explicit, uses evidence proportionately, separates identity from legal effect, rehearses rare true-match events and measures analyst errors in a way that improves the control.

Advanced practitioner layer: identity decision, legal applicability and disposition

The most important discipline in sanctions investigations is to prevent several different decisions from collapsing into one status. A screening candidate asks whether data is sufficiently similar to require review. An identity decision asks whether the screened person, entity or asset is the same as the sanctions target. An ownership/control decision asks whether an unlisted entity is nevertheless covered by a relevant sanctions rule. A legal-applicability decision asks which restriction applies to the bank, product or transaction. Only then should the operating process determine the disposition.

When systems use one generic status such as sanctions hit, analysts and downstream applications can misunderstand what has actually been established. A bank-grade case model should therefore make uncertainty and decision progression explicit.

A four-layer decision model

A useful model separates four layers.

The candidate layer contains the technical reason the alert was created: field, list value, alias, similarity, identifier or relationship rule.

The evidence layer contains facts used to resolve identity or coverage: date and place of birth, nationality, passport, company registration, address, ownership path, vessel IMO number, official documentation and source quality.

The legal layer identifies the authority, programme, bank legal entity, ownership/control rule, type of restriction, licence or exemption and applicable legal conclusion.

The operational layer records what the bank actually did: release, maintain hold, block/freeze, reject, restrict, report, refuse onboarding or another authorised action.

This structure makes cases auditable and prevents a technical candidate from being treated as a legal finding.

Missing data is not contradictory data

One of the most common investigation errors is treating absence as mismatch. If the sanctions record does not contain a date of birth, a customer's date of birth cannot be used to clear the candidate merely because the list field is blank. Likewise, an address not present on the list does not mean the customer's address is incompatible with the target.

The case tool should represent missing, unknown, approximate, multiple values and confirmed mismatch differently. Those states have different evidential meaning.

A strong analyst note says: “List record contains no passport information; passport cannot be used to disqualify.” A weak note says: “Passport does not match” when no list passport exists.

Evidence quality matters as much as evidence type

A passport number can be highly discriminating, but only if the source is reliable and the comparison is valid. A company registration number obtained from an official registry is different from an unverified number copied from an old website. A commercial database's ownership link may be valuable, but analysts should know whether it is verified, inferred or stale.

The case should preserve provenance. Evidence can be labelled by source, date, verification status and confidence where appropriate. This does not require a rigid numerical scoring model; it requires enough transparency for another qualified reviewer to understand why the conclusion was reached.

Strong match does not mean automatic blocking

Suppose a customer is conclusively identified as the same entity appearing on a sanctions list. The case is now a true identity match, but the operating action still depends on the list and programme. Some entries are subject to full blocking or asset-freeze measures; others impose narrower restrictions.

This distinction is essential for non-SDN or activity-specific programmes and for multi-jurisdiction banks. The case should route to legal applicability rather than map every true identity match to the same disposition.

OFAC's own match guidance makes the same conceptual separation: establish whether there is a valid match, then apply the restrictions relevant to that programme and situation. The bank should build that sequence into workflow states.

True exposure without a name match

A customer company may not appear on an official list and may never produce a direct name candidate. If a blocked or designated person owns or controls it under the applicable regime, the bank can still have a true sanctions exposure.

The case terminology should identify this accurately. Calling it a “true name match” is wrong. Better decision codes include true listed-party identity, ownership-based exposure, control-based exposure and activity-based restriction where relevant.

Accurate codes improve management information and ensure that analysts understand why the legal conclusion exists.

Potential match is a controlled state, not a failure state

Operations teams can feel pressure to turn every case into false positive or true match. That is unsafe when evidence is genuinely insufficient. A potential or unresolved match should have an owner, next action, deadline, escalation tier and operational effect.

For onboarding, an unresolved case may prevent activation according to policy. For a payment, it can maintain a temporary control state while information is obtained. For an external beneficiary with thin data, an RFI may be required.

The system should distinguish awaiting information, awaiting specialist review, awaiting legal interpretation and technical dependency if those distinctions help manage risk. A generic pending queue can hide cases that require very different actions.

Decision rights should match impact and uncertainty

Not every case requires the same approval. Straightforward common-name false positives with strong conflicting identifiers can often be resolved by trained first-line sanctions operations. Complex ownership, ambiguous legal control, unusual list programmes, licences or high-impact true matches may require senior sanctions or legal review.

The escalation matrix should be based on complexity and consequence rather than job title alone. Maker-checker control is valuable only if the second reviewer performs an independent challenge. A four-eyes click that merely repeats the first decision adds delay without meaningful control.

Evidence hierarchy should not become a mechanical points system

Training often describes passports or registration numbers as “stronger” than names, which is useful. But an institution should avoid turning that concept into a universal arithmetic formula such as passport mismatch = minus 50 points.

Official list data can contain errors, approximate dates, former addresses or incomplete identifiers. Identity decisions require contextual evaluation of data quality. A unique identifier match should receive serious attention, but the analyst should still verify that the identifier belongs to the same issuing system and is not mistyped or recycled.

The best case note explains why evidence is discriminating rather than simply referring to an internal score.

Reuse of historical false-positive decisions

A prior false-positive decision can save time, but only when the facts remain materially the same. The customer may change legal name, ownership, nationality or registration. The sanctions record may gain a new alias or identifier. The bank's list provider may correct data.

A reusable closure should therefore record the precise customer-target pair and the evidence supporting the distinction. Material changes should trigger re-evaluation. Historical evidence should remain visible so the analyst can understand what was decided previously without treating it as permanent immunity.

Case reopening and versioning

A reopened alert should preserve the original decision. The new case should state why it was reopened—for example a list amendment, customer data change, new ownership information, new official intelligence or control remediation.

Overwriting a previous closure destroys audit history and makes regulator questions difficult. Versioned decisions allow the bank to say: “Based on the data available on date A, the parties were different. On date B, the authority added identifier X, which required a new review and changed the conclusion.”

This is a more accurate control narrative than pretending the first analyst was necessarily wrong.

Customer-screening evidence and payment-screening evidence differ

A KYC customer can have verified date of birth, passport, corporate documents and ownership. A one-off external payment beneficiary may have only a name, account and address. Analysts should not apply the same evidence expectations to both populations.

Where a payment beneficiary is not the bank's customer, internal KYC for a similar name should not be reused unless the party is reliably linked. Incorrect party resolution can create a false clearance.

A BA should therefore define party identifiers and relationship keys carefully. The case should show whether evidence belongs to the screened party or merely to another person with a similar name.

Requests for information should answer a specific evidence gap

An RFI should not be a generic demand for every customer document. The case should identify what information is needed to decide identity or legal applicability: full legal name, date of birth, registration number, ownership, underlying beneficiary or another relevant fact.

Focused RFIs improve response time and reduce customer friction. They also create better evidence because the analyst can explain why each requested item matters.

Repeated RFIs for the same payment should be reviewed for process weakness. If a field is routinely needed, the bank may need to capture it earlier in the product or channel.

Quality assurance should target judgement risk

A purely random QA sample can miss the highest-risk closures. Targeted QA should include rapidly closed alerts, high-name-score false positives, low-score escalations, weak aliases, transliteration, thin-data payments, ownership/control cases, manual overrides and reused suppressions.

QA should ask whether the investigator compared the correct person, used available identifiers, distinguished missing from mismatching data, considered ownership where relevant, identified the correct programme and wrote a reproducible rationale.

An error rate alone is not enough. Themes should feed training, matching configuration and data remediation.

Automated false-positive closure

Automation can close highly repeatable false positives when evidence is deterministic and governance is strong. Examples might involve a stable customer-target pair with a verified incompatible registration number. The automated rule should be narrow, versioned and monitored.

The bank should retain the evidence used by the rule and support manual override. If the sanctions target record changes materially, the automation should reconsider the case rather than continue suppressing silently.

Automation should be more conservative where data is approximate, where ownership/control analysis is required or where legal applicability is complex.

AI-assisted investigation

AI can help summarise list entries, organise evidence or surface differences, but its output should be treated as assistance, not authoritative identity resolution. A model can hallucinate, omit qualifiers or overstate similarity.

High-impact sanctions decisions require traceable source evidence. If AI is used, the case should remain grounded in official list data, customer records and documented analyst judgement. The system should not transform a model's confidence percentage into a legal match probability.

SLA design should distinguish processing time from decision quality

Payment alerts can be time-critical, but service levels must not encourage unsafe release. Useful metrics can separate time waiting for external information, analyst handling time, specialist review time and technical outage time.

Cases approaching SLA can be escalated, but the escalation action should increase attention—not force the analyst to choose a conclusion unsupported by evidence.

Management information that reveals decision quality

Useful MI includes candidate volume, false positives, unresolved cases, true identity matches, ownership/control exposures, legal dispositions, reopening rates, suppression use, QA overturns and aged cases. These measures should be segmented by screening population, list source, rule and business line.

A falling false-positive rate can reflect better control or hidden sensitivity loss. Management should view it alongside challenge-set performance, true-match detections and QA findings.

Business analyst state model

A robust case state model can include candidate_created, under_investigation, awaiting_information, specialist_review, false_positive, identity_confirmed, ownership_or_control_exposure, legal_applicability_confirmed, release, reject, block_or_freeze, reported and closed. Not every case uses every state.

Each transition should record actor, timestamp, reason and evidence. State transitions with legal consequences should require the defined authority level. Systems should prevent contradictory terminal states such as simultaneously released and blocked.

Practitioner conclusion

Sanctions alert decisioning is strongest when uncertainty is visible and every conclusion is tied to evidence. The objective is not to close alerts quickly or to maximise true-match counts. It is to distinguish similarity from identity, identity from ownership/control coverage, and legal coverage from operational action—then preserve enough evidence that another qualified person can reproduce the decision.

Practitioner close: difficult sanctions alert cases

These cases test whether the learner can keep identity, evidence quality and legal consequence separate. Each case should be approached by asking what is known, what is missing, what can safely be concluded and what decision belongs to another specialist.

Case lab: exact name, reliable incompatible passport

A private-banking customer has an exact full-name match to a listed individual and the same nationality. The official list record includes a passport number. The customer's passport is issued by the same country but has a completely different number and the customer's date of birth is twenty years later.

The name similarity created the candidate, but reliable incompatible identifiers strongly support a false-positive conclusion. The closure should state the specific differences and confirm that the list passport and customer passport were compared in the same identifier context.

The analyst should not write “exact name but low risk.” Risk appetite is not the identity question. The correct statement is that available identity evidence demonstrates that the customer is not the listed individual.

Case lab: exact name but list data is sparse

A beneficiary's name exactly matches a designated person, but the official record contains no date of birth, passport or address. The payment beneficiary is not the bank's customer.

The absence of identifiers makes the case harder, not easier. The analyst cannot clear the candidate because the beneficiary's date of birth is different from a blank list field. Depending on policy and timing, the bank may request information from the ordering bank/customer, route to specialist review or maintain a controlled payment state.

This case is a useful test of whether operations treats missing as a real data state.

Case lab: same date of birth, different nationality

A customer name and date of birth align with a listed target, while current nationality differs. Nationality alone may not safely clear the case because people can hold multiple citizenships or change nationality. Other evidence is required.

If the official record includes place of birth or passport information, those fields can help. The analyst should evaluate the full entry rather than apply a one-field clearing rule.

Case lab: entity shares a common trading name

A customer operates under a trading name identical to a sanctioned company's former name, but the customer's legal name, jurisdiction, registration number, incorporation date and owners are unrelated.

The analyst can document a false positive because the legal entity evidence is incompatible. The case also demonstrates why trading names and former names are useful candidate inputs but cannot establish corporate identity by themselves.

A suppression can be considered if the same pair repeatedly alerts, but it should remain specific to the customer and target.

Case lab: target record changes after a historical clearance

A customer was cleared two years ago because the list entry had a different date of birth and address. The authority later updates the target record, removes the old date as erroneous and adds a passport number that matches the customer.

The bank should reopen the comparison. The historical decision may have been correct based on information available at the time; the new official information changes the evidential picture.

The control should preserve both versions of the list record and both decisions. A regulator should be able to understand the chronology rather than see an unexplained overwritten case.

Case lab: unlisted company, designated owner

A corporate customer generates no direct name candidate. A new designation affects one of its shareholders. The ownership service shows that the person's interest meets the applicable ownership rule for the relevant regime.

This is a true sanctions exposure without a true name match on the company. The case should record the ownership path, percentages, source, effective date and legal rule. The downstream disposition should use the applicable regime rather than mark the company as though it had been separately listed.

This distinction becomes important when the official list is updated, when ownership changes, and when customer communications are reviewed.

Case lab: control concern without automatic OFAC blocking

A blocked person owns a minority stake in a company but has substantial governance influence. Under OFAC's specific 50 Percent Rule, control alone below the ownership threshold does not automatically make the company blocked under that rule. Other legal or programme issues may still require assessment.

The investigator should not convert a control concern into an automatic 50-percent-rule conclusion. The case can escalate to sanctions/legal for the relevant programme and policy assessment.

This is a good example of why the decision taxonomy should distinguish identity, ownership, control and legal applicability.

Case lab: same IMO number, different vessel name

A trade payment references a vessel with a new name. The IMO number matches a vessel on the relevant sanctions list. Provided the identifier and list data are reliable, the persistent identifier can establish vessel identity despite the name change.

The next step is still programme analysis. The case should determine what restriction applies and whether the bank's activity falls within it.

Case lab: potential match remains unresolved at cut-off

A time-sensitive cross-border payment produces a strong candidate. The customer cannot provide requested beneficiary information before the payment cut-off. The evidence is insufficient either to clear or confirm.

The operating model should have a predefined response. The bank should not manufacture a false-positive conclusion just to avoid missing the cut-off. Depending on law, rail and policy, the payment may remain held or be handled through another controlled outcome.

The case state should show unresolved identity and the reason, not simply “sanctions rejected.”

Case lab: multiple list records for one person

A customer appears to match entries from more than one sanctions authority or programme. Some identifiers overlap, while programme consequences differ.

The investigator should not collapse all records into one generic hit. Identity can be resolved once, but each applicable programme may need separate legal assessment. The case should retain the authorities, programme tags and restrictions that matter to the bank's legal entities.

This design helps when one designation is later removed while another remains.

Case lab: false positive reopened because ownership changed

A corporate customer was previously cleared against a similarly named listed company using different registration number and ownership. Later, the customer is acquired by a designated person.

The name comparison remains a false positive: the customer still is not the listed company. But a new ownership-based sanctions issue now exists. The system should create the correct new case rather than changing the historical name-match result into “true match.”

Precise classification produces better audit history and better analytics.

Case lab: automated closure breaks after data-quality change

An automated rule closes a recurring customer-target candidate because verified dates of birth are incompatible. A KYC migration accidentally stops sending customer date of birth to screening and case management. The rule continues auto-closing because it interprets the missing field as unchanged.

This is a control failure. Automated closure logic should require the discriminating evidence to be present and valid. Missing critical evidence should cause the automation to fail safe into review, not continue based on an old assumption.

Monitoring should also detect the sudden loss of a source field across the population.

Case lab: external vendor says “high confidence”

A vendor assigns a high confidence sanctions match label to a customer. The vendor output contains a similar name and location but no unique identifier. The bank's KYC shows a different birth date and nationality.

The vendor label is an input, not the bank's legal conclusion. The analyst should inspect the underlying evidence and document the identity decision. Vendor confidence terminology should never replace the institution's controlled decision states.

The same principle applies to AI-generated summaries and risk scores.

Writing a false-positive note

A high-quality false-positive note is concise but reproducible. It identifies the candidate target, the matched field, the discriminating evidence and the conclusion. For example: “Customer full name aligns with target alias. Customer DOB 14 May 1987; target DOB 22 August 1954. Customer passport and nationality also incompatible with target. Candidate resolved as false positive.”

The note does not need to repeat the entire case file. It needs enough evidence for QA to understand why the parties differ.

Writing an unresolved-match note

An unresolved note should say why the bank cannot decide and what happens next. For example: “Beneficiary name exactly aligns with designated individual. Payment contains no DOB or identifier; beneficiary is not a bank customer. RFI requested from ordering customer for beneficiary legal identity and registration/identity data. Payment remains in sanctions review pending response.”

This is more useful than “possible hit, escalated.”

Writing a true-identity note

A true-identity note should identify the evidence establishing identity and then route to legal applicability: “Legal name and registration number match official target entry; registered address also aligns. Identity confirmed. Case escalated for programme-specific restriction and disposition.”

The analyst should not write “blocked” unless that operational/legal action has actually been determined.

Testing the state machine

UAT should test more than final outcomes. It should verify that a candidate can move to false positive, unresolved, identity confirmed or ownership/control exposure; that legal applicability can be added separately; that only authorised roles can trigger high-impact disposition; and that reopening preserves historical decisions.

Negative tests should attempt invalid transitions. A payment should not be released directly from unresolved status without the required decision. A true identity match should not automatically generate a blocked-property report if the applicable programme is not a blocking regime.

Final practitioner test

A learner is ready for real sanctions operations when they can explain why “hit” is an inadequate word. They should be able to distinguish candidate generation from identity, missing from mismatching data, listed-party identity from ownership/control exposure, and identity from the legal restriction. They should also be able to write a case note that another analyst can reproduce without relying on the original investigator's memory.

Practitioner masterclass: sanctions alert decisioning

The practical objective is to make every closure and escalation reproducible. Start with the candidate, identify the strongest identity evidence and separate the identity conclusion from the legal disposition.

Exercise 1 — false-positive closure

Write a closure for a common-name alert using date of birth, nationality and passport. Avoid the phrase “not the same person” unless you explain why.

Exercise 2 — unresolved case

The customer name and date of birth align but passport information is unavailable. Define the evidence request, owner, deadline and escalation path rather than forcing a false-positive decision.

Exercise 3 — true identity, limited restriction

A party is confirmed on a list that does not impose full blocking. Describe why true match and asset freeze are separate decisions.

Exercise 4 — ownership exposure

A company has no list-name hit but is owned by a designated person under the applicable regime. Classify the case correctly and preserve the ownership evidence.

Exercise 5 — reopening

A previously cleared customer alert is affected by a new alias or customer-data change. Define the event that reopens the case and how prior evidence is retained.

QA exercise

Review ten false positives and test whether each has a decisive evidence trail. Categorise errors by unsupported closure, missed identifier, ownership gap, wrong list interpretation or documentation weakness.

Final test

The learner should be able to distinguish candidate, false positive, potential match, true match and legal disposition, and should be able to defend the decision to a QA reviewer or regulator.

60-minute mastery extension: false positive, potential match and true match

This extension is designed to make the chapter a minimum 60-minute guided learning experience. Spend about 25 minutes on the core lesson and diagrams, 15 minutes on the identity-resolution cases, 10 minutes on workflow and suppression governance and 10 minutes on the final disposition test.

The most important distinction is identity versus legal consequence

A screening engine first generates a candidate because customer or payment data resembles sanctions data. An analyst may resolve that candidate as a false positive, determine that the identity remains a potential match requiring more evidence, or confirm that the party is the same person or entity as the sanctions target.

Even a confirmed identity does not mean every operational action is identical in every case. The bank must still determine the applicable sanctions regime, legal nexus, relevant property or activity, ownership/control implications and whether a licence or exception applies. Identity resolution and legal disposition are connected but separate decisions.

Candidate is not a true match

The system should not label every fuzzy candidate a "true hit" or "positive." That language can bias analysts and create incorrect management information. Better states describe what is actually known: candidate generated, potential identity match, identity confirmed, legal applicability under review and final disposition.

The terminology should be documented in the data dictionary and case workflow so technology, operations, compliance and audit use the same meanings.

Worked case: false positive

A customer has the same name as a designated person. The list record shows a birth year of 1962 and nationality A. The customer was born in 1994, has verified nationality B and a long-standing identity record. The candidate can be resolved as a false positive because reliable identifiers establish that the customer is a different person.

The closure should record which identifiers were compared and why they were decisive. "Name not same" is too weak. The decision should be reusable where appropriate but subject to refresh if either the customer or sanctions record changes materially.

Worked case: unresolved potential match

A payment beneficiary has a close name match to a designated entity. The message contains only a partial address and no registration number. Public sources show several companies with similar names. The bank cannot confidently clear or confirm the identity with available information.

The correct state can remain a potential match while additional evidence is obtained or specialist escalation occurs. Payment timing, legal requirements and operational cut-offs matter, but uncertainty should not be converted into a false-positive closure merely to clear a queue.

Worked case: identity confirmed, legal analysis follows

A customer is confirmed to be the same person as an individual on a sanctions list relevant to the bank. The sanctions team then identifies the applicable programme, legal entity, property interests, any licence/exception and required action. The final result may be blocking/freezing, rejection, restriction, reporting or another legally defined outcome depending on the regime and activity.

The case record should preserve both decisions: identity confirmed and legal disposition. This makes later review much clearer.

Secondary identifiers

Useful identifiers can include date and place of birth, nationality, passport or national identifiers, registration number, incorporation jurisdiction, address, aliases, vessel IMO number and other authority-provided information. Not every identifier has equal reliability.

A missing identifier is different from a conflicting identifier. If DOB is unavailable, the bank has less evidence. If a verified DOB clearly conflicts, that can support false-positive resolution. Systems should preserve these distinctions rather than treating blank and mismatch as equivalent.

Suppression governance

Repeated false positives can be suppressed or pre-resolved where policy allows, but the rule should be narrow and evidence-based. Store the exact customer/candidate relationship, decisive identifiers, rationale, date, reviewer and refresh triggers.

Suppression should expire or be re-evaluated when the sanctions record gains new aliases or identifiers, the customer changes identity information or ownership/control changes. Broad permanent whitelists can create false negatives.

SLA and queue risk

Potential sanctions matches can be time critical. Queue ageing should distinguish cases waiting for customer information, specialist legal review, ownership analysis or system recovery. A single average SLA hides where risk accumulates.

Priority can consider payment status, value, legal urgency, customer impact, list change and confidence. The objective is timely, accurate disposition—not simply fast closure.

QA exercise

Review a sample of false positives and ask: were the decisive identifiers documented? Did analysts over-rely on name score? Was a missing identifier treated as a mismatch? Were ownership/control questions ignored? Did a previously suppressed candidate remain valid after list changes?

Then review confirmed matches and ask whether legal applicability was separately documented. QA should test reasoning, not just whether the final status agrees with a reviewer.

Workflow-design exercise

Define states and transition permissions for: candidate → triage → false positive / potential match → escalated → identity confirmed → legal review → release / reject / freeze-block / other restriction → reporting → closure. Define which roles can move each state and what evidence is mandatory.

Add edge cases: payment expires while pending; customer provides new ID; list record is updated; ownership changes; licence arrives; duplicate candidate exists; system creates the same alert twice.

Final disposition test

Classify each: common-name customer with conflicting DOB; close corporate-name match with no registration data; exact name and matching passport; entity owned by blocked persons but not itself named; candidate resolved last year but list now has a new alias; confirmed identity under a programme that does not apply to the bank's current transaction.

For each, state whether the issue is identity resolution, ownership/control, legal applicability or final disposition.

A strong### Dual control and maker-checker that actually controls

Dual-control requirements for sanctions dispositions fail frequently through ritual compliance: second reviewers rubber-stamping first-reviewer conclusions under queue pressure, reviewers with identical training and perspective reproducing rather than challenging reasoning, and checker roles assigned to junior staff unable to overrule senior makers in practice. Effective dual control designs against these failure modes explicitly. Reviewer independence requires the checker to examine evidence before viewing the maker's conclusion wherever system design permits, preventing anchoring on the proposed disposition. Competence symmetry requires checkers qualified to challenge: true-match confirmations and inconclusive-hold decisions need checkers with authority and expertise exceeding the complexity of what they review, not merely a second pair of eyes.

Scope differentiation focuses dual control where it matters: true-match confirmations, inconclusive holds with commercial consequences, allow-list additions suppressing future alerts, and high-value or high-sensitivity releases each mandate independent review, while routine false-positive closures with strong distinguishing evidence proceed under sampling-based QA rather than universal checking that would collapse throughput. Disagreement protocols define what happens when maker and checker differ: escalation paths with defined authorities and timeframes, documentation of both positions with the deciding rationale, and trending of disagreement patterns that reveal training needs or procedure ambiguity. Dual-control effectiveness measurement tracks overturn rates on dual-controlled versus single-controlled dispositions, disagreement frequency by category, and the substantive quality of checker challenges through QA sampling, demonstrating that the second pair of eyes sees rather than merely attends.

Escalation tiers with defined routing and authority

Escalation structures route alerts by complexity and consequence through analyst, senior-analyst, specialist and legal tiers with defined entry criteria, authorities and timeframes at each level. Tier design must reflect the actual decision types: identity-complexity escalation for thin-data, transliteration and ownership cases needing specialist techniques; legal escalation for true-match confirmations, licence assessments and jurisdictional-conflict questions requiring legal determination; and management escalation for high-value holds, relationship-threatening dispositions and incident conditions needing senior authority. Each tier specifies what it decides, what evidence it requires, how quickly it responds, and where it escalates next, preventing both premature legal referral of routine identity questions and analyst-level resolution of legal determinations.

Routing discipline ensures cases reach the right tier first time: triage criteria distinguishing identity from legal complexity, with misrouted cases tracked as a routing-quality metric rather than absorbed silently. Tier-capacity planning addresses the bottleneck reality that specialist and legal tiers constrain overall throughput: service-level agreements between tiers with queue-visibility, surge protocols for designation waves, and delegation frameworks permitting defined decisions at lower tiers during capacity stress with enhanced QA rather than uncontrolled escalation collapse. Escalation documentation carries the case narrative forward without requiring re-investigation at each tier: evidence summaries with source citations, alternatives considered, and the specific question escalated, so that higher tiers decide rather than redo.

Disposition-code taxonomy and its governance

Disposition codes transform narrative conclusions into analysable data, but only where the taxonomy is designed with analytical intent and governed against decay. Effective taxonomies distinguish identity outcomes, confirmed false positive with distinguishing-evidence category, probable false positive, confirmed true match, inconclusive pending information, from legal outcomes, released, held, blocked, rejected, reported, licensed, with combination rules preventing contradictory coding. Free-text reasoning accompanies every code, since codes summarise conclusions while narratives preserve the reasoning auditors and investigators need. Code proliferation, taxonomies growing to hundreds of rarely used codes through undisciplined addition, destroys analysability and requires periodic rationalisation with mapping tables preserving historical comparability.

Governance controls code creation, modification and retirement through defined approval with impact analysis on reporting continuity. Usage monitoring detects the characteristic decay patterns: default-code overuse where analysts select the first available option, contradictory code combinations revealing training gaps, and code avoidance where difficult outcomes lack acceptable coding and analysts miscode to fit available options. Each pattern drives specific remediation rather than generic retraining. Analytics built on disposition codes, conversion-rate trending, overturn analysis by code, outcome forecasting, depend entirely on coding discipline, and QA sampling must verify code-to-narrative consistency as a core check rather than assuming coded data describes reality.

Management-information dashboards for disposition quality

Disposition MI must illuminate quality and risk rather than merely counting throughput, and dashboard design should serve each audience's decisions. Operational dashboards show queue health by tier with ageing alerts, capacity utilisation against forecast, and bottleneck identification directing daily management action. Quality dashboards show overturn rates by category and analyst cohort, QA sampling results with error taxonomy, thin-data case volumes indicating data-quality pressure, and suppression-rule performance revealing efficiency-risk trade-offs. Risk dashboards show true-match and near-miss trending, inconclusive-case ageing with exposure quantification, designation-wave response performance, and emerging-pattern indicators from alert-content analysis.

Dashboard integrity requires the same governance as the underlying dispositions: metric definitions documented and version-controlled, data-lineage from case records to displayed figures tested periodically, and drill-down capability enabling every aggregate to be traced to constituent cases. Vanity-metric discipline excludes measures that flatter without informing: raw closure counts without quality context, average handling times without complexity segmentation, and alert-volume reductions achieved through suppression rather than precision. Senior-committee reporting should lead with risk and quality measures, relegate throughput to appendix status, and explicitly connect MI trends to resourcing, tuning and training decisions, closing the loop between measurement and management action that distinguishes controlled operations from merely busy ones.

SLA tiering that reflects risk rather than queue order

First-in-first-out alert queues treat a common-name retail candidate and a probable designated-entity corporate payment as equals, misallocating scarce analyst attention toward whichever arrived first. Risk-tiered service design routes alerts by assessed urgency and consequence: probable true matches with time-critical transactions receive immediate specialist handling with defined response times measured in minutes to hours; standard candidates proceed through normal review with day-scale targets; low-risk recurring patterns with established resolution precedents follow streamlined paths with quality sampling rather than full review. Each tier specifies its entry criteria, handling team, decision authorities, evidence standards and escalation triggers, so that tiering reflects designed risk differentiation rather than informal cherry-picking of easy alerts.

Tier-entry criteria must be transparent and testable: score thresholds combined with risk attributes such as transaction value, corridor sensitivity, customer risk tier and list-programme severity. Criteria drift is inevitable as populations change, requiring scheduled recalibration with outcome feedback: tiers that consistently produce false positives need threshold adjustment, while tiers showing true matches below their entry boundary need expansion. Ageing management differs by tier: high-tier alerts age in minutes with automatic escalation on breach, while lower tiers age in days with queue-balancing rather than emergency response. Breach analysis distinguishes capacity shortfalls requiring resourcing from routing failures requiring redesign, since each demands different management action.

QA sampling statistics that actually assure

Quality-assurance sampling of alert dispositions must be statistically grounded to support its conclusions, yet most QA programmes sample arbitrarily and stratify poorly. Sound sampling design stratifies by the dimensions where quality risk concentrates: disposition type with oversampling of false-positive closures and true-match confirmations, analyst tenure with attention to newly independent reviewers, alert complexity with deeper sampling of thin-data and ownership cases, and customer and corridor risk with coverage of higher-consequence decisions. Sample sizes should support stated confidence levels for the error rates the programme claims to control; a QA programme asserting low error rates from a few dozen monthly samples across thousands of dispositions asserts what its mathematics cannot support.

Review standards must exceed re-performance: independent reviewers examine evidence sufficiency, reasoning quality, alternative-hypothesis testing and documentation adequacy rather than merely agreeing with conclusions. Disagreement calibration between reviewers, measured through dual-review exercises, establishes the QA standard's own reliability before it judges operational quality. Findings feed analyst coaching, procedure revision and scenario tuning with tracked remediation rather than accumulating as unaddressed observations. QA independence requires organisational separation from production pressure: reviewers measured on throughput or reporting to production management cannot challenge the dispositions their hierarchy needs closed.

Overturn analysis: learning from reversed decisions

Dispositions reversed on review, appeal, audit or regulatory challenge provide the richest control intelligence available, since each overturn identifies a specific reasoning failure with known consequences. Overturn taxonomy distinguishes identity errors, where the wrong identification conclusion was reached; legal errors, where identification was correct but disposition misapplied the restriction; evidence errors, where available information was missed or misread; and process errors, where the right conclusion emerged from inadequate reasoning that happened to land correctly. Each category drives different remediation: identity errors indicate training or data gaps, legal errors indicate advisory-access or procedure gaps, evidence errors indicate tooling or workload gaps, and process errors indicate the most dangerous condition, unreliable reasoning producing occasionally correct outcomes by chance.

Overturn trending by analyst, team, alert type and period reveals systemic patterns invisible in individual cases: particular typologies with persistent misclassification, workload thresholds beyond which quality collapses, or procedural changes whose consequences appear in overturn data before management reporting. Feedback delivery must be developmental rather than punitive to sustain reporting honesty: analysts who hide borderline decisions to protect overturn statistics deprive the control of its learning mechanism, while environments treating overturns as coaching material improve continuously. Senior reporting should present overturn analysis as control-health evidence alongside volume metrics, since disposition quality ultimately matters more than disposition speed.

Automation confidence and the human-review boundary

Automated disposition of low-risk alerts promises capacity relief but creates the control risk of machine error at scale, where a flawed auto-clear rule clears thousands of candidates before detection. Confidence-threshold design must therefore be conservative, evidence-based and continuously validated: auto-disposition limited to narrowly defined patterns with extensive historical validation, corroborating-identifier requirements that machines verify deterministically, and exclusion of all higher-risk attributes regardless of score. Each auto-disposition rule carries defined scope, validation evidence, performance monitoring and revocation triggers, approved at senior level with model-risk involvement where scoring models contribute.

Human-review boundary placement reflects the asymmetry between error types: false-positive auto-escalation wastes analyst time while false-negative auto-clearance creates legal exposure, so boundaries must bias toward human review wherever uncertainty exists. Sampling of auto-disposed alerts by independent reviewers verifies continued rule validity, with sample sizes supporting the claimed error rates and stratification covering rule subtypes and population segments. Rule-drift monitoring tracks the underlying populations for changes invalidating validation assumptions: customer-base shifts, list-composition changes and transaction-pattern evolution each trigger revalidation. Auto-disposition is a privilege earned through evidence and maintained through monitoring, never a capacity solution implemented to relieve queues.

Cognitive bias in match resolution

Analysts resolving matches face systematic cognitive biases that procedures must counteract rather than assume away. Confirmation bias drives premature true-match conclusions where initial similarity feels compelling, with subsequent evidence interpreted as corroboration; structured disconfirmation requirements, mandatory distinguishing-evidence checks before true-match confirmation, provide the procedural counterweight. Availability bias overweight recent high-profile cases, so analysts emerging from major true-match investigations see matches everywhere; workload rotation and calibration exercises using seeded false positives maintain proportion. Anchoring on screening scores treats algorithmic output as evidence rather than hypothesis; score-blind review stages, where analysts assess identity evidence before viewing scores, preserve independent judgement.

Commercial-pressure bias pushes toward clearance where transactions are urgent, valuable or customer-sensitive; dual-control requirements for time-critical releases, with the second reviewer explicitly charged to resist urgency framing, provide structural protection. Automation bias accepts machine suggestions uncritically, particularly dangerous where auto-populated resolution rationales invite analyst sign-off without independent reasoning; requirements for analyst-authored reasoning in the analyst's own words, rather than edited machine text, preserve accountability. Training should name these biases explicitly with case examples from the bank's own overturn history, since abstract bias awareness rarely survives contact with queue pressure while concrete institutional examples resonate.

Thin-data protocols: deciding with incomplete information

Payment and customer alerts frequently arrive with minimal data: single-name references without identifiers, truncated addresses, no ownership visibility, counterparties identified only by account numbers. Thin-data protocols define how far investigation proceeds on limited information, what additional sources are pursued in what order, and when thinness itself becomes the decision driver. The protocol sequences enrichment from fastest to slowest: internal data joins across customer, account and transaction systems; list-record detail examination for distinguishing attributes; commercial and registry sources for entity resolution; customer contact within tipping-off constraints; and correspondent or counterparty inquiry for cross-border cases.

Decision standards for persistently thin cases must be explicit: where enhanced inquiry is exhausted and identity remains unresolvable, the transaction does not proceed on the basis that nothing was proven. This inconclusive-hold standard requires senior support and customer-communication preparation, since it produces the most commercially painful outcomes from the least satisfying evidence. Documentation of thin-data cases must show the enrichment attempted with dates and outcomes, preventing both premature closure and indefinite drift. Monitoring of thin-data case volumes by channel and corridor identifies systemic data-quality failures masquerading as investigation backlogs: where thinness concentrates, the remediation is data capture and lineage improvement rather than analyst effort.

Alert-ageing governance and backlog prevention

Ageing alerts represent deteriorating control: each day an unresolved candidate persists, the underlying transaction or relationship continues operating on unassessed risk, and backlog accumulation eventually forces triage shortcuts that sacrifice quality for currency. Ageing governance starts from tier-differentiated age limits reflecting consequence: minutes-to-hours for time-critical true-match candidates, days for standard reviews, defined weeks for low-risk pattern clearances with sampling. Breach escalation must carry real consequences, automatic senior notification, capacity reallocation, root-cause analysis distinguishing surge-driven backlogs from chronic under-resourcing, rather than functioning as reporting decoration that queues learn to ignore.

Backlog-prevention architecture addresses causes structurally rather than clearing symptoms through overtime alone. Demand forecasting models alert volumes from list-change calendars, business-growth projections and seasonal patterns, triggering advance capacity arrangements before queues build. Triage automation disposes of defined low-risk patterns systematically, preserving analyst capacity for judgement-intensive cases instead of distributing all alerts equally. Allow-list governance with expiry and revalidation prevents repeat-alert accumulation from verified-clean entities. And upstream precision investment, matching-threshold calibration and data-quality improvement, reduces inflow at its source rather than expanding downstream capacity indefinitely. Backlog incidents require post-mortem analysis with published findings and tracked remediation, since recurring backlogs indicate structural capacity or design failure that incident-mode effort alone cannot resolve permanently.

Staffing, skilling and shift models for match operations

Match-review operations need staffing models reflecting the work's cognitive demands and temporal distribution rather than generic processing-team templates. Skill-tiering aligns analyst capability with alert complexity: entry-level reviewers handle high-volume standard patterns with defined procedures, experienced analysts take thin-data and ownership-complexity cases, and specialists cover transliteration, corporate-structure and legal-boundary questions. Progression pathways with demonstrated-competence gates, rather than tenure-based advancement, ensure reviewers face complexity they are equipped to resolve. Cross-training across customer, payment and trade-alert types builds roster flexibility for surge response while deepening analysts' institutional understanding.

Shift and coverage design must match the control's temporal obligations: real-time payment screening needs review coverage aligned to payment-system operating hours including weekends and holidays where instant payments flow continuously, while batch-review operations can follow business-day models with defined Monday-backlog provisions. Follow-the-sun arrangements for global banks need handoff discipline with case-state continuity, preventing the investigation fragmentation where cases restart with each timezone change. Fatigue management recognises match review as sustained high-concentration judgement work: realistic productivity expectations segmented by complexity, break discipline, rotation between alert types, and workload monitoring with intervention triggers protect both analyst wellbeing and decision quality. Attrition analysis treats experienced-reviewer departure as control-capability loss requiring succession planning rather than headcount replacement alone.

Continuous improvement loops from disposition data

Disposition data accumulates into the control-improvement fuel that distinguishes learning operations from static ones, provided feedback loops are designed deliberately rather than assumed emergent. Tuning feedback routes false-positive driver analysis to matching-threshold and suppression-rule owners with defined review cadence, so that recurring benign patterns systematically reduce future alert burden instead of taxing analysts indefinitely. Training feedback routes error-pattern and overturn analysis to training designers with case material drawn from the bank's own decisions, keeping learning grounded in institutional reality rather than generic examples. Procedure feedback routes friction-point and ambiguity reports from analysts to procedure owners, since frontline reviewers discover procedural gaps first and need channels that convert discovery into revision.

Data feedback routes field-completeness and quality findings to data-governance and front-office owners with measurable improvement targets, closing the loop between investigation difficulty and origination quality. Each loop needs ownership, cadence, tracking and effectiveness measurement: improvements claimed without before-and-after evidence are assertions rather than achievements. Governance reporting should present loop performance alongside disposition metrics, demonstrating that the operation learns systematically from its own output rather than merely processing it. The compounding effect of functioning feedback loops over time exceeds any single control investment, since each loop multiplies the value of all others through shared evidence and aligned improvement.

Visual control checkpoint: direct list match versus ownership exposure

The distinction matters operationally. A customer can be unlisted yet still subject to sanctions consequences under an applicable ownership or control rule. The case should record which path created the exposure rather than labelling every sanctions issue as a name-screening hit.

Boundary cases: where sanctions identity decisions most often go wrong

When two identifiers disagree with each other

A customer name, date of birth and nationality align with a sanctions target, but a passport number appears different. The analyst should not automatically clear the case until the reliability of both passport values is understood. One source may contain an expired passport, a transcription error, multiple passports or an identifier issued by a different authority. The case should establish whether the apparent contradiction is genuinely discriminating evidence or simply inconsistent source quality.

The control principle is that identifiers must be interpreted, not merely counted. Three aligned weak attributes do not automatically outweigh one reliable unique mismatch, and one apparent mismatch does not automatically outweigh several strong consistent identifiers if the mismatching field is uncertain.

When the customer changed identity data legitimately

People and companies can change names, citizenship, addresses, legal form, registration details or ownership for legitimate reasons. Historical sanctions records can contain former names or old addresses. A current-data-only comparison can therefore miss a genuine link or create a false mismatch.

Investigators should use effective dates and historical KYC where relevant. If a company changed legal name after a merger, the old name can still connect it to a target record. If a person changed nationality, the previous nationality can remain useful historical identification evidence without proving anything adverse by itself.

When two official sources appear inconsistent

A sanctions authority's list, explanatory notice or later amendment can occasionally present information differently across time. The bank should rely on the current authoritative source and preserve the list version used at the time of the decision. If a discrepancy is material, it should be escalated rather than silently resolved by choosing whichever value makes the case easier to close.

Vendor data can add another layer. A commercial provider may normalise or enrich the authority's record with additional aliases or identifiers. Analysts should be able to distinguish official data from vendor research so that the evidential basis of the decision remains clear.

When the same person appears under several programmes

A person can be designated by multiple authorities or under multiple programmes. Once identity is established, the bank should not create contradictory identity decisions for each record. The identity conclusion can be shared while the legal-applicability analysis remains programme-specific.

This matters operationally because one programme can create a full asset freeze while another imposes narrower restrictions. Removing one designation later does not necessarily make the customer unrestricted if another applicable designation remains.

When the payment party is only partially identified

A payment may contain a beneficiary name and account number but no date of birth, registration number or reliable address. If the name strongly aligns with a target, the case can remain unresolved because the bank lacks evidence. The account number itself may help correlate repeat payments or prior investigations, but it does not establish personal identity unless linked reliably to the beneficiary.

A good operating model makes thin-data uncertainty visible. It does not convert a lack of information into a false positive merely because the bank cannot obtain more detail immediately.

When a relationship exits before the alert is resolved

A customer may close an account, cancel onboarding or withdraw a payment while sanctions review is open. The case should not disappear simply because the commercial relationship ends. The bank may still need to resolve the alert, preserve evidence, assess whether any property is held and meet reporting or recordkeeping obligations under applicable law.

Workflow requirements should therefore separate case closure from product or relationship closure. A commercial exit can reduce future exposure but does not rewrite what happened before the exit.

When a false positive is operationally correct but poorly evidenced

An analyst may reach the right conclusion for the wrong documented reason. For example, the customer may clearly be a different person because of a unique identifier, but the note says only “different country.” QA should still treat the documentation weakness seriously. Regulators and future reviewers need reproducible evidence, and a weak rationale can make a correct historical decision appear unsupported.

Quality therefore includes both outcome accuracy and evidence quality. Training, case design and QA should reinforce both.

Knowledge check

1. What is the difference between a screening candidate, a false positive, an unresolved potential match and a true identity match?

2. Why must missing list data not be treated as contradictory evidence?

3. Why can a true identity match still require a separate legal-applicability decision?

4. How can an unlisted company create a true sanctions exposure without being a true name match?

5. What evidence should be preserved when a historical false-positive decision is reopened?

6. Why should an RFI ask for specific missing evidence rather than request every possible customer document?

7. What types of cases deserve targeted QA even if random sampling is already performed?

8. Why is a vendor or AI “high confidence” label not the bank's final sanctions conclusion?

Answer guide

A candidate is a technical comparison requiring review; a false positive is evidence that the screened party is different from the target; an unresolved potential match means the bank lacks enough reliable evidence; a true identity match establishes that the screened party is the target. Missing list data cannot contradict customer data because there is nothing to compare. Identity alone does not tell the bank which programme restriction applies or what action is required. An unlisted company can be covered through ownership or control under the relevant regime. Reopening should preserve the old list version, evidence, decision and reason for the new review. Focused RFIs reduce friction and directly address the decision gap. Targeted QA should include high-score false positives, low-score escalations, transliteration, thin-data cases, ownership/control cases, overrides and reused suppressions. Vendor or AI labels are inputs whose underlying evidence still needs bank-controlled review.

Glossary

Candidate alert — A system-generated comparison that requires investigation.

False positive — A candidate resolved with evidence showing that the screened party is not the sanctions target or otherwise not the relevant covered party.

Potential / unresolved match — A controlled state where available evidence is insufficient to clear or confirm the candidate.

True identity match — A conclusion that the screened person, entity or asset is the same as the official sanctions target.

Ownership-based exposure — A sanctions exposure created because an unlisted entity is owned by a designated or blocked person under the applicable rule.

Control-based exposure — A sanctions exposure or legal concern arising from control under the relevant regime; the legal test is jurisdiction-specific.

Legal applicability — The decision about which sanctions restriction applies to the confirmed identity or covered entity in the bank's legal and product context.

Disposition — The resulting operational action, such as release, reject, freeze/block, restrict or report.

Evidence provenance — The source, date and verification status of a fact used in the decision.

Confirmed mismatch — Reliable evidence demonstrating that a compared identifier or attribute is incompatible with the target.

Missing evidence — Information that is not available and therefore cannot be treated as a match or mismatch.

Reopening — Starting a new review of a previously resolved comparison because list data, customer data, ownership or other material facts changed.

Maker-checker / four-eyes control — A requirement for an independent second review of defined high-impact or complex decisions.

QA overturn — A quality-assurance finding that changes or rejects the original analyst conclusion.

RFI — Request for information used to obtain specific evidence needed to resolve an identity or legal question.

References and further reading

Identity resolution should be grounded in the complete authoritative sanctions record and reliable customer, counterparty or asset evidence. A screening alert is a candidate for investigation, not a legal conclusion. Once identity or another form of sanctions exposure is established, the bank must separately determine the applicable programme, jurisdictional nexus, ownership or control rule, restriction, licence or exemption, reporting duty and operational action.

• U.S. Treasury OFAC — FAQ 5, assessing potential matches and reviewing complete list-entry identifiers: https://ofac.treasury.gov/faqs/5
• U.S. Treasury OFAC — Sanctions List Service: https://ofac.treasury.gov/sanctions-list-service
• U.S. Treasury OFAC — Assessing OFAC Name Matches / Blocking and Rejecting decision guidance: https://ofac.treasury.gov/faqs/topic/1591
• U.S. Treasury OFAC — Entities Owned by Blocked Persons (50 Percent Rule), including FAQ 398 on ownership versus control: https://ofac.treasury.gov/faqs/topic/1521
• U.S. Treasury OFAC — Compliance Hotline and current match-guidance entry point: https://ofac.treasury.gov/ofac-compliance-hotline
• UK Office of Financial Sanctions Implementation — UK financial sanctions general guidance: https://www.gov.uk/government/publications/financial-sanctions-general-guidance/uk-financial-sanctions-general-guidance
• UK Government — UK sanctions collection and designation resources: https://www.gov.uk/government/collections/uk-sanctions
• Wolfsberg Group — Sanctions Screening Guidance: https://wolfsberg-group.org/resources/legacy/53
• European Commission — EU sanctions overview and related resources: https://finance.ec.europa.eu/eu-and-world/sanctions-restrictive-measures/overview-sanctions-and-related-resources_en
• European Commission — Asset freeze and prohibition to provide funds or economic resources, current Russia/Belarus FAQ set: https://finance.ec.europa.eu/publications/asset-freeze-and-prohibition-provide-funds-or-economic-resources_en
• FATF — FATF Recommendations: https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Fatf-recommendations.html
• FATF — June 2026 Recommendation 6 update on targeted financial sanctions and humanitarian exemptions: https://www.fatf-gafi.org/en/publications/Fatfrecommendations/update-recommendation-6-june-2026.html

Accuracy note — reviewed 15 September 2026: OFAC and OFSI both make clear, in their own jurisdiction-specific terminology, that an initial name or screening alert is not automatically a valid or target match. Investigators should compare the available identifying information, distinguish missing information from contradictory information, preserve the evidence used and then apply the legal consequence associated with the relevant sanctions regime. Wolfsberg likewise treats alert generation as the start of investigation rather than proof of sanctions exposure. FATF establishes targeted-financial-sanctions standards but does not prescribe a universal bank alert taxonomy, matching threshold or disposition workflow. OFAC's 50 Percent Rule is an ownership test: control without 50 percent or greater aggregate ownership does not by itself make an entity automatically blocked under that rule, although other prohibitions, designations or programme-specific rules can still matter.