Supervisión de prevención de lavado de dinero para bancos patrocinadores en programas fintech

Última actualización: septiembre de 2026

La supervisión de prevención de lavado de dinero (AML) de un banco patrocinador es el trabajo que realiza la entidad para seguir siendo responsable de cómo cada programa fintech que patrocina detecta y reporta delitos financieros, incluso cuando la fintech realiza ese trabajo en el día a día. Lo difícil es la escala: un solo programa se puede supervisar mediante informes y reuniones, pero una cartera completa de programas, cada uno con sus propios proveedores, reglas e historial de casos, no. Esta guía cubre los pilares para que la supervisión funcione en múltiples programas: visibilidad del cliente final, una visión unificada de cada persona a través de los programas, reglas adaptadas a cada programa, acceso a datos unidireccional y pruebas listas para una auditoría.

Resumen rápido

• El banco patrocinador no puede eludir su responsabilidad legal mediante contratos. Una fintech puede encargarse de la incorporación y del monitoreo de primera línea, pero el banco responde por el resultado.

• La supervisión falla cuando cada programa reporta en su propio formato utilizando sus propias herramientas, lo que hace que el banco vea resúmenes en lugar de clientes reales.

• La actividad inusual suele llegar al banco en forma de informe de actividad inusual (UAR), y el banco decide si lo convierte en un reporte de actividad sospechosa (SAR) y lo presenta.

• Los auditores están evaluando cómo detecta el banco la actividad de una misma persona a través de varios socios fintech, y no solo dentro de cada uno de ellos.

• Las reglas específicas de cada programa requieren control de cambios: quien diseña un cambio en una regla no debe ser quien la active en producción.

• La guía interinstitucional de 2023 sobre terceros sigue vigente, pero se propuso un reemplazo el 11 de septiembre de 2026. La norma de programas de AML/CFT de la FinCEN también sigue siendo una propuesta.

Qué debe cubrir la supervisión de AML del banco patrocinador

Un banco patrocinador debe poder responder a cuatro preguntas sobre cualquier programa en cualquier momento: quiénes son los clientes finales, qué están haciendo, qué reglas analizaron esa actividad y qué pasó con cada alerta. Si el banco solo puede responder esto enviando un correo a la fintech, está dependiendo de su socio en lugar de supervisarlo. El vicepresidente de operaciones de crédito y cumplimiento de una fintech de préstamos con bancos asociados describió este estándar de forma clara: "Tienes que demostrar que lo hiciste, ¿verdad? No se trata solo de hacer lo correcto. Tienes que poder demostrar que lo hiciste".

En la práctica, esto se divide en cinco componentes de trabajo. Cada uno representa un punto donde la supervisión puede fallar silenciosamente al agregar un nuevo programa.

Cada fila representa una decisión de diseño independiente. Un banco puede tener reglas de programa sólidas y aun así fallar en la segunda fila, que es donde se está centrando la atención de los auditores.

Por qué se rompe la supervisión al aumentar el número de programas

La supervisión falla a medida que se suman programas porque cada fintech llega con su propia infraestructura tecnológica. Un director de riesgos de fintech en un banco patrocinador comentó que hoy en día la supervisión implica recopilar diferentes formatos de informes de cada fintech, según las herramientas que utilicen. Así, el banco pasa el tiempo unificando formatos en lugar de analizar riesgos.

El volumen empeora la situación. El mismo directivo resumió el impacto financiero en una frase: "No podemos cobrar lo suficiente como para contratar a una persona nueva cada vez que sumamos un programa". La supervisión que depende de aumentar el personal por cada programa deja de ser viable a medida que crece la cartera.

El crecimiento de los programas también distorsiona el panorama de las alertas. Un gerente de sistemas BSA/AML de un banco patrocinador señaló que el efecto del ajuste de una regla quedó oculto por el pico de alertas tras integrar a un nuevo socio procesador, por lo que se necesitó un análisis independiente para distinguirlos. Un nuevo programa altera la línea base, y un banco que no rastrea el origen de cada alerta no puede saber si sus ajustes funcionaron.

