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

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

プロローグ — 銀行の心臓を入れ替えるということ

コアバンキングシステムは銀行で最も保守的な領域だ。モバイルアプリは半年ごとに作り直しても、台帳(ledger)を管理するコアは30年前のCOBOLコードがそのまま動いている、というのが珍しくない。理由は単純で、**間違ってはいけない**からだ。残高が1円でも狂えばその晩のニュースになる。

そこで2026年の論点は「どうやって止めずに心臓を入れ替えるか」になる。英Lloyds Banking Groupは2024年にThought Machine Vaultへの移行を開始し、独N26は最初からMambuの上にクラウドネイティブで構築、韓国のKB国民銀行は5年がかりの次世代ITプロジェクト(ACE-Bank)を進めている。日本は? 1973年稼働の全銀システムが60年目に入った — その裏ではNTTデータとNECがBeSTA・OperaMasterでクラウド移行を描いている。

本稿ではコアバンキング11ベンダーの地図を描き、日韓の次世代ITプロジェクトを概観し、メインフレームからクラウドへの道筋を解説する。

1. コアバンキングとは何か — 台帳こそが銀行

まず定義をはっきりさせよう。銀行が処理する業務は結局、**勘定(account)・台帳(ledger)・与信(loan)・受信(deposit)**の4モジュールに還元される。この4つをまとめて1つのシステムで管理するのがコアバンキングだ。

コアバンキングが扱う業務を展開すると以下のようになる。

- **勘定管理**: 新規開設・解約・残高照会・取引履歴

- **台帳管理**: 全取引の借方/貸方(debit/credit)の記録、日計表・月計表の生成

- **与信**: 融資申請・審査・返済スケジュール・延滞管理

- **受信**: 定期預金・積立預金・利息計算

- **決済・清算**: 他行振込・国際送金・カード決済後処理

- **会計締め**: 日次締め(EOD, end-of-day)、月末・期末締め

コア以外のシステム — モバイルアプリ・インターネットバンキング・ATM・コールセンター — はすべてコアを呼び出す**チャネル(channel)**だ。チャネルは作り変えてもコアが無事なら銀行は回る。逆は成り立たない。

2. メインフレーム時代 — IBM z/OSとCOBOLの60年

コアバンキングの歴史はメインフレームの歴史でもある。1960年代のIBM System/360、1970年代のSystem/370、2000年代のzSeriesと続くIBMのメインフレーム系譜は、いまも世界トップ100銀行のうち90行以上で使われている。OSはz/OS、言語はほぼCOBOL、トランザクションモニタはCICS、データベースはDB2かIMSだ。

なぜいまだにメインフレームなのか。理由は3つ。

1. **信頼性**: z/OSの年間ダウンタイムは分単位ではなく秒単位。99.999%可用性(年間約5分)。

2. **スループット**: 単一マシンで毎秒100,000件以上のトランザクションを処理。

3. **すでに動いている**: 30年検証されてきたコードを、わざわざ変える必要があるのか?

問題はコストと人材だ。IBMメインフレームのMIPS(million instructions per second)ライセンス費用は四半期で数十億円かかり、COBOLを扱える技術者は減り続けている。平均年齢は55歳以上で、大学ではもう教えていない。だから「脱メインフレーム」は2010年代から続く論点だ。

| 観点 | メインフレーム(legacy) | クラウドネイティブ(modern) |

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

| ハードウェア | IBM z16、単一機で数十億円 | x86クラウド、オンデマンド |

| OS | z/OS | Linuxコンテナ |

| 言語 | COBOL、PL/I | Java、Kotlin、Python、TypeScript |

| DB | DB2、IMS | PostgreSQL、Cassandra、DynamoDB |

| 処理 | バッチ中心(EOD) | リアルタイムイベントストリーミング |

| デプロイ | 四半期単位 | 日次以上 |

| 人材プール | 縮小傾向 | 豊富 |

| スケーリング | 垂直(スケールアップ) | 水平(スケールアウト) |

3. Temenos T24/Transact — 世界シェア1位

