Nouveaux vecteurs de développement, les API bouleversent le référentiel des échanges

Véritables évolutions de rupture, les API viennent profondément modifier le cadre des dialogues entre acteurs. Ils ne sont plus basés sur des échanges de données traditionnels —extractions des données pertinentes d’un système d’information, leur transfert et leur intégration dans la cible — très chronophages et gourmands en ressources humaines et techniques. Avec les API, il est désormais possible d’interagir d’application à application, dans un système qui encapsule les données utiles à l’échange. Certes, cette technologie existe déjà depuis plusieurs années, mais son développement récent dans un environnement ouvert, entre acteurs d’un même processus, ouvre d’innombrables opportunités.

Le potentiel des API est notamment boosté par la convergence des grands projets de place comme la facture digitale et ses liens avec les paiements. Cette évolution induit un changement complet dans la typologie des échanges entre acteurs d’un même secteur : ils ne sont plus atomisés, entrecoupés, longs et fractionnés. À l’inverse, ils deviennent fluides, rapides et transparents. Votre service métier gère des commandes ? Il a besoin d’une information précise ? Il a la capacité d’immédiatement aller demander cette information via une API avec les éléments de contexte justes qui permettent une réponse efficace. Outre le temps réel, ces interactions offrent l’opportunité de créer des processus complets entre des environnements tout à fait hétérogènes. Les données ne sont plus centralisées et les process non linéaires.

Pourquoi cette technologie est-elle devenue aussi puissante ces dernières années ? Cela est notamment dû à sa normalisation, qui faciliterait un usage de masse, mais également la forte évolution vers le SaaS, qui démultiplie encore un peu plus le potentiel API. Compte tenu de cette rupture, quelles évolutions sont à anticiper ? Elles sont nombreuses, mais une chose est sûre : les API permettent de créer des services de manière illimitée. Les possibilités d’évolution sont exponentielles, presque virales, et la seule limite réside dans la créativité de l’apporteur de valeur ajoutée. En outre, les API permettent la construction d’une offre modulaire qui peut reposer sur plusieurs producteurs de contenus reliés entre eux pour obtenir un métaservice à valeur ajoutée.

Paiement, authentification forte, API et après… laissons les paiements se frotter aux innovations

Confortant l’ère de l’open-banking, les API, qu’elles soient construites sur le protocole SOAP ou REST, font partie aujourd’hui des outils Internet composant l’architecture ouverte des paiements. Dans ce contexte, pour sécuriser l’accès aux interfaces bancaires par des tierces parties telles que l’initiation de paiement ou l‘agrégation de comptes, la DSP2 a permis de déployer des API standardisées. Toujours avec cet objectif de sécurisation des paiements, la DSP2 a également imposé l’authentification forte, nommée 3D-Secure V2, pour valider les paiements par carte sur Internet.

La migration vers l’authentification forte pour les cartes de crédit et de débit rattachées au compte du titulaire a été réalisée avec succès et massivement à 95 %, comme le note la Banque de France. En revanche, pour les cartes commerciales, le passage à l’authentification forte, pour les titulaires de cartes qui n’avaient pas accès au compte bancaire de l’entreprise, a été plus complexe à mettre en œuvre. Avec un taux de fraude pouvant atteindre 1,55 %, et qui concerne principalement les transactions e-commerce, pour cette gamme de cartes, il était urgent de mettre en œuvre l’authentification forte. À la différence des cartes de crédit ou de débit qui sont associées au compte bancaire de son porteur, la difficulté avec la carte commerciale Business ou Corporate réside en ce que son titulaire a rarement accès au compte bancaire de l’entreprise. Et pour être en conformité avec la réglementation DSP2, il n’est plus toléré l’usage du numéro reçu par sms pour valider la transaction e-commerce. Il faut désormais appliquer la règle de l’authentification forte qui requiert l’utilisation d’au moins deux des trois facteurs : mémoriel (ce que l’entité connaît), matériel (ce que l’entité détient) et le facteur d’inhérence (ce que l’entité est : exemple facteur biométrique). Une des solutions a été de développer une API permettant d’accéder à l’interface d’authentification du compte bancaire de l’entreprise, sans que le titulaire puisse faire des actions ou des consultations du compte, afin que le titulaire de la carte puisse valider la transaction e-commerce. Ce dernier, après s’être authentifié sur la page de la banque en ligne du compte rattaché à l’entreprise, doit saisir sur une autre fenêtre dédiée à l’authentification du paiement un code personnel seul connu par le titulaire de la carte. Cette API est conçue exclusivement pour valider la transaction et ne permet pas de consulter ou réaliser des actions sur le compte bancaire, l’entreprise ou son gestionnaire la représentant conservant les droits d’accès au compte.

