A Third Party Provider (TPP) in open banking is a regulated entity that uses bank APIs to offer Account Information Services (AIS) and/or Payment Initiation Services (PIS). Users consent once, and the TPP can then read account data or initiate payments on their behalf. Building a TPP means getting architecture, consent, and compliance right from day one.
AIS vs PIS
AIS (Account Information Services) concerne la lecture : liste de comptes, soldes, transactions. Exemples d’usage : dashboards d’agrégation, lending et vérification de revenus, apps de budget. L’utilisateur consent à « partager mes données de compte avec cette app » et le TPP appelle les API de la banque avec le token d’accès obtenu.
PIS (Payment Initiation Services) concerne l’initiation d’un paiement depuis le compte de l’utilisateur. L’utilisateur choisit le compte et le montant ; le TPP envoie l’instruction à la banque. Pas de carte ni de virement séparé : le paiement est initié via le canal open banking. Exemples : checkout, paiement de factures, décaissements.
Beaucoup de TPP font les deux : afficher les comptes d’abord (AIS), puis permettre de payer depuis l’un d’eux (PIS). Le consentement doit être clair et limité en scope : quelles données ou action sont autorisées, pendant combien de temps, et révocable.
Consent in practice
Le consentement n’est pas une case cochée une seule fois. Il a un cycle de vie : créer, utiliser, rafraîchir, révoquer. Le TPP doit stocker le consentement et son scope, le lier au token d’accès et respecter les révocations. Les utilisateurs doivent pouvoir voir et retirer leur consentement dans votre app ou via un portail centralisé. Nous construisons la gestion du consentement et les audit trails pour que nos clients restent conformes et user‑friendly.
Strong Customer Authentication (SCA)
Les banques exigent généralement la SCA (par ex. double facteur) avant de libérer des données ou d’exécuter un paiement. Le TPP redirige l’utilisateur vers la banque ; la banque effectue la SCA et redirige avec un code d’auth. Le TPP échange ce code contre un token d’accès. Nous concevons et implémentons ce flux de redirection et de tokens pour que votre produit n’ait pas à devenir expert sécurité — nous le construisons pour vous, comme pour Meras, Infinipi et d’autres.
Regulatory readiness
Les TPP sont souvent soumis à licence (par ex. en tant qu’institutions de paiement ou selon des règles open banking locales). L’architecture doit supporter des audit trails, le stockage sécurisé des tokens et une séparation claire entre consentement et exécution. Chez FintechPaa, nous construisons des systèmes prêts pour les TPP, alignés PSD2/Open Banking, afin que vous vous concentriez sur le produit et la régulation, pas sur l’intégration bas niveau.
Vous planifiez un TPP ou l’ajout d’AIS/PIS à votre produit ? Nous pouvons construire l’architecture et les flux pour vous.
← Retour au blog