The questions US bank examiners are likely to ask about AI in a BSA/AML program, mapped to FinCEN rules, 2018 joint statement, SR 26-2 & OCC 2023-17.
This post is organized as the question list a BSA officer should be able to answer in an exam. It is not an official examination checklist. Each question is drawn from a published rule or regulator statement, linked in the sources at the end, and we say plainly where a statement does not cover AI.
Three published documents set the tone, and one of them changed this year.
The first is the 2018 joint statement from the Federal Reserve, FDIC, FinCEN, NCUA and OCC. It encourages banks to consider and responsibly implement innovative approaches to BSA/AML compliance, and names artificial intelligence among the technologies banks are experimenting with. It says pilot programs should not by themselves subject a bank to supervisory criticism, even if they prove unsuccessful, and that innovation will not result in additional regulatory expectations. It also tells management to weigh information security and third-party risk management, and to discuss evaluations with its regulators.
The second is a change in model guidance. On April 17, 2026 the Federal Reserve issued SR 26-2 and the OCC issued Bulletin 2026-13, revised model risk management guidance. SR 26-2 supersedes SR 11-7 and SR 21-8, the 2021 interagency statement on model risk management for BSA/AML systems. The OCC bulletin replaces its 2011 guidance. SR 11-7 is no longer the current reference, so do not cite it as one. A footnote in the guidance says generative AI and agentic AI models are novel and rapidly evolving and are not within its scope, but that a bank's risk management and governance practices should still guide controls for tools it does not cover.
The third is OCC Bulletin 2023-17, the June 2023 interagency guidance on third-party relationships, which rescinded OCC Bulletins 2013-29 and 2020-10.
Examiners read the AML program rule on top of all this. Under 31 CFR 1020.210, a bank's program needs internal controls, independent testing, a designated compliance officer, training and risk-based customer due diligence. Our glossary entry on anti-money laundering (AML) covers the program basics.
Data lineage is the first question because every later answer depends on it. Expect to show which systems feed the AI (core banking, payments, KYC records, watchlists), how fields are mapped, and what happens when a field is missing or stale. If an AI employee ranks an alert, an examiner should be able to trace each input to a source record.
Keep the evidence boring and complete: a data dictionary, the mapping from source to model or agent input, and a record of changes. For the monitoring side of this, see our guide to AI alert triage and false positives.
A bank should know every system that influences an AML decision, who owns it, what it is allowed to do and which version is live. For agents, that includes the tools each agent can call and the identity it acts under. Because SR 26-2 places generative and agentic AI outside its scope, the inventory is where you show that your own governance fills the gap. We lay out controls for that in 12 controls for governing AI agents and map them in NIST AI RMF for AI agents.
This post does not go deeper on model risk management. The glossary term for model risk management (MRM) is the place to start.
Examiners want to see how you decided the system was fit for purpose and how you know it still is. That means documented test sets, thresholds and the reasoning for them, results over time, and a record of each tuning change with who approved it. The 2018 statement notes that when a bank pilots AI-based monitoring and finds activity existing processes missed, the agencies will not automatically assume the existing processes were deficient. A pilot that runs in parallel with current processes, with its results written down, is the cleanest evidence.
A closed alert needs a rationale a stranger could follow: what was reviewed, what was found, why it was closed or escalated, and who decided. AI-drafted rationales are fine if they are specific to the case and the decision is attributable. Retention matters here. Records required by Chapter X are generally kept five years under 31 CFR 1010.430, and a bank must keep a copy of each SAR and its supporting documentation for five years from filing under 31 CFR 1020.320(d). Our walkthrough of lookback reviews shows how that documentation holds up when a past period is re-examined.
OCC Bulletin 2023-17 applies to AI vendors like any other third party, and the 2018 statement already told banks to consider third-party risk when adopting new approaches. Expect questions about due diligence on the vendor, contract terms on data use and audit access, where data is processed, subcontractors, and your exit plan. A vendor you cannot examine is a finding waiting to happen.
A bank must file a SAR no later than 30 calendar days after initial detection of facts that may constitute a basis for filing, extended to a maximum of 60 days if no suspect is identified (31 CFR 1020.320(b)(3)). A SAR and any information that would reveal its existence are confidential under 1020.320(e). Both points shape how an AI can be used: it can assemble evidence and draft, but the decision to file and the final text belong to your BSA officer or a named delegate, and nothing about a SAR can reach the subject. See SAR narrative drafting with AI for the split in practice.
Here is how we run a BSA/AML case, using only what we have published about our platform.
Each AI employee runs one Agent Operating Procedure (AOP). For an alert-review or SAR-drafting role, the AOP would hold the bank's own thresholds, the sources of truth the agent may read, approval limits and escalation paths. The agent has its own identity with least-privilege access. A SAR-drafting agent has no permission to file and none to contact the customer, so the filing and the confidentiality rule stay with your people.
A case goes to Needs Attention when the agent cannot resolve it within scope: a threshold breach, missing data or an unfamiliar pattern. The reviewer gets the case with context already assembled. Before any case closes, the PEV loop validates the agent's own output. Every step is logged, and in the biopharma procurement deployment the agent writes its reasoning inside the customer's own system of record, SAP Ariba. For AML, that means the case-management system your examiners already read.
A reviewer's correction becomes an AOP change on a branch, is tested against evals including a golden set of behavior the agent must already get right, is reviewed and then merged, with no engineering ticket. That is the change history an examiner can inspect. See the AOP glossary entry.
Expect a high manual-review rate at launch. In that biopharma deployment, the agent sent 64% of requests to manual review in week one. As reviewed corrections built up, its decision rate rose from 36% to 85% and manual review fell to 15%. That figure comes from procurement, not AML, but the lesson transfers: early escalation is the safety mechanism working.
Banks usually choose BYOC or on-premises so data stays in an environment they already audit. Our deployment models guide compares the options. For the full workflow, start at the AML automation hub.
Assemble one folder per question above: data lineage, inventory, validation and tuning records, a sample of dispositions, the vendor file, and a SAR sign-off log. Run a mock exam with your internal audit team and fix the gaps you find. Where AI sits outside SR 26-2's scope, write down which governance standard you apply instead, so the answer does not depend on one person's memory.
