Lookback Review

A lookback review is a controlled retrospective examination of customers, transactions, alerts, decisions or control coverage after the bank learns something material that was not known, not available or not handled correctly at the time. The trigger might be a transaction-monitoring defect, a missing data feed, a newly identified suspicious network, a sanctions-screening weakness, an internal audit finding, a supervisory action, a law-enforcement request or a material change in the bank's understanding of a customer. The purpose is not simply to rerun old data. It is to determine what happened, what the bank could and should have detected, what legal or regulatory consequences may now follow, what present-day risk remains and what must change so the failure does not continue.

The phrase lookback review is widely used in financial-crime practice, but it is not one globally standardised statutory process. Different authorities may require historical transaction reviews in different ways, and the legal consequences of a retrospective finding depend on jurisdiction, entity, product, timing and applicable law. A U.S. enforcement order may explicitly require a suspicious-activity-reporting lookback, while another jurisdiction may expect remediation through supervisory findings, an AML/CTF programme review, a sanctions control assessment or a targeted customer investigation. The professional discipline is therefore to treat lookback as a method of retrospective control assurance, not as a universal legal label with identical duties everywhere.

A strong lookback separates four workstreams from the beginning. The control-effectiveness workstream reconstructs what the control was expected to do and where it failed. The legal and reporting workstream decides whether historical findings create current obligations under the applicable law, including suspicious-transaction reporting, sanctions reporting, asset restrictions or other regulatory communication. The customer and operational remediation workstream addresses relationships that remain open, inaccurate customer profiles, restrictions, exits, payment consequences and customer harm. The evidence workstream preserves the data, configuration, decisions and lineage needed to show how conclusions were reached. Combining all four into one vague “historical review” queue is a common source of inconsistent outcomes.

A lookback is a controlled sequence from trigger and scoping through historical reconstruction, review, legal decisioning, remediation and closure.

Why lookbacks matter in a bank

Financial-crime controls are never static. Customers change, payment products evolve, fraud and laundering methods adapt, sanctions lists and legal measures change, data platforms are migrated and monitoring models are tuned. A control can appear healthy in management information while a particular population is missing from the feed, an enrichment field is mapped incorrectly or an exclusion rule silently removes relevant transactions. When such a defect is discovered, fixing tomorrow's processing is only half the job. Management still needs to understand the historical exposure created during the period in which the control was ineffective.

That historical exposure can be significant even when no criminal activity is ultimately found. A lookback may reveal that the population missed by the control was small and benign, which is useful evidence supporting proportionate closure. It may identify customers whose activity needs enhanced due diligence. It may uncover transactions that should be escalated for investigation. It may reveal suspicious activity that now needs assessment under local reporting rules. In a sanctions context, it may identify historical dealings with a party that was restricted at the relevant time, requiring legal analysis of the measure that then applied and the bank's role in the activity. The result is therefore not predetermined. A lookback is an evidence exercise, not a hunt for a desired number of cases.

The board and senior management also need lookbacks because forward-looking remediation can conceal the scale of an old defect. If a bank discovers that one payment channel was excluded from transaction monitoring for nine months, a successful production fix proves only that the channel is monitored now. It does not answer how many transactions were missed, which customers were affected, whether other connected channels were affected, whether suspicious activity went unreported or whether the defect indicates a wider weakness in data governance. A credible programme closes both questions: is the control effective now, and what must be done about the period when it was not?

What can trigger a lookback

Triggers can be external or internal. External triggers include supervisory findings, enforcement orders, requests from a financial intelligence unit or law-enforcement agency, correspondent-bank inquiries, audit requirements imposed by a monitor and material legal or sanctions developments. Internal triggers include data-quality incidents, failed reconciliations, defects in rule or model logic, incorrect scenario thresholds, missed list updates, vendor-system faults, configuration changes, control testing failures, whistleblower information, repeated quality-assurance errors and investigations that reveal the same issue may have existed earlier than first thought.

The fact that an issue is historical does not automatically make a full-book lookback necessary. The trigger must be translated into a control hypothesis. For example: “Transactions initiated through API channel X between 1 February and 17 May were omitted from scenario Y because product code P17 was not mapped to the monitoring feed.” That statement is far more useful than “monitoring had a gap.” It defines a population, mechanism and time period that can be tested. If the investigation then shows the same mapping logic was reused by another product, the scope can be expanded on evidence rather than intuition.

Materiality is important, but it should not become a mechanism for avoiding inconvenient work. A low-volume population may still be high risk if it contains correspondent banking, private banking, high-risk geographies, virtual-asset flows or sanctions-sensitive activity. Conversely, a very large population does not always require individual manual review if reliable analytics can identify the subset affected by the specific control failure. Good governance records why a lookback was initiated, why it was not initiated where management chose not to do one, and which facts would cause that decision to be revisited.

Lookback triggers should be translated into a specific control hypothesis before scope is fixed.

Scoping the historical period

Time is often the first difficult question. The review should normally begin from the earliest date at which evidence shows the relevant control may have been ineffective and continue until the date on which the fix was demonstrated to be effective. A release date is not necessarily a control-effective date. If a software correction was deployed on 10 June but reconciliation and backtesting did not confirm stable data until 15 June, the bank needs a reasoned view on which date closes the exposure period.

Historical configuration is valuable here. Release notes, change tickets, deployment logs, vendor versions, mapping tables, watchlist-load records, scenario versions, data-quality incidents and batch-reconciliation evidence can help identify when a problem began. Where the onset cannot be established precisely, the safer professional response is to document uncertainty and choose a conservative boundary rather than use the narrowest date that minimises workload. Scope should be capable of surviving independent challenge.

Long lookbacks can cross changes in law, customer ownership, product terms, sanctions measures, data models and system architecture. The programme therefore needs effective dating. A transaction from 2022 should be assessed using the facts and legal context relevant to 2022 where the question is whether the bank complied at that time. Current information may still be relevant to present-day customer risk, but it should not be silently substituted for historical truth.

Defining the affected population

Population design follows the failure mechanism. If a feed dropped one channel, the first population is the transactions that should have arrived from that channel. If a sanctions engine failed to ingest an updated list, the population may be customers and payments exposed during the period between the required update and the corrected load. If a monitoring scenario excluded one product type, the population should be built from the product and transaction attributes that prove inclusion or exclusion, not from a convenient sample of cases already visible to compliance.

A defensible population usually has a reproducible query or data specification. It explains source systems, fields, filters, dates, joins, deduplication rules and known limitations. Counts should reconcile to independently controlled totals where possible. For payment flows, the bank may need to reconcile channel events, payment-hub records, ledger postings and clearing or settlement records because no single system always represents the whole lifecycle. For customer screening, the population may require effective-dated customer, beneficial-owner, director and connected-party relationships rather than a current customer table.