Patrones de falla a tener en cuenta

Un gerente de la unidad de inteligencia financiera (UIF) de un banco patrocinador describió el segundo patrón de forma directa: las alertas de diferentes productos de depósito se revisaban en una única lista común, por lo que una regla escrita para un producto específico afectaba a los clientes de todos los programas.

Quién monitorea, quién reporta y quién presenta

A menudo, la fintech o su administrador de programas se encargan de la incorporación y del monitoreo de primera línea según su contrato con el banco, pero el banco patrocinador es el dueño de la decisión final sobre el SAR. Un director de tesorería y cumplimiento en una fintech de pagos resumió la perspectiva de su lado: "Nosotros no presentamos ningún SAR. Si tuviéramos que hacerlo, probablemente correría por cuenta de nuestro banco patrocinador".

El flujo común consta de cuatro pasos:

1. La fintech detecta. Su equipo de monitoreo u operaciones detecta una actividad que parece inusual para el cliente.

2. La fintech reporta al banco. Envía un informe de actividad inusual (UAR), junto con la documentación de respaldo, al banco patrocinador.

3. El banco investiga y decide. El equipo de BSA del banco patrocinador revisa el UAR, suma la información que tiene de otros programas y decide si la actividad amerita un SAR.

4. El banco presenta e informa. El banco presenta el SAR e indica a la fintech qué medidas tomar con la cuenta.

Un vicepresidente sénior de regulación bancaria en un proveedor de infraestructura de BaaS describió este como el modelo habitual: la fintech genera el UAR, lo envía al banco patrocinador y este decide si se convierte en un SAR. El punto débil es el paso tres. Un vicepresidente y oficial de BSA de un banco patrocinador lo expresó así: "Recibimos un UAR de un socio y no siempre tenemos el mecanismo para asociar a ese actor de riesgo con otras cuentas en nuestros demás socios".

Este flujo también va en sentido contrario para las fintechs que trabajan con más de un banco. Un líder de cumplimiento de una fintech con varios bancos patrocinadores comentó que un cliente con cuentas en varios de ellos generaba actividad que debía reportar a cada uno, pero no podía revelar la actividad de un banco patrocinador a otro. La fintech no puede cerrar esa brecha, por lo que cada banco debe tener una visibilidad completa de su propia exposición.

Los datos que un banco patrocinador necesita de cada programa

Un banco patrocinador necesita datos de transacciones y clientes al nivel del usuario final de la fintech, no resúmenes de la fintech en general. El director de riesgos de un banco comunitario explicó por qué: "Si monitoreamos a nivel de socio, nunca encontraríamos nada porque es solo un conjunto de transacciones minoristas idénticas".

Las cuentas agrupadas y FBO (a beneficio de terceros) complican esto. En una cuenta FBO (mantenida para beneficio de los clientes de la fintech), el sistema central del banco ve una sola cuenta, mientras que la actividad pertenece a muchas personas. El mismo director de riesgos señaló que el banco no había dado soporte a cuentas FBO porque su monitoreo no podía llegar a esa segunda capa y agrupar las transacciones por el cliente final del socio, lo que los obligaba a rechazar cuentas potenciales por ese motivo.

Los documentos son tan importantes como las transacciones. Un director de control de calidad de cumplimiento de BSA en un banco patrocinador comentó que obtener los documentos que una fintech recopilaba al incorporar o actualizar la información del cliente (KYC) era un proceso totalmente manual: el banco tenía que pedirlos al socio cada vez. Cada solicitud manual retrasa la investigación y no deja un registro claro de qué vio el banco y cuándo.

El acceso debe ser unidireccional. Un oficial de BSA de un banco comunitario con socios fintech quería que el banco pudiera ver a los clientes de todos los socios y a los suyos propios, mientras que ningún socio pudiera ver a los clientes minoristas del banco ni a los de otras fintechs. Esta regla define la elección de las herramientas, ya que la infraestructura compartida solo es aceptable si la separación entre socios se garantiza mediante el sistema y no únicamente mediante políticas. Los programas con flujos transfronterizos añaden una capa de complejidad por corredor, la cual se detalla en una guía independiente sobre flujos de trabajo de AML transfronterizos.

