Cumplimiento PLD en México: de la obligación regulatoria al control operativo

Mapa de investigación PLD para instituciones financieras

El cumplimiento de Prevención de Lavado de Dinero y Financiamiento al Terrorismo (PLD/CFT) no se resuelve con una carpeta de políticas ni con una lista de requisitos documentales. En una institución financiera, cumplir significa convertir obligaciones normativas en controles que funcionan todos los días: conocer al cliente, evaluar su riesgo, monitorear su comportamiento, investigar alertas, conservar evidencia, reportar cuando corresponda y demostrar por qué se tomó cada decisión.

La diferencia entre un programa PLD formal y un programa PLD efectivo está en la operación. Un manual puede describir cómo identificar clientes de alto riesgo, pero si originación no captura los datos correctos, si el core no conserva el contexto de las operaciones, si las alertas no se investigan con método o si auditoría no puede reconstruir la evidencia, el control existe sólo en papel.

Por eso esta guía aborda PLD/CFT como un sistema operativo de control. El objetivo no es repetir la regulación artículo por artículo, sino explicar cómo se conecta el marco mexicano con procesos, datos, tecnología y gobierno interno. La serie está pensada para equipos de cumplimiento, dirección, operaciones, riesgo y tecnología en bancos, SOFOMes, fintechs, entidades de crédito y organizaciones financieras que necesitan pasar de la obligación regulatoria a la ejecución trazable.

Nota editorial: este contenido es informativo y no sustituye la revisión legal, normativa, de auditoría o del oficial de cumplimiento de cada entidad. Las obligaciones concretas, criterios, reportes, plazos y controles deben validarse contra la legislación aplicable, las Disposiciones vigentes, el manual interno y los criterios de la autoridad competente.

Mapa de la serie PLD

Este artículo funciona como página pilar. Resume el mapa completo y enlaza a siete artículos satélite, cada uno enfocado en un componente operativo del programa PLD/CFT:

Marco regulatorio. Entender la base normativa mexicana y sus implicaciones operativas: Marco regulatorio PLD en México para instituciones de crédito.
KYC, listas y beneficiario controlador. Convertir identificación, screening y debida diligencia en controles trazables: KYC, LPB, PEPs y beneficiario controlador en PLD.
Matriz de riesgo y EBR. Clasificar clientes y productos con criterios explicables y proporcionales: Matriz de riesgo PLD y Enfoque Basado en Riesgo.
Perfil transaccional. Definir la normalidad esperada de cada cliente para monitorear desviaciones: Perfil transaccional PLD: cómo definir la normalidad de un cliente.
Alertas y reportes. Gestionar detección, investigación, escalamiento, evidencia y reportes: Alertas, investigaciones y reportes PLD: del monitoreo a la evidencia.
Gobierno de cumplimiento. Asegurar roles, comité, auditoría, capacitación, calibración y seguimiento: Gobierno de cumplimiento PLD: oficial, comité, auditoría y capacitación.
Tecnología PLD. Integrar onboarding, identidad, reglas, core, monitoreo, expedientes y auditoría: Tecnología para operar PLD en instituciones financieras.

La lógica es progresiva: primero se entiende la obligación; después se identifica al cliente; luego se mide riesgo; se define comportamiento esperado; se monitorea; se investiga; se gobierna; y finalmente se integra todo en una arquitectura tecnológica capaz de operar con evidencia.

1. Marco regulatorio: la obligación debe traducirse a operación

En México, el punto de partida para instituciones de crédito está en el artículo 115 de la Ley de Instituciones de Crédito y en las Disposiciones de Carácter General emitidas por la Secretaría de Hacienda y Crédito Público, con participación de la Comisión Nacional Bancaria y de Valores. Ese marco exige medidas y procedimientos para prevenir y detectar operaciones que puedan ubicarse en supuestos de lavado de dinero, financiamiento al terrorismo u otras conductas relacionadas.

También existe una capa internacional. Las 40 Recomendaciones del GAFI, difundidas en la región por GAFILAT, establecen estándares sobre enfoque basado en riesgo, debida diligencia, beneficiario final, monitoreo, reportes, sanciones financieras, conservación de registros, supervisión y efectividad. México ha ido ajustando sus reglas para alinearse con esas expectativas y con los hallazgos de evaluaciones internacionales.

