INTERMEDIATE · 中級COURSE 09 · BANKING ENGINEERING

銀行エンジニアリング Lab 02：Payment Lab（Timeout・重複・拒否・結果不明・返却）

架空の3銀行を相手に、正常送金から結果不明・返却までを自分で起こし、状態・電文・記帳・照合がどう変わるかを観察します。

10 / 55

BANKING ENGINEERING · 銀行エンジニアリング

v8以降に実装した台帳・記帳エンジンなどを実際に動かし、正常時と異常時の両方から銀行システムの構造を学ぶ。

Prerequisite: BANKING SYSTEM

LEARNING GOALS

このページで学ぶこと

Simulatorシナリオの選び方
結果不明を照会で解消する手順
部分失敗と照合差異の読み方

PLAIN LANGUAGE

まず、ここだけつかむ

架空の3銀行とSimulatorシナリオで、正常送金から結果不明・返却までを再現します。

結果不明は照会で解消し、再送は条件を満たすまでできないことを確かめます。

各操作の後、記帳と照合がどう変わったかを確認します。

DIFFICULT PARTS, STEP BY STEP

難しいポイントを、順番にほどく

専門用語を覚えることより、「なぜ必要か」「このシステムのどこで使うか」を理解することが目標です。

Simulatorシナリオ

やさしく言うと

決済システムの振る舞いを指定する設定です。

なぜ必要？

異常を意図的に再現するためです。

Minibankでは

AUTO・ACCEPT・REJECT・TIMEOUT_THEN_ACCEPTED・TIMEOUT_THEN_REJECTED・LOST・RETURN。

Clearing Exception

やさしく言うと

MiniBankと決済システムの記録の食い違いです。

なぜ必要？

結果不明の支払を見逃さないためです。

Minibankでは

画面の「決済システムとの差異」。

決済バッチ

やさしく言うと

まとめて行う決済の1回分です。

なぜ必要？

決済結果と例外を記録として残すためです。

Minibankでは

interbank.settlement_batches（SETTLED / PARTIAL）。

準備

Lab 01 と同じローカル環境を使います。seed 実行時に中央銀行当座への資金準備と、決済済み・不成立・返却・結果不明・被仕向の支払が1件ずつ作られます。架空顧客の口座IDは .regression-local/platform-local-users.json にあります（ローカルのみ・Git管理外）。

open 'http://localhost:54336/local/login?as=operator&next=/admin/interbank'

演習

演習	操作	観察すること
1. 正常送金	相手行 9901、シナリオ AUTO で受付 → 送信 → 決済	AUTHORIZED → SENT → ACCEPTED → SETTLED、記帳2件
2. 拒否	相手行 9902、口座番号 1234560	REJECTED（ACCOUNT_NOT_FOUND）、取消仕訳で送金額と手数料が戻る
3. Timeout	相手行 9903 で受付 → 送信	TIMEOUT。詳細画面に送信ボタンはなく、照会だけが出る
4. 結果不明	「応答期限切れを結果不明へ」→「決済を実行」	バッチが PARTIAL、決済システムとの差異に1件。照会で SETTLED になり差異が消える
5. 重複	同じ内容の受付を通信エラー後に再送（フォームは同じキーを使う）	支払は1件のまま
6. 未着と再送	シナリオ LOST → 送信 → 照会を2回	resend_allowed が true になり、管理責任者だけが同じE2E IDで再送できる
7. 返却	相手行 9902、口座番号 1234569 → 送信 → 決済	SETTLED の直後に RETURNED、送金人に送金額だけ戻る

振り返り

どの操作で、どの勘定が動いたか（記帳一覧からトレースへ）
結果不明の間、顧客の預金と未決済送金はどうなっていたか
再送が許される条件を、自分の言葉で説明できるか

CHECK YOUR UNDERSTANDING

3問で理解チェック

答えを頭の中で考えてから、各項目を開いて確認してください。

Q1ひかり架空銀行（SLOW）へ送るとどうなりますか？

答え

応答がなくTIMEOUTになります（実際には多くは受理されています）。

Q2照会で差異が消えるのはなぜですか？

答え

照会で決済済みと分かり、MiniBank側も決済を記帳してSETTLEDになるからです。

Q3返却はどの状態の支払に起きますか？

答え

SETTLED（決済済み）の支払です。

ここまで読めましたか？

完全に暗記する必要はありません。大切な考え方を説明できそうなら押してください。

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-result-unknownRESULT_UNKNOWN
CURRENT IMPLEMENTATIONsrc/app/admin/(protected)/interbank/payments/[id]/page.tsxPaymentDetailPage()MiniBank側とSimulator側を並べる支払詳細画面
CURRENT IMPLEMENTATIONscripts/banking/v9-interbank.test.mjs正常・重複・拒否・Timeout・結果不明・再送・返却・部分失敗のDBテスト