Los auditores también evaluarán los datos. Un gerente de sistemas de BSA/AML de un banco patrocinador preveía que los auditores pedirían las reglas de fondo y la lógica de las consultas, y que harían pruebas consultando los datos de monitoreo directamente. Los datos que el banco solo posee en forma de informes de socios no pueden consultarse de esa manera.

Identificar a un cliente en todos los programas

La resolución de identidades a través de varios programas significa reconocer que el cliente de una fintech es la misma persona, empresa o dispositivo en otra, y analizar su actividad de forma integrada. Un director de BSA de un banco patrocinador de BaaS, tras una auditoría federal y estatal conjunta, señaló que los reguladores de banca integrada se centran cada vez más en detectar actividades sospechosas en múltiples socios fintech, y no solo dentro de cada uno.

La información clave suele estar ya en los datos del banco. Un gerente de la UIF de un banco patrocinador de BaaS describió casos de clientes con el mismo ID fiscal o número de seguro social que aparecían en varios socios fintech bajo diferentes ID de usuario, relacionados pero no vinculados en el sistema, por lo que conectarlos en la gestión de casos requería un proceso manual. La resolución de identidad funciona mediante identificadores compartidos: ID tributaria, número de seguro social, dispositivo, teléfono, dirección y cuenta de la contraparte.

Un hallazgo en un programa debería comunicarse a todos los programas que esa persona utilice. Un director de cumplimiento de delitos financieros en un banco patrocinador de BaaS mencionó que cuando alguien comete fraude contra una fintech, el banco quiere impedir que esa persona acceda a cualquier programa en su plataforma. Dado que el banco no controla a quién incorpora cada fintech, debe detectar la coincidencia rápidamente después de la incorporación, en lugar de intentar bloquearla en el registro.

Esta es también la razón por la que algunos bancos patrocinadores se replantean quién debe realizar el monitoreo. Líderes de BSA de dos bancos patrocinadores se preguntaban qué parte del monitoreo y filtrado de transacciones podría asumir el banco directamente en lugar de depender de sus socios fintech. Un banco que monitorea todos los programas bajo un único perfil de cliente tiene una visión integral; un banco que solo recopila las alertas de cada socio, no. Cuando la actividad de una misma persona también afecta a otras instituciones, esta misma lógica se aplica al intercambio de información entre instituciones.

Una línea base bancaria con reglas específicas para cada programa

Cada programa es diferente, por lo que el monitoreo debe adaptarse a cada uno de ellos, pero siempre bajo las reglas que el banco define y puede modificar. Un vicepresidente sénior de operaciones de UIF en un banco que está lanzando programas fintech comentó que los auditores siempre piden ver un monitoreo que se adapte a cada fintech y a su riesgo particular.

El director de riesgos de un banco patrocinador de tarjetas prepago dio un ejemplo concreto: "Personalizamos nuestras reglas para cada programa. Así, una tarjeta o programa puede permitir cargas de efectivo y otra no, ¿verdad? Por lo tanto, configuramos diferentes parámetros de monitoreo para cada uno de nuestros programas". La misma tipología general del banco (por ejemplo, estructuración de efectivo) funciona con parámetros distintos en cada programa.

Las reglas también deben adaptarse al nivel de riesgo del socio. Un programa de mayor riesgo (ya sea por el producto, la base de clientes o el canal de pago) debe tener parámetros más estrictos y una mayor revisión que uno de bajo riesgo. Usar las mismas reglas para todos genera demasiadas alertas innecesarias en los programas de bajo riesgo o debilita el monitoreo en los de alto riesgo.

El control de cambios suele ser el punto débil de las reglas específicas por programa. Un oficial de riesgos de producto en un banco patrocinador de BaaS describió un control dual para los cambios de reglas: la persona que diseña el cambio lo presenta y el oficial de BSA lo activa en producción, una práctica que, según el banco, los auditores valoraron muy positivamente. Cada cambio debe tener fecha y versión para que cualquier alerta pueda vincularse después con la versión de la regla que la generó. Cómo probar y documentar un ajuste de reglas para mantener la cobertura se analiza en una guía independiente sobre la reducción de falsos positivos en AML.