Sampling is appropriate only when it answers the review question. If the bank needs to determine whether any transaction involving a particular designated party occurred, sampling is generally the wrong method because one missed true match matters. If the review is assessing whether a defect produced a measurable error rate across a lower-risk population, statistically or risk-based sampling may be appropriate. The design should state what inference is being made from the sample and what is not being claimed.

A defensible scope combines time, affected population, review question and evidence boundaries rather than starting from workload capacity.

Historical data reconstruction

Historical reviews fail when the data team is asked merely to “pull the old transactions.” A transaction is rarely enough by itself. The investigator may need the customer profile that existed then, expected activity, risk rating, beneficial ownership, counterparty information, product details, device or channel information, payment message data, case history, prior alerts, screening results, watchlist version, scenario version and the actual data presented to the original control. If any of these were transformed between source and monitoring platform, lineage matters.

The concept of frozen-time truth is useful. For each material event, reconstruct the state that existed at the relevant date. If a company changed owners in 2025, a 2024 payment should not be attributed automatically to the 2025 owner. If a customer was reclassified as high risk after new adverse information emerged, that current rating can inform today's relationship decision, but it should not be misrepresented as the rating held when the historical transaction occurred. If a sanctions designation was added or removed, the effective dates and the legal measure in force at the transaction date must be preserved.

Data gaps must be recorded as findings, not hidden by default values. A missing address should remain missing unless another authoritative source can reconstruct it and the provenance is recorded. A migration that truncated free-text remittance information should be documented. If an archive retained ledger postings but not the original payment message, the review needs to explain which screening-relevant fields cannot be recovered. This distinction protects the integrity of the review and prevents false certainty.

Record retention creates real limits. FATF Recommendation 11 establishes an international standard for keeping transaction and CDD records for at least five years, but national laws may impose specific periods or additional requirements. A lookback should identify the law and policy that governed the relevant record set rather than assume every historical field must exist indefinitely. If information was lawfully deleted under an applicable retention schedule, the programme should document that limitation and determine whether alternative evidence can be used.

Replay, backtesting and reconstruction are not the same thing

A common technical mistake is to assume the bank can simply replay historical transactions through today's monitoring engine. That may be useful, but it answers only one question: what would today's logic flag if today's engine received the reconstructed historical input? It does not necessarily show what the old control should have done, whether the old legal requirement was met or whether the current model is appropriate for the historical period.

A more disciplined approach keeps three methods separate. Historical reconstruction attempts to reproduce the inputs, configuration and decision environment that existed at the time. Corrected-control replay applies the control that should have operated during the affected period, using the right historical data and repaired logic. Current-control backtesting applies present detection logic to historical data to identify additional risk or validate modern coverage. Each method is useful, but each supports a different conclusion.

This distinction matters when thresholds, typologies and customer segmentation have changed. Suppose a 2023 rule used a threshold of 50,000 and current intelligence has led the bank to lower it to 20,000. Replaying 2023 activity using 20,000 may identify useful cases for present investigation, but it cannot by itself prove the bank breached its 2023 obligation. The review should be clear about whether it is testing historical compliance, present risk or both.

Hindsight: use new knowledge without rewriting history

Lookbacks inevitably benefit from information that did not exist at the time. A customer may later be convicted, a network may be identified by law enforcement, a typology may become well understood or a beneficial owner may be exposed through new data. New knowledge can legitimately guide risk-based prioritisation and current decisions, but it must not be used to pretend an earlier analyst possessed information that was unavailable.

The review should therefore label important facts by knowledge date and effective date. Knowledge date asks when the bank actually received or could reasonably access the information. Effective date asks when the underlying status legally or factually applied. Those dates can differ. A later disclosure can reveal that an ownership arrangement existed years earlier; the legal ownership may be historically effective even though the bank learned of it only later. That is different from applying a 2026 sanctions measure retroactively to a 2024 transaction when the measure did not apply at the earlier date.

A fair lookback can reach two conclusions at once: the historical analyst may have acted reasonably on the evidence then available, and the bank may still need to investigate or remediate the relationship now because new evidence changes the present risk assessment. Mature governance allows that nuance rather than forcing every retrospective finding into “old decision good” or “old decision bad.”

Historical review separates event time, control configuration, knowledge time and current risk so hindsight informs the investigation without rewriting the past.

From review hit to investigation

Not every lookback hit should become a full case. The programme needs triage rules that preserve risk sensitivity while controlling volume. A hit can be resolved where reliable evidence shows it is outside scope, a duplicate, a data artefact or an explainable activity consistent with the customer profile. Where the hit indicates unexplained behaviour, a sanctions concern, a network relationship, a mismatch with expected activity or another meaningful risk factor, it should move into the institution's normal case or investigation process with a clear label that it originated from a historical review.

Investigators should be able to see both the historical activity and present relationship. This is important because an apparently isolated old transaction may become significant when the customer is still active and similar behaviour continues. Conversely, an old anomaly may be fully explained by evidence unavailable to the automated control. The case should capture the review trigger, scope, historical facts, current facts, source evidence, investigator reasoning, escalation and final decision.

Where multiple customers or accounts are connected, network analysis can be more useful than isolated transaction review. Shared addresses, directors, devices, counterparties, remittance patterns, account funding, common intermediaries or sequential movements can show that the risk is organised across entities. The programme should avoid turning weak connections into guilt by association: every relationship still needs a reasoned assessment of what the link means.

Reporting decisions: local law governs

A lookback can uncover activity that was not reported when it occurred. The correct response is not a generic rule that every historical hit becomes a “late SAR.” Suspicious transaction and suspicious activity reporting duties are created by domestic law and FIU rules, with different triggers, timing concepts, thresholds and confidentiality requirements. The bank must assess the facts under the law applicable to the relevant legal entity and activity.

In the United States, for example, the Bank Secrecy Act framework and implementing rules establish SAR duties for covered institutions, and U.S. regulators have explicitly required historical SAR lookbacks in enforcement actions. That is a useful illustration of lookback practice, not a template that should be presented as the global rule. In Australia, suspicious matter reporting operates under the Australian AML/CTF framework and AUSTRAC's current rules and forms. In the United Kingdom and European jurisdictions, reporting and disclosure architecture is different again. Global programmes need jurisdiction mapping rather than a single universal filing instruction.