La reforma publicada en el DOF el 28 de agosto de 2024 a las Disposiciones del artículo 115 de la LIC reforzó esta dirección: menos cumplimiento decorativo y más capacidad de demostrar controles efectivos, datos consistentes, medidas diferenciadas y procesos actualizados.

Para una institución, el efecto práctico es claro: no basta con saber que existe la norma. Hay que mapearla contra procesos concretos.

Algunas preguntas operativas que el marco regulatorio debe responder dentro de la institución son:

qué datos se capturan en onboarding;
qué documentos se exigen por tipo de cliente, producto y riesgo;
cómo se consulta y documenta la Lista de Personas Bloqueadas;
cómo se identifican PEPs, representantes, apoderados y beneficiarios controladores;
cómo se clasifica el riesgo inicial y continuo;
qué reglas monitorean operaciones y perfiles transaccionales;
quién investiga alertas y bajo qué SLA;
qué decisiones se escalan al oficial de cumplimiento o al comité;
cómo se conserva evidencia y por cuánto tiempo;
cómo se demuestra que los sistemas automatizados funcionan.

El detalle normativo se desarrolla en el artículo satélite sobre marco regulatorio PLD en México.

2. KYC: conocer al cliente es construir una explicación defendible

El proceso de Conocimiento del Cliente, o KYC, suele reducirse a capturar datos y subir documentos. Ese enfoque es insuficiente. En PLD/CFT, conocer al cliente significa poder explicar quién es, qué actividad realiza, quién actúa por él, quién se beneficia en última instancia, qué riesgo representa y qué comportamiento financiero es razonable esperar.

En personas físicas, esto incluye identidad, domicilio, actividad económica, origen de recursos, propósito de la relación, canal de contratación y datos fiscales. En personas morales, además incluye estructura corporativa, representantes, apoderados, administradores, socios relevantes y beneficiario controlador cuando aplique.

La operación debe separar controles con efectos distintos. Una coincidencia en la Lista de Personas Bloqueadas no equivale a una coincidencia en una lista preventiva, reputacional o fiscal. La LPB puede detonar restricciones operativas severas conforme al marco aplicable. Las listas preventivas suelen alimentar debida diligencia, revisión reforzada, rechazo por apetito de riesgo o actualización de expediente, pero no deberían confundirse automáticamente con los efectos de la LPB.

Un KYC operativo debe guardar evidencia de:

datos capturados y fuente de cada dato;
documentos recibidos y validaciones realizadas;
listas consultadas, fecha, versión y resultado;
coincidencias descartadas y fundamento del descarte;
PEPs identificadas y medidas reforzadas aplicadas;
beneficiario controlador y estructura de control;
nivel de riesgo asignado al alta;
autorizaciones requeridas;
cambios posteriores y motivo de actualización.

Sin esa evidencia, el expediente se vuelve una colección de archivos. Con evidencia estructurada, el expediente se convierte en una base de control para originación, monitoreo, auditoría y atención de requerimientos.

La guía completa está en KYC, LPB, PEPs y beneficiario controlador en PLD.

3. Matriz de riesgo y Enfoque Basado en Riesgo

El Enfoque Basado en Riesgo (EBR) parte de una premisa práctica: no todos los clientes, productos, geografías, canales y operaciones exponen a la institución de la misma forma. Por eso las medidas de PLD/CFT deben ser proporcionales al riesgo.

La matriz de riesgo es la herramienta que traduce esa premisa a decisiones. No debería ser una hoja de cálculo que se actualiza para cumplir una auditoría. Debe ser un mecanismo vivo que impacta onboarding, aprobaciones, límites, monitoreo, actualizaciones, excepciones y escalamiento.

Una matriz útil considera, como mínimo:

riesgo del cliente o usuario;
riesgo del producto o servicio;
riesgo geográfico;
riesgo del canal;
riesgo transaccional;
mitigantes aplicables;
riesgo residual después de controles.

El punto crítico es la explicabilidad. Si un cliente se clasifica como alto riesgo, la institución debe poder reconstruir por qué: qué factores pesaron, qué datos se usaron, qué lista se consultó, qué producto solicitó, qué canal usó, qué geografía involucra, qué controles mitigaron el riesgo y qué autorizaciones fueron necesarias.

También debe existir calibración. Una matriz que nunca cambia deja de reflejar el negocio. Nuevos productos, canales digitales, integraciones API, cambios geográficos, tipologías, alertas recurrentes o hallazgos de auditoría pueden exigir ajustes de pesos, reglas o criterios.

