Tecnologia para operar PLD en instituciones financieras

Mapa de investigacion PLD para instituciones financieras

El cumplimiento de Prevencion de Lavado de Dinero y Financiamiento al Terrorismo (PLD/CFT) no se opera bien con controles aislados. Una institucion puede tener un manual actualizado, reglas de monitoreo, listas, formatos de expediente y reportes, pero si todo vive separado en hojas de calculo, correos, carpetas locales y sistemas que no conversan entre si, el control termina dependiendo de esfuerzo manual.

La tecnologia PLD no deberia entenderse como un modulo que "genera alertas". Ese es solo un componente. Un programa moderno necesita conectar onboarding digital, identificacion del cliente, validacion documental, listas, matriz de riesgo, perfil transaccional, monitoreo, expedientes, bloqueos operativos, reportes, auditoria e integracion con originacion y core bancario.

La pregunta tecnica correcta no es si la institucion tiene un sistema PLD. La pregunta es si sus sistemas pueden demostrar, de punta a punta, que cada cliente fue identificado, evaluado, monitoreado y tratado conforme a su riesgo, con evidencia recuperable y decisiones trazables.

Este articulo describe el mapa de capacidades tecnologicas que una institucion financiera, SOFOM, fintech, entidad de credito o equipo de cumplimiento debe considerar para operar PLD/CFT con control real.

Nota editorial: este contenido es informativo y no sustituye la revision legal, normativa, de auditoria o del oficial de cumplimiento. Las obligaciones concretas, plazos, reportes y controles deben validarse contra el marco aplicable, las disposiciones vigentes, el manual interno y los criterios de la institucion.

Por que PLD es un problema de arquitectura operativa

PLD/CFT suele tratarse como una responsabilidad del area de cumplimiento. En la practica, es una responsabilidad distribuida que atraviesa la operacion completa:

marketing y canales digitales capturan prospectos;
originacion recibe solicitudes, documentos y declaraciones;
riesgo evalua capacidad, comportamiento y producto;
operaciones valida datos, fondea, activa cuentas o desembolsa;
core bancario registra movimientos, pagos, saldos y relaciones;
cobranza interactua con el cliente y puede detectar senales;
cumplimiento revisa alertas, expedientes, reportes y excepciones;
auditoria pide evidencia historica y trazabilidad.

Si cada etapa usa una fuente de datos distinta, el programa PLD se fragmenta. El analista no sabe si el expediente usado para aprobar al cliente es el mismo que revisa cumplimiento. El monitoreo no sabe si la actividad economica declarada cambio. El core registra operaciones, pero no siempre conserva el contexto de riesgo. Auditoria solicita evidencia y el equipo debe reconstruirla manualmente.

La arquitectura tecnologica debe resolver esa fragmentacion. No basta con capturar datos; hay que conservarlos con version, origen, fecha, usuario, autorizacion, resultado de validacion y relacion con decisiones posteriores.

En un entorno regulatorio basado en riesgo, la tecnologia debe ayudar a responder preguntas como:

Que se sabia del cliente al momento de aceptarlo?
Que reglas y listas se consultaron?
Que nivel de riesgo se asigno y por que?
Que perfil transaccional se definio?
Que operaciones rompieron ese perfil?
Que alerta se genero, quien la atendio y con que evidencia?
Que bloqueo, autorizacion o reporte se ejecuto?
Que version de la metodologia estaba vigente?

Sin esa trazabilidad, el cumplimiento se vuelve dificil de defender.

Onboarding digital: el primer control PLD

El onboarding digital es el punto donde la institucion conoce al cliente antes de permitirle operar. Por eso no debe ser solamente una pantalla para llenar datos. Debe ser un flujo controlado que capture informacion, valide identidad, solicite documentos, consulte listas, aplique reglas y deje evidencia.

Un onboarding PLD robusto incluye al menos estas capacidades:

