Conciliación del ledger BaaS: cómo diseñar la conciliación diaria de cuentas FBO después de Synapse

Yury Pukhov CEO & Mobile Engineering Lead, YuSMP Group

La conciliación del ledger BaaS es el proceso diario que demuestra que el dinero que un programa de banca como servicio dice deber a cada usuario final coincide con el efectivo depositado en las cuentas agrupadas de su banco patrocinador. El coste de hacerlo mal se ve con claridad en Synapse: en abril de 2024 este proveedor de middleware se declaró en quiebra, y la Consumer Financial Protection Bureau estimó después que sus registros dejaron un déficit de entre $60 millones y $90 millones en fondos adeudados a los consumidores.

La mayor parte del daño de Synapse se debió a la arquitectura del ledger y no al fraude. Los saldos estaban en un ledger de middleware que los bancos no podían ver en tiempo real, las cuentas agrupadas «for benefit of» estaban repartidas entre varios bancos y nadie ejecutaba cada día una conciliación por titular y por banco. Para corregirlo hace falta desarrollo de software a medida para ledgers de fintech y no otra hoja de cálculo, y es el núcleo de cualquier programa serio de desarrollo de software fintech que mueva fondos de clientes a través de un banco socio.

Esta guía está escrita para CTO, responsables de operaciones financieras y responsables de cumplimiento de fintechs de EE. UU., plataformas de finanzas integradas y bancos patrocinadores. Trata:

• cómo funcionan las cuentas FBO y quién debe mantener el sistema de registro;
• cómo es un ledger conciliable y cómo registrar la titularidad real;
• cómo ejecutar la conciliación diaria a tres bandas y gestionar las discrepancias;
• qué esperan los reguladores en 2026 y cuánto cuesta desarrollar una capa de conciliación.

¿Qué es la conciliación del ledger BaaS?

La conciliación del ledger BaaS es el control que cuadra cada día tres conjuntos de registros: el ledger de saldos de usuarios finales de la fintech, el extracto del banco patrocinador de cada cuenta agrupada y los ficheros de liquidación de los procesadores de tarjetas, ACH y otras redes de pago. El objetivo es una única afirmación que pueda defender: para cada banco y cada cuenta agrupada, la suma de los saldos de clientes más las partidas en tránsito explicadas es igual al saldo bancario, y la diferencia sin explicar es cero.

En un modelo de banca como servicio, una empresa no bancaria ofrece cuentas, tarjetas o pagos a sus usuarios mientras un banco patrocinador con licencia custodia los depósitos. La fintech suele mantener el subledger detallado, y el banco guarda el dinero en una o varias cuentas ómnibus (agrupadas) tituladas «for benefit of» los clientes de la fintech. La conciliación une ambos conjuntos de registros. Sin ella, el banco solo conoce el total y la fintech solo sabe lo que cree su propio software.

Tres propiedades distinguen una conciliación real de un ejercicio financiero mensual:

• Granularidad: los saldos se demuestran por titular real, no solo en conjunto.
• Frecuencia: la conciliación se ejecuta al menos una vez por día hábil, con comprobaciones por evento a lo largo del día.
• Independencia: el banco puede leer el ledger directamente y reproducir el resultado sin pedir una exportación a la fintech ni a un proveedor de middleware.

¿Qué reveló el colapso de Synapse sobre los ledgers FBO?

El colapso de Synapse demostró que una cuenta agrupada solo es tan segura como el ledger que la respalda. Synapse Financial Technologies se situaba entre las apps fintech de consumo y varios bancos socios. Guardaba en sus propios sistemas los registros de quién era titular de qué y movía fondos entre cuentas FBO de distintos bancos. Cuando se acogió al Chapter 11 el 22 de abril de 2024, los bancos no pudieron conciliar los saldos individuales de los clientes con el efectivo que custodiaban, y decenas de miles de usuarios finales perdieron el acceso a su dinero durante meses.

La acción de ejecución de la CFPB, presentada en agosto de 2025, cifró el déficit entre $60 millones y $90 millones. La Reserva Federal ya había dictado en junio de 2024 una orden de consentimiento contra Evolve Bank & Trust, uno de los bancos socios, que le obligaba a definir las responsabilidades contables del banco y de cada socio fintech y a obtener la aprobación del consejo antes de incorporar nuevos socios.

Para los ingenieros, cuatro lecciones importan más que las consecuencias legales:

