Mise en œuvre du FRTB : quels impacts sur les infrastructures bancaires ?

Avec la mise en oeuvre du Fundamental Review of the Trading Book, les plateformes de risque vont nécessiter une refonte complète pour répondre aux objectifs de performance et de latence.

La mise en œuvre de la « Fundamental Review of the Trading Book » (FRTB) va nécessiter des modifications importantes des infrastructures bancaires. Les implications en matière de volume de données et de calcul sont telles que les plateformes de risque vont nécessiter une refonte complète pour répondre aux objectifs de performance et de latence.

Afin de mettre en œuvre la « Fundamental Review of the Trading Book » (FRTB), les banques doivent satisfaire aux exigences imposées par « l’approche modèle interne » (IMA) et « l’approche standard » (SA). Une majorité des banques optera pour une approche IMA pour une grande partie de leurs activités de trading afin d’optimiser leurs besoins en capital, avec un calcul SA en parallèle pour validation.

Le respect des exigences de la FRTB oblige généralement à un remaniement important de l’infrastructure front-to-back pour faire face à l’augmentation d’un facteur 10 du nombre de calculs, à une augmentation tout aussi massive des volumes de données consommées et produites, et à la nécessité d’harmoniser l’utilisation des données et modèles de pricing et de risque dans une chaîne de traitement complexe.

Impacts technologiques de la FRTB

La FRTB aura plusieurs implications technologiques pour les banques, notamment :

L’augmentation massive du nombre de calculs : la FRTB modifie la modélisation du risque, et introduit des notions telles que l’Expected Shortfall, la « Standardized Approach » et le concept de « Non-Modellable Risk Factors » dans le calcul des besoins en capitaux. Ces modifications remettent en cause les approches courantes qui utilisent des optimisations basées sur les sensibilités, en contraignant à une réévaluation complète des portefeuilles. Cette exigence devrait entraîner une multiplication par dix du nombre de calculs P & L requis, à laquelle s’ajoute une tendance vers l’évaluation en temps-réel des tests de disponibilité des capitaux.

L’harmonisation des processus et formes de gouvernance : la FRTB encourage un réalignement de la gouvernance et des approches entre le Front Office et le département risques, impliquant une consolidation des moteurs d’évaluation. Cette tendance vient remettre en cause l’utilisation de packages d’éditeurs spécialisés, souvent dédiés à un desk spécifique en fonction des actifs négociés.

Le P & L et l’attribution des risques seront vérifiés au niveau des desks. Les exigences de cohérence impliquent une rationalisation des données de pricing et des librairies utilisées, indépendamment du desk et des lignes de reporting.

Les exigences de qualité des données et l’augmentation des volumes : la cohérence des prix et des calculs de risque dans l’ensemble de l’entreprise requiert l’utilisation d’un référentiel unique de données de marché, static data, courbes de volatilité…

Limitations des architectures existantes

Les banques dépendent généralement de différents systèmes Front-Office, chacun responsable d’un sous-ensemble des actifs. Il en résulte une infrastructure « en silo », où des rapports de risque distincts sont construits pour chaque plateforme.

Une approche consiste à déployer une solution de risque transverse, mais qui repose toujours sur les spécificités de chaque système sous-jacent concernant les algorithmes de pricing, les scénarios de choc, les facteurs de risque et les définitions de données de référence (yield-curves…) utilisés.

Ces différences se traduisent en écarts d’évaluation difficiles à expliquer entre les vues front, risque et finance, mais aussi en coûts d’infrastructure supplémentaires.

Spécifications des besoins systèmes

L’augmentation des calculs induite par l’implémentation de la norme FRTB va pousser de nombreuses grilles conventionnelles au-delà de leurs limites, augmentant ainsi la nécessité d’une refonte des systèmes de risque.

L’exigence de puissance de calcul et le passage à un modèle de risque unifié motive l’adoption de technologies et de modèles d’architecture qui (i) exploitent des grilles matérielles hautement parallèles et résilientes, éventuellement réparties entre des clouds privés et publics, (ii) favorisent la colocalisation des données et des traitements (mémoire partagée; idéalement en in-process) pour un traitement efficace des grandes volumétries de données, (iii) font levier sur les spécificités des plateformes techniques pour la planification des calculs, l’exécution des librairies de calcul natives ou l’exploitation des GPGPU, (iv) répondent aux exigences d’exécution quasi temps-réelle du Front-Office pour l’analyse décisionnelle et (v) permettent d’administrer finement les systèmes avec un environnement de développement et de déploiement compatibles avec les approches Agiles.

L’introduction de nouveaux composants d’architecture est l’opportunité de considérer les technologies soutenues par des projets open-source, réduisant l’effet silo (duplication, cohérence de modèle) qui résulterait de l’intégration de solutions de différents fournisseurs.

Solution design – le modèle d’acteurs

L’approche de conception « Reactive Software » couvre aussi bien la construction de microservices à grande échelle que celle d’applications au niveau process. Basés sur l’échange de messages asynchrones, il existe de nombreux modèles de programmation qui permettent de construire des logiciels réactifs. Le modèle à base d’acteurs en est l’un des principaux.

Les systèmes « réactifs » sont des systèmes logiciels qui satisfont aux 4 propriétés représentées dans le « Reactive Manifesto » :

• Réactif : aux actions utilisateurs et systèmes internes, en temps réel,
• Résilient : le système résiste aux erreurs par réplication, confinement, isolement et délégation,
• Élastique : le système s’adapte dynamiquement à la charge de travail,
• Piloté par messages : découplage, isolation et transparence du déploiement des systèmes par l’utilisation de messages asynchrones.

Le modèle d’acteurs est un modèle de développement qui utilise des « acteurs » comme unité de traitement, de développement et de test, et qui se prête naturellement aux traitements asynchrones, parallèles et distribués qui sous-tendent le modèle « réactif ». Les développeurs se concentrent sur la partie métier et un framework applicatif, dont l’exécution est paramétrable au déploiement, se charge de l’allocation de ressources.

Les besoins FRTB poussent les entreprises financières à reconsidérer leurs plateformes de risque, et à envisager le recours à des implémentations personnalisées. Alors que les banques construisent une vision de leur future infrastructure, leur conception doit refléter les critères décrits ci-dessus : réactive et évolutive, cohérence des sources de données, et efficacité de l’implémentation par l’utilisation de solutions techniques éprouvées. Les modèles à base d’acteurs en sont une solution toute désignée.

Tribune co-écrite avec Olivier Collard, principal consultant chez Capco