ARCHITECTURE DEEP DIVE

A core banking platform, all the way down

Most long-term cost and change friction in core banking comes from what sits at the foundation. This page is for architects and CTOs who want to see Solid's system boundaries before anyone talks commercials.

SYSTEM BOUNDARY

Solid owns the banking stack end to end

A core that runs on top of an ERP inherits that platform's release cycles, licensing, and upgrade obligations. Solid is built so the layer underneath banking is infrastructure only, not another product.

Layer 4 Channels & partners
Mobile / web banking
Operations tooling
Partner integrations
BI & reporting
Layer 3 Bank-owned extensions
Configured products
Policy & rule sets
Reports & exports
Custom workflows
↑ bank boundary · ↓ Solid boundary
Layer 2 Solid Core platform
Accounts & ledger
Lending · Deposits · Credit
Compliance & audit
Event bus & APIs
↑ Solid boundary · ↓ infrastructure boundary
Layer 1 Cloud infrastructure
Containers & orchestration
Managed storage
Networking & identity
No ERP layer

The dashed box is deliberate. Cores built on top of an ERP or generic enterprise runtime live there — with its licensing, its release cadence, and its consulting ecosystem. Solid does not.

DEPLOYMENT MODEL

Product platform, deployed per bank

Solid is not a multi-tenant SaaS app. The same product code is operated for each bank customer, with the bank's data, identity boundary, and operating posture.

What Solid is responsible for

  • The core product — ledger, products, compliance, APIs, event bus
  • Platform evolution and regulatory updates on the main release line
  • Upgrade path so every customer stays on one supported product
  • Reference infrastructure blueprints for cloud deployment

What the bank is responsible for

  • Their cloud account, identity, and data boundary
  • Configured products, policies, and reports on top of the core
  • Channels, partner integrations, and internal tooling
  • Operational runbooks for their regulatory and incident model

PLATFORM OVERVIEW

Three layers, with deliberate separation of concerns

Solid is shaped as three layers, each with a distinct change cadence. The core stays still. The integrations layer moves with the world around it. Administration is where the bank's own team operates the platform.

Solid Administration Graphical UI · product, policy, and operations configuration Solid Core Foundational engine · ledger, products, events, compliance Insulated from external complexity. Guaranteed stability and speed. Solid Integrations Adaptive bridge · KYC, payment rails, partners, channels

Foundational engine

Solid Core

The foundational engine of the platform. Insulated from external complexity, with guaranteed stability and speed.

  • Ledger, products, event bus, compliance, audit
  • Stable contracts — the surface partners and channels rely on
  • Performance and behavior do not change because something outside changed

Adaptive bridge

Solid Integrations

The adaptive bridge to other systems, designed to evolve freely as the surrounding ecosystem changes.

  • Connectors to KYC providers, payment rails, partners, and channels
  • Free to move at the cadence of the systems on the other side
  • Isolates the core from third-party churn and breaking changes

Operator surface

Solid Administration

The graphical user interface where the platform is configured and operated by the bank's own team.

  • Product, policy, fee, and rate configuration
  • Operations, exceptions, and case-handling workflows
  • No code path required for normal day-to-day platform changes

WHY THIS SHAPE

What the architecture is actually optimizing for

The shape above is not for marketing symmetry. Each layer exists to remove a specific class of long-running operating cost.

Change stays inside banking

No ERP underneath means no cascade updates on a layer the bank does not own.

State is always current

Real-time posting removes the blind spot between event and truth that batch systems live with.

Scaling is cloud-native

Containerized services scale with demand instead of provisioning for a nightly peak.

Audit is append-only

Every posting, decision, and config change lands on an immutable event log at the time it happens.

SELF-RELIANT OPERATIONS

Banking changes ship at the bank's pace, not the vendor's

Most cores route every change through certified consultants — quoted, scoped, and queued. Solid is built so the bank's own team owns the cadence. New products configured in days, rate and policy adjustments shipped without a release-window negotiation, partner channels added without a per-integration project.

  • Weekly product, rate, and policy iteration without vendor SOWs
  • Versioned configuration your team reads, audits, and rolls back
  • Expert help on tap when you want it — never as a gate

OPERATING BOUNDARIES

Clear split between product platform and bank delivery

Versioned interfaces

API and event contracts evolve with explicit deprecation windows, not silent breaks.

Configuration before code

Products, rates, fees, and policies are configured. Custom code stays a deliberate choice.

One supported product

All customers run the same core code. No per-customer forks, no drift on compliance updates.

TALK TO THE TEAM

Architects welcome. Bring the hard questions.

Schedule a call to go through the architecture end to end.

Schedule a call Review pricing approach