決済と口座 — 振込一件の旅
一言でいうと
銀行システムは、チャネル系・勘定系・情報系の3つの層に分かれていて、振込1件は、その層と決済網を経て元帳に載ります。その道のりが完全とは限らないので、締めと突合が存在します。
なぜ3つの層に分かれたのか
銀行に初めて入ると、「それは勘定系の仕事だ」、「チャネルで止めなければならない」、「情報系から抽出して」のような言葉を耳にします。この3つは、組織であり、システムの名前です。
| システム | 役割 |
|---|---|
| チャネル系 | 顧客と接する場所。モバイルアプリ、インターネットバンキング、ATM、窓口端末、オープンバンキングAPI。 |
| 勘定系 | 口座と元帳を持つ中核。残高を変える唯一の場所で、最も保守的に運用されます。 |
| 情報系 | 勘定系を複製して、分析・報告・マーケティングに使う場所。原本ではなく写しです。 |
このように分けた理由は、負荷とリスクを分離するためです。チャネルは1日に数千万回の照会を受けますが、残高を変えません。勘定系は残高を変えますが、照会の負荷から守られます。情報系は、重い集計を回しても、勘定系を遅くしません。その代わり、代償があります。層の間を行き来する電文(メッセージ)が生まれ、その往復が、常に完全とは限りません。
振込1件の道のり
顧客がモバイルアプリで他行振込を押すと、おおよそ次のことが起きます。
- チャネル系が認証と限度を確認して、勘定系に出金要求の電文を送ります。
- 勘定系が出金口座の残高を確認して、元帳に出金を記録します。
- 銀行は、金融決済院の共同網を通じて、受取銀行に入金要求を送ります。
- 受取銀行が受取人の口座に入金して、応答します。顧客にとっては、ここまでが数秒です。
- 銀行間の実際のお金の移動は、案件ごとには行いません。1日分をまとめて差額を計算し、韓国銀行に開設された各銀行の当座預金口座の間で、韓銀金融網を通じて決済します。これが差額決済で、実際には翌営業日の決まった時刻に行われます。
この構造で重要な事実が1つあります。受取人はすでにお金を受け取ったのに、銀行間の決済はまだ終わっていない時間が存在します。その間に1つの銀行が破綻したらどうなるかが、決済リスクで、そのため、韓国銀行が、担保と限度を管理します。
元帳・締め・整合性
勘定系の元帳は、取引を時間順に積んだ記録で、残高はその合算です。性能のために、口座ごとに残高カラムを持ちますが、それは複製です。1日が終わると、日次締めが回り、その日の取引を確定して、勘定日付を進めます。締めのあとにその日の日付で取引がさらに入ってきてはいけないので、カットオフ時刻以降の取引は、翌営業日に載ります。
締めの核心の手順が、突合です。チャネルが成功と答えた案件と元帳に載った案件、自社の元帳と相手機関の精算ファイル、残高カラムと元帳の合算。これらのペアが合っているかを確認します。ずれる形は、いくつかに決まっています。
| 不一致 | 何が起きたか |
|---|---|
| チャネルにだけある | 応答は返したのに、元帳への反映が失敗しました。顧客は完了したと思っています。 |
| 元帳にだけある | 元帳には載ったのに、応答が遅れてチャネルはタイムアウトとして記録しました。顧客は失敗したと思ってもう一度押します → 二重取引。 |
| 金額が違う | 電文のパース・桁数・通貨単位の問題。まれですが、最も長く残ります。 |
| 残高だけが違う | 元帳を通さずに残高カラムを直しました。訂正ではなく事故です。 |
訂正にも規則があります。元帳の行を直したり消したりしません。抜けた取引は訂正取引として入れ、誤って出た取引は、逆方向の取引で相殺します。何があったかが順番に残っていてはじめて、苦情と監査に答えられます。
お金を扱うシステムで、システムエンジニアが実際に直面すること
金融ドメインで、開発者が最初に驚くのは、業務ルールではなく、時間と順序に対する要求です。
1日は午前0時に終わりません。営業日と暦日が違い、締め時刻以降の取引は、翌営業日に回ります。そのため、「今日」という概念を、システム時刻から直接持ってきてはならず、業務日付を管理する場所が別に必要です。これを抜かすと、締めの前後の数分の間の取引が、どの日付に属するかを、人によって違うように語ることになります。
締め中は、元帳に手を付けられません。残高を確定している間に、新しい取引が入ってくると、合計が合いません。そのため、締めウィンドウ(window)では、書き込みを止めるか、その間に入ってきたものをキューに入れておいて、締めのあとに反映します。サービスが24時間動かなければならないなら、勘定系は締めて、チャネルだけが生きている構造になります。
突合(reconciliation)は、例外処理が本体です。自社の元帳と相手機関の記録を合わせる作業ですが、大半は自動で合い、問題は、合わない数件です。金額が違うもの、自社にだけあるもの、相手にだけあるものを分けて、それぞれを、誰がいつまでに処理するかが決まっていなければなりません。この流れがなければ、合わない案件が積み上がって、ある日大きな数字になります。
取消は削除ではありません。誤った取引を消すと、監査証跡が途切れます。逆方向の取引をもう1つ作って相殺し、2つの取引を互いにつなぎます。元帳は、追記しかしない帳簿でなければならず、そうしてはじめて、どの時点の残高でも、再計算できます。
金額は、絶対に浮動小数で扱いません。0.1 + 0.2が0.3にならないことが、ウォン単位でも問題になります。整数(最小の通貨単位)か十進型で保存し、通貨と小数点の桁数を、値と一緒に持ち回ります。
時間は、保存するときはUTC、判断するときは営業日です。2つを混ぜると、午前0時付近の取引で、必ずずれます。
実務で本当に大切なこと
1つ目に、タイムアウトは失敗ではありません。チャネルが応答を受け取れなかったという意味であり、勘定系が処理しなかったという意味ではありません。チャネルは、タイムアウトのあとに結果を照会して確認する必要があり、顧客には「処理中」を見せなければなりません。「失敗」を見せると、二重取引が起きます。
2つ目に、リトライには冪等キーが必要です。同じリクエストが2回来ても1回だけ載るようにするには、チャネルが作った一意の参照を、勘定系が覚えていなければなりません。突合が二重取引を見つけるのは事後の措置で、冪等キーは事前の措置です。
3つ目に、残高カラムは真実ではありません。ずれたら、元帳が勝ちます。残高をUPDATEで直した痕跡は、それ自体が監査の指摘事項です。
次のラボで、チャネルログと元帳を直接突合して、上の4つのずれをすべて見つけ出し、訂正取引で正します。