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.
Five places a conventional core falls short
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
DORA (Digital Operational Resilience Act) is Regulation (EU) 2022/2554 on digital operational resilience for the financial sector. It requires EU banks, insurers and investment firms to withstand ICT disruptions and threats, respond to them and recover. It has applied since 17 January 2025.Read more → DORA, Anti-money laundering (AML) is the prevention of money laundering and terrorist financing. In Spain, Law 10/2010 requires credit and financial institutions to apply customer due diligence and to report suspicious transactions to SEPBLAC; Regulation (EU) 2024/1624 harmonizes it from July 2027.Read more → AML and Solvency II bolted on with middleware, not native.
Limited performance
Legacy Java/COBOL cores with second-level latencies per operation.
One engine for banking, insurance and three accounting books
BlueUP Core unifies banking and insurance products in a single engine with integrated multi-standard accounting and institutional-grade performance.
Multi-GAAP accounting that reconciles without month-end
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 on demand over the in-memory books, not during monthly closes.
The finance team changes a rule without a deployment
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.
16 pre-configured posting templates, including:
| 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?).
Ten banking and insurance products in one engine
| 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 |
SEPA collections and payments with native IBAN validation
The engine implements the European payment primitives:
- SEPA Credit Transfer (SCT): Outbound transfers
- SEPA Direct Debit (SDD): Installment and premium collection
- IBAN and BIC validation: mod-97 checksum (ISO 13616) and BIC with no external dependencies
- Banking-as-a-Service:
PaymentGatewaytrait for plugging in the provider; integration with a real BaaS provider is roadmap
DORA, SEPBLAC and AML inside the engine, not bolted on
Compliance is part of the architecture, not a bolt-on module. The status column uses the engine's vocabulary: operational, modelled, roadmap.
| Regulation | Capability | Status |
|---|---|---|
| AML screening | Payer and payee screening through the ScreeningProvider trait, with an auditable record | Operational as a foundation (real lists: roadmap) |
| SEPBLAC S-1/S-3 | Typed data model of the filing (special examination and suspicion report) | Modelled (official XML export: roadmap) |
| DORA | Own control assessment structs with evidence (OSCAL-oriented) and AuditInfo (actor, timestamp, reason) on every accounting mutation | Assessment modelled (document conformant to the NIST OSCAL schema: roadmap); audit trail operational |
| Solvency II | PPNC/IBNR technical reserves and XBRL taxonomies and facts (EIOPA) | Reserves operational; XBRL modelled (conformant XML instance: roadmap) |
| Anti-structuring | Transaction aggregation over a moving window with configurable thresholds | Operational (internal configurable heuristic, not a statutory threshold) |
Auditable performance: date, load and hardware declared
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
An engine in Rust, no public ports, isolated in gVisor
| Layer | Technology |
|---|---|
| Language | Rust (Edition 2024) |
| Web Framework | Axum 0.8 |
| Messaging | NATS with mTLS + NKey fail-closed and JetStream guarantees (ACK, Nats-Msg-Id); nats feature off by default |
| Database | PostgreSQL partitioned by accounting framework (postgres feature, off by default, pending integration) |
| Network | Dark service via OpenZiti (no public ports) |
| Isolation | gVisor (runtimeClassName: gvisor) |
| Financial arithmetic | rust_decimal (arbitrary precision) |
| Dates and IDs | chrono + UUID v7 |
For institutions that want their own core, not a rented one
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
What the institution gains over a traditional core
| Feature | BlueUP Core | Traditional SaaS core banking |
|---|---|---|
| Multi-GAAP accounting | ✅ 3 native books | ❌ Manual adjustments |
| Banking + Insurance | ✅ Unified engine | ❌ Two separate systems |
| Performance | ✅ 150,657 journals/sec (benchmark 2026-07-02) | ⚠️ Hundreds/sec (Java/COBOL) |
| Type safety | ✅ Compile-time (Rust) | ❌ Runtime errors |
| Integrated compliance | ⚠️ AML screening operational; DORA/SEPBLAC export modelled | ⚠️ 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 | ✅ 11 property tests (proptest) | ❌ Manual tests only |
Declared limits
This list states what BlueUP Core does not do yet, in the engine's own vocabulary: operational, modelled, roadmap.
- AML screening and PEP detection: screening is operational through the
ScreeningProvidertrait, today against an in-memory demonstration provider. Real lists (EU consolidated, OFAC SDN) and fuzzy matching are roadmap; PEP detection is modelled (PepAssessmentand the EDD gate) and matching it against registers is roadmap. - Export to the regulatory format: SEPBLAC S-1 and S-3 filings, the OSCAL assessment (DORA) and the XBRL taxonomies and facts (Solvency II) are modelled as typed data with JSON serialization. The official filing XML, the conformant XBRL instance and the document conformant to the NIST OSCAL schema are roadmap.
- Authorization: Biscuit and Datalog are a design intent without implementation; the dependency was withdrawn from the workspace and will be declared again with the first real consumer.
- Payment gateway: the payment layer exposes the
PaymentGatewaytrait (BaaS) and the only implementation in the tree isMockGateway. Integration with a real Banking-as-a-Service provider is roadmap. - External ingestion (Store & Forward): the pattern is deferred by architectural decision; it will be implemented in Rust once a first real external producer exists, for example the webhooks of a BaaS provider.
- Journal reversal and domain events: the engine emits one canonical event per business event (
JOURNAL_ENTRY_POSTED);JOURNAL_ENTRY_REVERSEDis defined in the contract and the reversal mechanism is roadmap, as are the domain events (payment.*,policy.*,customer.*,compliance.*), none of which are emitted today. - Persistence and runtime wiring: the three books are natively in-memory; PostgreSQL backing, partitioned by accounting framework, sits behind the
postgresfeature, off by default and pending integration, and the domain crates have no consumer incore-serveryet.
Platform fit
BlueUP Core is the platform's accounting substrate: it depends on no other product and publishes a single canonical event upwards. The platform architecture lays out the three layers and their order.
What it receives. From the other products in the portfolio, nothing: its dependency list is empty and it subscribes to no NATS subject. Wiring the domain crates into the engine server is roadmap (see "Declared limits").
What it delivers. One canonical ledger event (LedgerEvent) per business event on the subject blueup.core.ledger.events, with mTLS, an NKey and fail-closed behavior, once the nats feature is enabled; it is off by default. BlueUPALM (AML/DORA) consumes it. It also exposes the server's two health endpoints (GET /healthz, GET /readyz).
Talk to our team
A technical session shows BlueUP Core configured for each institution's sector and use case.