Perfil transaccional PLD: cómo definir la normalidad de un cliente

Mapa de investigación PLD

En PLD/CFT, una alerta no empieza cuando una operación parece grande. Empieza cuando una operación deja de hacer sentido frente a lo que la institución sabe del cliente.

Por eso el perfil transaccional es una de las piezas más importantes del monitoreo. No es un campo más del expediente ni una etiqueta genérica como "cliente de bajo riesgo". Es la línea base que permite responder una pregunta operativa: ¿qué comportamiento financiero era razonable esperar de este cliente y qué cambió?

Bien construido, el perfil transaccional conecta tres mundos que a veces viven separados: los datos declarados en el onboarding, el comportamiento histórico observado en cuentas y productos, y las reglas de monitoreo que generan alertas. Si esos tres mundos no se comunican, el sistema de PLD termina con dos fallas frecuentes: demasiadas alertas irrelevantes o, peor, señales importantes que nunca se investigan porque no se midieron contra una expectativa clara.

Este artículo explica cómo definir, monitorear y actualizar el perfil transaccional desde un enfoque práctico para bancos, SOFOMes, fintechs, áreas de cumplimiento y equipos de tecnología financiera.

Nota editorial: este contenido es informativo y no sustituye la revisión legal, normativa o de auditoría de cada entidad. La implementación concreta debe validarse contra el marco aplicable, el manual interno de PLD/CFT y los criterios del oficial de cumplimiento.

Qué es el perfil transaccional en PLD

El perfil transaccional describe el comportamiento esperado de un cliente o usuario: montos, frecuencia, canales, productos, origen y destino de recursos, tipo de contraparte, actividad económica y patrones de uso razonables.

Su utilidad es simple: permite distinguir entre una operación inusual y una operación simplemente grande. Una transferencia de $500,000 puede ser normal para una empresa exportadora con flujos mensuales altos, pero atípica para una persona física que declaró ingresos modestos y cuyo historial ha sido de movimientos pequeños. Del mismo modo, muchas operaciones pequeñas pueden ser normales para un comercio con cobranza diaria, pero extrañas para una cuenta que se abrió con propósito patrimonial y casi no tenía actividad.

El perfil transaccional no debe verse como una predicción perfecta. Es una hipótesis documentada y actualizable sobre la normalidad del cliente. Esa hipótesis se construye con información declarada, se valida contra la operación real y se ajusta cuando hay evidencia suficiente para hacerlo.

Por qué importa para el Enfoque Basado en Riesgo

El Enfoque Basado en Riesgo exige que las medidas de PLD/CFT sean proporcionales a los riesgos identificados. En la práctica, eso significa que no basta con clasificar clientes al inicio. La institución debe observar si el comportamiento posterior confirma o contradice la evaluación inicial.

El perfil transaccional es el puente entre la matriz de riesgo y el monitoreo diario. La matriz ayuda a estimar el riesgo inherente y residual del cliente; el perfil transaccional permite comprobar si la actividad real se mantiene dentro de lo esperado.

Por ejemplo:

Cliente. La matriz puede clasificar una persona física con actividad empresarial; el perfil transaccional define ingresos mensuales esperados y variación tolerable.
Producto. La matriz identifica un crédito empresarial o cuenta operativa; el perfil describe flujos relacionados con pago a proveedores, cobranza o dispersión.
Canal. La matriz distingue operación digital, sucursal, corresponsal o comisionista; el perfil define frecuencia y horarios normales de uso.
Geografía. La matriz considera operación local, nacional o internacional; el perfil delimita zonas de origen y destino esperadas.
Comportamiento. La matriz asigna riesgo por factores conocidos; el perfil identifica desviaciones contra una línea base.

Sin perfil transaccional, la matriz de riesgo se queda como una fotografía inicial. Con perfil transaccional, se convierte en un mecanismo vivo de monitoreo.

Datos declarados: la primera versión del perfil

