En muchos bancos, el concepto de cliente se define por separado en cada sistema. El core banking tiene un número de cliente, el sistema de tarjetas otro, el de préstamos un tercero y los canales digitales un cuarto. Una misma persona puede figurar en tres sistemas con tres grafías distintas de su nombre, dos direcciones obsoletas y un teléfono que ya nadie contesta. Mientras cada sistema funcione de forma aislada, esta fragmentación permanece oculta. En cuanto el banco quiere una visión unificada, un análisis de riesgo o un servicio personalizado, el problema sale a la luz.
Su importancia va mucho más allá de la higiene de los datos. Conocer correctamente al cliente es la base de las obligaciones de identificación de clientes, la gestión del riesgo de crédito, la prevención del fraude e incluso un cálculo honesto de la rentabilidad. Si el banco no puede afirmar que tres cuentas, dos tarjetas y un préstamo pertenecen a la misma persona, no puede medir la exposición agregada de esa persona ni ofrecer una experiencia coherente entre la oficina y la aplicación. Las personas jurídicas y las relaciones entre ellas, como la participación accionarial, la representación y las garantías, añaden una capa adicional que una simple tabla de clientes no puede modelar.
La respuesta arquitectónica es una única fuente de verdad para la parte, conocida en la literatura técnica como datos maestros de partes (party master data). En este modelo, las personas físicas, las personas jurídicas e incluso roles intermedios como apoderados o beneficiarios se agrupan bajo el concepto general de parte, y las relaciones entre ellos se almacenan de forma explícita. El sistema maestro conserva la identidad dorada de cada parte, asigna a ella los identificadores locales de todos los demás sistemas y publica los cambios a todos los consumidores mediante API y eventos. Los sistemas operativos conservan sus propios datos, pero dejan de ser la fuente de verdad.
La primera consideración práctica son las reglas de cotejo y fusión. Decidir que dos registros pertenecen a la misma persona combina reglas deterministas, como un número de identificación nacional o de registro, con reglas probabilísticas, como la similitud del nombre y la fecha de nacimiento. Estas reglas deben ser transparentes, ajustables y revisables, porque cada fusión errónea puede vincular entre sí las cuentas de dos personas. Por ejemplo, cuando dos registros comparten un nombre similar y la misma fecha de nacimiento pero direcciones distintas, el sistema debe marcarlos para revisión humana en lugar de fusionarlos automáticamente.
La segunda consideración es modelar las relaciones. En la banca de empresas, el verdadero valor procede de comprender la red: qué empresas pertenecen a un grupo, quién tiene poder de firma, qué persona avala qué financiación. Estas relaciones necesitan un tipo, una fecha de inicio y de fin y una fuente registrada, para que puedan consultarse y auditarse. Un buen modelo permite al banco preguntar cuál es la exposición total a un determinado grupo económico y obtener una única respuesta coherente en lugar de una hoja de cálculo montada a mano.
Los errores habituales en los proyectos de datos maestros de partes son reconocibles. Primero, intentar migrar todos los sistemas a la vez, lo que convierte el proyecto en un programa plurianual sin resultados intermedios. Segundo, descuidar la titularidad de los datos; si ninguna unidad de negocio responde de la calidad de cada atributo, los datos maestros vuelven a contaminarse en cuestión de meses. Tercero, construir el maestro sin API ni eventos, de modo que los demás sistemas acaban recibiendo los datos mediante archivos nocturnos. Cuarto, ignorar el historial; un banco debe poder reconstruir lo que sabía de una parte en una fecha concreta del pasado.
La plataforma Ashna de Niadad está diseñada exactamente para este papel: gestión unificada de personas físicas y jurídicas, las relaciones entre ellas, reglas de cotejo configurables y publicación de cambios mediante API y eventos. En el programa bancario de Niadad, Ashna actúa como maestro de partes junto a la capa de identidad y la pasarela de API, de modo que los sistemas operativos, los canales digitales y la analítica trabajan con una definición compartida de quién es el cliente.
Los datos maestros de partes no son el proyecto más vistoso que puede acometer un banco, pero son el requisito previo de casi todos los proyectos vistosos. Sin ellos, la IA se entrena con datos erróneos, la visión 360 del cliente queda incompleta y la gestión del riesgo se apoya en conjeturas. Con ellos, cada proyecto posterior parte de una base sólida. Cuanto antes trate un banco los datos de partes como una infraestructura compartida y no como un asunto departamental, antes será alcanzable el resto de su hoja de ruta.