AI Agents in Regulated FinTech: Control Before Autonomy
Listen to this article
Preparing audio…
AI Engineering
An AI agent should not receive financial authority merely because it can plan and call tools. I treat autonomy as a graduated control decision: constrain tools, bind every action to policy and identity, require approval for material effects, and preserve replayable evidence. The use cases below are synthetic.
Start with an authority map
“Agent” describes an interaction pattern, not a risk class. A read-only assistant that summarizes a public policy differs fundamentally from a system that changes a customer limit or initiates a refund. Inventory each use case by data accessed, tools callable, maximum financial effect, reversibility, customer impact, and legal or compliance owner.
The US banking agencies’ Revised Guidance on Model Risk Management, SR 26-2, issued 17 April 2026, describes risk-tiered inventories, validation, monitoring, governance, effective challenge, and third-party considerations for models used by banking organizations. Whether a particular agent meets a jurisdiction’s formal definition of a model requires legal and supervisory analysis; the control disciplines remain useful for the model, tools, and decision process.
The Bank of England and FCA’s 2024 survey of AI in UK financial services reports industry practices and concerns around accountable ownership, data governance, and third-party dependencies. It is survey evidence, not a rulebook.
Separate proposal from execution
Let the model produce a structured action proposal: tool name, typed parameters, purpose, supporting evidence, confidence or uncertainty, and requested authority. A deterministic policy gateway validates it against the authenticated user, customer/account scope, amount limits, time window, segregation of duties, and current case state.
The model never chooses its own credential. The gateway issues a short-lived, single-purpose capability to a narrowly scoped tool adapter. The adapter validates parameters again and maps the request to a domain command with an idempotency key. Financial state transitions remain owned by the domain service and ledger, not by the conversation history.
Material actions require an approval bound to the exact proposal. Show the reviewer the amount, destination, affected account, source evidence, model and prompt version, and expiry. If any material field changes after approval, invalidate it. “A human clicked approve” is not a control if the screen hides what will execute or the agent can substitute parameters later.
Treat all retrieved content as untrusted
Prompts, emails, documents, web pages, and tool results can contain instructions aimed at the model. Never let retrieved text redefine policy or grant tools. Label content and instructions separately, allowlist tool schemas, validate every output, and prevent the model from selecting arbitrary URLs, SQL, shell commands, or recipients.
The NIST Generative AI Profile, AI 600-1 identifies risks including confabulation, information integrity, privacy, misuse, and third-party dependencies, with lifecycle actions for governance, measurement, and management. Use it as voluntary risk guidance, not as law.
Redact or tokenize sensitive context before it reaches a third-party model where possible. Define data residency, retention, training-use, incident notification, and subprocessors contractually. Keep secrets outside prompts and traces. A tool call should reference a protected object identifier rather than copying account data into free text.
Build an evidence record, not a surveillance dump
For each run, record the authenticated actor, use case, policy version, model and configuration, prompt-template version, retrieval document identifiers and versions, proposed actions, approvals, tool requests, domain-operation identifiers, outcomes, and exceptions. Hash or reference sensitive content instead of logging it indiscriminately.
Evidence must answer: who requested this, what authority applied, which facts were available, what did the model propose, what deterministic controls allowed, what financial operation executed, and how was the final outcome reconciled? Preserve stable identifiers across traces, cases, and ledger records.
Replay does not mean re-executing tools. An evaluation harness should reconstruct the input and proposed decision in an isolated environment with mocked tools. Production replay must never move money.
Increase autonomy only after measured evidence
Use stages: offline evaluation; shadow mode; read-only production; recommendations requiring approval; low-value reversible actions within limits; and only then narrowly defined automation. Promotion criteria should cover task success, unsupported-action rate, policy-block rate, approval disagreement, tool error, security tests, customer harm, operational load, and rollback performance.
Monitor by risk slice, not only averages. A low overall error rate can hide failures for a rare product or language. Revalidate when the model, prompt, retrieval source, tool schema, policy, or provider changes. Maintain a kill switch at the policy/tool layer that does not depend on the model cooperating.
Test adversarial and operational failure
Test prompt injection in a retrieved document, a model attempting an unlisted tool, parameter substitution after approval, duplicate execution after timeout, expired credentials, a compromised third-party tool, conflicting policies, missing evidence, and a model/provider change during an active case. Assert that no unapproved financial effect occurs and that the evidence still explains the block.
The architecture decision
Put the model inside the control plane, not in charge of it. Models may interpret and propose; deterministic services authenticate, authorize, enforce limits, acquire approval, execute idempotently, and record outcomes. Autonomy should be narrow, measurable, reversible, and earned one use case at a time. That architecture supports useful agents without turning probabilistic text generation into unbounded financial authority.
What decision would you make?
Add a question, a field note, or a respectful counterpoint. Comments are for signed-in members so the discussion stays useful and professional.