Where a current reporting obligation is triggered by a historical finding, the narrative should explain the chronology accurately. The bank should not manipulate “discovery dates” to make an old event appear current. Legal and compliance teams should determine how the relevant FIU expects historical discoveries to be reported and whether supplementary reports, linked cases or other mechanisms are appropriate. Confidentiality and tipping-off restrictions must also be respected when customer communication or account actions are considered.

Sanctions lookbacks require a different legal lens

A sanctions lookback is not simply transaction monitoring with a different watchlist. The programme may need to establish which restrictive measure applied at the transaction date, whether the bank or transaction had the necessary jurisdictional nexus, whether a party was designated, whether ownership or control rules captured an unlisted entity, whether a licence or exemption applied and what the bank actually did with funds or economic resources.

A historical match does not automatically mean funds should be frozen today. The current asset position matters. A transaction completed years ago may require historical legal analysis and reporting even though there is no asset currently held by the bank. A relationship that remains open may require current restrictions. A designation may have changed. The correct action therefore depends on both the historical legal question and the present legal position.

For EU institutions, the EBA's restrictive-measures guidelines, applicable from 30 December 2025, reinforce the need for governance, policies, procedures and controls for Union and national restrictive measures. They do not create a universal global sanctions rule. U.S. OFAC requirements, UK sanctions law and other regimes have their own legal frameworks. A global lookback should preserve these distinctions at entity and transaction level.

Customer remediation and present-day risk

Historical review should not become detached from the live customer relationship. If the customer remains active, material findings may require event-driven KYC or KYB refresh, source-of-funds or source-of-wealth enquiries, beneficial-ownership verification, risk-rating changes, enhanced monitoring, restrictions, senior approval or exit consideration according to policy and law. The objective is to understand whether the historical issue changes today's view of the customer.

Customer impact needs governance. A retrospective alert should not automatically cause an account restriction if the legal basis and risk evidence do not support it. Equally, fear of customer inconvenience should not suppress action where the bank has identified genuine ongoing risk. Operations, compliance, legal and the business should know who can impose holds or restrictions, how urgent cases are escalated, how vulnerable customers are treated and what communication can be given without compromising reporting confidentiality.

If the defect itself caused customer harm — for example, incorrect sanctions matching repeatedly blocked legitimate payments — remediation may include correction of customer records, fee or interest adjustments, complaint handling and control tuning. A lookback is therefore capable of finding both missed financial-crime risk and over-control. Quality assurance should look for both.

Control remediation and root cause

Every material historical finding should be connected to the control weakness that allowed it. A feed gap may point to weak interface reconciliation. A scenario gap may expose poor typology governance. Repeated analyst errors may indicate training, procedure or case-UI problems. A vendor defect may reveal inadequate acceptance testing, release governance or service monitoring. Customer data gaps may arise from upstream onboarding architecture rather than from the monitoring engine itself.

Root-cause analysis should reach beyond “human error” or “system issue.” Those labels are descriptions, not causes. Useful root causes identify the condition that can be changed: no reconciliation between source and target transaction counts; no effective-dated configuration archive; product-launch governance omitted AML data requirements; rule changes were approved without negative testing; list-loader failures did not alert operations; reviewers lacked the source documents needed to resolve beneficial ownership.

Remediation is complete only when effectiveness is demonstrated. A production release, updated procedure or training session is an action. Evidence that the control now receives the complete population, produces expected outputs, handles exceptions and remains stable under failure conditions is closure evidence. This is why lookbacks should feed directly into testing and control-assurance plans.

Governance and decision rights

A significant lookback usually needs formal governance because its scope can expand, deadlines can become material and findings may create reporting or customer consequences. The programme should identify an accountable executive, compliance ownership, legal support, data and technology owners, operations leads, business representatives, quality assurance and independent challenge. Audit may provide assurance, but it should not be made operational owner of the remediation it later needs to assess independently.

Scope changes should be controlled. If early results show the defect began earlier, affected more products or produced a higher risk outcome than expected, the programme must have a mechanism to expand scope quickly. Conversely, reducing scope should require evidence and approval, not simply pressure to meet a deadline. Decisions should be documented so that a future supervisor can understand who knew what, when and why the bank chose the final approach.

Management information should focus on outcomes rather than activity counts. Useful metrics include population completeness, reviewed cases by risk tier, unresolved data gaps, escalation volumes, reporting decisions, live-customer remediation, ageing, quality-assurance error rates, scope changes, remediation status and control-effectiveness evidence. “Ten thousand transactions reviewed” says little unless management knows whether the right ten thousand were selected and what conclusions the review supports.

Data architecture for a defensible lookback

Lookbacks expose whether the bank can reconstruct its own control history. A mature architecture retains effective-dated reference data, monitoring configuration, model or rule versions, sanctions list versions, customer relationship changes, alert and case decisions, payment messages and transformation lineage. The objective is not unlimited data retention; it is deliberate retention consistent with legal, privacy and records-management obligations so that required historical decisions can be reconstructed.

The architecture should distinguish source data, derived features, control configuration, decision output and human disposition. If a monitoring engine calculated a velocity feature from thirty days of transactions, a lookback may need both the underlying transactions and the feature logic. If a rule changed, the change should be versioned. If a data field was transformed, the mapping should be traceable. If an analyst overrode an alert, the reason and evidence should remain available according to retention requirements.

For business analysts and architects, this creates concrete requirements. Every critical monitoring interface should have source-to-target reconciliation. Every exclusion should be identifiable and owned. Rule and model releases should be effective-dated. Data dictionaries should state semantics rather than only field names. Case systems should preserve audit trails. Historical extracts should be reproducible using controlled code and parameter files rather than one-off analyst spreadsheets that cannot be rerun.

Testing a lookback programme

Testing begins before investigators open cases. Population tests should confirm that date, product, channel and customer filters return the intended universe. Reconciliation should compare source and target counts and values where suitable. Boundary testing should prove transactions at the start and end dates are handled correctly. Duplicate testing should prevent the same activity being counted repeatedly after joins across systems.

Control-replay testing should use known positive and negative cases. Positive tests show that the repaired logic identifies scenarios it should catch; negative tests show legitimate activity is not transformed into an unnecessary flood of false positives. Where current logic is used only for risk discovery rather than historical compliance testing, that distinction should be written into acceptance criteria.

Investigation-quality testing samples both escalated and closed cases. Reviewers should challenge whether evidence supports the decision, whether contradictory facts were addressed, whether jurisdiction and legal entity were correctly identified, whether reporting decisions were referred appropriately and whether current customer risk was assessed. For sanctions matters, quality review should test list identity, ownership or control analysis, nexus, timing and licence or exemption reasoning rather than only name similarity.

