In molte banche il concetto di cliente è definito separatamente in ogni sistema. Il core banking ha un numero cliente, il sistema delle carte un altro, il sistema dei finanziamenti un terzo e i canali digitali un quarto. Una stessa persona può essere registrata in tre sistemi con tre grafie diverse del nome, due indirizzi non aggiornati e un numero di telefono a cui nessuno risponde più. Finché ogni sistema lavora in modo isolato, questa frammentazione resta nascosta. Nel momento in cui la banca vuole una vista unificata, un'analisi del rischio o un servizio personalizzato, il problema emerge.
L'importanza va ben oltre la pulizia dei dati. Conoscere correttamente il cliente è la base per gli obblighi di identificazione della clientela, la gestione del rischio di credito, la prevenzione delle frodi e perfino un calcolo onesto della redditività. Se la banca non è in grado di dire che tre conti, due carte e un prestito appartengono alla stessa persona, non può né misurarne l'esposizione complessiva né offrire un'esperienza coerente tra filiale e app. Le persone giuridiche e le relazioni tra loro, come partecipazioni, rappresentanza e garanzie, aggiungono un ulteriore livello che una semplice tabella clienti non è in grado di modellare.
La risposta architetturale è un'unica fonte di verità per il soggetto, nota nella letteratura tecnica come party master data. In questo modello, persone fisiche, persone giuridiche e perfino ruoli intermedi come procuratori o beneficiari rientrano tutti nel concetto generale di soggetto, e le relazioni tra loro vengono memorizzate in modo esplicito. Il sistema master conserva l'identità golden di ciascun soggetto, vi associa gli identificativi locali di tutti gli altri sistemi e pubblica le modifiche a tutti i consumatori tramite API ed eventi. I sistemi operativi mantengono i propri dati, ma non sono più la fonte di verità.
La prima considerazione pratica riguarda le regole di abbinamento e unificazione. Stabilire che due record appartengono alla stessa persona combina regole deterministiche, come un codice identificativo nazionale o un numero di registrazione, con regole probabilistiche, come la somiglianza del nome e della data di nascita. Queste regole devono essere trasparenti, regolabili e verificabili, perché ogni unificazione errata può collegare tra loro i conti di due persone diverse. Ad esempio, quando due record hanno un nome simile e la stessa data di nascita ma indirizzi diversi, il sistema dovrebbe segnalarli per una revisione umana anziché unificarli automaticamente.
La seconda considerazione riguarda la modellazione delle relazioni. Nel corporate banking, il valore reale deriva dalla comprensione della rete: quali società appartengono a un gruppo, chi ha poteri di firma, quale persona garantisce quale finanziamento. Queste relazioni richiedono un tipo, una data di inizio e di fine e una fonte registrata, così da poter essere sia interrogate sia verificate. Un buon modello consente alla banca di chiedere quale sia l'esposizione complessiva verso un determinato gruppo economico e di ricevere un'unica risposta coerente, anziché un foglio di calcolo assemblato a mano.
Le insidie tipiche dei progetti di party master data sono riconoscibili. Primo, tentare di migrare tutti i sistemi contemporaneamente, trasformando il progetto in un programma pluriennale senza risultati intermedi. Secondo, trascurare la titolarità dei dati; se nessuna unità di business risponde della qualità di ciascun attributo, i dati master tornano a essere inquinati nel giro di pochi mesi. Terzo, costruire il sistema master senza API ed eventi, così che gli altri sistemi finiscano per ricevere i dati tramite file notturni. Quarto, ignorare lo storico; una banca deve poter ricostruire ciò che sapeva di un soggetto a una data specifica del passato.
La piattaforma Ashna («آشنا») di Niadad è progettata esattamente per questo ruolo: gestione unificata di persone fisiche e giuridiche e delle relazioni tra loro, regole di abbinamento configurabili e pubblicazione delle modifiche tramite API ed eventi. Nel programma bancario di Niadad, Ashna funge da anagrafica master dei soggetti accanto al livello di identità e all'API gateway, affinché sistemi operativi, canali digitali e analisi lavorino tutti su un'unica definizione condivisa di chi sia il cliente.
I dati anagrafici master dei soggetti non sono il progetto più affascinante che una banca possa avviare, ma sono il prerequisito di quasi tutti quelli affascinanti. Senza di essi, l'IA si addestra su dati errati, la vista customer 360 resta incompleta e la gestione del rischio si affida alle supposizioni. Con essi, ogni progetto successivo parte da basi solide. Prima una banca tratta i dati dei soggetti come infrastruttura condivisa anziché come questione di un singolo reparto, prima il resto della sua roadmap diventa realizzabile.