AI Agent Governance in Banking: PSD2, PSD3 and the EU AI Act Overlap

Why AI Agent Governance Is Now a Banking Priority

AI agents—systems that can plan, decide, and execute tasks with limited human input—are moving quickly from pilots to production in banking. They are being embedded in customer service, fraud operations, credit decisioning, AML investigations, and payments orchestration. At the same time, the regulatory perimeter is expanding:

• PSD2 continues to shape access-to-account, authentication, consent, and outsourcing expectations across payments.
• PSD3 (and the broader payments reform package) is expected to tighten fraud controls, clarify responsibilities, and strengthen operational and consumer protections.
• The EU AI Act introduces a lifecycle governance model for AI, with special focus on high-risk uses (notably creditworthiness and similar assessments).

The practical challenge for banking leaders is overlap: the same AI agent may touch payments, authentication, customer data, and credit decisions—triggering multiple regimes. This guide shows how to build an AI agent governance program that aligns to the shared requirements and reduces duplicated controls.

---

Step 1: Map Your AI Agents to Regulated Banking Activities

Start by inventorying AI agents as systems that take actions, not just “models.” In banking, the risk is often in what the agent can do (initiate payments, block accounts, request additional authentication, approve limits), not only how it predicts.

Create an inventory with these fields:

• Agent name and business owner
• Purpose and user population (retail, SME, corporate, internal ops)
• Actions it can execute (read-only, recommend, draft, execute, approve)
• Channels (mobile, web, call center, back office)
• Data access scope (account data, transaction history, sensitive data categories)
• Decision impact (customer rights, financial access, pricing, eligibility)
• Third parties involved (vendor models, cloud tools, outsourced processes)
• Geographies (EU vs non-EU operations, cross-border processing)

Then label each agent by the regulated activity it touches:

• Payments initiation / payment account access (PSD2/PSD3 relevance)
• Strong Customer Authentication (SCA) and fraud controls (PSD2/PSD3 relevance)
• Customer support with account data exposure (PSD2/PSD3 + privacy + security)
• Creditworthiness / underwriting / limit management (EU AI Act high-risk likely)
• AML/fraud investigations (often not AI Act high-risk by default, but still governance-heavy)

This mapping tells you where overlap will bite and which controls can be shared.

---

Step 2: Classify Each Agent’s Regulatory Risk Profile (One Taxonomy)

Instead of maintaining separate “PSD” and “AI Act” classifications, adopt one internal taxonomy that can be filtered per regime.

A practical three-layer classification:

1. Impact tier (customer and financial impact)

   • Tier 1: Informational/assistive, no customer impact
   • Tier 2: Recommendations that influence staff decisions
   • Tier 3: Automated decisions/actions that affect customers or money movement

2. Scope tier (data and access)

   • Narrow: limited datasets, no account access
   • Standard: account/transaction data read access
   • Elevated: write access, payment initiation, authentication triggers, account blocks

3. Regulated use flags

   • Payments access/initiation flag (PSD2/PSD3)
   • SCA/fraud intervention flag (PSD2/PSD3)
   • Creditworthiness/eligibility flag (AI Act high-risk likely)
   • Customer rights impact flag (complaints, disputes, adverse outcomes)

From this, define “governance intensity” levels (e.g., Basic/Standard/Enhanced) that determine required controls.

---

Step 3: Design Controls Around the Overlap (One Control Set, Multiple Outputs)

The most efficient approach is to implement a single control library that can demonstrate compliance across PSD2/PSD3 and the EU AI Act.

Key overlapping control domains:

1) Identity, Consent, and Purpose Boundaries

For agents accessing account data or acting on customer instructions:

• Consent capture and traceability: log when consent was obtained, what scopes were granted, and how they were used.
• Purpose limitation enforcement: technically prevent “helpful” but non-permitted uses (e.g., using payments data for unrelated profiling).
• Customer instruction integrity: ensure the agent cannot reinterpret intent without confirmation for sensitive actions.

Actionable implementation:

• Require explicit confirmation steps for payment initiation, payee creation, and limit changes.
• Use policy-based access control tied to consent scopes and user roles.

2) Authentication and Step-Up Triggers (SCA-Aware Agents)

If an agent influences authentication (e.g., deciding to step up, reroute flows):

• Define approved SCA triggers and prohibit the agent from inventing new ones.
• Enforce human-designed guardrails: thresholds, velocity rules, device signals, geo anomalies.
• Maintain audit-grade logs for authentication decisions and overrides.

Actionable implementation:

• Separate “risk scoring” from “auth decision”: the agent may recommend, but a deterministic policy engine executes SCA decisions unless formally approved.

3) Explainability and Customer Communications

PSD-style consumer protections and AI Act transparency both benefit from clear reasoning artifacts:

• Produce reason codes for customer-impacting outcomes (declines, holds, additional checks).
• Maintain decision trace: inputs used, rules invoked, model/agent version, and human overrides.
• Provide customer-facing explanations that are accurate and non-technical.

