Skip to content
ACPR · France

Open banking in France — RIB, AISP / PISP and the consent dashboard

Fintech Passport
June 21, 2026 · 6-min read
Open banking in France — RIB, AISP / PISP and the consent dashboard

Open banking in France runs on the PSD2 framework with a layer of French-specific operational standards on top. Account-Servicing Payment Service Providers (ASPSPs) — the banks holding customer accounts — must expose a regulated interface to authorised third-party providers (Account Information Service Providers, AISPs; Payment Initiation Service Providers, PISPs). The choice between a dedicated interface and a modified customer interface, the Strong Customer Authentication (SCA) exemptions, the customer-consent dashboard, and the upcoming PSD3 / PSR redesign all matter for any firm operating in France. This piece walks through what is live today and what is changing.

1. The PSD2 framework in France

PSD2 is transposed into French law through the Code monétaire et financier and the Ordonnance n° 2017-1252. The substantive open-banking obligations sit in Articles L.522-1 and following alongside the broader PI authorisation framework — see our PI licence France piece.

Open banking introduces three regulated roles:

  • ASPSP — Account-Servicing Payment Service Provider, the holder of the customer’s payment account (typically a credit institution, EME or EP with account-servicing)
  • AISP — Account Information Service Provider, providing aggregated views of accounts the customer holds elsewhere
  • PISP — Payment Initiation Service Provider, initiating payments from the customer’s account at the ASPSP

AISPs operate under registration; PISPs under authorisation. Both access ASPSP accounts under the EBA RTS on SCA and common and secure communication.

2. The RIB and the customer-side identification flow

French customers typically share their RIB (Relevé d’Identité Bancaire) — see our French IBANs piece — when granting access to a third-party provider. The RIB contains the IBAN and the BIC; the AISP / PISP uses this to identify the ASPSP and route the access request.

The French RIB flow is operationally embedded in customer journeys: customers expect to share a RIB rather than type an IBAN, and the AISP / PISP flow is built around RIB ingestion. This is a French-market specific that international providers entering France often underestimate.

3. Dedicated interface vs modified customer interface

Each ASPSP chooses between two compliance routes for the access obligation:

  • Dedicated interface — a purpose-built API for AISP / PISP access, separate from the customer-facing online banking. This is the most common choice in France for any meaningful ASPSP. Requires registration with the EBA register of dedicated interfaces, performance SLAs, and a fallback mechanism.
  • Modified customer interface — the AISP / PISP accesses the same interface the customer uses, identifying itself as a third-party provider. Permitted under the RTS but rare in practice for any ASPSP with capacity to build an API.

4. SCA and its exemptions

Strong Customer Authentication under PSD2 Article 97 requires two-factor authentication on online payment-account access and electronic payments. The EBA RTS on SCA defines the exemptions:

  • Trusted-beneficiary exemption — the payer’s PSP can waive SCA for transfers to a payee the customer has whitelisted
  • Recurring-transaction exemption — for repeated transfers of the same amount to the same payee
  • Low-value exemption — for cumulative transactions below a threshold
  • Corporate-payment exemption — for payments initiated by corporate users on dedicated processes
  • Transaction-risk analysis exemption — for transfers under thresholds where the PSP’s TRA scoring is below the regulated fraud-rate benchmark

For AISP access specifically, the customer must perform SCA at the start of the access journey, with a defined session-validity window thereafter under Article 10 RTS.

The customer’s consent is the legal basis for the AISP / PISP to access ASPSP data. The consent must be:

  • Explicit — captured separately from any product or service onboarding
  • Scoped — defined data fields, accounts, time horizon
  • Revocable — at any time, through the ASPSP and through the AISP / PISP
  • Renewable — current rules require renewal every 180 days (subject to PSD3 changes)

The PSR proposal in the PSD3 / PSR package includes a standardised consent dashboard at the ASPSP where customers see all active third-party permissions and can revoke them in one click. This becomes a regulated UI obligation, not a market-led add-on.

6. ACPR’s view on performance

ACPR has been one of the more demanding EU regulators on dedicated-interface performance. Recurring focus areas:

  • Latency benchmarks — dedicated interface vs the bank’s customer interface
  • Uptime and availability — published monthly per ASPSP
  • Error-rate transparency — categorised by error type
  • SCA-completion rate — proxy for customer-experience quality
  • Fallback-invocation rate — should be near zero for any well-built dedicated interface

Poor metrics are not just a market-perception issue; they invite supervisory dialogue and, in extreme cases, an obligation to provide the fallback.

7. What PSD3 / PSR will change

The PSR proposal materially redesigns the open-banking regime:

  • Standardised permission dashboard at the ASPSP — uniform UI obligation across the EU
  • Clearer data-scope rules — what fields an AISP can access, derivative-use constraints
  • Performance SLAs codified — currently best-practice; becomes a regulatory standard
  • Fraud-allocation rules — adverse for the PSP that fails to perform VoP or that misses spoofing-fraud detection
  • Direct PSP access to settlement systems — non-bank PSPs in scope

The Financial Data Access Regulation (FIDA) extends open-data principles beyond payments to insurance, savings, mortgages and pensions. A separate file but architecturally related.

8. FAQ

Do I need an authorisation to act as an AISP in France?

Yes — AISPs operate under a registration regime at ACPR. The file is lighter than full PI authorisation but the conduct, ICT and AML obligations apply. See our PI licence France piece for the AIS-specific path.

Can my dedicated interface be the same as my customer-facing API?

No. The dedicated interface must be technically separate from the customer-facing channel, with its own performance benchmarks and access controls. Sharing infrastructure but exposing separate endpoints with separate logging is acceptable.

What happens if my dedicated interface goes down?

Article 33 RTS requires a contingency mechanism allowing AISPs / PISPs to access via the modified-customer-interface route during the outage. If the dedicated-interface fails persistently, ACPR can require the firm to permanently provide the contingency.

How does the customer-consent renewal work?

Under current PSD2 RTS, consent renewal is required every 180 days. The PSR proposal will likely change this; firms should follow the file.

Does the RIB share customer credentials?

No. The RIB contains the IBAN and BIC — identifiers — not credentials. Customer authentication happens separately through SCA at the ASPSP.

How does VoP under IPR interact with open banking?

VoP applies to SEPA credit transfers regardless of initiation channel. A PISP-initiated payment is subject to VoP at the payer’s PSP. See our VoP piece.

9. What to do, today

  • If you operate as an ASPSP, audit your dedicated-interface performance metrics; ACPR publishes them and supervisory dialogue follows from poor numbers.
  • If you operate as an AISP or PISP, build the RIB ingestion flow into your French customer journey.
  • Design the customer-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 10-second envelope.

Related: PI licence in France · Verification of Payee under IPR · PSD3 and the PSR tracker

Related reads.