Modéliser la décision en banque et en assurance

Ce que coûte réellement une alerte

Prenez une alerte de correspondance bancaire sur un paiement sortant. La traiter suppose le système de paiement, l’entrée en relation pour les bénéficiaires effectifs, l’outil de gestion des cas pour savoir comment les alertes précédentes ont été closes, le filtrage pour la version de liste derrière le hit, le core banking, et un certificat de constitution en PDF sur un disque partagé. Six systèmes, quatre identifiants pour une seule personne morale, aucun n’étant une clé étrangère vers un autre.

Chaque champ existe, est correct, et a un propriétaire. Ce qui n’existe nulle part, c’est la jointure, alors un analyste l’effectue à la main et le raisonnement atterrit dans un champ de récit que personne ne peut interroger.

Pourquoi un agent devine ici

Lâchez un modèle sur ces tables et il écrit la jointure lui-même. La requête est différente le mardi, sans rien de figé à remettre à un validateur. C’est cela qui disqualifie ici, pas la fluidité. Aucune colonne ne dit à un modèle lequel des quatre identifiants désigne une seule personne morale, ni qu’un hit de filtrage se décide plutôt qu’il ne se compte.

Ce qui se déclare, dans l’ordre

Nommez d’abord les décisions, dans les mots de la personne qui les signe. Clore ou escalader cette alerte. Accepter, orienter ou instruire ce sinistre. Puis les finalités, car c’est la finalité et non l’intitulé de poste qui décide de ce que quelqu’un peut légalement voir : un validateur obtient les entrées du modèle, pas le nom du client. Chaque finalité est un rôle de base de données avec des droits au niveau colonne, si bien qu’une lecture hors de son périmètre échoue en erreur de base de données.

Ensuite seulement les entités sur lesquelles ces décisions portent, en général moins de vingt, et les liens entre elles, là où vivent réellement les questions. Puis les règles, chacune avec un code qui survit jusque dans l’enregistrement de décision : « activité incohérente avec le profil » est un récit, ce code avec les valeurs qui l’ont déclenché est un fait que l’on peut tester. Les actions en dernier. Chaque propriété se lie à une table et une colonne réelles dans une source, ce qui tue le modèle élégant d’une banque dont les données ne le portent pas.

Ce que l’agent peut faire ensuite

Donnez cette ontologie au même modèle et il cesse d’inventer la jointure. Il lit les paiements, l’entrée en relation, la gestion des cas et le filtrage là où ils se trouvent, sous la finalité au titre de laquelle l’analyste agit, et répond dans le vocabulaire de l’équipe avec la règle qui s’est déclenchée en dessous. Un modèle peut aiguiller : déterminer quelle décision est demandée est réellement difficile. Il ne doit pas calculer : la jointure, le filtre et l’évaluation de la règle tournent dans du code déclaré, si bien qu’un validateur revoit le contrat une fois, et non une requête régénérée à chaque run.

Rien n’est écrit sans approbation

Le traitement est une écriture : un statut, une motivation, parfois un blocage sur un compte. Dans Monarch, elle ne s’exécute jamais parce qu’un modèle a conclu quelque chose. Une action déclarée persiste comme approbation en attente, calcule un vrai diff à blanc, et patiente jusqu’à ce qu’une personne la valide ou l’écarte. Là où le core banking ne peut pas être écrit, la sortie est un enregistrement de décision qu’un humain porte de l’autre côté.

Le rejeu est ce qu’un validateur veut et qu’un log ne donnera pas. L’enregistrement conserve ses paramètres et une trace émise immuable : verdict, règles déclenchées, codes, périmètre, un hash. Le rouvrir redérive la décision sous les permissions du jour sans aucun appel au modèle et signale la divergence. Ce signalement recouvre quatre enquêtes différentes : la donnée a changé, la règle a changé, la liaison a changé, ou le périmètre du demandeur s’est resserré. Il répond aussi au droit à une explication utile de l’AI Act, car l’identifiant de la règle, les valeurs qui l’ont déclenchée et la provenance de chacune sont déjà dans l’enregistrement.

Deux limites honnêtes. Ceci rend l’altération visible, pas impossible. Et ce n’est pas le bon outil là où la décision ne traverse pas les systèmes, là où la valeur est un score à la latence de l’autorisation, ou là où personne ne portera l’ontologie. Déclarez les décisions avant les données, gardez le modèle hors du chemin de la justesse, et rendez chaque décision redérivable, y compris celles qui ne se reproduisent plus.