1. Los saldos agregados ocultan problemas. Una cuenta agrupada puede parecer sana en total mientras a usuarios concretos les falta dinero.
2. Mover dinero entre bancos crea riesgo en el ledger. Cada barrido interbancario (una transferencia en bloque de fondos agrupados de un banco a otro) debe registrarse como un par de asientos con un estado trazable, o los saldos se desvían.
3. Un único ledger de middleware es un punto único de fallo. Si la única copia de los registros de titularidad está en manos de un proveedor, el banco no puede actuar cuando ese proveedor falla.
4. Una conciliación que llega tarde no es un control. Un descuadre detectado al cierre del trimestre lleva semanas acumulándose.

¿Cómo funcionan las cuentas agrupadas FBO y de quién es el dinero?

Una cuenta FBO es una cuenta de depósito custodiada que se abre en un banco a nombre de una plataforma «for the benefit of» (en beneficio de) sus clientes, y el dinero que contiene pertenece a esos clientes, no a la plataforma. El banco ve una cuenta y un saldo. El ledger de la plataforma divide ese saldo en miles o millones de subcuentas individuales, una por usuario final o por monedero.

Esta estructura tiene una consecuencia directa en el seguro de depósitos. La cobertura pass-through de la FDIC significa que el seguro se aplica a la parte de cada titular real, como si este tuviera la cuenta a su nombre. Solo puede extenderse a cada titular si los registros de la cuenta reflejan la relación de custodia y se pueden acreditar la identidad y los derechos de los titulares. Por tanto, el ledger hace algo más que dar soporte a las operaciones: es la prueba que decide si el dinero de un cliente está protegido en caso de quiebra del banco.

Un flujo de dinero BaaS típico pasa por cuatro partes:

Los registros pueden divergir en cada traspaso entre esas partes. Cuantas menos copias independientes de los datos de titularidad existan, y menos pueda ver de ellas el banco, mayor es el riesgo.

¿Quién debe mantener el sistema de registro: el banco, el middleware o la fintech?

El modelo más seguro en 2026 es un ledger de partida doble propiedad de la fintech (o del banco) que el banco patrocinador pueda leer directamente, con el middleware tratado como una capa de transporte y no como la única fuente de verdad. Cada opción tiene un perfil de riesgo distinto:

Sea cual sea el modelo que elija, recoja el reparto de responsabilidades en el contrato del programa: quién registra qué eventos, quién corrige qué discrepancias, quién puede congelar fondos y qué ocurre con los registros si la relación termina. La orden contra Evolve insistía en lo mismo.

¿Cómo es un ledger conciliable?

Un ledger conciliable es un sistema de partida doble de solo anexado (append-only) en el que cada movimiento de dinero es un conjunto equilibrado de asientos. Cada conjunto lleva una clave de idempotencia única (una referencia que impide que el mismo evento se contabilice dos veces), una fecha valor y un vínculo con el evento externo que lo originó. Si se cumplen esas cuatro propiedades, la conciliación se convierte en una consulta; si no, se convierte en una investigación forense. Los mismos principios se aplican a cualquier arquitectura de ledger de finanzas integradas, ya esté el dinero en depósitos, saldos de tarjetas o monederos.

Partida doble e inmutabilidad

En un ledger BaaS de partida doble, cada transacción carga una cuenta del ledger y abona otra por el mismo importe, de modo que el ledger en su conjunto siempre suma cero. Los asientos nunca se editan ni se eliminan. Un asiento erróneo se corrige con un asiento de anulación y uno nuevo correcto, lo que deja una pista de auditoría completa de lo que el sistema creía y cuándo.

Un plan de cuentas mínimo del ledger

Un ledger BaaS mínimo necesita seis tipos de cuenta, no solo una cuenta por usuario. Como mínimo, modele estas:

¿Por qué guardar tanto la fecha valor como la fecha de registro?

Cada asiento debe llevar dos marcas de tiempo: cuándo se produjo el movimiento en términos económicos (la fecha valor) y cuándo lo registró su sistema. Las devoluciones ACH con fecha retroactiva, las liquidaciones tardías de tarjetas y las correcciones llegan a posteriori. Con ambas fechas guardadas, puede reproducir el saldo «tal como se conocía el martes por la noche» y «tal como se corrigió el jueves», y eso es lo que piden los inspectores y los auditores.

¿Cómo evitan las claves de idempotencia y las referencias externas el dinero duplicado?