Failure-mode testing is especially valuable. What happens if an archive cannot be read? If the replay job stops halfway? If a list version is missing? If an extract is rerun with a corrected query? If a customer is closed during the review? If a new designation occurs while the historical review is still open? Designing these cases in advance prevents the programme from improvising under pressure.

A realistic mini case: the missing payment channel

Consider a fictional bank that operates online banking, host-to-host corporate files and an API payment channel. During a routine data-lineage review, the monitoring team discovers that a product-code change introduced eight months earlier caused a subset of API-initiated corporate payments to be excluded from two AML scenarios. Sanctions screening remained active, ledger posting was unaffected and customers saw no payment failure. The defect is therefore invisible to ordinary operations and cannot be measured by customer complaints.

The bank first defines the failure mechanism. Product code APX2 was introduced on 4 January. The monitoring interface accepted the payment records, but an enrichment rule classified them as an unsupported transaction type, so they were dropped before scenario evaluation. The defect was corrected on 3 September. Reconciliation after the fix confirms that APX2 payments now enter the scenario engine. Governance approves a lookback from 4 January through 2 September, with an initial population limited to APX2 payments and the customers that used them.

Data engineering reconstructs the payment universe from the source payment hub, reconciles it to ledger totals, then joins historical customer risk, expected activity, counterparties and the versions of the affected scenarios. The team preserves the original and corrected transformations. Because the old scenario logic itself was appropriate, the main replay uses the corrected feed with the historical scenario versions. A separate exploratory run uses current typology logic to identify additional present-day risk; its results are labelled as current-risk discovery, not proof of historical control breach.

Most replay hits are explainable corporate activity. A smaller group shows rapid pass-through payments to newly added counterparties inconsistent with the customers' expected profiles. Investigators open cases on those customers. One case identifies a customer that is still active and whose ownership changed after onboarding without timely refresh. The bank performs event-driven KYB, updates beneficial ownership, increases the risk rating and expands monitoring. Another case concerns a closed customer and historical activity that meets the bank's internal suspicion threshold. Compliance assesses whether a report is required under the law applicable to that legal entity rather than assuming that every lookback case must be filed.

The programme also finds a technology weakness beyond the original defect: source-to-monitoring reconciliation counted interface messages but did not confirm that records survived enrichment. The bank adds stage-by-stage completeness controls, product-code coverage checks and release testing that requires new product codes to prove monitoring eligibility before production. The lookback therefore produces more than historical cases; it changes the architecture that allowed the gap to remain silent.

This example illustrates the central discipline of lookback work. The bank does not rerun everything indiscriminately, does not treat today's rulebook as if it existed eight months earlier, does not convert every hit into a report and does not stop after deploying a fix. It reconstructs the failure, proves the population, reviews the right history, assesses legal consequences locally, remediates live risk and hardens the control.

Common failure modes

The first failure mode is scope by convenience: choosing a period or population because it fits available staffing rather than because evidence supports it. The second is current-state substitution: using today's customer, ownership, list or configuration data as if it were historically true. The third is black-box replay: producing thousands of alerts from a current engine without explaining what question the replay answers. The fourth is reporting automation: treating every historical alert as an automatic SAR, STR or sanctions report without jurisdiction-specific assessment.

Other failures are less visible. One team may review transactions while another separately reviews KYC, causing connected evidence to be missed. Data scientists may remove “duplicates” that are actually repeated payments. Analysts may close cases because the customer is no longer active even though historical reporting still needs assessment. Legal teams may receive only escalated summaries rather than source evidence. Operations may apply restrictions before compliance has established a legal or risk basis. Programme management may count completed reviews while unresolved data gaps make the result unreliable.

The best defence is an explicit evidence model and decision model. Every material conclusion should answer: what fact supports this, which date does it apply to, where did the data come from, which control or law is being assessed, who made the decision and what action follows? If the programme cannot answer those questions, volume and speed do not make it defensible.

What good looks like

A good lookback is finite, reproducible and connected to present control effectiveness. Its trigger is clear. Its scope is linked to the failure mechanism. Its population is reconciled. Historical data states are preserved. Replay methods are labelled honestly. New knowledge is used without rewriting history. Investigations connect old activity to current customer risk. Legal and reporting decisions are jurisdiction-specific. Remediation reaches root cause. Quality assurance tests both false negatives and false positives. Closure is supported by evidence that the live control works.

For a business analyst, the most useful question is not “How many historical transactions must we review?” It is “What decision are we trying to support, and what evidence must the system preserve so that decision can be reproduced?” For an investigator, the question is “What did the bank know then, what do we know now, and what does that change?” For an architect, it is “Can we reconstruct the data and control state at the relevant time?” For management, it is “Have we understood the historical exposure and proved the weakness is fixed?”

A lookback becomes valuable when those questions converge. It is not retrospective paperwork. It is the mechanism by which a bank turns a discovered weakness into quantified exposure, defensible decisions, repaired customer risk and a stronger control environment.

Operational deep dive: historical reconstruction, versioning and reproducible replay

The hardest part of a lookback is often not investigation. It is proving what data and control state existed at the time. A bank can have excellent current monitoring and still be unable to answer a historical question because customer records were overwritten, rules were not versioned, transformations changed during migrations or case decisions were retained without the evidence on which they depended. This deep dive focuses on the engineering and analytical disciplines that make retrospective review reproducible.

Build a historical evidence model before extracting data

A lookback should start with an evidence model, not a database query. The model identifies the events and states that must be reconstructed: transaction or payment event, customer and account state, product and channel, connected parties, risk rating, beneficial ownership, watchlist or reference data, rule or model version, derived features, alert output, analyst disposition and any subsequent case or reporting decision. Each element should have a source, effective date, extraction method and known limitation.

The distinction between an event and a state matters. A payment instruction is an event. A customer's risk rating is a state that applies over a period. A sanctions designation has publication and effective dates. A monitoring rule has deployment and retirement dates. If the data model stores only current states, the review may falsely attribute later information to earlier transactions. Effective-dated tables, slowly changing dimensions or immutable event histories make retrospective analysis far more reliable.

Where historical state is unavailable, reconstruction must preserve provenance. A customer address recovered from a scanned KYC document should be labelled as reconstructed from that document, not silently inserted as though it came from the customer master at the transaction date. The same principle applies to beneficial ownership, expected activity and source-of-funds information. Evidence created later can be useful, but its creation date should remain visible.

Separate source completeness from monitoring completeness

