Cómo preparar los mecanismos automatizados antes de junio de 2027

La tecnología se convierte en una obligación jurídica

La reforma a la Ley Federal para la Prevención e Identificación de Operaciones con Recursos de Procedencia Ilícita modificó sustancialmente el modelo de cumplimiento aplicable a quienes realizan Actividades Vulnerables. El cambio no consiste simplemente en digitalizar expedientes, sino en utilizar información de manera sistemática para identificar riesgos, vigilar operaciones y documentar las decisiones adoptadas.

El artículo 18, fracción X, de la LFPIORPI establece expresamente la obligación de contar con mecanismos automatizados que permitan efectuar un monitoreo permanente de las operaciones realizadas con clientes o usuarios, identificar aquellas que se aparten de su perfil transaccional, efectuar acumulaciones y proporcionar seguimiento intensificado a Personas Políticamente Expuestas y clientes de alto riesgo.

Las nuevas Reglas de carácter general desarrollan esta obligación. Su artículo 3, fracción XI Ter, adopta deliberadamente un concepto tecnológico amplio: los mecanismos pueden comprender sistemas informáticos especializados, procesos automatizados apoyados en hojas de cálculo, bases de datos u otros instrumentos equivalentes, siempre que cumplan las funciones regulatorias y puedan ser verificados por la autoridad. Por ello, reducir la reforma a la frase “hay que comprar un software antilavado” sería técnicamente incorrecto.

No importa tanto el programa como lo que sea capaz de hacer

El artículo 41 de las Reglas exige que el mecanismo sea razonablemente adecuado al volumen, naturaleza, complejidad y riesgo de las operaciones del sujeto obligado. Esta proporcionalidad permite que las soluciones tecnológicas sean diferentes entre organizaciones, pero no autoriza a prescindir de las funciones mínimas.

En términos operativos, el sistema deberá cumplir seis tareas fundamentales.

Primero, deberá conservar, actualizar y permitir consultar la información correspondiente al expediente único de identificación de cada cliente o usuario.

Segundo, tendrá que consolidar en una misma base las operaciones efectuadas con una persona determinada. Esto permitirá no sólo realizar las acumulaciones exigidas por la legislación, sino también comparar el comportamiento real contra su Perfil transaccional.

Tercero, deberá suministrar información útil para la metodología del Enfoque Basado en Riesgos.

Cuarto, tendrá que ejecutar el modelo de evaluación y clasificación del riesgo, conservando además el historial de las modificaciones tanto en el Grado de Riesgo como en el Perfil transaccional. La propia regulación exige preservar esos registros históricos durante un periodo no menor a diez años.

Quinto, deberá producir alertas respecto de determinados clientes y operaciones, particularmente aquellas vinculadas con personas de riesgo alto, Personas Políticamente Expuestas y determinadas jurisdicciones o circunstancias de riesgo.

Finalmente, deberá monitorear el uso de efectivo y metales preciosos para verificar el cumplimiento de las restricciones del artículo 32 de la Ley.

La conclusión es relevante: una base electrónica que únicamente contenga nombres, fechas y montos difícilmente cumplirá, por sí misma, con este diseño regulatorio.

Del almacenamiento al análisis

Durante años, buena parte de la gestión de las Actividades Vulnerables estuvo concentrada en preguntas relativamente objetivas: ¿debe identificarse al cliente?, ¿la operación alcanza el umbral correspondiente?, ¿debe presentarse Aviso? El nuevo modelo incorpora otra dimensión.

Ahora será necesario observar el comportamiento del cliente a lo largo del tiempo. El mecanismo deberá ser capaz de determinar si una operación corresponde razonablemente con su actividad económica, comportamiento histórico, monto usual, frecuencia, ubicación, origen o destino de los recursos y demás componentes de su Perfil transaccional.

La regulación define precisamente este Perfil a partir de elementos como monto, frecuencia, zona geográfica, origen y destino de recursos y actividad económica. Esto transforma el cumplimiento: el dato deja de ser un elemento pasivo dentro del expediente y se convierte en insumo para la detección.

Una alerta no equivale a una operación ilícita

Debe evitarse otra interpretación equivocada. La finalidad del mecanismo no consiste en declarar automáticamente sospechosa una operación cuando se actualiza determinada regla, la alerta es el comienzo del análisis, no su conclusión.

Si un cliente históricamente realiza operaciones por montos reducidos y repentinamente incrementa sustancialmente su actividad; si comienza a utilizar terceros para efectuar pagos; si cambia reiteradamente los medios utilizados; o si su comportamiento deja de coincidir con la información conocida, el mecanismo deberá ser capaz de detectar la desviación.

