Blog

Proveedores de verificación remota de identidad para entidades financieras en México

Compara opciones para validar documentos y biometría, consultar fuentes y conservar la evidencia del alta digital.

Por Deepia ·

Para contrastar una identidad con fuentes mexicanas, empezaría por Incode y Nubarium. Sumsub y Didit también merecen una prueba si el alta necesita captura documental, biometría y un flujo configurable. Antes de comparar tasas de aprobación, pida que cada proveedor muestre el mismo documento, la fuente consultada y el expediente que queda cuando la consulta falla.

Cuando un proveedor dice “validación de INE”, pídale que precise la operación. Leer los campos de la credencial, revisar señales de autenticidad, consultar datos de referencia y comparar una selfie con la imagen de un registro producen evidencias distintas. El expediente debe indicar cuál se obtuvo.

Nuestra primera prueba sería con Incode (8/10 para el cotejo local). Su documentación explica cómo encadenar captura y consulta gubernamental en México, que es el paso decisivo en este caso. Pediríamos que nos enseñen el expediente cuando la fuente no responde. Nos interesa ver qué referencia se guarda y con qué datos puede continuar el analista. Para un equipo que ya arma sus propias consultas, también probaríamos la API de Nubarium.

Separe captura, cotejo y decisión

Primero obtenga imágenes utilizables y extraiga sus campos. Luego registre por separado la comprobación documental, el cotejo del rostro y la prueba de vida. Si el flujo consulta una fuente oficial o autorizada, guarde su identificador y el resultado, incluso cuando la consulta quede inconclusa.

Por ejemplo, una credencial puede producir nombre y fecha de nacimiento legibles mientras la consulta no responde. El sistema debe distinguir esa situación de una discrepancia real en el registro. Si confunde ambas, un incidente del proveedor acaba convertido en una ola de rechazos. Si interpreta la extracción como un cotejo positivo, la institución pierde la capacidad de explicar qué evidencia usó.

Las disposiciones mexicanas sobre contratación no presencial tienen alcances distintos según el tipo de entidad y la operación. Las publicadas en el Diario Oficial para ciertas SOFOM, por ejemplo, tratan la identificación remota dentro de su propio régimen. Antes de configurar el flujo, el equipo de cumplimiento identifica la disposición vigente y sus anexos para ese producto. El equipo técnico traduce cada requisito a un campo, un control, una fuente y una decisión que se puedan auditar.

Qué ofrece cada proveedor y qué hay que comprobar

Proveedor Punto de partida documentado Qué debe demostrar en su alta
Incode Su módulo Government Validation para México describe el cotejo con un registro y la posibilidad de comparar la selfie con la referencia oficial Fuente exacta, respuesta ante indisponibilidad y permisos de acceso para la entidad
Nubarium Describe una API de validaciones locales, además de SDK; incluye capacidades relacionadas con CURP e INE Qué dato confirma cada servicio y cómo queda referenciado en el expediente
Sumsub Documenta verificación de documentos por SDK o API, con configuración de niveles y métodos adicionales El nivel habilitado, los documentos mexicanos aceptados y cualquier consulta local incluida
Didit Distingue las sesiones de verificación configurables de las comprobaciones independientes Si el flujo contratado cubre su combinación de credencial, biometría, fuentes y revisión

Incode es especialmente pertinente si la pregunta de compra es cómo demostrar el cotejo con una referencia de México. Su documentación explica que Government Validation depende de pasos de captura previos y de la configuración del flujo. No trate una demostración en un entorno de prueba como prueba de acceso a una fuente en producción. Pida que el proveedor identifique el servicio contratado y las dependencias de esa consulta.

Nubarium entra en una evaluación que necesita componer validaciones locales. Una CURP validada y un cotejo facial son resultados distintos. En la prueba, haga que aparezcan como tales y confirme qué ocurre si un campo del documento no coincide con el registro consultado. Para los dos proveedores internacionales, pregunte por el detalle del paquete y por la forma de exportar evidencia. Cómo funciona Didit explica la diferencia entre sesión y resultado desde la perspectiva de la aplicación.