One of the most important controls in a lookback is proving the population. A bank may reconcile payment-hub records to the ledger and still miss the fact that some records never reached the monitoring platform. Conversely, the monitoring platform may have received transactions that were later filtered or excluded before scenario evaluation. A useful reconciliation therefore follows the data through stages:

  1. source business event created;
  2. event extracted for financial-crime processing;
  3. transformation and enrichment completed;
  4. record accepted by the monitoring or screening engine;
  5. applicable rule or model evaluated;
  6. alert or no-alert outcome recorded;
  7. alert, if generated, reached the case workflow.

This stage model helps identify where the historical break actually occurred. Counts alone are not always enough. A feed can deliver the correct number of records while critical fields such as counterparty country, payment purpose or customer risk segment are blank. Reconciliation should therefore test both completeness and fitness for control use.

Version configuration as evidence

Rules, thresholds, scenario parameters, model features, segmentation logic, suppression lists, exclusions and watchlist configurations are part of the evidential record. A lookback that cannot establish which configuration was active on a given date cannot make a strong statement about historical control effectiveness.

Versioning should capture more than a file name. It should preserve effective-from and effective-to dates, approval reference, implementation ticket, test evidence, parameter values and dependencies. If a vendor platform stores rule configuration internally, the bank should have an export or controlled archive sufficient to reconstruct the active state. Vendor ownership does not remove the bank's need to evidence how its control operated.

Change events also need ordering. If customer segmentation changed on the same day as a scenario threshold, the replay must know which combination applied to transactions processed before and after each effective timestamp. Batch systems may use business dates rather than wall-clock time, so the technical design should state which temporal convention governs the control.

Three replay modes, three different questions

A mature lookback labels replay outputs according to method.

Historical-state reconstruction reproduces the data and configuration that actually existed. It is used to understand what the original control saw and why it produced its original result.

Corrected historical replay uses the historical period and the control that should have operated, but repairs the identified defect. This is often the most relevant method for quantifying missed alerts from a known feed, mapping or configuration failure.

Current-control discovery replay applies today's detection logic to historical activity. It can uncover present-day risk, test typologies or identify customers that deserve review now. It should not be described as proof that the current rule was a legal or supervisory expectation in the historical period.

The three outputs can overlap, but they should not be merged into one alert population without lineage. Each hit should retain the replay method and version so investigators and governance can interpret it correctly.

Data lineage and transformation testing

Historical financial-crime data often crosses many transformations: channel format to payment hub, payment hub to data lake, data lake to feature store, feature store to monitoring engine and monitoring engine to case system. Lookbacks need enough lineage to explain how a source value became the field used by the control.

For example, a country-risk rule may use a derived counterparty_country field. The lineage should state whether this field comes from an account master, BIC mapping, postal address, card-acquirer location or payment message. If the derivation changed during the review period, the same transaction can receive a different country value depending on which transformation version is used. That is not a small technical detail; it can determine whether a scenario should have fired.

Testing should include field-level sampling from source to final control input, null-rate analysis, code-value coverage, rejected-record analysis and comparison of expected versus observed populations. Reconciliation breaks should be treated as findings requiring explanation rather than dismissed as technical noise.

Preserve reproducibility

A defensible lookback should be reproducible months later by a competent independent team. This means preserving query logic, extraction parameters, code version, data cut, hashes or other integrity controls where appropriate, configuration snapshots, population counts, exclusions, manual adjustments and the reason for every scope change. Spreadsheet work can be used for limited analysis, but critical population construction and transformations should not depend on undocumented manual manipulation.

Reproducibility also protects the bank when a review evolves. Suppose the first extraction uses a customer risk table later found to contain stale values. If the original data cut and query are preserved, the bank can rerun the population with the corrected source, quantify the difference and explain the change. Without reproducibility, every correction creates a new unexplained number and erodes confidence in the programme.

Privacy, retention and access control

Historical review does not create unlimited permission to copy sensitive data. The programme should use data minimisation, purpose limitation, access controls and retention rules appropriate to the jurisdiction and the bank's policy. Investigators may need sensitive KYC, payments and case information, but broad programme teams do not automatically need all fields. Cross-border transfers of historical data can create additional restrictions and should be designed with legal and privacy teams.

Temporary lookback datasets should have owners, approved locations and deletion or archival rules. If data is exported from production into an analytical environment, the bank should know who can access it, whether masking is appropriate, how results are returned to case systems and how the temporary copy is disposed of after the review. A remediation programme that creates a new uncontrolled data lake solves one risk by creating another.

Technical acceptance criteria

A technically complete lookback can answer the following questions with evidence: What was the source population? Can source and monitoring populations be reconciled? Which data transformations applied? Which rule, model, list and segmentation versions were active? Which exclusions operated? Can a sample be traced end to end? Can the replay be rerun from controlled code and parameters? Are data gaps quantified? Are current-state substitutions clearly identified? Are manual changes logged? Are legal-entity and jurisdiction attributes reliable enough for downstream decisions?

When those questions are answered, investigators can focus on financial-crime judgement instead of arguing about whether the underlying population is real. That is the core technical value of reconstruction discipline: it turns a retrospective exercise into evidence rather than approximation.

Advanced practice: legal decisioning, sanctions history and cross-border governance

A technically correct historical population can still produce poor outcomes if legal and governance questions are handled as afterthoughts. Advanced lookback practice separates detection from legal consequence, keeps sanctions analysis distinct from AML suspicion and coordinates multi-entity decisions without pretending that one country's rules apply everywhere.

The decision chain after a historical finding

A useful decision chain has five gates. First, is the record reliable enough to support a conclusion? Second, does the finding require investigation under the bank's risk framework? Third, does the investigation create a reporting, sanctions, law-enforcement or other legal question in a particular jurisdiction? Fourth, does the customer or product require current remediation? Fifth, does the finding reveal a control weakness that changes the programme's scope or remediation plan?

These gates prevent an alert from jumping directly to a filing or customer restriction. They also make ownership clear. Data teams establish reliable evidence; investigators assess behaviour; compliance and legal interpret reporting or sanctions obligations; customer and product owners execute approved remediation; control owners fix the root cause. The same person may perform more than one role in a small institution, but the decisions should remain conceptually separate.

Historical findings move through evidence, investigation, local legal assessment, customer remediation and control remediation rather than directly from alert to filing.

Suspicious-activity reporting is jurisdiction specific

FATF Recommendation 20 establishes the international standard that financial institutions should report promptly when they suspect, or have reasonable grounds to suspect, that funds are proceeds of criminal activity or related to terrorist financing. The actual filing trigger, form, timing and legal consequences are implemented through domestic law. A global lookback therefore needs a jurisdiction map connecting the relevant legal entity, customer or transaction to the rules that govern that entity's reporting obligation.

