The reliability of the monolith,
rewritten for the cloud.
BX-CoCore is a separate core banking product built on microservices and containers. Institutions requiring that architecture can evaluate it as an alternative Main Product for a banking suite or domain solution, subject to technical assessment.
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.
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%.
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.
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.
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 BX-CBB engine) inside each business microservice, inheriting design techniques proven over 30+ years of legacy systems.
BX-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.
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.
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.
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 BX-CBP with the full feature set real banks require, handling online and center-cut transactions without trouble.
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.
99.99% availability
An availability target supported by resilient infrastructure, failover and operational arrangements.
Proven MSA performance
Distributed-transaction overhead cut to about a third of x86. Response stays stable even at 99% APP CPU.
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.
Open Container · Kubernetes
Java/Spring Boot as-is, portable to OpenShift/Kubernetes and standard containers. No lock-in to specific hardware.
Same code, only the platform changes, and the overhead shrinks to a third.
The distributed overhead (TPS −35%, +47% response on x86) narrows sharply on IBM LinuxONE (s390x). Same BX-CoCore code, same 17-transaction scenario, measured with only the platform changed.
x86 data is at 40 concurrent users; LinuxONE data is measured across the 35, 50 and 100-user bands. LinuxONE held its response steady even at 99% APP CPU. These figures come from a joint technical validation with IBM Japan, not from a customer deployment; BX-CoCore is ready to sell and has no commercial reference yet.
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.
Let's design your MSA × LinuxONE transition.
See BX-CoCore running on both x86 and IBM LinuxONE.
→Our core-banking architecture team diagnoses your transaction patterns with you.
→See how BX-CoCore fits the wider Bankware platform.
→Background on MSA core banking and the LinuxONE platform.
→