El nuevo bloque de construcción del cumplimiento

Toda empresa que maneja dinero realiza el mismo ritual con sus clientes. Pide información, el cliente proporciona la información, la empresa verifica la información. La coreografía puede variar de una empresa a otra, pero en esencia es el mismo baile.

Esto no le resta propósito a ese intercambio de información: las instituciones financieras tienen obligaciones con sus reguladores, sus socios y su base de clientes de asegurarse de que solo dejan entrar a sus rieles a clientes seguros y confiables. Estos intercambios están diseñados para reducir el riesgo, y lo logran.

Sin embargo, este enfoque para gestionar el screening de sanciones, las verificaciones de delitos financieros y las medidas antifraude pasa por alto otras dos dimensiones de riesgo, tanto para la empresa como para el cliente: las instituciones financieras cargan con la responsabilidad de la pila de datos de clientes que se recopilan durante todo el proceso de onboarding. El riesgo del cliente es aún mayor. Cada cliente que hace onboarding en una nueva institución financiera debe compartir ese mismo conjunto de datos con cada empresa sucesiva en la que abre una cuenta, lo que multiplica su exposición de datos entre varias entidades.

Hay otra forma de construir esto. Una verificación de cumplimiento puede vivir en una red compartida como un bloque de construcción auditado, llamado “política”. Cualquier institución de la red puede confiar en una política, mientras que los datos personales del cliente nunca tocan la red.

Dos tipos de seguridad

Con una política, la información personal del cliente permanece en un solo lugar. Como una red compartida mantiene un registro permanente, los datos personales nunca se suben a ella. En su lugar, lo que viaja por la red es una “prueba de conocimiento cero” (“ZKP”, por sus siglas en inglés). Una ZKP es una forma de demostrar que una afirmación sobre el cliente es verdadera sin revelar la información que la respalda. Puedes demostrar que tienes dieciocho años sin entregar tu licencia de conducir. Una empresa puede acreditar su salud financiera sin entregar estados de cuenta bancarios. La institución financiera que hace el onboarding del cliente obtiene la información que necesita mediante la ZKP, mientras que los datos subyacentes del cliente siguen siendo confidenciales.

La segunda dimensión de la seguridad está en el código. Cuando cien empresas escriben cada una su propia lógica de screening, hay cien lugares distintos donde puede esconderse un error, y cada uno lo revisa solo el equipo que lo escribió. Si se consolida todo en una sola política compartida, queda una superficie única y pequeña que verificar, vigilada por todos los que dependen de ella. Una superficie más pequeña significa menos lugares donde puede existir una vulnerabilidad. La confianza surge de tener muchos ojos sobre un solo elemento, lo contrario de cómo suele funcionar el código de cumplimiento. La contrapartida es que una falla en una política compartida afectaría a todos los que dependen de ella, y por eso la auditoría y la revisión abierta importan todavía más aquí.

Fácil de adoptar, fácil de explicar

Una verificación compartida solo es útil si la institución financiera que la usa entiende el concepto lo suficiente como para explicárselo a un regulador o a otra parte interesada. Una política está construida exactamente para eso. Si una política de uso extendido ya cubre un requisito, una institución puede usarla en lugar de escribir la suya. El onboarding pasa a ser cuestión de elegir la política adecuada para el producto y el mercado, del mismo modo que hoy un desarrollador recurre a una biblioteca bien probada en lugar de escribir cifrado desde cero.

Y como la verificación ya está construida, el equipo que la adopta necesita entender qué demuestra, no cómo lo logra la criptografía. Las matemáticas detrás de estas pruebas son realmente difíciles de hacer bien, lo que normalmente las dejaría fuera del alcance de la mayoría de los equipos de ingeniería. Una política deja esa dificultad bajo la superficie, ya construida y ya auditada. La institución elige la política que le corresponde y la integra.

Reutilización que se multiplica

Una verificación compartida es más segura y más fácil de adoptar aunque solo una institución la use. La reutilización es el tercer beneficio, y es ahí donde las ventajas empiezan a multiplicarse.

Las políticas se comparten, pero también se pueden combinar. Un servicio arma sus requisitos exactos a partir de verificaciones que ya existen. A medida que más instituciones se apoyan en las mismas verificaciones, las más útiles atraen adopción, y la adopción atrae escrutinio. Las políticas más usadas se convierten en el estándar, por la misma razón por la que los estándares antiguos se ganaron la confianza: han resistido el escrutinio a lo largo del tiempo.

