本物の銀行システムで考えること

利息は商品別に実装状況を区別する

定期満期の利息は、v15以降に開いた契約では、契約時に固定した年利（interest_rate_bps）と、開始日から満期日までのJST暦日数で、利息=floor(元本×年利bps×日数÷(10,000×365))と計算します。v15より前の契約は従来の式（日数=(maturity_date−opened_at)の秒数/86400、利息=floor(元本×interest_rate_bps/10000×期間日数/365)）のままです。元本はTIME_DEPOSITS_PAYABLEの借方、正の利息はINTEREST_EXPENSEの借方、元利合計は普通預金負債の貸方です。端数切捨てで利息0なら利息行を作りません。これは満期処理のコードであり、自動batch稼働や本番適用の確認ではありません。

銀行システムは『都市』として見る

勘定系だけが銀行システムではありません。顧客接点、本人確認、融資、カード、決済、会計、risk、監査、data分析、監督報告、問い合わせ、障害対応が、多数のsystemと人を介してつながります。

すべてを同じdatabase・同じrelease周期へ詰め込むと、1か所の障害が銀行全体へ広がります。責任・data所有・障害範囲を分けつつ、どの記録が正かと照合方法を決めます。

取引の4つの時点を混ぜない

大量取引と締め処理

銀行では日中のonline処理に加え、利息、手数料、口座振替、明細、会計集計、規制報告など大量のbatch処理があります。暦の日付、銀行のbusiness date、value date、予約日、実際の決済日を区別します。

peak時に無制限にrequestを受けるのではなく、capacity、queue、backpressure、優先順位、timeout、retry、重複排除を設計します。締め処理が遅れた場合も、重要決済をどこまで継続するか決めます。

• 同じ取引をend-to-endで追えるcorrelation id
• 順番が入れ替わっても正しく状態を収束させる設計
• retryしてよい処理と人の確認が必要な処理の区別
• online・batch・外部network間の照合
• 限界容量と縮退運転を定期的にtest

正しく守るだけでなく、壊れても重要業務を続ける

実銀行は障害をゼロにする努力だけでなく、障害が起きる前提で重要業務、許容中断、代替手段、復旧順序を定めます。systemが復帰しても、欠落・重複・順序逆転がないか照合するまで業務復旧は終わりません。

変更そのものが大きなrisk

長年動く銀行には、古いsystem、買収したsystem、外部仕様、手作業が共存します。古いから危険、最新だから安全とは限りません。変更範囲を理解できないこと、移行前後のdataが照合できないことが大きなriskです。

本番変更では、要件と規制のtraceability、設計審査、職務分離、段階release、parallel run、cutover、rollback、監視強化、顧客対応まで1つのchangeとして扱います。

実際のMinibankでは

MinibankはNext.js、Supabase Auth、PostgREST、PostgreSQLを使い、口座・KYC・内部振込・Ledger・Audit・Reconciliationを1つの学習systemで示します。DB transaction、row lock、idempotency、RLS、private schemaなど、本番でも重要な基本原則を小さく観察できます。

一方、外部決済network、複数通貨、普通預金利息・融資、card、口座振替、AML transaction monitoring、総勘定元帳、日次締め、規制報告、multi-region DR、24時間operations、call center連携は備えていません。Minibankのtest合格を本物の銀行への準備完了とは判断できません。