Cada asiento necesita una clave de idempotencia derivada del evento externo, como el número de rastreo ACH, el ID de transacción de la red de tarjetas o la referencia bancaria. Así, los reintentos y los webhooks duplicados no pueden crear dinero dos veces. Guardar la referencia externa en el asiento también da a la conciliación una clave de unión determinista en lugar de un cotejo aproximado por importe y fecha.

¿Cómo se registra la titularidad real de cada usuario final?

Registrar la titularidad real significa que, para cada cuenta agrupada, usted puede generar en cualquier momento una lista de cada titular, sus datos de identidad y el saldo exacto que le corresponde. La propuesta de la FDIC de 2024 sobre el registro de cuentas de custodia convertiría esto en una obligación formal para los bancos que tienen este tipo de cuentas, y los bancos patrocinadores ya lo piden en la diligencia debida.

Diseñe el registro de titularidad como una entidad de primer nivel, no como un campo enterrado en el perfil del usuario. Un registro práctico contiene:

Dos detalles de implementación son los más importantes:

1. Asigne cada titular a una cuenta bancaria concreta, nunca a «el programa» en general, para que una configuración con varios bancos pueda conciliarse por banco.
2. Exporte estos registros cada día en un formato estable y documentado y entregue una copia al banco, porque la propuesta contempla tanto el acceso directo como una copia de seguridad diaria.

Conciliación diaria o en tiempo real: ¿cuál necesita?

La mayoría de los programas BaaS necesitan ambas: comprobaciones por evento casi en tiempo real para detectar problemas en minutos, y una conciliación formal al cierre del día hábil que genere la prueba diaria para el banco. Las comprobaciones en tiempo real reducen el riesgo; la prueba diaria es el control que los inspectores van a verificar.

Si está en una fase temprana y los recursos son escasos, desarrolle primero la conciliación diaria, porque es el control que esperan el banco y los reguladores. Después, añada comprobaciones en tiempo real en los flujos de mayor riesgo: autorizaciones de tarjeta, pagos instantáneos y barridos interbancarios.

Cómo ejecutar paso a paso una conciliación diaria a tres bandas

Una conciliación diaria a tres bandas cuadra el ledger, el banco y las redes de pago de cada cuenta FBO y termina con una diferencia sin explicar igual a cero o con una discrepancia documentada. El proceso siguiente sirve tanto para programas con un solo banco como para programas con varios bancos.

1. Fije el corte. Elija la hora de fin de día del banco para cada cuenta y tome una instantánea del ledger «a fecha de» ese momento usando las fechas valor.
2. Cargue los datos del banco. Importe el extracto o la respuesta de la API de saldos de cada cuenta FBO, normalizados en un formato común y con las referencias conservadas.
3. Cargue los ficheros de las redes de pago. Importe los ficheros de ACH, transferencias, liquidación de tarjetas, contracargos y devoluciones de la misma ventana.
4. Cuadre las transacciones. Una los asientos del ledger con los registros del banco y de las redes primero por referencias externas, después por importe y fecha solo para el resto, y marque cada regla de cotejo utilizada.
5. Calcule la prueba de saldo. Para cada cuenta bancaria: el saldo bancario menos la suma de los saldos de los titulares menos las partidas en tránsito es igual a la diferencia sin explicar.
6. Verifique cada titular. Compruebe que ningún saldo de titular sea negativo sin un motivo aprobado y que los totales de titulares por banco coincidan con la cuenta de efectivo FBO del ledger.
7. Clasifique las discrepancias. Asigne cada partida sin cuadrar a una categoría y a un responsable, y regístrela en la cuenta de espera con un contador de antigüedad.
8. Firme y comparta. Genere un informe con los totales, las discrepancias y las aprobaciones, guárdelo de forma inmutable y entréguelo al banco patrocinador.

Ejemplo práctico: la prueba de saldo diaria de un banco

La prueba de saldo diaria del paso 5 toma el saldo bancario, resta los saldos de los titulares y las partidas en tránsito, y debe dejar una diferencia sin explicar de cero. Un ejemplo simplificado para un banco:

Las cifras son ilustrativas. Cada línea en tránsito debe estar respaldada por partidas concretas que se liquiden dentro de su ventana prevista. Si un saldo en tránsito no deja de crecer, trátelo como una discrepancia.

¿Cómo se clasifican y resuelven las discrepancias de conciliación?

Una discrepancia es cualquier diferencia que la conciliación no puede explicar con partidas cuadradas, y cada discrepancia necesita una categoría, un responsable, un plazo y una regla de escalado. Tratar las discrepancias como un único montón sin distinguir es la forma en que pequeñas diferencias temporales se convierten en déficits sin explicar.

