💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

Prologue — changing a bank's heart

Core banking systems are the most conservative area in a bank. Mobile apps can be rebuilt every six months, but the core managing the ledger often still runs on 30-year-old COBOL code. The reason is simple — **it cannot be wrong**. If a balance is off by even one unit of currency, it ends up on the evening news.

That is why the 2026 conversation is "how do you swap out the heart without stopping it." UK's Lloyds Banking Group started migrating to Thought Machine Vault in 2024, Germany's N26 was built cloud-native on Mambu from day one, and Korea's KB Kookmin Bank is in the middle of a five-year next-generation IT project (ACE-Bank). And Japan? The Zengin system that went live in 1973 is in its sixtieth year — but behind it, NTT Data and NEC are drafting a cloud transition with BeSTA and OperaMaster.

This article maps the eleven core banking vendors, walks through Korean and Japanese next-generation IT projects, and explains the road from mainframe to cloud.

1. What is core banking — the ledger is the bank

Let's nail the definition. What a bank actually does reduces to four modules: **accounts, ledger, loans, and deposits**. A core banking system is what manages all four in one place.

What core banking handles, in detail:

- **Account management**: open, close, balance inquiry, transaction history

- **Ledger management**: debit and credit recording of every transaction, daily and monthly trial balances

- **Loans**: application, underwriting, repayment schedules, delinquency tracking

- **Deposits**: term deposits, recurring deposits, interest calculation

- **Settlement**: interbank transfers, international remittance, card post-processing

- **Accounting close**: end-of-day (EOD), month-end, year-end

Everything outside the core — mobile app, internet banking, ATM, call center — is a **channel** that calls the core. Replace channels all you want, the bank keeps running as long as the core is fine. The reverse is not true.

2. The mainframe era — sixty years of IBM z/OS and COBOL

The history of core banking is the history of the mainframe. IBM's mainframe lineage — System/360 in the 1960s, System/370 in the 1970s, zSeries in the 2000s — is still used by more than 90 of the world's top 100 banks. The OS is z/OS, the language is mostly COBOL, the transaction monitor is CICS, and the database is DB2 or IMS.

Why mainframes still? Three reasons.

1. **Reliability**: z/OS downtime is measured in seconds per year, not minutes. 99.999% availability (about five minutes a year).

2. **Throughput**: a single machine processes over 100,000 transactions per second.

3. **It already runs**: code that has been validated for 30 years — do you really have to change it?

The problem is cost and people. The MIPS (million instructions per second) licensing on an IBM mainframe runs to billions of won per quarter, and engineers who can work with COBOL are vanishing. Average age is over 55, and universities no longer teach it. That is why "post-mainframe" has been the conversation since the 2010s.

| Dimension | Mainframe (legacy) | Cloud-native (modern) |

| --- | --- | --- |

| Hardware | IBM z16, single machine in the billions of won | x86 cloud, on-demand |

| OS | z/OS | Linux containers |

| Language | COBOL, PL/I | Java, Kotlin, Python, TypeScript |

| Database | DB2, IMS | PostgreSQL, Cassandra, DynamoDB |

| Processing | Batch-centric (EOD) | Real-time event streaming |

| Deployment | Quarterly | Daily or more often |

| Talent pool | Shrinking | Plentiful |

| Scaling | Vertical (scale-up) | Horizontal (scale-out) |

3. Temenos T24/Transact — global market share leader

Headquartered in Switzerland, Temenos is the top vendor in the core banking market. Its flagship T24 (Transaction 24) launched in 1993 and is over 30 years old, but the redesigned cloud-native line called **Transact**, introduced in 2020, is the current focus.

Temenos is strong on **global standardization**. Used by 950 banks in 150 countries, it ships with multi-country support (multi-currency, multi-language, multi-jurisdiction) from the start. That is why multinational banks like HSBC and Standard Chartered prefer it.

The stack is Java-based with a proprietary database called jBASE. Recent versions also support Oracle and PostgreSQL. Cloud deployments target AWS, Azure, and GCP, and the container-based Transact Cloud is the strategic push.

Example Temenos Transact container deployment (Kubernetes)

apiVersion: apps/v1

kind: Deployment

metadata:

name: transact-core

namespace: banking

spec:

replicas: 3

selector:

matchLabels:

app: transact-core

template:

metadata:

labels:

app: transact-core

spec:

containers:

- name: transact

image: temenos/transact:R24.AMR.0

env:

- name: DB_HOST

value: postgres-primary.banking.svc.cluster.local

- name: COMPANY

value: 'BNK01'

resources:

requests:

memory: '4Gi'

cpu: '2'

limits:

memory: '8Gi'

cpu: '4'

ports:

- containerPort: 2020

name: tafj

Temenos's weak points are price and complexity. Licensing is expensive and customization requires specialized consultants. A bank typically takes 18 to 36 months and somewhere between `$50M` and `$300M` to roll it out.

4. Mambu — cloud-native, the original API-first

Berlin-based Mambu was founded in 2011 as a SaaS-style core banking platform. Skipping the mainframe era entirely, it was designed as multi-tenant on AWS from day one. By 2025 it serves over 11,000,000 end users across 65 countries.

Mambu's three core values:

1. **API-first**: every capability is exposed via REST APIs. Mobile, web, POS — channels only have to call APIs.

2. **Cloud-native**: multi-tenant on AWS, Azure, or GCP. The bank does not have to run infrastructure itself.

3. **Composable banking**: Mambu only provides the core. Payments, KYC, credit scoring are wired in via APIs from other fintech SaaS. The bank picks "best of breed" parts.

Representative customers include Germany's N26, the UK's ABN AMRO, Australia's 86 400, and Indonesia's BTPN. N26 in particular launched across all of Europe on top of Mambu.

