銀行エンジニアリング 05：銀行内振込と銀行間振込（ClearingとSettlement）
同じ「振込」でも、相手が同じ銀行か他の銀行かで、銀行の中で起きることはまったく違います。MiniBank v9の架空の他行為替Simulatorで、送金指図から決済までを追います。
v8以降に実装した台帳・記帳エンジンなどを実際に動かし、正常時と異常時の両方から銀行システムの構造を学ぶ。
Prerequisite: BANKING SYSTEMLEARNING GOALS
このページで学ぶこと
- 仕向銀行・被仕向銀行・決済システムの役割
- Clearing（清算）とSettlement（決済）の違い
- 他行宛送金で動く勘定（未決済送金・中央銀行当座預金）
PLAIN LANGUAGE
まず、ここだけつかむ
他行宛の振込は、MiniBankの台帳だけでは完結せず、決済システムと相手の銀行が関わります。
資金確保で顧客預金を未決済送金へ移し、決済で中央銀行当座預金から支払います。
MiniBank v9の相手は架空の3銀行だけで、実在のネットワークには接続しません。
DIFFICULT PARTS, STEP BY STEP
難しいポイントを、順番にほどく
専門用語を覚えることより、「なぜ必要か」「このシステムのどこで使うか」を理解することが目標です。
Clearing（清算）
支払を受け付け、受理・拒否を判定し、受け渡し額を整理することです。
多数の銀行の支払をまとめて処理するためです。
架空のSimulator（interbank.clearing_records）。
Settlement（決済）
銀行どうしで最終的に資金を移すことです。
受理しただけでは資金はまだ移っていないためです。
interbank.run_settlement()。中央銀行当座預金（架空）から支払います。
未決済送金
顧客から預かり、まだ他行へ渡していないお金です。
受付から決済までの間の義務を正しく表すためです。
INTERBANK_OUTBOUND_PENDING（負債）。
Level 1 基礎：なぜ他行宛は難しいのか
同じ銀行内の振込は、1冊の台帳の中で「Aさんへの返還義務を減らしBさんへの返還義務を増やす」だけで完結します。相手が別の銀行だと、MiniBankの台帳だけでは完結しません。相手の銀行にお金を届け、銀行どうしで資金を受け渡す必要があります。
| 登場人物 | 役割 | MiniBank v9での姿 |
|---|---|---|
| 仕向銀行（Sending Bank） | 送金を依頼された銀行 | MiniBank |
| Payment Gateway | 銀行から決済システムへ電文を送る窓口 | interbank.send()・interbank.messages |
| 決済システム（Clearing） | 支払を受け付け、受理・拒否を判定し、銀行間の受け渡し額を整理する | 架空のSimulator（interbank.clearing_records） |
| Settlement | 銀行間で最終的に資金を移すこと | interbank.run_settlement() |
| 被仕向銀行（Receiving Bank） | 受取人の口座を持つ銀行 | 架空の3行（interbank.participants） |
Level 2 銀行業務：MiniBankから架空銀行へ2万円を送る
- 01送金指図の受付（CREATED）
- 02資金確保（AUTHORIZED：顧客預金→未決済送金、手数料330円）
- 03決済システムへ送信（SENT）
- 04受理（ACCEPTED）
- 05決済（SETTLED：未決済送金→中央銀行当座預金から支払）
| 段階 | 借方 | 貸方 | 意味 |
|---|---|---|---|
| 資金確保 | 顧客預金 20,330 | 未決済送金 20,000 / 手数料収益 330 | 顧客からは引き落とすが、まだ他行へは払っていない |
| 決済 | 未決済送金 20,000 | 中央銀行当座預金 20,000 | 銀行どうしの資金が動き、支払義務が消える |
Level 3 システム：MiniBankでの実装（正常時）
- 受付と資金確保は同じトランザクション。残高不足なら支払は REJECTED（INSUFFICIENT_FUNDS）として記録され、仕訳は1行も作られない
- お金の動きはすべて v8 Posting Engine のイベント（INTERBANK_OUTBOUND_AUTHORIZE / INTERBANK_OUTBOUND_SETTLE）で記帳される
- 支払ごとに end_to_end_id を持ち、MiniBankと決済システムはこの番号で同じ支払を指す
- 架空の参加行は3つ：さくら架空銀行（NORMAL）、あおば架空信用金庫（STRICT）、ひかり架空銀行（SLOW）。挙動は口座番号の末尾で決まり、画面から意図的に選ぶこともできる
異常時：受取銀行に口座がない
| 段階 | 内容 |
|---|---|
| 症状 | 送信直後に REJECTED（ACCOUNT_NOT_FOUND）になった |
| 調査 | 支払詳細の電文一覧で、決済システムからの STATUS_REPORT に拒否理由があるか確認する |
| 対応 | 資金確保のイベントを v8 の取消仕訳で打ち消し、送金額と手数料を顧客預金へ戻す（refund_event_id に記録） |
| 再発防止 | 受付前の口座確認は将来の課題。v9 のSimulatorには口座確認機能はない |
Level 4 アーキテクチャ：2つの帳簿がある
銀行間振込では、MiniBankの台帳と決済システムの記録という、別々の2つの帳簿が同じ支払を記録します。どちらかが知らない状態が必ず起こり得るため、支払の状態管理・照会・照合が設計の中心になります。v9の画面が「MiniBank側」と「Simulator側」を並べて表示するのはこのためです。
どこを確認すればよいか
- 管理画面「他行為替 Simulator」：支払一覧・決済バッチ・決済システムとの差異
- 支払詳細：状態遷移・電文・Simulator側の記録・記帳
CHECK YOUR UNDERSTANDING
3問で理解チェック
答えを頭の中で考えてから、各項目を開いて確認してください。
Q1同一銀行内の振込で中央銀行当座預金は動きますか？
動きません。銀行間の決済がないためです。
Q2資金確保の時点で、他行へお金は渡っていますか？
渡っていません。未決済送金として銀行内に残っています。
Q3v9の相手銀行は実在しますか？
いいえ。架空の3行だけです。
完全に暗記する必要はありません。大切な考え方を説明できそうなら押してください。
SOURCE TRAIL
根拠と関連教材
CURRENT IMPLEMENTATIONは確認したrepository内の実装です。HISTORICAL IMPLEMENTATIONは導入・修正の履歴で、後続migrationによる再定義があり得ます。RELATED LESSONは教材への案内で、実装の一次Sourceではありません。ASSUMPTIONは仮定、UNKNOWNは未確認を表します。
確認基点: d02eae8914f39cbf06bfe422dc39c71886f82b3e / 2026-09-11。稼働環境への適用確認: UNKNOWN。パス実在の自動検査と、記述した技術的事実の確認は別です。
Implementation Status: IMPLEMENTED IN MINIBANK（この教材が扱うコードの範囲）
- RELATED LESSON/docs/be-ledger-foundation同一銀行内の振込の仕訳
- RELATED LESSON/docs/real-banking本物の銀行システム
- CURRENT IMPLEMENTATION
supabase/migrations/20260924110000_v9_interbank_simulator.sqlinterbank.submit / interbank.send受付・資金確保・送信 - CURRENT IMPLEMENTATION
supabase/migrations/20260924110000_v9_interbank_simulator.sqlinterbank.sim_rules / interbank.sim_clearing_receive架空の決済システムの判定と重複排除 - CURRENT IMPLEMENTATION
supabase/migrations/20260924110000_v9_interbank_simulator.sqlinterbank.apply_return返却（支払ごとのサブトランザクション） - CURRENT IMPLEMENTATION
supabase/migrations/20260930130000_v17_reliability.sqlinterbank.run_settlement決済バッチ（支払ごとのサブトランザクション。v17で、書込停止中は部分失敗として記録せず RY001 で止める）