Une approche pratique du reporting Solvabilité II de bout en bout dans Databricks

Le reporting Solvabilité II n'est pas seulement une soumission réglementaire. C'est un processus métier qui connecte les données, les modèles, les contrôles, les approbations et le contenu narratif au sein d'un assureur.

Solvabilité II est le cadre réglementaire basé sur le risque de l'EU pour le capital, la gouvernance et la publication d'informations des assurances (conservé au UK sous le nom de Solvency UK). Il impose aux assureurs d'évaluer et de communiquer leur situation financière à l'aide de données, de modèles, de contrôles, d'approbations, de l'évaluation interne des risques et de la solvabilité (ORSA) et des publications réglementaires afin de prouver qu'ils peuvent respecter leurs obligations envers les assurés.

En pratique, le reporting Solvabilité II est un processus métier de bout en bout qui connecte l'ingestion des données, le provisionnement actuariel, le calcul du capital, les modèles de rapports quantitatifs (QRT), l'ORSA, les approbations de gouvernance et la publication d'informations, le tout dans le respect de délais réglementaires stricts.

Le défi réside dans le fait que ce processus est souvent réparti sur de nombreux systèmes, équipes, sources de données et sites. Lorsque ces éléments ne sont que lâchement connectés, il devient difficile de maintenir une vue gouvernée unique du cycle de reporting, ou de répondre à une question métier transversale.

Une démo Databricks, présentée par Laurence Ryszka, Architecte de solutions senior Assurance chez Databricks, illustre ce à quoi ce processus pourrait ressembler lorsqu'il est implémenté de bout en bout : de l'ingestion et du provisionnement jusqu'au calcul du capital, au reporting, à la gouvernance et à la publication.

Pourquoi le reporting Solvabilité II est difficile à gérer

De nombreuses implémentations de Solvabilité II ont été assemblées au fil du temps. Différentes équipes gèrent différentes parties du processus, les données arrivent à des rythmes différents et les activités de reporting peuvent être réparties sur plusieurs systèmes et emplacements de données. Une personne supervisant le processus peut être responsable de la soumission finale sans disposer d'une vue connectée unique de tout ce qui se passe en arrière-plan.

Cette fragmentation crée des problèmes spécifiques et récurrents :

• Un flux de données arrive en retard et nécessite un suivi manuel pour identifier son propriétaire et évaluer l'impact
• Une règle de qualité des données échoue et les lignes affectées nécessitent une décision de traitement avant que le workflow ne puisse continuer
• Deux QRT peuvent ne pas concorder
• L'approbation d'un modèle peut bloquer un workflow automatisé
• La direction pose une question de scénario, par exemple ce qu'il advient du ratio de solvabilité si l'assureur double son portefeuille cyber au cours des 12 prochains mois, et y répondre nécessite que les données, les modèles, les calculs de capital et les résultats de reporting fonctionnent ensemble.

Chaque problème entraîne les équipes dans des investigations distinctes et une coordination entre plusieurs outils. La soumission est effectuée, mais le processus demande un effort important et reste difficile à surveiller.

Comment Databricks prend en charge le reporting Solvabilité II de bout en bout

Databricks fournit une plateforme unique sur laquelle l'ensemble du cycle de reporting Solvabilité II peut être implémenté sous la forme d'un workflow gouverné unique. L'approche couvre l'ingestion des données, les contrôles de qualité, le provisionnement actuariel, le calcul du capital, la production des QRT, la rédaction de l'ORSA, la gouvernance et la publication.

Il ne s'agit pas d'un choix exclusif. La plupart des assureurs utilisent des suites de modélisation actuarielle et de capital bien établies, et ces systèmes restent en place. Databricks agit comme la couche gouvernée de données, d'orchestration et de reporting qui les entoure : en préparant leurs entrées, en consommant leurs sorties et en connectant les deux dans un processus surveillé unique.

Les sections suivantes décrivent le fonctionnement de chaque partie de ce workflow.

Une vue de contrôle unique pour le cycle de reporting

Au centre du workflow se trouve une tour de contrôle. Elle offre un espace unique pour surveiller le ratio de solvabilité actuel, l'état de préparation pour la date limite de reporting, les approbations, les flux en retard et les problèmes en suspens. Les variations du ratio peuvent également être associées à l'événement correspondant, ce qui aide les utilisateurs à comprendre ce qui a changé plutôt que de simplement constater que le chiffre a bougé.

Cette vue transforme le modèle opérationnel : au lieu de courir après les mises à jour auprès des différentes équipes, on travaille à partir d'une vision partagée du processus. Un flux en retard peut être associé à son propriétaire. Un blocage d'approbation peut être mis en évidence à côté du workflow qu'il affecte. Un problème de reporting peut être analysé depuis le même endroit où l'état de préparation global est surveillé.

Contrôles d'ingestion automatisés et contrôles de qualité des données

L'ingestion dans le workflow est automatisée. Les données sont récupérées dès qu'elles sont disponibles et vérifiées immédiatement.

