Agentic payments architecture: separating intelligence from execution

Agentic payments have moved from a speculative idea to an active architecture question. In its July 2026 Financial Stability Report, the Bank of England described more autonomous payment systems as an area of rapid innovation and identified questions around authorisation, traceability, fraud, liability, resilience and legal accountability.¹

The central design problem is easy to state. An AI agent works with probabilities, context and changing objectives. A payment system must turn an approved instruction into an outcome that is predictable, attributable and reconcilable. The Bank and the International Monetary Fund both identify this tension between probabilistic AI behaviour and deterministic payment infrastructure.¹ ²

For enterprise payment teams, the useful response is an architectural boundary. An agent may interpret a goal, compare options and propose a payment. It should not hold an unrestricted path to a payment rail. Between reasoning and execution, a deterministic control plane must decide whether an instruction is permitted, sufficiently evidenced and safe to submit.

Start with three separate responsibilities

The IMF analyses agentic payments through three layers: intent, authorisation and settlement.² That model is a sound starting point, provided each layer has a distinct technical responsibility.

Intent is the objective the user or organisation wants to achieve. It might be narrow, such as paying an approved invoice on its due date, or conditional, such as moving surplus cash when a balance exceeds a defined threshold. An AI agent can help interpret the objective, collect context and choose among permitted actions.

Authorisation converts that proposed action into a decision that a payment platform can enforce. It covers identity, delegated authority, consent, policy, limits, risk checks and any required customer authentication. This is where an ambiguous request becomes a bounded payment instruction or is rejected.

Execution and settlement submit the authorised instruction to the appropriate rail, track its state and reconcile the result. They require stable identifiers, explicit status transitions and controlled retry behaviour.

Treating these as separate responsibilities prevents a common design error: allowing a single agent runtime to interpret a request, decide that it is permitted, call a payment API and then explain its own action. That arrangement collapses proposal, approval and evidence into one component. It also makes it difficult to determine whether a failure arose from reasoning, policy, authentication, API execution or downstream settlement.

Keep reasoning in the orchestration layer

The orchestration layer is where agentic capabilities are most useful. It can translate natural language into structured intent, gather invoices or account information, compare payment options and prepare a proposed action.

Its output should be a typed request, not an executable command. At minimum, the request should identify:

• the principal on whose behalf the agent is acting
• the purpose of the payment
• the proposed source and destination
• the amount, currency and requested timing
• the evidence used to reach the proposal
• the mandate or policy the agent believes applies
• a confidence measure and any unresolved ambiguity

The schema is important because it creates a stable hand-off. The reasoning model may change, prompts may be revised and supporting tools may be replaced, while the control plane continues to receive the same explicit fields. Free-form text can remain as evidence, but it should not be the only representation of amount, beneficiary or authority.

The orchestration layer also needs clear limits on the tools and data it can access. Read access to account information does not imply permission to initiate payments. Permission to prepare a payment does not imply permission to approve it. Access should follow the task and expire with it, with each tool call associated with the principal, purpose and session.

Confidence is useful for routing, but it is not authorisation. A highly confident model can still be wrong. If beneficiary identity is ambiguous, invoice data conflicts or the proposed action falls outside a defined mandate, the correct output is an exception for deterministic handling or human review.

Put a deterministic control plane in the middle

The control plane is the boundary that turns a proposed payment into an authorised instruction. Its decisions should follow versioned rules and produce the same result for the same inputs and policy state.

A practical evaluation sequence can include:

1. Resolve the principal, organisation and agent identity.
2. Verify that the agent has an active delegated mandate for the requested action.
3. Validate beneficiary, amount, currency, timing and purpose against policy.
4. Apply transaction, velocity and aggregate limits.
5. Check sanctions, fraud and other risk controls required by the service.
6. Determine whether customer authentication or human approval is required.
7. Bind the approved fields to an immutable authorisation record.
8. Issue a short-lived, single-purpose execution token or instruction.

The authorisation record should capture which policy version was evaluated, which facts were supplied, which controls passed, what approval occurred and exactly which payment fields were authorised. If the amount, destination or execution date changes, the instruction should return through authorisation rather than being edited downstream.

This approach extends the governance questions in our analysis of the FCA's AI review and payments. Model oversight remains necessary, but the payment control plane gives the organisation a place to enforce authority even when the reasoning system produces an unexpected proposal.

Separation also supports independent change. A team can update or replace its agent model without rewriting payment policy. It can add a new payment rail without granting that rail's credentials to the reasoning layer. Risk owners can review versioned controls without reconstructing their effect from prompts.

Make payment state explicit

Once an instruction crosses the authorisation boundary, the execution service should behave like conventional payment infrastructure. It accepts a bounded instruction, submits it through a controlled adapter and records every state transition.

The UK Open Banking domestic payment consent specification illustrates useful primitives. A consent is staged, moves through states including awaiting authorisation, authorised, rejected and consumed, and uses unique identifiers to associate the instruction with later events. The consent creation endpoint also requires an idempotency key.³ These features were not designed as a complete agentic mandate framework, but they demonstrate the value of explicit consent and transaction state.

An enterprise execution service should distinguish at least the following conditions:

• instruction received
• policy authorisation valid
• customer authentication required or completed
• submitted to the payment provider
• accepted, rejected or pending
• completed, failed, reversed or under investigation
• reconciled against the account or ledger

These states should not be inferred from a conversational response. They need to come from the payment provider, account data, scheme messages or the organisation's authoritative ledger.

