PSD3, fraud liability, and the limits of AI agent governance

At a glance

What this is: This interview examines PSD3, bank liability for impersonation scams, and the emerging gap created by AI agents that can make payments without fitting current fraud and authentication assumptions.

Why it matters: It matters because IAM, fraud, and payments teams will need to decide how identity proofing, transaction controls, and delegated authority work when the actor is no longer a person.

Context

PSD3 is tightening the policy expectations around fraud prevention in European payments, but the article's real governance issue is narrower and harder: current controls are still built around a human customer signal. Once payment initiation shifts to delegated software, the assumptions behind strong customer authentication, behavioural fraud detection, and liability assignment start to diverge.

OneSpan's interview frames that tension through bank impersonation scams and the question of who carries responsibility when fraud originates outside the bank itself. The article also points to AI agents as an upcoming gap in the legislation, because automated actors can make purchases and payments without the behavioural patterns that fraud teams traditionally monitor.

Key questions

Q: What breaks when AI agents can initiate payments without verified consent?

A: When consent is not verified, the trust chain becomes weak at the exact point where payment decisions are made. Issuers and networks lose clear evidence of authorisation, tokens can be used beyond intended limits, and later disputes become difficult to adjudicate. The result is weaker accountability, higher fraud exposure, and less confidence in agent-driven commerce across schemes and issuers.

Q: Why do bank impersonation scams matter more under PSD3 than under older payment rules?

A: Because PSD3, as described in the article, moves liability toward the bank when impersonation of the bank or its staff leads to fraud. That changes the governance burden from after-the-fact reimbursement to earlier fraud prevention, evidence of control, and clearer classification of where the scam began.

Q: What are the main mistakes teams make when governing delegated payment activity?

A: The biggest mistake is treating customer authentication as if it automatically authorises any software acting for that customer. Teams also fail when they keep behavioural fraud rules tied only to human interaction and do not define separate limits, approval gates, and monitoring for delegated execution paths.

Q: What should payment teams do when fraud originates outside the banking app?

A: They should treat the payment app as one control point in a wider deception chain, not the whole problem. That means tracing social media, messaging, telecom, and handoff channels back to the payment event, then assigning responsibility based on where the impersonation and authority abuse actually occurred.

Technical breakdown

How PSD3 changes liability for bank impersonation scams

PSD3, as described in the interview, moves European payments toward bank liability when a fraudster impersonates a bank employee or the bank as an institution. That matters because liability is not just a reimbursement rule. It changes which events banks must prevent, how they classify scam origin, and how they evidence control effectiveness across the payment flow. The important technical point is that the fraud case is not limited to the payment rail itself. It depends on identity deception that begins earlier, often on social media or via messaging, and later manifests as an authorised payment. Practical implication: teams need to map identity-deception sources to payment controls, not just monitor the transaction layer.

Practical implication: align fraud monitoring to the whole deception chain, not only the payment event.

Why AI agents break human-based fraud detection models

The interview's core warning is that AI agents are not just another user type. They can perform purchases and payments on behalf of a person, which means the behavioural cues fraud teams use today may disappear or become unreliable. In a human model, patterns such as typing rhythm, session behaviour, device familiarity, and response timing can support fraud signals. With delegated software, the payer may be a person in intent but an autonomous execution path in practice. That creates a control mismatch between authorisation, authentication, and transaction risk scoring. Practical implication: fraud controls that depend on observing human behaviour need a separate model for delegated execution.

Practical implication: build a distinct fraud model for delegated execution paths, not human behavioural monitoring.

Strong customer authentication is not the same as delegated authority

The article highlights a structural gap between authenticating a customer and governing an AI agent acting for that customer. Strong customer authentication proves the person is who they claim to be, but it does not automatically define what software acting on their behalf may do, when it may do it, or under what limits. That is an identity and authority problem, not just an authentication problem. In governance terms, the approval boundary moves from user login to task-scoped execution. Practical implication: the control stack must distinguish identity proofing, authorisation scope, and delegated action rights instead of collapsing them into one checkpoint.

Practical implication: separate identity proofing from delegated action rights in payment governance.

NHI Mgmt Group analysis

