Un knowledge graph (KG) aide les banques à relier entités et relations pour répondre à des besoins concrets : vue client 360°, détection de fraude et soutien à la conformité AML/KYC. Les usages vont de l’enrichissement d’enquêtes à la traçabilité des données, avec des implémentations très différentes selon la taille et le parcours d’adoption de l’établissement.
Qu’est-ce qu’un knowledge graph ?
Un knowledge graph est une modélisation sémantique qui représente des entités et les relations entre elles. Le KG organise des personnes, comptes, contrats, documents et liens en un graphe joignable pour l’analyse et la navigation. Cette définition est utile pour distinguer rôle conceptuel et stockage technique.
La notion se distingue d’une base relationnelle classique : la structure met l’accent sur les relations explicites entre entités plutôt que sur des tables normalisées. Le KG se distingue aussi d’une base de graphes orientée performance : le premier est une couche conceptuelle et sémantique, la seconde est souvent un moteur et un stockage optimisé pour certains calculs.
Source : fr.wikipedia.org. Source : neo4j.com.
Pourquoi les banques s’y intéressent : enjeux métier et limites
Les enjeux métier qui poussent vers le KG sont la consolidation d’une vue client unifiée, l’amélioration des processus de lutte contre la fraude et la conformité AML/KYC, la traçabilité via data lineage, et l’enrichissement des services IA. Ces points sont documentés dans des publications d’éditeurs et de cabinets.
Un knowledge graph aide à présenter des relations multi-sauts et des contextes qui seraient difficiles à reconstituer dans des silos. Il facilite l’enquête en mettant en évidence des chaînes relationnelles et en offrant une indexation sémantique qui sert l’audit et la gouvernance.
Les limites et contraintes sont récurrentes. La qualité des sources conditionne la valeur du KG. La gouvernance devient centrale pour définir ontologies et règles de correspondance. La performance peut poser problème sur des volumes très importants. Enfin, l’exigence de compétences sémantiques et de modèles standardisés (par exemple des ontologies financières) est souvent citée comme un frein.
Source : deloitte.com. Source : thedatapraxis.com.
Cas d’usage concrets
Ce H2 détaille les cas d’usage principaux. Pour chaque cas, le paragraphe explique le contexte, les données à lier et l’apport concret du KG.
Customer 360 / KYC
Contexte : réunir identités disparates et documents KYC pour obtenir une vue consolidée. Données à lier : comptes, contrats, identifiants, documents KYC, notes et PDF. Apport du KG : consolidation d’identités, résolution d’entités et enrichissement des enquêtes grâce à la mise en évidence de liens faibles entre documents et entités.
Source : neo4j.com. Source : thedatapraxis.com.
AML & transaction monitoring
Contexte : surveiller les transferts et extraire sous-graphes suspects. Données à lier : transactions, comptes, relations entre comptes, métadonnées de transfert. Apport du KG : visualiser chaînes de transfert, exposer structures de relations et prioriser les alertes en montrant des parcours de fonds multi-sauts.
Source : neo4j.com.
Fraud ring detection
Contexte : détecter anneaux organisés impliquant adresses, appareils, IBANs ou identifiants. Données à lier : logs clients, identifiants techniques, informations transactionnelles. Apport du KG : mise en évidence de clusters et de motifs multi-sauts qui échappent à des règles transactionnelles isolées.
Source : tigergraph.com.
Entity resolution & beneficial ownership traversal
Contexte : comprendre les structures juridiques et la propriété effective pour le screening sanctions/PEP. Données à lier : entités juridiques, bénéficiaires effectifs, relations de contrôle. Apport du KG : traversée de hiérarchies juridiques et visualisation des liens entre personnes morales et physiques.
Source : thedatapraxis.com.
Data lineage, gouvernance et audit
Contexte : tracer provenance et transformations des données pour audits et conformité. Données à lier : sources de données, pipelines ETL, règles métier. Apport du KG : lier sources, transformations et règles métier pour faciliter les audits et documenter la traçabilité.
Source : deloitte.com.
Enrichissement pour modèles ML / recommandations
Contexte : fournir des features relationnelles et du contexte pour des modèles ou des agents. Données à lier : graphes relationnels, attributs clients, événements. Apport du KG : produire des signaux relationnels et un contexte sémantique réutilisable par des modèles ou des systèmes de recommandation.
Source : pwc.com.
Exemples industriels et études de cas
Plusieurs éditeurs et cabinets publient des retours publics. Neo4j documente des cas customer 360 et fraud graphs. TigerGraph présente des références dans les services financiers. Metaphacts publie une étude sur la détection de fraude. The Data Praxis propose une référence d’architecture pour Lakeside Trust Bank. Ces documents sont des retours d’éditeurs ou de consultants et doivent être lus comme tels.
Source : neo4j.com. Source : tigergraph.com. Source : metaphacts.com. Source : thedatapraxis.com.
Architecture & pipeline
Vue métier : le pattern d’ingestion combine données structurées (CRM, core banking), semi-structurées (PDF KYC) et streaming de transactions. Les étapes courantes incluent extraction d’entités via NER, normalisation, et alimentation du graphe. L’ontologie joue un rôle central pour garantir cohérence et interopérabilité.
Rôle des composants : ETL pour ingérer et normaliser, outils d’extraction pour transformer documents non structurés, moteurs de graphes pour stockage et traversée. Les fournisseurs cloud et bases graphes proposent des offres et exemples métier pour ces patterns.
Source : thedatapraxis.com. Source : aws.amazon.com.
Gouvernance, conformité et risques
La gouvernance doit documenter provenance des données, règles de correspondance et politiques de conservation. Les exigences RGPD portent sur droit d’accès et suppression et doivent être intégrées aux flux du KG. Il faut pouvoir justifier l’origine et la transformation des données pour des audits réglementaires.
Le KG peut soutenir les audits AML en rendant traçables les décisions et les chemins d’investigation. Mais la mise en œuvre exige des choix documentés sur la conservation, la reproductibilité des correspondances et la gestion des accès.
Source : deloitte.com. Source : metaphacts.com.
Facteurs de succès et pièges à éviter
Facteurs de succès récurrents : une ontologie claire, qualité et gouvernance des sources, une équipe mixte data + domain et la priorisation de cas d’usage. Commencer par un cas ciblé permet d’aligner valeur métier et investissement technique.
Pièges fréquents : répliquer le data warehouse sans ontologie, négliger la gouvernance, et porter des attentes irréalistes sur les résultats. Ces erreurs conduisent à projets coûteux et peu utilisables.
Source : thedatapraxis.com.
Ce qui change avec l’IA (Graph+LLM) : opportunités et limites
Opportunités : combiner KG et modèles de langage permet un enrichissement sémantique, du raisonnement sur sous-graphes et des interfaces conversationnelles pour les enquêtes. Ces pistes sont documentées comme orientations R&D et proofs of concept.
Limites : risques d’hallucination des modèles, besoin d’explicabilité dans des contextes réglementés, et nécessité de validation des sorties. Les travaux académiques et industriels montrent un intérêt croissant mais restent expérimentaux pour la détection de blanchiment.
Source : pwc.com. Source : arxiv.org.
Pour aller plus loin
Ressources et standards cités dans la littérature utile pour approfondir : ontologies financières, études éditeurs et notes d’architectures listées par les sources publiques. Ces documents donnent accès à exemples d’architecture, retours d’expérience et recommandations de gouvernance.
Sources principales : thedatapraxis.com ; neo4j.com ; autres sources listées ci-dessous.
Ce que veut savoir votre DSI
Prioriser un cas d’usage clair (par exemple AML ou KYC) avant d’étendre le périmètre.
Valider la qualité des données sources et définir règles de correspondance mesurables.
Mettre en place une gouvernance ontologique et une équipe mixte data + métier.
Sources consultées
Neo4j — Customer 360 pour les services financiers. neo4j.com.
Neo4j — Fraud/financial services use cases (fraud graphs). neo4j.com.
The Data Praxis — Building a Production Knowledge Graph at Lakeside Trust Bank. thedatapraxis.com.
AWS — Knowledge Graphs on AWS. aws.amazon.com.
Deloitte — Risk & Knowledge Graphs for Financial Services. deloitte.com.
Metaphacts — Fraud detection at an international financial services provider. metaphacts.com.
TigerGraph — Financial Services solutions. tigergraph.com.
PwC — Graph LLMs: The next AI frontier in Banking and Insurance. pwc.com.
arXiv — Exploring LLMs for money laundering detection in financial graphs. arxiv.org.
Wikipédia — Graphe de connaissances. fr.wikipedia.org.