Idempotency is equally important. If an agent times out after submission, it may decide to try again. The execution layer must recognise the same authorised instruction and return its existing result rather than create a second payment. Retries should be owned by deterministic workflow logic, with limits based on the failure class. A validation error, an authentication timeout and an unknown downstream status require different responses.

Stable end-to-end identifiers allow the organisation to connect intent, authorisation, submission and settlement. They also make auditability in payment journeys operational rather than retrospective. An investigator should be able to move from a ledger entry back to the approved intent and forward from the original request to the final outcome.

Design failure handling before autonomy

Autonomy increases the speed and volume at which a flawed assumption can propagate. Failure design therefore belongs in the first architecture, not a later hardening phase.

Start by defining conditions that always stop automated progress. Examples include an unrecognised beneficiary, a policy conflict, a changed amount after approval, missing evidence, an unavailable fraud control or an unknown execution status. The response may be rejection, a request for more information or human escalation, but it should be explicit.

Then define how the service degrades. If the reasoning layer is unavailable, can approved scheduled payments continue? If account data is stale, which proposals must pause? If one payment provider fails, can traffic move to another without changing the user's consent or the authorised instruction? A fallback is safe only when its authority and operational effect are understood.

Operational controls should include:

• a kill switch scoped by agent, customer, payment type and rail
• rate and value limits outside the model runtime
• immutable logs for proposals, decisions, approvals and execution events
• reconciliation that identifies missing, duplicated and inconsistent outcomes
• alerts based on control breaches and unusual behaviour, not only service availability
• tested procedures for suspending mandates and restoring service

For firms in scope, the FCA expects important business services to have impact tolerances and requires mapping, testing, remediation, learning and communications.⁴ An agentic payment journey should be mapped as an end-to-end service, including model providers, retrieval systems, identity services, policy engines, payment APIs and operational teams. Our open banking operational resilience playbook covers that broader testing discipline.

Testing should include severe but plausible scenarios. An agent may repeatedly misclassify an invoice, accept manipulated context, lose access to a required tool or continue operating with stale policy. The payment provider may return a timeout after accepting an instruction. Authentication may complete after the commercial context has expired. Each scenario should have an expected state, owner, containment action and recovery path.

Use open banking as a controlled execution route

Open banking offers useful foundations for agent-mediated payments: consent resources, customer authorisation, payment initiation APIs, status information and end-to-end references. It can give the execution layer a standardised connection to banks while keeping the reasoning layer away from account credentials.

It does not settle every agentic question. A payment consent does not by itself prove that an AI agent was entitled to interpret a broad commercial objective. Scheme and API rules do not necessarily define how a delegated mandate should be expressed, how liability should be allocated when an agent misinterprets intent, or when a human must intervene. The Bank of England specifically identifies authorisation, traceability, liability, resilience and legal accountability as open areas of concern.¹

The architecture should therefore maintain two related records. The agent mandate defines what the agent may propose or approve on behalf of a principal. The payment consent and authentication record defines what may be submitted through the selected rail. A control plane binds them for one instruction without treating them as interchangeable.

This layered approach also preserves optionality. The organisation can route an approved instruction through open banking, a card-based service, an internal ledger or another payment mechanism while applying the same upstream mandate and policy. Rail-specific controls remain in the adapter and execution layer.

That is consistent with the broader case for payments infrastructure built for the next decade: intelligence, policy and execution should be composable, observable and replaceable without weakening the control boundary.

Questions for an enterprise design review

Before connecting an AI agent to any payment capability, architecture, product and risk teams should be able to answer these questions:

• Where is user or corporate intent recorded in a form that can be reviewed later?
• Which component decides whether the agent has authority, and can it be bypassed?
• Are amount, beneficiary, timing and purpose cryptographically or logically bound to the approval?
• Which decisions are deterministic, versioned and reproducible?
• How are authentication, consent and agent mandate distinguished?
• Who owns retries, duplicate prevention and unknown payment states?
• Can every settled transaction be traced back to its proposal, evidence, policy and approval?
• What stops the service when a dependency, control or evidence source is unavailable?
• How quickly can authority be revoked for one agent without disrupting unrelated services?
• Which scenarios have been tested against impact tolerances and recovery objectives?

Weak answers usually indicate that autonomy has been added to an existing journey without redesigning authority and evidence. Strong answers show a chain of responsibility from intent to ledger.

Adopt autonomy in bounded stages

Enterprises do not need to begin with autonomous execution. A staged path can establish evidence before authority expands.

The first stage lets an agent assemble information and recommend a payment while a person prepares and approves it. The second allows the agent to prepare a structured instruction that a person authorises through the usual controls. The third permits execution within a narrow mandate, with low limits, approved beneficiaries and immediate exception routing. Broader autonomy should depend on measured accuracy, control performance, reconciliation quality and successful resilience testing.

At every stage, the architecture should keep reasoning separate from authority. Better models may reduce ambiguity and improve orchestration, but they do not remove the need for deterministic policy, explicit consent, stable payment state and accountable recovery.

Agentic payments will be credible when organisations can explain not only what the agent intended, but why a specific instruction was allowed, which controls it passed and how the resulting movement of money was confirmed. That evidence begins with the boundary between intelligence and execution.

Footnotes

1. Bank of England, Financial Stability Report, July 2026, accessed 16 July 2026.
2. International Monetary Fund, How Agentic AI Will Reshape Payments, 24 April 2026.
3. Open Banking Implementation Entity, Domestic Payments Consents v3.1.2, accessed 16 July 2026.
4. Financial Conduct Authority, Operational resilience, updated 14 July 2026.