How should financial institutions govern AI systems that can spend money on behalf of users?

Treat the AI system as a delegated non-human identity with a narrow transaction scope, explicit ownership, and revocation controls. The governance model should define what it may spend, when human approval is required, and how every action is logged. Without those boundaries, agentic payments become an uncontrolled authorization channel rather than a managed capability.

Why This Matters for Security Teams

When an AI system can initiate payments, move funds, or approve purchases, it stops being “just a model” and becomes an execution-capable non-human identity with financial impact. That changes the control model from advisory AI to delegated authority. Institutions need clear scope, strong ownership, revocation, and evidence of every decision path. The governance gap is especially risky because payment abuse can look like normal business activity until reconciliation, fraud monitoring, or audit review catches it. The NHIMG Top 10 NHI Issues research is useful here because it frames lifecycle control as a security requirement, not an administrative preference. For financial institutions, that lifecycle must extend to AI-spend authority, not just login access. Current guidance suggests treating spending rights as a high-risk delegated capability that demands the same rigor as privileged access. In practice, many security teams discover this only after an agent has already triggered an unauthorised purchase or exceeded a policy threshold, rather than through intentional delegation design.

How It Works in Practice

The practical model is to bind the AI system to a narrowly defined authority envelope. That envelope should specify what it may buy, the maximum value per transaction, daily or monthly caps, approved merchants or categories, and the exact conditions that force human approval. This is consistent with the access-and-audit approach in the NIST Cybersecurity Framework 2.0 and with privilege discipline described in NIST SP 800-53 Rev. 5 Security and Privacy Controls. For banking and fintech use cases, the AI should be issued a delegated identity, not a shared service account, so every action is attributable and revocable.

Implementation usually needs four layers:

• Policy gating: spending rules enforced before execution, not after settlement.
• Approval workflow: human sign-off for exceptions, threshold breaches, and unusual recipients.
• Transaction telemetry: immutable logs covering prompt, policy decision, tool call, payment instruction, and outcome.
• Emergency revocation: a fast kill switch that disables all spend authority without affecting unrelated services.

Identity lifecycle discipline matters because delegated financial authority is only safe when provisioning, rotation, review, and decommissioning are auditable. The NHIMG Ultimate Guide to NHIs – Lifecycle Processes for Managing NHIs is relevant here because the same governance pattern applies to AI agents that hold or exercise credentials. For institutions that expose AI through APIs, include transaction signing, step-up checks for high-risk actions, and separation between recommendation and execution. These controls tend to break down when the AI is connected to legacy payment rails or multiple treasury systems because policy enforcement becomes inconsistent across channels.

Common Variations and Edge Cases

Tighter spending controls often increase friction and operational overhead, requiring institutions to balance customer convenience against fraud exposure and model autonomy. There is no universal standard for this yet, especially where AI systems can both recommend a purchase and trigger settlement. Current guidance suggests treating that as a higher-risk pattern than simple spend advice.

Some environments will need stricter controls than others. A retail chatbot that submits a one-off merchant payment may only need a low ceiling and manual approval, while a corporate treasury assistant may need segmented limits by business unit, jurisdiction, and counterparty risk. In regulated financial services, the strongest design is usually a tiered model: low-risk transactions execute automatically, medium-risk transactions require conditional approval, and high-risk transactions are blocked until a human explicitly authorises them. Audit teams should also test for indirect prompt injection, stolen session tokens, and privilege creep, because the AI’s decision path can be manipulated even when the payment policy itself looks sound. The NHIMG Ultimate Guide to NHIs – Regulatory and Audit Perspectives is useful when documenting why a given approval threshold, logging depth, or revocation SLA is defensible to auditors and regulators.

For identity assurance, institutions should align these controls with the NIST SP 800-63 Digital Identity Guidelines wherever the AI is acting on behalf of a person, because impersonation, delegated authentication, and step-up verification all affect the trust boundary. The hardest edge case is when an AI agent can chain multiple low-value actions into a larger financial outcome, because individual transactions stay inside policy while the aggregate effect does not.

Related resources from NHI Mgmt Group

• How should financial institutions govern access when launching crypto products?
• How should security teams govern API keys used for generative AI access?
• How should financial institutions govern explainable AI in high-risk use cases?
• How should financial institutions include AI systems in DORA compliance programmes?