Depuis la publication de la directive européenne DSP2, l'ouverture des systèmes bancaires aux prestataires de services tiers n'est plus un simple vœux pieux, mais une obligation réglementaires. Les chemins pour y parvenir peuvent être tortueux. Aussi, est-il nécessaire de bien penses son approche et optimiser ses choix.
Familles de services
Deux principales familles de services doivent être assurées :
- Un accès aux informations sur le compte bancaire (relevés, état, reporting, ...)
- Un service d'initiation d'opération de paiement
Il va bien entendu, sans dire, que ces accès doivent être hautement sécurisés et que l'authentification forte est de rigueur.
Condition préalable
- Une condition importante pour la mise en œuvre volontaire d’une API bancaire ouverte veut que l’utilisation souhaitée par le client de ses données bancaires soit traitée par une plate-forme API sécurisée.
- Ce principe doit s’appliquer à son tour aussi bien aux clients qu'aux banques et aux prestataires tiers.
Possibilités d'architecture
Deux grandes familles d'architectures se distinguent :
- Une architecture "captive" : chaque banque met en place son API d'accès de façon autonome. Bien que les banques françaises peuvent convenir d'un formalisme et de mécanismes communs d'accès. Avec les contraintes de chacune, les mises en œuvres différentes, le modèle de données de chaque institution et l'organisation interne des équipes de support et dévolution, ces APIs finiront tôt ou tard par diverger et fragmenter le paysage des services bancaires en France. Le risque alors est d'ouvrir la voie à un acteur (de Data) des géant du Net qui jouera le rôle d'intermédiaire entre les consommateurs des services (Fintech) et les fournisseurs des services (Banques) en profitant au passage de la mine de Data qui transite et qui peut être hautement valorisée.
- Une architecture en étoile : via une structure commune aux institutions financières (Banques). Cela peut être un acteur ayant une masse critique nécessaire pour entrainer le reste du marché des services bancaires en France derrière lui. Sur le modèle de SEPAMAIL par exemple. Aussi, cet intermédiaire standardisera les fonctions de :
- Registres des membres fournisseurs et consommateurs
- Sécurité et contrôle d'accès
- Routage des requêtes
- Facturation et statistiques
- PROTECTION DES DATAs échangées
- ...
Une plateforme dédiée
Le choix optimal pour les banques françaises est alors de COOPERER afin de mettre en place un plateforme dédiée à l'open Banking et assurant et la protection ds données clients et un haut niveau de qualité de service.
Architecture proposée
Afin de répondre à la fois aux obligation d'ouverture et d'accès aux données d'un part et aux obligations de protection renforcée des données sensibles de paiement et des données personnelles des clients, nous proposons l'architecture modulaire suivante :
ARCHITECTURE PLATEFORME API OPEN BANKING COMMUNE
Commentaires
Enregistrer un commentaire
Bonjour,
Merci pour votre contribution.
Elle sera prochainement publiée, si elle est conforme aux règles du site.
Cordialement,