Fije los umbrales antes de necesitarlos. Por ejemplo, un programa podría:

• cerrar de forma automática las discrepancias temporales por debajo de un importe pequeño que se resuelvan en dos días hábiles;
• exigir la revisión de un responsable para todo lo que sea más antiguo;
• pausar las transferencias salientes de una cuenta FBO si su diferencia sin explicar supera un límite acordado.

Incluya las cifras exactas en el contrato del programa con el banco para que no vivan solo en la cabeza de un ingeniero.

Cumplimiento de la banca como servicio en 2026: ¿qué esperan los reguladores?

A noviembre de 2026 no existe una norma federal definitiva única sobre la conciliación BaaS, pero la dirección es clara: los reguladores esperan que los bancos patrocinadores sepan cada día quién es el titular del dinero de las cuentas de custodia y que tengan acceso directo a los registros que lo demuestran. Tres documentos fijan esa expectativa.

La propuesta de la FDIC sobre cuentas de custodia («Synapse rule»)

La norma propuesta por la FDIC sobre el registro de cuentas de custodia (RIN 3064-AG07), a menudo llamada «Synapse rule», es la más concreta de las tres. El consejo de la FDIC la aprobó el 17 de septiembre de 2024 y se publicó el 2 de octubre de 2024. Obligaría a los bancos que tienen cuentas de custodia con funciones transaccionales a:

• mantener registros de cada titular real y de su saldo en un formato estándar;
• tener acceso directo, continuo y sin restricciones a los registros que mantienen terceros;
• recibir al menos una copia de seguridad diaria;
• conciliar al menos una vez al día;
• hacer validar los controles de forma independiente cada año.

El periodo de comentarios se cerró el 16 de enero de 2025. En la Unified Agenda de otoño de 2025 la norma figura como acción a largo plazo sin fecha de norma definitiva, así que trátela como el estándar previsto y no como derecho consolidado.

La declaración interinstitucional de julio de 2024 y las acciones de ejecución

El 25 de julio de 2024 la Reserva Federal, la FDIC y la OCC publicaron una declaración conjunta sobre los riesgos de los acuerdos de los bancos con terceros para ofrecer productos de depósito, junto con una solicitud de información sobre los acuerdos entre bancos y fintechs. Ambos documentos insisten en el registro, la conciliación y la responsabilidad del banco sobre sus socios.

Las acciones de ejecución apuntan en la misma dirección. La orden de consentimiento de la Reserva Federal de junio de 2024 contra Evolve Bank & Trust exigía un plan que definiera las responsabilidades contables entre el banco y cada socio fintech. Los bancos patrocinadores sujetos a órdenes suelen trasladar estos requisitos directamente a sus programas fintech.

Para una fintech, esto significa que su banco patrocinador le pedirá conciliación diaria, registros por titular y acceso directo durante la incorporación o la próxima inspección, se llegue o no a aprobar la norma de la FDIC. Desarrollar ahora esas capacidades es más barato que añadirlas a posteriori con un plazo encima.

Lista de comprobación de cumplimiento para la conciliación BaaS

Un programa de conciliación BaaS que cumpla lo que piden los bancos patrocinadores y los inspectores en 2026 necesita trece controles, desde un ledger de solo anexado hasta un plan de liquidación ordenada. Use esta lista para evaluar el suyo. Cada punto debe tener un responsable y pruebas que pueda mostrar.

• Ledger de partida doble de solo anexado, con asientos de anulación en lugar de ediciones.
• Claves de idempotencia y referencias externas en cada asiento.
• Marcas de tiempo de fecha valor y de registro en cada asiento.
• Registro de titularidad real por titular, asignado a un banco y a una cuenta FBO concretos.
• Acceso de lectura directo y continuo al ledger para el banco patrocinador.
• Exportación diaria de los registros de titularidad y de los saldos entregada al banco.
• Conciliación al cierre del día hábil de cada cuenta FBO, por banco, cada día hábil.
• Cotejo a tres bandas con los extractos bancarios y los ficheros de liquidación de las redes de pago.
• Taxonomía de discrepancias con responsables, plazos, umbrales y vías de escalado.
• Informe diario de antigüedad de la cuenta de espera compartido con el banco.
• Validación independiente anual de los controles de conciliación.
• Reparto por escrito de las responsabilidades contables en el contrato del programa.
• Un plan de liquidación ordenada que entregue registros completos al banco si el programa o un proveedor fallan.

