Cloud-Native Core Banking Platform
A reference architecture for moving core banking onto cloud-native services, with domain-aligned microservices and a regulated data zone.
The challenge
Replacing a monolithic core banking system without a big-bang migration, while keeping every transaction auditable and resident in an approved region.
Core banking replacements fail in the same way: the programme tries to swap the ledger and every channel at once, and the cutover becomes a single event nobody can rehearse. This cloud-native platform architecture is shaped around avoiding that — the legacy core stays in place and is strangled one domain at a time.
How it works
Channels never talk to the core. They talk to an API contract, and behind that contract a strangler adapter decides whether a given domain is served by the new microservice or still by the legacy core. Migrating a domain becomes a routing change rather than a cutover, and rolling one back is the same change in reverse.
State changes are published to the event backbone rather than pushed synchronously to every consumer. Fraud scoring, notifications, the reporting warehouse and the audit log all subscribe. Adding a consumer does not modify the producer, which is what keeps the payments service from accumulating a call to every downstream system in the bank.
What to get right
- Idempotency is not optional. Every command carries a client-generated key, and every consumer is safe to replay — at-least-once delivery is the default and a duplicated payment is not a recoverable error.
- Keep the ledger boring. Business logic belongs in the domain services; the system of record should do as little as possible and be auditable line by line.
- Decide residency before the first service ships. Region pinning and customer-managed keys are architectural, and retrofitting them means re-encrypting and re-homing data that is already under regulation.
- One correlation ID, end to end. Without it the event backbone turns every production incident into an archaeology exercise.
How it fits together
Channel and experience layer
Mobile, internet banking, branch and partner channels call one API contract rather than the core directly, so a channel change never reaches into the ledger.
API gateway and BFF
Terminates TLS, authenticates the caller, applies rate limits and per-channel quotas, and routes to a backend-for-frontend that shapes responses per channel.
Domain microservices
Payments, accounts, customer, lending and cards are separate deployables aligned to business domains, each owning its schema so a release is scoped to one domain.
Event backbone
Every state change is published as an immutable event. Downstream consumers — ledger, fraud, notification, analytics — subscribe rather than being called synchronously.
Strangler adapter to the legacy core
The seam that makes the migration incremental: reads and writes route to the legacy core until a domain is ready, then flip per-domain behind a feature flag.
Regulated data zone
The system of record, encrypted at rest with customer-managed keys, region-pinned for residency, and fronted by an immutable audit log.
Observability and controls
Distributed traces, metrics and structured logs across every hop, joined by a correlation ID that starts at the channel and survives the event backbone.
Typically built with
- Kubernetes
- Apache Kafka
- Spring Boot
- PostgreSQL
- Redis
- OpenTelemetry
