MiniBankv13CORE BANKING / ACCOUNTING / SECURITY / OPERATIONS
画面個人口座、法人口座、振込、権限管理、MFA。
裏側その先にある、仕訳、GL、照合、締め処理、AML、運用、Treasury / ALMまで。
MiniBank v13は、銀行らしい画面を再現したデモではありません。
1件の取引が、認証され、権限を確認され、記帳され、残高へ反映され、仕訳となり、GLへつながり、照合され、運用される。
その一連の仕組みを、実際に動くシステムとして積み上げてきた個人開発プロジェクトです。
Finance × Engineering × AI Development経理・財務の視点から、AIとともに銀行システムを13世代にわたって拡張してきた。
WHAT MINIBANK DOES10 operations
見えるのは銀行画面。つくったのは、
MiniBankは学習・研究・検証用のシミュレーションです。実際の預金を受け入れたり、実資金を送金したりする銀行サービスではありません。
MiniBank System Overview
利用者が見る画面から、その裏側にある認証、権限、取引制御、台帳、仕訳、銀行間決済、会計、AML、日次運用、障害対応、資金管理まで。
さらに、それらを読み解くArchitectureとAcademyまで。
CHANNEL
BANK CORE
OPERATE
UNDERSTAND
PERSONAL BANKINGv1–v2個人向け銀行利用者登録・ログイン本人確認申請・KYC審査口座開設・凍結・解除・利用停止普通預金・入出金履歴振込先登録・振込MFA / TOTP定期預金章 01–03 CORPORATE BANKINGv3–v5法人向け銀行法人口座・法人メンバーRole / PermissionMaker / Checker指定日支払重要設定変更の二者確認法人全体の日次上限章 04–07 LEDGER / POSTINGv8台帳・記帳基盤Business EventPosting RuleJournal EntryLedger逆仕訳Integrity Check章 10–11 / 17–18 INTERBANK PAYMENTv9銀行間決済Participant BankClearingSettlement中央銀行預け金RESULT_UNKNOWN の照会章 19–21 BANK ACCOUNTINGv10銀行会計・決算General LedgerTrial BalanceBalance SheetProfit & Loss補助元帳照合日次・月次締め章 22–24 AMLv11不正・AMLScanAlertCaseInvestigationEvidenceDecision章 25–26 OPERATIONS CENTERv6–v7 / v12日次運用・障害対応論理営業日・EOD / BODReconciliation調査案件・復旧Backup / RestoreSystem StatusException / Approval QueueTrace・Incident・Runbook章 12–16 / 27–29 TREASURY / ALMv13資金繰り・ALM預金流出シナリオ必要調達額・調達コストInterest Rate ShockNIIWhat-ifGL → ALM → Posting章 30–34 ARCHITECTURE構造と責任分界Customer / Corporate / Admin UINext.js / TypeScriptPostgREST / Business RPCPostgreSQL Business LogicJava / Spring Boot Payment Service章 38–40 MINIBANK ACADEMY学習コンテンツ9 Courses107 LessonsBank Engineering 29 Lessons6 Labs章 41–46 TRANSACTION INTEGRITYIdempotencyConcurrencyRESULT_UNKNOWNReversalIntegrity Check全領域を横断SECURITY & CONTROL認証認可RLSDatabase PrivilegeRPCFail ClosedMFAMaker / Checker監査記録全領域を横断送金ボタンを押した。
画面に「成功」と表示された。
それだけで、本当に銀行システムは完成なのでしょうか。
MiniBankが作ってきたのは、
こうした「画面の先にある問題」を扱う仕組みです。
PART ICustomer Banking
MiniBankには、利用者として銀行を体験するための機能があります。
しかし、残高を表示するだけの銀行デモではありません。
利用者が行った操作が、その後の取引記録や台帳までつながることを重視しています。
は、それぞれ別の条件です。
画面を開けたからといって、金融取引まで許可されるわけではありません。
利用者に見える残高と、その裏側の銀行の記録をつなげます。
ここでも「送る」だけでは終わりません。
金融更新の前に確認すること
これらを確認してから金融更新へ進みます。
MiniBankでは、振込認可にTOTPを利用したMFAフローを組み込んでいます。
単に入力欄に6桁の数字を入れているだけではありません。
認証と金融取引を分けて考える。
その考え方まで含めて実装しています。
実在銀行の本人認証方式を完全に再現するものではありません。
MiniBankでは定期預金も扱います。
「定期預金残高」という数字を画面へ表示するだけではありません。
普通預金から定期預金へ資金が移れば、銀行の内部記録も変わる。
満期になれば元本と利息が動く。
利用者の商品状態と、銀行側の会計をつなげます。
利息計算は学習用の簡略化されたモデルです。
PART IICorporate Banking
個人向け銀行機能に会社名を付けただけではありません。
法人では、「会社」と「操作する人」を分けます。
口座の所有者は法人。
操作するのは、それぞれのユーザーIDを持った担当者です。
法人ユーザーの役割は、実装上4つです。
役割によって操作できる機能を分けます。
同じ法人に所属しているからといって、全員が同じ操作をできるわけではありません。
BANK SIDE — 法人Roleとは別
銀行側の担当者は、法人のRoleとは別に、銀行の管理者Role（オペレーター／管理責任者）として扱います。
法人支払では、申請・承認・実行を分離します。
銀行システムだけでなく、
企業内部統制の考え方
まで扱っています。
指定日付きの支払依頼も扱います。
申請日。指定日。実行日。この3つを分けます。
指定日前なら実行を拒否する。
指定日を過ぎてから実行したなら、実際に実行された日を記録する。
そして、指定日になったからといって無条件に送金するわけではありません。
実行時にも、
などを確認します。
自動振込サービスではなく、学習用の指定日支払フローです。
MiniBankでは、支払いだけでなく、
こうした操作にも二者確認の考え方を入れています。
法人全体の日次上限も、口座や担当者を分けるだけで簡単に回避できないように扱います。
PART IIITransaction Integrity
Idempotency・Concurrency・RESULT_UNKNOWN・逆仕訳・Ledger。
金融システムでは、
「ボタンを二回押した」
「通信が切れて再送した」
だけで二重送金になってはいけません。
MiniBankでは、依頼を識別するキーを使います。
同じ依頼が再び届いたとき、
二つの処理が同じ古い残高を読み、
それぞれが勝手に引き落としたら、
残高は壊れます。
そのためMiniBankでは、
重要な金融更新をデータベース側で制御します。
これらをバラバラに更新するのではなく、必要な単位で整合させます。
これはMiniBankで特に重視している考え方です。
このとき、
「失敗したから、もう一度送ろう」
と考えると、
二重送金になる可能性があります。
そこでMiniBankでは、
を区別します。
結果が分からなければ、
金融システムでは、
「分からない状態」を正しく扱うこと自体が機能です。
銀行の帳簿で、
都合の悪い取引を削除してしまったら、
何が起きたのか後から分からなくなります。
MiniBankでは、訂正が必要な場合、
元の仕訳を残したうえで、
反対方向の仕訳を追加する
逆仕訳
を扱います。
| 記録 | 借方 | 貸方 | 扱い |
|---|---|---|---|
| 元の仕訳 | 勘定 X | 勘定 Y | 残す |
| 逆仕訳 | 勘定 Y | 勘定 X | 追加（反対方向） |
何が起きたのかを後から追えることを重視します。
MiniBankは、
口座テーブルの残高数字だけを増減させるアプリではありません。
取引の裏側には、
銀行側の台帳があります。
顧客に見えるお金の動きと、銀行側の会計をつなぐ。
ここは、経理・財務の視点からMiniBankを見ると特に面白い部分です。
PART IVBusiness Day / Recovery
論理営業日・EOD / BOD・照合・調査・Backup / Restore。
MiniBankには、システムが管理する論理営業日があります。
という流れを管理します。
締め処理が始まれば、新しい金融更新を止める。
一方で、すでに依頼された取引の結果確認まで止めてしまうわけではない。
「金融取引を受け付ける時間」と「結果を確認すること」を分けます。
End of Day。Beginning of Day。
MiniBankでは、単なる日付更新ではなく、銀行業務として扱います。
必要な日次処理を確認してから締める。
問題があれば、
「なかったこと」にせず、
調査対象へ回します。
金融システムでは、
複数の場所に似た数字が存在します。
これらが一致しているか確認する。
それが照合です。
MiniBankでは、
「画面上の残高がそれっぽい」
だけで正常とは判断しません。
差異を検出したら、
それ自体を運用上の問題として扱います。
こうしたものを調査案件として扱います。
そして、
案件を「完了」にすることと、お金を動かすことを分離する。
調査画面で完了ボタンを押したからといって、
金融記録まで都合よく書き換わるわけではありません。
バックアップを復元できた。
アプリも起動した。
だから復旧完了。
……ではありません。
MiniBankでは隔離した検証環境で、
復元後のデータを照合し、
安全に金融更新を再開できる状態かを確認する考え方まで扱っています。
起動できることと、安全に再開できることを分ける。
これも金融システムの重要なテーマです。
PART Vv8 – v10 · Posting / Interbank / Accounting
v8 Ledger & Posting Engine から、v13 Treasury / ALM Simulator まで。
v8では、Ledger & Posting Engineを追加しました。
それまで各業務の中に存在していた記帳を、
より体系的な仕組みとして扱います。
つまり、Business Event → Posting Rule → Journal Entry → Ledger という流れです。
「振込処理のコードの中で仕訳を書いた」
だけではありません。
銀行取引を会計記録へ変換する仕組みそのものを、一つの基盤として扱う。
MiniBankはここで、一段階違うシステムになりました。
Posting Engineでは、
帳簿そのものの整合性も確認します。
差異を抱えたまま締め処理を完了させてしまえば、
問題を含んだ帳簿が「締めた結果」として残ってしまいます。
だから、
異常を検知したら、締め処理を完了させない。
整合性チェックで問題が見つかった日次・月次の締めは、
CLOSEDではなくBLOCKEDとして記録し、
運用者に対応を求めます。
「とりあえず締める」ではなく、
金融システムでは安全側に倒すことも重要な設計です。
v9では、Interbank Payment Simulatorを追加しました。
MiniBank内部の口座振替だけでなく、
別の銀行へ送金するケースを扱います。
MiniBankでは、この流れを学習用にシミュレーションします。
実際の銀行ネットワークへ接続するわけではありません。
しかし、
自分の銀行内だけで残高を減らせば他行送金が終わるわけではない
という重要な考え方を、動く形で扱います。
顧客Aから顧客Bへ送る。
二人が同じ銀行なら、銀行内部の帳簿で完結できます。
しかし、相手が別の銀行なら、銀行同士の決済が必要になります。
そこで登場するのが、銀行側の決済用資金です。
MiniBankでは、銀行間支払と中央銀行預け金を意識した勘定をつなぎます。
これにより、
顧客の振込
と
銀行間の資金決済
を分けて考えられます。
v9では、銀行間決済でも RESULT_UNKNOWN を重要な状態として扱います。
送信した。
しかし返答がない。
この状態で同じ決済を再送したら、
二重決済になる可能性があります。
そこで、再送ではなく照会を行います。
相手側・決済側の確定状態を確認し、
その結果に合わせてMiniBank側の状態を解決する。
実装上も、
結果不明の取引に対して安易な再送をさせず、
照会によってSETTLEDへ解決する流れを用意しています。
v10では、Bank Accounting & Closingへ進みました。
顧客が振り込んだ。定期預金を作った。利息を支払った。他行から入金があった。
それらは最後に、
銀行の会計へ集約されます。
これは会計の基本です。
しかし、
画面へ式を書くだけなら簡単です。
重要なのは、
実際の取引を積み上げた結果として、
その関係が保たれていること。
MiniBankでは、
それぞれをつなぎ、
銀行業務の結果を会計として確認します。
「会計画面があります」から、「締め処理まで動く」へ。
v10でMiniBankはそこまで広がりました。
PART VIv11 – v13 · AML / Operations / Treasury
v11 Fraud / AML Simulator・v12 Banking Operations Center・v13 Treasury / ALM Simulator。
v11では、Fraud / AML Simulatorを追加しました。
Ledgerに記録された取引を監視し、
一定のルールに該当するものを検出します。
しかし、
アラートが出たからといって、
その時点で不正と決めつけるわけではありません。
アラートと不正確定を分ける。これはAMLを扱ううえで非常に重要な考え方です。
MiniBankのAMLフローでは、
必要な調査を行わないまま、
いきなり判断しようとすると拒否される設計があります。
誤検知なら、
誤検知として完了する。
「怪しいから自動で口座凍結」
だけの単純な仕組みにしない。
検知・調査・判断・実処理を分けています。
v12では、Banking Operations Centerを追加しました。
ここでMiniBankは、
「機能を持つシステム」から
「運用するシステム」
へ進みます。
金融システムで問題が起きたとき、
ただログを眺めるだけでは判断できないことがあります。
MiniBankでは、
運用画面から原因を追跡するための情報をつなぎます。
取引を「業務の流れ」として追う。
それがOperations Centerの役割です。
MiniBankでは、
問題発生後の運用までをシステム設計の対象にしています。
v13では、Treasury / ALM Simulatorを追加しました。
ここまで来ると、
顧客向け銀行アプリという枠を大きく超えます。
銀行は、
資産と負債を見ながら、
必要な資金を確保しなければなりません。
Treasury / ALM Simulatorでは、
預金流出シナリオを設定できます。
数字で確認します。
MiniBankでは、
市場シナリオを使ったWhat-if分析を行います。
架空の銀行条件を入力し、
再現可能なシナリオとして計算します。
例えば、
さらに流出率を大きくすれば、
資金ショートが発生するケースも確認できます。
これらはMiniBankの学習用シナリオに基づく計算例であり、実在銀行の財務状況や規制指標ではありません。
v13で重要なのは、
ALM画面だけを独立して作ったのではないことです。
1件の取引を考えてみます。
一つひとつ別々のデモを作ったのではありません。
できる限り、
一つの銀行の中でつなげる。
それがMiniBankの設計思想です。
PART VIISecurity & Control
認証・認可・RLS・Database Privilege・RPC・Fail Closed・MFA・Maker / Checker・監査記録。
MiniBankでは、画面を非表示にするだけで権限管理を終わらせません。
認証。認可。RLS。データベース権限。RPC。口座状態。法人所属。法人ロール。振込限度額。Maker / Checker。MFA。監査記録。
これらを組み合わせます。
「見えない」だけではなく、「できない」。
この境界を重要視しています。
AUDIT TRAIL
金融システムでは、
結果だけではなく、
経緯をたどれること
も重要です。
MiniBankでは、
重要操作と監査記録をつなげます。
PART VIIIArchitecture
MiniBankでは、利用者画面だけでなく、システム内部の責任分界も学習対象です。
概念的には、
という関係になっています。
MiniBank Architectureでは、単に
と製品名を並べるのではありません。
その技術に、どの責任を持たせているか
を見ることを重視します。
MiniBankには、
Java / Spring BootによるPayment Serviceもあります。
Next.js / PostgreSQLだけではなく、
エンタープライズ開発で広く使われるJavaの構成からも、
銀行システムを学べます。
重要なのは、
技術が違っても、金融取引の正しさは一つ。
その考え方を共有します。
PART IXMiniBank Academy
振込ができる。
それと、振込がなぜ安全に処理できるのか説明できる。
これは違います。
MiniBank Academyは、
動いているMiniBankを教材にして、銀行業務とシステム設計をつなげて学ぶコンテンツです。
Academyは、基礎から専門領域まで広がっています。
MiniBankの全体像、基本用語、画面・API・DBの関係。
口座、決済、預金、銀行ビジネスなど。
台帳、会計、振込、認証、監査、照合。
トランザクション、並行処理、API、DB、テスト、障害対応。
Java、Spring Boot、Controller / Service / Repositoryなど。
安定稼働、品質、技術選択、金融システムの信頼性。
業務、アプリケーション、データ、技術を横断して設計する。
法人金融、企業財務、融資、コミットメントライン、シンジケートローンなど。
Posting。Interbank Payment。Bank Accounting。AML。Operations Center。Treasury / ALM。MiniBank v8〜v13で実装した銀行内部機能を、実装と結びつけて学びます。
v8〜v13既存教材を残しながら、
v8〜v13に合わせて銀行エンジニアリング教材を追加。
新しい銀行エンジニアリングには、29レッスン。6つのLab。総まとめ。を用意しています。
目的から選ぶLearning Pathは7つ。
さらに、
自分のバックグラウンドから、銀行システムへ入れます。
Labでは、
正解だけを読むのではありません。
自分ならどう判断するのか。
実装を見ながら考えます。
Academyでは、
実銀行の仕組みについても扱います。
しかし、
教材で説明していることが、
すべてMiniBankの実行機能として存在するわけではありません。
例えば、
これらを提供しているわけではありません。
を混同しない。
これもMiniBank Academyの重要な方針です。
PART XEvolution / Verification / Process
MiniBankは、
最初からこの規模だったわけではありません。
MiniBankでは、
機能追加だけでなく、
継続的に検証を行っています。
v13の検証では、
さらにRelease Candidateでは、
をローカルの検証環境で実施しました。
また、
Academy全ルート。内部リンク。管理画面。顧客画面。モバイル表示。
なども確認しています。
テスト数が多ければ安全だ、と単純に言うつもりはありません。
しかし、
「動いたから完成」ではなく、何を確認したのかを残す。
それを開発プロセスの一部にしています。
MiniBankは、
AIを活用して開発してきたプロジェクトです。
AIは大量のコードを作ることができます。
しかし、
コードが生成されたことと、
正しい銀行システムになったことは同じではありません。
だから、
を分けて進める。
AIが速いからこそ、
人間は「何を正しいとするのか」を決める。
MiniBankは、
AI時代のシステム開発そのものを学ぶプロジェクトでもあります。
MiniBankの特徴の一つは、
技術だけから銀行を見ていないことです。
これらを、
システム実装と結びつけています。
それらを横断することを目指しています。
PART XIScope
MiniBankは、
実在の銀行システムと同等ではありません。
だからこそ、
できていることと、できていないことを分けて説明します。
銀行という題材を通じて、
業務・会計・技術・運用を、
一つのシステムとしてつなげる。
それがMiniBankです。
そして、その仕組みをAcademyで学ぶ。
MiniBank v13
Banking System, built to understand.