Consultoría en Crimen Financiero

Diseño y opero plataformas de tecnología en crimen financiero. Los problemas de cumplimiento vienen con el territorio.

Trabajo con instituciones financieras en la arquitectura de programas de tecnología en crimen financiero — cómo encajan el monitoreo de transacciones, el screening de sanciones, la gestión de casos y la infraestructura de datos financieros, y si aguantan cuando los reguladores y la auditoría interna los examinan de cerca. Vengo del desarrollo de software y del trabajo como DBA, antes de entrar a cumplimiento, lo que significa que puedo hacerme cargo de la capa de sistemas, no solo asesorar sobre ella.

Áreas de trabajo
  • AML & Monitoreo de Transacciones
  • Fraude & FRAML
  • Sanciones & Screening
  • Validación de Modelos
  • Cumplimiento en Activos Digitales
  • IA en Crimen Financiero
Marcos regulatorios
  • OCC / BSA / FinCEN
  • NYDFS Part 504
  • OFAC / SDN
  • FATF Travel Rule
  • OCC 2011-12 (Riesgo de Modelo)
En qué consiste el trabajo

El trabajo suele ser una combinación de arquitectura de plataformas, consolidación de sistemas, gobernanza de modelos de detección y preparación para exámenes regulatorios. En el lado técnico, eso significa el marco y la arquitectura de datos sobre los que realmente opera un programa de cumplimiento — en sistemas como Actimize, Oracle FCCM e infraestructura empresarial adyacente. En el lado regulatorio, significa asegurar que los controles aguanten cuando auditores y examinadores miran de cerca, no solo cuando todo funciona sin problemas.

Por qué el lado técnico importa

Empecé como desarrollador y DBA antes de entrar al área de crimen financiero. Esa trayectoria significa que puedo ser propietario de una plataforma, no solo evaluarla. Cuando un programa de monitoreo genera demasiados falsos positivos, un modelo no puede validarse, o un sistema de screening deja pasar coincidencias, el problema casi siempre está en los datos o en la arquitectura. Puedo identificarlo y resolverlo — porque he diseñado y estabilizado este tipo de sistemas en múltiples proveedores y entornos operativos.

Cómo llegué hasta aquí.

Crecí en Caxias do Sul, en el sur de Brasil, y empecé como desarrollador — Oracle Forms, Reports, Designer, luego DBA, luego VB. Con el tiempo asumí roles de liderazgo de equipos. El crimen financiero llegó después, y se quedó. Desde entonces he trabajado en FRAML, y más recientemente también en tecnología de cumplimiento más amplia, incluyendo sistemas de tesorería y finanzas.

Ese historial como desarrollador no es casual. Es por eso que abordo los problemas de AML y fraude de manera distinta a quienes vienen del lado legal o de auditoría. He revisado lógica de segmentación con ingenieros de datos, reconstruido flujos de generación de alertas, trabajado en vacíos de trazabilidad en la validación de modelos con equipos quant, y participado en reuniones donde el responsable de cumplimiento y el arquitecto de tecnología no logran ponerse de acuerdo sobre lo que hace el sistema. Conozco bien los dos lados de esa conversación.

A lo largo de los años he trabajado en entornos de EE.UU., Canadá, Europa, Oriente Medio, Asia-Pacífico y América Latina — distintos reguladores, distintos perfiles de riesgo, distintos niveles de madurez en cómo las instituciones construyen y gobiernan estos programas. Esa diversidad define cómo pienso sobre lo que es un programa realmente defendible frente a uno que simplemente pasa una revisión interna.

Mi enfoque actual es la arquitectura de plataformas — cómo se diseñan, conectan y gobiernan los sistemas de crimen financiero en todo el stack. Eso suele significar trabajar en las partes más difíciles de corregir después: la integración de datos entre sistemas de detección y financieros, las decisiones de ecosistema de proveedores que acumulan deuda técnica, y la capa de gobernanza que hace que la validación de modelos y la respuesta a exámenes sean realmente funcionales, no improvisadas. Este sitio refleja mi propio pensamiento. Hablo inglés, portugués y español.

Fuera del trabajo: dos hijos, cuatro gatos, dos perros y mi esposa — también de Caxias do Sul. Vivimos en Concord, en el área metropolitana de Charlotte, Carolina del Norte.

Donde suelo ser más útil.

