Auditors do not ask whether you screened today; they ask what you knew on a past date and whether you can prove it. Historical sanctions data plus a complete audit trail answers both questions. This guide explains which history to keep, how lookback screening works, and what evidence makes examiners confident in your program.
Why does history matter more than the current list?
Sanctions lists change constantly through designations, delistings, alias additions, and program updates. A customer who screens clean today may have matched a designation that applied two years ago, and a name cleared last quarter may have been relisted under a new program. Without versioned history, you cannot reconstruct what the correct decision was at the time of the transaction.
Examiners focus on exactly this gap. They sample historical transactions and ask which list version applied and how the alert was resolved. Teams that only store the latest screening verdict struggle here. Teams with strong screening pipelines store the list version, the match logic, and the disposition together, so any past decision can be replayed on demand.
What should you keep for every screening decision?
Keep enough to replay the decision. At minimum, record the screened name and identifiers as submitted, the normalized form used for matching, the watchlist source and version with its publication date, the rules and thresholds in force, and the score or match detail for every hit. Then add the human layer: who reviewed the alert, what evidence they used, the disposition and reason code, and timestamps for each step.
Retention should cover the full lookback window your regulator expects, plus a margin for investigation lag. Store list deltas rather than full snapshots where storage is a concern, but make sure deltas are complete enough to rebuild any historical list state. Link screening records to the underlying customer and transaction in case-management so an examiner can move from a ledger entry to its screening evidence in a few clicks.
How does lookback screening actually work?
Lookback screening re-runs historical customers and transactions against list changes, usually after a new designation round or a data-quality remediation. The trigger might be a newly listed entity with broad aliases, a corrected date of birth that suddenly makes old records matchable, or an examiner request to prove that a past period was clean.
A sound lookback has a defined scope, a frozen historical dataset, and a documented outcome. Scope covers the date range, the customer segment, and the list versions applied. The dataset is frozen so re-runs are reproducible. Outcomes record how many new alerts fired, how each was dispositioned, and which remediation followed. Running lookbacks through continuous monitoring rather than one-off spreadsheets keeps the method consistent and the evidence centralized.
| Evidence item | What it proves | Common failure |
|---|---|---|
| Watchlist version and publish date | Which rules applied on that day | Storing only the screening verdict with no list reference |
| Input record and normalized form | The decision was based on complete data | Re-screening cleaned data and claiming it reflects history |
| Rule set and thresholds | Matching behavior was controlled | Undocumented tuning changes between periods |
| Reviewer, evidence, and disposition | Alerts were resolved deliberately | Missing reason codes or unsigned overrides |
How do you handle delistings and list corrections?
Delistings create some of the hardest audit questions. A customer blocked under an old designation may later be delisted, renamed, or narrowed to a specific alias, and the business wants the relationship restored quickly. The compliant path is to keep the original blocking evidence intact, record the delisting notice with its source and date, and document a fresh risk decision rather than editing history.
List corrections need similar care. When a publisher fixes a birth year or removes an alias, preserve both the erroneous and corrected versions with their validity periods. Future examiners may ask why an alert fired or did not fire during the faulty window, and the version trail is the only honest answer. Where the customer relationship continues, connect the updated assessment to your aml risk rating so the file tells one coherent story.
Never overwrite historical screening results with re-screened outcomes. Append corrections as new records with new timestamps, and keep the original verdict visible for audit replay.
An audit trail is a time machine: it should let a stranger stand in your shoes on any past date and reach the same decision. by Ambriel Team, Editors
Building an audit-ready archive
Historical coverage does not require exotic tooling. Version your lists, freeze your inputs, log every rule change, and store dispositions with evidence where reviewers already work. Test the archive by replaying a sample quarter before the examiner arrives: pick closed alerts, rebuild the list state, and confirm the file answers what was screened, against what, and why.
Historical Sanctions Data FAQ
Historical sanctions data is the versioned record of watchlists, aliases, designations, and delistings over time, paired with the screening inputs and decisions made under each version. It lets teams replay past decisions during audits and lookbacks.
Keep them for at least the full regulatory lookback window that applies to your business, plus a margin for investigation and appeal lag. When in doubt, align retention with your broader financial crime record-keeping schedule.
New designations with broad aliases, alias or identifier corrections, data-quality remediation that makes old records newly matchable, and examiner or audit requests. Each run should document its scope, dataset freeze, and disposition outcomes.
Dated list versions, frozen inputs, rule and threshold records, match details, reviewer identity, evidence used, disposition reason codes, and timestamps. Linked records that connect transactions to screening outcomes carry more weight than summaries.