U.S. practice provides clear examples of formal SAR lookbacks. In December 2024, the U.S. Office of the Comptroller of the Currency required Bank of America to engage an independent consultant and conduct lookback reviews to ensure suspicious activity was appropriately reported. In October 2024, FinCEN's TD Bank action described a historical analysis of transaction data, often called a SAR lookback, to remediate missed filings created by control gaps. These examples show why retrospective review matters in U.S. supervision. They should not be rewritten as a global rule that every bank everywhere must use the U.S. SAR framework.

Other jurisdictions use different concepts and procedures. AUSTRAC's Australian framework, for example, uses suspicious matter reports and from 1 July 2026 operates updated reporting forms under Australia's reformed AML/CTF regime. A group-level remediation programme may use one technical review population while still routing reporting decisions to different legal entities and local compliance teams.

Historical sanctions analysis has two clocks

Sanctions lookbacks need two clocks: the historical clock asks what restriction applied when the transaction or relationship activity occurred; the current clock asks what restriction applies now and whether the bank currently holds assets, maintains a relationship or is considering a new transaction. Mixing the clocks leads to both over-control and under-control.

For the historical clock, reviewers need designation status, ownership or control relationships, applicable jurisdictional nexus, transaction date, asset status, service or activity, licences or exemptions and the bank's role. The fact that a name appears on a current sanctions list does not prove a transaction years earlier was prohibited. Equally, a person may have been designated during the historical period but no longer appears on the current list, so current screening alone can miss the historical legal issue.

For the current clock, the bank asks whether a present restriction affects an ongoing relationship, funds or economic resources now held, pending transactions or future service. Legal advice may be required where regimes differ on ownership, control, aggregation, sectoral restrictions or licensing. The lookback should preserve the legal analysis rather than reduce it to a generic “sanctions hit” disposition.

The EBA's guidelines on internal policies, procedures and controls for Union and national restrictive measures became applicable from 30 December 2025. They are particularly relevant to EU institutions designing governance and risk-management controls around restrictive measures. They do not replace the need to identify the actual Union or national measure applicable to a historical transaction.

Scope expansion is a governed decision

Lookbacks often change shape after work begins. A sample may show the defect existed earlier than the initial incident date. A customer network may reveal another product or legal entity used the same broken mapping. A vendor may disclose that the defect affected multiple versions of its platform. Scope expansion should be treated as an expected governance process rather than as project failure.

A well-designed programme defines expansion triggers before review begins. Examples include a material error rate above the approved tolerance, discovery of a second affected product, evidence that the defect predates the original start date, inability to reconcile the population, a sanctions true match, a reporting issue involving another legal entity or quality-assurance findings that undermine case conclusions. The steering forum should be able to expand scope quickly without waiting for a monthly meeting if risk warrants immediate action.

Scope reduction should be harder. It should require positive evidence that a population was not exposed, not simply a lower-than-expected hit rate. For example, if one payment channel used an independently validated interface that never passed through the defective enrichment layer, it may be excluded with evidence. “No suspicious cases found in the first sample” is not by itself proof that the rest of the population was unaffected.

Group-wide review and local decision rights

International banking groups often centralise data engineering and investigation while legal obligations remain local. The operating model should state which decisions can be made centrally and which require local approval. A central team can construct a cross-border transaction network or apply common investigation standards. Local compliance may still need to determine whether a report is required, how confidentiality rules apply and what regulator or FIU engagement is appropriate.

Data-sharing constraints should be designed into the review. Some customer or case information may not be freely transferable across borders. Instead of discovering this midway through the programme, architecture should identify which fields can be centralised, which require tokenisation or restricted access and which must remain in-jurisdiction. Investigators can then work from approved views without creating informal data copies.

Supervisory communication also needs coordination. If several authorities have an interest, the bank should avoid inconsistent descriptions of the same control failure. The facts, scope methodology, milestones and unresolved limitations should come from a controlled programme record, while each legal entity communicates through the appropriate regulatory channel.

Quality assurance should challenge both escalation and closure

Lookbacks create pressure to demonstrate seriousness by escalating many cases. That pressure can distort judgement. Quality assurance should therefore sample both escalations and closures, asking whether evidence supports the decision in either direction. A high escalation rate is not proof of a good review; a low escalation rate is not proof of weakness. The relevant question is whether decisions are consistent with evidence, policy and local law.

QA should also challenge temporal reasoning. Did the reviewer use the correct historical customer state? Was a later conviction improperly treated as if known earlier? Was a current sanctions designation applied to an earlier transaction without checking effective dates? Was a historical report decision assessed using the right legal entity and reporting framework? These are lookback-specific errors that ordinary case QA may not detect.

Closing a lookback

Programme closure should require more than “all cases reviewed.” The bank should have a reconciled final population; documented data limitations; completed investigations; disposition of reporting and sanctions questions; present-day customer remediation; completed root-cause actions; evidence that the corrected control works; quality-assurance results; unresolved residual risks with approved ownership; and a clear record of scope changes.

Management should also know what the lookback cannot prove. If archives were incomplete for part of the period, closure should state that limitation. If sampling was used, conclusions should stay within the inference the sample supports. If current controls were used for discovery rather than historical compliance testing, that distinction should remain visible in the final report.

A credible closure pack allows a supervisor, auditor or future control owner to reconstruct the programme without relying on institutional memory. That is the final test of advanced lookback practice: the bank can explain not only what it found, but exactly how it knows.

Practice close: BA requirements, acceptance criteria and audit evidence

A lookback is easier to control when the review is translated into explicit delivery artefacts. The following guidance is intended for business analysts, control owners, architects, engineers, testers, investigators and QA teams turning a financial-crime finding into a reproducible remediation programme.

BA scoping questions

Before requirements are approved, the team should be able to answer these questions in plain language. What exactly failed? Which control objective was affected? When could the failure have started? Which legal entities, products, channels, customers and transaction types passed through the affected path? What proves the proposed start and end dates? Which historical data states are needed? Which systems hold them? Which fields are unavailable or unreliable? What decision must each review output support? Which local compliance or legal teams own reporting and sanctions conclusions? What facts would require scope expansion?

The BA should convert these questions into traceable requirements rather than a single requirement such as “rerun historical transactions.” A good requirement might state that the population must include every settled and rejected payment carrying source code APX2 between two approved timestamps and must reconcile by count and amount to the payment hub, with exclusions documented and approved. Another might require the replay output to retain transaction ID, source-system ID, customer ID, legal entity, historical scenario version, replay method and reason code.

