A look-back review is a backward look at historical activity over a set period, usually required after a control gap, missed filings, or a regulator finding. The goal is to find and fix the suspicious activity that went undetected the first time, and it often ends in a batch of late SARs.
What is a look-back review, in plain English?
When a program discovers that something was broken, a rule that was misconfigured, a scenario that never ran, alerts that were never worked, the obvious next question is: what did we miss while it was broken? A look-back review answers that. It is a retrospective sweep of historical activity over a defined period, re-examining the past to catch the suspicious behavior that slipped through when the control was failing.
Look-backs are usually not optional. They are triggered by a failure: a control gap found internally, a stretch of missed filings, or a specific regulator finding that says go back and check. The scope, the period, and the method are defined up front, because the whole exercise is about being able to show you cleaned up the mess thoroughly.
Because it re-reviews activity that was never properly assessed, a look-back commonly ends in a batch of late SARs, filed now for activity that should have been reported earlier. That is expected; the point is to close the gap, not to pretend it never existed.
How a look-back is run
- Trigger — A gap is identified. An internal discovery, missed filings, or a regulator finding sets off the requirement to look back.
- Scope — Define period and population. The timeframe, affected customers, and transaction types are documented, since scoping drives everything after.
- Resource — Staff and sometimes outsource. The review is staffed, often heavily, and sometimes requires independent parties to run or validate it.
- Review — Re-examine the history. Historical activity is reworked to find suspicious behavior the failed control let pass.
- File — Report and document. Late SARs are filed as needed, and the scope, method, and results are preserved as scrutinized deliverables.
What it looks like in practice
In practice
During validation, a bank discovers that a wire-monitoring scenario silently stopped generating alerts eighteen months ago after a data feed changed and nobody noticed. Every cross-border wire in that window went unmonitored. A look-back is required.
The team documents the scope: all affected wires over eighteen months, across the impacted customer segments. They bring in extra reviewers and an independent party to validate the method, then rework the history. Several layering patterns surface that were never reported, producing a batch of late SARs. The scope memo, the method, and the results are all retained, because they know this file will be examined closely and weak scoping would get the whole effort rejected.
Why it matters to operators
Look-backs are resource-heavy and high-stakes. They can absorb large teams for months, sometimes require independent third parties, and always land under close regulatory scrutiny because they exist to prove a failure was remediated. Treating the scope, method, and results as formal deliverables, not internal notes, is essential; these are exactly the things an examiner will pull apart.
The fastest way to fail is weak scoping. If the period is too short, the customer population too narrow, or the method poorly justified, a regulator can reject the entire review and demand it be redone, at even greater cost. Clean documentation and a clean audit trail throughout are what make a look-back defensible and, ideally, a one-time event rather than a repeated one.
Operator notes
- Scope is everything. Under-scoping the period or population is the most common reason a look-back gets rejected and redone.
- Expect late SARs. Finding unreported activity is the point; filing the resulting late SARs is a feature, not a failure.
- Consider independence. Regulators often expect independent parties to run or validate the review, especially after a serious finding.
- Document as a deliverable. Scope, method, and results will be scrutinized; treat them as formal, defensible work product.
- Keep a clean audit trail. The credibility of the whole exercise rests on being able to show exactly what was reviewed and how.
Quick questions
What triggers a look-back review?
A discovered control gap, a period of missed filings, or a specific regulator finding. Anything that means suspicious activity may have gone undetected for a stretch of time can require going back to re-examine it.
Why do look-backs produce late SARs?
Because they re-review activity that was never properly assessed the first time. When suspicious behavior surfaces in that history, it has to be reported now, resulting in filings that are late relative to when the activity occurred. That is an accepted outcome of the exercise.
How is scope decided?
By the nature of the failure: which period it covered, which customers and transaction types were affected, and how far back the risk plausibly extends. The scope must be documented and defensible, because under-scoping is the top reason reviews get rejected.
Do look-backs need independent reviewers?
Often, yes. Regulators frequently expect an independent party to conduct or validate the review, particularly when it follows a significant finding, to give the result credibility.
How is a look-back different from routine monitoring?
Routine monitoring reviews activity as it happens or shortly after. A look-back reaches back over a defined historical window to catch what a broken control missed. It is remedial and time-bound rather than ongoing.
Go deeper
- FinCEN ↗ — The US financial intelligence unit. Bank Secrecy Act rules, advisories, and SAR and CTR guidance.
- FFIEC BSA/AML Examination Manual ↗ — The manual US examiners use to assess BSA and AML programs.