Human Approval Checkpoints for AI Agents in Regulated Finance

This article is written by an engineering team, not a law firm or a regulator. It explains what several public regulatory texts say about human oversight of AI, and then shows how a team might turn that into approval steps in an agent. It does not tell you what your firm is required to do. That depends on your jurisdiction, licence, products and the specific use case, and it should be decided with your compliance function and counsel.

We checked the sources named below on 10 November 2026. Regulation in this area is moving, including dates for the EU AI Act, so confirm the current position before relying on anything here. If you want the mechanics of pausing an agent first, read Pause an AI Agent for Human Approval with LangGraph interrupt() and Human-in-the-Loop AI Agent Frameworks Compared.

Four widely cited sources show the range. None of them is a complete answer on its own.

The pattern across them is consistent. Human oversight is expected to be proportionate to risk, effective rather than nominal, and evidenced. That is a design brief, and the rest of this article works from it.

A single approval step on everything creates queues and fatigue. No approval at all fails the first test above. The practical answer is tiers, decided with compliance and written down. The thresholds below are illustrations to start the conversation, not recommendations.

Decide tier membership by three questions: how much could go wrong, how easily can it be undone, and does it affect a customer or a regulated outcome. Re-tier when the agent's abilities change, because adding a tool can quietly move an action up a tier.

Finance already has a control for this: the maker-checker, or four-eyes, principle, where the person or system that prepares an action is not the one who approves it. Applied to agents, the agent is the maker, and a person with the right authority is the checker. For tier 3 you may want two checkers.

Three rules make it real rather than ceremonial:

• Separation of duties: the approver must not be the requester of the underlying action, and approval rights should differ from build and deployment rights.
• Least privilege for the agent: the agent's credentials should allow it to propose, not to execute above its tier. Execution should happen in a step that only runs after an approval is recorded, with a different credential.
• Approval bound to the exact action: the person approves specific parameters, such as a payee and amount. If anything changes after approval, the approval is void and the request goes round again.

The mechanics for pausing, binding and resuming are covered in our LangGraph approval guide. The point here is the policy those mechanics enforce.

Article 14 of the EU AI Act explicitly names automation bias, the tendency to rely too much on a system's output. Every team that adds approval steps runs into it. A reviewer who sees a confident, well-written recommendation, forty times a day, will approve most of it. That satisfies the checkbox and fails the purpose.

A useful test is to seed a small number of deliberately flawed requests into the queue, with the knowledge of compliance, and see how many are caught. If reviewers catch few, the process needs to change before it is relied on. Also make rejection cheap: a reviewer who has to write an essay to say no will say yes.

Two categories draw particular attention. For customer communications, FINRA notes that its content standards for communications with the public apply whether a human or a technology tool generated the message. Whether a firm pre-approves every AI-drafted message, samples them, or uses approved templates is a supervisory decision for the firm and its compliance function, not an engineering default.

For decisions with legal or similarly significant effects on a person, such as credit or account decisions in the EU, GDPR Article 22 is the starting question. The text gives people a right not to be subject to solely automated decisions in many cases, and, where permitted exceptions apply, requires safeguards including a route to human intervention and to contest the decision. A design that builds in a genuine human decision point and a way for the customer to ask for review gives you something to work with. Whether a particular approval step is sufficient is a legal question.

When an examiner, an auditor or a customer asks 'why did this happen', the answer is a record. Design it before you build the agent, because it is hard to reconstruct later. This list is our suggestion, to be shaped by your retention and recordkeeping obligations.

Store this in an append-only system you control, separate from the agent's own state, with access limited and retention set by policy. Paused-run state and checkpoints are useful for resuming work but are not a substitute for an audit record.

SR 11-7 stresses ongoing monitoring and outcomes analysis, not just validation before launch. The same attitude suits agents, whose behaviour changes with model updates, prompt edits and new tools.

• Track rejection and edit rates by action type. A sudden change is a signal.
• Sample approved actions after the fact and check them against the system of record.
• Measure time to decision, queue length and expired requests.
• Record every change to prompts, tools and models, and re-run your evaluation set before release. Our guide to evaluating AI agents in production covers how.
• Keep an inventory of agents, their tools, their tiers and their owners, as SR 11-7 recommends for models.
• Review the tiering itself on a schedule, because the agent's reach will grow.

1. Which rules and guidance apply to this use case in each jurisdiction we serve?
2. Does this agent count as a model under our model risk policy, and who validates it?
3. Which actions fall into each tier, and who signs off the tiering?
4. Where are pre-approval, sampling and templates acceptable for customer communications?
5. Could any decision here be 'solely automated' with significant effect on a person, and what route to human review do we offer?
6. What do we have to retain, for how long, and in what form?
7. How do we treat vendor and embedded AI features we did not build?
8. What would we show a regulator tomorrow if they asked how this works?

Bring working drafts of the tier table and the evidence record. Compliance teams respond better to a concrete proposal than to an open question. For help designing and building approval steps into an agent for a regulated workflow, see our agentic workflow orchestration service.