Desarrollar, comprar o modelo híbrido: ¿cuánto cuesta una capa de conciliación?

La mayoría de los programas BaaS en crecimiento acaban en un modelo híbrido: un motor de ledger comprado o de código abierto para la mecánica básica de partida doble, más registros de titularidad, conectores con bancos y redes de pago, reglas de cotejo e informes desarrollados a medida. Comprarlo todo rara vez encaja en un programa con varios bancos y productos; desarrollarlo todo tiene sentido sobre todo cuando el ledger es el producto.

Cuando evalúe software de conciliación de cuentas FBO, compruebe si admite pruebas por titular, fechas valor y acceso directo del banco, además del cotejo de transacciones.

En cuanto al coste, el alcance influye en la cifra más que la tecnología. En YuSMP Group, un sistema interno acotado, como un panel de conciliación sobre un ledger existente, cuesta desde $2,900 (6–10 semanas), y una plataforma multirrol con conectores bancarios, registros de titularidad e informes cuesta desde $10,400 (14–22 semanas), según los precios publicados en nuestra página de desarrollo de software a medida.

Un neobanco completo o una plataforma de préstamos con KYC/AML e integración de banca como servicio es otra clase de proyecto: nuestra página de fintech indica $250,000–$500,000+. Para una visión más amplia de los presupuestos, consulte nuestro desglose del coste de desarrollo de un neobanco.

Antes de empezar, reúna cuatro elementos. Juntos definen el primer sprint:

• extractos bancarios de muestra y la documentación de la API de saldos de cada banco patrocinador;
• ficheros de liquidación y de devoluciones de cada red de pago;
• el esquema actual de su ledger;
• las cláusulas de conciliación y de registro de cada contrato de programa.

Errores habituales en la conciliación del ledger BaaS

Los errores más caros en la conciliación del ledger BaaS son decisiones de diseño tomadas al principio, cuando los volúmenes son pequeños y cada discrepancia todavía puede corregirse a mano. Estos son los que vemos con más frecuencia:

• Conciliar solo en conjunto. Un total que cuadra por banco oculta titulares a los que les falta dinero y titulares con abonos de más.
• Saldos mutables. Actualizar in situ una columna de saldo hace imposible demostrar cómo se llegó a la cifra.
• Tratar el ledger del middleware como el registro del banco. Si el banco no puede leer los datos de titularidad de forma independiente, el programa hereda el riesgo de fallo del proveedor.
• Ignorar la antigüedad de las partidas en tránsito. Las partidas en tránsito que nunca se liquidan se convierten en silencio en un déficit.
• Mezclar programas o bancos en un mismo fondo. Cada titular debe asignarse a una cuenta bancaria concreta o las pruebas por banco se vuelven imposibles.
• Cotejo aproximado por defecto. Cotejar primero por importe y fecha genera falsos positivos; el cotejo debe basarse en las referencias.
• Sin plan de liquidación ordenada. El día en que sale un socio es el peor día para descubrir que los registros no pueden entregarse limpiamente.

Para una visión más amplia de cómo los bancos y las fintechs construyen sus plataformas, lea nuestras guías sobre desarrollo de software bancario, arquitectura y cumplimiento del software de pagos e integración de API de open banking.

Preguntas frecuentes

Fuentes: documentos de la FDIC, la CFPB, la Reserva Federal y la OCC

• Federal Register: FDIC proposed rule, Recordkeeping for Custodial Accounts (2 de octubre de 2024) (en inglés)
• FDIC: comment period extended for the custodial deposit account proposal (en inglés)
• Unified Agenda, Fall 2025: RIN 3064-AG07 status (en inglés)
• CFPB: enforcement action against Synapse Financial Technologies (en inglés)
• Federal Reserve: consent order with Evolve Bancorp and Evolve Bank & Trust (junio de 2024) (en inglés)
• OCC Bulletin 2024-21: joint statement and request for information on bank-fintech arrangements (julio de 2024) (en inglés)

Publicado el 13 de noviembre de 2026. Esta guía es técnica y no constituye asesoramiento jurídico; confirme las obligaciones regulatorias con su banco patrocinador y sus asesores legales. Los precios de YuSMP Group son precios de partida para desarrollos de alcance cerrado publicados en nuestras páginas de servicios; los presupuestos finales dependen de los bancos, las redes de pago, los productos, la calidad de los datos y los requisitos de cumplimiento.