La matriz no termina en una etiqueta. Debe activar consecuencias operativas:

debida diligencia simplificada, estándar o reforzada;
periodicidad de actualización de expediente;
límites o controles adicionales;
aprobación por oficial de cumplimiento o comité;
monitoreo más sensible;
reglas específicas por producto o canal;
bloqueo o rechazo cuando el riesgo excede el apetito definido.

El desarrollo metodológico está en Matriz de riesgo PLD y Enfoque Basado en Riesgo.

4. Perfil transaccional: definir la normalidad antes de buscar anomalías

Una alerta PLD no debería depender sólo de que una operación sea grande. Debe depender de si la operación tiene sentido frente a lo que la institución sabe del cliente.

El perfil transaccional es la línea base del comportamiento esperado. Describe montos, frecuencia, canales, contrapartes, zonas, producto, actividad económica, origen y destino de recursos. Su función es conectar los datos declarados en onboarding con el comportamiento observado y con las reglas de monitoreo.

Un perfil bien diseñado distingue tres capas:

lo declarado por el cliente;
lo observado en la operación real;
lo aprobado por cumplimiento como expectativa vigente para monitoreo.

Esa distinción evita normalizar automáticamente conductas atípicas. Si un cliente declara movimientos moderados y después opera montos diez veces mayores sin explicación, el sistema no debería actualizar la normalidad por repetición. Primero debe generar revisión, pedir soporte si corresponde y documentar la decisión.

El perfil transaccional también mejora la calidad de alertas. Sin perfil, las reglas tienden a generar ruido: alertas por montos altos que son normales para ciertos clientes, y omisiones en patrones pequeños pero sospechosos. Con perfil, el monitoreo puede evaluar desviaciones reales frente al comportamiento esperado.

El perfil debe actualizarse por eventos relevantes, no sólo por calendario. Cambios de actividad, producto, canal, representante, domicilio, flujo esperado, contrapartes, estructura accionaria o comportamiento observado pueden justificar una revisión.

La guía operativa está en Perfil transaccional PLD: cómo definir la normalidad de un cliente.

5. Alertas, investigaciones y reportes: del semáforo a la evidencia

Una alerta es una pregunta, no una conclusión. Indica que una operación, patrón, cliente o evento requiere revisión frente al perfil esperado, el nivel de riesgo o una regla definida.

El problema común es tratar la alerta como un semáforo aislado. Se genera, alguien la cierra, se guarda una nota breve y el proceso continúa. Ese flujo no produce aprendizaje ni evidencia suficiente.

Un ciclo operativo robusto debe incluir:

Detección. Pregunta: qué regla o evento disparó la alerta. Evidencia: regla, versión, datos usados, fecha y cliente.
Priorización. Pregunta: qué tan urgente o material es. Evidencia: severidad, SLA, factores de riesgo y responsable.
Investigación. Pregunta: qué explica el comportamiento. Evidencia: expediente, operaciones, perfil, documentos y notas.
Decisión. Pregunta: se descarta, monitorea, escala o reporta. Evidencia: conclusión, fundamento y aprobación.
Escalamiento. Pregunta: quién debe revisar. Evidencia: oficial, comité, legal, auditoría o dirección.
Reporte. Pregunta: existe obligación de reporte. Evidencia: tipo de reporte, soporte, envío y acuse cuando aplique.
Retroalimentación. Pregunta: debe cambiar el modelo. Evidencia: ajuste de regla, matriz o perfil con justificación.

El valor de un sistema PLD no está en generar muchas alertas. Está en gestionar las alertas correctas con prioridad, método y trazabilidad. Para eso, cada caso debe conservar el contexto que lo originó: regla, versión, datos evaluados, umbral, perfil usado, riesgo del cliente, historial, evidencias revisadas y conclusión.

Las alertas también deben retroalimentar el programa. Si muchas alertas son falsos positivos por una regla mal calibrada, hay que ajustar. Si una señal relevante se detecta sólo por revisión manual, hay que evaluar si debe convertirse en regla. Si un producto genera patrones no previstos, la matriz y el perfil transaccional deben revisarse.

El flujo completo se detalla en Alertas, investigaciones y reportes PLD: del monitoreo a la evidencia.

6. Gobierno de cumplimiento: responsabilidades que sostienen el control

La tecnología ayuda, pero no gobierna sola. Un programa PLD/CFT necesita responsables, órganos de revisión, políticas, capacitación, auditoría, seguimiento de hallazgos y mecanismos de mejora.