El perfil transaccional empieza en el onboarding. La información declarada por el cliente debe traducirse a expectativas operativas medibles. No basta con guardar "actividad económica: comercio" o "propósito de la cuenta: operación del negocio". El sistema debe convertir esos datos en parámetros útiles para monitoreo.

Algunos datos clave son:

Actividad económica o giro.
Ocupación o fuente principal de ingresos.
Monto mensual estimado de ingresos o depósitos.
Frecuencia esperada de operaciones.
Tipo de operaciones esperadas: depósitos, retiros, transferencias, pagos, dispersión, cobranza.
Canales previstos: sucursal, banca electrónica, app, corresponsales, APIs o integraciones.
Zonas geográficas de operación.
Contrapartes habituales: clientes, proveedores, empleados, socios, fondeadores.
Propósito de la relación: ahorro, nómina, crédito, inversión, cobranza, dispersión o administración de cartera.

El punto crítico es que estos datos deben capturarse de forma estructurada. Si quedan enterrados en notas libres, PDFs o comentarios manuales, después no podrán alimentar reglas, segmentaciones ni análisis.

Historial observado: cuando la operación corrige la teoría

La información declarada es necesaria, pero no suficiente. Con el tiempo, la operación real empieza a revelar patrones más confiables: cuánto mueve el cliente, en qué días, por qué canales, con qué contrapartes y con qué variación.

El historial observado debe alimentar el perfil de manera controlada. No todo cambio de comportamiento debe aceptarse automáticamente como nueva normalidad. Si un cliente declara operaciones de $50,000 mensuales y durante tres meses mueve $500,000 sin explicación, el sistema no debería simplemente subir su perfil a $500,000. Primero debe generar revisión, pedir justificación cuando corresponda y documentar la decisión.

Una práctica robusta separa tres conceptos:

Valor declarado: lo que el cliente informó al iniciar o actualizar la relación.
Valor observado: lo que el sistema ha medido en la actividad real.
Valor aprobado para monitoreo: el umbral o rango que cumplimiento acepta como expectativa vigente.

Esa separación evita que el sistema "normalice" conductas atípicas sólo porque se repitieron. También ayuda a auditoría: se puede explicar qué se declaró, qué ocurrió y quién autorizó cambiar el criterio de monitoreo.

Qué variables debe monitorear un perfil transaccional

Cada entidad debe ajustar sus variables a sus productos y riesgos, pero hay un conjunto mínimo que suele ser útil.

Monto

El monto puede medirse por operación, por día, por semana, por mes o por ciclo de producto. En créditos, por ejemplo, no sólo importa el desembolso; también importan pagos anticipados, pagos de terceros, liquidaciones inusuales y movimientos que no correspondan con el calendario esperado.

Frecuencia

La frecuencia permite detectar cambios de ritmo. Un cliente que normalmente hace 4 operaciones al mes y de pronto realiza 80 puede ameritar revisión, aunque el monto total no sea extraordinario.

Canal

El canal modifica el contexto de riesgo. Un comportamiento esperado en banca electrónica puede no ser igual de razonable si se desplaza a efectivo, comisionistas o cuentas de terceros. En originación digital, el canal también debe conectarse con identidad, dispositivo, ubicación y trazabilidad de consentimiento.

Contrapartes

No basta saber cuánto se mueve; también importa con quién. Contrapartes nuevas, recurrentes o relacionadas con jurisdicciones, actividades o señales de riesgo pueden cambiar la lectura de una operación.

Geografía

La operación puede ser local, regional, nacional o internacional. Cambios en zonas de origen/destino deben evaluarse contra el giro del cliente y el propósito de la relación.

Producto

El mismo cliente puede tener distintos perfiles por producto. Una cuenta operativa, un crédito, una línea revolvente y una app de cobranza pueden tener comportamientos esperados diferentes. Consolidar todo en una sola etiqueta puede ocultar desviaciones relevantes.