L’impact des API sur l’écosystème des paiements est évident. 2022 devrait être la rampe de lancement de l’ère du tout API, facilitant la connexion des applications. Gageons que l’architecture ouverte et « apéisée », en offrant de nouveaux services par exemple avec l’appui d’un « portefeuille store » d’applications, enrichira la fonction paiement. Les nouvelles API devraient ainsi contribuer à gagner de nouvelles clientèles. Cependant, les défis resteront la fluidité du parcours client, le déport des applications dans le Cloud, la protection des données sensibles, la résilience et la disponibilité du service. Pour répondre à ces défis, la banque demeurera un acteur incontournable au cœur du système des paiements. Elle est garante des fonds et demeure le coffre-fort le plus efficient pour les protéger ainsi que les données. Enfin, d’autres innovations viendront probablement impacter le monde du paiement et des API comme l’ovni Métavers et l’ordinateur quantique. Le premier ouvre un espace virtuel, reposant sur la neuroscience avec la création d’avatars, qui pourrait participer notamment au rôle de personal shopper dans le parcours client et augmenter fortement le taux de transformation. Le second apportera une puissance de calcul phénoménal, mais ouvrira la porte à des risques de cyberattaques en attendant la cryptologie quantique. Comme le disait si justement Paul Valéry « les recherches insensées sont parentes de découvertes imprévues ». Laissons les paiements se frotter aux innovations.

Néo-banques et acteurs historiques se rendent coup pour coup !

Il fallait s’y attendre, 5 Saisons n’auront pas suffi pour aboutir à « The End ». En effet, sous toutes les latitudes, l’ensemble des ingrédients reste réuni pour alimenter la poursuite de la lutte intense entre « néo » et « anciens ».

Que l’on soit leader ou challenger, c’est à qui, tour à tour, tentera d’échapper aux risques d’intermédiation ou de banalisation, et de faire mieux que son voisin à coup de services additionnels et d’innovations.

En cette année 2021, le nombre de naissances a largement dépassé celui des disparations, les jeunes pousses ont récolté des sommes spectaculaires auprès des investisseurs (cf. les dernières levées de fonds de Revolut, N26, Monzo, Lydia… ou l’introduction en bourse de la brésilienne Nubank valorisée 50 milliards $), elles continuent de diversifier ou d’internationaliser leurs activités et couvrent toujours plus de segments en BtoC et BtoB.

Les banques quant à elles ont recouvré une santé de fer et ne s’en laissent pas compter, tant s’en faut. Fortes de leurs atouts et de leurs capacités financières, elles misent de lourds tickets dans la Tech, s’invitent dans des tours de tables auprès de néo-banques/fintechs ou en rachètent et lancent moult contre-offensives.

Cette course effrénée entre belligérants des deux camps, rarement à bout de souffle, concourt évidemment à la suprématie sous toutes les latitudes de la banque numérique/mobile, celle-ci favorisée de surcroît par les évolutions réglementaires et technologiques et l’appétence persistante des consommateurs et entreprises pour des services pratiques, utiles et performants.

Elle entraîne également une surenchère ininterrompue qui pourrait conduire à une espèce de bain de sang, à moins que les plus lucides et astucieux de la bande n’empruntent des chemins de traverse moins chaotiques et ne sortent de la jungle : vous avez dit océan bleu ?

Quoi qu’il en soit, dans les années à venir, nous allons assister à un flot de tentatives et d’évènements qui ne manqueront pas de générer d’innombrables soubresauts et des retombées inattendues.

Face à un tel scenario digne des meilleures séries télévisées, la saga des néo-banques va se poursuivre inexorablement…

Nous vous invitons à accéder à notre 5ème édition disponible sur notre site web www.syrtals-cards.com et nous serons ravis d’échanger nos idées et sensations respectives en la matière.

L’usage des API via les TMS (Treasury Management System) pour la communication bancaire

Les API ont pour objectif de faire communiquer en temps réel les applications métiers que ce soit vers la banque ou en interne en l’entreprise. Les entreprises réfléchissent à optimiser leurs communications bancaires dans une perspective de rationalisation des développements et d’efficacité des suivis.
Les TMS sont de plus en plus implémentés par ces dernières pour s’affranchir des aspects techniques et opérationnels de la communication bancaire.

