Integración de biometría multimodal en APIs bancarias: qué exige el regulador

Cuando un banco decide exponer identificación biométrica a través de una API, el primer frente que se abre no es técnico sino documental. Los equipos de cumplimiento piden ver, antes que cualquier diagrama de flujo, cómo se separa la plantilla biométrica del dato crudo que la originó. Esa separación no es un detalle de implementación: define qué se puede almacenar, durante cuánto tiempo y bajo qué condiciones se destruye.

En la práctica, la mayoría de los rechazos en auditoría no vienen por fallos del motor de IA, sino por logs incompletos. Un registro que anota "verificación exitosa" sin marca de tiempo verificable, sin identificador de canal y sin versión del modelo no sirve como evidencia. Los revisores quieren poder reconstruir la cadena completa: quién solicitó la verificación, con qué modalidad, contra qué plantilla y con qué resultado.

Dos arquitecturas, dos regímenes de obligaciones

La primera arquitectura mantiene el motor biométrico dentro de la entidad. Aquí el banco custodia las plantillas, controla los umbrales de decisión y responde directamente por la conservación. La ventaja es la trazabilidad interna; el costo es asumir la actualización del modelo, la seguridad del repositorio y la revocación por canal sin depender de terceros.

La segunda delega el motor en un proveedor externo. Cambia el mapa de responsabilidades: el consentimiento revocable debe propagarse hasta el proveedor en un plazo acotado, y el contrato tiene que fijar qué ocurre con las plantillas si la relación termina. Muchos equipos descubren tarde que su cláusula de salida no contempla la destrucción verificable de los datos biométricos alojados fuera.

Consentimiento revocable por canal

El consentimiento no puede ser un checkbox único firmado en el enrolamiento. Los reguladores esperan que el cliente pueda revocar el uso de una modalidad concreta —por ejemplo, la voz— sin perder acceso al resto del perfil. Eso obliga a modelar el consentimiento como un estado por canal, con su propio historial de cambios y su propia marca temporal.

Antes de abrir la API a terceros conviene resolver tres preguntas: qué identificador único vincula la plantilla con el titular, cómo se propaga una revocación a todos los nodos que ya recibieron la identificación, y qué evidencia queda cuando un tercero consulta el perfil fuera del horario de soporte.