Open Banking for AI Agents · A Guide by Bugni Labs

Agentic open banking is the shift from a person approving a single data-sharing or payment action to an AI system that can plan and execute a sequence of financial actions within delegated authority. Autonomous consent is the governance layer that makes that safe: executable policy that decides, for every agent action, whether this actor may do this thing, to this account, for this purpose, at this moment, within the authority the customer granted and can revoke.

The core change is simple. Open banking consent stops being a one-time screen and becomes a runtime control surface. A customer may still grant access through a familiar consent journey, but the system behind that journey has to supervise repeated agent actions, changing context, risk thresholds, expiry, revocation, evidence, and escalation.

This guide is written for engineering leaders and senior engineers designing open-banking, payments, and account-information platforms for regulated financial services. It explains where existing PSD2-era consent models hold, where they strain under agentic execution, and how to design an architecture that keeps autonomy bounded, explainable, and auditable.

Why does agentic open banking matter now?

Open banking was designed around explicit consent, secure access, and regulated third-party roles. The UK Open Banking customer-experience guidance for account-information services says the consent journey should make clear why access is needed, what data is shared, how long access lasts, and how the customer can revoke it (Open Banking Standards, Consent for AIS). That model remains the foundation.

Agentic systems add pressure because they change the operational shape of consent. A budgeting app that reads account balances once a day is different from an agent that monitors spending, identifies unused subscriptions, compares alternatives, drafts cancellation requests, moves funds, and asks for approval only when a transaction crosses a materiality threshold. The customer may have delegated one intent, but the platform now sees many downstream decisions.

PSD2 already contains the legal architecture for consent, withdrawal, account-information access, payment-initiation access, evidence, and liability. The EBA single rulebook maps these across Articles 64, 66, 67, 72, and 73 of PSD2 (EBA PSD2 single rulebook). The challenge is that most implementation patterns reduce those duties to authentication events, consent records, and static scopes. That is not enough when an AI agent acts repeatedly inside a delegated mandate.

The near-term design question is not whether banks should allow unrestricted autonomous finance. They should not. The practical question is how to support semi-autonomous financial actions inside a policy envelope narrow enough to govern, broad enough to be useful, and observable enough to defend.

What is autonomous consent in financial services?

Autonomous consent is consent represented as enforceable policy rather than only as a stored record. The record still matters: it captures who granted authority, when, for what purpose, through which regulated journey, and with what expiry or renewal conditions. The policy is what turns that record into runtime control.

In a human-led open-banking flow, consent answers a bounded question: may this third party access these accounts or initiate this payment after this person approves? In an agentic flow, consent has to answer a repeated question: may this agent perform this specific action now, given the customer's stated intent, current risk context, account state, transaction value, counterparty, tool, model version, and previous actions in the same chain?

That distinction changes the data model. Consent needs to carry purpose, permitted tools, account boundaries, transaction limits, escalation triggers, renewal state, revocation status, and evidence requirements. It also needs a clear link to the acting agent. An agent that reads balance data, an agent that drafts payment instructions, and an agent that initiates a payment are different actors for control purposes even if they belong to the same product experience.

The safest model is a spectrum:

Human-in-the-loop: the agent proposes an action, and a person approves before execution.
Human-on-the-loop: the agent operates inside a low-risk envelope while humans monitor and intervene.
Human-as-architect: humans define the policy, constraints, evidence requirements, and escalation paths, then the agent operates within them.

Most regulated institutions should start in the middle. Let agents handle low-risk, reversible, well-understood actions. Keep high-value payments, ambiguous identity decisions, complaints, vulnerable-customer interactions, and novel policy interpretations under human approval.

How do PSD2 consent models strain under agentic execution?

The first strain is static scope. A consent that says an account-information service may read balances and transactions does not express why an agent is reading them, which downstream decision the read supports, or whether this read is still proportionate to the customer's delegated intent. The UK Open Banking standards describe duration and purpose as explicit consent parameters; an agentic implementation needs to enforce those parameters continuously, not just display them once.

The second strain is renewal and reauthentication. The Open Banking delegated SCA guidance explains the role of strong customer authentication and the 90-day account-information access pattern (Open Banking Standards, 90-day reauthentication and delegated SCA). For a human-led service, the expiry reminder is a product journey. For an agentic service, expiry is a hard runtime boundary. The agent must not continue using account data after access expires simply because it still has a plan in progress.