captura estructurada de datos personales, fiscales, de contacto y actividad economica;
validacion de documentos de identidad y comprobantes;
verificacion de consistencia entre datos declarados y documentos;
identificacion de beneficiario controlador cuando aplique;
declaracion de origen y destino de recursos;
deteccion de Persona Politicamente Expuesta (PEP);
consulta de Lista de Personas Bloqueadas y listas preventivas;
evaluacion inicial de riesgo;
definicion o propuesta de perfil transaccional;
flujo de excepciones y revision manual;
bitacora de cada decision.

La institucion debe evitar que el onboarding sea un simple formulario que despues alguien "interpreta". Las preguntas, documentos y validaciones deben depender del tipo de cliente, producto, canal, monto, geografia y nivel de riesgo. Un cliente de bajo riesgo no requiere la misma profundidad operativa que uno con senales de mayor exposicion.

El sistema tambien debe impedir aprobaciones incompletas. Si falta un dato critico, si hay una coincidencia relevante en listas, si el documento no corresponde al solicitante o si la actividad declarada no es consistente con el producto, el flujo debe detenerse o escalarse antes de activar la relacion.

PUI y busqueda de identidad: integracion como control, no como tramite

Las obligaciones relacionadas con busqueda de personas, identidad y cooperacion institucional han elevado la necesidad de sistemas capaces de integrarse con fuentes externas. En ese contexto, la Plataforma Unica de Identidad (PUI) debe verse como una capacidad operativa dentro del ecosistema de cumplimiento, no como un proyecto aislado de tecnologia.

Una integracion de identidad bien disenada debe permitir:

consultar fuentes externas desde el flujo de originacion u onboarding;
registrar la fecha, entrada, salida y resultado de cada consulta;
conservar evidencia del criterio usado;
asociar la consulta al expediente del cliente o solicitante;
disparar acciones de bloqueo, revision o escalamiento cuando exista coincidencia;
evitar reprocesos manuales entre sistemas;
permitir auditoria posterior sin depender de capturas de pantalla.

La PUI se vuelve mas valiosa cuando esta conectada con el resto del ciclo de vida. Si un solicitante aparece con una senal relevante, originacion debe saberlo antes de aprobar. Si la coincidencia surge despues, el core y el monitoreo deben poder reaccionar. Si un auditor pregunta meses despues que se hizo, la respuesta debe estar en la bitacora del expediente.

Para profundizar en este tema, la serie puede enlazar al contenido existente sobre Plataforma Unica de Identidad PUI, especialmente en la etapa de implementacion del articulo.

Reglas parametrizables: cambiar el control sin reescribir el sistema

Un sistema PLD que depende de desarrollo para cada cambio se vuelve lento. Las reglas deben poder parametrizarse por personal autorizado, con gobierno, pruebas y versionado.

Algunas reglas comunes:

monto superior al perfil declarado;
frecuencia inusual de pagos, transferencias o disposiciones;
operaciones de terceros no documentados;
coincidencia total o parcial contra listas;
actividad economica incompatible con el producto;
cliente nuevo con operacion atipica de alto monto;
uso de canal o geografia distinta al comportamiento esperado;
acumulacion de operaciones por debajo de umbral interno;
cambio abrupto frente al historial del cliente;
excepciones repetidas autorizadas por el mismo usuario.

Parametrizar no significa permitir cambios sin control. Cada regla debe tener:

nombre y objetivo;
descripcion de la condicion;
fuentes de datos usadas;
segmento al que aplica;
umbral o formula;
severidad;
accion resultante;
responsable de aprobacion;
fecha de vigencia;
version;
bitacora de cambios;
evidencia de pruebas antes de activarse.

Esto evita dos problemas frecuentes. El primero es el exceso de falsos positivos por reglas rigidas que no consideran segmento, producto o perfil. El segundo es la perdida de control cuando las reglas cambian sin dejar evidencia.

Monitoreo transaccional: contexto antes que volumen de alertas

El monitoreo transaccional debe detectar desviaciones relevantes, no solamente producir volumen. Para lograrlo, necesita conectar operaciones reales con el conocimiento del cliente.

El core bancario o sistema de cartera registra hechos: desembolsos, pagos, cargos, abonos, saldos, movimientos, cuentas, referencias, contrapartes y fechas. El motor PLD debe interpretar esos hechos contra:

