Norme API Berlin Group
L'API Berlin Group est une spécification technique commune pour connecter des services bancaires à d'autres logiciels. Le cadre NextGenPSD2 soutient l'open banking en définissant comment les prestataires autorisés échangent informations de compte et instructions de paiement avec les banques. Des formats de message communs réduisent le besoin de créer une interface différente pour chaque banque.
Les développeurs qui mettent en œuvre l'open banking en Allemagne utilisent NextGenPSD2 pour l'information sur les comptes, l'initiation de paiement et la confirmation de disponibilité des fonds. Les clients autorisent l'accès via l'authentification de la banque. Les banques peuvent appliquer différentes méthodes d'authentification, donc les développeurs doivent toujours tester chaque connexion.
Le groupe derrière NextGenPSD2
Berlin Group est un organisme sectoriel réunissant banques, banques centrales, associations de paiement, réseaux de paiement et processeurs interbancaires opérant dans SEPA. Il organise des équipes spécialisées, soutenues par des groupes d'experts API, d'évaluation commerciale et de communication de marché. Berlin Group n'est pas un régulateur et ne délivre aucun agrément. Il produit des spécifications qu'une banque applique parce que le marché l'attend, et non sur ordre d'un superviseur.
Chaque cadre comprend trois types de documents, tous publiés gratuitement sous licence Creative Commons: les Operational Rules décrivent le service, le modèle logique de données et les flux comme interface interentreprises; les Implementation Guidelines détaillent les interfaces techniques avec leurs schémas XML et JSON; les fichiers OpenAPI permettent de générer du code. Une équipe lisant seulement les guides ignore les règles de processus; une équipe lisant seulement les règles écrit une interface que personne ne peut appeler.
NextGenPSD2 et ses trois groupes de services
NextGenPSD2 couvre exactement les trois services d'accès aux comptes créés par la DSP2. Account Information Service, AIS, lit soldes et transactions pour un tiers autorisé par le client. Payment Initiation Service, PIS, initie un paiement depuis le compte du client. Confirmation of Availability of Funds, parfois abrégé PIIS ou CAF, indique par oui ou non si un montant est couvert, ce qu'un émetteur de cartes utilise avant autorisation.
La spécification utilise REST et des messages JSON, sécurisés par OAuth 2.0 et OpenID Connect. Ses versions dépassent largement le minimum initial: comptes multidevises, ordres permanents, paiements périodiques et meilleure gestion des erreurs. Le suivi des normes de Fiskil recense une trentaine de pays l'appliquant, permettant à un prestataire ciblant l'Allemagne de couvrir l'essentiel de l'Europe avec le même code.
Le modèle de consentement et les trois modes d'authentification
Le consentement est une ressource de l'API: un tiers crée un objet de consentement décrivant l'accès souhaité et sa durée, le client l'autorise auprès de la banque et chaque appel ultérieur s'y réfère. Un consentement a une durée de validité et un périmètre, tous deux imposés par la banque, donc un consentement expiré provoque une erreur, plutôt qu'une réponse vide silencieuse.
L'authentification forte du client peut suivre trois voies, toutes prises en charge par la norme. Avec la redirection, le client rejoint la page ou l'application de la banque, puis revient. En mode découplé, il approuve dans l'application bancaire sur un autre appareil tandis que la session initiale attend. En mode intégré, les données d'authentification passent dans l'API elle-même. Le choix proposé par la banque détermine l'expérience de paiement; la page authentification forte du client couvre les règles sous-jacentes.
Pourquoi deux banques appliquant la même norme exigent du code différent
Une spécification laisse des choix, et chaque choix différent d'une banque impose un travail d'intégration au prestataire. Les différences concernent l'authentification, les champs facultatifs, la durée du consentement avant réauthentification, les codes d'erreur et la prise en charge des paiements groupés et de leurs formats. Aucun de ces choix ne viole la norme; tous compromettent une intégration naïve.
C'est la raison commerciale de l'existence des agrégateurs. Une banque directement connectée à quelques centaines d'établissements allemands maintient autant d'ensembles de particularités, et un prestataire vend une abstraction de celles-ci. Chaque banque exploite aussi un environnement de test avant l'accès en production, dont le comportement ne correspond pas toujours à la production, et c'est là que glissent la plupart des calendriers d'intégration.
Le cadre API openFinance au-delà de la DSP2
Le cadre API openFinance de Berlin Group repose sur les investissements technologiques et d'infrastructure de NextGenPSD2. Il ajoute des extensions normalisées dépassant le périmètre réglementaire DSP2, pour que les clients bancaires accèdent à leurs comptes pour des services commerciaux premium et des données enrichies. Il couvre davantage de sources de données et de types de comptes que la DSP2: épargne, prêts et investissements, outre le compte de paiement.
Côté paiements, les extensions premium couvrent des services au-delà de la DSP2: bloquer ou réserver des fonds, différer un paiement, payer par prêt avec crédit à la consommation intégré, créer un mandat de prélèvement SEPA. Le cadre définit la forme technique; le dispositif SPAA définit les conditions commerciales. Les deux sont conçus pour fonctionner ensemble, et Berlin Group publie un programme des services qu'il prévoit d'ajouter.
Données de compte au-delà de la DSP2: FIDA
FIDA, le règlement européen sur l'accès aux données financières, étendrait l'accès obligatoire bien au-delà du compte de paiement, aux prêts immobiliers, à l'épargne, aux investissements, aux assurances, aux retraites et aux données de solvabilité. Il obligerait les entreprises à adhérer à des dispositifs de partage de données financières définissant normes et compensation. Ce périmètre dépasse largement celui de NextGenPSD2.
Pour une banque allemande, l'enchaînement importe plus que le détail. Une banque ayant correctement appliqué NextGenPSD2 possède déjà les mécanismes de consentement, l'infrastructure d'authentification et la pratique d'exploitation des API. FIDA ajouterait des domaines de données et un tableau de bord des autorisations, et openFinance est la proposition de Berlin Group pour devenir la spécification adoptée par ces dispositifs. Une banque avec une interface DSP2 à moitié construite abordera FIDA en moins bonne position.
Qu'est-ce que la norme Berlin Group?
La norme Berlin Group, précisément le cadre NextGenPSD2 Access to Account, est une spécification API gratuite pour les trois services DSP2: information sur les comptes, initiation de paiement et confirmation des fonds. Le cadre NextGenPSD2 définit des interfaces REST et JSON, un modèle de consentement et trois modes d'authentification forte du client, et les banques d'une trentaine de pays l'appliquent.
La norme Berlin Group est-elle obligatoire?
La DSP2 oblige une banque à fournir une interface d'accès sans prescrire de spécification. Berlin Group est une initiative sectorielle, non un régulateur, et ses documents sont volontaires. La norme domine en Allemagne et dans une grande partie de l'Europe continentale grâce à la convergence du marché, produisant l'effet pratique d'une exigence sans sa force juridique.
La norme Berlin Group et Finance Loop
Finance Loop réunit les équipes bancaires ayant construit une interface XS2A et les prestataires en utilisant plusieurs centaines, une discussion qui révèle ce que la spécification laisse ouvert. Finance Loop est le lieu de rencontre des paiements en Allemagne, avec des rencontres et conférences sur l'open banking, les virements instantanés et la réglementation des paiements. Finance Loop tient ces dates dans son calendrier des événements.
Finance Loop est un réseau professionnel qui favorise l'usage institutionnel des technologies émergentes en finance, comme l'IA, la tokenisation, les stablecoins, et la DeFi. Finance Loop aide ses membres à développer leurs compétences et leurs réseaux personnels dans ces domaines: Investissement & actifs numériques, Paiements & monnaie numérique, Infrastructure numérique & souveraineté et Risque & conformité.