Plataforma de screening
Sanciones y PEP para sujetos obligados · UIF-SBS
El problema
Los sujetos obligados peruanos —casas de cambio, notarías, inmobiliarias, fintechs— están obligados por la UIF-SBS a verificar a cada cliente contra listas de sanciones y de personas expuestas políticamente antes de operar con él, y a conservar la evidencia de esa verificación. En la práctica eso significaba abrir una a una las fuentes (OFAC SDN, OFAC Consolidated, OFSI del Reino Unido, la consolidada de la UE, la de la ONU, más los padrones del JNE y las declaraciones juradas de la Contraloría), buscar el nombre en cada una y guardar capturas de pantalla en una carpeta. La plataforma reduce eso a una consulta por nombre o documento que cruza las cinco listas internacionales, el maestro PEP peruano y las listas privadas que carga cada cliente, con sincronización automática de las fuentes y consumo por API para incrustar el screening en el onboarding de otro sistema.
Decisiones
La evidencia es el producto, no la búsqueda
Ante el regulador la pregunta no es «¿está sancionado?» sino «¿qué consultaste el 14 de marzo y contra qué versión de OFAC?». Por eso cada consulta se persiste en una auditoría con el nombre normalizado, el resultado y la versión exacta de la lista contra la que se corrió. Los sincronizadores versionan cada descarga en lugar de sobrescribir, así que una búsqueda de hace seis meses sigue siendo reconstruible con la lista tal como estaba ese día.
esquema de auditoría → version por match
sincronizadores → versionan cada descarga, no sobrescriben
consulta(14-mar) ──► resultado ──► versión de OFAC de ese día
(reconstruible seis meses después)Matching determinista antes que score difuso
Un umbral de similitud de 0,87 no se defiende en una auditoría; una regla escrita sí. El matching es determinista y explicable: normalización Unicode, identificadores que preservan los ceros a la izquierda —el DNI peruano suele empezar en 0 y un parseo a entero lo destruye— y variantes de nombre que cubren el intercambio de apellido paterno y materno, porque el orden cambia entre fuentes.
// utilidades de normalización normIdentifier() // preserva ceros a la izquierda: "07654321" ≠ 7654321 generateNameVariations() // paterno/materno intercambiados entre fuentes
Un adaptador por fuente, no un parser genérico
Cinco XML con esquemas que no se parecen entre sí y que cambian sin aviso. Cada fuente tiene su adaptador y su mapper con tests propios, de modo que una fuente que rompe formato rompe un archivo y no el pipeline entero. Un parser genérico habría sido más corto de escribir y más frágil en cada actualización de OFAC.
El producto
Cifras
- 5
- listas internacionales de sanciones cruzadasOFAC SDN · OFAC Consolidated · OFSI UK · UE · ONU
- +1
- maestro PEP peruano (JNE + Contraloría)Descripción del proyecto
- 1
- consulta reemplaza la búsqueda fuente por fuenteDescripción del proyecto
- API
- para incrustar el screening en onboarding de tercerosDescripción del proyecto
Lo que demuestra
| Habilidad | Evidencia |
|---|---|
| Criterio en dominio regulado | Auditoría versionada por consulta: la evidencia es el entregable, no el resultado de la búsqueda |
| Diseño de matching | Reglas deterministas y explicables en vez de un score de similitud indefendible ante un auditor |
| Arquitectura de integraciones | Un adaptador por fuente con tests propios: una fuente rota no tumba el pipeline |
| Detalle de dominio local | Ceros a la izquierda del DNI peruano · orden variable de apellidos entre fuentes |
| Full-stack de extremo a extremo | Multi-tenant, contenerizado con Docker, consumible por API |