nivel de riesgo del cliente;
perfil transaccional declarado y observado;
producto contratado;
historial de comportamiento;
canal usado;
zona geografica;
relaciones con terceros;
alertas previas;
listas o senales externas;
excepciones autorizadas.

Una alerta de monto alto puede ser irrelevante para una empresa con actividad comprobada, pero critica para un cliente recien incorporado sin historial. Una operacion pequena puede ser importante si forma parte de un patron de fraccionamiento. Un pago de tercero puede ser normal en ciertos productos, pero requerir soporte adicional en otros.

Por eso la tecnologia debe enriquecer la alerta con contexto. El analista no deberia abrir cinco sistemas para entender que paso. La alerta debe mostrar la operacion, la regla que la genero, el perfil usado, datos del expediente, historial, coincidencias, documentos relevantes y decisiones previas.

El monitoreo efectivo tambien debe aprender de la operacion. Si muchas alertas se cierran por la misma razon, puede haber una regla mal calibrada. Si una senal repetida termina en escalamiento, tal vez debe aumentar su severidad. Si un segmento crece o cambia su comportamiento, la matriz de riesgo y los perfiles deben revisarse.

Expediente unico: datos, documentos, decisiones y evidencia

El expediente PLD no debe ser una carpeta pasiva. Debe ser una vista integral del cliente que consolide datos, documentos, validaciones, riesgo, alertas, decisiones, reportes y auditoria.

Un expediente tecnologicamente util contiene:

datos de identificacion y contacto;
documentos vigentes y versiones anteriores;
beneficiarios controladores y representantes;
actividad economica y origen de recursos;
resultados de listas y screening;
nivel de riesgo inicial y vigente;
perfil transaccional;
solicitudes, contratos o productos asociados;
operaciones relevantes;
alertas generadas;
investigaciones y conclusiones;
excepciones y aprobaciones;
reportes presentados, cuando aplique;
capacitaciones o comunicaciones relacionadas, si corresponden;
bitacora de accesos, cambios y descargas.

La clave es que el expediente conserve historia. Si el cliente cambio de domicilio, actividad o perfil, el sistema debe saber que cambio, quien lo autorizo y desde cuando aplica. Si una regla se modifico, debe quedar claro que version estaba vigente cuando se genero una alerta. Si una operacion fue autorizada como excepcion, debe conservarse la justificacion.

Esto permite que cumplimiento y auditoria revisen decisiones en su contexto original, no con informacion reconstruida despues.

Bloqueo operativo y control de excepciones

La tecnologia PLD tiene poco valor si detecta riesgos pero no puede actuar sobre la operacion. Algunas senales deben impedir avanzar hasta que exista una revision. Otras deben permitir continuidad con autorizacion documentada. La diferencia debe estar definida en reglas y flujos.

Ejemplos de bloqueos o restricciones:

no permitir alta de cliente con expediente incompleto;
detener originacion por coincidencia relevante en lista;
impedir desembolso si falta validacion obligatoria;
bloquear operaciones por revision de cumplimiento;
exigir aprobacion superior para clientes de alto riesgo;
suspender canal digital ante evento critico;
requerir actualizacion de expediente vencido;
limitar producto o monto hasta completar debida diligencia reforzada.

El control de excepciones es igual de importante. Una excepcion no es un salto informal del proceso. Debe tener motivo, usuario solicitante, aprobador, evidencia, vigencia, condicion de cierre y seguimiento.

En terminos de arquitectura, los sistemas de originacion, core, cobranza y canales digitales deben consumir el estado PLD del cliente. Si cumplimiento bloquea, la operacion debe enterarse. Si el bloqueo se levanta, debe quedar evidencia. Si la excepcion vence, el sistema debe volver a restringir o alertar.

Integracion con originacion y core bancario

PLD no puede operar desconectado de originacion y core. La originacion conoce la intencion: quien solicita, que producto quiere, que monto pide, que documentos entrega y que declaraciones hace. El core conoce la realidad operativa: que se desembolso, que se cobro, como se movio el dinero y que saldos existen.

La integracion debe cubrir al menos cinco momentos:

