Skip to content

Alertas

Para qué sirve

El módulo de alertas es el registro centralizado de los hallazgos del proceso de screening que requieren una decisión humana antes de que la cuenta pueda avanzar o ser aprobada. Cuando el proceso automático de screening detecta una coincidencia con una lista de sancionados que supera el umbral configurado, el sistema abre una alerta y la deja esperando revisión.

Las alertas no son solo notificaciones: tienen un ciclo de vida completo con estados, asignaciones, comentarios y una resolución justificada que queda registrada permanentemente para fines de auditoría regulatoria.


Quién lo usa

El oficial de cumplimiento es el usuario principal de este módulo. Su tarea diaria incluye revisar las alertas nuevas, determinar si hay un riesgo real o un falso positivo, documentar la decisión y cerrar o escalar según corresponda.

El área legal puede intervenir cuando el oficial de cumplimiento escala una alerta que requiere acciones que exceden su competencia: bloqueo de cuenta, presentación de un Reporte de Operación Sospechosa (ROS) ante la UIF, comunicación al directorio, o inicio de acciones legales.


Qué se puede hacer

  • Ver el listado de alertas con filtros combinables por estado, tipo, severidad y texto libre sobre el título o la descripción.
  • Acceder al detalle de cada alerta: incluye la descripción completa del hallazgo, el resultado crudo del screening presentado como un bloque de metadata clave/valor (los campos visibles son los que el screening guardó: matched_name, score, source, threshold), los datos adicionales relevantes y el historial de comentarios.
  • Asignar la alerta a un usuario específico del equipo. Al asignarla, el estado pasa automáticamente a "En revisión", dejando claro que alguien la está analizando.
  • Agregar comentarios durante el análisis: para registrar avances parciales, consultas internas o instrucciones al equipo legal, sin necesidad de cerrar la alerta.
  • Cerrar la alerta con una justificación obligatoria: el sistema exige un texto que explique la decisión tomada (mínimo 10 caracteres). Esa justificación queda en el registro de auditoría y es la evidencia ante una inspección.
  • Escalar cuando el hallazgo lo requiere: se procede fuera del sistema (bloqueo de cuenta, contacto con UIF) y se documenta el escalamiento en la resolución al cerrar.

Conceptos clave

Tipos de alerta

El sistema declara tres tipos formales de alerta: Riesgo Alto, Match en Screening y Transacción Excede Perfil. Hoy solo se generan alertas de tipo Match en Screening; los otros dos tipos están reservados para funcionalidad futura y no producen entradas en el módulo de alertas en la versión actual.


Match en Screening

Es el único tipo de alerta que se genera actualmente. Se produce cuando el proceso de due diligence compara los datos del inversor o sus vinculados con listas externas y encuentra una coincidencia que supera el umbral de similitud configurado. Las fuentes que generan estas alertas son:

  • OFAC SDN (sanciones internacionales). El sistema busca coincidencias contra la lista SDN de la OFAC (Oficina de Control de Activos Extranjeros de Estados Unidos). Estas alertas son las de mayor prioridad: operar con una persona o entidad sancionada tiene consecuencias legales graves para su ALYC.

  • Listas consolidadas de la ONU (sanciones internacionales). Coincidencias contra las listas de sanciones administradas por el Consejo de Seguridad de la ONU. Al igual que OFAC, un match real activa el gate de revisión manual en la matriz de riesgo.

  • RePET (sanciones locales por terrorismo). Registro Público de Personas y Entidades vinculadas a actos de Terrorismo y su Financiamiento, creado por Decreto 489/2019 y administrado por el Ministerio de Justicia. Incluye las designaciones del Consejo de Seguridad de la ONU (Res. 1267 y sucesoras) más designaciones judiciales locales. No debe confundirse con un padrón de PEP: es específicamente una lista de restricción por terrorismo y su financiamiento.

Controles que no generan alertas en este módulo