Qué esperan los auditores y en qué estado se encuentran las normas

Los auditores esperan que un banco patrocinador demuestre la supervisión de sus socios fintech mediante registros documentados; una política por escrito no es suficiente para cumplir con esta expectativa. Un vicepresidente sénior de BSA, AML y fraude de un banco que está lanzando un programa BaaS resumió la realidad regulatoria en una frase: "Una vez que te conviertes en un banco BaaS, la atención nunca se aparta de ti".

Esa atención se centra ahora en las pruebas que respaldan el modelo de supervisión. Un banco debe ser capaz de generar desde sus propios sistemas el historial de alertas, las versiones de las reglas y el registro de escalamiento para cualquier programa que el auditor elija evaluar.

El panorama regulatorio está cambiando, por lo que es importante conocer el estado de las normativas:

Considere esta tabla como una captura del momento actual. Un banco patrocinador que diseñe su modelo de supervisión hoy debe trabajar conforme a la guía de 2023 mientras sigue de cerca el borrador de reemplazo que podría cambiar las reglas del juego. La norma de la FinCEN es aún una propuesta, por lo que un banco no debe considerar sus términos como requisitos obligatorios todavía.

Las sanciones y medidas de cumplimiento añaden presión a este panorama. Desde 2024, los reguladores bancarios de EE. UU. han emitido acciones correctivas de BSA/AML contra bancos que ofrecen servicios a programas fintech, llegando incluso a suspender algunos de ellos. Las deficiencias en la supervisión de socios fintech y en los programas BSA/AML son constantes en estas acciones, pero las resoluciones demuestran que corregir el rumbo es posible.

Desde que la Reserva Federal finalizó su programa de actividades novedosas, las alianzas fintech se evalúan como cualquier otra actividad bancaria habitual, con la misma exigencia de controles demostrables por parte del banco.

Cómo encajan los agentes de IA en los distintos programas

Los agentes de IA encajan en la supervisión del banco patrocinador como herramientas de preparación de casos que sugieren medidas, mientras que los analistas toman la decisión final. Un agente puede recopilar un UAR, la actividad del cliente en otros programas, alertas previas y entidades relacionadas en un solo caso mucho más rápido de lo que un analista podría hacerlo manualmente. Sin embargo, la validación final sigue estando en manos del analista.

La gobernanza depende del banco patrocinador, incluso para las herramientas de IA que una fintech quiera utilizar. Un líder de cumplimiento en un neobanco con bancos asociados comentó que los requisitos de su banco patrocinador frenaron una prueba de concepto con un agente de IA, ya que cualquier herramienta que use el neobanco debe ser auditable y contar tanto con la aprobación interna como con la del banco patrocinador. Un banco patrocinador debe estar preparado para definir estas exigencias en sus programas.

El peligro que se debe evitar es la automatización sin revisión aplicada a datos que nadie ha verificado. Un oficial adjunto de BSA en un banco de criptomonedas señaló: "La próxima oleada de órdenes de consentimiento podría dirigirse contra las empresas que utilicen agentes de IA internos para cerrar alertas de forma automática, alimentándose de datos de mala calidad y generando resultados erróneos".

El diseño que resuelve esta preocupación mantiene siempre a un humano a cargo de cada decisión y registra los motivos de esta. La sección de agentes de Oscilar especifica que "los agentes nunca cierran ni escalan alertas de forma autónoma; cada recomendación es revisada y validada por un analista humano antes de tomar cualquier medida". El nivel de intervención humana también puede ajustarse según el nivel de riesgo. El líder de riesgos de una fintech mencionó que su equipo mantiene una supervisión humana constante en cada clasificación de riesgo, lo cual es fundamental para la debida diligencia reforzada y los clientes de alto riesgo. Este mismo principio se aplica a los diferentes programas: los agentes de riesgo que recomiendan mientras los analistas deciden pueden encargarse de recopilar la información, adaptando el nivel de revisión humana al nivel de riesgo.