Antes de aceptar al cliente: identificacion, listas, riesgo inicial y expediente.
Antes de aprobar el producto: validacion de consistencia, condiciones y excepciones.
Antes de activar o desembolsar: bloqueos, autorizaciones y documentos obligatorios.
Durante la vida del producto: monitoreo transaccional, perfil y alertas.
Al cierre o salida: conservacion de expediente, historial y evidencia.

Cuando estas capas estan conectadas, el cumplimiento deja de ser una revision posterior. Se vuelve parte del flujo operativo. Una solicitud puede avanzar automaticamente si cumple reglas, escalar si requiere analisis o detenerse si hay una senal critica. Un pago puede alimentar el perfil transaccional. Un cambio de riesgo puede ajustar el nivel de monitoreo.

Para instituciones que administran credito, vale la pena conectar este tema con originacion de credito digital y core banking. La tecnologia PLD no reemplaza esas plataformas; necesita integrarse con ellas.

Auditoria y trazabilidad: disenar para explicar

La trazabilidad no se agrega al final. Debe disenarse desde el principio. Cada accion relevante debe responder quien, que, cuando, por que, con que datos y bajo que regla.

Un sistema PLD defendible conserva:

eventos de alta, actualizacion y baja;
resultados de consultas externas;
coincidencias en listas y decisiones;
versiones de matriz de riesgo y reglas;
cambios de perfil transaccional;
alertas generadas y atendidas;
notas de investigacion;
documentos revisados;
aprobaciones, rechazos y excepciones;
bloqueos y desbloqueos;
reportes, acuses o evidencia de envio;
accesos y descargas de informacion sensible.

La auditoria debe poder filtrar por cliente, periodo, usuario, regla, alerta, producto, sucursal, canal o nivel de riesgo. Tambien debe poder reconstruir la cadena completa: del dato capturado al resultado operativo.

Este punto es critico porque en PLD no siempre basta con decir que una decision fue correcta. La institucion debe demostrar como llego a ella.

Mapa de capacidades tecnologicas PLD

Onboarding digital. Resuelve captura y validacion inicial del cliente; integra originacion, identidad, documentos y listas; evidencia datos, documentos, validaciones, fecha y usuario.
Screening de listas. Resuelve deteccion de coincidencias relevantes; integra LPB, PEP, listas preventivas y fuentes internas; evidencia resultado, score, criterio y decision.
PUI e identidad. Resuelve busqueda y cooperacion operativa; integra APIs externas, expediente y originacion; evidencia consulta, respuesta, accion y bitacora.
Matriz de riesgo. Resuelve clasificacion inicial y continua; integra onboarding, producto, canal, geografia e historial; evidencia version, factores, ponderacion y resultado.
Perfil transaccional. Resuelve linea base de comportamiento esperado; integra core, cartera, pagos y declaraciones; evidencia perfil vigente, cambios y justificacion.
Reglas parametrizables. Resuelve deteccion adaptable sin desarrollo constante; integra motor de reglas, core, listas y expediente; evidencia version, parametro, prueba y aprobacion.
Monitoreo transaccional. Resuelve identificacion de desviaciones relevantes; integra core bancario, pagos, canales y clientes; evidencia alerta, datos evaluados, contexto y severidad.
Gestion de casos. Resuelve investigacion y cierre controlado; integra expediente, alertas, documentos y usuarios; evidencia notas, evidencias, decision y aprobacion.
Bloqueos operativos. Resuelve prevencion antes de operar o desembolsar; integra originacion, core, canales y cobranza; evidencia bloqueo, motivo, vigencia y desbloqueo.
Reportes. Resuelve preparacion y soporte de reportes normativos; integra alertas, casos, operaciones y catalogos; evidencia datos fuente, autorizacion, envio y acuse.
Auditoria. Resuelve reconstruccion historica del control; integra todos los modulos; evidencia bitacora completa, versiones y accesos.

Checklist para evaluar tecnologia PLD

Antes de comprar, construir o modernizar un sistema PLD, conviene revisar estas preguntas:

El onboarding puede variar por tipo de cliente, producto, canal y riesgo?
Las consultas de listas dejan evidencia recuperable y versionada?
El sistema conserva el resultado de cada regla aplicada?
La matriz de riesgo se puede explicar factor por factor?
El perfil transaccional se alimenta de datos declarados y comportamiento observado?
Las reglas se parametrizan con aprobacion, pruebas y versionado?
El monitoreo transaccional recibe datos del core sin recaptura manual?
Las alertas llegan enriquecidas con expediente, historial y contexto?
Existen flujos de caso con SLA, notas, evidencias y aprobaciones?
Los bloqueos PLD afectan originacion, core y canales cuando corresponde?
Las excepciones tienen motivo, vigencia, aprobador y seguimiento?
Auditoria puede reconstruir decisiones historicas sin pedir archivos sueltos?
Los reportes se generan desde datos fuente trazables?
Los accesos a informacion sensible quedan registrados?
La plataforma permite integrar nuevas fuentes o APIs sin rehacer todo el flujo?

Si la respuesta a varias preguntas es "no" o "depende de Excel", la institucion probablemente tiene controles documentales, pero no un sistema operativo de cumplimiento.

Errores comunes al digitalizar PLD

Un error frecuente es comprar un modulo de alertas sin resolver datos maestros. Si los datos del cliente estan incompletos, duplicados o desactualizados, las alertas nacen debiles.

Otro error es automatizar el flujo sin gobierno. Las reglas cambian, pero nadie documenta por que. Se agregan listas, pero no se define como tratar coincidencias. Se crean bloqueos, pero no hay criterios de desbloqueo.

Tambien es comun separar cumplimiento de originacion. El cliente se aprueba en un sistema y cumplimiento lo revisa despues. Eso crea retrabajo y riesgo operativo. La evaluacion PLD debe ocurrir antes de activar relaciones y durante toda la vida del cliente.

Un cuarto error es no considerar auditoria desde el diseno. Si la evidencia se guarda como archivos sueltos o comentarios sin estructura, cada revision se convierte en una investigacion manual.

Finalmente, muchas instituciones subestiman la integracion con core. El monitoreo PLD vive de operaciones reales. Si el core no envia datos oportunos, completos y normalizados, el motor de cumplimiento queda ciego.

Como Acendes conecta cumplimiento con operacion

En Acendes, el cumplimiento PLD se entiende como parte del flujo operativo de una institucion financiera, no como un repositorio separado. La originacion digital, la administracion de cartera, las integraciones de identidad, los expedientes, las reglas de negocio y la trazabilidad deben trabajar juntos.

Una arquitectura bien implementada permite que:

Acendes Aura capture solicitudes, documentos, reglas de decision y aprobaciones en originacion;
Core Banking Acendes administre productos, saldos, movimientos, pagos y eventos relevantes para monitoreo;
las integraciones de identidad y PUI alimenten el expediente del cliente;
las reglas parametrizables definan acciones automatizadas o revisiones manuales;
cumplimiento revise casos con contexto y evidencia;
auditoria consulte historicos sin reconstruir manualmente la operacion.

El objetivo no es prometer que la tecnologia elimina el criterio del oficial de cumplimiento. Al contrario: la tecnologia debe darle mejores datos, controles mas consistentes y evidencia mas defendible para tomar decisiones.

De sistema PLD a capacidad institucional

La tecnologia PLD madura no se mide por la cantidad de pantallas ni por el numero de alertas generadas. Se mide por su capacidad para prevenir operaciones no autorizadas, priorizar riesgos, documentar decisiones, alimentar reportes y demostrar control.

En instituciones financieras, el cumplimiento no puede depender de heroicidad manual. Necesita arquitectura: datos confiables, reglas parametrizables, integracion con originacion y core, expedientes vivos, bloqueos operativos, monitoreo con contexto y auditoria desde el diseno.

La mejor tecnologia PLD no es la que opera al margen del negocio. Es la que convierte el cumplimiento en parte natural de cada proceso: conocer al cliente, aprobar productos, registrar operaciones, investigar alertas, reportar cuando corresponde y conservar evidencia.