Fintech エンジニアリング・ハンドブック、金銭システム設計の三原則を解説

Fintech ソフトウェア・エンジニアリングの重要なパターンを体系化したハンドブックが、「No invented data」「No lost data」「No trust」の三つの核となる原則に基づく金銭システム設計手法を説明している。

金銭を中心に据えたソフトウェア・エンジニアリングのパターンを網羅したハンドブック「Fintech Engineering Handbook」が、金銭の表現方法、台帳記録、送金実行といった金融システム設計の基本原則を詳述している。このハンドブックは全文通読する方法と、パート単位での参照の両方に対応している。

三つの設計原則

ハンドブックの基盤となるのが三つの原則である。第一に「No invented data」：「金銭は無からは生まれないため、重複や恣意的な残高更新は許容できない」との考えのもと、冪等性、重複排除、照合によって実装される。第二に「No lost data」：「金銭に生じるすべてのことは追跡・永続化されなければならない」という要件である。第三に「No trust」：「外部プロバイダー、内部コンポーネント、世界のいずれも信頼しない」という原則である。

金銭表現と精度管理

ハンドブックは金銭データの表現方法を複数提示する。浮動小数点表現は最速でメモリ効率が高い一方、予測不可能な精度喪失を生む可能性がある。Java の BigDecimal のような任意精度型は計算精度の制御を可能にする。マイナー・ユニット精度は金額を最小単位の整数として保存する方式で、例えば €12.34 は 1234 となる。暗号資産は整数最小単位方式を採用し、精度はトークンごとに定義される（しばしば 18 桁）。有理数は最も強力な精度方式だが、他の手段より遅い。通常、JSON 数値は大多数のパーサーで IEEE-754 ダブルとして扱われ、ISO 4217 は通貨精度の桁数を規定している。

複式簿記と監査証跡

複式簿記は (貸方勘定、借方勘定、金額) として取引を記録する。残高は金銭移動から導出され、直接保存されることはない。複式簿記のポスト済みエントリは慣例上、変更不可である。「訂正は新しい相殺エントリを追加することで行われる」と、ハンドブックは説明する。トランザクションは最低でも二つのタイムスタンプを持つ：バリュー・タイムとブッキング・タイムであり、しばしば決済タイムを加えて三つになる。決済タイムは通常 T+X （X は バリュー後の日数）で表現される。監査証跡は何が起きたのか、いつ起きたのか、誰が引き起こしたのか、なぜ起きたのかを記録する。「編集可能な監査証跡は何も証明しないため、レコードは更新も削除も決してされない」との原則である。

資金予約と過度当座貸越

資金予約は総残高と利用可能残高の区別を導入する。残高確認と新規予約は利用可能残高に対して行われ、同じ資金が複数の取引に担保されることを防ぐ。過度当座貸越（オーバードラフト）は意図的なもの（信用商品）と意図しないもの（ポリシーに反して残高がマイナスになること）に分けられる。冪等性キーは特定の操作とクライアントにスコープされるべきである。

筆者の見立て

• ハンドブックの著者は、浮動小数点表現は「ほぼ確実に金銭には適さない」と論じている。
• 精度表現の選択に「経験則は存在しない。浮動小数点を使用しないことを除いて」と解釈している。
• イベント・ソーシングは「監査証跡が必須の場合は非常に優れた解決策だが、システム複雑性の観点から非常に高い代価を伴う」と論じている。
• 実際のシステム構築では「バグは避けられず、イベント・ログの修正が必要になる可能性がある」と解釈している。
• 不変性の強制方法として「構造による実装が最強だが、すべてを表現することはできない」と解釈している。

この記事は元記事の事実のみに基づいて自動生成されました。

出典

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