Ten questions your examiner will ask about your agents

An examiner reviewing an AI agent will ask about the decision, not the model: which rule applied, who approved it, whether anyone could have stopped the agent before it acted, and whether you can show all of that for a single case without calling engineering. This post sets out ten questions in that spirit, with what a good answer contains. No regulator has published this list. It is our synthesis of public guidance and reported supervisory attention, and each question says where it comes from.

What examiners are asking about AI agents, and why now

Three things landed in October. On 13 October Reuters reported that the Federal Reserve, the OCC and the FDIC are asking banks how they use autonomous AI agents, which controls limit them and which models sit underneath. eSecurity Planet's summary lists the concerns: whether a bank can reconstruct what an agent did, when and why, and whether a person must approve a sensitive action such as freezing an account or changing payment instructions. On 15 October the Financial Stability Board published a consultation for banks warning that highly autonomous agentic systems "may act unpredictably or outside intended boundaries", that agents "do not reason like humans", and that their behavior can change as they gain new tools or prompts. The same day FIS made its Claude-based AML investigations agent available to any US bank, with an audit trail and an analyst who confirms every case. The coverage notes that no FinCEN, OCC or FFIEC guidance yet explains how examiners should judge agent-assisted AML decisions.

Two cautions. The US regulator story is second-hand, and the FSB paper is a consultation that may change. And the April 2026 interagency guidance, SR 26-2, replaced SR 11-7 and states that generative and agentic AI models are not within its scope. That leaves no dedicated rulebook for supervising agents. Examiners fall back on governance, operational risk, third-party risk and consumer compliance, and those frameworks were written for processes, so they ask process questions. A bank that reads "out of scope" as "less to prove" has it backwards.

After the ten, one exported case shows the answers in a single record, and a one-page checklist lets you run them on your own process this week.

The ten questions

The questions run from what exists, to who owns it, to one case, to what the customer was told. Supervisory reviews differ, so read this as a pattern, not a script.

1. What agents do you have, and what can each one change?

This is the inventory question, prompted by the reported US interest in how banks use agents at all. The examiner wants every agent, its process, its decisions and the actions it can take: a payment, a limit change, a claim. Agents appear faster than registers, and a business-team pilot on a vendor platform with real data counts.

A good answer is a register with the process, decisions, actions, systems reached and an owner, pilots included. An agent missing from the list is a governance finding before any record is read.

2. Who is accountable for each decision?

The examiner wants a name: the executive who answers for the outcome of the process, such as the head of credit or the head of claims, not the build team. The difficulty is that the rules usually sit in a prompt owned by the builder, and the accountable executive has never read it.

A good answer gives each decision a named owner with authority over the process, who has seen the actual rules in readable form and approved them on a dated record. If nobody will sign, the agent is not ready.

3. Which rule did it apply, and in which version?

The examiner picks one case from March and asks for the rule that governed it, as it stood that day. With rules in a prompt plus retrieved passages, the answer is a reconstruction. The prompt has changed since, and the sources may conflict: a credit policy that caps loan-to-value at 80% and a 2024 procedure that says 85%. A model will lean one way on one run and the other way on the next, and nobody chose.

A good answer names the rule, its ID, version, owner and approval date, and the case record points at it. Conflicts between sources were settled once by the owner, and the settlement is on file.

4. Can you stop the agent before it acts, or only notice afterward?

Examiners separate controls that prevent from controls that detect, and detection is weaker for actions that cannot be undone, such as a released payment. Most tooling added to agents detects. Guardrails filter what the agent says, evaluation suites and model judges score outputs after the model has interpreted the rule, and observability records what happened. EMA's August 2026 research for Cequence Security found that only 34% of enterprises check an agent's authority at the moment it acts.

A good answer shows a check at each step, outside the model, against the approved rule, that blocks mismatches and routes the case to a person. The block is recorded like any other event.

5. Where must a person approve, and what covers a case the rules do not?

The reported US example is an employee reviewing an agent's recommendation before an account is frozen or payment instructions change. FIS describes the same pattern, with no AML case closing until an analyst confirms the outcome. "A human is in the loop" can mean anything from approving every case to someone who could look. The examiner wants the step, the role, the threshold, what the reviewer sees and what they record, and may test whether review is real, for instance how long reviewers spend and how often they overrule the agent. A case nobody planned for is the other half: an agent that guesses is making policy on the spot.