Hay controles automáticos que no generan entradas en el módulo de alertas, aunque sí afectan el estado de la cuenta:

  • Búsqueda PEP por IA y Adverse news. Cuando la IA detecta un cargo público o noticias adversas que superan el umbral configurado, la matriz de riesgo fuerza el estado de la cuenta a pendiente de revisión manual — sin crear una alerta visible aquí. Para ver el detalle del hallazgo, el oficial debe ingresar al legajo de la cuenta.

  • FaceMatch (verificación biométrica). El resultado de la comparación entre la selfie y la foto del DNI queda registrado en el legajo del titular. Un resultado negativo es visible para el oficial al revisar el legajo, pero no aparece como alerta en este módulo.

  • Discrepancias ARCA / Renaper. Cuando los datos declarados por el inversor no coinciden con lo que devuelven fuentes oficiales (por ejemplo, diferencia entre el nombre OCR del DNI y el nombre registrado en ARCA), el sistema registra el mismatch en el legajo del titular. Ese dato es visible en el perfil de la cuenta, pero no genera una alerta en el módulo de alertas.


Tipos reservados para uso futuro

Riesgo Alto y Transacción Excede Perfil están declarados en el sistema pero aún no tienen implementación activa. No aparecerán en el listado de alertas en la versión actual.


Match score y umbrales

Cada vez que el sistema compara un nombre contra una lista o base de datos, aplica algoritmos de similitud que devuelven un puntaje entre 0 y 100. El puntaje refleja cuán parecidos son los nombres, considerando variaciones ortográficas, transliteraciones, orden de apellidos y alias registrados.

Cuando el sistema compara contra una lista, calcula un puntaje de similitud entre 0 y 100. Por debajo de 80 no se genera alerta. Entre 80 y 94 se considera match medio (genera alerta de severidad media). Con 95 o más, match alto (alerta de severidad alta). El umbral exacto es configurable.

El puntaje aparece en el detalle de la alerta junto con los campos que el screening guardó: nombre coincidente (matched_name), puntaje (score), umbral aplicado (threshold) y fuente (source). El detalle se presenta como un bloque de metadata clave/valor. Con esa información, el oficial puede comparar directamente con los datos del cliente y determinar si es el mismo individuo.

Un falso positivo es cuando el match coincide en el nombre pero no es la misma persona. Es el caso más común, especialmente con nombres frecuentes. La revisión humana es el control final: el sistema detecta la similitud, pero solo un oficial de cumplimiento puede verificar identidad cruzando fecha de nacimiento, documento, país de origen, industria y contexto.


Estados de la alerta

Abierta — La alerta fue generada por el sistema y todavía no tiene ningún oficial asignado. Es el estado inicial. Las alertas abiertas son la primera prioridad en el triage diario.

En revisión — Un oficial fue asignado a la alerta. El estado cambia automáticamente cuando se realiza la asignación. En este estado la alerta tiene un responsable claro; los comentarios son el canal para documentar el análisis en curso.

Cerrada — El oficial completó el análisis y documentó la resolución. El sistema pide un texto justificatorio obligatorio antes de cerrar. Esa justificación queda almacenada junto con el nombre del usuario que cerró y la fecha y hora exactas. El estado formal es uno solo: Cerrada. La distinción entre un cierre por falso positivo y un cierre con escalamiento la hace el revisor en el texto de resolución, que queda en auditoría como evidencia; el sistema no maneja sub-estados formales para cada caso.


Flujos típicos

Triage diario de alertas nuevas

Al iniciar la jornada, filtrá el listado por estado "Abierta". El sistema las presenta ordenadas por severidad descendente: las de severidad alta aparecen primero. Priorizá siempre las alertas de sanciones internacionales (OFAC SDN, ONU) por encima de cualquier otra: son las de mayor implicancia legal.

Para cada alerta abierta: revisá el título y la descripción, ingresá al detalle para ver el match crudo, y decidí si la tomás vos o si la asignás a otro miembro del equipo. Asignarla la pone en estado "En revisión" e indica que está siendo atendida.

Escalar una alerta de OFAC con match real