The third strain is attribution. When a person clicks a button, the evidence trail can connect the instruction to that person's action. When an agent interprets a customer mandate and chooses a sequence of actions, the platform must show the mandate, the policy check, the agent's reasoning context, the data accessed, the tool called, and the human escalation decision where one occurred. A consent record without decision evidence is too thin.

The fourth strain is continuous risk. Fraud, sanctions, affordability, and operational-resilience controls were often built around discrete events. An agent creates streams: repeated reads, proposed actions, intermediate artefacts, draft instructions, tool calls, retries, and exception paths. Screening once at the front door misses the behaviour that emerges in the chain.

The fifth strain is revocation. Consent must be revocable, but revocation in an agentic system is not only a UI state. It has to cancel queued actions, invalidate cached authority, stop scheduled jobs, revoke tool access, and produce evidence that downstream systems received the revocation.

What architecture supports agentic consent?

The architecture should treat consent as a governed domain, not as a property on an API token. Four patterns matter most.

Policy-based authorisation at every action. Every agent tool call should pass through a policy decision point. The input should include the consent artefact, customer intent, actor identity, account, action type, transaction value where relevant, risk score, expiry state, and current context. The output should be an allow, deny, or escalate decision with a reason code. This makes consent executable.

Event-driven orchestration for non-repudiation. Every consent grant, renewal, revocation, policy decision, tool call, escalation, and outcome should emit an event onto an ordered log. The event log is not only an integration mechanism. It is the evidence trail. This matches the same event-driven architecture discipline used in regulated screening and payments platforms: ordered facts first, downstream projections second.

Domain-aligned service boundaries. Consent, account access, payments, risk, customer communication, and agent orchestration should be separate bounded contexts with explicit contracts. A consent service should not know payment-routing internals. A payment service should not infer agent authority from a free-text instruction. Clear boundaries support audit, liability analysis, and change control. This follows domain-driven design, but the reason is regulatory as much as technical.

Reversible checkpoints. High-consequence actions should pass through checkpoints where a human can approve, deny, or modify the action without halting the entire customer journey. Reversibility is what makes semi-autonomy acceptable. A system can run faster when it can stop precisely.

The common mistake is to build agent orchestration first and retrofit consent enforcement later. That produces a system where policy is advisory. In regulated financial services, policy needs to be in the execution path.

How should the consent data model be designed?

A useful consent model separates four concepts that are often collapsed.

The customer grant records the customer's explicit consent: purpose, account set, data categories, duration, revocation path, and regulated disclosures. This is the artefact the customer understands.

The agent mandate translates the grant into permitted agent behaviour. It states which agent or agent class may act, which tools it may use, which actions are prohibited, which values trigger human approval, and which events must be retained as evidence.

The runtime decision records each policy evaluation. It should include the consent reference, mandate reference, input context, decision, reason, policy version, model version where relevant, and timestamp from a trusted source.

The action evidence records what happened after approval: API called, data read, payment instruction drafted or submitted, user notified, human decision captured, downstream failure received, or revocation processed.

This separation keeps the customer-facing grant stable while allowing policy and runtime controls to evolve. A customer should not need to approve a new consent every time an institution improves its risk model. But if the institution widens what the agent may do, changes tool access, or adds a new payment capability, the customer grant and the agent mandate must be reviewed together.

The model should also preserve absence. A missing expiry date, an expired consent, and an explicit indefinite mandate are not the same thing. A missing counterparty, an unverified counterparty, and a verified counterparty outside policy are not the same thing. Agentic systems fail quietly when they flatten those distinctions into strings and booleans.

How does governance change when agents act?

Governance moves from periodic review to runtime integrity. The central control is no longer a committee approving a design document. It is a platform that prevents an out-of-scope action at the moment it would take effect.

The first governance requirement is encoded scope. If the agent is not allowed to initiate payments, the payment-initiation tool should be unavailable. If the agent may initiate payments only below a threshold, the authorisation service should enforce the threshold, not rely on prompt wording. If the agent may read only a subset of accounts, the account-access layer should enforce that subset.

The second requirement is explainability at the action level. The evidence trail should answer: what did the customer authorise, what did the agent decide, what information did it use, what policy version approved it, what tool did it call, what happened, and who reviewed it if review was required? A generic transcript is not enough. The evidence must be structured and queryable.