01

AML & Monitoreo de Transacciones

Diseño y estabilización de plataformas de monitoreo de transacciones y gestión de casos. Lógica, segmentación y ajuste de alertas. Calidad de SARs y diseño de rutas de escalación. Gran parte de este trabajo implica consolidar sistemas superpuestos y corregir los problemas de integración de datos que hacen que la generación de alertas no sea confiable a escala — el tipo de problemas que parecen de ajuste pero son en realidad de arquitectura.

02

Fraude & Convergencia FRAML

Diseño de programas de riesgo de fraude, cobertura de tipologías y la pregunta estructural de si AML y detección de fraude deberían compartir datos, procesos e infraestructura de investigación. La mayoría de las instituciones los mantiene separados de maneras que generan vacíos de cobertura y trabajo duplicado.

03

Sanciones & Screening

Arquitectura de screening, cobertura y actualización de listas de vigilancia, configuración de coincidencia de nombres, gestión de falsos positivos y controles para pagos internacionales y activos digitales. OFAC SDN, ONU, UE, OFSI y listas específicas por jurisdicción.

04

Validación de Modelos & IA

Diseño de marcos de gobernanza de riesgo de modelos, revisión independiente de modelos de detección, lógica de puntuación y definición de umbrales. Construcción de la infraestructura y documentación que hacen que la validación sea trazable, reproducible y defendible — no solo formalmente conforme. Incluye diseño de gobernanza de IA donde la explicabilidad y la auditabilidad son requisitos de examen, no aspiraciones.

05

Riesgo en Activos Digitales

Arquitectura de cumplimiento para instituciones nativas en cripto y bancos con exposición indirecta. Integración de blockchain analytics, implementación de Travel Rule y TRISA, riesgo de contraparte VASP y screening de sanciones para actividad on-chain. Diseñado a partir de lo que los examinadores están pidiendo hoy.

06

KYC / CDD / EDD

Controles de onboarding, metodología de calificación de riesgo de clientes, beneficiario final, procesos de debida diligencia reforzada y la arquitectura de datos que los sostiene. Un modelo de riesgo que no puede mantenerse ni explicarse es un pasivo. La mayoría de los problemas aquí son de datos y de proceso, no de política.

Temas sobre los que sigo escribiendo porque siguen apareciendo.

La transformación financiera falla en las empresas reguladas por una razón concreta.

El problema no es la tecnología ni la ambición. Es que los programas de transformación se diseñan sin tener en cuenta cómo el cumplimiento, el riesgo y las restricciones regulatorias interactúan con los sistemas que se están reemplazando.

LinkedIn →

Las stablecoins no van a esperar a que tu programa de cumplimiento se ponga al día.

Las stablecoins ya están circulando en flujos de pago y en la actividad de clientes de instituciones reguladas — tengan o no una política al respecto.

LinkedIn →

La IA tiene un problema de datos. Y casi nadie lo está diagnosticando bien.

El fallo no está en el modelo. Está en los datos que lo alimentan — y en las decisiones institucionales que dieron forma a esos datos mucho antes de que se entrenara cualquier sistema.

LinkedIn →

Tu banco no opera con cripto. Eso no significa que el cripto no esté afectando tu banco.

La exposición al cripto llega a través de la actividad de los clientes, los patrones de pago y las relaciones con corresponsales — generalmente mucho antes de que haya una decisión formal de entrar al mercado.

LinkedIn →

La validación de modelos es donde los programas de cumplimiento suelen estar más expuestos.

No porque los modelos estén mal. Sino porque las instituciones no pueden explicar las decisiones, reproducir los resultados ni mostrar qué cambió entre versiones cuando un examinador lo pregunta.

LinkedIn →

Implementar IA en crimen financiero no es, en primer lugar, una decisión tecnológica.

Las preguntas más difíciles son de gobernanza: quién aprueba un cambio de umbral, cómo se documenta, y qué pasa cuando un investigador no coincide con la puntuación del modelo.

LinkedIn →

Escríbeme con lo que necesitas.

Si tienes un problema de AML, sanciones, riesgo de modelo, fraude o activos digitales y quieres una segunda opinión o ayuda para definir qué hacer — unas pocas líneas sobre la situación son suficientes para empezar.

El mensaje llega directamente a mí. No hay correo expuesto en esta página.