Si el análisis del detalle indica que el match es con la misma persona — mismo documento, misma fecha de nacimiento, mismas empresas vinculadas — no cerrés la alerta sin antes tomar las acciones que corresponden. Los pasos típicos son: bloqueo inmediato de la cuenta en el módulo de cuentas, notificación al área legal y al directorio, y evaluación de si corresponde presentar un ROS ante la UIF. Una vez realizadas esas acciones, documentalas en la resolución de la alerta ("Cuenta bloqueada. Se notificó a dirección legal. Se inició proceso de ROS.") y cerrá la alerta con el registro del escalamiento. No esperes tener el ROS presentado para cerrar la alerta: lo importante es que la resolución deje constancia de las acciones tomadas.

Resolver un match de sanciones con homónimo

El caso más frecuente es que el nombre del cliente sea similar al de un individuo en las listas de OFAC, ONU o RePET, pero no se trate de la misma persona. El detalle de la alerta muestra los campos clave del match: matched_name, score, source y threshold. Comparalos con los datos del cliente: CUIT, fecha de nacimiento, domicilio, actividad económica. Si la diferencia es clara — distinto número de documento, distinta fecha de nacimiento, distinto país — documentá el razonamiento en la resolución y cerrá la alerta. Ejemplo de texto válido: "El cliente Juan García, DNI 28.xxx.xxx, nacido el 15/03/1978, no coincide con el homónimo registrado en la lista SDN, quien figura con nacimiento en 1952 y nacionalidad iraní. Se descarta identidad." Ese texto es el que va a sostener la decisión ante una eventual inspección.

Recordá que cerrar la alerta no desbloquea la cuenta si el gate de revisión manual estaba activo. Una vez cerrada la alerta, ingresá al módulo de Cuentas y cambiá el estado de la cuenta manualmente si la revisión concluye que no hay riesgo real.


Cosas que conviene saber

  • Las alertas no son inmediatas. Los screenings corren en procesos en segundo plano que se disparan al completar el onboarding. Entre que el inversor envía su solicitud y que aparecen las alertas pueden pasar desde unos pocos segundos hasta varios minutos, dependiendo de la carga del sistema y de la cantidad de fuentes a consultar. No es necesario ni conveniente esperar frente a la pantalla; las alertas van a aparecer solas.

  • El sistema deduplica alertas por fingerprint de condición. Si el mismo cliente genera la misma condición en dos screenings distintos (por ejemplo, el mismo nombre coincide con el mismo registro en dos corridas diferentes), el sistema no crea una segunda alerta para no generar duplicados. Si un re-screening detecta una condición distinta que no estaba cubierta por una alerta previa, sí se genera una alerta nueva.

  • El re-screening periódico puede generar nuevas alertas. Las listas de sanciones (OFAC, ONU, RePET) se actualizan. Cuando el sistema corre un re-screening de la cartera de cuentas activas y detecta un match que no estaba cubierto por una alerta anterior, genera una alerta nueva. Una cuenta ya aprobada puede tener alertas activas si su situación cambió desde el onboarding.

  • Las alertas de sanciones activan un gate de revisión manual. Cuando un screening de sanciones (OFAC SDN, ONU, RePET) detecta un match, la matriz de riesgo activa un gate que fuerza el estado de la cuenta a pendiente de revisión manual — independientemente del score. Cerrar la alerta NO desbloquea automáticamente la cuenta: el oficial debe revisar el legajo y, si corresponde, cambiar el estado de la cuenta desde el módulo de Cuentas. El bloqueo es procedimental: el gate fuerza el estado, pero la decisión final (aprobar o rechazar) la toma el oficial sobre la cuenta, no sobre la alerta.

  • Las justificaciones son evidencia regulatoria. El texto de resolución que escribís al cerrar una alerta queda registrado en el módulo de Auditoría con el nombre del responsable, la fecha y la hora exactas. Ante una inspección de la UIF o la CNV, ese texto es lo que se presenta para demostrar que la decisión fue tomada conscientemente, con análisis documentado, y por personal autorizado. Un cierre sin justificación suficiente — o con frases genéricas como "revisado" o "ok" — es un riesgo regulatorio en sí mismo. La justificación debe explicar por qué se descartó el riesgo o qué acciones se tomaron.