Actionable implementation:

• Maintain a reason-code catalog mapped to operational playbooks and complaint handling.

4) Data Governance and Security (Model + Agent + Tooling)

Agents often use tools (search, code execution, payment APIs). Control the whole chain:

• Data minimization: only necessary data is retrieved into agent context.
• Context hygiene: prevent sensitive leakage into prompts, logs, analytics, or vendor telemetry.
• Secrets management: no credentials in prompts; use scoped tokens and short-lived credentials.
• Segregation of duties: developers cannot unilaterally expand an agent’s privileges.

Actionable implementation:

• Implement prompt and output filtering for sensitive fields.
• Use tool allowlists and restrict high-risk tools (payment initiation, account freezes) to enhanced governance tier.

---

Step 4: Build an Agent Lifecycle That Matches Regulatory Expectations

Regulators will expect governance from design through monitoring. Implement a lifecycle with clear gates.

Gate A: Use-Case Approval (Before Build)

Checklist:

• Define regulated flags (payments, SCA, creditworthiness).
• Set automation level (recommend vs execute).
• Specify customer impact and fallback process.
• Identify third-party dependencies and outsourcing implications.

Deliverables:

• Use-case risk assessment
• RACI (business owner, compliance, risk, security, model risk)

Gate B: Design Review (Before Pilot)

Checklist:

• Threat model (prompt injection, tool abuse, data exfiltration, privilege escalation)
• Control design (consent checks, SCA boundaries, reason codes)
• Human-in-the-loop requirements (who approves what and when)

Deliverables:

• Control mapping to internal library
• Test plan (functional + security + fairness/quality where relevant)

Gate C: Validation (Before Production)

Checklist:

• Pre-production testing across “known bad” scenarios (fraud scripts, ambiguous instructions)
• Robustness testing (edge cases, adversarial prompts)
• Logging and audit readiness (traceability and versioning)

Deliverables:

• Validation report
• Model/agent card (internal) documenting limitations and intended use

Gate D: Ongoing Monitoring (After Launch)

Checklist:

• Drift monitoring (behavior changes, tool invocation patterns)
• Incident monitoring (misroutes, unauthorized actions, leakage)
• Complaint and dispute linkage (tie customer cases to agent decisions)

Deliverables:

• Monthly governance dashboard
• Change control records for prompts, tools, policies, model upgrades

---

Step 5: Put Hard Guardrails on “Agency” (Prevent Runaway Automation)

Banking AI agents should be designed with bounded authority. Practical guardrails:

• Tiered permissions: read-only → draft → recommend → execute, with escalation.
• Dual control for money movement: for certain thresholds or new payees, require a second factor (human or policy-based approval).
• Tool sandboxing: separate environments for test vs production; no cross-over tokens.
• Action rate limits: cap number of payment attempts, account updates, or customer communications per time window.
• Kill switch: instant disablement of tools or entire agent, with predefined criteria and owner.

These controls reduce operational risk and create a clear compliance narrative: the agent is powerful, but not unconstrained.

---

Step 6: Prepare Evidence Once, Reuse It Across PSD and the AI Act

Your objective is an “evidence pack” that can satisfy multiple audits and supervisory questions.

Build standardized evidence artifacts:

• Agent inventory with regulated flags and automation level
• Control mapping showing which controls apply to each agent
• Audit logs demonstrating consent checks, SCA triggers, and customer-impact decisions
• Validation results (robustness, security tests, outcome quality)
• Change management records (prompt/tool/model versions)
• Incident playbooks and post-incident reports

Operational tip: create an internal “governance folder” per agent with a fixed template so audits don’t become bespoke archaeology.

---

Step 7: Align Operating Model—Who Owns What?

AI agent governance fails when ownership is unclear. Use a simple operating model:

• Business owner: accountable for outcomes and customer impact
• Risk/compliance: sets requirements, reviews high-impact changes
• Security: approves tool access, secrets, and monitoring
• Model risk management (MRM): validates models/agents based on tier
• Operations: runs workflows, handles exceptions and disputes
• Vendor management: governs third-party tools and outsourcing clauses

Set a rule: no agent goes live without a named accountable owner and an on-call path.

---

A Practical Starting Blueprint (First 30–60 Days)

1. Inventory and classify all existing AI agents and near-term proposals.
2. Adopt a unified control library covering consent, SCA boundaries, traceability, security, and change control.
3. Implement bounded authority (permissions, tool allowlists, kill switch) for every agent.
4. Stand up lifecycle gates with templates for approval, validation, and monitoring.
5. Create reusable evidence packs and a dashboard for governance reporting.

Done well, this approach turns PSD2/PSD3 and EU AI Act overlap into an advantage: fewer duplicated controls, clearer accountability, and safer automation that regulators—and customers—can trust.