A good answer has the owner marking judgment points in advance and naming a judge for each, either a person or an agent with written authority below a limit. Uncovered cases go to the judge. Every judgment is recorded with a name and a reason.

6. Can you reconstruct one case and hand it over without engineering?

This is the auditability concern in the reported US questions: what the agent did, when and why. Logs, traces and prompt histories are written for engineers. They show what the system did, step by step, and rarely which rule governed, whether it was the approved version, or who stepped in. With logs, "why did it approve this?" is a reconstruction that ends in a story.

A good answer is a lookup. The record names the case, the rule set and version, the sources, each step with its rule, the figures the agent extracted, every human judgment with its reason, and the outcome. Test it by picking a recent case and producing that record without engineering explaining it. What you cannot fill in is your finding.

7. What happens when several agents hand work to each other?

Real processes run as a sequence: one agent gathers data, one assesses, one executes. The FSB's warning about agents acting outside intended boundaries raises the question of whether anything checks the whole chain or only each step. An income figure extracted by one agent and a limit applied by another can each be right on their own and wrong together, and per-agent logs will not show it.

A good answer has one rule set for the whole process, checked at every step by every agent in the chain, and one case record that spans them, owned by the process owner.

8. What has changed since last quarter?

The FSB notes that agent behavior can change as agents gain new tools or prompts. Change arrives from several directions: a prompt edit, a vendor model update, a new tool, a revised policy. If each agent holds its own copy of the rule, a policy change reaches agents one at a time, and some find out a month late.

A good answer shows change control at the level of the rule. Each revision is approved by the owner, versioned, and reaches every agent at once, and each case points to the version it ran on. Model and tool changes are logged and risk-assessed separately.

9. Which vendors and models touch the decision, and what do you control?

The reported US questions include which models banks deploy, and SR 23-4, the June 2023 third-party guidance, already expects a bank to oversee what its vendors do for it. An agent often rests on a platform, a model provider, tool vendors and a data source. The risk is decision logic that lives inside a vendor's product, where the bank cannot show it, version it or move it.

A good answer maps each third party to what it sees and does, and shows the rules held somewhere the bank controls. With the rule outside the model, a model swap changes how documents are read and leaves the decision logic alone.

10. What does the customer get told, and is it the real reason?

Consumer reviews look at outcomes: whether similar customers were treated alike, and whether a declined customer received the reasons the law requires. The CFPB's Circular 2022-03 says creditors using complex algorithms must still give the specific principal reasons for an adverse action. "The model decided" is not a reason. For insurers, the NAIC's model bulletin on AI systems, adopted by at least 24 states by March 2025 according to Quarles, expects documentation an insurer can produce in an investigation. US institutions with EU customers should plan against 2 December 2027, from which the AI Act's high-risk obligations for credit scoring and for life and health insurance pricing apply.

A good answer takes the customer's reason from the rule that failed, such as loan-to-value above the limit in version 3.2, through the case record and not from a second model asked to explain the first. Similar cases under one version reach the same outcome.

One case, answered: a supplier invoice

Here is what the answers look like in a single record. A payables agent matches an invoice to its purchase order and receipt, and one step needs a person. Every value is illustrative.

Read it against the ten questions. The owner (question 2) is the Controller who sealed version 2.4, and the person who decided the exception. Question 3 is answered on every line, with a version. Each step was checked against its rule before the next began (question 4), and the one step a person decided is recorded as a decision with a name and a reason (question 5). The record is the answer to question 6, and it spans every agent that touched the invoice (question 7). If the tolerance changes next quarter, this case still points at v2.4 (question 8). The rule lives in the Rulebook, not in a vendor's prompt (question 9). Had the invoice been rejected, the reason sent to the supplier would be rule 3.1, price above tolerance (question 10).

Notice what the model did and did not do. It read the invoice and the contract clause, and the figures are attached so anyone can check the reading. It did not decide whether 4.1% was acceptable. A person did, at a step the owner had marked in advance.

Run it this week: the one-page checklist

Pick one agent, or one process you plan to give to agents, and try to produce each item in a day without help from the team that built it. Whatever you cannot produce is where an examiner will start.

Where Factify fits

The exported case above is what Factify produces as the default output of every agent run.

We do not make anyone compliant. We prove that your agents followed your Rulebook, and we give your owners the evidence to show whether the Rulebook meets the regulation.

Frequently asked questions