お金を扱うソフトウェアで「1円のズレ」も起こさないための設計原則をまとめた「Fintech Engineering Handbook」とは？

お金に関する処理においては、お金を二重に動かさず、端数を勝手に消さず、後から説明できる形で記録する必要があります。お金を扱うソフトウェアの設計原則をまとめた「Fintech Engineering Handbook」は、フィンテック分野で使われる重要な考え方を整理したハンドブックです。

Fintech Engineering Handbook
https://w.pitula.me/fintech-engineering-handbook/

ハンドブックはフィンテックに加わったばかりの人、すでにフィンテックで働いている人、フィンテック以外の分野から「お金を扱うシステムは何が違うのか」を知りたい人を対象に書かれているとのこと。筆者のボイテック・ピトゥラ氏はハンドブック全体を貫く原則として「存在しないお金やデータを作らない」「情報を失わない」「何も信用しない」という3つを挙げています。

たとえば残高が1万円の口座から同時に1万円の出金リクエストが2回走った場合、一般的なログや通知の処理なら「あとで整合性を取る」という方針で済む場合があっても、お金を扱うシステムでは同じ1万円を2回使わせると存在しないお金を作ったことになります。通信が途中で切れたから再試行しただけなのか、本当に2回送金したいのかを区別できなければユーザーの残高や事業者の帳簿が壊れてしまいます。

最初に重要になるのはお金の表し方です。ハンドブックでは浮動小数点数、つまり多くのプログラミング言語で使われるfloatやdoubleは精度の誤差を生むため、ほとんどの場合で避けるべきだと説明されています。代わりに「12.34ユーロ」を「1234セント」のように最小単位の整数で保存したり、計算途中ではJavaのBigDecimalのような任意精度の型を使ったりするべきとのこと。さらに金額だけを保存するのではなく、金額と通貨を必ず組にして扱い、円とドルをそのまま足し合わせるような処理を禁止する必要があります。

次に端数処理が問題になります。手数料、利息、外貨両替、暗号資産の換算などで小数点以下の値が発生しますが、端数をどちらに丸めるかは単なる実装の好みではなく、誰が端数分を受け取るのかというビジネス上や税務上の判断につながります。丸め処理はできるだけ遅らせ、永続化やユーザー表示などシステムの境界に来た段階で明示的に行うべきとのこと。

金額を正しく表せたら、次はお金の動きを記録する台帳が必要になります。ハンドブックではソフトウェア設計の中心的なパターンとして複式簿記が登場。複式簿記では同じ金額の移動元と移動先を対で記録するため、合計額が勝手に増えたり減ったりしません。残高を直接書き換えるのではなく、過去の移動履歴から残高を計算するため、後から「なぜ残高がこの数字になったのか」を追跡できるという利点があります。

また、時刻の管理については「カード決済が行われた時刻」「システムに記録された時刻」「資金が実際に移動した時刻」が別々になることもあるため、ハンドブックによると「取引発生時刻」「記帳時刻」「資金が実際に移動した時刻」を分けて記録する必要があるとのこと。1つの時刻だけで済ませると、月末の決済が翌月に記録された場合や、数日後に精算される取引を説明できなくなるためです。

外部サービスとの連携において、決済事業者、銀行、本人確認サービス、ブロックチェーンノードなどは自社で制御できません。APIの返答が仕様と違ったり、Webhookと呼ばれる外部システムからの通知が遅れたり、同じ通知が複数回届いたりすることがあります。そのためハンドブックでは、外部から届く情報をそのまま信じるのではなく、境界で検証し、リクエストとレスポンスを保存し、必要に応じて別の情報源と突き合わせるべきだと説明しています。

二重処理を防ぐための仕組みとして、冪等(べきとう)性についても解説されています。冪等性とは、同じリクエストが複数回届いても結果が1回分だけになる性質のこと。通信エラーが起きた送金処理では、送金に成功したのに返答だけ失われたのか、送金自体が失敗したのか分からない場合があります。安全に再試行するには、同じ操作を識別するキーを用意し、同じキーの処理が二重に実行されないようにする必要があります。

出金や送金のような処理は「残高確認」「資金の予約」「本人確認やコンプライアンスチェック」「外部システムへの登録」「資金移動」といった複数の段階に分かれます。途中でサーバーが落ちても、お金が行方不明になってはいけません。ハンドブックでは進行状況をメモリではなく永続的に保存し、止まった処理を再開できるようにし、各段階を再実行しても同じ処理が二重に記録されない作りにすることが重要だと説明されています。

監査と権限管理も重要なテーマです。誰が手数料設定を変更したのか、誰が大口出金を承認したのか、誰が本番環境にコードを反映したのかを後から説明できなければ、帳簿が正しくても運用の正しさを証明できません。ハンドブックでは、重要な操作を1人だけで完結させない職務分掌や、2人目の承認を求めるフォーアイズ、最小権限、定期的な権限レビューなどもお金を扱うシステムの一部として扱っています。

さらにハンドブックには、プロパティベーステスト、古いデータ形式を読み続けられるかを確認する後方互換性テスト、本番環境で少額の実取引を使って確認するテストなども登場します。テストで動かすお金も本物のお金である以上、抜け道のような処理ではなく、通常の台帳、照合、監査証跡を通す必要があるとのことです。

Fintech Engineering Handbookは、金額の型から台帳、冪等性、Webhook、照合、権限管理、用語集、暗号資産の出金やカード入金の例までをまとめた長大な資料です。ハンドブックは全体を一気に読むことも、困っている設計課題に応じて該当部分だけ参照することもできるとされており、今後お金を扱う機能を作る人にとって「まず疑うべき場所」を教える地図のような資料になっているとのことです。