なぜすべての残高は複式簿記台帳から導出されなければならないか

すべてのバンキングシステムには、プロダクトで最も重要な問い — この顧客はいくら持っているのか — に答えるテーブルがあります。信頼できるコアと脆弱なコアを分ける設計判断は、その数字が保存されているか — 誰かが更新する1つの列か — それとも導出されているか — 追記専用の台帳の合計か、です。実装の詳細に聞こえます。しかしそれは、自らの残高を証明できるシステムと、主張することしかできないシステムの違いなのです。

これはフィンテックのコアにおいて最も影響の大きいアーキテクチャ判断でありながら、デモではほぼ見えません。2つのプロダクトは画面上ではまったく同じに見えても、一方は残高の列をその場で上書きし、もう一方はすべての残高を複式簿記台帳から導出しているかもしれません。その違いは後になって表面化します — 照合の不一致として、誰にも説明できないサポートチケットとして、そして監査の場で。

エンジニアリングの文脈で複式簿記が意味するもの

複式簿記は5世紀の歴史を持ちますが、バンキングのバックエンドにおいては会計上の形式ではありません — データベースが強制する不変条件です。すべての資金移動は、少なくとも2つの仕訳を持つトランザクションです。一方の勘定が借方に、他方が貸方に記帳され、仕訳の合計はゼロになります。お金がUPDATE文で生成されたり消滅したりすることは決してありません。勘定間を移動するだけであり、その移動自体が記録なのです。

顧客の残高は、したがって射影です。その勘定に触れるすべての台帳仕訳の合計です。パフォーマンスのためにキャッシュするのは構いません — しかし常に再計算可能であり、再計算こそが真実です。キャッシュと台帳が食い違うことがあれば、勝つのは台帳であり、その食い違い自体が、何かを調査すべきだというシグナルです。

ゼロサムの不変条件は、保存型残高の設計には決して提供できない性質を与えてくれます。システム全体を検算できるのです。すべての勘定 — 顧客ウォレット、手数料収入、プロバイダーの決済勘定、仮勘定 — のすべての仕訳を合計すれば、総計はゼロになります。お金を失わせるバグ、競合状態、部分的な障害はどれもこの等式を破り、検出可能になります。通常はその日のうちに。

保存された残高はいかにしてずれていくか

残高列設計の故障モードは劇的なものではありません。ごく普通の本番トラフィックが生み出す、ゆっくりとしたずれです。

• 並行性：2件の出金が同じ瞬間に同じ残高を読み、どちらもチェックを通過し、どちらも書き込む。台帳がなければ、残高が本来いくらであるべきだったかの記録は残りません。
• リトライと部分的障害：決済プロバイダーがタイムアウトし、クライアントがリトライして、入金が二重に着地する — あるいは「残高を更新」と「取引を記録」の間でクラッシュが起き、両者が恒久的に不整合のまま残る。
• 手作業のオペレーション：サポートエンジニアが苦情を直接のUPDATEで解決する。顧客は満足しますが、現れたお金には出所がなく、どのレポートも決してそれを説明できません。
• 手数料と丸め：ある場所で計算され別の場所で適用される手数料、両側で異なる丸め方をされる通貨換算 — セントの端数が積み重なり、実体のある不一致になります。

台帳が強いるルール — そのすべてが良いもの

導出型残高にコミットすることは、コアの残りの部分に規律を課します。これらの制約は初日には厳格に感じられ、3年目にはシステムが正しくあり続けている理由だったと判明します。

• 金額は最小単位の整数 — セント、サトシ、wei — で持ち、浮動小数点は決して使わない。2進浮動小数点は0.10を正確に表現できません。合計がゼロにならなければならない台帳を、ほぼ合っている数字の上に築くことはできません。
• 不変の仕訳：記帳済みの仕訳は決して編集も削除もされません。誤りは、銀行が昔から正してきた方法で正されます — 誤りと訂正の両方を記録に残す反対仕訳によって。
• 冪等性：すべての操作がキーを持ち、リトライされたリクエストは一度だけ記帳されます。台帳は重複を可視化し、冪等性は重複を防ぎます。
• 原子性：借方、貸方、ビジネス状態の変更は、まとめてコミットされるか、まったくされないかのどちらかです。台帳トランザクションの外で残高を更新するコードパスは存在しません — 管理者による調整も含めてです。調整は静かな上書きではなく、通常の、帰属先の明確な仕訳になります。

