Open Banking in France: what PSD2 actually lets you automate in 2026

Every few weeks a prospective customer asks a version of the same question in slightly different words: can Dibein move money, and if not, why not, and how do we know. It's a fair question to ask of any tool that connects to a bank account, so it's worth explaining properly rather than pointing at a badge in a footer.

Two different licenses, two very different capabilities

The EU's second Payment Services Directive, PSD2, and its French implementation created two distinct categories of regulated third-party provider that can access a bank account with the customer's consent, without going through the bank's own interface. An Account Information Service Provider, AISP, can read balances and transaction history. A Payment Initiation Service Provider, PISP, can trigger a payment out of the account. These are separate authorizations, separate risk profiles, and — critically for anyone evaluating a vendor — separate things to ask about.

Dibein operates as an AISP only. We connect to accounts through licensed aggregators (Bridge and Powens are the two we use most for French and broader EU banks) that hold the relevant PSD2 authorizations, and we consume account information — balances, transactions, standing data — through that channel. We never request PISP scope, and there is no code path in the product that can initiate, authorize, or modify a payment. This isn't a policy we could quietly change later; it's a structural decision about what the product is for.

Why we deliberately stayed read-only

It would be technically possible to build payment initiation into a forecasting and anomaly-detection product — plenty of fintech platforms do exactly that, usually branded as "treasury automation" or "smart payments." We chose not to, for a reason that has more to do with what the product is actually for than with regulatory conservatism.

Anomaly Radar's entire value proposition rests on being a second, independent set of eyes on transactions — a system that notices something is wrong and tells a human, who then goes and acts on it through the bank's own interface, where the bank's own controls and audit trail apply. The moment a tool that flags fraud-shaped transactions can also move money, it becomes a much more attractive target for exactly the kind of attack it's supposed to catch, and a much harder thing for a security team to reason about. Read-only isn't a limitation we're working around; it's the reason the fraud-detection half of the product can be trusted at all.

What this means practically for a finance team

• Connecting a bank account to Dibein requires the same strong customer authentication flow as checking your balance in your bank's own app — usually a redirect to your bank, an approval there, and a return to Dibein. Nobody at Dibein ever sees your online banking credentials.
• Consent is time-limited under PSD2 and must be renewed periodically (typically every 90 days), which is a regulatory requirement, not a Dibein-specific design choice.
• Because there is no payment-initiation capability, a compromised Dibein account cannot be used to move funds, even in the worst case. It can expose transaction visibility, which is why the rest of our security posture — encryption, access controls, audit logging — is built around protecting that data specifically.

What's changing in 2026

The practical experience of Open Banking in France has improved substantially over the past two years as more banks moved from minimally-compliant PSD2 interfaces to properly maintained ones — connection reliability and re-authentication friction were real problems in 2022 and 2023 and are much less so now. The EU's PSD3 proposal, still working through the legislative process, would tighten some of the interface-quality requirements that made early Open Banking implementations frustrating, but it doesn't change the fundamental AISP/PISP split described above. Whatever changes, the read-only line is one we're not planning to move.