Multi-Tenancy en Banking SaaS: Patrones de Diseño y Errores Comunes
Guía práctica sobre arquitectura multi-tenancy para plataformas bancarias SaaS: modelos silo, pool y bridge, aislamiento de bases de datos, seguridad de datos, problema del vecino ruidoso, cumplimiento de Banco de España, CNMV, DORA y RGPD, y errores frecuentes a evitar.
Qué significa la multi-tenancy en una plataforma bancaria SaaS
Una arquitectura multi-tenant es aquella en la que una única instancia de una aplicación sirve a múltiples clientes independientes - tenants - desde una infraestructura compartida. Cada tenant dispone de su propio espacio lógico: sus propias cuentas, su propia configuración, sus propios datos. Nada de eso se mezcla con el espacio del siguiente tenant. El operador de la plataforma mantiene una sola base de código, no una copia por cliente.
Para un producto SaaS de consumo, la multi-tenancy es una elección de ingeniería estándar. Para una plataforma bancaria SaaS, conlleva un peso diferente. Los tenants son entidades reguladas. Sus datos incluyen registros de transacciones, datos personales de clientes, hallazgos AML y el estado del libro contable. Una fuga de datos entre tenants no es un ticket de soporte - es un incidente regulatorio con posibles sanciones, obligaciones de notificación y daños reputacionales que pueden cerrar el negocio de un cliente.
Por qué bancos y entidades de dinero electrónico eligen SaaS
Lanzamiento más rápido, menor inversión inicial, sin necesidad de equipo de infraestructura propio y acceso a una capa de cumplimiento normativo mantenida, sin reconstruir los mismos fundamentos cada vez.
El requisito de aislamiento
El Banco de España, la CNMV y las directrices de la EBA esperan que los datos de los tenants estén separados de forma lógica o física. La forma en que lo consiga condiciona todas las demás decisiones arquitectónicas.
El espectro de concesiones
Más aislamiento cuesta más en operación. Más compartición es más económica pero limita a qué clientes puede servir. La elección correcta está en algún punto intermedio, según la composición del cliente.
En España, el Banco de España aplica la Circular 3/2022 y la normativa de externalización, que exige a las entidades supervisadas que los servicios externalizados - incluido el SaaS en la nube - estén contractualmente controlados, sean auditables y cuenten con planes de continuidad documentados. DORA, en vigor desde enero de 2025, añade requisitos de resiliencia operativa digital y gestión de riesgos de terceros ICT que refuerzan estas exigencias en todo el espacio europeo, incluyendo a los proveedores con presencia en España y Latinoamérica.
Hablemos de tu proyecto y veamos cómo podemos lanzar tu Producto bancario digital Juntos
Solicita una demoModelos de tenancy: silo, pool y bridge
Existen tres modelos fundamentales. La mayoría de las plataformas bancarias en producción acaban en una variante del tercero, pero entender los tres hace que las concesiones sean concretas.
| Modelo | Qué significa | Nivel de aislamiento | Coste operativo | Mejor uso |
|---|---|---|---|---|
| Silo | Cada tenant dispone de su propia base de datos dedicada, clúster de cómputo o pila completa. | Físico - máximo | Alto - escala linealmente con el número de tenants | Titulares de licencia bancaria completa, grandes fintechs reguladas con requisitos de auditoría |
| Pool | Todos los tenants comparten la misma base de datos y esquema. Una columna Tenant ID en cada tabla filtra las filas. | Lógico - el más bajo | Bajo - el más eficiente | Productos SaaS de bajo riesgo; menos adecuado para banca sin controles adicionales |
| Bridge | Capa de aplicación compartida, pero esquemas separados o clústeres de BD dedicados por nivel de tenant. Los tenants premium obtienen más aislamiento. | Mixto - configurable por nivel | Medio - overhead compartido, coste de recursos escalonado | La mayoría de plataformas bancarias con base de clientes mixta |
BD-por-tenant vs. esquema compartido es una pregunta relacionada pero separada. En una configuración BD-por-tenant, los datos de cada tenant viven en una base de datos físicamente separada. Las consultas entre tenants son estructuralmente imposibles. Las migraciones requieren un despliegue escalonado a través de N bases de datos. En un esquema compartido, todas las tablas están en una base de datos, las filas llevan un Tenant ID y una cláusula WHERE ausente es la diferencia entre una consulta correcta y una brecha de datos.
Ventajas de BD-por-tenant
- El aislamiento físico satisface la mayoría de revisiones del Banco de España y auditorías sin controles adicionales
- Los datos del tenant pueden residir en una región cloud específica para cumplir el RGPD y requisitos de residencia de datos
- Una vulneración en la BD de un tenant no afecta a otros
- Copia de seguridad y restauración independiente por tenant
Ventajas del esquema compartido
- Una única migración se despliega en todas partes simultáneamente
- El coste de infraestructura por tenant cae significativamente con la escala
- Las analíticas entre tenants (agregadas, anonimizadas) son más sencillas de construir
- La gestión del connection pool es mucho más fácil de operar
La mayoría de las plataformas bancarias SaaS maduras utilizan hoy un enfoque bridge: una capa de aplicación compartida, esquemas o bases de datos separados por tenant (o por nivel de tenant) y un registro de metadatos que mapea cada solicitud entrante al almacén de datos correcto. La capa de aplicación nunca consulta "todos los tenants" - resuelve el contexto del tenant a partir del token de solicitud y enruta a un único almacén de datos.
Aislamiento de datos y seguridad para tenants regulados
Para una plataforma bancaria, el aislamiento no es solo una cuestión de rendimiento - es un requisito de cumplimiento. El Banco de España, la CNMV, las directrices de la EBA sobre externalización, DORA y el RGPD esperan que los datos de una entidad regulada no puedan ser leídos, modificados ni eliminados por otra. La forma de demostrarlo depende del modelo de aislamiento elegido.
Row-Level Security (RLS)
Políticas a nivel de base de datos que aplican filtrado por tenant en cada consulta, independientemente de lo que envíe la aplicación. Si un fallo de la aplicación envía una consulta sin filtro de Tenant ID, la base de datos devuelve cero filas en lugar de los datos de otro tenant. RLS es la red de seguridad bajo un esquema compartido.
Bring Your Own Key (BYOK)
Cifrado en reposo con claves por tenant. Incluso en infraestructura compartida, los datos cifrados de un tenant no pueden ser leídos por otro. BYOK lo exigen cada vez más los tenants regulados y las jurisdicciones con normas estrictas de soberanía de datos, incluyendo el entorno europeo bajo el RGPD.
Contexto de tenant en IAM
Los tokens de autenticación (JWT, OAuth) incorporan el Tenant ID como claim. El API gateway valida ese claim en cada solicitud y lo propaga por toda la cadena de llamadas. Una solicitud que llega sin un claim de tenant válido se rechaza antes de tocar ninguna capa de datos.
Residencia de datos bajo RGPD
El RGPD exige que los datos personales europeos permanezcan en el EEE. Una plataforma bancaria SaaS que sirva a clientes en España, Alemania y Francia debe demostrar que los datos de cada tenant se almacenan y procesan en la jurisdicción correcta. BD-por-tenant en regiones cloud geográficamente fijadas es la solución más limpia.
DORA, obligatorio en toda la UE desde enero de 2025, añade una dimensión de riesgo de terceros ICT. Si su plataforma bancaria SaaS está clasificada como proveedor de ICT crítico, los supervisores de sus tenants - incluyendo el Banco de España y la CNMV - pueden realizar visitas de supervisión directa. La documentación de la arquitectura, los controles de aislamiento y los procedimientos de respuesta ante incidentes se convierten en evidencia durante ese proceso.
Desde una perspectiva latinoamericana, vale la pena señalar que plataformas SaaS que sirvan a entidades bancarias tanto en España como en LATAM deben gestionar requisitos de residencia de datos que pueden diferir por país: algunos mercados latinoamericanos tienen exigencias de almacenamiento local que requieren configuraciones de región cloud específicas por tenant.
El vecino ruidoso, escalabilidad y concesiones de coste
El problema del vecino ruidoso surge cuando la carga de trabajo de un tenant consume una parte desproporcionada de los recursos compartidos y degrada el rendimiento de todos los demás. En una plataforma bancaria, esto puede significar retrasos en el procesamiento de transacciones, consultas de saldo más lentas o timeouts de API durante el ciclo de conciliación de fin de mes de un tenant grande.
| Técnica de mitigación | Cómo funciona | Concesión |
|---|---|---|
| Cuotas de recursos | Límites de CPU, memoria e IOPS por contenedor de tenant o pool de conexiones a BD | Limita el rendimiento pico para tenants grandes; puede necesitar ajuste por nivel |
| Rate limiting | Throttling de solicitudes a nivel de API por tenant, aplicado en el gateway | Protege los servicios compartidos pero puede frustrar a tenants de alto volumen sin capacidad dedicada |
| Enrutamiento por nivel de tenant | Los tenants premium se enrutan a clústeres de alto rendimiento dedicados; los estándar comparten pools optimizados en coste | Añade complejidad de enrutamiento; el límite de nivel debe estar bien definido en los contratos |
| Descarga a cola asíncrona | Las operaciones batch (conciliación, generación de extractos) van a una cola separada, no al path de la API en tiempo real | Añade latencia para trabajo batch; las respuestas en tiempo real quedan protegidas |
| Aislamiento BD-por-tenant | Las consultas de cada tenant se ejecutan contra su propia BD; sin I/O compartida en absoluto | Elimina el vecino ruidoso en la capa de BD pero aumenta el coste de infraestructura |
La lección práctica del funcionamiento de plataformas bancarias a escala: diseñe para la carga de trabajo del tenant más pesado esperado desde el primer día, no para el tenant medio. Un único cliente grande haciendo un batch de fin de mes puede exponer cuellos de botella en la base de datos que eran invisibles al 10% de carga. La planificación de capacidad basada en la carga del tenant P99, no en el P50, evita la mayoría de los incidentes en producción.
Errores comunes y anti-patterns
La mayoría de los fallos de multi-tenancy en banking SaaS caen en un pequeño número de patrones repetidos. Reconocerlos temprano es más barato que descubrirlos durante un incidente en vivo o una auditoría regulatoria.
Hay un meta-patrón detrás de todos estos errores: tratar el aislamiento como algo secundario. Las decisiones de diseño de multi-tenancy tomadas en el primer sprint de una plataforma son muy difíciles de revertir una vez que hay clientes reales activos. El coste de hacer bien el aislamiento desde el principio es unas pocas semanas de trabajo de arquitectura adicional. El coste de incorporarlo después de un incidente de datos se mide en meses de remediación y posibles acciones regulatorias.
Cómo gestiona Crassula la multi-tenancy
Crassula sirve a más de 150 empresas reguladas - entidades de dinero electrónico, instituciones de pago y titulares de licencias bancarias - en una única plataforma. La arquitectura multi-tenancy refleja años de trabajo con clientes reales en auditorías regulatorias reales en toda la UE.
Separación de datos por tenant
Los datos financieros de cada cliente de Crassula están separados lógicamente dentro de la plataforma, con el contexto de tenant aplicado en cada capa, desde el API gateway hasta el almacén de datos. El acceso a datos entre tenants está estructuralmente impedido, no solo controlado por política.
Cifrado y gestión de claves
Los datos en reposo y en tránsito están cifrados. Para tenants con requisitos más estrictos de gestión de claves, incluyendo clientes en jurisdicciones con expectativas BYOK, están disponibles configuraciones de cifrado por cliente.
RGPD y residencia de datos
Crassula procesa datos en cumplimiento del RGPD. Para clientes con requisitos específicos de residencia de datos, la plataforma soporta configuraciones alineadas con las expectativas regulatorias de la UE y la guía supervisora nacional, incluidas las del Banco de España.
Trail de auditoría
Cada acción queda registrada con contexto de tenant, identidad del usuario, timestamp e IP. El trail de auditoría es inmutable y cubre el ciclo de vida completo de cada registro financiero - necesario para AML, reporting regulatorio y revisiones de compliance del lado del cliente.
Preparación para DORA
Como proveedor de servicios ICT para entidades reguladas, Crassula mantiene documentación y controles alineados con los requisitos de riesgo de terceros ICT de DORA, apoyando las propias obligaciones DORA de los clientes ante Banco de España y CNMV.
Escalable por diseño
La arquitectura de la plataforma gestiona un amplio rango de tamaños de tenant, desde fintechs en fase inicial hasta titulares de licencias establecidos. La asignación de recursos escala con las necesidades del cliente sin degradar el rendimiento de otros tenants.
Si está evaluando plataformas bancarias SaaS y quiere entender cómo se implementan el aislamiento, el cifrado y los controles regulatorios - o si está diseñando su propia arquitectura multi-tenant y quiere comparar enfoques - hable con nuestro equipo. Estaremos encantados de analizar los detalles.
Preguntas frecuentes
La multi-tenancy significa que una única plataforma bancaria sirve a múltiples clientes independientes (tenants) desde una infraestructura compartida - cada uno con sus propias cuentas, configuración y datos, sin que ninguno se mezcle con otro. Para el operador de la plataforma significa mantener una sola base de código en lugar de una copia por cliente. Para los clientes significa incorporación más rápida, menor coste y una capa de cumplimiento normativo y seguridad mantenida continuamente. El requisito crítico en banca es que el aislamiento de datos de los tenants se aplique en cada capa: API gateway, lógica de aplicación y almacén de datos.
El aislamiento físico (modelo silo, BD-por-tenant) es el más defendible en una auditoría del Banco de España o de la CNMV, porque el acceso a datos entre tenants es estructuralmente imposible. Sin embargo, también es el más caro de operar. La mayoría de las plataformas bancarias SaaS reguladas utilizan un enfoque bridge: infraestructura de aplicación compartida con esquemas o bases de datos separados por tenant (o por nivel de tenant), más Row-Level Security como backstop en la capa de base de datos en cualquier tabla compartida. El modelo correcto depende de las obligaciones regulatorias de su base de clientes.
Los principales mecanismos son: (1) bases de datos separadas por tenant para que las consultas físicamente no puedan cruzar fronteras; (2) políticas de Row-Level Security (RLS) en la capa de base de datos que filtran por Tenant ID en cada consulta; (3) Tenant ID embebido en tokens de autenticación (claims JWT), validado en el API gateway y propagado a través de cada llamada de servicio; (4) claves de cifrado por tenant gestionadas mediante KMS o HSM; (5) segmentación de red en la capa de infraestructura. Una plataforma bancaria madura combina los cinco mecanismos.
Los cinco más comunes: (1) lógica de tenant dispersa en el código de la aplicación en lugar de resolverse desde un registro central - añadir un tenant requiere cambios de código; (2) cláusulas WHERE ausentes en consultas de esquema compartido que devuelven datos de múltiples tenants; (3) planificación de capacidad basada en el tenant medio cuando uno o dos tenants grandes dominan la carga real; (4) claves de cifrado compartidas entre todos los tenants - una vulneración afecta a todos; (5) logs de auditoría sin contexto de tenant, lo que hace imposible la revisión regulatoria. Todos estos patrones son mucho más baratos de abordar en el diseño que tras un incidente en vivo.
Sí, cuando se implementa correctamente. La Circular 3/2022 del Banco de España, las directrices de la EBA sobre externalización, DORA (obligatorio desde enero de 2025) y el RGPD no prohíben el SaaS multi-tenant. Sí exigen que las entidades reguladas puedan demostrar aislamiento de datos, integridad del trail de auditoría, controles de acceso y resiliencia operativa, y que los contratos de externalización otorguen derechos claros de auditoría al Banco de España y a la entidad. Una plataforma bancaria multi-tenant bien diseñada cumple esos requisitos y puede aportar la documentación de evidencia que los supervisores esperan.
Otras guías
Crea un banco digital en cuestión de días
Solicita una demo