Avec la DSP2, les banques ont mis à disposition des API sur les services de banques en ligne pour permettre l’agrégation de comptes. Les principaux services utilisés sont la consolidation des relevés de compte ou l’exécution des virements unitaires. Un constat : chaque banque propose ses propres API. Les agrégateurs ont réalisé les développements pour chaque établissement et ils les ont mis à disposition dans certains TMS. Cependant, ces services ne sont pas opérationnels pour les transferts de fichiers.

Les entreprises s’efforcent de travailler en temps réel pour la récupération des fichiers de relevés (de comptes, d’opérations, d’impayés…) pour les transmettre à l’ensemble des applications métiers (trésorerie, comptabilité, commercial…) ou l’émission des fichiers de paiements issus des applications « métiers» .
Aujourd’hui, les process sont encore « Batch » et tous interdépendants. Avec les API, la question est comment faire communiquer entre eux les logiciels internes de l’entreprise pour gagner en efficacité ?
Les API pour la connexion bancaire sont encore inexistantes, car cela repose sur l’aspect réglementaire, contractuel et fonctionnel lié à la communication bancaire et à la signature des ordres.
Chaque connexion EBICS TS ou Swiftnet fait l’objet d’un contrat entre l’entreprise et ses banques indiquant les services ouverts et les signataires. La mise en place de ce contrat nécessite des deux acteurs un paramétrage des services, des tests avant la mise en production. Ces actions doivent être menées en avance de phase, ce qui limite les usages des API.

Cependant, les TMS proposent des services d’API pour faire les liens avec le système d’information des entreprises. Les deux services proposés à travers les API sont :
• La mise à disposition ou la diffusion des relevés (de comptes, d’impayés…) auprès des applications métiers,
• L’émission des paiements depuis les services « métiers », les entreprises commencent à mettre des « hubs » pour l’émission, la mise aux formats selon la norme XML et l’émission des fichiers selon les typologies d’ordres (SCT, SDD…). Les TMS apportant les services de suivis et de signature des ordres.
Cette mise en œuvre d’API, bien que demandant de la structuration, permet de rendre communiquant les applications et les échanges avec une tendance vers le temps réel en s’affranchissant des règles d’interface selon des planifications de production.

Le service des API est en marche…, il est lié au monde digital, à l’évolution des systèmes d’information vers le temps réel, à la standardisation des messages avec SWIFT et aux maîtrises par les différents acteurs (FINTECH, agrégateur, entreprises…). Dans un mode de plus en plus digitalisé, les API seront indispensables pour permettre au Système d’information les échanges temps réel entre les applications.

SWIFT normalise les API sur les extraits comptables et pré comptables

« Instant Treasury Cash Reporting API » est une initiative Swift qui a pour objectif de répondre aux besoins principaux de gestion de trésorerie et de Cash Management, via des services qui vont permettre aux banques et aux entreprises d’obtenir des informations sur les comptes et sur les écritures, à la demande et en temps réel.
Les nouveaux services ont été définis, courant 2021, par des groupes de travail constitués de huit banques (CITI, ING, BNPP, SG…), d’éditeurs (Kyriba, SAP…) et de grandes entreprises. Ces API s’adressent aux banques et aux entreprises multibancarisées et devraient être opérationnelles à partir de la fin du premier semestre 2022.
Les atouts de ces services sont principalement la disponibilité, la transparence, l’homogénéité et l’instantanéité. Pour bénéficier des atouts business des API et favoriser l’adoption de cette solution, il est essentiel que les API soient implémentées de la façon la plus large possible par l’écosystème.

Dans ce cadre, l’initiative Swift définit un standard, basé sur le modèle de données ISO 20022, et permet de proposer une expérience utilisateur uniformisée. Les services donnent accès à des informations sur les comptes, dont les positions (comptables, intermédiaires) et sur les écritures (avec les niveaux Entry, EntryDetails, TransactionDetails, valorisés en fonction du mode de comptabilisation de l’opération).
Ils s’appuient sur cinq « end points » autonomes présentant différents niveaux de granularité (liste des comptes avec les positions comptables et intraday, détail d’un compte, cumul des écritures sur une période, détail des écritures sur une période, l’ensemble des écritures et des positions sur une période).
L’historique des données remonte sur une année. Les informations principales sont obligatoires. Elles peuvent être complétées par des informations optionnelles (sur souscription). Les contraintes de temps de réponse et de disponibilité seront partagées dans un souci d’harmonisation des services.
Le modèle économique, quant à lui, devra préserver les intérêts de part et d’autre et en particulier la relation commerciale entre l’entreprise et sa banque. Dans ce cadre, l’entreprise devrait contractualiser avec Swift et avec sa banque.