La propuesta de Oscilar

Oscilar unifica la supervisión del banco patrocinador en una única plataforma controlada por el banco, de modo que cada programa fintech funciona bajo el mismo modelo de datos y cada decisión deja un registro claro. Para las reglas específicas por programa, nuestra solución para bancos patrocinadores permite "duplicar modelos de riesgo entre fintechs con un solo clic, permitiendo personalizar fácilmente los modelos de riesgo de cada socio mediante un sistema visual de arrastrar y soltar". Para el flujo de UAR a SAR, ofrece el "escalamiento con un solo clic de alertas de SAR/UAR desde las fintechs asociadas hacia el banco patrocinador".

Para facilitar las pruebas de auditoría, Oscilar mantiene un registro completo de cada decisión con sus justificaciones almacenadas, priorizando siempre la supervisión humana en el proceso. La evaluación previa al lanzamiento se estructura mediante un modelo de colaboración de diseño de cuatro semanas: configuración de datos, prueba retrospectiva con alertas históricas, ejecución en paralelo y una sesión de análisis con su equipo.

Encontrará todos los detalles del producto en nuestra página sobre supervisión de AML para bancos patrocinadores.

Preguntas frecuentes

¿Quién es el responsable del cumplimiento de AML en una alianza entre un banco patrocinador y una fintech?

El banco patrocinador sigue siendo el responsable final del cumplimiento de AML en todos sus programas fintech, ya que las cuentas se operan bajo su licencia bancaria. El acuerdo del programa puede delegar en la fintech las tareas de incorporación, monitoreo e investigación de primera línea, y esta tiene la obligación de realizarlas correctamente. Lo que el acuerdo no puede hacer es trasladar la responsabilidad legal del banco ante los reguladores.

¿Quién presenta el SAR cuando el cliente de la fintech es el investigado?

Por lo general, el banco patrocinador presenta el SAR. La fintech suele enviar un informe de actividad inusual (UAR) con el análisis de la investigación, y el equipo de BSA del banco investiga, decide si la actividad es sospechosa y realiza la presentación. El banco también debe comprobar los antecedentes del investigado en sus otros programas antes de decidir.

¿Qué datos necesita un banco patrocinador de sus socios fintech para el monitoreo de AML?

Un banco patrocinador necesita datos transaccionales y de clientes detallados al nivel del usuario final de la fintech, incluido el desglose de saldos detrás de cualquier cuenta agrupada o FBO. También requiere acceso a los documentos de incorporación y actualización de datos sin tener que solicitarlos manualmente cada vez. Los resúmenes a nivel de socio ocultan los comportamientos individuales en flujos minoristas homogéneos.

¿Cómo identifican los bancos patrocinadores a un mismo cliente en diferentes programas fintech?

Los bancos patrocinadores identifican al mismo cliente a través de varios programas cruzando identidades mediante identificadores comunes como el ID tributario, número de seguro social, dispositivo, teléfono, dirección y cuenta de destino. Este análisis solo funciona si los datos de los clientes de todos los programas se unifican en un solo lugar del banco. Un hallazgo en un programa debería vincularse de inmediato con todos los demás programas que use esa persona.

¿Pueden los agentes de IA ayudar a un banco patrocinador a revisar alertas en varios programas manteniendo la validación humana?

Sí. Los agentes de IA pueden estructurar un caso analizando múltiples programas, conectando entidades vinculadas y alertas previas para recomendar una resolución, mientras que un analista toma la decisión final. El banco debe exigir un registro de cada recomendación, de sus fundamentos y de la decisión humana correspondiente.

La supervisión de un banco patrocinador es tan fuerte como la visibilidad que tiene de los clientes reales de sus programas. Si está evaluando dónde falla esa visibilidad hoy, empiece por el programa cuyos datos le resulten más difíciles de consultar por sí mismo. Descubra cómo nuestra plataforma le ayuda a solucionarlo en la página de Oscilar sobre supervisión de AML para bancos patrocinadores.