Búsqueda complementaria, histórica y continua: la interconexión PUI
Introducción
Cuando una institución financiera piensa en "interconectarse con la PUI", suele imaginar una sola conexión: recibir un reporte, responder y terminar. La realidad técnica es distinta. El Artículo 22 de los Lineamientos para el Desarrollo y Operación de la Plataforma Única de Identidad exige que cada institución obligada ejecute tres fases de búsqueda diferenciadas, cada una con su propio flujo, sus propios servicios técnicos que la PUI invoca y sus propias implicaciones de infraestructura.
Entender estas tres fases —y automatizarlas correctamente— es lo que separa una interconexión que cumple de una que solo "responde a tiempo".
Este “triplete tecnológico” —búsqueda complementaria, búsqueda histórica y búsqueda continua— permite complementar el reporte de búsqueda, revisar antecedentes dentro del periodo aplicable y mantener vigilancia sobre eventos recientes mientras el reporte permanezca activo.
¿Qué son las tres fases de búsqueda de la PUI?
Recordemos primero el modelo de integración: no es la institución la que consulta a la PUI, sino la PUI la que consulta a la institución. Cuando la Comisión Nacional de Búsqueda de Personas o una comisión local activa un reporte de persona desaparecida o no localizada, la PUI notifica a cada sujeto obligado, y es la institución quien debe exponer los servicios técnicos —endpoints— que la PUI invocará para obtener resultados.
Sobre esa base, el Manual Técnico define tres fases secuenciales:
Fase 1 — Búsqueda complementaria (única vez)
Al activarse un reporte, la institución realiza una búsqueda por CURP para complementar la información del reporte de búsqueda. Si existe coincidencia, debe notificar los datos complementarios mediante la API de la PUI; si no existe coincidencia, el flujo avanza a la fase histórica. Esta fase se ejecuta una sola vez.
Fase 2 — Búsqueda histórica (única vez, hasta 12 años)
En esta fase se reportan las coincidencias identificadas desde la fecha de desaparición de la persona hasta un máximo de 12 años previos a la fecha de consulta. Si hay coincidencias por CURP, se notifican los eventos históricos de forma individual; si no las hay, se notifica la búsqueda correspondiente. Al concluir esta fase, el flujo avanza a búsqueda continua.
Esta es, técnicamente, una de las fases más demandantes: requiere consultar antecedentes dentro del periodo aplicable y contar con mecanismos para identificar coincidencias históricas de forma trazable, especialmente en instituciones con sistemas bancarios legacy o bases no indexadas para consulta rápida.
Fase 3 — Búsqueda continua (cada 24 horas o menos)
Mientras el reporte permanezca activo, la institución debe ejecutar búsquedas periódicas para identificar y reportar eventos recientes. Si hay coincidencia por CURP, se notifican los eventos recientes; si no hay coincidencia, el sistema verifica si el reporte sigue activo y continúa el ciclo hasta que la PUI indique su cierre. La frecuencia es configurable.
Es la fase con mayor exigencia operativa continua: no es una consulta puntual, sino un proceso vivo que debe correr de forma confiable, sin intervención manual constante, durante todo el tiempo en que el reporte permanezca activo.
Automatizar sin perder el control humano
Las tres fases, ejecutadas manualmente, serían insostenibles a escala: ningún equipo de cumplimiento puede revisar historiales de 12 años o correr monitoreos horarios reporte por reporte. La automatización es indispensable, pero no puede significar "caja negra".
El diseño correcto separa dos capas:
- Capa automatizada: ejecución de las tres fases, generación de coincidencias candidatas, notificación a los servicios técnicos correspondientes y registro trazable de cada evento con controles de integridad y con datos personales enmascarados en bitácoras.
- Capa de validación humana: revisión de coincidencias antes de su confirmación final, con evidencia auditable de quién validó qué y cuándo
Esta separación es exactamente lo que un auditor —interno o de la autoridad— va a querer ver: no solo que el sistema encontró la coincidencia, sino que existió un control humano sobre la decisión final.
Qué necesita su institución para soportar las tres fases
En términos de infraestructura, esto implica:
- Exponer los servicios técnicos que la PUI invocará para cada fase de búsqueda, con la disponibilidad y seguridad que exige el modelo de integración.
- Acceso a registros vigentes y a antecedentes históricos.
- Un mecanismo de vigilancia periódica confiable mediante procesos programados, colas de eventos o mecanismos equivalentes que no dependa de intervención manual diaria.
- Registro de evidencia para auditoría en cada una de las tres fases, no solo en la fase inmediata.
- Pruebas de seguridad SAST, SCA, DAST sobre los componentes que exponen estos endpoints, antes del registro ante RENAPO.
Construir esto desde cero implica meses de desarrollo, especialmente para instituciones con sistemas heredados sin arquitectura de APIs. Es exactamente el problema que resuelve una solución on-premise ya implementada: las tres fases operan sobre infraestructura propia de la institución —control total de los datos— sin el tiempo ni el riesgo de un desarrollo interno desde cero. PUI-Service integra las tres fases de búsqueda, trazabilidad verificable, evidencia documental y operación bajo control institucional, acelerando la ruta de implementación sin obligar a rediseñar el entorno actual.
¿Su infraestructura actual soporta las tres fases sin desarrollo adicional?
Agende un diagnóstico técnico y valide qué tan lista está su institución para operar la interconexión PUI con seguridad, evidencia y control. https://bit.ly/4znco1U
Nota de verificación: este artículo describe el modelo de tres fases conforme al Artículo 22 de los Lineamientos para el Desarrollo y Operación de la Plataforma Única de Identidad y al Manual Técnico de la Solución Tecnológica para Instituciones Diversas (DOF, 23 de enero de 2026). El marco normativo de la PUI continúa en desarrollo: está pendiente de publicación el Manual de Operación de la PUI para el SNIP, que podría precisar algunos detalles operativos. Antes de implementar, le recomendamos validar el texto vigente en el DOF.
