BlueUP Core: Motor financiero soberano
BlueUP Core es un motor de core bancario y asegurador integrado, construido desde cero en Rust para entidades que necesitan soberanía tecnológica total sobre su lógica financiera, contabilidad y compliance.
Cinco puntos donde un core convencional se queda corto
Dependencia de proveedores SaaS
Tus reglas contables, productos y compliance viven en un servidor que no controlas.
Banca y seguros separados
Dos cores, dos equipos, dos integraciones, doble coste.
Contabilidad single-GAAP
Informes manuales para IFRS, ajustes fiscales fuera del sistema.
Compliance como parche
DORA (Digital Operational Resilience Act) es el Reglamento (UE) 2022/2554 sobre la resiliencia operativa digital del sector financiero. Obliga a bancos, aseguradoras y empresas de inversión de la UE a resistir las perturbaciones y amenazas TIC, responder a ellas y recuperarse. Se aplica desde el 17 de enero de 2025.Leer más → DORA, SEPBLAC (Servicio Ejecutivo de la Comisión de Prevención del Blanqueo de Capitales e Infracciones Monetarias) es la Unidad de Inteligencia Financiera de España y autoridad supervisora de prevención del blanqueo y financiación del terrorismo. Los sujetos obligados le comunican toda operación con indicio (Ley 10/2010).Leer más → SEPBLAC y Solvencia II añadidos con middleware, no nativos.
Rendimiento limitado
Cores legacy en Java/COBOL con latencias de segundos por operación.
Un solo motor para banca, seguros y tres libros contables
BlueUP Core unifica productos bancarios y aseguradores en un solo motor con contabilidad multi-normativa integrada y rendimiento de grado institucional.
Contabilidad multi-GAAP que cuadra sin esperar al cierre
Cada evento de negocio genera asientos automáticos en tres libros simultáneamente:
| Libro | Normativa | Ejemplo |
|---|---|---|
| Sectorial | Plan Contable de Seguros / Circular BdE | PGC Seguros, cuentas 440, 700... |
| IFRS | Normas Internacionales (NIIF 17) | contract_liability, insurance_receivable |
| Fiscal | Impuesto de Sociedades | Diferencias temporales, ajustes extracontables |
Reconciliación automática
Cada evento de negocio genera un identificador único (UUID v7 time-ordered) que vincula los asientos de los tres libros. La reconciliación inter-libros se ejecuta bajo demanda sobre los libros in-memory, no en cierres mensuales.
El equipo financiero cambia una regla sin desplegar
Las reglas contables se definen en ficheros YAML en Git, no en código. Tu equipo financiero puede modificar cómo se contabiliza un evento sin necesidad de un despliegue de software.
16 plantillas de posting pre-configuradas, entre ellas:
| Evento de negocio | Plantilla YAML |
|---|---|
| Cobro de prima de seguro | cobro_prima.yaml |
| Pago de siniestro | pago_siniestro.yaml |
| Desembolso de préstamo | desembolso_prestamo.yaml |
| Cobro de cuota | cobro_cuota_prestamo.yaml |
| Constitución de reserva | constitucion_reserva.yaml |
| Transferencia SEPA saliente | transferencia_sepa_saliente.yaml |
Cada plantilla define las entradas de débito y crédito para los tres libros simultáneamente. Validación automática de completitud (¿todos los libros tienen asientos?) y balance (¿hay al menos un débito y un crédito por libro?).
Diez productos de banca y seguros en el mismo motor
| Bancarios | Aseguradores |
|---|---|
| Préstamos personales | Vida riesgo y ahorro |
| Hipotecas | Hogar multirriesgo |
| Depósitos a plazo | Autos (terceros y todo riesgo) |
| Cuentas corrientes | Salud |
| Transferencias SEPA | Responsabilidad civil |
Cobros y pagos SEPA con validación IBAN nativa
El motor implementa las primitivas de pago europeas:
- SEPA Credit Transfer (SCT): Transferencias salientes
- SEPA Direct Debit (SDD): Cobro de cuotas y primas
- Validación IBAN y BIC: checksum mod-97 (ISO 13616) y BIC sin dependencias externas
- Banking-as-a-Service: trait
PaymentGatewaypara conectar el proveedor; la integración con un proveedor BaaS real es roadmap
DORA, SEPBLAC y AML dentro del motor, no en un parche
El compliance es parte de la arquitectura, no un módulo añadido. La columna de estado usa el vocabulario del motor: operativo, modelado, roadmap.
| Regulación | Capacidad | Estado |
|---|---|---|
| Screening AML | Cribado de pagador y beneficiario vía el trait ScreeningProvider con registro auditable | Operativo como fundamento (listas reales: roadmap) |
| SEPBLAC S-1/S-3 | Modelo de datos tipado del filing (examen especial y comunicación por indicio) | Modelado (export XML oficial: roadmap) |
| DORA | Structs propios de assessment de controles con evidencia (orientados a OSCAL) y AuditInfo (actor, timestamp, motivo) en toda mutación contable | Assessment modelado (documento conforme al esquema NIST OSCAL: roadmap); audit trail operativo |
| Solvencia II | Reservas técnicas PPNC/IBNR y taxonomías y facts XBRL (EIOPA) | Reservas operativas; XBRL modelado (instancia XML conforme: roadmap) |
| Anti-structuring | Agregado de operaciones en ventana móvil con umbrales configurables | Operativo (heurística interna configurable, no umbral normativo) |
Rendimiento auditable: fecha, carga y hardware declarados
Invariantes contables verificadas con property testing
- Cada asiento mantiene el balance (∑débitos = ∑créditos)
- Completitud: todo evento genera asientos en los 3 libros
- Determinismo: la misma entrada produce siempre la misma salida
- Sin efectos secundarios: el motor es puro
- Acumulación monotónica: el ledger solo crece
Un motor en Rust, sin puertos públicos, aislado en gVisor
| Capa | Tecnología |
|---|---|
| Lenguaje | Rust (Edition 2024) |
| Framework Web | Axum 0.8 |
| Mensajería | NATS con mTLS + NKey fail-closed y garantías JetStream (ACK, Nats-Msg-Id); feature nats off por defecto |
| Base de datos | PostgreSQL particionado por framework contable (feature postgres, off por defecto, pendiente de integración) |
| Red | Dark service vía OpenZiti (sin puertos públicos) |
| Aislamiento | gVisor (runtimeClassName: gvisor) |
| Aritmética financiera | rust_decimal (precisión arbitraria) |
| Fechas y IDs | chrono + UUID v7 |
Para entidades que quieren un core propio, no alquilado
Entidades que necesitan soberanía
- Neobancos y fintech que quieren un core propio sin depender de Mambu, Thought Machine o Temenos
- Aseguradoras que necesitan un motor unificado para banca-seguros
- Gestoras de patrimonio con requisitos de contabilidad multi-GAAP
- Entidades reguladas que deben cumplir DORA y SEPBLAC por diseño
Lo que gana la entidad frente a un core tradicional
| Característica | BlueUP Core | Core bancario SaaS tradicional |
|---|---|---|
| Contabilidad multi-GAAP | ✅ 3 libros nativos | ❌ Ajustes manuales |
| Banca + Seguros | ✅ Motor unificado | ❌ Dos sistemas separados |
| Rendimiento | ✅ 150.657 asientos/seg (benchmark 2026-07-02) | ⚠️ Cientos/sec (Java/COBOL) |
| Seguridad de tipos | ✅ Compile-time (Rust) | ❌ Errores en runtime |
| Compliance integrado | ⚠️ Screening AML operativo; export DORA/SEPBLAC modelado | ⚠️ Add-on |
| Reglas contables configurables | ✅ YAML en Git, sin despliegue | ❌ Requiere desarrollo |
| Zero Trust | ✅ Sin puertos públicos | ❌ API con gateway |
| Soberanía del dato | ✅ On-premise / cloud propio | ❌ Multi-tenant compartido |
| Property testing | ✅ 11 tests de propiedad (proptest) | ❌ Solo tests manuales |
Límites declarados
Esta lista recoge lo que BlueUP Core todavía no hace, con el vocabulario del propio motor: operativo, modelado, roadmap.
- Screening AML y detección PEP: el cribado es operativo a través del trait
ScreeningProvider, hoy contra un provider in-memory de demostración. Las listas reales (EU consolidated, OFAC SDN) y el fuzzy matching son roadmap; la detección PEP está modelada (PepAssessmenty gate de EDD) y su contraste contra registros es roadmap. - Export al formato regulatorio: los filings SEPBLAC S-1 y S-3, el assessment OSCAL (DORA) y las taxonomías y facts XBRL (Solvencia II) están modelados como datos tipados con serialización JSON. El XML oficial del filing, la instancia XBRL conforme y el documento conforme al esquema NIST OSCAL son roadmap.
- Autorización: Biscuit y Datalog son intención de diseño sin implementación; la dependencia se retiró del workspace y se volverá a declarar con el primer consumidor real.
- Pasarela de pagos: la capa de pagos expone el trait
PaymentGateway(BaaS) y la única implementación en el árbol esMockGateway. La integración con un proveedor Banking-as-a-Service real es roadmap. - Ingesta externa (Store & Forward): el patrón está diferido por decisión de arquitectura; se implementará en Rust cuando exista el primer productor externo real, por ejemplo los webhooks de un proveedor BaaS.
- Reversión de asientos y eventos de dominio: el motor emite un evento canónico por evento de negocio (
JOURNAL_ENTRY_POSTED);JOURNAL_ENTRY_REVERSEDestá definido en el contrato y el mecanismo de reversión es roadmap, igual que los eventos de dominio (payment.*,policy.*,customer.*,compliance.*), que hoy no se emiten. - Persistencia y cableado runtime: los tres libros son nativos in-memory; el respaldo PostgreSQL, particionado por framework contable, va tras la feature
postgres, off por defecto y pendiente de integración, y los crates de dominio aún no tienen consumidor encore-server.
Encaje en la plataforma
BlueUP Core es el sustrato contable de la plataforma: no depende de ningún otro producto y publica un solo evento canónico hacia arriba. La arquitectura de la plataforma sitúa las tres capas y su orden.
Qué recibe. De los otros productos de la cartera, nada: su lista de dependencias está vacía y no se suscribe a ningún subject NATS. El cableado de los crates de dominio con el servidor del motor es roadmap (ver «Límites declarados»).
Qué entrega. Un evento canónico del libro (LedgerEvent) por evento de negocio en el subject blueup.core.ledger.events, con mTLS y NKey y comportamiento fail-closed, tras activar la feature nats, desactivada por defecto; lo consume BlueUPALM (AML/DORA). Además, los dos endpoints de salud del servidor (GET /healthz, GET /readyz).
Habla con nuestro equipo
Una sesión técnica muestra BlueUP Core configurado para el sector y el caso de la entidad.