Open Banking Under PSD3: The New AML Obligations for AISPs and PISPs

VOVE ID helps AISPs and PISPs absorb the compliance weight that PSD3 formalizes — in markets where regulators no longer read open-banking firms as data-only. On paper PSD3 clarifies. In practice it closes a gap that many founders assumed would stay open indefinitely.

This article covers what open-banking firms now need operationally: where AML obligations actually sit for AISPs and PISPs, how the two risk models differ, and what happens when a platform sees suspicious behavior but has no path to act on it. For the underlying EU AML framework governing these obligations, see our AML Requirements Explained 2026.

What PSD3 does to AISP and PISP obligations

Under PSD2, many founders treated AISPs as "view-only" products and PISPs as "connectivity" products. That framing doesn't hold now.

An AISP may not move funds, but it can see patterns across linked accounts that no single bank sees in one place. A PISP doesn't just observe risk — it triggers payment flows in real time. Once a product sits that close to account data and payment behavior, supervisors look beyond consent screens and API uptime. They ask how customer identity is verified, how fraud and financial-crime signals are escalated, how outsourcing is governed, and how suspicious behavior is documented.

The EU's 28 June 2023 payments package — PSD3 and the Payment Services Regulation — was designed to modernize PSD2 because the market had changed, fraud had become more sophisticated, and open banking had become core payments infrastructure. In parallel, the EU AML framework requires obliged entities to identify and verify clients, monitor transactions, and report suspicious activity. The practical result is that the payment-services perimeter and the AML perimeter now have fewer gaps between them than they did under PSD2. Open-banking firms are expected to behave like supervised payment operations — not lightweight data tools.

AML where there was barely any AML

The EU AML framework's baseline is clear: customer due diligence, transaction monitoring, and suspicious transaction reporting. For open-banking firms, the operational question is how those duties appear in a product that was originally sold as fast, modular, and API-first.

For an AISP, the risk is visibility-led. Account cycling, unusual funding sources, mule-account behavior, repeated consent resets across institutions — these signals may surface in the AISP's platform before they surface anywhere else. If they do and nobody owns them, the firm has intelligence without control. That combination is what supervisors now ask about.

For a PISP, the risk is execution-led. The firm is closer to beneficiary risk, sanctions exposure, payment velocity, merchant abuse, refund loops, and account-takeover behavior. The window for judgment is shorter, and the cost of acting late is higher because the payment may already be initiated.

A defensible open-banking AML stack needs:

• customer identification and remote KYC tied to the consent record
• risk scoring that combines onboarding, device, behavioral, and payment-context signals
• sanctions, PEP, and adverse-media checks where the license model and corridor require them
• alert routing, case ownership, and audit logs showing who reviewed what and when
• a suspicious-activity escalation path that exists before it is needed

The failure mode: when an AISP sees laundering and has no SAR pipeline

A Dutch AISP serves SMB treasury teams. It aggregates accounts from several banks and notices a pattern across one customer: repeated round-amount inflows, same-day fragmentation to newly linked accounts, and rapid consent re-authentication whenever an account gets disconnected.

The product team sees the anomaly. The data team can chart it. The customer-success team knows the account is sensitive. But there is no case owner, no documented escalation threshold, no suspicious-activity workflow, and no route into a formal filing decision. The issue sits unresolved for two days while the customer continues operating.

That is the modern failure. Not missing data. Missing control ownership.

The result is rarely limited to one alert. A bank partner asks whether the platform is surfacing risky behavior without acting on it. A supervisor asks how governance works when open-banking data points to financial crime. "We are only a data layer" is not a viable answer once the platform demonstrably has the data and chose not to act.

How VOVE ID gives AISPs and PISPs a PSD3-grade compliance stack

VOVE ID connects onboarding, monitoring, review, and reporting in one operating system rather than leaving teams to stitch them together under regulatory pressure.

For AISPs, customer identity, screening, account-linking events, and monitoring signals live in one case file. When a pattern looks suspicious, the reviewer sees the consent history, linked entities, prior alerts, and the exact signal path that triggered review — not a collection of disconnected logs.

For PISPs, the same stack adds real-time controls around payment initiation: sanctions screening, beneficiary checks, risk rules, velocity triggers, manual-review fallbacks, and an audit trail that explains why a payment was allowed, stepped up, or blocked.

The difference between an AISP and a PISP control design matters here. Visibility-heavy operations need strong escalation and case management. Execution-heavy operations need real-time decisioning close to the payment. Those are not the same architecture — but both need to exist before a supervisor or bank partner asks for them.

Checklist

• Map which signals your AISP or PISP platform sees before assuming lightweight operations
• Separate visibility risk (AISP) from execution risk (PISP) — they require different control designs
• Tie customer identification, consent records, and monitoring events into one reviewable file
• Define who owns alert review, escalation, and suspicious-activity decisions before the first incident
• Review outsourcing and bank-partner dependencies before scale exposes the gaps

FAQ

Does PSD3 itself create every AML obligation for AISPs and PISPs?

No. PSD3 and the EU AML framework work together. The operational result is that open-banking firms are expected to operate like supervised payment businesses, not passive data services.

Is an AISP risk model basically the same as a PISP risk model?

No. AISPs are visibility-heavy — the risk is in what the platform sees and fails to escalate. PISPs are execution-heavy — the risk is in what the platform triggers and fails to screen. Both need AML controls, but the design differs.

What trips founders up first?

Not missing rules — missing ownership. The signals exist. The problem is that nobody owns the review queue, the filing decision, or the partner escalation path. That gap is what surfaces first in supervisory conversations.

This article is intended for general informational purposes only and does not constitute legal, financial, or regulatory advice. KYC/KYB/AML requirements may vary depending on jurisdiction, industry, and specific business circumstances. For up-to-date and binding compliance obligations, readers should refer to the relevant regulatory authorities or consult qualified professionals.