Después corresponderá analizarla, la organización deberá establecer responsables, procedimientos para solicitar documentación adicional, criterios para modificar la clasificación de riesgo y reglas para determinar si resulta procedente alguna medida reforzada o la presentación del Aviso correspondiente.

Por esa razón, tan deficiente puede resultar un sistema que jamás genera alertas como uno que produce cientos de incidencias que nadie analiza.

Excel puede servir; una plataforma costosa también puede incumplir

Uno de los aspectos más interesantes de las Reglas es su neutralidad tecnológica, no existe obligación de contratar una marca, proveedor o plataforma específica. La definición reglamentaria admite expresamente procesos automatizados sustentados incluso en hojas de cálculo o bases de datos, cuando sean adecuados y verificables.

Esto es especialmente importante para organizaciones de menor tamaño, sin embargo, utilizar Excel no significa reducir la obligación a una lista de clientes. Una solución de esa naturaleza tendría que permitir identificar inequívocamente a cada persona, acumular operaciones, aplicar reglas, conservar históricos, controlar modificaciones y documentar resultados.

A la inversa, la adquisición de una plataforma sofisticada tampoco garantiza cumplimiento. Si el sistema contiene parámetros genéricos que no corresponden con la actividad, los riesgos o el Manual de Políticas Internas del sujeto obligado, su costo tecnológico no subsanará la deficiencia jurídica.

¿Cómo debería comenzar la implementación?

El primer paso no debería ser solicitar cotizaciones de software, sino levantar requerimientos. La organización necesita identificar dónde se encuentra actualmente la información de clientes, operaciones, facturación, medios de pago, contratos y expedientes. Posteriormente tendrá que definir cómo se relacionarán esas fuentes y mediante qué identificador será posible reconocer a una misma persona en diferentes sistemas.

Después deberán traducirse las políticas de prevención en reglas susceptibles de automatización: acumulaciones, desviaciones del Perfil transaccional, factores de riesgo, PEP, jurisdicciones, pagos efectuados por terceros, modificaciones inusuales de frecuencia o monto y utilización de formas de pago restringidas.

El mecanismo deberá guardar coherencia con el Manual de Políticas Internas y con la metodología del Enfoque Basado en Riesgos. Las propias Reglas ordenan evitar inconsistencias entre la información empleada en la metodología y aquella contenida en los mecanismos automatizados.

A ello deben sumarse controles tecnológicos ordinarios pero jurídicamente relevantes: perfiles de usuario, separación de funciones, respaldos, bitácoras, registros históricos, control de cambios y procedimientos de recuperación. Si una clasificación de riesgo o una alerta puede ser modificada sin dejar rastro, acreditar posteriormente la confiabilidad del sistema resultará considerablemente más complejo.

El calendario ya está corriendo

El Acuerdo 115/2026 prevé una implementación escalonada, las nuevas Reglas entrarán en vigor, con las excepciones transitorias correspondientes, el 30 de noviembre de 2026. La evaluación con Enfoque Basado en Riesgos deberá encontrarse disponible para la autoridad desde el 1 de marzo de 2027, y diversas obligaciones sobre clasificación, conocimiento de clientes y Beneficiario Controlador también comenzarán a aplicarse respecto de operaciones realizadas a partir de esa fecha.

Para los mecanismos automatizados existe una fecha específica: quienes realicen Actividades Vulnerables deberán contar con ellos a más tardar el 1 de junio de 2027, incorporando la información de las operaciones efectuadas desde esa fecha.

En consecuencia, junio de 2027 no debería considerarse la fecha para comenzar un proyecto tecnológico, sino el límite para tenerlo operando. Antes deberán haberse definido requerimientos, fuentes, reglas, perfiles, procedimientos, pruebas, capacitación, documentación y mecanismos de evidencia.

La pregunta de la autoridad será: ¿puede demostrar que funciona?

El desafío principal de la reforma probablemente no estará en acreditar la existencia de un programa instalado, sino en demostrar la eficacia del modelo.

Ante una revisión, será razonable esperar preguntas como: ¿qué datos recibe el mecanismo?, ¿cómo identifica a una misma persona?, ¿qué operaciones acumula?, ¿qué reglas determinan el riesgo?, ¿cómo detecta una desviación?, ¿qué alertas genera?, ¿quién las analiza?, ¿cuándo se cierran?, ¿qué evidencia permanece disponible?

El artículo 41 convierte así a la tecnología en una pieza central del sistema de prevención. La verdadera obligación no consiste en tener software, sino en disponer de un mecanismo capaz de transformar información dispersa en conocimiento verificable sobre el riesgo.

A partir del 1 de junio de 2027, para quienes realizan Actividades Vulnerables, la diferencia entre tener datos y tener un sistema de cumplimiento será precisamente esa: la capacidad de demostrar qué detectó el mecanismo, por qué lo detectó y qué hizo la organización al respecto.