BX-CoCore · Cloud-Native Core Banking · Runs on x86 & IBM LinuxONE

The reliability of the monolith,
rewritten for the cloud.

BX-CoCore re-architects CBP, a core-banking package proven in production banks for 10+ years, into cloud-native microservices. It preserves exact, to-the-cent data consistency while running identically on x86 cloud and IBM LinuxONE (s390x), and on LinuxONE its real strength shows.

0types
Real transaction mix under load test
0.000000%
LinuxONE mainframe-class availability
0–13%
LinuxONE MSA overhead (x86: 35%)
0%
Stable response even at peak CPU
Why MSA for core banking

Integrated core banking is stable, but heavy to change.

A commercial bank's core banking sees 10,000–20,000 code changes a year, and a single new-product campaign can draw millions of customers at once. One monolithic block struggles to keep that pace. BX-CoCore separates business domains into independent services, easing three burdens.

Auto scale-out

Elastic under transaction spikes

When a campaign or partner traffic suddenly surges, only the relevant business microservice scales out automatically. No need to pre-buy standby capacity that otherwise idles below 50%.

BaaS ready

Spin up lightweight virtual banks fast

When a partner needs a dedicated virtual bank, compose a small core from only the functions you need (customer, deposit) without touching the live system, isolating the risk.

DR cost down

Lighter disaster-recovery investment

Keep the DR system on minimal standby, then scale capacity dynamically when an event occurs. Capital tied up in always-idle duplicate hardware turns into OPEX.

Architecture

Distributed, without giving up response time.

Core banking must process tens of thousands of transactions per second, each within one second. To minimise inter-service calls, BX-CoCore co-locates a common component (the CBB engine) inside each business microservice, inheriting design techniques proven over 30+ years of legacy systems.

CBB Business service + common engine

Product, contract, settlement and accounting engines live inside each microservice, so an ordinary transaction never crosses an MS boundary; it is processed as on a single server.

SVC Service orchestration

Business services drive the flow directly. Instead of the textbook external orchestrator, the business service, which holds all the decision context, takes that role.

LRA Compensating transactions · eventual consistency

For inter-MS transactions (~40%), if a failure occurs the LRA Coordinator calls @compensate to restore state automatically. Consistency is owned by the application.

LOCK Semantic lock

Logical, business-level locking keeps incomplete data from a distributed transaction from ever being exposed mid-flight.

BX-CoCore / 8 CPU · 6 Container
API GATEWAY · REST
Deposit
Deposit DB · CBB Engine
Loan
Loan DB · CBB Engine
Customer
Customer DB · C·U·D owner
Accounting
via MQ · journal posting
Common
address, numbering · replicated per MS
LRA Coordinator
@compensate / @complete · tracks compensations
Product Factory
product, rate, fee deploy
Config Portal
COA, journal rules, codes
Customer DB
read-only share
Performance, verified

We don't dress up the data. And the platform changes the answer.

We ran the same workload as a monolith (CBP-Mono) and as MSA (BX-CoCore) and measured 17 transaction types under JMeter. On AWS x86, MSA showed clear overhead, and we publish it as-is. The point: running the same code on IBM LinuxONE (s390x) makes that overhead nearly disappear.

WAS 8 CPU · JMeter load · AWS x86 vs. IBM LinuxONE s390x, identical scenario
MSA throughput (TPS) overhead, closer to 0% is betterTPS loss vs. monolith
AWS · x8640 USER · 170→110
−35%
LinuxONE · 50Us390x · 340→305
−10%
LinuxONE · 35Us390x · 287→263
−8%
LinuxONE · 100Us390x · 385→336
−13%
MSA average response-time overhead (17-type mix), lower is betterincrease vs. monolith
AWS · x86230→339 ms
+47%
LinuxONE · 50U132→148 ms
+12%
LinuxONE · 35U112→123 ms
+10%
LinuxONE · 100U213→248 ms
+16%
Loan execution response (LRA inter-MS transaction): the toughest caseabsolute response · lower is better
AWS · MSAx86 · REMOTE+LRA
1,929 ms · +62%
AWS · Monox86 BASELINE
1,193 ms
LinuxONE · MSAs390x · 50 USER
652 ms · +25%
LinuxONE · Monos390x BASELINE
520 ms

x86 data is at 40 concurrent users; LinuxONE data is measured across the 35, 50 and 100-user bands. Same code, same scenario; only the platform changed.

The same MSA code, and on LinuxONE the overhead shrinks to a third.

Inter-MS transactions inherently carry overhead: they update two DBs and run LRA compensation. On x86 that showed up as −35% TPS and +47% response. On s390x, with its high single-thread throughput and I/O bandwidth, it narrows to −10–13% / +10–16%. And LinuxONE held its response steady even at 99% APP CPU.

10–13%
MSA TPS overhead on LinuxONE, roughly a third of AWS x86's 35%. You take the flexibility of distribution while landing close to integrated-system performance.
Mission-critical platform

BX-CoCore × IBM LinuxONE.

BX-CoCore runs anywhere as containers: AWS, Azure, x86, and IBM LinuxONE (s390x). Among them, LinuxONE delivers mainframe-class reliability and cloud-native agility on one platform. Not a return to the mainframe era; it brings mainframe-class resilience into the cloud-native age.

Reliability

99.999999% availability

Mainframe-class non-stop operation. The 24×365 uptime core banking demands, backed at the hardware level.

Performance

Proven MSA performance

Distributed-transaction overhead cut to about a third of x86. Response stays stable even at 99% APP CPU.

Operation

Simple operations even at scale

High-density consolidation onto fewer physical nodes. The larger the scale, the more it lowers operational complexity and 5-year TCO.

Portability

Open Container · Kubernetes

Java/Spring Boot as-is, portable to OpenShift/Kubernetes and standard containers. No lock-in to specific hardware.

The best platform for mission-critical banking in the AI era

BX-CoCore brings agility and portability; LinuxONE brings security, resilience and operational simplicity.

Together they redefine the core-banking platform for the AI era. Where z/OS legacy still runs, you can modernise incrementally, running new MSA workloads (lending, eWallet, underwriting, notifications) as a LinuxONE sidecar on the same hardware, integrated over MQ and REST.

BX-CoCoreCloud-Native MSA · Container
IBM LinuxONEs390x · Mainframe-class trust
Signature technology

MS-Flexer: change the placement, not the code.

A business program should be written without knowing whether it's distributed or co-located. MS-Flexer locates the target microservice at runtime and calls it, letting you re-architect placement dynamically while watching performance.

Runtime placement

One line of code, two placement strategies

The same business code branches automatically: a remote call plus LRA compensation when the target MS is on a separate server, or a simple internal call when it's co-located. Developers don't think about placement; operations re-place freely while watching performance.

Deposit MSLoan MS
Remote call + LRA compensation · two DBs updated
1,929 ms (x86) / 652 ms (LinuxONE)
Fully distributed: flexible, but inter-MS transactions slow down
Adoption benefits

On a proven package, add only the upsides of cloud.

Domain-specialised operations teams

Run deposits and loans as independent teams. A change in one domain doesn't make another team wait, so maintenance gets easier and long-term TCO drops.

Immediate impact for intake & campaigns

Split non-financial work (intake, campaigns) into separate microservices and scale them out without touching the core, solving customer wait times and traffic spikes at once.

Higher availability

Spread microservices across several mid-sized servers and the single point of failure disappears. If one server stops, the whole core doesn't go down.

Complete business coverage

Not a toy model. Built on a CBP with the full feature set real banks require, handling online and center-cut transactions without trouble.