09. 銀行らしい機能を追加する | ミニバンクの作り方

基本の口座・送金ができた後に、使いやすさと安全を補う機能を見ます。

このページでわかること

v1には送金のOTP確認があります。使い捨てコードと有効期限、再発行、試行回数を組み合わせ、重要な操作に追加の確認を置きます。画面の操作だけで完了させない理由は、誤操作や不正操作の影響が大きいためです。

v1にはデモ環境でOTPを見せる仕組みがあります。学習時の確認には便利ですが、実際の認証手段として同じ表示を使うべきではありません。設定の境界を確認し、公開環境に混ざらないようにします。

定期預金にも作成、解約、満期の状態があります。期日を迎えたときの処理が二度走っても二重記帳しないこと、普通預金との資金移動が一致することを考えます。

よく使う振込先を保存すれば入力の手間は減ります。しかし表示名を変えられても、実際の送金先口座がいつの間にか別人になっていてはいけません。登録時と送金確定時の情報をどう確認し、変更をどう扱うかが必要です。

お気に入りから選んだ場合も、最後の確定画面には口座番号と受取人を明確に示します。使いやすさが安全確認を省略する理由にはなりません。

短いコードは推測され得ます。期限、試行回数、再発行時に古いコードを無効化すること、確認対象の送金内容と結びつけることが必要です。v1のOTP経路はこうした状態を持ちます。

デモ用にコードを表示する設定は学習には便利ですが、公開された通常の認証手段として扱いません。「コードを知った人が、どの送金を確定できるのか」を意識して読みます。

通知は、送金完了や定期預金の満期などを利用者へ知らせます。しかし通知の作成や表示が一時的に遅れたとき、取引の真偽まで変わってはいけません。取引記録を主とし、通知はそこから利用者に伝える情報として扱います。

同じ出来事を二度通知しないか、既読状態をどう保存するかも別の設計課題です。通知の便利さと帳簿の正しさを混ぜないようにします。

定期預金には作成日と満期日があり、途中解約や満期処理で状態が変わります。予定日に処理が走らなかった場合、翌日にどう追いつくか。同じ処理が再実行された場合、二重に資金を移さないか。通常の送金にはない時間の問題があります。

v1の定期預金関連のマイグレーションには、作成や満期処理の再実行を意識した仕組みがあります。機能を一つ増やすと、帳簿・管理・照合にも新しい条件が増えます。

デビットカード、口座振替、ローンのような項目が画面にあっても、v1で実際の金融取引として完成しているとは限りません。ナビゲーションや説明用の表示と、API・帳簿・テストまでつながった機能を区別します。

機能追加を評価するときは、画面の存在ではなく、状態遷移、権限、記録、失敗時の扱いまで確認します。

普通預金から定期預金を作れば、普通預金側の利用可能額と定期預金側の債務の両方が変わります。満期で戻すときも、残高の表示だけでなく対応する仕訳と状態変更が必要です。

満期処理が通信障害で再実行されたときに二重に払い戻さないこと、途中解約と満期が競合したときにどちらか一方だけ成立することも考えます。