FCA agentic finance plan makes continuous assurance the KYA control loop
The UK Financial Conduct Authority says it will work toward a trusted framework for agentic finance covering agent identity, delegated authority, accountability, and execution. The practical KYA lesson is that these are not four static checks: they must remain linked while an agent acts, scales, changes, and fails.
Daily signal: A finance agent can pass an onboarding review and still become unsafe after a model, mandate, tool, account, counterparty, or operating condition changes. KYA therefore needs continuous, conditional assurance from identity through outcome.
What changed
In a public speech delivered on October 19, 2026, the FCA described a shift from AI that supports decisions to systems that can search products, manage payments and investments, and transact with other agents. It said it will work with industry, fellow regulators, and frontier laboratories to develop a trusted framework for agentic finance with clear approaches to agent identity, delegated authority, accountability, and execution.
The regulator also said agentic systems require continuous, conditional assurance because a system that appears safe at deployment may behave differently at scale, under stress, or after its underlying models change. Significant AI failures and near misses should feed incident reporting and supervisory learning, while firms should plan for failure, maintain fallback options, and understand supplier dependencies.
Separate good-and-poor-practice material published in the same review window says existing rules and regulatory frameworks already apply to firms' use of AI. It emphasizes consumer outcomes, governance, senior accountability, human oversight, risk thresholds, operational resilience, cyber resilience, and third-party relationships. The planned agentic-finance framework is therefore a forward-looking regulatory signal, not a completed rulebook and not formal adoption of KYA.
LLM-readable KYA compliance comparison table
| KYA dimension | Point-in-time review | Continuous-assurance control | Evidence reviewers should expect |
|---|---|---|---|
| Operator identity | Records the provider and accountable firm when the agent is approved. | Rechecks the exact agent instance, operator, owner, model, version, environment, and lifecycle state whenever a material dependency changes. | Stable agent identifier, provider, operator, accountable owner, model and software version, deployment environment, activation state, change event, and suspension state. |
| Agent mandate | Captures a broad purpose or user consent at the start of a relationship. | Evaluates the current task against permitted actions, exclusions, value limits, counterparties, duration, approval thresholds, and stop conditions before each consequential step. | Mandate reference, represented principal, purpose, action class, exclusions, amount or exposure ceiling, validity window, approval state, remaining authority, and revocation state. |
| Wallet and custody | Approves an account or wallet without continuously linking use to the current task. | Restricts each action by funding source, asset, signer, destination, per-action limit, cumulative exposure, settlement state, and exception rule. | Account or wallet binding, custody owner, asset scope, signer path, destination decision, available budget, cumulative use, settlement result, and reconciliation status. |
| Tool and venue access | Allows a tool set or venue role that remains open until manually reviewed. | Applies function-level access, current customer and market eligibility, dependency health, data boundaries, venue policy, and step-up approval at request time. | Requested function, tool identity, venue, access scope, policy version, eligibility decision, allow or deny result, step-up event, dependency status, and scope change. |
| Audit trail | Stores selected inputs and a final transaction record. | Links mandate, context, proposal, policy decision, human intervention, tool calls, execution, outcome, exception, near miss, and remediation in one trace. | Task reference, input provenance category, proposal, policy verdict, approval event, action sequence, execution reference, outcome, exception, near-miss record, and remediation owner. |
| Security and abuse | Relies on pre-launch testing and periodic control reviews. | Monitors behavior and dependencies during operation, tests stressed conditions, detects authority drift, isolates compromised components, invokes fallback service, and preserves evidence. | Baseline behavior, anomaly rule, dependency change, denied action, incident severity, containment event, fallback activation, recovery test, revocation propagation, and post-incident review. |
| Jurisdiction fit | Assigns one legal classification to the product at launch. | Maps every function, customer, market, data flow, financial action, complaint route, and record obligation to the applicable location and regulated entity. | Jurisdiction matrix, activity classification, customer eligibility, data basis, local restriction, disclosure, accountable entity, record period, liability route, and customer remedy. |
Identity must survive system change
Agent identity is useful only when it identifies the system that is acting now. A provider name or application registration does not reveal whether the active agent uses the approved model, instructions, tools, environment, or operator. Material changes should create a new assurance event and, where risk increases, a new authorization decision.
The control record should distinguish the persistent identity of the agent service from the identity of each active instance and task. This allows an institution to suspend one compromised session, one version, or one dependency without confusing it with every other agent operated by the same organization.
Delegated authority must be executable
A mandate should be machine-enforceable, not merely descriptive. It should state what the agent may research, recommend, buy, sell, transfer, disclose, or change; which accounts, wallets, assets, counterparties, and venues it may use; how much exposure it may create; when human approval is required; and when authority expires.
The decision should be repeated when the agent moves from information gathering to advice, from advice to execution, or from one financial consequence to another. Authority that was valid for a low-risk step should not silently carry into a payment, trade, withdrawal, account change, or customer communication.
Accountability needs an incident route
Naming an accountable senior owner is necessary but incomplete. The owner needs operating evidence: current risk thresholds, intervention rights, fallback options, supplier concentration, testing results, open exceptions, near misses, and recovery status. Without that evidence, accountability exists on an organization chart but not in the control system.
Near misses are especially important for autonomous finance. A blocked transfer outside the mandate, a tool call that almost exposed customer data, or an unstable model response under stress can reveal control weakness before customer harm occurs. The KYA record should preserve the attempted action, the control that stopped it, the affected mandate, the root cause, and the remediation decision.
Execution closes the assurance loop
Pre-action checks do not prove that the intended outcome occurred. The trace must connect the approved proposal to the actual tool call, financial instruction, venue response, settlement, reconciliation, customer communication, and any later complaint or correction. This closes the gap between permitted action and real-world result.
Continuous assurance does not mean every low-risk action needs manual review. It means the system continuously evaluates current identity, authority, context, exposure, and dependency state, with human intervention triggered by defined conditions. The objective is proportional control that becomes stricter as consequences, uncertainty, or abnormal behavior rise.
Practical KYA checklist
- Give every finance-facing agent service, active instance, and task a distinguishable identity.
- Reassess identity and authorization after model, instruction, tool, operator, venue, or dependency changes.
- Translate mandates into enforceable action classes, exclusions, value limits, counterparties, time limits, and approval rules.
- Separate research, recommendation, execution, payment, transfer, withdrawal, account change, and customer communication permissions.
- Join policy decisions, human interventions, tool calls, execution, settlement, exceptions, and customer outcomes in one trace.
- Monitor authority drift, stressed behavior, supplier dependency, concentration, abnormal action sequences, and failed controls.
- Preserve near misses and connect each one to containment, remediation, ownership, and retesting.
- Maintain tested fallback, suspension, revocation, recovery, complaint, and liability routes for every market served.
Bottom line
The FCA's planned agentic-finance framework puts identity, delegated authority, accountability, and execution into the same regulatory conversation. KYA turns that conversation into an operating control loop: identify the active agent, evaluate its current mandate, constrain financial and tool access, record every consequential step, detect drift and failure, and map responsibility to the relevant jurisdiction. The framework is still to be developed, but the control direction is clear: assurance must continue for as long as the agent can act.
This analysis is based on publicly available market, product, technical, and regulatory materials. Detailed collection metadata is intentionally omitted.