El oficial de cumplimiento no debe ser visto como la persona que llena reportes. Debe tener capacidad para supervisar el programa, coordinar áreas, revisar excepciones, dar seguimiento a alertas, promover capacitación, atender auditorías y proponer ajustes de controles.

El comité o instancia equivalente de comunicación y control debe servir para decisiones relevantes: cambios de metodología, aprobación de políticas, revisión de clientes o casos sensibles, seguimiento de hallazgos, ajustes de reglas y evaluación de efectividad.

La capacitación también es parte del control. Un equipo de originación que no identifica inconsistencias documentales, un equipo de cobranza que no sabe escalar señales o un equipo de soporte que no registra cambios relevantes puede debilitar el programa aunque el sistema tenga reglas configuradas.

Un gobierno efectivo deja evidencia de:

nombramientos y roles;
sesiones de comité y acuerdos;
políticas y versiones;
aprobación de metodologías;
auditorías y planes de remediación;
capacitación, asistencia y evaluación;
cambios a reglas y modelos;
revisiones periódicas de efectividad;
excepciones y decisiones sensibles.

El tema completo está en Gobierno de cumplimiento PLD: oficial, comité, auditoría y capacitación.

7. Tecnología para operar PLD: integración de punta a punta

La tecnología PLD no es sólo un módulo de alertas. Es una arquitectura que conecta datos, procesos y evidencia desde el primer contacto con el cliente hasta la auditoría posterior.

En la práctica, PLD atraviesa varias capas:

marketing y canales digitales capturan prospectos;
originación recibe solicitudes, declaraciones y documentos;
identidad valida datos y evidencia;
riesgo y cumplimiento clasifican al cliente;
el core registra productos, saldos, pagos y movimientos;
monitoreo evalúa comportamiento transaccional;
alertas e investigaciones documentan decisiones;
auditoría revisa evidencia histórica.

Si esas capas no comparten información, el programa se fragmenta. El expediente queda en un sistema, el nivel de riesgo en otro, las operaciones en el core, las listas en un proveedor, las alertas en hojas de cálculo y las decisiones en correos. Esa fragmentación vuelve difícil demostrar control.

Una arquitectura moderna debe permitir:

onboarding digital con captura estructurada;
validación de identidad y documentos;
integración con fuentes de identidad y PUI cuando aplique;
consultas a listas con evidencia de versión y resultado;
matriz de riesgo parametrizable;
perfil transaccional inicial y actualizado;
reglas de monitoreo configurables;
bandejas de alertas e investigaciones;
bloqueo operativo o escalamiento cuando corresponda;
integración con core bancario y originación;
bitácoras, permisos y auditoría;
reportes internos y normativos;
trazabilidad de versiones de reglas y decisiones.

El artículo técnico está en Tecnología para operar PLD en instituciones financieras.

Cómo conectar PLD con originación, core e identidad

El cumplimiento efectivo requiere que los controles PLD estén integrados en el flujo natural del negocio. Si se agregan al final, generan fricción, retrabajo y decisiones tardías.

En originación, PLD debe participar desde el primer formulario: datos obligatorios por tipo de cliente, validaciones de identidad, listas, beneficiario controlador, actividad económica, origen de recursos, matriz de riesgo y aprobaciones. Un cliente no debería avanzar a contrato o desembolso si tiene un bloqueo crítico pendiente.

En el core bancario, PLD necesita información transaccional completa: producto, saldos, pagos, movimientos, contrapartes, fechas, canales, referencias, reversos, pagos de terceros y cambios de estado. Sin core confiable, el monitoreo se queda sin materia prima.

En identidad, PLD necesita consistencia: nombres, RFC, CURP, documentos, representantes, apoderados, beneficiarios, cotitulares y relaciones. Una misma persona no debería existir con variantes contradictorias que impidan screening o consolidación de exposición.

En gobierno, PLD necesita auditoría: quién cambió una regla, quién aprobó una excepción, quién cerró una alerta, qué evidencia revisó, qué versión del perfil se usó y qué decisión se tomó.

Acendes trabaja precisamente en esas capas: originación digital, core bancario, identidad, automatización de procesos y trazabilidad. La oportunidad no está en prometer cumplimiento automático, sino en diseñar una operación donde el cumplimiento sea verificable.

Checklist ejecutivo para evaluar madurez PLD

Una institución puede usar este checklist como punto de partida para evaluar si su programa está operando o sólo documentando controles.

