La complexité d’un produit structuré exige qu’on en ait une vision globale. Qu’aucun paramètre n’échappe à l’attention du client. Pourtant, force est de constater qu’un bon nombre de gérants restent à la traîne dans le domaine des techniques de modélisation de tels produits. Leurs systèmes de gestion de portefeuille ou «portfolio management systems» (PMS) ne sont pas en mesure d’analyser des instruments auxquels sont rattachés des dérivés. Impossible de modéliser quoi que ce soit. Face à ce désert technologique se développent deux tendances, nous explique Alexis de Bernis, Chief Technology Officer chez SILEX. D’un côté, les brokers modernisent leurs plateformes dédiées aux produits structurés. De l’autre, des sociétés informatiques se lient aux brokers. Ou, simplement, les rachètent.

En quoi la technologie liée aux investissements dans les produit structurés diffère-t-elle de celles liées aux instruments et classes d’actifs plus traditionnelles?

Les produits structurés se sont largement popularisés et constituent un poids croissant dans les portefeuilles des clients. Pourtant, de tels produits ne rentrent pas dans les PMS et les systèmes automatisés. L’une des raisons en est que ces produits exotiques ne sont en général pas listés sur les marchés, bien qu’ils soient enregistrés et possèdent un code ISIN. Plus significatif encore, les produits structurés exigent un nombre de paramètres bien supérieur aux instruments classiques pour les modéliser.

Pour capturer une action, cinq ou six paramètres tels que le secteur ou le niveau de dividende sont suffisants. On monte à une douzaine de paramètres pour des obligations et des fonds, pour inclure les maturités et les classes d’actions etc. C’est-à-dire des paramètres facilement récupérables via des fournisseurs de données tels que Bloomberg, SIX, LSEG, Morningstar et d’autres… En revanche, pour les produits structurés, il faut souvent intégrer plusieurs dizaines de paramètres, chacun étant en outre unique.

«Cela peut surprendre, mais certaines banques ne disposent même pas d’API, la transmission des données s’effectuant par courrier électronique.»

En réalité, un produit structuré est comparable à un Lego sur lequel des ingénieurs appelés des «structureurs» ont décidé d’assembler des pièces en toute liberté. Ce qui veut dire qu’il est extrêmement délicat de les modéliser dans une base de données via un modèle tabulaire classique. Par exemple, dans le cas d’un autocall step down sur un panier worst-off, il faut connaître toutes les dates d’observation, les coupons, les barrières, les sous-jacents, les niveaux de fixing initiaux, les dividendes attendus, les dates de maturité, les conditions de rappel, sans parler du calendrier e paiement, qui est lui-même ajustables, pour ne citer que ces paramètres. Or il n’y a aucun fournisseur de données pour ces paramètres.

Dans ce cas, comment s’effectue aujourd’hui la transmission de données sur des produits dont il peut être délicat de savoir quels facteurs influent sur leurs valorisations à un moment donné?

A l’heure actuelle, la façon dont les informations liées à un produit structuré sont transmises entre une banque et son client se fait via un document PDF, qui est, comme vous le savez, la «termsheet». Le problème avec un tel document, qui est généré par la banque émettrice et pas nécessairement de façon automatisée, réside dans le fait que l’intégrer dans le système ne va pas de soi. Bien que les progrès dans le domaine de l’intelligence artificielle soient significatifs et rapides, des erreurs persistent. Or personne n’a droit à l’erreur lorsqu’il s’agit de modéliser un produit. De plus, il n’existe aucune base de données mondiales où il serait possible de trouver tous les paramètres d’un produit structuré. Il faut donc analyser chaque document PDF lié à un produit.

Ces difficultés rendent-elles le suivi ou la gestion du cycle de vie du produit d’autant plus compliquée?

Cette étape exige en effet de nombreux ajustements et des observations à un rythme quotidien, ce qui pèse sur les systèmes informatiques. Et, là encore, il n’existe pas de sources de données, en-dehors de celles fournies par les banques émettrices. Ce qui signifie qu’il faut coder ou développer des canaux d’intégration avec chaque banque, celles-ci ayant des API ou des modèles différents les unes des autres. Cela peut surprendre, mais certaines banques ne disposent même pas d’API, la transmission des données devant s’effectuer par courrier électronique. Par conséquent, en termes opérationnels, tout ceci est très lourd pour les systèmes informatiques des gérants.

Quel est l’état des technologies liées à l’analyse des risques d’un produit structuré?