Ese efecto multiplicador también llega al cliente. Donde las reglas permiten que una institución confíe en la verificación de otra, alguien verificado una vez puede cumplir el mismo requisito en el siguiente servicio sin volver a entregar su información. Su estado de verificado puede acompañarlo entre los servicios de la red. El cliente enfrenta menos fricción repetida, y la empresa hereda un grupo más grande de clientes ya verificables y una pila más pequeña de datos que resguardar.

Una mirada más de cerca a una política

Una política es una verificación de cumplimiento auditada, publicada en una dirección fija de la red, que cualquier institución puede encontrar y en la que puede confiar. Verifica pruebas de conocimiento cero y funciona porque verificarse y demostrarlo son dos pasos separados.

‍

Primero, el cliente se verifica una sola vez, mediante el mismo tipo de verificaciones de identidad que conocemos hoy. El proveedor que verifica al cliente emite una credencial, un registro firmado de la información confirmada, que el cliente conserva. La credencial contiene los datos personales reales, por lo que se queda con el cliente y nunca toca la red.

A partir de ahí, demostrarlo es cuestión de usar esa credencial. Cuando un servicio necesita confirmar que un cliente califica, se genera una prueba a partir de la credencial, ya sea en el propio dispositivo del cliente o por parte del proveedor en su nombre, que demuestra que cumple la política sin exponer nada de lo que contiene. El servicio recibe un simple “sí” o “no”. El cliente controla cuándo se usa su credencial, y el servicio nunca construye ni mantiene la verificación. Una vez publicada, una política puede ser reutilizada por cualquier institución de la red.

El onboarding pasa de ser un desarrollo a ser una integración

Imagina una fintech haciendo el onboarding de un nuevo cliente. Antes de permitir que ese cliente mantenga o mueva fondos, la fintech tiene que confirmar que el cliente está verificado, vive en un mercado elegible y supera las verificaciones de sanciones.

La versión “tradicional” es pesada. La empresa recopila los documentos de identidad del cliente, los almacena y desarrolla su propio proceso para revisarlos contra listas de sanciones y reglas de elegibilidad. El mismo cliente tiene que repetir el proceso por cada cuenta que abre.  Cada empresa en la que el cliente abre una cuenta conserva datos personales que pasan a ser su responsabilidad. La verificación no es un diferenciador, y la carga recae por completo en cada empresa.

Una política cambia eso: ya hay una política auditada que cubre los tres requisitos publicada en la red. El cliente se verifica una sola vez y luego conserva una credencial. Cuando la fintech la solicita, se genera una prueba a partir de esa credencial, en el dispositivo del cliente o por parte de su proveedor. En una política bien diseñada, el screening de sanciones se ejecuta de forma continua y la política se actualiza cuando cambia una lista, de modo que la verificación refleja las listas vigentes.

La fintech recibe la confirmación que necesita. El proveedor que verifica conserva los registros subyacentes, y la fintech puede obtenerlos para un examinador o una auditoría cuando se requiera. Los documentos no necesitan pasar entre instituciones en el día a día, no se escribe nada sensible en la red y la fintech confía en la misma verificación que otras instituciones de la red usan e inspeccionan. El onboarding pasa de ser un desarrollo a ser una integración.

El cumplimiento se convierte en infraestructura

El cumplimiento es una de las funciones más importantes de los servicios financieros, y una de las más duplicadas. Cada equipo reconstruye las mismas verificaciones, lo que consume tiempo de ingeniería, concentra el riesgo y dispersa datos sensibles en más sistemas de los que cualquiera elegiría. Tratar la verificación como un bloque de construcción compartido y auditado cambia la naturaleza del problema. Una política se escribe y se revisa una vez, se reutiliza ampliamente y se ejecuta sin poner jamás los datos del cliente en la red. Cada institución sigue siendo dueña de su programa de cumplimiento y responde ante sus reguladores. Una política compartida cambia la forma en que se construye y se revisa la verificación, mientras que la responsabilidad sigue en manos de las instituciones.

Esta es una base que una red centrada en pagos puede sentar desde el principio. Y mejora con el uso. Cada institución que confía en una política compartida suma al escrutinio que la respalda, lo que hace que la siguiente sea más segura para construir sobre ella. El cumplimiento deja de ser algo que cada empresa construye por su cuenta y se convierte en una infraestructura compartida que se fortalece con cada institución que confía en ella.