Desviaciones: cómo evitar alertas sin contexto

Una desviación no es automáticamente una operación sospechosa. Es una señal que pide contexto.

El error común es convertir cualquier exceso de umbral en alerta crítica. Eso genera fatiga operativa y hace que los analistas pierdan tiempo en casos que el propio sistema pudo clasificar mejor. Un monitoreo maduro combina reglas cuantitativas con contexto cualitativo.

Ejemplos de desviaciones útiles:

Monto mensual observado superior al rango aprobado.
Operaciones frecuentes justo por debajo de umbrales internos.
Cambio repentino de canal, por ejemplo de transferencias a efectivo.
Alta concentración en una contraparte nueva.
Operaciones incompatibles con el giro declarado.
Actividad en geografías no relacionadas con el domicilio, negocio o mercado del cliente.
Pagos de crédito hechos por terceros sin relación documentada.
Incremento de actividad después de periodos largos de inactividad.
Uso de productos digitales desde ubicaciones o dispositivos inconsistentes.

Cada desviación debe tener severidad, explicación y ruta de atención. Algunas sólo requieren revisión documental; otras deben escalar a análisis del oficial de cumplimiento, restricción operativa o reporte conforme al marco aplicable.

Actualización del perfil: cuándo cambiar la línea base

El perfil transaccional debe actualizarse, pero no de forma automática ni arbitraria. La actualización debe tener causa, evidencia y trazabilidad.

Momentos típicos para actualizarlo:

Renovación periódica del expediente.
Cambio de actividad económica, empleo, giro o tamaño del negocio.
Apertura de nuevos productos.
Incremento sostenido de operación con justificación documentada.
Cambio de canal principal.
Revisión posterior a una alerta.
Resultado de una visita, entrevista, análisis documental o auditoría.
Cambio en la calificación de riesgo del cliente.

También debe existir un criterio para no actualizarlo. Si el cliente no justifica la desviación, si la información es inconsistente o si la explicación aumenta el riesgo, el perfil no debe ampliarse como si nada hubiera pasado. En esos casos, la institución puede mantener la alerta, solicitar información adicional, restringir ciertas operaciones o escalar el caso.

Ejemplos operativos

Ejemplo 1: comercio con crecimiento estacional

Un comercio minorista declara depósitos mensuales de $300,000, principalmente por transferencias y pagos con tarjeta. En diciembre mueve $750,000.

Una regla simple marcaría exceso de monto. Un perfil transaccional más útil considera estacionalidad, historial de años previos, giro, ticket promedio y contrapartes. Si el crecimiento coincide con temporada alta y está soportado por ventas, puede actualizarse temporalmente el rango estacional. Si además aparecen depósitos en efectivo no explicados o contrapartes no relacionadas, la alerta debe mantenerse.

Ejemplo 2: acreditado que liquida con recursos de tercero

Una persona física toma un crédito y paga normalmente desde su cuenta propia. En el mes 5, un tercero liquida el saldo total.

El sistema no debe limitarse a registrar "crédito liquidado". Desde PLD, debe identificar que el origen del pago cambió. La pregunta operativa es si ese tercero está relacionado, si existe justificación económica y si el pago es congruente con el expediente. El evento puede requerir documentación adicional o investigación.

Ejemplo 3: empresa que cambia de canal

Una empresa usa banca electrónica para pagos a proveedores. De pronto empieza a operar retiros y depósitos en efectivo por montos similares.

El monto total quizá no cambió, pero el canal sí. Ese cambio puede ser normal si el negocio abrió puntos de venta físicos; también puede ser señal de una operación distinta a la declarada. El perfil transaccional debe detectar ese cambio y pedir contexto antes de ajustar la normalidad.

Ejemplo 4: cliente digital con ubicación inconsistente

Un cliente de onboarding digital declara residencia y operación local. Su actividad transaccional empieza a originarse desde ubicaciones o dispositivos recurrentes no congruentes.

