A SAR lookback is a review of a defined past period of transactions and customer activity to find suspicious activity that a bank should have reported and did not, and to file the SARs that were missed. Regulators order them when they find monitoring failures: the OCC's 2024 order against Blue Ridge Bank required a lookback over September 2022 to August 2023 that included high-risk activity through its fintech partners, and the Federal Reserve's 2024 order against Evolve Bank & Trust required a review of partner wire activity from April to September 2023. At a fintech partner, a lookback means re-testing what the partner's analysts and systems already closed, alerts dismissed, onboarding exceptions cleared, activity never referred, against the bank's own data. Botminds' BaaS Compliance runs that re-test as routine: each quarter its agents re-perform a risk-based sample of each partner's end-customer files and, when failures share a cause, test the partner's whole population.
The worked example is a fictional sample bank, Tessaly Community Bank, and one of its 11 partner programs, Fernquill Pay. Every figure from it is sample data; the rules and orders are quoted from the regulators.
Two BaaS lookbacks: the period reviewed, and how long before the order it ended
- Lookback period, Sept 2022 to Aug 202312 months
- To the order5 months
- Partner wire review, Apr to Sept 20236 months
- To the order8 months
What is a SAR lookback?
A SAR lookback is a backward-looking investigation with one purpose. In the Blue Ridge order's words, it is "to determine whether SARs should be filed for any previously unreported suspicious activity" (AA-ENF-2023-68, Article XI). It is not an audit of policies; it is a re-review of the activity itself, usually by a qualified party independent of the people whose work is being re-checked, ending in late SARs where they are due.
Lookbacks get ordered because a monitoring failure is invisible until someone re-runs it. FinCEN's October 2026 consent order against Bank of America describes the scale a lookback can reveal: "In 2024, Bank of America conducted a one-time lookback for potential missed suspicious activity under these revised parameters ... and found that under the revised thresholds, the Bank had failed to identify and file nearly 8,900 SARs, with transaction activity totaling nearly $4 billion" (FinCEN Consent Order 2026-03). That was a bank's own monitoring, not a partner's. A sponsor bank's version is harder, because the activity sits in a partner's systems and the closed alerts were closed by people the bank does not employ.
What a lookback report must contain
The orders are specific about what a lookback must report, and the list doubles as a design for any partner re-test. Blue Ridge had to report "the methodologies and tools used," "the process for investigating customers and customer activities," "the number and types of customers and accounts reviewed," "the number of customers that warranted SAR filings or modifications to existing SAR filings," and "the number of customers where the Bank determined not to file a SAR." Evolve's engagement letter had to detail "the methodology for conducting the Transaction Review, including any sampling procedures to be followed" (Evolve order, paragraph 17).
What a SAR lookback at a fintech partner should be able to report
- The period and the population
Which partner, which accounts and sub-accounts, which activity types (cash, ACH, wires, card), and which months.
- The method and the tools
How the sample was drawn and why, which scenarios or rules were re-run, which data the bank used instead of the partner's.
- How customers were investigated
The steps from a re-opened alert to a decision, and who made each decision.
- Customers and accounts reviewed
Counts by type and risk, so the coverage can be judged.
- What warranted a SAR
New SARs and amendments to existing ones, filed on the bank's obligation.
- What did not
The number of customers where the bank decided not to file, as the Blue Ridge order required.
- What the partner must fix
The causes found, as remediation items with owners, dates and the test that closes each.
Who does transaction monitoring in a BaaS program?
In a BaaS program, transaction monitoring is often run by the fintech or its middleware platform on the end-customer data, while the bank monitors its own FBO accounts and remains responsible for both. The 2024 request for information lists "monitoring transactions" among the key functions a fintech or intermediate platform provider may perform, and warns that payment growth brings more alerts with it (89 FR 61577).
The OCC's order shows what the bank's own monitoring had to reach. Blue Ridge needed procedures to measure the activity through each partner's accounts and sub-accounts, and "a review for suspicious activity of cash transactions, Automated Clearing House (ACH), and wire activity conducted through the Bank," followed by independent validation of its monitoring system once enhanced for partner activity (AA-ENF-2023-68, Article X). Whoever runs the scenarios, the bank needs the per-customer activity to test them. The fintech AML analyst guide covers who does which part of the work.
How do you test a fintech's AML program? Re-perform what it closed
You test a fintech's AML program by taking decisions it already made and making them again with the bank's own sources, then comparing. A questionnaire tests what the partner says it does; re-performance tests what it did. The method has four steps, and each produces evidence an examiner can follow.
Re-performing a fintech partner's closed work: what to take, and what the bank re-checks
| What the partner closed | What the bank takes from the partner | What the bank re-checks with its own sources |
|---|---|---|
| Onboarding decisions | The identity data, the identity vendor's raw response and the open decision for each sampled account | Name, date of birth, address and ID number with the bank's identity service; OFAC as of the opening date; purpose, expected activity and risk rating |
| Dismissed alerts | The alert, the activity behind it, and the analyst's written rationale | Whether the rationale fits the activity and the customer profile, and whether the bank would have referred it |
| Activity never alerted | Per-customer transactions for the period | The bank's own rules or scenarios run over the same data, for patterns the partner's scenarios did not catch |
| Referrals made | Each referral with its detection and send dates | Completeness and timeliness against the agreement, and whether the bank's investigators reached a decision on time |
Each disagreement needs a classification, and three are enough: the bank agrees with the partner; the bank disagrees, and the file fails a named test; or the evidence the partner relied on is missing, which is a failure of a different kind. The distinction matters for remediation. A wrong decision points at the analyst or the rule; missing evidence points at the partner's system.
What sample size for an AML lookback?
No rule sets a sample size for a lookback or for testing a partner; the size should follow risk, and the method must be written down. The Blue Ridge order made that explicit for audit testing: the bank's workpapers had to set out what was tested, how large the sample was, how it was drawn and what counted as a pass (AA-ENF-2023-68, Article VII; the guide to BaaS enforcement actions reads the order article by article). The OCC's community bank procedures say the same about examiners: the size and make-up of a test sample should match the bank's risk profile (OCC Bulletin 2025-37 attachment).
Arithmetic can still say what a sample proves. If a random sample finds no failures, the smallest sample that shows, with a chosen confidence, that the true failure rate is below a chosen tolerance is n = ln(1 − confidence) ÷ ln(1 − tolerance). The table works it through.
How many files a zero-failure sample needs to support a conclusion
| Confidence | Failure rate you want to rule out | Files needed, none failing |
|---|---|---|
| 90% | Above 5% | 45 |
| 95% | Above 10% | 29 |
| 95% | Above 5% | 59 |
| 99% | Above 5% | 90 |
| 95% | Above 2% | 149 |
| 95% | Above 1% | 299 |
The table explains a common choice. Sixty files with no failures supports, at 95% confidence, a failure rate below 5%; that is why 60 per program per quarter is a defensible default, and why the sample bank's BSA Officer set it as the minimum. It also shows the limit of sampling: once a sample finds failures, more sampling is the slow way to learn how big the problem is. The faster way is the next section's. The neighbouring guide on validating AI that tests fintech partners discusses sampling risk for lending programs.
Does a lookback have to record why a SAR was not filed?
No, not as a general rule. The interagency SAR FAQs of October 9, 2025 say nothing in the BSA or its regulations requires, or leads examiners to expect, a written record of a decision not to file, while noting that FinCEN has "encouraged, but not required" one and that a short statement will usually be enough (SAR FAQs, October 2025).
A lookback is the exception in practice. The Blue Ridge order required that bank to write down each decision whether to file and the key facts behind every decision not to, and its lookback report had to count the customers where it decided not to file. A sponsor bank re-testing a partner should do the same for the decisions it re-makes, because the count of no-file decisions is how a reviewer judges whether the re-test was real. That record stays with the bank's investigators; the partner never sees it.
A worked replay: one partner's quarter
Take the sample bank's fourth-quarter test of Fernquill Pay, a consumer wallet and debit card program with 41,820 end customers. The sampling planner drew 60 files in three strata: 20 high-risk applicants, 25 accounts opened in the quarter and 15 across the book. The CIP and CDD re-performer re-ran seven tests on each with the bank's identity service and OFAC list history as of each opening date: name, date of birth, address, Social Security number, OFAC screening, purpose and expected activity, and risk rating. Fernquill had reported a pass on every test of every file.
Fernquill Pay's quarter, re-performed: failures by stratum
The strata did their job. Three of the four failures were accounts opened in the quarter, which pointed at something that had changed recently. The file-level evidence named it: Fernquill's identity response for file 24 showed the date-of-birth check "queued after a timeout" at 2:22 PM on October 6 and never run, while Fernquill's system recorded the file as passed. The high-risk failure was different in kind. The Social Security number ending 2290 was linked to a different date of birth in two sources, a sign of a possible synthetic identity, so the re-performer referred it to the bank's investigators as IR-2026-118 and the partner was not told.
A file that does not verify goes to the bank's investigators, not to the partner
From sample to population: when failures share a cause
When failures share a cause, the right next step is to test every account the cause could have touched, not to draw a bigger sample. In the sample bank, three of the four failures traced to Fernquill release 4.18, shipped September 30, which let onboarding continue when the identity service timed out. The bank's rule, a setting the BSA Officer approves, is that two failures with one cause trigger a population test. The re-performer queried Fernquill's onboarding file for every account opened from October 1 to 26: 212 of 3,412 had the same gap, 31 of them rated high risk, holding $184,377.20.
BaaS Compliance tests the whole population: 212 of 3,412 accounts with the same gap
The population result turned a finding into a fix. Remediation item R-031-1 required the partner to make the date-of-birth check mandatory and fail closed on a timeout, closing only when the agents re-perform 20 files opened after the fix. Item R-031-2 required verification of the 212 accounts, or limits on them until verified, closing only when the population test re-runs with 0 of 212 unverified. Neither closes on the partner's letter. Piloting this method on one partner's last quarter shows how a bank can try it before changing anything.
How do sponsor banks audit fintech partners?
Sponsor banks audit fintech partners through their own independent testing, which should reach partner activity, plus the bank's ongoing monitoring of each partner. The FFIEC manual says no regulation fixes how often independent testing happens, offers every 12 to 18 months as an example, and asks for testing when the bank's risk profile, systems, compliance staff or processes change significantly (FFIEC manual, independent testing). The OCC's 2025 community bank procedures list what testing should evaluate, including "the identification or alert process ... the management of alerts, research, SAR decision making, SAR completion and filing" (OCC Bulletin 2025-37 attachment).
The FFIEC manual also explains why sampling decides how a finding is read. Whether violations are systemic depends partly on "whether the number of violations is high when compared to the bank's total activity," which "usually is determined through a sampling of transactions or records" (FFIEC manual, developing conclusions). A bank that already samples each partner every quarter, and tests the population when causes repeat, knows its own answer to that question before the examiner asks it.
Questions people ask
How far back does a SAR lookback go?
As far as the order or the bank's own scope says; there is no standard period. The Blue Ridge order covered twelve months (September 2022 to August 2023) and the Evolve order six months of partner wire activity (April to September 2023), and both let the regulator extend the period after seeing results.
Who performs a SAR lookback?
Usually a qualified party independent of the people whose work is being reviewed, often an outside firm the regulator must accept. The Evolve order required an "independent third party acceptable to the Supervisors" and approval of its engagement letter, including the sampling procedures.
What happens if a lookback finds missed SARs?
The bank files them on its own obligation, under the normal SAR rule, and reports the counts to its board and regulator. The Evolve order required that throughout the review "all matters or transactions required to be reported that have not previously been reported are reported." The causes then become remediation.
Can a sponsor bank run a lookback on a partner without an order?
Yes. Nothing restricts a bank from re-reviewing activity in its own accounts, and the 2023 interagency guidance allows a bank, where risk warrants, to test a third party's own controls directly. Running a smaller version every quarter, as a re-performed sample, is cheaper than a large one after an examination.
Does a lookback count as the bank's independent test?
Not on its own. Independent testing evaluates the whole BSA/AML program; a lookback re-examines activity for a period. A lookback's method and results are strong evidence for the independent tester, and the BaaS Compliance examiner pack keeps each quarter's re-test, cited, for that purpose.