Intégration d'une API bancaire

Qonto expose les comptes de votre entreprise : vous êtes le titulaire, vous lisez vos mouvements et vous pouvez déclencher des virements. L'open banking expose les comptes de vos utilisateurs, avec leur consentement, via un agrégateur qui porte l'agrément réglementaire. Le premier cas sert le rapprochement et la trésorerie interne. Le second sert un produit qui a besoin de voir la banque de ses clients. Les deux se combinent, et ce n'est pas le même contrat, ni le même parcours d'authentification.

Cela dépend du périmètre bien plus que de la marque. Lire les transactions d'un seul compte et les pousser en comptabilité se chiffre bien plus bas qu'une agrégation multi-banques avec renouvellement de consentement, ou qu'une chaîne de virements déclenchés par le métier. Le rattrapage d'historique et le traitement des échecs pèsent souvent plus que le flux nominal. Nous cadrons le périmètre en amont et donnons une estimation ferme.

Pour l'agrégation des comptes de vos utilisateurs, l'agrément est porté par l'agrégateur (Bridge, Powens, Tink), pas par votre application. Vous restez responsable du parcours de consentement, de la conservation des jetons et de l'information donnée à l'utilisateur. Pour une banque professionnelle dont vous êtes le titulaire, le sujet est contractuel avec l'établissement, pas un agrément DSP2 à obtenir vous-même. Cela se clarifie au cadrage, avec votre DSI et votre conseil.

Oui, à condition de porter une référence de bout en bout plutôt que de matcher au montant et à la date. Nous posons cette référence à l'émission de la facture, puis nous l'attendons sur le mouvement. Les cas restants (virement libre, montant partiel, libellé tronqué) sortent dans une file d'exceptions, ils ne sont pas rapprochés au jugé. Un rapprochement silencieux et faux coûte plus cher qu'une exception visible.