照合：外の世界に対して証明する

内部の不変条件は、システムが自分自身と整合していることを証明します。照合は、現実と整合していることを証明します。フィンテックのコアは外部の相手 — バンキングレール、カードプロセッサー、ブロックチェーンネットワーク — とポジションを持ち、それぞれが自分版の真実を保持しています。日次照合は、すべてのプロバイダー明細とすべてのオンチェーンポジションを対応する台帳勘定と突き合わせ、すべての差異に説明を強制します。進行中の決済、まだ記帳されていないプロバイダー手数料、あるいは本物の不一致 — その場合はその日のうちに仮勘定への仕訳と担当者が割り当てられます。

照合は、このアーキテクチャが元を取る場所です。複式簿記台帳があれば、不一致は範囲の限られた探索です。現れた日、触れた勘定、関係する仕訳。保存型残高では、同じ調査が履歴のない1つの数字から始まります — 残高列システムの未照合差異が、解決されるのではなく償却されがちなのはこのためです。

暗号資産は賭け金を引き上げます。オンチェーン残高は公開されています。あなたが管理するウォレットと、顧客に見せている残高は、誰でも突き合わせられるのです。チェーンと日次で照合する台帳を持たないセルフカストディは、社外の誰かに発見されるのを待っている不一致にほかなりません。

監査人と規制当局が実際に尋ねること

遅かれ早かれ、規制下のフィンテックは同じ問いのいずれかの形に直面します。顧客残高が正しいことを証明せよ、と。実務的な答えは証拠の連鎖です — すべての残高は追記専用の台帳から導出される。台帳の合計はゼロになる。すべての外部ポジションと日次で照合されている。そして不変でハッシュチェーン化された監査証跡が、誰がどのデバイスからどの承認の下で各資金移動を開始したかを記録している。

保存型残高の設計の上に築いたチームは、これらの問いにフォレンジックで答えることになります — アプリケーションログとプロバイダーのエクスポートから履歴を再構築するのです。最悪のタイミングで、締切に追われながら。台帳を持つチームは、クエリ1つで答えます。監査が要件を生み出すのではありません。アーキテクチャが最初からそれを満たしていたかどうかを、明るみに出すだけです。

あらゆるコアバンキングプラットフォームに行うべきテスト

プラットフォームを評価しているなら — あるいは自分たちが作ったものをレビューしているなら — これらの質問は5分で聞け、答えをごまかすことは困難です。

• 顧客の画面に表示される数字はどこから来ますか。答えが台帳の射影ではなく残高の列なら、それ以外のすべては飾りです。
• 台帳の仕訳を作らずに残高を変更できますか。管理ツールとサポートワークフローについて具体的に尋ねてください — 静かなUPDATEが隠れているのはそこです。
• 金額は、暗号資産側も含めて、端から端まで最小単位の整数ですか。
• 昨日の照合を見せてください。すべてのプロバイダー、すべてのチェーン、すべての差異に説明が付いているものを。これを見せられないプラットフォームは、やっていないのです。
• 誤った記帳はどう訂正されますか。唯一の良い答えは、個人に帰属し、承認フローを経た反対仕訳です。

Corezaの立ち位置

Corezaはこの設計の厳格版の上に構築されています。すべての残高 — 法定通貨も暗号資産も — は複式簿記台帳から導出され、金額はあらゆる箇所で最小単位の整数であり、記帳済みの仕訳は不変で、訂正はメーカーチェッカー承認を経た反対仕訳として行われ、各インスタンスは接続されたすべてのプロバイダーと稼働するすべてのチェーンに対して日次で照合されます。監査証跡は追記専用かつハッシュチェーン化されており、各資金移動の誰が・いつ・どこからを記録します。

このいずれもプロダクトデモには映りません。そしてそれこそが本記事の主旨です。台帳は、コアバンキングプラットフォームの中で、画面を眺めても評価できない部分なのです。このコアの一バージョンは2024年から規制下の欧州フィンテックで実際の顧客と実際のお金を処理してきました — そして上の5つの質問こそ、当社のものを含むあらゆるプラットフォームにぶつけていただきたい質問です。