Architecture
Digital Twin as the foundation
Digital Twin is the foundation that connects two worlds. Above it, the systems that cannot stop — digital channels, card processors, FedNow, RTP and blockchain — run 24×7. Below it, systems of record and reporting (Mainframe DDA, GL and others) can be unavailable for a few hours without affecting any real-time obligation of the bank.
M
24×7 layer — cannot stop
Digital channels
mobile & internet banking
Card processors
authorize / post
Payment processors
FedNow · RTP
Blockchain
Fireblocks · Circle
↕
DIGITAL TWIN
The foundation connecting both worlds · always 24×7
24×7
↕
Core-banking adaptor
playbook, not a product — bank-built software · 2-way async replication (CDC ↔ Kafka)
CDC: mainframe → DTw
Kafka: DTw → mainframe
↕
Non-24×7 layer — may be down for hours
Mainframe (DDA)
system of record · shadowed
General Ledger (GL)
accounting
Regulatory & reporting
end-of-day / month
Figure 1 — Digital Twin is the 24×7 foundation. Above, systems that cannot stop connect to it; below, systems of record and non-real-time reporting can go down for hours. Digital Twin bridges both worlds.
The core-banking adaptor is a playbook, not a product
It is custom software the bank builds following our playbook. It performs asynchronous two-way replication between the mainframe and Digital Twin: (1) it replicates every mainframe transaction into Digital Twin via Change Data Capture (CDC); and (2) it consumes any new Digital Twin transaction from Kafka and pushes it back to the mainframe. This bidirectional, asynchronous replication is what implements eventual consistency between the two systems.
Cloud architecture
After the big picture above — where Digital Twin sits alongside the other business microservices — this is the technical view: Digital Twin alone and the technology it depends on to run in the cloud. It is cloud-agnostic and scales horizontally.
VPC — network isolation
API Gateway + mTLS
ingress · OpenID Connect
↓
Kubernetes cluster
Ledger service
stateless pods · autoscaling
actuator /health
Transaction service
applies transaction codes
actuator /health
Sync service
shadows the mainframe
actuator /health
↓
Aurora RDS
relational store · Multi-AZ
Kafka + Avro Registry
events · versioned schemas
Immutable journal
append-only · audit
Health monitoring
scrapes the actuator APIs
← /actuator/health
Figure 2 — Digital Twin's cloud view: services on Kubernetes inside a VPC, with Aurora RDS, Kafka + Avro Registry, and actuator APIs exposed to health-monitoring systems.