Estrategia y gobierno

Existe un oficial de cumplimiento con responsabilidades y permisos claros.
El comité revisa decisiones relevantes y deja evidencia.
La metodología de riesgo está aprobada, versionada y calibrada.
Auditoría puede revisar decisiones sin depender de correos sueltos.
La capacitación está documentada y vinculada a funciones reales.

KYC y expediente

Los datos críticos se capturan de forma estructurada.
Las listas se consultan con evidencia de fecha, versión y resultado.
Se distingue LPB de listas preventivas, fiscales o reputacionales.
Beneficiario controlador, representantes y apoderados se documentan cuando aplica.
Las actualizaciones de expediente tienen motivo, responsable y fecha.

Riesgo y monitoreo

La matriz de riesgo produce una clasificación explicable.
El perfil transaccional se define antes de monitorear desviaciones.
Las reglas usan contexto de cliente, producto, canal y geografía.
Las alertas se priorizan por severidad y riesgo, no sólo por orden de llegada.
Las reglas se calibran con falsos positivos, hallazgos y cambios de negocio.

Evidencia y tecnología

Originación, core, identidad y monitoreo comparten datos consistentes.
Cada decisión sensible queda en bitácora.
Los bloqueos operativos se aplican antes de permitir actos críticos.
Los reportes internos y normativos conservan soporte y acuse cuando aplica.
Las versiones de reglas, perfiles, matrices y políticas son recuperables.

Errores comunes al operar PLD

El primer error es confundir documentación con control. Tener expedientes completos no garantiza que el cliente haya sido evaluado correctamente ni que su operación se monitoree conforme a su riesgo.

El segundo es tratar todas las listas igual. La LPB, las PEPs, las listas preventivas, los hallazgos reputacionales y los riesgos fiscales no tienen el mismo efecto operativo. Deben modelarse de forma distinta.

El tercero es dejar la matriz de riesgo desconectada del negocio. Si la clasificación no cambia aprobaciones, monitoreo, periodicidad de actualización o escalamiento, la matriz no está controlando nada.

El cuarto es monitorear sin perfil transaccional. Sin una línea base, el sistema no distingue entre operaciones normales, operaciones grandes y operaciones realmente atípicas.

El quinto es cerrar alertas sin evidencia suficiente. Una nota genérica como “sin riesgo” no explica qué se revisó ni por qué la institución decidió no escalar.

El sexto es operar PLD en sistemas separados. La fragmentación obliga a reconstruir evidencia manualmente y eleva el riesgo de inconsistencias.

De obligación a ventaja operativa

PLD/CFT suele verse como costo regulatorio. Esa lectura es incompleta. Cuando se implementa bien, el programa también mejora la calidad de datos, reduce fraudes, ordena procesos, acelera auditorías, fortalece la originación, mejora la trazabilidad del core y permite decisiones más consistentes.

El cumplimiento no debe competir con la experiencia del cliente. Debe diseñarse para pedir lo necesario, en el momento correcto, con reglas proporcionales al riesgo. Un cliente de bajo riesgo no debería sufrir el mismo flujo que una estructura corporativa compleja. Un cliente de alto riesgo no debería avanzar sin evidencia y aprobación suficientes. Esa diferenciación es precisamente el propósito del enfoque basado en riesgo.

El reto para las instituciones financieras mexicanas no es sólo “cumplir PLD”. Es operar PLD de forma que pueda demostrarse: con datos, controles, decisiones, bitácoras, reportes y mejora continua.

Cómo puede ayudar Acendes

Acendes desarrolla tecnología financiera para operar procesos críticos con trazabilidad: originación digital, core bancario, aplicaciones móviles, identidad, automatización de flujos y control documental. En PLD/CFT, esas capacidades permiten diseñar una arquitectura donde cumplimiento no vive aislado, sino conectado al ciclo completo del cliente.

Un programa PLD efectivo requiere que el negocio y la tecnología trabajen juntos. El área de cumplimiento define criterios, apetito de riesgo, reglas y decisiones. Tecnología debe convertirlos en flujos parametrizables, datos confiables, bitácoras, controles de acceso, integraciones y evidencia recuperable.

Si tu institución está revisando cómo fortalecer su operación PLD, integrar originación con core, mejorar expedientes digitales, parametrizar reglas de riesgo o hacer trazable el ciclo de alertas, el siguiente paso es mapear el proceso actual contra controles verificables.