Diseñe el expediente antes de elegir el SDK

El expediente debería permitir reconstruir por qué se aceptó un alta sin obligar a que todos los equipos vean todas las imágenes. Considere un identificador interno de solicitud, la referencia del proveedor, el tipo de documento, el origen de la evidencia, los controles ejecutados, su versión, el estado y las intervenciones del personal. Determine con qué permisos se puede ver cada objeto y cómo se aplica el periodo de conservación correspondiente.

Conserve la distinción entre la información declarada por la persona y lo que devolvió la verificación. Una fecha que se corrigió después del alta no debe borrar el valor con el que se tomó la decisión. Si el expediente se actualiza, deje un registro que explique el cambio. Lo mismo ocurre si una comprobación se repite por caída de red: el expediente debe mostrar el primer intento inconcluso y el segundo resultado sin contabilizarlos como dos solicitantes.

En un proyecto con IA para captura y clasificación, los indicadores operativos necesitan contexto. La guía de KPIs de una línea de producción usa la misma lógica de separar etapas. Aquí, una captura utilizable, una consulta respondida y una solicitud aprobada son tres denominadores diferentes. Mezclarlos puede mejorar un porcentaje en el tablero mientras empeora el tiempo real para abrir una cuenta.

Pruebe con documentos y fallas que sí encontrará

Arme un conjunto de casos por tipo de documento, versión, dispositivo y escenario. Incluya reflejo en la credencial, reverso ausente, nombre con acentos, fecha ilegible, dispositivo de gama baja y cambio de navegador entre captura y retorno. Use los casos de prueba del proveedor para la integración; reserve cualquier dato real para un piloto con tratamiento autorizado y acceso limitado.

Luego pruebe cuatro respuestas: coincidencia, discrepancia, fuente no disponible y revisión pendiente. La pantalla de usuario debe explicar lo que la persona puede hacer en cada caso. Una discrepancia puede necesitar otro documento o revisión; una fuente temporalmente caída no se arregla enviando cinco selfies seguidas. En el canal interno, registre quién puede reintentar, cuánto tiempo se espera y cómo se evita que un resultado tardío sobrescriba una decisión más reciente.

Haga que soporte localice una solicitud usando una referencia que no sea la CURP ni un identificador de documento. El equipo debe poder informar que falta un paso o que el expediente está en revisión sin acceder a todo el archivo biométrico. Esta prueba revela si la consola y la API sirven a la operación cotidiana o solamente al caso que mostró la demo.

Aclare qué significa el porcentaje de éxito

Solicite el denominador de cualquier tasa que se presente durante la compra. Un proveedor puede contar únicamente documentos admitidos y otro todas las sesiones iniciadas. Pida las cifras separadas por origen del documento, primer intento, reintentos y revisión humana. Un porcentaje agregado no revela si los clientes de un tipo de cuenta quedan esperando la consulta de una fuente durante más tiempo. El piloto debe medir la duración de la solicitud completa y cuánto del retraso corresponde a cada proveedor, a la institución o a una tercera parte.

Lleve una matriz de aceptación a la cotización

Pida a cada empresa una respuesta escrita para el mismo volumen, documentos y flujo. Separe la captura, prueba de vida, cotejo facial, fuente consultada, exportación, revisión y costos de recuperación. Solicite ejemplos del resultado que puede guardar su institución, no solo capturas del panel comercial. Defina también cómo se informa una interrupción y qué datos pueden recuperarse al terminar el contrato.

Para elegir, pida tres expedientes del piloto: uno aprobado, uno ambiguo y uno interrumpido. Cada uno debe mostrar qué evidencia llegó y a quién le toca resolverlo. Esa prueba sirve tanto para una consulta local con Incode o Nubarium como para un flujo configurable en Sumsub o Didit.