WHY SOLID
The difference is structural
What separates Solid from legacy and ERP-based core banking platforms is structural — six differences below, then six more, capability by capability.
-
Real-time, end to end
One current view of the bank, for everyone
There is no end-of-day batch to wait for. Every balance, every interest accrual, every compliance check, every report reflects the state of the bank as of right now — for back-office staff, for the internet-banking customer, for the auditor.
Take something as everyday as accrued interest. Most legacy cores recalculate it for every account in a nightly batch — a long, blocking job that the rest of the bank waits behind. Solid takes the opposite approach. Each new transaction updates the cached accrued interest on its account as part of processing the transaction; on accounts with no activity, the value is computed on demand so it's ready when anyone asks. By the time end-of-day arrives, the number is already correct for every account — no big batch waiting to fail. When the nightly schedule fails on a legacy core, customers don't get their interest. In Solid there is no nightly schedule to fail.
-
Concurrency
Fast on a quiet Tuesday and on month-end close
Most cores are not lock-free. When the internet bank gets busy, back-office tools start to hang. When a heavy integration syncs, a teller's screen waits behind it. Performance under load is not a feature you can patch in — it is an architectural choice made on day one.
Solid is lock-free by design. Internet-banking traffic, integrations, back-office work, and bulk operations run concurrently without blocking each other. One busy customer cannot lock out another. A heavy integration cannot delay a teller's screen. The system handles peak pressure the same way it handles a quiet Tuesday afternoon — with no architectural ceiling under which everything starts to slow.
-
Resilience
No single thing whose failure stops the bank
Solid runs as many small services on many small machines, not one big system on one big machine. If a node fails, traffic reroutes. If a service needs an update, the others keep serving. There is no single piece of infrastructure — and no single deploy window — that can take the bank offline.
Capacity grows by adding more small machines, not by buying a larger one. Legacy cores tend to scale vertically: one bigger box, then an even bigger box, then a "we need to talk to the vendor" conversation. Solid scales horizontally — the same architectural choice that makes it resilient also lets it deploy continuously, with zero-downtime rolling releases instead of migration weekends.
-
Banking depth
A core that's actually a core
A core banking system has to know banking — every detail, every edge case, every regulatory rule. Solid is built by people who have spent their careers in this domain, and the platform reflects it.
The detail matters. Payment-day handling that respects every Nordic country's bank-holiday calendar — so a payment due on Midsummer's Eve in Sweden doesn't break a customer's direct debit. IRR for revolving credit, calculated to the standard the regulator actually checks. FATCA and CRS edge cases handled in the data model, not in spreadsheets. An immutable audit log captured as events happen, not reconstructed afterwards. Get any of these subtly wrong and the bank pays later — in penalties, in customer trust, in reconciliation work. And the core stays a core: opinionated where law and accounting require it, unopinionated everywhere else. The product model, the GUI, the customer journey, the segmentation — those are yours.
-
Independence
No specialist gatekeeping between you and a change
Microsoft Dynamics has its own language. SAP has its own language and its own way of doing everything. A bank built on either pays specialists who speak the proprietary stack — at proprietary-stack rates — every time anything needs to change.
Solid is built on standard, open technologies. The skills required to operate and extend it are skills your engineering team already has, or can hire on the open market. No vendor-certified consulting partners standing between the bank and the change it wants to make. A change to banking stays in banking — there is no ERP project beneath it. The cost of a small change stays the size of a small change.
-
Total cost
The same architecture that makes it better makes it cheaper
A core banking decision is a multi-year operating commitment, and license is rarely the biggest line. Solid accepts a slightly higher license to deliver meaningfully lower operating cost and much lower consulting cost. The total over time is lower — and the shape stays predictable.
Operating cost is lower because there is no nightly batch to overprovision for, no third-party platform license sitting underneath the banking layer, and the cloud-native shape lets capacity scale with traffic instead of being bought ahead. Consulting cost is much lower because product, policy, and integration changes land as configuration on a stable platform — not as custom code on a forked vendor stack. Per-line items are visible from day one; the multi-year shape stays predictable. The full cost model is on the pricing page.
AND SIX MORE, IN DETAIL
Where the six show up, capability by capability
Each row below is a practical consequence of one or more of the differences above — side by side with the legacy approach, and what it means for the bank.
Architecture
Purpose-built microservices
Built as independent microservices from the ground up — not layered on top of an ERP system. Each service owns its data and is deployed independently, so a change to one service doesn't put the others at risk.
Monolith or ERP-extended
Often extend monolithic ERP frameworks, inheriting their constraints around deployment, data coupling, and upgrade cycles.
Targeted updates without system-wide risk — no coordinating across the whole platform.
Performance
Sub-second under any load
Capacity grows by adding more instances, not by buying a bigger server. Response times stay sub-second whether the bank is quiet or in the middle of month-end close.
Hardware-bound, vertical scaling
Constrained by monolithic architectures that require vertical scaling — adding more powerful hardware rather than more instances — leading to performance degradation during peak volumes and meaningfully higher infrastructure cost.
Consistent performance under any load, with infrastructure cost that scales with traffic.
Infrastructure
Cloud-native from day one
Auto-scaling, containerised deployments, and infrastructure-as-code. No on-premise lineage to maintain.
Cloud-hosted legacy
Originally designed for on-premise or static-capacity hosting. May run in the cloud, but elasticity is limited, driving up operational overhead.
Elasticity and DR are built in, not a second budget line.
Extensibility
Plug-in API modules
New payment rails, product types, or integrations plug in through well-defined APIs without modifying the core engine. Each module is versioned and deployable independently.
Customizations on ERP base
Customizations often require forking the base system, creating upgrade conflicts and long-term technical debt.
New rails and products ship without modifying the core engine.
Compliance
Configurable and future-ready
Compliance is part of the platform model from day one, so new requirement types can be added quickly, monitored continuously, and followed up operationally without core rewrites.
Bolted-on modules
Often bolt on compliance modules later, which slows change cycles and fragments visibility across tools.
New requirements land as configuration, not as project plans.
Audit trail
Immutable, real-time logs
Every transaction, configuration change, and access event is captured in an immutable, append-only log as it happens — providing full traceability for auditors and regulators.
Retroactive logging
Audit trails often reconstructed after the fact from disparate sources, creating gaps and inconsistencies that surface during regulatory reviews.
Auditors and regulators see one source of truth, current as of now.