Functional acceptance criteria

Population acceptance criteria should prove completeness, deduplication and boundary handling. Historical customer-state criteria should prove that ownership, risk rating and expected activity are effective-dated. Replay criteria should identify the exact rule, model or list version and distinguish corrected historical replay from current-control discovery. Case-integration criteria should ensure investigators can trace a hit back to source evidence and understand why it entered the lookback.

Decision criteria should keep investigation, reporting, sanctions and customer-remediation outcomes separate. The case workflow should not force a report merely because an investigator escalates risk. Where legal review is required, the system should record jurisdiction, legal entity, decision owner, decision date and rationale without exposing confidential reporting information more widely than permitted.

Closure criteria should require a reconciled final population, disposition of all cases or approved residuals, completed quality assurance, documented data limitations, resolved scope changes, customer remediation, root-cause actions and evidence that the live control works after remediation.

Technical and data tests

Positive tests should include known transactions that the corrected control is expected to identify. Negative tests should include legitimate activity that should remain unalerted or should close with clear evidence. Boundary tests should cover transactions immediately before, at and after the scope start and end timestamps. Version tests should prove that transactions on different dates receive the correct historical rule or list version.

Lineage tests should trace selected records from source through extraction, enrichment, monitoring and case output. Null and code-value tests should identify fields that became incomplete during migration or transformation. Reconciliation tests should compare expected and observed populations at each material stage, not only at the file-transfer boundary.

Failure-mode tests should simulate unavailable archives, duplicate source events, partial replay jobs, changed customer identifiers, missing list versions, late-arriving payment records and corrected queries. The programme should define whether a failed batch is rolled back, resumed or rerun, and how duplicate case creation is prevented.

Investigation and QA checks

QA should sample both escalated and closed cases. The reviewer should confirm that the historical customer state was used where relevant, subsequent information was dated correctly, contradictory evidence was addressed and the outcome follows policy. For sanctions-related cases, QA should challenge identity, ownership or control, legal nexus, effective date and licence or exemption reasoning. For AML cases, QA should distinguish unusual activity from suspicion and ensure any reporting question is routed under the correct local framework.

A useful QA defect taxonomy includes wrong population, wrong historical state, wrong control version, unsupported closure, unsupported escalation, missing evidence, wrong jurisdiction, chronology error, duplicate case, reporting-decision error and customer-remediation omission. Tracking these defects helps determine whether the lookback process itself is reliable enough to support closure.

RACI and evidence ownership

Senior management owns the risk and approves material scope. Financial-crime compliance owns the control interpretation and investigation framework. Legal advises on jurisdiction-specific obligations where required. Data and technology own population construction, lineage and replay. Operations and investigators execute reviews. Business or relationship teams support customer remediation without influencing confidential reporting decisions. QA provides independent challenge within the programme, while internal audit remains independent of operational ownership where it later provides assurance.

The evidence pack should identify who owns each dataset, query, control configuration, case population, legal decision, remediation action and closure artefact. Ownership prevents the common end-of-programme problem where everyone contributed to the review but nobody can reproduce the final numbers.

Definition of done

A lookback is not done because a project plan reaches 100 percent. It is done when the bank can reproduce the population, explain the historical control state, show how every material outcome was reached, demonstrate that local legal and reporting questions were handled by the right owners, evidence current customer remediation and prove the control weakness has been corrected effectively. Anything less is activity completion, not risk closure.

Masterclass: the payments feed that looked healthy

This fictional composite case brings the chapter together. It does not describe a real bank or enforcement action. The facts are deliberately ordinary because the most dangerous control failures are often not dramatic system outages; they are plausible production states in which payments continue, customers are unaffected and management information remains green while a control receives incomplete data.

The discovery

A regional bank launches a new corporate API channel. Payments flow through the same payment hub as online banking and host-to-host files, and the project team confirms that sanctions screening is invoked in the payment path. Transaction monitoring is downstream: payment events are exported nightly into a financial-crime data platform, enriched with customer and product attributes and then evaluated by several scenarios.

Nine months after launch, a data analyst investigating an unrelated alert notices that API payments appear underrepresented in the monitoring warehouse. The payment hub shows materially more API activity than the monitoring platform. There has been no outage alert, no customer complaint and no monitoring incident. The issue is escalated as a possible completeness defect.

The bank does not start by searching for suspicious customers. It first reconstructs the control failure. The API launch introduced a new source code. The extract job accepted the records, but the enrichment layer mapped the code to an unsupported category. Those records were written to a reject table that was retained for thirty days and then purged. The monitoring dashboard counted successfully completed nightly files, not transaction records surviving enrichment. The interface therefore appeared operational even though a population was silently lost.

Scoping the review

The bank identifies the first production date of the new source code and the date on which the corrected mapping became effective. Release tickets show one short pilot period before the formal launch, so the scope starts from the pilot rather than the public launch date. Data engineering obtains API transaction counts from the payment hub and reconciles them to ledger postings. This establishes a population independent of the defective monitoring feed.

The steering group initially considers reviewing only high-risk customers. Compliance challenges that approach because the defect affected the channel, not the customer-risk segment. The final design reconstructs the entire affected API population, then uses risk-based prioritisation for case review. High-risk geographies, unusual counterparties, rapid value movement and customers with other open alerts receive earlier attention, but lower-risk customers remain in the population.

Sanctions screening is assessed separately. Payment-path logs confirm that the real-time sanctions service received the API messages throughout the period, and sample tracing verifies the relevant fields. The lookback therefore does not label the issue a sanctions-screening outage. However, because some API payments contain richer ultimate-party information than the monitoring extract retained, sanctions specialists verify that the real-time service screened those fields as designed. The review records the evidence instead of assuming one control failure affected every financial-crime control.

Reconstructing historical truth

The bank discovers that current customer profiles cannot simply be joined to old payments. Several corporate customers changed ownership during the nine months, two were re-rated after adverse-media events and one migrated between relationship-management systems. The data team builds effective-dated customer snapshots from archived KYC records and change logs. Where a historical field cannot be reconstructed, the limitation is recorded rather than filled with current data.

Scenario configuration is also versioned. One monitoring scenario changed its threshold during the review period after a scheduled tuning exercise. The corrected historical replay therefore uses the appropriate scenario version for each transaction date. A separate current-control run is performed to identify present risk, but its alerts carry a distinct label so they are not mistaken for historical missed alerts.

Investigation outcomes

