What an AML lookback review involves, why it costs so much, and which phases an AI employee speeds up while people keep scoping and SAR decisions.
A lookback is the part of a BSA/AML remediation that most compliance teams dread. It means re-reading months or years of past activity, usually under regulator scrutiny and a fixed deadline. This guide explains what a lookback is, how the phases run, why the work is so expensive, and where an AI employee changes the economics without taking decisions away from your BSA officer.
The goal is specific. The review decides whether suspicious activity reports (SARs) should be filed for activity that was missed, and whether earlier filings need correction. It also feeds a broader fix of the monitoring program, which is why a lookback rarely arrives alone.
Two situations trigger most lookbacks. The first is a formal enforcement action. The second is an internal discovery, such as finding that a monitoring scenario was misconfigured, a data feed was dropped, or a product line was never covered by transaction monitoring. In the second case a bank may run a lookback on its own, often before an examiner asks.
A public example shows what regulators write into these orders. In its 2024 consent order with TD Bank, N.A. and TD Bank USA, N.A. (AA-ENF-2024-77), the OCC included an article titled "Suspicious Activity Review Look-Back." It requires the bank to propose an independent, third-party consultant for the OCC's written no-objection. The consultant reviews suspicious activity monitoring, investigation, decisioning and reporting. The order says the purpose is to determine whether SARs should be filed for previously unreported activity, to check the quality and accuracy of earlier SAR filings against 12 C.F.R. § 21.11, and to identify transactions that represent excessive BSA/AML risk. It also states that the OCC's Examiner-in-Charge sets the scope in writing. You can read the full text in the OCC's published order.
Two details from that article matter for planning. The consultant must give the board a written report that lists the methods used, how many customers, accounts and transactions were reviewed, and the SARs recommended for filing or amendment. And the scope is not the bank's call alone. Orders differ, so read the exact article in yours.
Most lookbacks follow the same six phases, whatever the bank size.
The cost comes from volume, time pressure and proof requirements arriving together.
Re-running detection logic over two or three years of history can generate far more alerts than a normal monitoring queue handles in a month, and the false positive rates that burden day-to-day monitoring apply here too. Each alert still needs a documented conclusion. Banks often staff the surge with temporary analysts and outside consultants, so the bill grows with every extra week.
Data work is the second driver. Historical data lives in core systems that have been migrated, merged or retired. Fields changed meaning over time. Missing records have to be found before anyone can claim the review is complete, and a regulator will ask how you know it is.
Consistency is the third. When dozens of analysts work the same population over many months, two reviewers can reach different dispositions on near-identical facts. Quality control then re-reviews a sample, and every disagreement costs time.
The last driver is the audit trail. The final report must show how every alert was handled. Reconstructing that from emails and spreadsheets after the fact is slow.
An AI employee works well on the phases that are high volume, rule-bound and evidence-heavy. These are data validation, alert review and evidence assembly. Each step still passes through approval gates, and every action is logged. The table shows how the work splits.
Phase | What the AI employee does | What stays with people |
|---|---|---|
Scoping | Profiles the data to show what is available per period and product, so scope decisions rest on facts | Choosing the period, populations and scenarios; agreeing scope with the regulator |
Data extraction and validation | Reconciles record counts and totals against source systems, flags gaps, duplicates and field changes | Deciding how to treat gaps and signing off data completeness |
Alert generation | Runs the approved logic in a controlled way and keeps run parameters on record | Approving the detection logic and thresholds |
Investigation | Gathers customer profile, account history and counterparty context, drafts a disposition with reasons | Reviewing dispositions, handling complex or novel cases |
SAR decisions | Assembles the evidence pack and a draft narrative for cases an analyst escalates | The decision to file, amend or close, and the filing itself |
Regulator reporting | Compiles volumes, dispositions and audit trail into report tables | Writing conclusions, answering the regulator, owning the submission |
Validation is repetitive and mechanical, which makes it a good fit. An AI employee can compare counts and balances between the extract and the source, check that required fields are populated across the whole period, and list the exceptions for a person to resolve. Faster validation means the investigation phase starts sooner, and that is where most of the calendar time sits.
For each alert, the AI employee collects the facts an analyst would otherwise gather by hand: customer risk rating, expected activity, prior alerts and SARs, counterparties and the transaction pattern. It applies the bank's own investigation procedure and writes a proposed disposition with the reasoning attached. An analyst reviews the proposal rather than starting from a blank page. Our post on AI agents for financial crime investigations covers how this works for live alerts, and the same pattern applies to a historical population.
Because the same procedure and the same checklist run on every alert, near-identical facts get near-identical treatment. That cuts the disagreements that quality control would otherwise find months later. Each disposition carries its evidence: the records consulted, the rule applied and the time of the review. The audit trail is produced as the work happens, so the regulator report draws from it instead of reconstructing it.
Three things stay with people, and a regulator would expect that.
Scoping decisions.
The period, populations and scenarios in scope are risk judgments, and under an enforcement action the regulator may set them. An AI employee can show what the data supports. It does not decide the scope.
SAR filing decisions.
The BSA officer owns the decision to file, amend or close, and the narrative a person signs off must reflect their own reading of the case. The SAR rule in 12 C.F.R. § 21.11 (and FinCEN's rule at 31 C.F.R. § 1020.320 for banks) places the obligation on the institution, and the SAR glossary entry explains the filing basics. An AI employee prepares the evidence pack and a draft. A person decides.
Regulator communication.
Meetings, written responses and negotiation over timelines are human work. So is the judgment about what the findings mean for the wider program.
The consultant's independence is another reason to keep these decisions human. If an order requires an independent consultant, the AI employee supports that team rather than replacing the accountability the order assigns.
A lookback runs for months with many hands on it, so the main risk is that the method moves while the work is in flight. An AI employee's AOP is versioned, which gives you a fixed method to cite. Every disposition records which AOP version produced it, so you can reproduce any alert's treatment on request.
A record that cannot be found in any source, a field whose meaning changed between migrations, a customer with a prior SAR, or a pattern the procedure has no precedent for. The case goes to Needs Attention with the data gap named, instead of a guessed disposition.
The validate step of the PEV loop confirms every statement cites a record in the evidence pack, the checklist is complete, and the case count reconciles: alerts generated equals alerts dispositioned plus alerts escalated. Reasoning is written to the team's own case-management system, where the regulator report will draw from it.
Mid-project changes follow the same path as any correction. A reviewer's override becomes a branch, runs against a golden set that includes closed alerts QC already agreed on, gets reviewed, and merges. Quality control then compares versions, not impressions.
On cost, the biopharma procurement deployment is the useful reference. Cost per request fell 90%, from $11.57 to $1.21, while weekly volume grew from 205 to 2,712, mostly by splitting rules into smaller deterministic steps. Historical data from retired cores is exactly the kind of data a bank keeps in its own environment, so BYOC or on-premises is the usual fit, per our deployment models.
Preparation shortens the project more than any tool. Five steps are worth doing first.
If your monitoring program is also being rebuilt, link the lookback logic to the new scenarios so you do not run two different definitions of "suspicious." For the wider picture, see how AML automation works end to end, and how an AI compliance analyst fits into a compliance team.
Ask how dispositions are reviewed and by whom, whether every action is logged with a timestamp, and whether the logic can be reproduced on request. Ask where data is processed and how access is controlled. Ask whether the regulator has seen the approach, since some examiners will want to understand how automation was used before accepting results. Compliance teams that already screen payments will recognize this level of scrutiny from payment screening, where speed has to be balanced against control.
