Les API : une partie intégrante des services titres

API-sation

Devons-nous évoluer ? Si nous ne voulons pas être dépassés par nos concurrents, traditionnels ou disruptifs, la réponse est oui. Devons-nous apprendre à apprécier les API ? Si nous voulons continuer à répondre aux besoins des clients et optimiser l’offre de produits du secteur, la réponse est oui. Savons-nous comment procéder ? Si nous avons été suffisamment attentifs aux changements qui s’opèrent presque quotidiennement, la réponse est également oui.

Services en interne et services externalisés

Chaque prestataire devra se poser la question de savoir exactement qui fait quoi dans cet environnement en évolution. Vous pouvez essayer d’y répondre par vous-même. Vous pouvez également demander l’aide d’un partenaire. Le fait est que les API sont en train de modifier le contexte actuel.

De la messagerie aux API

Cela fait des décennies que les clients des grands groupes dépositaires utilisent SWIFT ou un format SWIFT pour envoyer leurs instructions de règlement. Mais une fois les instructions émises, traditionnellement, les clients étaient entièrement dépendants du personnel bancaire pour être tenus informés de l’état du règlement.

Avec l’arrivée d’Internet, les prestataires se sont mis à offrir des interfaces graphiques (Graphic User Interfaces – GUI) sur le web pour leurs services de transactions et de rapports. Simultanément, certains prestataires ont proposé des services web, une forme spécifique d’API uniquement disponible par le biais d’Internet. Les utilisateurs d’Internet ont maintenant l’habitude de naviguer sur des sites Internet qui intègrent des services web.

Généralement, un site web qui affiche un bulletin ou des prévisions météo fournit des informations extraites d’un serveur météo spécialisé par le biais d’un service web. Ainsi, les clients utilisent des API sur Internet sans même le savoir.

Une API est plus générique qu’un service web car on peut y accéder par différents canaux.

La sécurité des API

Les mots clés habituels associés à la sécurité des données s’appliquent aussi aux API. L’authentification, l’intégrité et la confidentialité concernent davantage le mode de transmission des informations que l’API en elle-même. Les deux principaux problèmes sont la disponibilité, étant donné la dépendance qui se crée envers un tiers, et qui pose la question de la continuité des activités, surtout pour les services essentiels, et la modularité, la question étant de savoir si le prestataire pourra réagir dans le délai convenu avec le client.

Instructions et rapports

Dans le meilleur des mondes des API, les clients peuvent envoyer leurs instructions, suivre leurs états et extraire différentes données pour l’établissement de rapports ; et ils peuvent faire tout cela directement à partir de leur propre système d’information.

Extension des fonctionnalités

La capacité à intégrer des fonctionnalités ou des données externes au cœur d’un système d’information élargit le champ des possibilités, notamment parce que la plupart des API sont conçues pour fournir une réponse à la demande en temps réel ou presque. Les systèmes d’information des clients peuvent être étendus grâce aux fonctionnalités proposées par les API de leurs prestataires. Pour illustrer cette idée, imaginons qu’on utilise un programme d’opérations d’arbitrage pour acheter et vendre systématiquement lorsque la différence de prix entre deux biens corrélés varie. Un tel programme se servirait des API pour extraire le prix des deux biens, envoyer l’ordre d’achat vers un marché et l’ordre de vente vers un deuxième marché, ainsi que pour suivre l’état d’exécution de ces ordres.

Enrichissement des données

Dans la mesure où les API peuvent servir à étendre la portée des fonctionnalités du système d’information, elles peuvent être utilisées pour enrichir les données, notamment pour ajouter des informations détaillées, dézoomer ou classifier.

En matière de données, les difficultés sont liées à la codification. Bien que l’ISO (Organisation internationale de normalisation) ait défini des normes largement adoptées, il existe de nombreux domaines dans lesquels aucune norme ne s’est imposée. Par exemple, la plupart des titres peuvent être identifiés grâce à un numéro international d’identification des titres (code ISIN), mais il n’existe aucun code officiel pour les produits dérivés cotés, donc chaque marché, compensateur ou fournisseur utilise sa propre codification.

Lorsqu’il n’existe pas de norme largement adoptée, il est nécessaire de tenir à jour des systèmes de transcodage ou bien des tables de correspondance. Ces systèmes pourraient également devenir des services accessibles par le biais des API.

Effet domino

Les clients vont de plus en plus s’associer aux prestataires de services afin de développer de solides capacités en API. Ces prestataires à leur tour feront équipe avec leurs propres fournisseurs, par exemple les dépositaires locaux, pour mieux répondre aux besoins de leurs clients en matière d’API.

Simple ou sophistiqué

D’un point de vue plus pratique, une API peut être conçue comme un service élémentaire ou bien comme un service plus large permettant d’extraire des donnéessélectionnées parmi un grand ensemble de données, ou encore comme un service à haute valeur ajoutée intégrant plusieurs services internes et externes. La plupart des clients préféreront disposer d’un seul élément à valeur ajoutée qui simplifie leurs opérations, mais les clients de plus grande taille ou aux activités plus confidentielles voudront bénéficier d’éléments plus simples à assembler et enrichiront l’information par eux-mêmes, notamment en faisant appel à d’autres fournisseurs. Les clients de plus petite taille préféreront externaliser l’intégralité du processus commercial plutôt que d’avoir à gérer un système d’information.

Des normes communes

Plaçons-nous dans un contexte international plus large : les API permettront aux prestataires d’offrir un service intégré de bout en bout. Un tel service intégré serait tout à l’avantage des clients, notamment si les prestataires de services s’accordent à utiliser des normes communes, plutôt que des « normes ouvertes » propriétaires, et à promouvoir l’interopérabilité.