La DSP2 en tant que germe de cristallisation des API au cours des dernières années a conduit à ce que différentes initiatives en Europe spécifient une API accès au compte. Les initiatives les plus importantes sont certainement « The Berlin Group », « stet » et « PolishAPI ». Mais la DSP2 a également eu un impact en dehors de l’Europe. En Suisse, le « OpenBankingProject » a été créé, inspiré de l’API du Berlin Group SwissNextGenAPI. Au Royaume-Uni, l’initiative « Open Banking » a été lancée. Toutes les initiatives et leurs API misent sur la DSP2 et elles ont toutes en commun l’objectif de réaliser un gain d’efficacité élevé.
La réalité tempère quelque peu cet espoir. Il existe bien sûr des initiatives de normalisation décrites ci-dessus. Cependant, tout d’abord il n’existe pas de spécification universelle, mais ensuite, les institutions financières ne sont pas obligées de s’y conformer et enfin, les spécifications laissent une certaine liberté d’implémentation (mot-clé Implementor Options). Si un acteur du marché, qu’il s’agisse d’une institution financière ou d’un prestataire de services tiers, souhaite utiliser l’API accès au compte des institutions financières, il est confronté à un défi. PPI a relevé ce défi et a créé, avec le produit TRAVIC-Payment-Client-API, une bibliothèque qui dissimule l’hétérogénéité décrite derrière une seule interface. L’utilisation de TRAVIC-Payment-Client-API permet de minimiser les risques et de raccourcir le temps de développement pendant la connexion des interfaces accès au compte des institutions financières. Le produit est utilisé de manière productive chez Atruvia AG. Pour en savoir plus et découvrir par exemple comment Atruvia AG en a profité, cliquez ici.
Du point de vue de PPI, le thème API est un incontournable dans le contexte des paiements. Poussés en partie par la DSP2, les premiers pas ont été faits du côté des institutions financières. Mais il est prévisible que le progrès ne s’arrêtera pas là. Le Berlin Group a depuis longtemps spécifié l’openFinance API Framework (https://www.berlin-group.org/open-finance) qui développe les cas d’utilisation de l’interface accès au compte. Pour autant que l’on sache, d’autres extensions de la spécification sont prévues pour 2022. Ces services à valeur ajoutée, qui sont bien entendu fournis via des API, sont de plus en plus proposés sur les portails pour développeurs des grandes institutions financières. Certaines de ces API ne s’adressent plus seulement à des prestataires de services tiers, mais aussi directement aux entreprises. Cela montre clairement que le thème de l’API ne se limite pas aux cas d’utilisation pertinents pour la DSP2, mais qu’il s’établira de plus en plus comme un canal autonome pour différentes parties impliquées. Par conséquent, il est probable que tôt ou tard, d’autres API seront disponibles en plus d’EBICS, FinTS et accès au compte.
Le Berlin Group n’est pas le seul à s’intéresser à l’API. Le Conseil européen des paiements (EPC) a créé un groupe de travail au niveau européen, chargé d’élaborer un Rulebook pour l’accès aux comptes de paiement SEPA via les API (https://www.europeanpaymentscouncil.eu/news-insights/news/call-candidates-sepa-payment-account-access-multi-stakeholder-group-spaa-msg), auquel PPI participe. En outre, dans l’annonce publiée récemment au sujet du « SEPA Request to Pay Scheme Rulebook 2.0 », l’EPC a même déclaré que l’échange de messages SRTP via des API serait obligatoire à l’avenir.
Le marché est en pleine mutation, mais une chose est claire : la liste des initiatives existantes et futures autour des API est longue et de nombreuses innovations sont envisageables dans cet environnement. Avec le produit TRAVIC-Payment-Client-API, PPI a fait le premier pas et le propose notamment aussi comme service. En outre, PPI conçoit d’autres services autour du thème de l’API.
Auteur : Christian Wenz
0 commentaires:
Enregistrer un commentaire