Là aussi, l’exercice s’avère particulièrement délicat. Prenons un cas basique consistant à évaluer l’exposition sectorielle d’un produit. Il sera difficile d’extraire le niveau d’exposition d’un produit financier auquel est rattaché un dérivé, telle qu’une option exotique avec des barrières, c’est-à-dire des paramètres non-linéaires, et/ou ayant pour sous-jacent un panier qui n’est pas statique dans le temps. Cela exige des librairies mathématiques de pricing, développées par des quants au sein des banques et qui coûtent très cher. Ici, les données de marchés ne se limitent simplement aux prix, mais incluent celles calculées par le trading, telles que la volatilité implicite, la corrélation ou encore les attentes de dividendes. Il est pratiquement impossible d’obtenir ces données, dont le coût se chiffre en millions de dollars, à moins d’être une banque.

«Les PMS actuels sont incapables d’analyser ou de réaliser un reporting complet et correct sur un produit structuré.»

Comment surmonter ces défis technologiques, qui paraissent justement insurmontables?

Certains acteurs ont décidé de s’attaquer spécifiquement à la problématique liée à la modélisation des produits structurés. On peut notamment citer le cas de LexiFi, qui est un pure player au sein de l’industrie des produits structurés. Il s’agit d’une société de logiciels basée en France qui équipe un bon tiers des institutions financières actives dans les produits structurés. Ce sont les leaders mondiaux dans le domaine de la modélisation des produits structurés et leur expertise est telle que même Bloomberg a acheté leur technologie. Leur offre s’adresse principalement aux banques.

En ce qui nous concerne, notre plateforme digitale SPARK, contient des modules dédiés exclusivement aux produits structurés. Elle ne cible pas directement les banques, comme le fait LexiFi, mais les gérants de fortune pour le compte de leurs clients. Nous apportons de l’efficacité et de la simplification dans la vision globale du produit structuré. Car le problème des PMS actuels, c’est qu’ils sont incapables d’analyser ou de réaliser un reporting complet et correct sur un produit structuré.

Certains PMS viennent désormais nous voir afin de résoudre le problème de complexité extrême liée au développement de systèmes permettant la compréhension des produits structurés. Ceux-ci intègrent donc notre solution au sein de leurs PMS via une API pour l’échange des données. Un scanner de termsheets automatique va lire tous les paramètres de ce dernier, puis nous renvoyons les informations pré-calculées dont le PMS a besoin pour représenter le reporting, les événements, le risque etc.

Ce qui paraît paradoxal, à première vue, c’est que, d’un côté, de nombreux acteurs tentent de redévelopper la technologie leur permettant de couvrir toute la chaîne de valeur des produits structurés, tandis que, de l’autre, il semble que la spécialisation de pure players apportent des solutions plus fiables…

Notre vision est celle d’un écosystème. Elle repose sur la conviction qu’il ne peut plus y avoir qu’un seul provider assumant toute la chaîne de valeur verticalement. Nous estimons que le client est mieux servi grâce aux interconnexions réalisées entre des outils spécialisés via des API. Il est intéressant de souligner une tendance récente, à savoir que tous les acteurs technologiquement sérieux au sein des produits structurés, mettent en place des plateformes technologiques dédiées. Parmi les entreprises comparables à la nôtre, en Suisse et en France, environ la moitié sont concernées.

Toutefois, il s’agit souvent de plateformes développées en externe et à qui il manque généralement une API, qui est une composante essentielle. Ce défaut oblige le client à venir se connecter sur la plateforme pour être en mesure de visualiser les données du produit. Il manque donc cette intégration dans la vision globale du portefeuille, problématique à laquelle nous apportons une solution. Mais d’autres acteurs empruntent également cette voie, ce qui tendra à rendre notre champ d’activité de plus en plus concurrentiel mais en relevant le niveau d’investissements technologique nécessaires.

Par exemple, nous avons récemment constaté certains mouvements capitalistiques, tel que le rachat du broker digital français Feefty par le groupe Harvest, également français, le leader du marché dans le secteur des PMS pour les gestionnaires de patrimoine en France. Ils ont estimé qu’il était stratégiquement important de se doter de la partie technologique multi-service du broker, préférant racheter celui-ci plutôt que de former un simple partenariat. En un mot, le smart money au sein du wealthtech a déjà commencé à investir dans les produits structurés, celle-ci étant une classe d’actifs qui se démocratise et s’intègre de plus en plus dans les portefeuilles.