BlueUP Core: Sovereign Financial Engine
BlueUP Core is an integrated core banking and insurance engine, built from the ground up in Rust for institutions that need total technological sovereignty over their financial logic, accounting and compliance.
The Problem
SaaS vendor dependency
Your accounting rules, products and compliance live on a server you don't control.
Banking and Insurance separated
Two cores, two teams, two integrations, double the cost.
Single-GAAP accounting
Manual reports for IFRS, fiscal adjustments outside the system.
Compliance as an afterthought
Digital Operational Resilience Act: reglamento UE 2022/2554 sobre resiliencia operativa digital. Exige a entidades financieras de la UE resistir, responder y recuperarse de incidentes TIC. En vigor desde 17 enero 2025. Leer más → DORA, Anti-Money Laundering: prevención de blanqueo de capitales. Consume 5-10% del presupuesto operativo de una entidad media; los sistemas tradicionales generan >95% falsos positivos. Leer más → AML and Solvency II bolted on with middleware, not native.
Limited performance
Legacy Java/COBOL cores with second-level latencies per operation.
Our Solution
BlueUP Core unifies banking and insurance products in a single engine with integrated multi-standard accounting and institutional-grade performance.
Parallel Accounting (Multi-GAAP)
Every business event automatically generates entries in three books simultaneously:
| Book | Standard | Example |
|---|---|---|
| Sectorial | Local Insurance/Banking Chart | Spanish PGC, accounts 440, 700... |
| IFRS | International Standards (IFRS 17) | contract_liability, insurance_receivable |
| Fiscal | Corporate Tax | Temporary differences, extra-accounting adjustments |
Automatic reconciliation
Every business event generates a unique identifier (UUID v7 time-ordered) linking entries across all three books. Inter-book reconciliation runs in real time, not during monthly closes.
Decoupled Rules Engine
Accounting rules are defined in YAML files tracked in Git, not code. Your finance team can modify how an event is accounted for without a software deployment.
6 pre-configured posting templates:
| Business event | YAML template |
|---|---|
| Insurance premium collection | cobro_prima.yaml |
| Claim payment | pago_siniestro.yaml |
| Loan disbursement | desembolso_prestamo.yaml |
| Installment collection | cobro_cuota_prestamo.yaml |
| Reserve constitution | constitucion_reserva.yaml |
| Outbound SEPA transfer | transferencia_sepa_saliente.yaml |
Each template defines debit and credit entries for all three books simultaneously. Automatic validation of completeness (are all books covered?) and balance (is there at least one debit and one credit per book?).
Banking and Insurance Products
| Banking | Insurance |
|---|---|
| Personal loans | Term and savings life |
| Mortgages | Multi-risk home |
| Term deposits | Auto (third-party and comprehensive) |
| Current accounts | Health |
| SEPA transfers | Professional liability |
Integrated Payments
Native integration with European payment infrastructure:
- SEPA Credit Transfer (SCT): Outbound transfers
- SEPA Direct Debit (SDD): Installment and premium collection
- Spanish IBAN accounts operational from day one
- Banking-as-a-Service: Swan (European EMI, GraphQL API)
Native Compliance
Not a bolt-on module — it's part of the architecture:
| Regulation | Capability |
|---|---|
| AML | Screening, alerts, suspicious activity reports |
| DORA | Incident management, operational resilience, audit trail |
| Solvency II | Actuarial technical reserves, QRT reporting |
| Anti-structuring | Sliding window, pre-alerts at 80% threshold |
Verified Performance
Accounting invariants verified with property testing
- Every entry maintains balance (∑debits = ∑credits)
- Completeness: every event generates entries in all 3 books
- Determinism: the same input always produces the same output
- Side-effect free: the engine is pure
- Monotonic accumulation: the ledger only grows
Technology Stack
| Layer | Technology |
|---|---|
| Language | Rust (Edition 2024) |
| Web Framework | Axum 0.8 |
| Messaging | NATS JetStream with local SQLite buffer (Store & Forward) |
| Database | PostgreSQL (partitioned by book_id) |
| Authorization | Biscuit v6 / Datalog v3.3 |
| Network | Dark Service via OpenZiti (no public ports) |
| Isolation | gVisor (runsc) |
| Financial arithmetic | rust_decimal (arbitrary precision) |
| Dates and IDs | chrono + UUID v7 |
Who Is It For?
Institutions that need sovereignty
- Neobanks and fintechs wanting their own core without depending on Mambu, Thought Machine or Temenos
- Insurance companies needing a unified bancassurance engine
- Wealth managers with multi-GAAP accounting requirements
- Regulated entities that must comply with DORA and AML by design
Differentiation
| Feature | BlueUP Core | Traditional SaaS core banking |
|---|---|---|
| Multi-GAAP accounting | ✅ 3 native books | ❌ Manual adjustments |
| Banking + Insurance | ✅ Unified engine | ❌ Two separate systems |
| Performance | ✅ 162k journals/sec | ⚠️ Hundreds/sec (Java/COBOL) |
| Type safety | ✅ Compile-time (Rust) | ❌ Runtime errors |
| Integrated compliance | ✅ DORA/AML native | ⚠️ Add-on |
| Configurable accounting rules | ✅ YAML in Git, no deployment | ❌ Requires development |
| Zero Trust | ✅ No public ports | ❌ API with gateway |
| Data sovereignty | ✅ On-premise / own cloud | ❌ Shared multi-tenant |
| Property testing | ✅ 5 invariants, 1,280 executions | ❌ Manual tests only |
Talk to Our Team
Does your institution need a sovereign financial core with native compliance?