Les premiers contrôles couvrent les signaux opérationnels de base tels que la fraîcheur, l'exhaustivité et la propriété. La fraîcheur indique si un flux est arrivé à l'heure prévue. L'exhaustivité vérifie que les enregistrements et les champs attendus sont présents, avec des volumes comparés aux chargements précédents. Propriété permet d'identifier clairement qui est responsable d'une source lorsqu'un suivi est nécessaire.

Les règles de qualité des données constituent une autre ligne de défense. Les contrôles sont personnalisables, et une règle qui échoue peut être signalée pour examen. Les équipes peuvent ensuite décider de la manière de traiter les lignes affectées (par exemple, les accepter, les rejeter ou les mettre en quarantaine) en fonction de seuils adaptés à leur processus.

Le workflow prend également en charge le rapprochement entre les QRT. Dans la démo, un agent AI examine un écart entre deux modèles et l'attribue à des facteurs de développement obsolètes provenant du flux de provisionnement vers le calcul du capital. Il propose ensuite un plan de remédiation. Le point important n'est pas qu'un agent remplace l'examen humain, mais plutôt qu'il peut se concentrer sur un problème spécifique et offrir au réviseur un second regard utile.

Gestion des modèles, approbations et pistes d'audit

Le reporting Solvabilité II ne dépend pas uniquement du mouvement des données. Il repose également sur des modèles, des approbations et des preuves que le processus a été correctement mené à bien.

La démo inclut des modèles de provisionnement gérés dans Databricks avec MLflow. Elle montre également comment des suites de modélisation actuarielle et de capital établies (telles que Prophet, RAFM ou Igloo) peuvent être orchestrées au sein du même workflow : Databricks prépare les données que ces moteurs consomment, ingère et gouverne leurs sorties, et achemine les résultats jusqu'au reporting. Les moteurs de modélisation restent là où ils sont ; le workflow qui les entoure devient connecté et surveillé. Lorsqu'un nouveau modèle de provisionnement ou un nouvel étalonnage est en attente d'approbation, le workflow met en évidence le blocage et l'action requise pour le débloquer.

gouvernance sont enregistrés tout au long du processus, y compris les promotions, les approbations et les activités liées aux rapports. La piste d'audit offre aux utilisateurs une vue de ce qui s'est passé, de ce qui est en attente et des workflows qui nécessitent une attention particulière.

La démo inclut également la gouvernance de l'AI. Les agents ont des champs d'action restreints et accèdent aux données pertinentes pour leurs tâches. Leur activité est enregistrée, y compris ce qu'ils utilisent et créent. Les agents fournissent des recommandations ; ils ne prennent pas de décisions à la place du réviseur.

Un agent d'orchestration AI peut orienter une question plus large vers les agents compétents. Par exemple, une question sur ce qui reste en suspens pour une clôture trimestrielle peut être adressée aux agents qui détiennent les informations pertinentes. Genie, l'interface en langage naturel de Databricks pour interroger les données, peut également être utilisée pour poser des questions directement aux tables sous-jacentes.

Rédaction de l'ORSA et analyse de scénarios

Le workflow de reporting peut également prendre en charge l'analyse narrative et de scénarios.

L'ORSA est différent d'un QRT numérique. Il s'agit d'un processus continu dans lequel un assureur évalue ses besoins globaux de solvabilité et son profil de risque, et son résultat est un rapport narratif qui nécessite généralement une contribution importante des équipes actuarielles et de gestion des risques. Dans la démo, un grand modèle de langage (LLM) génère un projet de rapport ORSA basé sur les chiffres actuels, offrant à l'équipe un point de départ qui est ensuite examiné et contesté par ces équipes. Le workflow comprend également des tests de résistance et de scénarios.

L'exemple du portefeuille cyber montre comment cela peut répondre à une question métier concrète. Le scénario exécute une projection dans Databricks et renvoie une réponse sur ce qui pourrait se passer si le portefeuille cyber doublait au cours des 12 prochains mois. Un second agent AI agit en tant qu'examinateur de capital contradictoire, conçu pour offrir une vision alternative du résultat et mettre en évidence des défis qui pourraient ne pas être visibles à partir du seul ratio de solvabilité.

C'est là toute la différence entre de simples données de reporting et un processus de reporting opérationnel. Le même workflow gouverné qui produit les résultats de la soumission peut également aider les équipes à explorer la signification de ces résultats dans le cadre d'un scénario différent.

Ce qui change avec une approche de bout en bout

Une implémentation de bout en bout ne supprime pas le besoin d'expertise réglementaire, d'examen actuariel ou de responsabilité métier. Elle offre simplement à ces équipes une manière plus connectée de travailler.

Grâce à une vue de contrôle unique, les équipes peuvent suivre l'état du processus, notamment les retards d'alimentation, les problèmes de qualité des données, les approbations et les points de blocage. Grâce aux contrôles automatisés et à l'aide au rapprochement, elles peuvent passer plus rapidement d'une alerte à une explication. Grâce à la gouvernance et aux pistes d'audit, elles conservent une visibilité totale sur les actions et les recommandations qui ont façonné le processus.

