When a person initiates a wire transfer, the bank verifies several things in sequence: is the account holder authenticated, is the requested amount within their authorized limits, and does anything about the transaction trigger a hold for further review? These checks exist because the financial system has centuries of accumulated experience with what happens when the chain of authorization breaks down.
Now consider the same transaction initiated by an AI agent. The agent authenticates using a stored credential. The account number is correct. The transfer request is syntactically valid. But the bank has no way to determine whether a real person explicitly authorized this transaction, what spending limit that person imposed, whether the agent was operating inside or outside its delegated authority, or whether that authority was revoked after the agent began its session. Authentication has succeeded. Authorization is a different question entirely, and most payment infrastructure is not yet designed to answer it.
Authentication confirms that an entity has the right to access a system using a set of credentials. It does not confirm that the entity was authorized by its principal to perform this specific transaction at this moment. For human users, the gap between authentication and authorization is managed through session controls, transaction limits, behavioral monitoring, and friction at high-risk thresholds. These mechanisms assume a human is present and can respond to prompts.
Agents change that assumption. An agent that has obtained valid credentials can authenticate continuously without any human remaining in the loop. The agent's behavior may look indistinguishable from normal account activity, particularly if the transaction amounts fall within expected ranges.
What is missing is a way for the agent to present proof that it was delegated specific spending authority, that the authority covers this transaction, and that the person who granted it has not since revoked it. Authentication and identity proofing are well-understood mechanisms. Delegation is a distinct concept that neither was designed to handle, and it becomes the critical gap when the party initiating the transaction is software acting on a principal's behalf.
For a financial institution receiving a payment request from an agent, the full set of questions looks like this:
Most current models treat the account holder as the unit of authorization. Controls are calibrated to account-level patterns: typical transaction sizes, merchant categories, geographic behavior. When an agent transacts, it may follow patterns quite different from the account holder, such as a procurement agent instructed to execute bulk payments to new vendors. Behavioral anomaly detection designed for individual humans is not a reliable control for agent-initiated workflows.
API-based payment access moves the problem to a different layer but does not resolve it. An OAuth token grants an application access to an account's payment capabilities within a defined scope. It does not bind that access to a specific agent, a specific human principal, or a specific task. When an enterprise deploys multiple agents across multiple banking integrations, the relationship between each transaction and the person who ultimately authorized it becomes difficult to reconstruct. Under the Bank Secrecy Act, institutions must be able to identify the natural person behind transactions for beneficial ownership and suspicious activity reporting. FinCEN's April 2026 proposed rulemaking to reform AML/CFT programs encourages adoption of innovative technologies but does not yet address agent-initiated transactions specifically.
Notably, recent regulatory guidance confirms that banks can accept verifiable digital credentials for customer identification, establishing the verification side of this equation; the authorization side, determining whether an agent presenting that credential was delegated the authority to transact, remains the open problem. In the EU, the AMLD6, adopted in 2024 with transposition deadlines through 2027, similarly assumes human account holders.
The architectural pattern that addresses these questions is one SpruceID has been developing as part of its work on agent identity and authorization and informed by exploratory work with the Bank for International Settlements on agentic payments.
An identity credential, issued by a regulated intermediary that has verified the principal's identity, answers who the agent represents. This is the "agent passport" concept: not a platform-issued session token, but a credential from an identity trust that binds the agent to a verified principal.
A payment capability credential answers what the agent is authorized to do. This credential specifies transaction limits, permitted categories, valid time window, and any other constraints the principal imposed at delegation. The receiving institution reads these constraints directly from the credential rather than relying on application-layer configuration.
Revocation status, referenced within the credential and checkable against a registry, answers whether the authority is still current. If the principal has revoked the agent's authority, the verification fails cleanly and the transaction is declined.
The infrastructure supporting this model already exists in mature form for verifiable digital credentials used by people. SpruceID has deployed this infrastructure at population scale for California and Utah. The open question is how to compose these components into a delegation layer that agents can carry and financial institutions can verify.
None of the architectural components described here is theoretical. What does not yet exist in standardized form is the specific application to agent-initiated financial transactions: the credential formats, the trust frameworks governing who may issue agent identity credentials for regulated financial use, and the integration patterns payment infrastructure would use to verify them.
Several parallel efforts are converging. The IETF draft on AI agent authentication and authorization (draft-klrc-aiagent-auth), with contributors from OpenAI, Okta, Ping Identity, AWS, and Zscaler, proposes composing existing standards rather than building new protocols. The W3C Agent Identity Registry Protocol Community Group, proposed in April 2026, is developing open specifications from the verifiable credential side. These efforts are not yet at ratified-standard status, but they represent significant industry investment in getting the infrastructure right.
For financial institutions and payment infrastructure teams, the architectural decisions being made before standards stabilize will either compose cleanly with what emerges or require expensive remediation. The choice of whether to treat agent authorization as an application-layer problem or as a credential-layer problem will shape how easily those systems adopt the standards that are coming.
SpruceID is actively exploring these design questions and is interested in comparing approaches with financial institutions and payment infrastructure teams working on the same problem. If your organization is building infrastructure for agent-initiated transactions and wants to discuss how identity and delegation could work at the payment layer, we would welcome the conversation.
Building digital services that scale take the right foundation.
About SpruceID: SpruceID builds digital trust infrastructure for government. We help states and cities modernize identity, security, and service delivery — from digital wallets and SSO to fraud prevention and workflow optimization. Our standards-based technology and public-sector expertise ensure every project advances a more secure, interoperable, and citizen-centric digital future.