The corrected replay produces a manageable set of cases. Many are resolved because the activity matches documented corporate business and counterparties. A smaller group requires deeper review. One customer receives large incoming payments and sends most of the value onward within hours through the API channel. The pattern was already present in host-to-host activity and had generated an alert there, but investigators had closed it after reviewing only the host-to-host transactions. The API lookback reveals the full flow and shows why cross-channel visibility matters.

Another case involves a customer whose activity looks unusual only when viewed against the historical expected profile. Current KYC says the customer operates internationally, but at the transaction date the stated business was domestic. Investigators establish that the business expanded legitimately and the customer had informed the relationship manager, but the KYC profile was not updated promptly. The outcome is not suspicion; it is a customer-data and event-driven-review weakness requiring remediation.

A third case contains unexplained payments through several newly formed counterparties. The customer is still active. Investigators obtain additional information, connect the counterparties through common ownership and escalate the case. Compliance then assesses any reporting obligation under the law applying to the bank's legal entity. The lookback team does not declare that a report is automatically required simply because the alert was historical.

The control finding becomes broader than the cases

Case results matter, but the most important finding is architectural. The bank's monitoring completeness control proves only that a file arrived, not that expected records survived every transformation stage. The same pattern could recur with another product code. The remediation therefore adds source-to-target record reconciliation, rejected-record monitoring, product-code coverage checks and release acceptance criteria requiring every new code to demonstrate a valid monitoring path before production approval.

The bank also changes investigation tooling. Cases now show channel-level activity in one timeline rather than requiring analysts to open separate views. The original host-to-host alert had been closed partly because the investigator could not see the API leg. This is a reminder that lookbacks can identify failures in decision support even when rule logic is sound.

Closure

The final closure pack contains the trigger chronology, scope rationale, reconciled population, data limitations, replay methodology, scenario versions, investigation outcomes, local reporting decisions, current customer remediation, quality-assurance results, root-cause analysis and evidence that the new reconciliation controls work across several production cycles. Residual issues are assigned to owners with dates and risk acceptance where necessary.

The lesson is not “every missing feed creates suspicious activity.” The lesson is that a bank must know whether the control saw the population it was supposed to see. A credible lookback reconstructs that truth, separates historical compliance from present risk, follows evidence into cases without forcing outcomes and leaves the live control measurably stronger than before the defect was discovered.

Knowledge check and glossary

Use these questions to test whether the distinctions in the chapter are clear enough to apply in a real bank.

What is a lookback review?

A controlled retrospective review triggered by a material new fact, control weakness or external requirement. It reconstructs historical activity and control state so the bank can assess missed risk, legal or reporting consequences, customer remediation and control fixes. It is not one globally standardised statutory procedure.

Why is simply replaying old transactions through today's monitoring engine insufficient?

Because today's logic may not represent the control or legal context that applied historically. Current-control replay is useful for present-risk discovery, but historical reconstruction and corrected historical replay answer different questions. The method must be labelled so governance does not mistake today's detection standard for proof of an old breach.

What is frozen-time truth?

The customer, ownership, risk, transaction, configuration and legal state relevant at the historical date. A good lookback distinguishes that state from information learned later.

What is the difference between knowledge date and effective date?

Knowledge date records when the bank learned a fact. Effective date records when the underlying status applied. A beneficial-owner relationship may have existed historically even if the bank discovered it later. A sanctions designation, by contrast, should not be treated as effective before the relevant legal measure took effect unless the law itself provides otherwise.

Does every historical alert require a SAR or STR?

No. Reporting duties depend on the law and rules applicable to the relevant legal entity and facts. Historical activity may create a reporting question that must be assessed, but an alert is not automatically a filing decision.

Does a current sanctions match prove an old transaction was prohibited?

No. Historical sanctions analysis requires the measure and designation status at the transaction date, applicable jurisdictional nexus, ownership or control, activity, licences or exemptions and the bank's role. Present restrictions are a separate current-state question.

When is sampling inappropriate?

When the objective requires complete identification of a population, for example testing whether transactions with a specific designated party occurred. Sampling can be useful for control-effectiveness or error-rate questions if the methodology supports the inference being made.

What should cause scope expansion?

Evidence that the defect started earlier, affected more products or entities, produced material findings outside the initial hypothesis, cannot be reconciled reliably or creates related control questions. Scope expansion should be governed but expected where evidence requires it.

What closes a lookback?

A reconciled population, completed investigations, disposition of local legal and reporting questions, current customer remediation, documented limitations, QA, root-cause remediation and evidence that the live control is now effective.

Glossary

Affected population: the customers, accounts, transactions, parties or events exposed to the identified control weakness.

Backtesting: applying a control, rule or model to historical data to assess performance or identify activity that would have produced an outcome.

Corrected historical replay: rerunning historical activity using the control that should have operated during the period after repairing the identified defect.

Current-control discovery replay: applying today's logic to old activity to identify present risk, without implying the same logic was historically required.

Effective dating: recording when a customer state, rule, list, ownership relationship or other attribute became and ceased to be applicable.

Frozen-time truth: a reconstructed view of the facts and control state at a specific historical point.

Historical reconstruction: rebuilding the data, configuration, customer state and decision environment that existed when the original activity occurred.

Knowledge date: the date on which the bank received or could establish a fact, distinct from when the underlying fact legally or economically applied.

Lookback trigger: the event or finding that creates a reason to assess historical exposure, such as a data gap, control defect, supervisory finding or newly identified network.

Population reconciliation: evidence that the review population matches the events expected from authoritative sources, with differences explained.

Provenance: the source and history of a data element or conclusion, including how it was obtained or reconstructed.

Replay method: the declared approach used to evaluate historical data, such as historical-state reconstruction, corrected historical replay or current-control discovery.

Scope expansion: a governed increase in period, population, products, entities or review questions because evidence shows the original scope is insufficient.

Source-to-target lineage: the traceable path by which source data is transformed into the fields consumed by a financial-crime control.

References and further reading

The sources below support the control, records, suspicious-activity reporting, testing, restrictive-measures and remediation concepts used in this chapter. Jurisdiction-specific sources are labelled as such; they should not be treated as universal legal rules.

Global standards and banking supervision

United States examples: transaction testing, SAR controls and formal lookbacks

European Union restrictive-measures control governance

Australia: current suspicious-matter reporting framework

UK systems-and-controls context

How to use these sources

FATF and Basel provide international standards and supervisory principles, not identical legal filing rules for every country. FFIEC, OCC and FinCEN sources illustrate U.S. examination, SAR and enforcement practice. AUSTRAC sources describe the Australian regime. EBA material addresses EU restrictive-measures control governance. For a real lookback, teams must identify the law, supervisor, FIU, sanctions authority and legal entity that apply to the specific facts and review date.