PSD3 is shifting fraud liability, but the deeper issue is identity accountability across the payment chain. The article shows that banks may become liable for bank impersonation scams even when the initial deception starts outside the banking application. That means the governance question is no longer confined to transaction monitoring, but extends to where identity influence begins and ends across channels. Practitioners should treat liability as a signal that identity assurance now spans messaging, payment initiation, and fraud response.

AI agents expose an assumption that payment governance was built for human-paced decisions. That assumption fails when the actor can make purchases and payments without a person directly observing each step. The implication is not simply more controls, but a rethink of which part of the workflow is being authenticated, which part is being authorised, and which part is being delegated. Current fraud programmes will struggle if they keep treating delegated execution as if it were ordinary customer activity.

Strong customer authentication does not solve delegated authority. The article implicitly separates proving a user from governing what software may do on that user's behalf. That is a named governance gap: delegated payment authority. It matters because the same authentication event can support very different execution rights depending on the agent or service acting next. Practitioners should stop treating authentication strength as a proxy for action scope.

Bank impersonation scams show that fraud prevention and identity governance are converging. The interview makes clear that fraud origin, liability, and authentication design are now part of the same control conversation. For financial services teams, the practical consequence is that fraud engineering, IAM, and payments operations can no longer design in separate silos. The field is moving toward integrated authority models that must account for human customers, service flows, and delegated software together.

The next regulatory gap will likely be agent identity, not just transaction validation. PSD3 is framed as a current response, but the article explicitly points to AI agents as an unresolved issue for future legislation. That tells us the market has not yet built a common governance model for software that initiates value transfer on behalf of a person. Practitioners should expect the next wave of controls to focus on delegated actor classification and constraint enforcement.

From our research library:

• U.S. fraud losses are projected to reach $40 billion by 2027.

What this signals

Delegated payment authority is the governance gap PSD3 exposes. Payment security has traditionally assumed that identity and intent stay bound to a human user at the moment of authorisation. Once AI agents can initiate transactions, practitioners need separate policy for delegation scope, approval boundaries, and accountability across the payment chain.

For financial services teams, the practical signal is that fraud and IAM can no longer be managed as adjacent disciplines. Identity proofing, behavioural monitoring, and transaction controls now need a shared model for who or what is actually acting.

For practitioners

• Map impersonation scenarios to the full fraud chain Trace where a bank impersonation scam starts, how it reaches payment initiation, and which control owner is accountable at each stage. Use that map to separate channel deception from transaction execution.
• Define a delegated payment authority model Specify what an AI agent may do, which payment types it may access, and what approval or constraint logic applies before execution. Do not rely on the customer's login state as the only authorisation signal.
• Review fraud signals that depend on human behaviour Identify any detection logic built on user cadence, typing, device familiarity, or session behaviour, then determine how it fails when a software agent performs the action instead of a person.
• Separate authentication from action scope Document where strong customer authentication ends and delegated execution begins, then set explicit policy for task scope, payment limits, and re-approval thresholds.

Key takeaways

• PSD3 is pushing bank impersonation scams into a clearer liability framework, but the operational burden shifts earlier in the control chain.
• AI agents create a distinct governance problem because the usual human behaviour cues used in fraud detection may not exist.
• The control gap is not only authentication strength, but the absence of a separate model for delegated payment authority.

Key terms

• Delegated Payment Authority: A governance model in which a non-human actor can initiate or complete a payment on behalf of a person or system. The key issue is not automation alone, but whether the actor has independent execution capability that needs separate identity, audit, and accountability controls.
• Bank Impersonation Scam: A fraud pattern in which the attacker pretends to be the victim's bank or a bank employee to influence a payment decision. The control problem is not only payment security but trust validation, because the victim is being manipulated through an apparently legitimate identity channel.
• Strong Customer Authentication: A regulated authentication requirement that demands more than a single password or code. Under PSD2, it requires at least two factor types and must support the payment context, so the approval is tied to the specific transaction rather than a reusable login event.
• Fraud Liability: The assignment of financial responsibility when a payment scam succeeds. In governance terms, liability shapes which organisation must absorb losses, but it also reveals where control ownership, evidence, and preventative measures are expected to exist.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.