The third requirement is escalation design. Human review should not be a catch-all error path. It should be deliberate: high value, low confidence, new counterparty, unusual pattern, expired mandate, ambiguous purpose, regulatory uncertainty, or irreversible effect. Each escalation should carry the context a reviewer needs to make a decision quickly.

The fourth requirement is lifecycle control. Prompt changes, tool additions, model upgrades, policy changes, and threshold changes can all alter the agent's behaviour. Treat them like software releases. Version them, test them, canary them where possible, and retain rollback. This is the practical face of AI-native engineering: AI participation is governed inside the delivery lifecycle, not treated as an external add-on.

What should banks build first?

Start with account-information use cases where the agent can create value without moving money. Examples include spending classification, cash-flow forecasting, subscription review, affordability evidence assembly, reconciliation support, and customer-facing summaries. These use cases still require consent discipline, but most actions are reversible or advisory.

The first production slice should have five properties:

The customer intent can be stated clearly.
The permitted actions fit into a narrow policy envelope.
Revocation can stop all future actions cleanly.
The evidence trail can be reconstructed end to end.
Human review is available for ambiguous cases.

Build the policy layer and event trail before adding more capable agents. A narrow agent with strong controls is more useful than a broad agent that cannot prove why it acted. Once the institution can show grant, mandate, decision, action, and revocation evidence for one workflow, it can widen the envelope gradually.

Payment-initiation use cases should come later. Begin with draft instructions and human approval. Then allow low-value, low-risk actions inside tight constraints. Treat counterparty changes, cross-border payments, unusual amounts, and vulnerable-customer contexts as mandatory escalation triggers until the evidence supports a wider envelope.

Which anti-patterns should teams avoid?

Consent as a checkbox. A customer seeing a consent screen does not prove the platform can enforce the consent during execution. The runtime path is what matters.

Prompt-based guardrails. A prompt that says "do not exceed the mandate" is not an authorisation control. The agent should be technically unable to exceed the mandate.

Shared agent identities. If multiple agents act through the same service account, attribution becomes weak. Each agent role needs a distinct workload identity and auditable tool permissions.

Silent cache reuse. Cached account data should carry the consent, purpose, retrieval time, and expiry state that justified the original access. Agents should not reuse stale data outside its authorised context.

Autonomous repair of regulated facts. An agent may normalise a known code or format. It should not invent missing identity, address, counterparty, or affordability data to make a workflow pass.

No revocation propagation. Revocation must invalidate scheduled tasks, queued tool calls, cached authority, and downstream access. A dashboard toggle without propagation is not revocation.

One autonomy level for every action. Balance enquiries, categorisation, subscription analysis, new payee creation, and payment initiation do not carry the same risk. The autonomy model should reflect that difference.

FAQ

What is agentic open banking?

Agentic open banking is open banking designed for AI systems that can plan and execute multi-step work inside delegated authority. Instead of a person approving every individual action, the customer grants a bounded intent and the platform enforces that intent as runtime policy. The agent can act only inside the consent, tool, risk, and escalation limits the institution has encoded.

How is autonomous consent different from normal PSD2 consent?

Normal PSD2 consent records what the customer approved for account-information or payment-initiation access. Autonomous consent adds continuous enforcement for repeated agent actions. It checks every action against purpose, scope, expiry, revocation, account, value, risk, and policy version before execution.

Can banks let AI agents initiate payments?

Banks can design toward agent-assisted payment initiation, but the safe starting point is staged. Let the agent draft or prepare instructions, route material actions to human approval, and allow autonomous execution only for low-risk actions inside explicit limits. New payees, high values, cross-border movement, vulnerable-customer context, and uncertain purpose should trigger review.

What evidence does a regulator need for an agentic consent flow?

The evidence should show the customer grant, the agent mandate, each policy decision, the data accessed, the tool called, the model or policy version used, the outcome, and any human review. It should also show revocation and expiry handling. A transcript alone is too weak because it is hard to query, compare, and reconcile with system events.

Where should an institution start?

Start with advisory or account-information workflows where actions are reversible and the policy envelope is narrow. Build consent records, mandate policy, action-level authorisation, event evidence, and revocation propagation for one workflow. Widen autonomy only after the institution can reconstruct the full chain for normal actions and exceptions.

Open Banking for AI Agents: Autonomous, Scoped Consent