Aller au contenu
XSIS
Parler à un ingénieur

Intégrations

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

Open banking : données et paiements avec le consentement du clientLe 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.PersonnesClientServiceVotre applicationou plateformeTrésorerie, crédit oucomptabilitéXSISConnecteur openbankingConsentement, jetonset normalisation desdonnéesBanqueAPI bancaires ouagrégateurInformation sur lescomptes et initiationde paiementERPERP ou grand livrePosition de trésorerieet rapprochement12REST/JSON3OAuth 2.0 · FAPIREST4REST/JSON · webhook5REST/JSON6HTTP 401 · 4037

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

  1. Source Client, destination Votre application ou plateforme : Donne son consentement (flux principal).
  2. Source Votre application ou plateforme, destination Connecteur open banking : Demandes de comptes et de paiements, via REST/JSON (flux principal).
  3. Source Connecteur open banking, destination API bancaires ou agrégateur : Appels API autorisés, via OAuth 2.0 · FAPI · REST (flux principal).
  4. Source API bancaires ou agrégateur, destination Connecteur open banking : Soldes, transactions et statut des paiements, via REST/JSON · webhook (asynchrone).
  5. Source Connecteur open banking, destination ERP ou grand livre : Transactions normalisées, via REST/JSON (flux principal).
  6. Source API bancaires ou agrégateur, destination Connecteur open banking : Consentement expiré ou retiré, via HTTP 401 · 403 (chemin d’exception).
  7. 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

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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 question
Avons-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 question
Quels 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 question
L’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 question
Comment 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 question

Dites-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