Hashes de cumplimiento entre exchanges

Cuando un exchange valida una credencial SSI, no recibe el pasaporte ni el extracto bancario del inversor. Recibe una prueba matemática de que ciertos atributos fueron verificados por un emisor reconocido en un momento dado. El hash certifica integridad y vigencia, pero no revela el contenido subyacente. La diferencia práctica está en la superficie de exposición: menos datos personales en tránsito y menos copias almacenadas en servidores de terceros.

Qué viaja realmente en la verificación

El paquete que llega a la plataforma receptora contiene tres cosas: la prueba criptográfica de que el emisor firmó los atributos, el identificador del esquema de credencial y una marca temporal. Nada más. No hay número de documento, no hay dirección, no hay saldo. El verificador comprueba la firma contra la clave pública del emisor y decide si acepta o rechaza. Lo que no puede hacer es reconstruir el expediente original, porque nunca lo tuvo.

Metadatos que sí persisten

Hay una parte que suele pasarse por alto: aunque el contenido no viaje, sí quedan rastros. El exchange sabe qué emisor emitió la credencial, en qué franja horaria se presentó y desde qué rango de red. Esos metadatos son suficientes para correlacionar operaciones si alguien se lo propone. La promesa de privacidad es real respecto al contenido, pero más frágil respecto al contexto de uso. Conviene tenerlo claro antes de asumir que la verificación es anónima por defecto.

Revocaciones y vigencia

Una credencial emitida hace dos años puede haber sido revocada ayer. El mecanismo estándar consulta una lista de revocación publicada por el emisor, o bien una prueba de no revocación incluida en el propio paquete. El problema práctico es la latencia: si el exchange no refresca esa lista con la frecuencia adecuada, puede aceptar una credencial que ya no debería valer. En operaciones con obligación de reporte, ese desfase es exactamente el tipo de detalle que aparece en una auditoría.

La trazabilidad, el punto delicado

Aquí es donde el modelo SSI todavía genera discusiones. Un regulador puede pedir a un exchange que demuestre que verificó a un cliente concreto en una fecha concreta. Con un hash, el exchange puede probar que hubo verificación, pero no siempre puede exhibir el expediente completo. La solución que se está imponiendo es mantener un registro interno de eventos de verificación, separado del contenido de la credencial, con retención alineada a la normativa local. Es menos elegante que la promesa original del SSI, pero es lo que hoy sostiene una inspección.

En la práctica, el ahorro está en el tránsito y en el almacenamiento: menos documentos circulando por correo, menos bases de datos con copias del pasaporte de cada cliente. Lo que no desaparece es la obligación de cada entidad de responder por lo que verificó. Ese reparto de responsabilidades es el que conviene documentar antes de conectar la primera credencial.