{

"comment": "Mambu Loan Account creation API example",

"endpoint": "POST /loans",

"request": {

"loanName": "Personal Loan - 2026-05-25",

"loanAmount": "10000.00",

"interestRate": "8.5",

"productTypeKey": "8a8e8d2f-personal-loan-product",

"accountHolderKey": "8a8e8d2f-customer-uuid",

"accountHolderType": "CLIENT",

"scheduleSettings": {

"gracePeriod": 0,

"repaymentInstallments": 36,

"repaymentPeriodCount": 1,

"repaymentPeriodUnit": "MONTHS"

"disbursementDetails": {

"expectedDisbursementDate": "2026-06-01T00:00:00+09:00"

}

"response": {

"encodedKey": "8a8e8d2f-loan-account-uuid",

"accountState": "PENDING_APPROVAL",

"loanAmount": "10000.00"

}

Mambu's weakness is that **complex products are hard to build**. Standardized products (deposits, loans, cards) ship quickly, but markets like Korea and Japan with many variants — installment deposits, subscription savings, preferential rates — incur heavy custom development.

5. Thought Machine Vault — products as smart contracts

London-based Thought Machine was founded in 2014 by former Google engineers. Its flagship product Vault is widely seen as the most innovative approach in the core banking market — **financial products defined as code (smart contracts)**.

In a traditional core, launching a new product (say, a youth savings account with preferential rate) means filing a request with the vendor for a patch or bringing in consultants for six months of customization. Vault is different. You write the product logic in a Python-like DSL called **Contract Language**, and the bank's own engineers deploy it.

Thought Machine Contract Language example (simplified)

Term deposit: 1-year tenor, 4.5% APR, 0.5% on early redemption

api = '4.0.0'

display_name = '1-Year Term Deposit'

parameters = [

Parameter(name='deposit_amount', shape=NumberShape(min_value=1000)),

Parameter(name='interest_rate', shape=NumberShape(default_value=Decimal('0.045'))),

Parameter(name='penalty_rate', shape=NumberShape(default_value=Decimal('0.005'))),

Parameter(name='term_months', shape=NumberShape(default_value=12)),

]

@requires(parameters=True, balances='latest')

def execution_schedules():

return [('ACCRUE_INTEREST', {'hour': '0', 'minute': '0'})]

@requires(parameters=True, balances='latest')

def scheduled_code(effective_date, event_type):

if event_type == 'ACCRUE_INTEREST':

balance = vault.get_balance_timeseries().at(timestamp=effective_date).net()

rate = vault.get_parameter_timeseries(name='interest_rate').latest()

daily_interest = balance * rate / 365

posting_ins = vault.make_internal_transfer_instructions(

amount=daily_interest,

denomination='KRW',

from_account_id='BANK_INTEREST_EXPENSE',

to_account_id=vault.account_id,

)

vault.instruct_posting_batch(posting_instructions=posting_ins)

The advantage of this model is **product time-to-market**. A product that takes six months on a traditional core can ship in two weeks on Vault. And because all product logic is code-reviewed, tested, and version-controlled, auditability is excellent.

In 2024, the UK's Lloyds Banking Group started migrating to Vault, and Australia's ANZ Plus and Japan's SMBC also adopted it. There is no Korean deployment yet, but several commercial banks are evaluating it.

The downside is **learning a new stack**. Contract Language is powerful, but you need engineers in-house to wield it. For Korean and Japanese banks with heavy outsourcing dependence, this is a barrier to entry.

6. FIS Modern Banking Platform — the US market heavyweight

Headquartered in the US, FIS (Fidelity National Information Services) is a financial infrastructure giant with a market cap in the tens of billions. It acquired SunGard in 2015 and Worldpay in 2019, spanning payments, trading, and wealth. The core banking line consolidates multiple acquired products — IBS, Profile, HORIZON — under **Modern Banking Platform (MBP)**.

MBP is strong with mid-sized US and Canadian banks and credit unions. Its characteristics:

- **Modular structure**: ledger, loans, deposits, and cards deploy as independent modules

- **Cloud and on-prem hybrid**: keeps an on-prem option for conservative banks

- **Legacy compatibility**: incremental migration paths from existing FIS products

*> FIS HORIZON core EOD batch job (simplified)

IDENTIFICATION DIVISION.

PROGRAM-ID. EOD-INTEREST-ACCRUAL.

DATA DIVISION.

WORKING-STORAGE SECTION.

01 WS-ACCOUNT-RECORD.

05 WS-ACCT-NO PIC X(12).

05 WS-BALANCE PIC S9(13)V99 COMP-3.

05 WS-RATE PIC S9(3)V9(5) COMP-3.

05 WS-ACCRUED PIC S9(13)V99 COMP-3.

PROCEDURE DIVISION.

MAIN-LOGIC.

OPEN INPUT ACCT-MASTER-FILE

OUTPUT JOURNAL-FILE.

PERFORM READ-AND-ACCRUE UNTIL EOF-ACCT.

CLOSE ACCT-MASTER-FILE JOURNAL-FILE.

STOP RUN.

READ-AND-ACCRUE.

READ ACCT-MASTER-FILE INTO WS-ACCOUNT-RECORD

AT END MOVE 'Y' TO EOF-FLAG.

COMPUTE WS-ACCRUED ROUNDED =

WS-BALANCE * WS-RATE / 365.

WRITE JOURNAL-RECORD FROM WS-ACCOUNT-RECORD.

MBP's strength is **proven stability**. It is optimized for the US FDIC regulatory environment, and conservative customers like credit unions have been on it for 30+ years. The weakness is limited global reach.

7. NCR Voyix and Finastra Fusion — payments and mid-market specialists

NCR Voyix (spun off from NCR Corporation in 2023) is a giant in the ATM and POS terminal market, but in core banking it focuses on NCR Voyix Digital Banking, specialized for US community banks and credit unions. Less of a standalone core, more of a digital channel and middleware layer integrated with other cores.

Finastra was formed by a UK-US merger. Its Fusion Banking line covers small to mid (Fusion Essence), US credit unions (Fusion Phoenix), and global large banks (Fusion Equation) with market-specific products. It is particularly strong in **trade finance** and **syndicated loans**.

| --- | --- | --- | --- |

8. Infosys Finacle and TCS BaNCS — global cores made in India

Two Indian IT services giants produce core banking products that hold a major slice of the global market.

**Infosys Finacle** launched in 1995 and processes over 100 million customer accounts in 100 countries. Big banks like State Bank of India (SBI), the UK's RBS, and Australia's ANZ use it. Originally Java and Oracle based, it is moving to cloud-native with Finacle 11J. It has particularly high share in emerging markets like Indonesia, the Philippines, and Africa.

**TCS BaNCS** is a product of Tata Consultancy Services. It covers not only core banking but capital markets, insurance, and pensions as a comprehensive financial platform. Major customers include State Bank of India, Japan's SBI, and Canada's Bank of Montreal. **BaNCS adoption in Japan by SMBC and SBI** makes it a frequent evaluation candidate in Korea too.

Finacle internet banking component health check (example)

curl -s https://finacle-api.bank.example.com/v1/health | jq .

Response

{

"status": "UP",

"components": {

"coreEngine": "UP",

"ledger": "UP",

"paymentGateway": "UP",

"loanModule": "UP"

},

"version": "11J.1.0"

}

The strengths of Indian cores are **price competitiveness** and **fit with emerging markets**. Pricing is less than half of Temenos, and the outsourcing talent pool is enormous (Indian IT services have hundreds of thousands of staff). Weaknesses are a less polished UI/UX and being outpaced by Temenos and Mambu in developed markets.

9. Avaloq, SAP for Banking, Oracle Banking — Europe and the ERP giants

**Avaloq** is headquartered in Switzerland and specializes in **private banking and wealth management**. Swiss private banks like UBS, Credit Suisse, and Julius Baer are its key customers. Rather than general retail banking, it is optimized for managing high-net-worth individuals (HNWIs) with assets over `$100M`. Acquired by NEC in 2020, its Japan market push has accelerated.

**SAP for Banking** is the core banking line from ERP giant SAP. Its strength is **integration with accounting and finance modules** — if you view a bank as an enterprise, it solves ERP and core simultaneously. Adoption was slow after launch and momentum has flagged through the 2020s.

**Oracle Banking** (formerly i-flex / Flexcube) is a core built on Oracle DB. A natural choice for banks already on Oracle. Flexcube is strong in India, the Middle East, and Southeast Asia, and in Korea it is mostly used by foreign-bank branches.

| --- | --- | --- | --- |

10. Korea's next-gen IT — KB ACE-Bank, Shinhan SOL, Woori, Hana

Korean bank IT is a peculiar ecosystem. **They do not use vendor cores as-is. SI firms (Samsung SDS, LG CNS, SK C&C, KB Data Systems) build cores almost from scratch.** As a result, even the five major Korean banks all have different core architectures.

| --- | --- | --- | --- | --- |

| Woori | WIN | Woori FIS | 2020 to 2025 | `$300M+` |

**KB ACE-Bank** is Korea's largest next-gen IT project, migrating from mainframe (IBM z/OS) to an x86 distributed system (Linux plus Java plus Oracle/Tibero). It decomposes into microservices and adopts Kafka-based event streaming. Target go-live in 2026.

**Shinhan SOL** is both a mobile app brand and the name of the next-gen system. Shinhan launched its next-gen in 2021 and built the SOL super-app on top. Among Korean bank apps, it ranks number one in both usability and traffic.

Characteristics of Korean bank IT:

- **High share of in-house development** — they do not use commercial cores like Temenos and Mambu as-is

- **High dependence on KFTC (Korea Financial Telecommunications and Clearings Institute)** — interbank and real-time transfers go through KFTC

- **Strict FSS security regulations** — network segregation, authentication, and other Korea-specific rules

11. Samsung SDS Nexledger and Brity, plus Korean financial blockchain

In Korean financial IT, you cannot ignore Samsung SDS's **Nexledger** (blockchain platform) and **Brity** series (AI and automation).

**Nexledger** is an enterprise blockchain platform built in-house by Samsung SDS, deployed at Shinhan and Hana for digital assets, document authentication, and KYC. It is not core banking itself, but as adjacent infrastructure connected to the core, it forms one axis of the Korean financial IT map.

**Brity Works** and **Brity Assistant** are automation tools used in bank call centers and internal operations. Next-gen IT projects are integrating these automation tools with the core.

Typical Korean next-gen IT architecture (simplified)

core_ledger:

language: Java

framework: Spring Boot

database: Oracle / Tibero

message_queue: IBM MQ → Kafka (transitioning)

deployment: Linux on x86 (off mainframe)

channels:

mobile: React Native / Flutter

internet_banking: React + Spring

atm: in-house terminals (Diebold Nixdorf / Wincor)

external_integration:

kftc: Korea Financial Telecommunications (interbank transfer)

bok_wire: Bank of Korea BOK-Wire+ (large-value settlement)

cls: CLS Bank (FX)

swift: SWIFT (international remittance)

security:

network_segregation: split networks (internet zone vs business zone)

authentication: joint cert / financial cert / biometrics

encryption: AES-256, HSM (Hardware Security Module)

12. Japan's Zengin system — 60-year-old payment infrastructure

Japanese core banking is another peculiar ecosystem, distinct from Korea's. The **Zengin system (Zenginkyo Data Telecommunications System)** is the Japanese interbank settlement infrastructure that went live in 1973 and is now in its sixtieth year. The Japanese Bankers Association (JBA) operates it, and NTT Data runs the system. It processes over 13 million transactions a day.

At the heart of Zengin is **BANCS (Banking Application Network for Communication Services)**, NTT Data's platform. It is mainframe-based, and the eighth-generation system is rolling out in the late 2020s.

Zengin system data flow (simplified)

Bank A (initiates remittance)

↓ Zengin protocol (dedicated line)

Zengin center (operated by NTT Data, dual-site Tokyo/Osaka)

↓ net settlement (BOJ current account)

Bank B (receives)

Processing time: real-time during business hours / next business day outside hours

Japan's three megabanks (MUFG, SMBC, Mizuho) each use a different core.

| --- | --- | --- | --- |

**Mizuho MINORI** is particularly noteworthy — after going live in 2018, it had widespread ATM outages in February and March 2021, which became a social issue. Integrating three banks' cores after merger turned out to be too complex. Japan's FSA stepped in directly.

13. Japanese core banking vendors — NEC OperaMaster and NTT BeSTA

In the Japanese market, domestic cores dominate over global vendors.

**NEC OperaMaster** is a core for Japanese regional banks and credit unions, deployed at over 100 Japanese financial institutions. It is optimized for Japanese accounting, tax, and FSA reporting.

**NTT Data BeSTA** (Best-fit Standard banking Application) is the de facto standard for over 80% of Japanese regional banks. It is mainframe-based and transitioning to cloud, and the **OpenCanvas BeSTA Cloud** released in 2024 is the result.

NTT Data BeSTA Cloud architecture (based on public materials)

Presentation layer

- Mobile/web channels → API Gateway

Service layer

- Account service, Loan service, Deposit service (microservices)

Domain layer

- Ledger core (gradual migration from mainframe)

Infrastructure layer

- NTT Data private cloud (OpenCanvas)

- Kubernetes + PostgreSQL + Kafka

Characteristics of Japanese core banking:

- **Consensus-driven decision making** makes change slow — adding one feature can take 1 to 2 years

- **Extremely conservative about outages** — fallout from the Mizuho incident

- **Very high outsourcing dependence** — banks have few internal IT staff and rely on NTT Data, NEC, Fujitsu, and Hitachi (the big four SIs)

- **Cloud transition is slower than Korea's** — FSA guidance is conservative

14. Microservices decomposition — how do you slice a monolithic core

A traditional core is a giant monolith. Change one line and you recompile and test the whole thing. A cloud-native core slices this into microservices — but how?

From a domain-driven design (DDD) perspective, the natural boundaries of core banking are:

1. **Customer**: KYC, account holder management

2. **Account**: open, close, basic information

3. **Ledger**: debit and credit recording of every transaction (single source of truth)

4. **Loan**: loan products, underwriting, repayment

5. **Deposit**: deposit products, interest

6. **Payment**: transfer, remittance, billing

7. **Card**: debit and credit card issuance, authorization

8. **FX**: currency exchange, international remittance

Each domain becomes an independent service and communicates over REST/gRPC. The key principle is **each service owns its database (Database per Service)**.

Decomposed microservices core banking (simplified topology)

services:

customer-service:

db: PostgreSQL (customers, kyc_records)

api: gRPC / REST

account-service:

db: PostgreSQL (accounts, account_balances)

publishes: account.opened, account.closed

ledger-service:

db: Event Store (append-only) + PostgreSQL (snapshots)

publishes: posting.created

loan-service:

db: PostgreSQL (loans, repayment_schedules)

payment-service:

db: PostgreSQL (payments) + Redis (idempotency)

publishes: payment.initiated, payment.completed

card-service:

db: PostgreSQL (cards, authorizations)

infrastructure:

message_broker: Apache Kafka

service_mesh: Istio

observability: OpenTelemetry → Datadog

The hard part is **distributed transactions**. One transfer touches a debit (account-service) + ledger entry (ledger-service) + credit on the receiving side (account-service), and what if one step fails? Traditional cores solved this with 2PC (two-phase commit), but in microservices the standard is the **saga pattern** — break each step into compensatable units and emit compensation transactions on failure.

15. Event sourcing and CQRS — a new ledger paradigm

The ledger is the heart of core banking. The essence is not "what is the current balance" but **"the entire history of events on this account"**. The pattern that fits this view best is **event sourcing**.

A traditional core stores the balance as a single row.

-- Traditional balance table

account_balances (account_id, balance, updated_at)

1001 100000 2026-05-25 09:00:00

-- After transfer

1001 90000 2026-05-25 10:30:00 -- prior balance is gone

Event sourcing stores **every event**.

-- Event store

events (event_id, account_id, event_type, amount, timestamp)

e001 1001 AccountOpened 100000 2026-05-25 09:00:00

e002 1001 Withdrew 10000 2026-05-25 10:30:00

-- Current balance = sum of all events = 90000

Benefits:

- **Audit trail is automatic** — every change is preserved forever

- **Bug recovery is possible** — bad transactions are corrected with compensating events

- **Combines naturally with CQRS** — you can build many read models

CQRS (Command Query Responsibility Segregation) separates writes from reads. Writes append events; reads see various views projected from those events (balance, transaction history, tax reporting, etc.).

Event sourcing + CQRS flow

1. Command: Withdraw $10000 from account 1001

2. Event Store: append event (Withdrew, 10000, 2026-05-25T10:30)

3. Event Bus: publish event

4. Read Model 1 (Balance View): decrement balance by 10000

5. Read Model 2 (Transaction History): append history row

6. Read Model 3 (Tax Report): update tax aggregate

Thought Machine Vault is the model example of this pattern. Every transaction is recorded as a permanent Posting event, and the balance is a derived read model.

16. Real-time vs batch — RTGS and EOD coexist

The processing model of core banking has two axes: **real-time** and **batch**.

**Batch (EOD, end-of-day)**: aggregate the day's transactions and close after business hours. Interest accrual, tax aggregation, and trial-balance generation live here. This was the standard model in the mainframe era, and daily close is still an accounting necessity.

**Real-time (RTGS, real-time gross settlement)**: as soon as a transaction occurs, both accounts update and the settlement network reflects it. Operates 24/7. Digital banks like KakaoBank and N26 adopted this from day one.

| Dimension | Batch (EOD) | Real-time (RTGS) |

| --- | --- | --- |

| Processing unit | Day's worth at once | Each transaction immediately |

| Visibility | Next morning | Within seconds |

| Infrastructure | Mainframe + DB2 | Kafka + microservices |

| Outage impact | Close delay | Immediate user impact |

| Operating hours | Business hours | 24/7 |

Korea has had **real-time transfers as the standard since 2001** (over the KFTC network). On that count, Korea has one of the most advanced payment infrastructures in the world. Japan's Zengin system is real-time but conservative — outside business hours, transactions process the next business day. Europe standardized on SEPA Instant Credit Transfer, and the US is a latecomer with FedNow only going live in 2023.

17. Korea's payment infrastructure — KFTC, BOK-Wire+, open banking

The structure of Korea's payment networks.

- **KFTC (Korea Financial Telecommunications and Clearings Institute)**: interbank small-value settlement network. Interbank transfers and real-time remittance go through here. Founded in 1986.

- **BOK-Wire+**: the large-value settlement network run by the Bank of Korea. RTGS model. End users do not see it directly, but large-value transfers above `1,000,000,000` KRW go here.

- **Open Banking (2019~)**: fintechs can access any bank account via API. The infrastructure behind the explosion of Toss, KakaoPay, and others.

- **MyData (2022~)**: integrated query across financial information. A user's full financial data in one place.

Korea Open Banking data flow (simplified)

User → fintech app (e.g., Toss)

↓ authentication and consent

Fintech → KFTC Open Banking API

↓ calls each bank's core

Banks (KB, Shinhan, Woori, ...) → return balance, transaction history

↓

User sees a unified view

Thanks to this infrastructure, Korea has become **one of the most fintech-friendly markets in the world**. It is the background to why Toss, KakaoBank, and Naver Pay captured the market so quickly.

18. Japan's payment infrastructure — Zengin, BOJ-NET, late-arriving code payments

Japan's payment network has two axes.

- **Zengin system**: interbank small-value settlement. Live since 1973.

- **BOJ-NET**: Bank of Japan large-value settlement network. Similar to Korea's BOK-Wire+.

Code payments (QR and barcode) include **PayPay, LINE Pay, Rakuten Pay**, but adoption has been slow compared to Korea and China. Cash use in Japan is still high (around 35% in 2024, above the OECD average).

In 2023 there was a major Zengin outage — during a system upgrade, interbank transfers stopped for several days in August, affecting Japanese society as a whole. The limits of 60-year-old infrastructure surfaced. NTT Data subsequently announced an accelerated cloud transition.

19. The neobank core choice — Chime, Monzo, N26, Revolut

Neobanks are branchless mobile-only digital banks. The cores they chose reveal trends in the core banking market.

| --- | --- | --- | --- |

| Chime | US | Galileo (Stripe subsidiary) + in-house | 30M+ |

| Monzo | UK | in-house (Go, Kubernetes) | 11M+ |

| Revolut | UK | in-house | 50M+ |

| N26 | Germany | Mambu | 8M+ |

Interesting: **most neobanks built their own core**. Those that used a SaaS like Mambu (N26, 86 400) chose it for fast market entry. As they scale, they either move to in-house or apply deep customization.

The reason is **differentiation**. A standard core produces standard products, and standard products are hard to differentiate from competitors. So the bigger the digital bank, the larger the in-house share.

Korea's KakaoBank had LG CNS build its core, but all the product logic and channels on top were built by KakaoBank engineers. Toss Bank started with an in-house core from day one.

20. Core migration strategy — the strangler fig pattern

Moving a legacy core to cloud-native is a **multi-year project**. "Swap it out overnight" is impossible. So the **strangler fig pattern** (named by Martin Fowler) is the standard.

The key is **not killing the legacy, but having the new system gradually absorb its capabilities** — like a strangler fig slowly wrapping around the host tree.

Strangler fig migration phases

Phase 1 (1 to 2 years):

- Deploy a facade (router) in front of the new system

- All requests go through the facade

- Facade routes 100% to legacy

- Existing behavior unchanged

Phase 2 (2 to 3 years):

- Move non-core modules to the new system first (e.g., reporting, statistics)

- Facade routes some to new, some to old

- Data is bidirectionally synchronized

Phase 3 (3 to 5 years):

- Move core modules (account, ledger)

- Dual write → comparison validation

- Gradually grow new system share

Phase 4 (5 years+):

- Phase out legacy

- Remove or simplify the facade

- Decommission the mainframe

The key throughout is **data consistency**. Running both systems risks balance discrepancies. Most banks write to both for a period and run daily reconciliation.

Korea's KB ACE-Bank follows exactly this pattern. Started in 2021, migrating modules in phases, with full go-live target in 2026.

21. Regulation and compliance — the load the core carries

Core banking is more than technology. **Regulatory compliance** is half of it.

Major global regulations:

- **Basel III/IV**: capital adequacy and liquidity ratios

- **AML/CFT**: anti-money-laundering and counter-terrorism financing

- **KYC**: know-your-customer

- **GDPR**: privacy (Europe)

- **PCI DSS**: card data protection

Korea-specific:

- **FSS Electronic Financial Supervision Regulations**

- **PIPA (Personal Information Protection Act)**: similar to GDPR

- **Credit Information Use Act**: restrictions on credit data

- **Network segregation**: physical separation of internet and business networks

Japan-specific:

- **FSA comprehensive supervision guidelines**

- **APPI (Act on the Protection of Personal Information)**

- **My Number** handling regulations

When picking a core banking vendor, **how well it handles these regulations** is a key evaluation criterion. New cloud vendors like Mambu and Thought Machine enter emerging markets quickly, but conservative regulatory markets like Korea and Japan take time to validate.

22. Cost models — license, SaaS, in-house

Core banking adoption splits into three cost models.

**1. Perpetual license**: the traditional model. One-time license fee plus annual maintenance (20 to 25%). Temenos, FIS, and Finastra are here. Initial cost `$10M` to `$300M`, annual maintenance `$2M` to `$50M`. Drifting to cloud SaaS.

**2. SaaS/subscription**: Mambu, Thought Machine. Monthly or annual billing by user count or transaction volume. Low entry cost, ops cost scales with traffic.

**3. In-house build**: Korean and Chinese large banks and neobanks. Up-front investment `$100M` to `$500M` with hundreds to thousands of staff. Maximum long-term flexibility but largest risk.

| --- | --- | --- | --- | --- |

23. The future of core banking — AI, blockchain, CBDC

Where core banking is heading in 2026.

**1. AI integration**: LLMs for customer support, fraud detection, and credit scoring. An AI layer sits on top of the core. Korea's KB and Shinhan are aggressive here.

**2. Blockchain/DLT integration**: distributed ledger complements traditional ledgers. Starts with cross-border payments replacing SWIFT (JP Morgan Onyx, Partior). Korea's Samsung SDS Nexledger is part of the same wave.

**3. Central Bank Digital Currencies (CBDC)**: central banks piloting digital currency. China's e-CNY is furthest ahead, and the Bank of Korea has been piloting since 2024. When CBDCs go live, core banking will need direct connections to central bank systems.

**4. Embedded banking**: core banking APIs integrated directly into non-bank apps (taxi, commerce, SaaS). Banking-as-a-Service (BaaS) kicks into gear. Mambu, Solaris, and Treasury Prime live in this space.

**5. Post-quantum cryptography**: 2030s worry about quantum computers breaking RSA. Core banking crypto infrastructure starts moving to PQC (post-quantum cryptography).

24. Wrap-up — what to read after this

Core banking systems are the heart of a bank. COBOL on IBM mainframes in the 1970s is being reborn as Java/Kotlin/Python on Kubernetes in 2026. Temenos, Mambu, Thought Machine, FIS, NCR, Finastra, Finacle, BaNCS, Avaloq, SAP, Oracle — eleven global vendors each with a different market and value proposition. Korea is strong in in-house cores built by SI firms; Japan is dominated by Japan-made cores from NTT Data and NEC.

The point is **not "what should I buy" but "why are we changing"**. Mainframes are validated reliability assets; cloud is the opportunity for speed and cost efficiency. The answer ends up **hybrid**, with gradual five-to-ten-year migrations being the reality.

Topics worth reading next:

- Payment systems overall (SWIFT, SEPA, FedNow, Zengin)

- Banking-as-a-Service (BaaS) market

- CBDC and digital assets

- Korean fintech ecosystem (Toss, KakaoBank, Naver Pay)

- Japanese megabank IT governance

References

- Temenos Transact Documentation — `https://docs.temenos.com/`

- Mambu Developer Portal — `https://api.mambu.com/`

- Thought Machine Vault Contract Language Docs — `https://docs.thoughtmachine.net/vault/`

- FIS Modern Banking Platform — `https://www.fisglobal.com/en/banking/modern-banking-platform`

- NCR Voyix Digital Banking — `https://www.ncrvoyix.com/financial-services`

- Finastra Fusion Banking — `https://www.finastra.com/solutions/banking`

- Infosys Finacle — `https://www.edgeverve.com/finacle/`

- TCS BaNCS — `https://www.tcs.com/what-we-do/products-platforms/tcs-bancs`

- Avaloq — `https://www.avaloq.com/`

- SAP for Banking — `https://www.sap.com/industries/banking.html`

- Oracle Banking — `https://www.oracle.com/industries/financial-services/banking/`

- KB Kookmin ACE-Bank Next-Gen IT Press — `https://www.kbstar.com/`

- Shinhan The New Shinhan — `https://www.shinhan.com/`

- Samsung SDS Nexledger — `https://www.samsungsds.com/kr/blockchain/nexledger.html`

- KFTC Open Banking — `https://www.kftc.or.kr/`

- Bank of Korea BOK-Wire+ — `https://www.bok.or.kr/`

- NTT Data BeSTA / BANCS — `https://www.nttdata.com/jp/ja/services/besta/`

- NEC OperaMaster — `https://jpn.nec.com/financial/`

- Japanese Bankers Association Zengin System — `https://www.zenginkyo.or.jp/`

- Bank of Japan BOJ-NET — `https://www.boj.or.jp/paym/bojnet/index.htm/`

- Martin Fowler — Strangler Fig Application — `https://martinfowler.com/bliki/StranglerFigApplication.html`

- Domain-Driven Design (Eric Evans, 2003) — Addison-Wesley

- Building Event-Driven Microservices (Adam Bellemare, 2020) — O'Reilly

- BIS — Real-Time Gross Settlement Systems — `https://www.bis.org/cpmi/publ/d22.htm`

- Basel Committee on Banking Supervision — `https://www.bis.org/bcbs/`

- Mambu — The State of Cloud Banking Report — `https://www.mambu.com/insights/reports`

- Thought Machine — Lloyds Banking Group Migration Announcement (2024) — Thought Machine press release

- IBM z/OS and Mainframe Modernization — `https://www.ibm.com/z`