Diseño de Bases de Datos para Banca en 2026: Esquemas y Fragmentación
Guía práctica sobre diseño de bases de datos para banca central: esquemas de libro mayor, contabilidad de doble entrada, consistencia ACID, event sourcing y estrategias de sharding para el procesamiento de transacciones de alto volumen.
Principios fundamentales del diseño de bases de datos bancarias
Todo producto fintech es tan fiable como su base de datos. El pago con tarjeta, la transferencia SEPA, el devengo de intereses nocturno - todos escriben y leen desde un almacén central de registro. Equivocarse en ese almacén no es un problema de rendimiento que se optimiza después; es un problema de corrección que se manifiesta como diferencias de conciliación, hallazgos regulatorios o dinero de clientes que no puede localizarse.
El diseño de bases de datos para banca central se sustenta en principios que han sobrevivido a cada generación tecnológica: desde los archivos VSAM de mainframe hasta las bases de datos relacionales y los sistemas distribuidos cloud-nativos de hoy. Los nombres evolucionan, pero los requisitos de fondo no.
Inmutabilidad
Las transacciones contabilizadas nunca se actualizan ni eliminan. Las correcciones llegan como nuevos asientos de reversión. El libro mayor solo crece hacia adelante.
Contabilidad de doble entrada
Cada movimiento de dinero debita una cuenta y acredita otra por el mismo importe. La suma de todos los asientos es siempre cero.
Event sourcing
El registro autoritativo es el log ordenado de eventos, no un campo de saldo mutable. Los saldos se derivan reproduciendo ese log.
En la práctica, estos principios significan: usar DECIMAL o NUMERIC en todas las columnas monetarias (nunca FLOAT), aplicar restricciones de clave foránea a nivel de base de datos y no solo en la capa de aplicación, y tratar la tabla de transacciones como append-only desde el primer día. Las decisiones tomadas en el diseño del esquema son caras de revertir una vez que existen datos de producción.
Hablemos de tu proyecto y veamos cómo podemos lanzar tu Producto bancario digital Juntos
Solicita una demoDiseño de esquemas para cuentas, asientos y productos
Un esquema bancario mínimo pero completo necesita tres entidades de dominio principales con separación clara entre ellas. Los nombres exactos de columnas varían según el proveedor o equipo, pero la estructura conceptual refleja cómo se organizan los sistemas de producción en fintechs en 2026.
| Entidad | Columnas clave | Notas de diseño |
|---|---|---|
| Cliente | customer_id, status, nivel KYC, created_at | PII almacenado cifrado (AES-256). Una tabla de eventos KYC separada almacena resultados de verificación AML con log de auditoría inmutable. |
| Cuenta | account_id, customer_id, product_id, currency, status, current_balance, available_balance | Las columnas de saldo son agregados derivados actualizados transaccionalmente; almacenados para velocidad de lectura. product_id enlaza al catálogo de productos, sin lógica hardcodeada. |
| Asiento / Entrada del libro mayor | posting_id, account_id, transaction_id, amount (DECIMAL), direction (DB/CR), value_date, booking_date, status | Append-only. transaction_id agrupa las dos líneas de un par de doble entrada. Los saldos se concilian sumando los asientos. |
| Transacción | transaction_id, reference, channel, initiated_at, settled_at, narrative | Registro padre que enlaza uno o más pares de asientos. Almacena referencias externas (SWIFT UETR, ID extremo a extremo SEPA). |
| Producto | product_id, type, interest_rate_config, fee_config, currency_rules | Definiciones de producto como datos - una cuenta corriente, cuenta de ahorro y préstamo difieren por configuración, no por código. Permite nuevos productos sin cambios de esquema. |
Un patrón que muchos núcleos cloud-nativos adoptan es separar el Libro Mayor General (General Ledger) de la capa de cuentas orientada al cliente. El libro mayor aplica la doble entrada a nivel de sistema; la capa de cuentas agrega y presenta saldos a clientes y APIs. Los informes se ejecutan contra una réplica de lectura separada o un data warehouse alimentado por Change Data Capture (CDC), evitando que las consultas analíticas compitan con las escrituras transaccionales en tiempo real.
Consistencia, ACID y el libro mayor
La banca es uno de los pocos dominios donde la garantía ACID completa - Atomicidad, Consistencia, Aislamiento, Durabilidad - no es negociable. Un débito de pago que tiene éxito sin su crédito correspondiente no es una degradación del rendimiento; es dinero desaparecido.
| Propiedad | Qué significa para banca | Aplicación práctica |
|---|---|---|
| Atomicidad | El débito y crédito de una transferencia o se confirman ambos o ambos se revierten. No hay estados parciales. | Transacción de base de datos única que envuelve ambas filas de asiento. Patrón saga para libros mayores distribuidos. |
| Consistencia | La suma de todos los DB menos la suma de todos los CR debe ser cero después de cada transacción. | Restricciones CHECK en base de datos más afirmación a nivel de aplicación en el momento del asiento. |
| Aislamiento | Una comprobación de saldo durante una transferencia concurrente debe ver el estado anterior o posterior a la transferencia, nunca una vista intermedia. | Nivel de aislamiento Serializable o REPEATABLE READ; bloqueo a nivel de fila para actualizaciones de saldo. |
| Durabilidad | Una vez confirmado un pago, debe sobrevivir a un fallo del servidor o un corte de electricidad. | WAL (write-ahead log) en PostgreSQL/Oracle; replicación síncrona a al menos un servidor en espera. |
Event sourcing complementa ACID al tratar el log de asientos como el registro canónico. En lugar de almacenar un campo de saldo mutable como fuente de verdad, el sistema almacena cada evento (débito, crédito, comisión, devengo de interés) y deriva el saldo actual sumándolos. Esto crea un rastro de auditoría natural y simplifica el cumplimiento regulatorio bajo la supervisión del Banco de España y la CNMV: dado que cada operación contable se registra de forma inmutable, la base de datos cumple los requisitos de trazabilidad sin infraestructura adicional.
PostgreSQL es el motor de código abierto más común para este patrón en 2026: admite aislamiento serializable, bloqueo a nivel de fila, replicación lógica para CDC, particionamiento por rango o hash, y el tipo NUMERIC con precisión arbitraria. Las variantes gestionadas en la nube (AWS Aurora, Google AlloyDB, Azure Database for PostgreSQL) añaden failover gestionado y autoescalado de almacenamiento.
Estrategias de sharding para procesamiento de transacciones de alto volumen
Un único nodo PostgreSQL puede manejar aproximadamente 10.000-30.000 transacciones por segundo en buenas condiciones. Muchas plataformas fintech alcanzan ese límite en pocos años desde el lanzamiento. Una vez que el escalado vertical (agregar RAM y CPU a un servidor) alcanza su límite de coste y físico, el siguiente paso es el escalado horizontal mediante sharding: distribuir filas entre múltiples nodos de base de datos autónomos para que cada nodo almacene solo una fracción de los datos y el tráfico.
Un shard map (también llamada tabla de enrutamiento o directorio) rastrea qué datos residen en qué nodo. Cada consulta pasa por una capa de enrutamiento que consulta el shard map y dirige la solicitud al nodo correcto.
| Estrategia | Funcionamiento | Idoneidad bancaria | Riesgos |
|---|---|---|---|
| Basado en hash | Función hash sobre la clave de shard (ej., account_id) enruta a un shard fijo. El hashing consistente minimiza el movimiento de datos al añadir nodos. | Excelente para distribuir escrituras entre cuentas de forma uniforme. | Las consultas de rango sobre muchas cuentas requieren fan-out a todos los shards. |
| Basado en rango | Rangos secuenciales de la clave (ej., IDs de cuenta 0-999999 en shard 1, 1000000-1999999 en shard 2). | Bueno para datos de series temporales e informes por rango de fechas. | Las nuevas cuentas o transacciones recientes se concentran en el último shard - el problema clásico de hot-spot. |
| Geo-sharding | Datos enrutados por geografía del cliente. Clientes en España en shards europeos; clientes en LATAM en shards regionales. | Reduce latencia; admite requisitos de residencia de datos según el Reglamento (UE) 2016/679 (RGPD) y regulaciones locales de LATAM. | Las transferencias transfronterizas requieren coordinación entre shards. |
| Basado en directorio | Tabla de búsqueda asigna cada clave a su shard explícitamente. Máxima flexibilidad en la ubicación. | Útil para cuentas VIP o empresariales que necesitan shards dedicados. | El directorio en sí se convierte en un punto único crítico de fallo si no se replica. |
Escalado de lecturas y escrituras, claves de partición y evitar hot-spots
Elegir una clave de shard es la decisión más trascendente en una arquitectura bancaria fragmentada. Una mala elección de clave crea hot-spots - shards que reciben una fracción desproporcionada del tráfico mientras otros shards están inactivos. El error clásico es fragmentar por un campo de baja cardinalidad (moneda, estado de cuenta, país) en lugar de un identificador de alta cardinalidad (ID de cuenta, ID de cliente, ID de transacción).
Directrices prácticas para la selección de clave de shard en banca:
- Usar account_id o customer_id para datos del libro mayor - todos los asientos de una cuenta permanecen en el mismo shard, haciendo las consultas de cuenta única rápidas y sin joins entre shards.
- Evitar IDs secuenciales de una sola secuencia como clave de shard en modo hash al crear cuentas a alto volumen. Usar UUIDs v4 o IDs snowflake en su lugar.
- Pre-dividir los shards si se conoce la carga inicial - mejor empezar con más shards de los necesarios que tener que re-fragmentar después. Re-fragmentar un libro mayor en producción sin tiempo de inactividad es una de las tareas operativas más complejas en ingeniería fintech.
- Mantener integridad referencial a nivel de aplicación - las claves foráneas tradicionales no cruzan límites de shard. La aplicación o un coordinador de sagas debe aplicar consistencia entre asientos en diferentes shards para transferencias entre cuentas.
El escalado de lecturas se gestiona por separado del sharding de escrituras. Las réplicas de lectura en cada shard sirven informes, consultas de saldo y generación de extractos sin competir con el tráfico de escritura. El patrón CQRS (Command Query Responsibility Segregation) es común: las escrituras van al clúster OLTP fragmentado; las lecturas para informes y análisis van a un modelo de lectura separado o a un data warehouse (BigQuery, Redshift, Snowflake) alimentado via pipelines CDC.
Para consultas entre shards (ej., "mostrar todas las transacciones superiores a 10.000 EUR en todas las cuentas para revisión AML"), las opciones son: dispersar la consulta a todos los shards y combinar resultados en la capa de aplicación, mantener un índice materializado entre shards actualizado via event streaming, o enrutar tales consultas al data warehouse. La mayoría de sistemas de producción usan los tres enfoques según el tipo de consulta y la tolerancia de latencia.
Backup, auditoría y retención regulatoria de datos
Los reguladores financieros tanto en España como en Latinoamérica exigen que los registros de transacciones se conserven durante períodos mínimos definidos. En España, bajo la supervisión del Banco de España y siguiendo la Directiva PSD2 y la normativa AML europea, los registros de transacciones de pago deben conservarse típicamente cinco años, y los relacionados con AML hasta diez años. En mercados latinoamericanos como México, Colombia o Brasil, los requisitos equivalentes varían entre cinco y siete años dependiendo del supervisor local.
| Requisito | Enfoque de implementación |
|---|---|
| Pista de auditoría inmutable | Tablas de libro mayor append-only. Disparadores de base de datos o lógica de aplicación impiden UPDATE/DELETE en filas contabilizadas. Los eventos de auditoría se escriben en un log append-only separado (puede ser un esquema separado o un sumidero de streaming como Kafka). |
| Retención regulatoria (5-10 años) | Particionar tablas de transacciones por mes o trimestre. Las particiones más antiguas se mueven a almacenamiento en frío más económico (object store, nivel de archivo) mientras siguen siendo consultables mediante vistas particionadas o motores de consulta federada. |
| Backup y recuperación | Recuperación point-in-time (PITR) mediante archivado WAL. Mínimo: backup completo diario más WAL continuo. Pruebas de restauración trimestrales. Objetivos de RTO y RPO documentados en el plan de continuidad de negocio. |
| Enmascaramiento de datos y RGPD | Cifrar datos personales a nivel de aplicación (AES-256) antes de escribir en BD. Enmascarar datos en entornos no productivos. Cifrado a nivel de columna para campos especialmente sensibles (IBAN, números de tarjeta). Implementar derecho al olvido mediante eliminación lógica (seudonimización). |
| Control de acceso | Row-Level Security (PostgreSQL RLS) asegura que los roles de aplicación solo accedan a datos de su propio cliente. Roles de solo lectura separados para informes. Acceso DBA registrado y limitado en tiempo. |
La regla de inmutabilidad también simplifica las auditorías de cumplimiento. Cuando el Banco de España, la CNMV o los auditores internos preguntan "muestre todas las transacciones de la cuenta X entre la fecha A y B", la respuesta es una consulta directa contra la tabla de asientos - sin reconstrucción desde logs, sin preocupación por filas editadas. Esa sencillez justifica la disciplina de diseño de tratar el libro mayor como append-only desde el inicio.
Cómo encaja Crassula
La plataforma bancaria white-label de Crassula está construida sobre estos principios. El libro mayor es append-only, de doble entrada y cumple con ACID desde su base. Los saldos de cuentas se mantienen transaccionalmente y se concilian con el log de asientos. Los rastros de auditoría se escriben en un almacén de eventos inmutable y están disponibles para inspección regulatoria bajo demanda.
Para clientes que lanzan nuevos productos bancarios o de pago en España o LATAM, Crassula elimina la necesidad de diseñar y construir esta infraestructura desde cero. La capa de datos, el motor de conciliación, las políticas de particionamiento y retención - todo está incluido en la plataforma. Los equipos se centran en la experiencia del cliente y la configuración del producto.
Si está evaluando la arquitectura de base de datos para una construcción de banca central, o valorando si una plataforma white-label es adecuada para sus volúmenes de transacciones y requisitos de cumplimiento, el equipo de Crassula está disponible para profundizar en los detalles técnicos.
Preguntas frecuentes
Comience con el libro mayor como fuente única de verdad. Defina sus entidades principales - Cliente, Cuenta, Asiento (entrada del libro mayor), Transacción y Producto - con separación clara entre ellas. Use DECIMAL o NUMERIC para todas las columnas monetarias. Haga la tabla de asientos append-only desde el primer día: las correcciones llegan como nuevos asientos de reversión, nunca como actualizaciones de filas existentes. Aplique transacciones ACID a nivel de base de datos para cada movimiento de fondos. Separe su ruta de escritura (OLTP) de la ruta de informes y análisis. Construya el particionamiento de retención desde el inicio para que los datos más antiguos puedan archivarse sin cambios de esquema.
La contabilidad de doble entrada significa que cada movimiento de dinero produce dos entradas en el libro mayor - un débito en una cuenta y un crédito en otra por el mismo importe. La suma de todas las entradas es siempre cero, lo que hace imposible que el dinero aparezca o desaparezca silenciosamente.
Event sourcing amplía esto almacenando el log ordenado de eventos (cada asiento) como el registro autoritativo, con saldos derivados sumando ese log en lugar de almacenados como campos mutables. La combinación proporciona una pista de auditoría natural, consultas en el tiempo ("¿cuál era el saldo en el momento T?") y una base para el reporting regulatorio ante el Banco de España o la CNMV - sin infraestructura de auditoría adicional.
El sharding es particionamiento horizontal: distribuir filas entre múltiples nodos de base de datos independientes para que cada nodo almacene solo una fracción de los datos. Una capa de enrutamiento (shard map) dirige cada consulta al nodo correcto.
En banca necesita sharding cuando un único nodo de base de datos ya no puede gestionar el pico de escrituras, o cuando el volumen de datos hace que el almacenamiento en un solo nodo sea impracticable. Un nodo PostgreSQL bien ajustado maneja aproximadamente 10.000-30.000 transacciones por segundo. A volúmenes más altos, o cuando la residencia de datos distribuida geográficamente es necesaria para cumplir con el RGPD u otras regulaciones locales, el sharding se convierte en la solución estándar.
La clave de shard debe tener alta cardinalidad - suficientes valores distintos para distribuir los datos de forma uniforme entre todos los shards. Para un libro mayor bancario, account_id o customer_id son las opciones naturales: todos los asientos de una cuenta caen en el mismo shard, haciendo las consultas de cuenta única rápidas y sin joins entre shards.
Evite fragmentar por campos de baja cardinalidad (moneda, país, estado) - crean hot-spots. Evite enteros auto-incrementales secuenciales como clave de shard; use UUIDs v4 o IDs snowflake en su lugar. Planifique su número de shards generosamente al lanzamiento - re-fragmentar un libro mayor en producción sin tiempo de inactividad es una de las operaciones más complejas en ingeniería fintech.
Dentro de un único shard, las transacciones ACID estándar mantienen la consistencia. El problema difícil son las transacciones entre shards - por ejemplo, una transferencia entre dos cuentas que residen en shards diferentes.
Los enfoques estándar son: el patrón saga (una secuencia de transacciones locales coordinadas por un orquestador de sagas o coreografía via eventos, con transacciones compensatorias para rollback), y two-phase commit (2PC) entre nodos (raramente usado en sistemas de alto rendimiento por la latencia y el riesgo de fallo del coordinador). La mayoría de libros mayores fintech de producción usan sagas, con una clave de idempotencia en cada operación para que los reintentos tras un fallo parcial sean seguros.
Otras guías
Crea un banco digital en cuestión de días
Solicita una demo