Ces nouveaux services contribuent à l’optimisation de la gestion de trésorerie et à la rationalisation du Cash Management. Ils permettent d’établir des standards en termes d’expérience client, qui pourraient se généraliser à d’autres périmètres. Ils devraient s’imposer sur le périmètre de la clientèle Swift.

1. Quelles grandes évolutions voyez-vous prochainement dans l’univers du paiement ?

Dans le domaine du paiement, il y a eu trois évolutions récentes. La première concerne les paiements électroniques : ils connaissent un rebond post-pandémie. Même en prenant en compte la baisse des volumes générale induite par la crise du covid-19, le rebond est significatif. Il s’explique par les nouvelles habitudes de paiement prises par les consommateurs. Pour des raisons d’hygiène, ces derniers ont beaucoup plus utilisé les cartes, et beaucoup moins les espèces et les chèques. Ainsi, à la reprise de l’activité, les consommateurs et les commerçants ont continué avec les habitudes de consommation développées pendant la pandémie. La seconde évolution concerne l’augmentation de l’utilisation du sans contact. Toujours pendant la pandémie, le plafond a été relevé de 30 euros à 50 euros, ce qui a contribué à la popularité de ce moyen de paiement parmi les consommateurs et les commerçants. Enfin, la troisième évolution notable concerne le
e-commerce : là encore, les habitudes prises pendant le confinement ont perduré. Ce domaine connaît une très forte utilisation de standards techniques et notamment d’API.

2. Et au niveau de la standardisation des solutions de paiement et des API notamment ?

Tous les travaux de standardisation suivent les trames précédemment évoquées. La hausse de l’usage du paiement sans contact entraîne un besoin renforcé de standardisation. Et ce notamment pour répondre aux besoins de tous les styles de paiements surtout pour le sans contact et là il faut également s’adapter à tous les schemes : CB, Visa, Mastercard, American Express, Discover, JCB, UnionPay, etc. En outre, même si les touristes n’ont pas été aussi nombreux que les années précédentes, ils sont en train de revenir et amènent avec eux de nouveaux challenges de standardisation. En effet, en France aujourd’hui, c’est la carte qui vérifie le PIN. Dans un scénario de paiement sans contact généralisé, en revanche, le PIN se vérifie plus facilement en ligne sur des serveurs. UnionPay par exemple, utilise beaucoup cette technique. Cette étape est très importante pour l’ergonomie des paiements internationaux mais également domestiques. Le déploiement FRv6 s’inscrit dans cette logique.
Au-delà de la standardisation, le secteur dans lequel les API ont une importance conséquente est l’e-commerce. C’est la raison pour laquelle nous avons compilé tous les besoins des schemes et les besoins réglementaires pour en faire une spécification technique commune que l’on appelle le MPADS (Manuel des paiements à distance sécurisés). Ce dernier permet aux développeurs de solutions d’être en phase avec toutes les exigences des schemes ainsi qu’avec les exigences réglementaires, notamment l’authentification forte, et de s’intégrer dans l’écosystème français du paiement. Cela permet également d’offrir le choix d’application en ligne avec les dispositions réglementaires dites IFR, tant au consommateur qu’au commerçant. Pour toutes ces raisons, il est primordial que les développeurs suivent cette spécification.

3. Et dans ce cadre, quelles sont, selon vous, les perspectives pour les API à moyen terme ?

 Dans le commerce électronique, les API sont en fait une perspective à court terme : elles sont utilisées dans tous les développements d’applicatifs e-commerce, mais également entre les banquiers acquéreurs et leurs commerçants, ou encore en interbancaire. Par exemple, ces API commencent à être utilisées dans le protocole de sécurité 3D Secure. Et aussi, traditionnellement, les échanges interbancaires se faisaient sur la base de protocoles de messages — norme ISO8583 — mais ils évoluent vers le standard ISO20022, qui est une modélisation beaucoup plus évoluée. Nous avons déjà pu constater qu’entre cette dernière et le mode de fonctionnement des API, il est très facile de passer de l’un à l’autre, de faire des conversions. Dans ce contexte, le passage à l’utilisation d’API est facile, voire naturel. Ainsi, l’utilisation de plus en plus massive d’API semble être la perspective la plus probable dans le domaine de la monétique tout comme dans celui des virements instantanés et de leurs initiations. Nous travaillons beaucoup sur ce sujet à niveau européen dans le cadre de notre nouveau consortium EPEC (European Payment Experts Consortium) avec nos partenaires allemands de la société SRC.