Etude de cas : du reporting à la mesure du risque, BNP Paribas fait confiance à Sybase IQ


Rédigé par le 4 Mai 2005

A la fin de l’année 2000, Emmanuel Hulin, chef de projet chez BNP Paribas prend ses fonctions londoniennes avec plusieurs projets sous sa responsabilité, dont la modernisation d’une application de calcul et d’édition de reporting du P&L (Profit and Loss, le compte de résultat en quelque sorte) de l’ensemble des positions de trading dans le monde. Cet outil, employé par le middle-office des salles de marché de la banque, soit une quinzaine de salles dans le monde, connaissait de grosses difficultés. « Cette application a toujours rencontré des problèmes de performance. Nous connaissions le diagnostic : beaucoup de manipulations de données étaient réalisées directement sur la base de données via des procédures stockées ou par l’intermédiaire de requêtes SQL, auxquelles s’ajoutaient les requêtes d’un bon nombre d’utilisateur Business Objects », expose Emmanuel Hulin. Une situation hélas classique dont le principal handicap revenait aux temps de réponses variables, voir mauvais, qui alimentaient le mécontentement circonstanciel des utilisateurs. Une étape préalable au projet consistera en l’assainissement du modèle de données.



L’histoire se répète

Une rencontre avec IQ, quelques années plus tôt, n’avait pas porté ses fruits. Le produit fraîchement passé sous la coupe de Sybase avait alors été jugé trop jeune, mais Emmanuel Hulin avait conservé la bonne impression laissée par IQ à cette occasion, sentiment qui sera rapidement mis à profit. « Je me souvenais que les concepts portés par IQ étaient particulièrement bons. Par ailleurs, l’application dédiée au calcul du P&L tournait déjà sur Sybase ASE » explique-t-il. En 2003, BNP Paribas décide d’utiliser IQ sur le projet, « afin de garantir de bons temps de réponse aux utilisateurs, nous avons décidé de dissocier la base de production de la base de reporting sur IQ, et de procéder à une alimentation continue tout au long de la journée » poursuit-il. Le projet suivra son cours jusqu’à sa mise en production en 2004 et s’il est appelé à d’autres fonctions, Emmanuel Hulin reste toutefois en contact avec l’équipe et se fait l’écho d’un bilan très satisfaisant « l’application de reporting des P&L, résultat du travail entrepris sur le modèle de données et du support de IQ, est sans comparaison avec la situation antérieure. Les gains s’expriment à travers des temps de réponse améliorés en moyenne par un facteur de 5 à 10. L’effet est particulièrement frappant, aucun rapport ne dépasse désormais la minute, alors qu’auparavant les délais se situaient le plus souvent entre 2 et 10 minutes (avec des « pointes » pouvant aller jusqu'à 30 minutes), et même parfois des abandons par saturation des ressources. Au-delà, il y a le ressenti des utilisateurs. De lassitude en exaspération, ils finissaient par perdre confiance dans le système. Cinq minutes c’est énorme lorsque vous attendez une réponse de votre outil de travail ! Aujourd’hui, l’application ne fait plus parler d’elle et je crois qu’en informatique c’est un gage de réussite ! ».

La table centrale qui totalise 200 millions de lignes, est la cible de 95 % des requêtes. Emmanuel Hulin reconnaît que IQ tient les promesses de son éditeur « la rapidité d’une part mais aussi et c’est particulièrement important dans le contexte du reporting P&L, la faible sensibilité de l’outil au nombre d’utilisateurs connecté simultanément comme au volume brut des données. Le fait que IQ ne soit pas linéairement dépendant du nombre de lignes s’avère particulièrement important lorsque l’on réalise des agrégats ». Mais tous les outils sont perfectibles et IQ n’échappe pas à la règle « IQ reste un peu faible sur les mises à jour. Pour conserver des performances correctes, il nous a fallu configurer le moteur, optimiser les requêtes, mais pour être honnête cela constitue un moindre souci. Un autre point vient du fait qu’il n’y ait qu’un seul port ouvert en écriture à la fois sur la base. Nous parvenons à pousser de gros volumes de données, mais cela créé un goulet d’étranglement », poursuit-il. Chaque jour, nous avons 9 millions de nouvelles lignes, autant de lignes supprimées, et les mises à jour concernent approximativement 40 millions de lignes » développe Emmanuel Hulin.

Transcription d’un métier

Le reporting sur les positions de trading dans le monde revient à établir une évaluation du gain net réalisé par le front-office. Les chiffres correspondent aux gains et pertes enregistrés sur les positions en cours. « Quotidiennement, nous calculons le gain ou la perte sur chaque position, sur chaque portefeuille. Les traders surveillent la position de leurs portefeuilles en permanence, sachant qu’ils sont aussi rémunérés sur cette base. Par ailleurs, à la fin de chaque mois, la banque doit déclarer des résultats comptables qui correspondent à l’état de ses positions. Ce résultat comptable, il est nécessaire de le suivre et de le valider au quotidien, de maintenir l’information à jour. De nombreux paramètres interviennent qui justifient des écarts parfois importants et si l’information n’est pas maîtrisée au fil de l’eau cette gestion devient très vite impossible à mener dans de bonnes conditions » expose Emmanuel Hulin.

La boucle est bouclée

Les informations qui alimentent le datawarehouse, via le back-office, proviennent de toutes les applications qui participent à ce résultat. Chaque utilisateur de cette information, trader et middle-office, peut contrôler que ce qu’il imagine comme étant la situation de sa position correspond bien à la situation gérée par le back-office. Cent à cent cinquante utilisateurs accèdent à la base, essentiellement via Business Objects et quelques modules périphériques destinés, par exemple, à saisir des ajustements (visibles bien sur depuis Business Objects) dans la base. Enfin, la base renvoie également les informations vers d’autres applications et notamment vers la comptabilité. En terme de volumétrie, les 200 millions de lignes et 50 colonnes abritent un contenu majoritairement composé d’identifiants et de valeurs numériques.
Le département finances, en charge de la vie de l’application, assure la préparation d’un ensemble de rapport pré-établis pour le middle-office. « Ces derniers ont peu d’occasion de construire leurs propres rapports. Ils le peuvent en cas de besoin et dans la mesure où le système leur est accessible. Mais l’usage se borne le plus souvent aux rapports officiels. Ceux qui se lancent dans la constitution de requêtes peuvent désormais le faire sans mettre en danger le système car avec IQ, le bonheur est justement dans la fiabilité des temps de réponse » souligne Emmanuel Hulin.
Un autre sujet de satisfaction est fourni par la faible gourmandise de IQ, qu’il s’agisse de l’espace disque ou du temps machine. « Nous avons très nettement constaté et apprécié cette qualité dans la mesure ou l’application précédente consommait traditionnellement au moins une machine par an, conséquence de la croissance des volumes de données. Ajoutez à cela la multiplication des requêtes et leurs délais… aucune machine ne résiste longtemps. La capacité machine n’était jamais suffisante et rapidement cette montée en puissance coûte très cher. Aujourd’hui, nous disposons d’une marge confortable et avec la réduction des temps de réponse, la base travaille moins » poursuit-il.
Signe de reconnaissance, cette expérience ouvre d’autres portes à IQ au sein de BNP Paribas avec un second puis un troisième projet.

Le risque de marché

Plus récent, le second projet, intitulé MRX pour Market Risk eXplorer s’inscrit sur le même type de problématique. « Les besoins associés à la mesure du risque de marché restent finalement proches de ceux liés au P&L. Il s’agit de déterminer la sensibilité au risque (VaR, ou Value At Risk) d’une position, d’un portefeuille. Cette mesure répond à différents paramètres et fait l’objet d’un reporting. En revanche, l’application fait intervenir des notions plus quantitatives, elle implique des calculs, son fonctionnement est en cela plus complexe. L’exploitation des résultats reste comparable avec l’application P&L, toutefois les utilisateurs n’emploient pas Business Object mais leurs propres applications (Visual Basic ou Web) pour naviguer dans les positions et récupérer leur chiffres » évoque Emmanuel Hulin. Si le premier projet était majoritairement orienté vers la constatation, le second est axé sur la simulation. Le risque de marché consiste à déterminer le montant maximum que la banque peut éventuellement perdre dans un certain intervalle de confiance, lié à l’évolution de paramètres de marché tels que les taux, le cours des devises, etc. « Nous simulons l’évolution de ces paramètres de marché sur un jour. Toute la difficulté revient à construire ces modèles de projection. Puis en fonction de cette vision de l’avenir et de la sensibilité respective des portefeuilles aux différents paramètres de marché, nous allons donner une estimation, générale et particulière, du risque potentiel consécutif à l’évolution de ces paramètres de marché sur la journée. En conséquence, nous saurons déterminer la somme dont la banque doit disposer pour couvrir le risque » poursuit-il.

Le choix de IQ pour supporter ce domaine d’application tient notamment aux résultats du premier projet. Le besoin avait été rempli et donnait satisfaction. Par ailleurs, l’application MRX s’appuie en l’état sur Sybase ASE, donc comme pour le premier projet la migration se fera entre deux environnements Sybase. « IQ stockera à terme l’ensemble des positions de trading dans le monde, avec la faculté de naviguer et de « plonger » dans les données suivant plusieurs dimensions : portefeuilles, positions, type de risque, date de trading, émetteurs (pour les obligations), …. L’objectif est ainsi de faciliter l’identification des éléments qui ont contribué à un dépassement de VaR. Les gains vont se jouer sur la performance qui n’a pas encore été mesurée, même si elle est déjà constatée sur l’espace disque. Sur ce point le gain est estimé à 90 % sur les deux plus grosses tables » explique Emmanuel Hulin.

Prochain projet : le risque de crédit

De proche en proche, un troisième projet est inscrit au calendrier commun BNPParibas / Sybase avec Valrisk, application dont Emmanuel Hulin a actuellement la charge, « il s’agit d’affiner le calcul d’exposition de la banque en risque de crédit ou risque de contrepartie et qui équivaut au manque à gagner pour la banque si un client fait défaut. C’est un risque au moins aussi important que le risque de marché mais qui a longtemps été plus difficile à quantifier. Nous simulons l’évolution de paramètres de marchés avec une projection à 50 ans et, à intervalles réguliers nous procédons à une réévaluation de l’ensemble de la position en prenant en compte les deals, les données de marché simulées et le cadre légal (accords de netting et de collatéral). Le cadre réglementaire lié à ce domaine du risque de crédit se renforce. Bien adapté aux opérations simples telles que les prêts par exemple, il est en revanche très conservateur en ce qui concerne les opérations plus élaborées. Le modèle de mesure de risque utilisé par les banques, qu’il s’agisse de risques de marché ou de crédit, est habituellement plus sophistiqué que le modèle par défaut, sachant bien entendu qu’il doit être validé par la Commission Bancaire. L’objectif reste de calculer de la manière la plus juste le montant de capital disponible pour couvrir nos risques. A terme, ce projet nous permettra également de procéder au « back-testing ». Il s’agit de prendre une mesure à un instant donné, d’établir une projection à 10 jours par exemple, et à ce terme de vérifier par la réalité la validité du modèle de projection. Le risque ne se mesure pas au doigt mouillé, il est impératif pour nous de valider, d’affiner et le cas échéant de rectifier nos modèles. Près de 400 000 deals (des « dérivés » : swaps, options, …) sont récupérés quotidiennement depuis le front-office et sur lesquels nous effectuons des simulations avec une moyenne de 100 000 réévaluations par deal. Il s’agit de faire jouer chacun des paramètres dans le temps et selon les différents scénarii. Sur ce projet, la contrainte n’est pas véritablement dans le volume de données stockées, mais bien dans les calculs. Contrairement aux deux projets précédents, le bénéfice de IQ ne jouera pas sur l’amélioration des performances mais sur la mise en place d’une fonction supplémentaire qui est l’archivage. Aujourd’hui, notre profondeur d’archive est de 10 jours en ligne. Nous souhaitons pouvoir conserver l’ensemble des informations sur une très longue période pour être en mesure d’analyser l’évolution des profils de risques, mais aussi d’analyser la corrélation entre l’exposition de la banque et les paramètres de marché ou la structure de nos positions. Ce projet est amorcé et nous devrions débuter l’archivage au cours du second semestre 2005 », conclut Emmanuel Hulin.



Dans la même rubrique :