API d’open banking
Open banking : données de compte et paiements via les API bancaires
Information sur les comptes et initiation de paiement via des API bancaires réglementées et des agrégateurs, avec gestion du consentement et des jetons.
Schéma
Faites défiler latéralement pour voir tout le schéma.
Open banking : données et paiements avec le consentement du client
Le client donne son consentement, le connecteur conserve les jetons, et chaque appel à la banque est autorisé et journalisé. Lorsque le consentement expire ou est retiré, l’application sollicite à nouveau le client au lieu d’échouer sans rien signaler.
- Flux principal
- Asynchrone
- Chemin d’exception
Le flux, étape par étape
- Source Client, destination Votre application ou plateforme : Donne son consentement (flux principal).
- Source Votre application ou plateforme, destination Connecteur open banking : Demandes de comptes et de paiements, via REST/JSON (flux principal).
- Source Connecteur open banking, destination API bancaires ou agrégateur : Appels API autorisés, via OAuth 2.0 · FAPI · REST (flux principal).
- Source API bancaires ou agrégateur, destination Connecteur open banking : Soldes, transactions et statut des paiements, via REST/JSON · webhook (asynchrone).
- Source Connecteur open banking, destination ERP ou grand livre : Transactions normalisées, via REST/JSON (flux principal).
- Source API bancaires ou agrégateur, destination Connecteur open banking : Consentement expiré ou retiré, via HTTP 401 · 403 (chemin d’exception).
- Source Connecteur open banking, destination Votre application ou plateforme : Client invité à renouveler son consentement (chemin d’exception).
Présentation
L’open banking permet à une application de consulter les comptes d’un client et d’initier des paiements via des API bancaires réglementées, avec le consentement du client. Il rend possibles l’agrégation de comptes, l’analyse de solvabilité pour le crédit, le paiement par virement au moment de l’achat et une vue de trésorerie consolidée sur plusieurs banques.
L’architecture de référence place un connecteur open banking entre votre application et les banques, en direct ou via un agrégateur agréé. Le connecteur conduit le parcours de consentement, conserve les jetons de manière sécurisée, appelle les API bancaires selon des standards tels que Berlin Group NextGenPSD2 ou le UK Open Banking Standard, et convertit les données de chaque banque dans un modèle unique et cohérent.
Le consentement n’est pas permanent, et l’architecture l’anticipe. Lorsqu’il expire ou qu’il est retiré, le client est invité à le renouveler, plutôt que de voir l’application perdre des données sans le signaler. Chaque appel est autorisé, journalisé et rattaché au consentement qui l’a permis.
Fonctionnement du flux
- 01
Le client donne son consentement
Le client choisit sa banque, voit quelles données sont partagées et pour quelle durée, puis s’authentifie auprès de sa banque, qui le redirige vers votre application.
- 02
Votre application formule la demande
Votre application demande des soldes, des transactions ou un paiement via l’API du connecteur, et jamais directement auprès de la banque.
- 03
Le connecteur appelle la banque
Le connecteur utilise les jetons conservés pour adresser des appels autorisés à l’API de la banque ou à l’agrégateur, selon le profil de sécurité exigé par la banque.
- 04
Les données et les statuts reviennent
Les soldes, les transactions et le statut des paiements reviennent sous forme de réponses ou de webhooks, et le connecteur les normalise dans un modèle unique, commun à toutes les banques.
- 05
Exploiter les données
Les transactions normalisées alimentent votre produit, vos modèles de risque ou votre ERP pour les positions de trésorerie et le rapprochement.
En cas d’erreur
Le consentement expire ou est retiré
La banque refuse l’appel. Le connecteur marque le consentement comme n’étant plus valide, et votre application invite le client à le renouveler en lui en expliquant la raison.
Un paiement est rejeté
Le statut et le motif communiqués par la banque reviennent via l’API ou un webhook, et le client comme votre équipe des opérations voient immédiatement le résultat.
Une banque limite l’accès
Les banques limitent la fréquence à laquelle les données peuvent être récupérées en l’absence du client. Le connecteur planifie les actualisations dans ces limites et ralentit lorsqu’une banque le signale.
Une API bancaire est indisponible
Les appels sont relancés avec des délais croissants, les dernières données valides sont affichées avec leur ancienneté, et une alerte est émise si l’indisponibilité persiste.
Standards et systèmes
- Standards et canaux bancaires
- PSD2
- Berlin Group NextGenPSD2
- UK Open Banking Standard
- FAPI
- Intégration
- REST
- Webhooks
- Identité et accès
- OAuth 2.0
- OpenID Connect
Questions et réponses
Faut-il se connecter aux banques en direct ou via un agrégateur ?
Un agrégateur vous donne accès à de nombreuses banques via une seule API et gère les particularités de chacune, moyennant un coût par appel ou par connexion. Les connexions directes offrent davantage de maîtrise et peuvent convenir pour un petit nombre de banques importantes. De nombreux produits démarrent avec un agrégateur et ajoutent ensuite des connexions directes. Nous comparons les options au regard des banques et des pays dont vous avez besoin.
Lien vers cette questionAvons-nous besoin d’un agrément pour utiliser l’open banking ?
L’information sur les comptes et l’initiation de paiement sont des activités réglementées dans de nombreux pays. Soit votre entreprise détient l’agrément, soit vous passez par un prestataire agréé qui le détient. Le cas applicable dépend de votre pays et de votre cas d’usage, et vos conseillers juridiques et conformité doivent le confirmer. Nous réalisons l’intégration quelle que soit la voie retenue.
Lien vers cette questionComment le consentement du client est-il géré ?
Le client voit quelles données sont partagées, dans quel but et pour quelle durée, et s’authentifie auprès de sa propre banque. Le connecteur conserve le consentement et ses jetons sous forme chiffrée, et chaque appel est rattaché à un consentement valide. Les clients peuvent retirer leur consentement ; le connecteur cesse alors d’appeler la banque concernée pour leur compte.
Lien vers cette questionQuels banques et pays sont couverts ?
La couverture dépend des règles de la région et des API des banques. L’Union européenne et le Royaume-Uni bénéficient d’une large couverture au titre de la DSP2 et du UK Open Banking Standard. Ailleurs, la couverture varie, et les agrégateurs comblent une partie des lacunes. Nous vérifions la couverture des banques utilisées par vos clients avant que vous ne vous engagiez sur une architecture.
Lien vers cette questionL’open banking remplace-t-il les connexions bancaires host-to-host ?
Pas pour la plupart des activités de trésorerie d’entreprise. Les canaux host-to-host traitent les fichiers de paiement en masse et les relevés complets de vos propres comptes. L’open banking convient aux produits destinés aux clients, aux soldes en temps réel et aux paiements unitaires. De nombreuses entreprises utilisent les deux : le host-to-host pour leurs propres campagnes de paiements et l’open banking pour leurs clients.
Lien vers cette questionComment les données d’open banking sont-elles protégées ?
Les jetons et les enregistrements de consentement sont chiffrés au repos, seul le connecteur peut les utiliser, et chaque appel est journalisé avec le consentement qui le fonde. Nous ne collectons que les données nécessaires à la finalité et fixons leur durée de conservation. Ces données sont soumises aux règles de protection des données telles que le RGPD, et nous concevons l’architecture avec votre délégué à la protection des données (DPO).
Lien vers cette questionDites-nous ce que vous devez construire ou connecter.
Décrivez les systèmes, le calendrier et les contraintes. Les ingénieurs concernés prennent ensuite le relais.
- Notre équipe vous appellera dans les 24 heures, sur le créneau de votre choix
- Notre équipe est disponible 24 h/24, 7 j/7