Dans de nombreuses banques, la notion de client est définie séparément dans chaque système. Le core banking attribue un numéro client, le système de cartes un autre, le système de crédit un troisième et les canaux numériques un quatrième. Une même personne peut être enregistrée dans trois systèmes avec trois orthographes de son nom, deux adresses obsolètes et un numéro de téléphone auquel plus personne ne répond. Tant que chaque système fonctionne isolément, cette fragmentation reste invisible. Dès que la banque souhaite une vue unifiée, une analyse de risque ou un service personnalisé, le problème apparaît.
L'enjeu dépasse largement l'hygiène des données. Bien connaître le client est le fondement des obligations d'identification de la clientèle, de la gestion du risque de crédit, de la prévention de la fraude et même d'un calcul honnête de la rentabilité. Si la banque ne peut pas établir que trois comptes, deux cartes et un prêt appartiennent à la même personne, elle ne peut ni mesurer l'exposition globale de cette personne ni offrir une expérience cohérente entre l'agence et l'application. Les personnes morales et leurs relations, telles que l'actionnariat, la représentation et les garanties, ajoutent une couche supplémentaire qu'une simple table de clients ne peut tout bonnement pas modéliser.
La réponse architecturale est une source unique de vérité pour le tiers, que la littérature technique désigne sous le nom de données de référence des tiers (party master data). Dans ce modèle, les personnes physiques, les personnes morales et même les rôles intermédiaires tels que les mandataires ou les bénéficiaires relèvent tous de la notion générale de tiers, et les relations entre eux sont enregistrées explicitement. Le système de référence détient l'identité de référence de chaque tiers, y rattache les identifiants locaux de tous les autres systèmes et publie les modifications à l'ensemble des consommateurs via des API et des événements. Les systèmes opérationnels conservent leurs propres données, mais ils ne sont plus la source de vérité.
La première considération pratique concerne les règles de rapprochement et de fusion. Décider que deux enregistrements appartiennent à la même personne combine des règles déterministes, comme un identifiant national ou un numéro d'immatriculation, et des règles probabilistes, comme la similarité du nom et de la date de naissance. Ces règles doivent être transparentes, paramétrables et révisables, car chaque fusion erronée peut relier les comptes de deux personnes. Par exemple, lorsque deux enregistrements présentent un nom similaire et la même date de naissance mais des adresses différentes, le système doit les signaler pour une revue humaine plutôt que de les fusionner automatiquement.
La deuxième considération est la modélisation des relations. En banque d'entreprise, la véritable valeur vient de la compréhension du réseau : quelles sociétés appartiennent à un groupe, qui détient le pouvoir de signature, quelle personne garantit quel crédit. Ces relations doivent comporter un type, une date de début et de fin et une source enregistrée, afin de pouvoir être à la fois interrogées et auditées. Un bon modèle permet à la banque de demander quelle est l'exposition totale envers un groupe économique donné et d'obtenir une réponse unique et cohérente, au lieu d'un tableur assemblé à la main.
Les écueils habituels des projets de données de référence des tiers sont reconnaissables. Premièrement, vouloir migrer tous les systèmes à la fois, ce qui transforme le projet en un programme pluriannuel sans résultats intermédiaires. Deuxièmement, négliger la propriété des données ; si aucune unité métier n'est responsable de la qualité de chaque attribut, les données de référence se dégradent de nouveau en quelques mois. Troisièmement, construire le référentiel sans API ni événements, si bien que les autres systèmes finissent par recevoir les données par fichiers nocturnes. Quatrièmement, ignorer l'historique ; une banque doit pouvoir reconstituer ce qu'elle savait d'un tiers à une date précise du passé.
La plateforme Ashna («آشنا») de Niadad est conçue précisément pour ce rôle : gestion unifiée des personnes physiques et morales et de leurs relations, règles de rapprochement paramétrables et publication des modifications via des API et des événements. Dans le programme bancaire de Niadad, Ashna joue le rôle de référentiel des tiers aux côtés de la couche d'identité et de la passerelle API, afin que les systèmes opérationnels, les canaux numériques et l'analytique s'appuient tous sur une même définition du client.
Les données de référence des tiers ne sont pas le projet le plus prestigieux qu'une banque puisse mener, mais elles sont la condition préalable de presque tous les projets prestigieux. Sans elles, l'IA s'entraîne sur des données erronées, la vue client à 360 degrés reste incomplète et la gestion des risques s'appuie sur des suppositions. Avec elles, chaque projet ultérieur part d'une base solide. Plus tôt une banque traite les données des tiers comme une infrastructure partagée plutôt que comme l'affaire d'un seul service, plus tôt le reste de sa feuille de route devient réalisable.