SEPRELAD y AML
Veridia no está certificada, registrada, aprobada ni revisada por SEPRELAD ni por ninguna otra unidad de inteligencia financiera. No genera ningún reporte regulatorio, no produce ninguna presentación en el formato de ningún supervisor, y no envía nada a nadie en tu nombre.
Si sos sujeto obligado, tus obligaciones AML siguen siendo enteramente tuyas: tu programa, tu oficial de cumplimiento, tu evaluación de riesgo, tus reportes. Lo que describe esta página es un conjunto de controles que pueden aportar evidencia a ese programa — no un reemplazo de él.
Confirmá con tu asesoría legal qué exige realmente tu actividad regulada. Esta página no te lo puede decir.
Dicho ese límite, esto es exactamente lo que hace el sistema.
Screening de sanciones
Toda verificación cuyo OCR haya producido un nombre se contrasta contra listas de sanciones antes de emitir un veredicto.
Qué listas
| Fuente | Lista |
|---|---|
| OFAC (Tesoro de EE. UU.) | Specially Designated Nationals (SDN) |
| Naciones Unidas | Consolidated Sanctions List |
Esa es la cobertura completa. Específicamente no se incluye:
- Ninguna lista PEP. Las personas expuestas políticamente no se contrastan en absoluto.
- Ningún screening de adverse media.
- Ninguna lista consolidada de la UE. Considerada y postergada; no implementada.
- Ninguna lista local o regional de ninguna jurisdicción.
Si tu programa requiere screening de PEP — y para muchas actividades reguladas lo requiere — necesitás un proveedor o un proceso aparte para eso. No asumas que está cubierto acá.
Qué tan actualizadas están las listas
Un timer refresca ambas fuentes a diario desde los endpoints oficiales de los publicadores y reconstruye el índice de coincidencias. Si una descarga falla, el índice anterior queda en su lugar, en vez de que el sistema caiga a contrastar contra nada.
El estado de las listas es, por lo tanto, "la publicación de ayer en el peor caso" bajo operación normal — pero no hay ningún contrato de alertas alrededor de un refresh que falle de forma persistente, ni un SLA de frescura publicado. Si la vigencia de las listas es un punto de auditoría para vos, verificalo operativamente en lugar de asumirlo.
Qué produce una coincidencia
Los resultados del screening se exponen como flags en la verificación:
| Flag | Nivel | Significado |
|---|---|---|
aml_sanctions_match | err | Coincidencia fuerte contra un nombre listado |
aml_possible_match | warn | Coincidencia más débil que merece atención humana |
Una coincidencia fuerte fuerza la verificación a review, para que decida una persona. No produce por sí sola un veredicto rejected, por más confianza que tenga la coincidencia.
Esto es deliberado y vale entenderlo, porque el diseño intuitivo es el opuesto. El matching de nombres contra listas de sanciones produce falsos positivos constantemente — nombres comunes, variantes de transliteración, coincidencias parciales. Rechazar automáticamente por una coincidencia de nombre le negaría el servicio a personas reales sobre la base de una comparación de strings, y lo haría en silencio. Poner el caso frente a un humano es el único manejo defendible: la decisión, y el razonamiento detrás, pasan a pertenecer a una persona a la que se le puede pedir que la justifique.
La consecuencia para tu integración: un caso de sanciones llega como verdict: "review", no como un rechazo. Si tu onboarding trata a review como una cola que nadie mira, los casos de sanciones se quedan ahí.
Un límite que conviene conocer
El screening corre sobre el nombre extraído por OCR del documento. Si el OCR lee mal el nombre, el screening corre contra la versión mal leída. Un nombre que no se logra extraer no se contrasta en absoluto.
Esto es inherente a hacer screening sobre un documento fotografiado en lugar de sobre una identidad tipeada, y no hay nada en el pipeline que lo cierre del todo. Si necesitás que el nombre contrastado coincida con un nombre que tienen tus propios sistemas, mandalo como submittedFullName en el init, para que la comparación entre los dos quede puntuada y visible en los resultados.
Qué retiene el sistema como evidencia
El registro de verificación está diseñado para sobrevivir como el artefacto de la verificación de identidad. Contiene:
- El veredicto, la confianza general y el score de cada control individual
- Cada flag levantado, incluidos los flags de sanciones de arriba
- Los campos de identidad extraídos del documento
- Los timestamps de envío y de finalización
- Cuando una persona revisó el caso: quién lo revisó, cuándo y su nota
Los registros de verificaciones identificadas como paraguayas conservan sus imágenes 5 años; todo lo demás, y todo aquello cuya jurisdicción sea incierta, 8. La fila de la base de datos en sí nunca la borra el barrido de retención. Ver Retención de datos para saber exactamente qué significa eso, incluida la parte donde las imágenes se van y el registro se queda.
Qué NO produce Veridia
Listado explícitamente, porque son las cosas que un programa AML necesita y que sería razonable suponer que un producto de "KYC/AML" provee:
| Reportes de operaciones sospechosas (ROS / STR) | No se generan, no se formatean, no se presentan |
| Formatos de reporte de SEPRELAD | No implementados |
| Presentación o envío a cualquier supervisor | Ninguno |
| Scoring o calificación de riesgo del cliente | No se produce. El score de confianza es una medida de verificación de identidad, no una calificación de riesgo de lavado — no lo uses como tal |
| Re-screening continuo o periódico | No implementado. El screening ocurre una sola vez, en la verificación. Un cliente que sea listado después de haber sido verificado no se vuelve a contrastar y no va a ser flaggeado |
| Monitoreo transaccional | Totalmente fuera de alcance |
| Screening de PEP o adverse media | No implementado |
| Beneficiario final o KYB corporativo | No implementado |
| Conservación de registros en el formato prescrito por algún supervisor | No implementado |
La ausencia de re-screening continuo merece atención particular. Las listas cambian; un chequeo único en el onboarding es un control puntual en el tiempo. Si tus obligaciones incluyen re-screening periódico de tu base de clientes existente, eso hay que resolverlo en otro lado.
Qué podés afirmar razonablemente
Si estás describiendo tu stack en tu propia documentación de cumplimiento, las afirmaciones defendibles tienen esta forma:
La verificación de identidad la realiza un proveedor externo, que contrasta el nombre extraído contra las listas OFAC SDN y Consolidada de la ONU al momento de la verificación. Las coincidencias fuertes se derivan a revisión manual en lugar de rechazarse automáticamente. Los registros de verificación, incluidos el veredicto, los controles realizados y la decisión del revisor, se conservan por [plazo].
Lo que no es defendible es cualquier afirmación que implique que Veridia está certificada por SEPRELAD, que descarga una obligación de reporte, o que usarla vuelve conforme a un proceso de onboarding. No lo hace, y afirmarlo en un documento que puede leer un regulador crea un problema bastante más grande que el que resuelve.