Abrir una cuenta empresarial puede tomar minutos para el cliente y horas para el equipo de compliance. Ese contraste explica buena parte del problema del onboarding B2B en fintechs.
Mientras la experiencia del usuario se volvió digital, muchos procesos internos de AML (Anti-Money Laundering) siguen dependiendo de analistas que consultan diferentes fuentes, revisan documentos, investigan socios y beneficiarios finales, buscan coincidencias en listas de sanciones y PEP, evalúan alertas y, finalmente, deciden si una empresa puede ser aceptada.
No es necesariamente un mal proceso. El problema aparece cuando el volumen crece. Cien empresas nuevas al mes pueden ser manejables con un buen equipo. Diez mil requieren otra arquitectura.
La solución tampoco consiste simplemente en “automatizar AML”. Una fintech necesita separar aquello que puede ser decidido de forma determinística de aquello que realmente requiere investigación y criterio humano.
La mejor automatización de AML no elimina al analista de compliance. Elimina el trabajo que no necesita un analista de compliance.
Y esa diferencia importa.
El onboarding empresarial es mucho más que validar un CNPJ o Tax ID
En un onboarding individual, gran parte de la evaluación gira alrededor de una persona. En empresas, la estructura rápidamente se vuelve más compleja.
La fintech necesita entender no solo si la compañía existe, sino quién está detrás de ella. Eso puede implicar validar datos registrales, situación de la empresa, actividad económica, fecha de constitución, dirección, socios, administradores y beneficiarios finales.
Después aparece una segunda capa: riesgo.
- ¿Alguno de los socios es una persona políticamente expuesta (PEP)?
- ¿Hay coincidencias con listas de sanciones o watchlists?
- ¿Existen señales negativas relevantes?
- ¿La actividad declarada por la empresa es compatible con el producto solicitado?
- ¿Su estructura societaria merece una revisión adicional?
- ¿Hay inconsistencias entre la información declarada y la obtenida de fuentes externas?
El verdadero desafío del KYB no es consultar un dato: es conectar diferentes señales y convertirlas en una decisión consistente.
¿Dónde se pierde tiempo en una revisión AML manual?
Pensemos en un caso bastante común: una fintech recibe la solicitud de una nueva empresa. Un analista abre el registro mercantil o una fuente de datos empresariales. Verifica la información de la compañía. Identifica a los socios. Consulta a las personas relacionadas en otro proveedor. Revisa listas de PEP y sanciones. Busca información adicional. Compara los resultados con la política interna. Si aparece una alerta, investiga. Después documenta su conclusión.
Multiplique este proceso por cientos o miles de solicitudes. El problema no es únicamente el costo.
Dos analistas pueden interpretar una misma situación de maneras ligeramente diferentes. En períodos de mayor demanda, los tiempos aumentan. Y una política que existe perfectamente en un manual de compliance puede ejecutarse de manera diferente en la operación.
La automatización comienza precisamente aquí: transformando la política de AML en un flujo de decisión ejecutable.
Paso 1: convertir la política de AML en reglas
Muchas políticas de compliance todavía están escritas para ser interpretadas por personas. Por ejemplo: “Empresas con beneficiarios finales identificados como PEP deben ser sometidas a diligencia reforzada.”
Para automatizarla, hay que convertirla en lógica operacional:
Beneficiario final identificado → consulta PEP → coincidencia confirmada → Enhanced Due Diligence / revisión manual.
Otro ejemplo: “Empresas pertenecientes a determinados sectores de mayor riesgo deben recibir un análisis adicional.” La lógica puede convertirse en:
Actividad económica → clasificación de riesgo → riesgo alto → solicitar info adicional + enviar a revisión.
Este ejercicio es fundamental. Antes de comprar más datos o incorporar IA al proceso, una fintech necesita saber qué quiere decidir con cada señal.
Paso 2: automatizar la recopilación de datos
Una vez estructurada la política, el siguiente cuello de botella son los datos: registros corporativos, estructura societaria, beneficiarios finales (UBO), PEP, sanciones, watchlists, información judicial, señales de fraude y documentos.
En un flujo automatizado, el sistema recibe la identificación de la empresa y ejecuta automáticamente las consultas necesarias según la política. Pero no todas las empresas necesitan las mismas consultas: las empresas sencillas siguen un camino rápido, mientras que estructuras complejas activan consultas progresivas solo cuando el riesgo lo justifica.
Paso 3: automatizar el screening de socios y beneficiarios finales
Aprobar una empresa sin entender quién la controla deja fuera una parte fundamental del riesgo. Una infraestructura de decisión debe trabajar con relaciones:
Empresa → socios → beneficiarios finales → administradores.
La plataforma necesita interpretar esos resultados dentro de la política: una coincidencia potencial con PEP no necesariamente significa rechazar a la empresa, sino dirigirla a diligencia reforzada.
Screening no es decisioning.
Consultar listas es screening. Determinar qué hacer con el resultado es decisioning.
Paso 4: crear un risk score de onboarding
Consolidar señales en clasificaciones de riesgo permite un tratamiento ágil y transparente:
- Low Risk: estructura societaria simple, sin alertas → aprobación automática.
- Medium Risk: señales que requieren validación → revisión simplificada o solicitud de documentos.
- High Risk: combinación de factores AML, PEP o jurisdicciones complejas → Enhanced Due Diligence (EDD).
Paso 5: automatizar lo evidente y enviar las excepciones a personas
Una fintech debería intentar automatizar todos los casos en los que una persona no agrega valor. Los casos claros se aprueban o rechazan de inmediato. El juicio humano se concentra en las excepciones complejas.
En Sinky, este diseño conecta el flujo de Studio con AI Case Management, donde los analistas reciben expedientes previamente organizados con toda la evidencia necesaria.
Paso 6: usar IA donde realmente tiene sentido
En AML hay decisiones que deben ser determinísticas. La IA destaca procesando tareas que consumen tiempo: lectura de documentos, cotejo de datos declarados, detección de discrepancias y generación de resúmenes estructurados del caso.
Ejemplo de resumen estructurado generado por IA:
“La empresa fue enviada a revisión debido a una potencial coincidencia PEP relacionada con uno de sus beneficiarios finales. Los datos registrales de la compañía son consistentes con la información declarada. No se encontraron coincidencias relevantes en las demás verificaciones realizadas. Se recomienda validar la coincidencia PEP antes de continuar el onboarding.”
Paso 7: hacer que cada decisión sea explicable
Si una empresa fue aprobada hace seis meses, la entidad debe poder reconstruir exactamente qué política regía, qué datos se obtuvieron, qué reglas saltaron, qué analista intervino y por qué se adoptó esa resolución.
Paso 8: el AML no termina cuando termina el onboarding
Un cliente de bajo riesgo hoy puede alterar su directorio o incorporar nuevos socios PEP en el futuro. Las reglas de onboarding deben extenderse naturalmente hacia políticas de re-screening y monitoreo continuo.
¿Qué arquitectura necesita una fintech para automatizar AML?
Se requieren cuatro capas operando de forma integrada:
- Datos: fuentes registrales, UBO, PEP, sanciones, fraude y datos internos.
- Decisioning: reglas, políticas, scores, modelos, workflows y thresholds.
- Case Management: gestión de excepciones, análisis humano y trazabilidad.
- Monitoring: re-screening continuo y detección de cambios de riesgo.
¿Dónde entra Sinky?
La propuesta de Sinky conecta los mejores proveedores de datos a través del Data Marketplace con una potente capa de decisión en Sinky Studio y gestión de casos en AI Case Management.
Las máquinas ejecutan la política y las personas se concentran en las excepciones que exigen criterio.
