Open banking in the Netherlands — AISP, PISP and PSD2 access
Open banking in the Netherlands runs on the PSD2 framework with a uniquely mature domestic payments ecosystem around it. Account-Servicing Payment Service Providers (ASPSPs) — the banks holding customer accounts — must expose a regulated interface to AISPs and PISPs. The Dutch retail-payments market is dominated by a domestic account-to-account scheme that interoperates with PSD2 open-banking infrastructure. The dedicated-interface vs modified-customer-interface choice, the SCA exemptions, the consent management and the upcoming PSD3 / PSR redesign all matter. This piece walks through what is live and what is changing.
1. The PSD2 framework in the Netherlands
PSD2 is transposed into Dutch law through the Wet op het financieel toezicht (Wft). Substantive open-banking obligations sit in the Wft alongside the broader PI authorisation framework — see our PI licence Netherlands piece.
Three regulated roles:
- ASPSP — the account-holding PSP (credit institution, EMI or PI with account-servicing)
- AISP — Account Information Service Provider, providing aggregated account views
- PISP — Payment Initiation Service Provider, initiating payments from ASPSP accounts
2. The Dutch domestic context
The Netherlands has one of Europe’s most established account-to-account payment ecosystems. Dutch consumers expect:
- Frictionless online payment initiation directly from bank accounts — the dominant retail e-commerce flow
- SCA delivered through the bank’s existing customer authentication (banking app, hardware token)
- Real-time confirmation and settlement for most consumer flows
- High interoperability between PSPs without manual reconciliation
Open banking under PSD2 sits alongside this ecosystem. AISPs and PISPs add data and initiation capabilities on top of the existing account-to-account rails. The Dutch market’s high baseline of native digital banking sets a high bar for PSD2-driven services.
3. Dedicated interface vs modified customer interface
For the dedicated interface to satisfy Article 32 of the RTS, the ASPSP must demonstrate:
- Performance comparable to the customer-facing online banking
- A documented contingency mechanism
- EBA-register registration
- Published performance data — DNB publishes per-ASPSP metrics
4. SCA and exemptions
PSD2 Article 97 requires two-factor SCA on online payment-account access and electronic payments. The EBA RTS defines exemptions (trusted-beneficiary, recurring-transaction, low-value, corporate-payment, transaction-risk analysis). Dutch ASPSPs implement SCA through their existing customer-authentication infrastructure — typically banking app + biometric, or banking app + hardware token, with TRA scoring layered on top.
5. Customer-consent management
The customer’s consent is the legal basis for AISP / PISP access to ASPSP data. The current PSD2 requirements:
- Explicit, captured separately
- Scoped — defined data fields, accounts, time horizon
- Revocable at any time through ASPSP and AISP / PISP
- Renewable every 180 days (subject to PSD3 change)
The PSR proposal in the PSD3 / PSR package introduces a standardised permission dashboard at the ASPSP. Dutch ASPSPs have built consent-management UIs ahead of the PSR; the change codifies what is already largely in place.
6. DNB’s view on dedicated-interface performance
DNB monitors dedicated-interface metrics:
- Latency benchmarks (dedicated interface vs customer interface)
- Uptime and availability (published monthly per ASPSP)
- Error-rate transparency
- SCA-completion rate
- Fallback-invocation rate (should be near zero)
Poor metrics invite supervisory dialogue and, in extreme cases, an obligation to provide the fallback permanently.
7. What PSD3 / PSR will change
The PSR proposal redesigns the open-banking regime:
- Standardised permission dashboard at ASPSPs
- Clearer data-scope rules and derivative-use constraints
- Performance SLAs codified
- Fraud-allocation rules adverse for PSPs failing VoP or spoofing-fraud detection
- Direct PSP access to settlement systems for non-banks
The Financial Data Access Regulation (FIDA) extends open-data principles beyond payments — architecturally related but a separate file.
8. The IPR overlay
The IPR introduces Verification of Payee on every SEPA credit transfer, including PISP-initiated payments. The 10-second SCT Inst envelope must accommodate VoP, sanctions screening and PISP-initiation logic. Dutch ASPSPs and PISPs have built the VoP integration alongside their SCT Inst migration.
9. FAQ
Do I need authorisation to operate as an AISP in the Netherlands?
Yes — AISPs operate under a registration regime at DNB. The file is lighter than full PI authorisation but conduct, ICT and AML obligations apply.
Can my dedicated interface share infrastructure with my customer-facing API?
No. The dedicated interface must be technically separate, with its own performance benchmarks and access controls. Shared back-end services with separate endpoints and separate logging is acceptable.
What happens if my dedicated interface goes down?
Article 33 RTS requires a contingency mechanism allowing access via the modified-customer-interface route. If the dedicated interface fails persistently, DNB can require the firm to permanently provide the contingency.
How does the Dutch domestic payment ecosystem interact with PSD2?
PSD2 sits on top of the existing rails. PISP-initiated payments use the underlying account-to-account infrastructure; AISP data aggregation accesses the bank’s API. The two layers coexist; the bank’s native channels remain primary for most consumers.
How does VoP under IPR interact with PISP flows?
VoP applies to every SEPA credit transfer regardless of initiation channel. PISP-initiated payments are subject to VoP at the payer’s PSP. See our VoP piece.
What is the consent-renewal cadence under PSD2?
180 days under current PSD2 RTS. The PSR proposal will likely change this; track the PSD3 / PSR file.
10. What to do, today
- If you operate as an ASPSP, audit your dedicated-interface performance metrics; DNB publishes them.
- If you operate as an AISP or PISP, build for the Dutch baseline expectation of frictionless customer journeys.
- Design consent management against PSD2 today and PSR-compliant patterns tomorrow.
- Track the PSD3 / PSR file for the permission-dashboard and performance-SLA changes.
- Integrate VoP and sanctions-screening into the PISP-initiated payment flow within the IPR envelope.
Related: PI licence in the Netherlands · Open banking in France · PSD3 and the PSR tracker
