Evaluaciones de programas, análisis de deficiencias de control, revisión crítica de modelos, preparación para exámenes regulatorios — pero también revisiones de arquitectura, diseño de pipelines, ajuste de alertas y apoyo para construir sistemas que puedan explicarse ante un regulador, no solo presentarse en una licitación.
Consultoría en Crimen Financiero
Me dedico a los problemas de cumplimiento que son más complejos de lo que aparentan.
Trabajo con bancos, fintechs y empresas reguladas en AML, fraude, sanciones, validación de modelos y riesgo en activos digitales. Mi experiencia abarca tanto el cumplimiento normativo como la tecnología que lo sostiene — pipelines de monitoreo de transacciones, arquitectura de screening de sanciones, gestión del riesgo de clientes y la integración de datos que determina si todo eso realmente funciona cuando se somete a escrutinio.
Á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)
Empecé como desarrollador y DBA antes de entrar al área de crimen financiero. Esa trayectoria cambia cómo interpreto un programa de monitoreo. Cuando hay 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 — no en la política. Puedo identificarlo porque he construido este tipo de sistemas.
Sobre mí
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.
Actualmente trabajo en Huron Consulting Group. Este sitio refleja mi propio pensamiento y experiencia. 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.
Trabajo
Donde paso la mayor parte de mi tiempo.
01
AML & Monitoreo de Transacciones
Evaluación de programas, lógica y ajuste de alertas, gestión de casos, calidad de SARs y diseño de rutas de escalación. Incluye trabajo directo con la arquitectura del pipeline de monitoreo y la integración de datos que determina si el sistema genera alertas útiles o simplemente ruido.
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
Revisión independiente de modelos de detección, lógica de puntuación y definición de umbrales. Infraestructura de modelos, explicabilidad, backtesting y documentación de trazabilidad. Incluye diseño de gobernanza de IA para instituciones que aplican aprendizaje automático en detección de crimen financiero, donde la auditabilidad no es negociable.
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.
Desde el campo
Temas sobre los que sigo escribiendo porque siguen apareciendo.
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.
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.
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.
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.
Contacto
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.