スイス本社のTemenosはコアバンキング市場のトップベンダーだ。主力製品のT24(Transaction 24)は1993年発売で30年以上経つが、2020年にクラウドネイティブとして設計し直された**Transact**ラインが現在の主力。

Temenosが強い理由は**グローバル標準化**だ。150か国950行が利用しており、多通貨・多言語・多法域(マルチカントリー)対応が最初から組み込まれている。HSBCやStandard Charteredといった多国籍銀行が選ぶ理由がここにある。

技術スタックはJavaベースで、自社DBのjBASEを使う。近年はOracleやPostgreSQLにも対応。クラウドはAWS・Azure・GCPすべて対応し、コンテナベースのTransact Cloudを推している。

Temenos Transactコンテナデプロイの例 (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の弱点は価格と複雑性だ。ライセンス費用が高く、カスタマイズには専門コンサルタントが必須。1行が導入するのに平均18~36か月、`$50M`から`$300M`規模かかる。

4. Mambu — クラウドネイティブ・APIファーストの草分け

ベルリン本社のMambuは2011年設立のSaaS型コアバンキングだ。メインフレーム時代を飛ばし、最初からAWS上でマルチテナント設計。2025年時点で65か国・11,000,000人超のエンドユーザーに提供している。

Mambuの核心的な3つの価値。

1. **APIファースト**: 全機能をREST APIで公開。モバイル・Web・POSなどのチャネルはAPIを叩くだけ。

2. **クラウドネイティブ**: AWS・Azure・GCPでマルチテナント運用。銀行がインフラを自前で運用しなくてよい。

3. **コンポーザブルバンキング(composable banking)**: Mambuはコアだけ提供し、決済・KYC・与信スコアリングは他のフィンテックSaaSとAPIで組み合わせる。「ベストオブブリード」を選ぶモデル。

主要顧客は独N26、英ABN AMRO、豪86 400、インドネシアBTPN。とくにN26はMambuの上で欧州全域に展開した。

{

"comment": "Mambu Loan Account 作成API例",

"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の弱点は**複雑な商品を作りづらい**ことだ。標準化された商品(預金・融資・カード)はすぐに出せるが、韓国・日本のように定期預金・積立預金・申込預金・優遇金利などバリエーションが多い市場では追加開発コストが大きい。

5. Thought Machine Vault — 商品をコード(スマートコントラクト)で定義

ロンドン本社のThought Machineは2014年に元Googleエンジニア達が設立した。主力製品Vaultはコアバンキング市場で最も革新的なアプローチと評価される — **金融商品をコード(スマートコントラクト)で定義**するというものだ。

伝統的なコアバンキングで新商品(例: 若者向け積立預金の優遇金利)を出すには、ベンダーにパッチを依頼するか、コンサルタントに半年カスタマイズしてもらう必要がある。Vaultは違う。**Contract Language**というPython風のDSLで商品ロジックを書き、銀行の内部エンジニアがデプロイする。

Thought Machine Contract Languageの例 (簡略化)

定期預金商品: 1年満期、年4.5%、中途解約時0.5%

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)

このモデルの利点は**商品リリース速度**だ。従来コアで半年かかる商品がVaultでは2週間で作れる。さらに全商品ロジックがコードレビュー・テスト・バージョン管理されるので監査性も高い。

2024年に英Lloyds Banking GroupがVaultへの移行を開始し、豪ANZ Plus、日本のSMBCも採用。韓国ではまだ採用事例はないが、複数の都市銀行が検討中だ。

弱点は**新しい技術スタックを習得しなければならない**ことだ。Contract Languageは強力だが、銀行内部に使いこなせる技術者が必要になる。外注依存度が高い日韓銀行には参入障壁がある。

6. FIS Modern Banking Platform — 米国市場の覇者

米国本社のFIS(Fidelity National Information Services)は時価総額数百億ドルの金融インフラ巨人だ。2015年にSunGardを買収、2019年にWorldpayを買収し、決済・トレーディング・資産運用までカバーする。コアバンキング系列はIBS・Profile・HORIZONなど複数の買収製品を統合し、**Modern Banking Platform(MBP)**を作った。

MBPは米国・カナダの中小銀行と信用組合(credit union)で強い。特徴は以下。

- **モジュール構造**: 台帳・与信・受信・カードを独立モジュールとしてデプロイ

- **クラウド/オンプレ併用**: 保守的な銀行向けにオンプレ選択肢を維持

- **レガシーとの互換**: 既存FIS製品からの段階的移行パス

*> FIS HORIZONコアの日次締めバッチ (簡略化)

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の強みは**実証された安定性**だ。米国FDIC規制環境に最適化されていて、信用組合のような保守的顧客が30年以上使い続けている。弱点はグローバル展開力に欠けることだ。

7. NCR Voyix・Finastra Fusion — 決済・中堅市場の専業

NCR Voyix(2023年にNCR Corporationから分社化)はATM・POS端末市場の巨人だが、コアバンキング領域では米国コミュニティバンク・信用組合に特化したNCR Voyix Digital Bankingを提供する。スタンドアロンのコアというより、他社コアと統合するデジタルチャネル+ミドルウェア寄りだ。

Finastraは英米合併で生まれた巨人だ。Fusion Bankingはコアバンキング系列で、Fusion Essence(中小)、Fusion Phoenix(米国信用組合)、Fusion Equation(グローバル大手)など市場別の製品群を持つ。とくに**貿易金融(trade finance)**と**シンジケートローン(syndicated loans)**領域で強い。

| ベンダー | 主要ターゲット | 強み | 弱み |

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

8. Infosys Finacle・TCS BaNCS — インド発のグローバルコア

インドのITサービス2大巨人が作ったコアバンキング製品が、グローバル市場の一角を占める。

**Infosys Finacle**は1995年発売で、100か国・1億人超の顧客口座を処理する。インド国営銀行(SBI)、英RBS、豪ANZのような大手銀行が利用。Java/Oracleベースで始まり、近年Finacle 11Jでクラウドネイティブ化を進めている。とくにインドネシア・フィリピン・アフリカなどの新興市場でシェアが高い。

**TCS BaNCS**はTata Consultancy Servicesの製品で、コアバンキングだけでなく資本市場・保険・年金まで網羅する総合金融プラットフォーム。State Bank of India、日本のSBI、カナダのBank of Montrealといった大口顧客を持つ。**日本市場ではSMBC・SBIなどがBaNCSを採用**しており、韓国でも検討対象として頻繁に挙がる。

Finacleインターネットバンキングコンポーネントのヘルスチェック (例)

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

応答

{

"status": "UP",

"components": {

"coreEngine": "UP",

"ledger": "UP",

"paymentGateway": "UP",

"loanModule": "UP"

},

"version": "11J.1.0"

}

インド製コアの強みは**価格競争力**と**新興市場適合性**だ。価格はTemenosの半分以下で、外注人材プールが豊富(インドITサービス企業の従業員数十万人)。弱みはUI/UXの洗練度が低く、先進国市場ではTemenos・Mambuに押されること。

9. Avaloq・SAP for Banking・Oracle Banking — 欧州とERP巨人勢

**Avaloq**はスイス本社で**プライベートバンキング・資産運用(wealth management)**に特化したコアだ。UBS・Credit Suisse・Julius Baerといったスイスのプライベートバンクが主要顧客。一般リテール銀行ではなく、資産1億ドル以上の超富裕層(HNWI)管理に最適化されている。2020年にNECに買収され、日本市場進出も加速中。

**SAP for Banking**はERP巨人SAPのコアバンキング系列だ。SAPの強みは**会計・財務モジュールとの統合**で、銀行を1つの企業として見ればERPとコアを同時に解決する価値がある。ただ発売後の市場浸透が遅く、2020年代に入り後退気味だ。

**Oracle Banking**(旧i-flex/Flexcube)はOracle DBの強みの上に作ったコアだ。すでにOracle DBを使っている銀行にとって自然な選択。Flexcubeはインド・中東・東南アジアで強く、韓国では外資系銀行支店が主に使っている。

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

10. 韓国の次世代IT — KB ACE-Bank・新韓SOL・ウリィ・ハナ

韓国の銀行ITは独特の生態系だ。**ベンダーコアをそのまま使わず、SI会社(サムスンSDS・LG CNS・SK C&C・KBデータシステム等)がほぼゼロから作る。**そのため同じ韓国5大銀行でもコアアーキテクチャがそれぞれ異なる。

| 銀行 | 次世代プロジェクト | 主要SI | 期間 | 規模 |

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

| ウリィ銀行 | WIN | ウリィFIS | 2020~2025 | `$300M+` |

**KB ACE-Bank**は韓国で最大規模の次世代ITプロジェクトで、メインフレーム(IBM z/OS)からx86分散システム(Linux + Java + Oracle/Tibero)へ移行する。マイクロサービスに分解し、Kafkaベースのイベントストリーミングを導入。2026年稼働目標。

**新韓SOL**はモバイルアプリのブランド名であり、次世代システム名でもある。新韓銀行は2021年に次世代を稼働させ、その上にSOLというスーパーアプリを構築した。韓国銀行アプリの中で使いやすさ・トラフィックともにトップクラス。

韓国銀行ITの特徴:

- **自社開発比率が高い** — Temenos・Mambuのような商用コアをそのまま使わない

- **金融決済院(KFTC)依存が大きい** — 他行振込・リアルタイム送金がKFTC網を通過

- **金融監督院のセキュリティ規制が厳格** — 網分離・認証など韓国特有の規制

11. サムスンSDS Nexledger・Brityと韓国金融ブロックチェーン

韓国金融ITで欠かせないのが、サムスンSDSの**Nexledger**(ブロックチェーン基盤)と**Brity**シリーズ(AI/自動化)だ。

**Nexledger**はサムスンSDS自社開発のエンタープライズブロックチェーンで、新韓・ハナのデジタル資産・書類認証・KYC領域に導入された。コアバンキングそのものではないが、コアと連携する周辺インフラとして韓国金融IT地図の一翼を担う。

**Brity Works・Brity Assistant**といった自動化ツールは銀行コールセンターや社内業務自動化に使われる。次世代ITプロジェクトはこうした自動化ツールをコアと統合する方向で進んでいる。

韓国次世代ITの典型的アーキテクチャ (簡略化)

core_ledger:

language: Java

framework: Spring Boot

database: Oracle / Tibero

message_queue: IBM MQ → Kafka (移行中)

deployment: Linux on x86 (メインフレーム脱却)

channels:

mobile: React Native / Flutter

internet_banking: React + Spring

atm: 自社端末 (Diebold Nixdorf / Wincor)

external_integration:

kftc: 金融決済院網 (他行振込)

bok_wire: 韓国銀行 BOK-Wire+ (大口決済)

cls: CLS Bank (外為)

swift: SWIFT (国際送金)

security:

network_segregation: 網分離 (インターネット網 ↔ 業務網)

authentication: 共同認証書 / 金融認証書 / 生体認証

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

12. 日本の全銀システム — 60年続く決済インフラ

日本のコアバンキングは韓国とも異なる独特の生態系だ。**全銀システム(全国銀行データ通信システム)**は1973年に稼働して60年目に入る日本の銀行間決済インフラだ。全国銀行協会(全銀協)が運営し、NTTデータがシステムを担う。1日1,300万件以上の取引を処理する。

全銀システムの核は**BANCS(Banking Application Network for Communication Services)**というNTTデータのプラットフォームだ。メインフレームベースで、2020年代後半に第8世代システムへ移行中。

全銀システムのデータフロー (簡略化)

銀行A (送金依頼)

↓ 全銀プロトコル (専用線)

全銀システムセンター (NTTデータ運営、東京/大阪の二重化)

↓ 差額決済 (日銀当座預金)

銀行B (受取)

処理時間: 営業時間内はリアルタイム / 営業時間外は翌営業日

日本のメガバンク3行(三菱UFJ・三井住友・みずほ)もそれぞれ異なるコアを使う。

| 銀行 | コアシステム | 主要SI | 特徴 |

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

とくに**みずほMINORI**は2018年稼働後、2021年2~3月に大規模なATM障害を起こし社会問題化した。合併3行のコアシステム統合があまりにも複雑だった結果と分析される。日本の金融庁(FSA)が直接介入する事態となった。

13. 日本のコアバンキングベンダー — NEC OperaMaster・NTT BeSTA

日本市場はグローバルベンダーよりも日本製コアが優勢だ。

**NEC OperaMaster**は日本の地方銀行・信用金庫向けコアで、100社以上の日本金融機関が導入している。日本の会計・税務・金融庁報告に最適化されている。

**NTTデータ BeSTA**(Best-fit Standard banking Application)は日本の地方銀行の80%以上が利用する事実上の標準だ。メインフレームベースからクラウドへの移行を進めており、2024年リリースの**OpenCanvas BeSTA Cloud**がその成果物。

NTTデータ BeSTA Cloudのアーキテクチャ (公開資料ベース)

プレゼンテーション層

- モバイル/Webチャネル → APIゲートウェイ

サービス層

- 勘定サービス、与信サービス、受信サービス (マイクロサービス化)

ドメイン層

- 台帳(ledger)コア (メインフレームから段階的移行)

インフラ層

- NTTデータプライベートクラウド (OpenCanvas)

- Kubernetes + PostgreSQL + Kafka

日本コアバンキングの特徴:

- **合意制の意思決定**で変更が遅い — 1機能追加に1~2年

- **障害に対し極めて保守的** — みずほ事案の影響

- **外注依存度が非常に高い** — 銀行内ITが少なく、NTTデータ・NEC・富士通・日立の4大SIに依存

- **クラウド移行が韓国より遅い** — 金融庁ガイドラインが保守的

14. マイクロサービス分解 — モノリスコアをどう切り分けるか

伝統的コアは巨大なモノリスだ。1行変更するために全体を再コンパイル・再テストしなければならない。クラウドネイティブコアはこれをマイクロサービスに分解する — どうやって?

ドメイン駆動設計(DDD)の観点からコアバンキングの自然な境界はこうなる。

1. **顧客(Customer)**: KYC・口座名義管理

2. **勘定(Account)**: 開設・解約・基本情報

3. **台帳(Ledger)**: 全取引の借方/貸方記録(単一の真実の源泉)

4. **与信(Loan)**: 融資商品・審査・返済

5. **受信(Deposit)**: 預金商品・利息

6. **決済(Payment)**: 送金・振込・請求

7. **カード(Card)**: デビット・クレジットカードの発行・承認

8. **外為(FX)**: 両替・国際送金

各ドメインが独立サービスとなり、REST/gRPCで通信する。中核原則は**各サービスが自前のDBを持つ(Database per Service)**。

マイクロサービス分解されたコアバンキング (簡略化トポロジ)

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

難しいのは**分散トランザクション**だ。1件の送金は出金(account-service) + 台帳記録(ledger-service) + 受取側入金(account-service)を伴うが、どれか1段階が失敗したら? 従来コアは2PC(2フェーズコミット)で解決していたが、マイクロサービスでは**Sagaパターン**が標準だ — 各段階を補償可能な単位に分け、失敗時に補償トランザクションを発行する。

15. イベントソーシングとCQRS — 台帳の新パラダイム

台帳(ledger)はコアバンキングの心臓だ。「今の残高はいくらか」ではなく、**「この口座に起こった全イベントの履歴」**こそが本質である。この観点に最も合うパターンが**イベントソーシング(Event Sourcing)**だ。

従来コアは残高を1行に保存する。

-- 従来の残高テーブル

account_balances (account_id, balance, updated_at)

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

-- 送金後

1001 90000 2026-05-25 10:30:00 -- 以前の残高は消える

イベントソーシングは**全イベント**を保存する。

-- イベントストア

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

-- 現在残高 = 全イベントの合計 = 90000

利点:

- **監査証跡が自動** — 全変更が永久保存される

- **バグからの復旧が可能** — 誤った取引を補償イベントで訂正

- **CQRSと自然に結合** — 複数の読み取りモデルを作れる

CQRS(Command Query Responsibility Segregation)は書き込みと読み取りを分離する。書き込みはイベントを追記し、読み取りはイベントから作った様々なビュー(残高・取引履歴・税務報告用など)を見る。

イベントソーシング + CQRSの流れ

1. Command: 口座1001から$10000を引き出す

2. Event Store: イベント追加 (Withdrew, 10000, 2026-05-25T10:30)

3. Event Bus: イベント発行

4. Read Model 1 (残高ビュー): 残高 -10000 更新

5. Read Model 2 (取引履歴): 履歴追加

6. Read Model 3 (税務レポート): 税務集計更新

Thought Machine Vaultはこのパターンの好例だ。全取引がPostingというイベントとして永続記録され、残高は派生した読み取りモデルになる。

16. リアルタイムvsバッチ — RTGSとEODの共存

コアバンキングの処理モデルには**リアルタイム**と**バッチ**の2軸がある。

**バッチ(EOD, end-of-day)**: 営業時間終了後にその日の取引を集計して締める。利息計算・税務集計・日計表生成がここに入る。メインフレーム時代の標準モデルで、いまも会計上の日次締めは必要だ。

**リアルタイム(RTGS, Real-Time Gross Settlement)**: 取引発生と同時に双方の口座が更新され決済網に反映される。24/7運用。カカオバンク・N26のようなデジタルバンクは最初からこのモデル。

| 観点 | バッチ(EOD) | リアルタイム(RTGS) |

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

| 処理単位 | 1日分まとめて1回 | 取引ごとに即時 |

| 結果可視化 | 翌朝 | 数秒以内 |

| インフラ | メインフレーム + DB2 | Kafka + マイクロサービス |

| 障害影響 | 締め遅延 | 即時にユーザー影響 |

| 運用時間 | 営業時間 | 24/7 |

韓国はすでに**2001年からリアルタイム送金**を標準化している(金融決済院網)。この点で韓国は世界で最も進んだ決済インフラの1つだ。日本は全銀システムがリアルタイムだが、営業時間外は翌営業日処理で保守的。欧州はSEPA Instant Credit Transferが標準化され、米国は2023年にFedNowが稼働した後発組だ。

17. 韓国の決済インフラ — 金融決済院・BOK-Wire+・オープンバンキング

韓国の決済網の構造を整理する。

- **金融決済院(KFTC)**: 銀行間の小口決済網。他行振込・リアルタイム送金はここを通る。1986年設立。

- **BOK-Wire+**: 韓国銀行が運営する大口決済網。RTGS方式。一般利用者は直接触れないが、`1,000,000,000`ウォン以上の大口はここを通る。

- **オープンバンキング(2019~)**: フィンテックが全銀行口座にAPIアクセス可能。Toss・KakaoPayといったフィンテック爆発のインフラ。

- **マイデータ(2022~)**: 金融情報統合照会。本人の全金融データを一箇所にまとめる。

韓国オープンバンキングのデータフロー (簡略化)

ユーザー → フィンテックアプリ(Toss等)

↓ 認証/同意

フィンテック → 金融決済院オープンバンキングAPI

↓ 各銀行コアを呼び出し

銀行 (KB・新韓・ウリィなど) → 残高・取引履歴を応答

↓

ユーザーに統合画面を提供

このインフラのおかげで韓国は**世界で最もフィンテックフレンドリーな市場**の1つとなった。Toss・KakaoBank・Naver Payが短期間で市場を席巻した背景だ。

18. 日本の決済インフラ — Zengin・BOJ-NET・コード決済の後発組

日本の決済網は2軸だ。

- **全銀システム(Zengin)**: 銀行間小口決済。1973年稼働。

- **BOJ-NET**: 日本銀行の大口決済網。韓国のBOK-Wire+に相当。

コード決済(QR・バーコード決済)は**PayPay・LINE Pay・楽天Pay**などがあるが、韓中に比べ普及が遅かった。日本は現金利用比率がいまも高い(2024年時点で約35%、OECD平均より高い)。

2023年に全銀システムで大規模障害があった — システム更改作業中の8月に数日間、他行振込が止まり日本社会全体に影響。60年続いたインフラの限界が露呈した事案だ。これを受けNTTデータがクラウド移行加速を発表した。

19. ネオバンクのコア選択 — Chime・Monzo・N26・Revolut

ネオバンク(neobank)は店舗を持たずモバイルだけで運営するデジタル銀行だ。彼らがどのコアを選んだかを見ると、コアバンキング市場のトレンドが見える。

| ネオバンク | 本社 | コア | 利用者数(2025) |

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

| Chime | 米国 | Galileo (Stripe子会社) + 自社 | 30M+ |

| Monzo | 英国 | 自社開発(Go・Kubernetes) | 11M+ |

| Revolut | 英国 | 自社開発 | 50M+ |

| N26 | ドイツ | Mambu | 8M+ |

| カカオバンク | 韓国 | 自社 + LG CNS | 25M+ |

| トスバンク | 韓国 | 自社 | 10M+ |

興味深い点: **大半のネオバンクは自前コアを作った**。MambuのようなSaaSを使ったのはN26・86 400のように素早く市場参入したケース。規模が大きくなれば結局自社開発に移るか、深いカスタマイズを行う。

理由は**差別化**だ。標準コアでは標準商品しか作れず、標準商品では競合との差別化が難しい。だから規模の大きいデジタル銀行ほど自社開発比率が高くなる。

韓国カカオバンクはLG CNSがコアを作ったが、その上の全商品ロジックとチャネルはカカオバンク自社エンジニアが書いた。トスバンクは最初から自社コアでスタート。

20. コア移行戦略 — Strangler Figパターン

レガシーコアをクラウドネイティブに移すのは**数年がかりのプロジェクト**だ。「一晩で入れ替え」は不可能。だから**Strangler Figパターン**(Martin Fowler命名)が標準になる。

要点は**レガシーを殺さず、新システムが段階的に機能を吸収する**ことだ。宿主の木をゆっくり包んで枯らすイチジクの蔓のように。

Strangler Fig移行のフェーズ

Phase 1 (1~2年):

- 新システムの前にfacade(ルーター)を配置

- 全リクエストがfacadeを経由

- facadeが100%レガシーへルーティング

- 既存挙動に変化なし

Phase 2 (2~3年):

- 非中核モジュールから新システムへ移行 (例: レポート・統計)

- facadeが一部を新、一部を旧へルーティング

- データは双方向同期

Phase 3 (3~5年):

- 中核モジュール移行 (勘定・台帳)

- デュアルライト(dual write) → 比較検証

- 段階的に新システム比率を拡大

Phase 4 (5年以降):

- レガシーを段階的に廃止

- facadeを除去または簡素化

- メインフレーム廃止

この過程で要は**データ整合性**だ。両システムを並行稼働させると残高がずれる危険がある。多くの銀行が一定期間両方に書き込み、毎日reconciliation(突合)を回す。

韓国KB ACE-Bankはまさにこのパターンだ。2021年開始、段階的にモジュール移行中で、2026年全面稼働目標。

21. 規制とコンプライアンス — コアが背負う重み

コアバンキングは技術以上の領域だ。**規制遵守**が半分を占める。

グローバル主要規制:

- **Basel III/IV**: 自己資本適切性・流動性比率

- **AML/CFT**: マネーロンダリング防止・テロ資金供与防止

- **KYC**: 顧客確認

- **GDPR**: 個人情報保護(欧州)

- **PCI DSS**: カード情報保護

韓国固有:

- **金融監督院(FSS) 電子金融監督規定**

- **個人情報保護法(PIPA)**: GDPR類似

- **信用情報法**: 信用情報処理制限

- **網分離**: インターネット網と業務網の物理分離

日本固有:

- **金融庁(FSA) 総合監督指針**

- **個人情報保護法(APPI)**

- **マイナンバー**処理規制

コアバンキングベンダー選定では**こうした規制対応の充実度**が中核評価項目になる。Mambu・Thought Machineのような新興クラウドベンダーは新興市場への参入は早いが、韓日のような保守的規制市場では検証に時間を要する。

22. コストモデル — ライセンス・SaaS・自社開発

コアバンキング導入コストは大きく3モデル。

**1. 永続ライセンス(perpetual license)**: 伝統モデル。ライセンス一括購入 + 年間保守(20~25%)。Temenos・FIS・Finastraがこのモデル。初期費用`$10M`~`$300M`、毎年保守`$2M`~`$50M`。クラウドSaaSへ移行中。

**2. SaaS/サブスク**: Mambu・Thought Machine。ユーザー数・トランザクション数ベースの月次/年次課金。初期参入コストは低く、運用コストはトラフィック比例。

**3. 自社開発**: 韓中の大手銀行・ネオバンク。初期投資`$100M`~`$500M`、人員数百~数千人。長期的には柔軟性最大だがリスクも最大。

| モデル | 初期コスト | 運用コスト | 柔軟性 | リスク |

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

| SaaS | 低い | 変動 | 中下 | 値上げ |

23. コアバンキングの未来 — AI・ブロックチェーン・CBDC

2026年のコアバンキングが向かう方向。

**1. AI統合**: LLMを活用した顧客応対・不正取引検知・与信スコアリング。コアの上にAIレイヤが乗る形。韓国のKB・新韓が積極的。

**2. ブロックチェーン/DLT統合**: 分散台帳が伝統台帳を補完。SWIFTを代替する国境間決済(JP Morgan Onyx・Partior)から始まる。韓国サムスンSDS Nexledgerも同じ流れ。

**3. 中央銀行デジタル通貨(CBDC)**: 各国中央銀行がデジタル通貨を試験運用。中国e-CNYが最も進んでおり、韓国銀行も2024年からパイロットを実施。CBDCが稼働するとコアバンキングは中央銀行システムとの直接接続が必要になる。

**4. 組み込み型バンキング(embedded banking)**: コアバンキングAPIが非銀行アプリ(タクシー・コマース・SaaS)に直接統合。BaaS(Banking-as-a-Service)の本格化。Mambu・Solaris・Treasury Primeがこの市場。

**5. 耐量子暗号**: 2030年代に量子コンピュータがRSAを破る懸念。コアバンキングの暗号インフラがPQC(post-quantum cryptography)へ移行開始。

24. まとめ — 本稿の次に何を読むか

コアバンキングシステムは銀行の心臓だ。1970年代IBMメインフレーム上のCOBOLが、2026年にはKubernetes上のJava/Kotlin/Pythonに生まれ変わる。Temenos・Mambu・Thought Machine・FIS・NCR・Finastra・Finacle・BaNCS・Avaloq・SAP・Oracle — 11のグローバルベンダーがそれぞれ異なる市場と異なる価値を持つ。韓国はSI会社が作る自社コアが強く、日本はNTTデータ・NECが作る日本製コアが優勢だ。

要点は**「何を買うか」ではなく「なぜ変えるか」**である。メインフレームは信頼性が検証された資産であり、クラウドは速度とコスト効率の機会だ。結局答えは**ハイブリッド**であり、5~10年がかりの段階的移行が現実だ。

次に読むべきトピック:

- 決済システム全般(SWIFT・SEPA・FedNow・全銀)

- BaaS(Banking-as-a-Service)市場

- CBDCとデジタル資産

- 韓国フィンテック生態系(Toss・KakaoBank・Naver Pay)

- 日本メガバンクIT統制

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国民銀行 ACE-Bank 次世代IT プレス — `https://www.kbstar.com/`

- 新韓銀行 The New 新韓 — `https://www.shinhan.com/`

- サムスンSDS Nexledger — `https://www.samsungsds.com/kr/blockchain/nexledger.html`

- 金融決済院(KFTC) オープンバンキング — `https://www.kftc.or.kr/`

- 韓国銀行 BOK-Wire+ — `https://www.bok.or.kr/`

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

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

- 全国銀行協会全銀システム — `https://www.zenginkyo.or.jp/`

- 日本銀行 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`