Le résultat est un workflow plus facile à surveiller et à analyser, tout en permettant de répondre à des questions qui dépassent le cadre de la simple soumission. Au lieu de traiter Solvabilité II comme un ensemble de tâches déconnectées, les assureurs peuvent le gérer comme un processus métier unique et gouverné.

De l'obligation de reporting à l'aide à la décision stratégique

Solvabilité II rassemble les données, les modèles, les contrôles, les approbations et les publications. Lorsque ces éléments sont fragmentés, la moindre question simple, comme l'impact du doublement d'un portefeuille cyber (le portefeuille d'assurance cyber d'un assureur), peut nécessiter une coordination complexe.

Un workflow connecté dans Databricks permet de regrouper ces activités au sein d'un processus unique : contrôles d'ingestion automatisés, vue de contrôle de l'état de préparation et des points de blocage, approbations gouvernées, pistes d'audit et révision assistée par l'IA. Cela ne remplace pas l'expertise réglementaire ou actuarielle. Cela donne à ces équipes une vision plus claire du processus et des bases plus solides pour explorer différents scénarios métier.

Regardez la démo complète et l'analyse approfondie de nos experts lors de notre Insurance Virtual Industry Forum – Des données aux décisions : comment les grands assureurs déploient l'IA à l'échelle sur toute la chaîne de valeur.

Foire aux questions

Qu'est-ce que le reporting Solvabilité II ?

Le reporting Solvabilité II est le processus par lequel les assureurs prouvent aux régulateurs qu'ils détiennent suffisamment de capital et gèrent les risques de manière appropriée. Il englobe les soumissions quantitatives (QRT), l'ORSA et les publications publiques, le tout s'appuyant sur des données, des modèles et des approbations gouvernés.

Que comprend le reporting Solvabilité II de bout en bout ?

Le reporting Solvabilité II de bout en bout connecte l'ingestion des données, les contrôles de qualité, le provisionnement, le calcul du capital, les QRT, l'ORSA, la gouvernance, les approbations et les publications afin que les assureurs puissent suivre l'état de préparation et analyser les anomalies.

Comment Databricks peut-il faciliter le reporting Solvabilité II ?

Databricks offre une plateforme unifiée pour l'ensemble du cycle de reporting Solvabilité II. Databricks permet de disposer d'une vue de contrôle gouvernée pour les ratios de solvabilité, les retards d'alimentation, les problèmes de qualité des données, les approbations, les échéances, les workflows de modèles et les pistes d'audit.

Comment l'IA peut-elle aider pour le reporting Solvabilité II ?

L'IA peut identifier les écarts de rapprochement, suggérer des mesures correctives, rédiger le contenu des rapports ORSA et répondre aux questions sur l'ensemble des données de reporting. Les réviseurs actuariels, réglementaires et métiers restent responsables des décisions et des approbations.

Les données de Solvabilité II peuvent-elles servir à l'analyse de scénarios ?

Oui. Les assureurs peuvent utiliser les données de reporting et les calculs de capital pour évaluer des scénarios, comme le doublement d'un portefeuille cyber, et analyser les impacts potentiels sur le ratio de solvabilité au sein d'un processus gouverné.

Databricks remplace-t-il les systèmes de modélisation actuarielle tels que Prophet, RAFM ou Igloo ?

Non, Databricks ne remplace pas Prophet, RAFM ou Igloo. Databricks s'articule autour des suites de modélisation actuarielle et de capital existantes plutôt que de les remplacer. Il prépare les données utilisées par ces moteurs, exploite et gouverne leurs résultats, et les connecte au sein d'un workflow de reporting unique de bout en bout, doté de contrôles, d'approbations et de pistes d'audit partagés.

Qu'est-ce qu'un QRT dans Solvabilité II ?

Un QRT, ou quantitative reporting template, est un formulaire de données standardisé que les assureurs soumettent aux régulateurs dans le cadre de Solvabilité II. Les QRT couvrent le bilan, le capital, les primes, les sinistres et d'autres données financières. Le rapprochement entre les QRT est une source fréquente d'anomalies de reporting ; le workflow Databricks prend en charge des contrôles de rapprochement automatisés et la révision assistée par l'IA des écarts constatés.

Qu'est-ce que l'ORSA dans Solvabilité II ?

L'ORSA, ou own risk and solvency assessment, est un processus continu requis par Solvabilité II dans lequel les assureurs évaluent leurs besoins globaux de solvabilité, leur profil de risque et leur conformité aux exigences de capital. Son résultat est un rapport narratif, distinct des QRT chiffrés, qui nécessite généralement une contribution importante des équipes actuarielles et de gestion des risques. Databricks facilite la rédaction de l'ORSA grâce à un LLM qui génère un premier projet basé sur les données de reporting actuelles, destiné à être révisé par ces équipes.

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original