La alerta no depende sólo del monto. Depende de la combinación entre identidad, canal, geografía, dispositivo y patrón histórico. Para una plataforma moderna, PLD debe conversar con prevención de fraude e identidad digital.

Gobierno y trazabilidad del perfil

El perfil transaccional no puede depender de criterios informales de cada analista. Debe existir gobierno.

Esto implica definir:

Qué datos forman parte del perfil.
Qué áreas pueden modificarlo.
Qué cambios requieren aprobación del oficial de cumplimiento.
Qué evidencia debe adjuntarse.
Qué reglas se recalculan cuando cambia el perfil.
Qué bitácora se conserva para auditoría.
Cada cuánto se revisa su vigencia.

Una buena práctica es conservar historial de versiones del perfil. Así, si una autoridad, auditor interno o comité pregunta por qué una alerta se cerró o por qué un umbral cambió, la institución puede mostrar la secuencia completa: dato declarado, operación observada, análisis, evidencia, aprobación y fecha de vigencia.

Tecnología: del expediente al monitoreo continuo

El perfil transaccional se vuelve operativo cuando vive dentro de la arquitectura tecnológica, no sólo en un PDF.

Para funcionar bien, necesita integrarse con:

Onboarding digital y expediente del cliente.
Motor de reglas y scoring de riesgo.
Core bancario o sistema de cartera.
Monitoreo de transacciones.
Listas, screening y señales externas.
Bitácoras de investigación.
Reportes regulatorios y tableros internos.

En una operación manual, el analista revisa caso por caso y depende de memoria, hojas de cálculo o consultas aisladas. En una operación integrada, el sistema puede comparar automáticamente comportamiento esperado vs. comportamiento real, priorizar desviaciones, pedir evidencia y conservar trazabilidad.

Aquí es donde soluciones como Acendes Aura, Core Banking, Presti o una Plataforma Única de Identidad pueden aportar valor: no por "resolver" PLD de forma automática, sino por convertir datos, flujos, reglas y evidencia en un proceso controlado.

Checklist para implementar perfiles transaccionales

Definir variables mínimas por tipo de cliente y producto.
Capturar datos declarados de forma estructurada desde el onboarding.
Separar valor declarado, valor observado y valor aprobado para monitoreo.
Establecer umbrales por monto, frecuencia, canal, geografía y contraparte.
Documentar tolerancias, estacionalidad y excepciones.
Crear reglas para desviaciones relevantes, no sólo para montos altos.
Evitar que el historial actualice automáticamente la normalidad sin revisión.
Conservar bitácora de cambios al perfil.
Vincular alertas con expediente, evidencia y decisión del analista.
Revisar periódicamente calibración, falsos positivos y casos no detectados.

Errores comunes

Usar el mismo perfil para todos los productos del cliente.
Guardar expectativas transaccionales en campos de texto libre.
Ajustar umbrales sólo para reducir alertas, sin evidencia.
Confundir operación inusual con operación sospechosa.
No registrar quién aprobó cambios al perfil.
Diseñar reglas sin considerar estacionalidad o giro.
No conectar pagos de crédito, terceros y origen de recursos.
Monitorear sólo montos y olvidar canal, frecuencia y contrapartes.

Conclusión

El perfil transaccional es la definición operativa de normalidad. Sin él, el monitoreo PLD se vuelve una lista de reglas desconectadas. Con él, la institución puede evaluar operaciones con contexto, priorizar alertas, documentar decisiones y actualizar su entendimiento del cliente con evidencia.

La clave está en tratar el perfil como un activo vivo: nace en el onboarding, se valida con la operación, se ajusta con controles y se conserva con trazabilidad. Esa disciplina reduce ruido, mejora la calidad de las investigaciones y ayuda a que cumplimiento, operaciones y tecnología trabajen sobre la misma base.

En PLD, conocer al cliente no termina cuando se firma el expediente. Empieza ahí.