約定した取引は、入力、確認、決済、記帳、報告と、複数の部署のシステムを順に渡ります。フロントの入力を受けて確認と決済を進めるバックや、同じデータで時価とリスクを確かめるミドルは、日々の業務でこれらのシステムを使います。

業務ごとに分かれるシステム

米国の連邦準備制度理事会の検査の手引き（以下、検査の手引き）によると、1998 年ごろ、デリバティブを扱う金融機関のシステムは、多くの場合、業務ごとのシステムの組み合わせでした。システムが支える業務には、市場リスクと信用リスクの管理、取引の処理、決済、会計、財務と規制と経営への報告があります1。使う人も、経営陣、リスク管理、フロント（営業・トレーディング）、バック（事務・決済）、財務報告、内部監査と、部署をまたいでいます。主なシステムと、それぞれが受け持つことは次のとおりです。

システム 主に受け持つこと 主に関わる部署
取引システム 約定の条件の入力、持ち高の記録、日中の時価の確認 フロント
リスク管理のシステム 時価とリスク量の計算、限度枠の監視、経営への報告 ミドル（リスク管理など）
確認・決済・担保のシステム 取引確認書（コンファメーション）の送受、支払いの指図、担保の評価と受け渡し バック（確認書と支払いの指図）
会計のシステム 総勘定元帳（すべての勘定をまとめた帳簿）への記帳 バック（記帳のもとになる、確認した取引の記録を渡す）

取引システムには、約定の日時、決済日、取引相手、商品、金額、価格やレートといった取引の基本の情報を入力します2。2003 年ごろには、担保を使って信用リスクを管理する金融機関は、担保の評価と監視のために担保管理のシステムを持つのが通例でした3。総勘定元帳への記帳と、満期の支払いの指図は、確認した取引の記録をもとにします4。

担保の業務と総勘定元帳への記帳を受け持つ部署を含め、部署ごとの役割と、部署を分ける理由はフロント・ミドル・バックの役割で扱います。

約定から決済、会計までのデータの流れ

取引のデータは約定の入力で作られ、確認、決済、元帳の記帳へと順に使われます。金融機関が取引相手と、想定元本 100 億円、期間 5 年の金利スワップを約定した架空の例で考えます。図 1 は、この 1 件の取引のデータがどのシステムを通るかを示したものです。

取引確認・決済会計フロントが約定の条件を入力するバックが確かめて受け付ける確認書を取引相手と照合する支払日に資金を受け払いする総勘定元帳を更新する
図 1約定から元帳の記帳までのデータの流れ
図の説明

1 件の金利スワップのデータが、取引、確認・決済・担保、会計の 3 つのシステムを通る順番を示した図です。自動処理のシステムを使う場合の形で、まずフロントが取引システムに約定の条件を入力し、バックがその内容を確かめてから取引を受け付けます。受け付けた取引のデータは確認・決済・担保のシステムに渡り、バックが確認書を取引相手と照合します。照合を済ませた取引は、支払日に資金を受け払いし、その結果で会計のシステムの総勘定元帳を更新します。リスク管理のシステムも同じ取引のデータを使います。

フロントの入力をバックが確かめてから受け付ける形は、1998 年ごろの実務で、手作業を減らして一続きで処理すること（STP）や自動処理のシステムを使う場合のものです5。バックは確認書を取引相手に送り、相手の確認書と照らし合わせます。確認書はオンラインの取引システムから自動で作ることもできます6。

支払日（決済日）には資金などを受け払いし、あわせて総勘定元帳の記帳を更新します7。受け払いの手続きは決済で扱います。記録した取引は定期的に評価し直し、満期、売却、解約、行使などで取引が終われば帳簿から外します4。取引の途中では、金利の確定や行使などの処理も起こります。

システムどうしの記録は、定期的に照合します。照合するものには、トレーダーの持ち高の表と総勘定元帳、総勘定元帳と規制上の報告、ブローカーの取引明細と総勘定元帳があります。照合する担当者は、取引のデータを入力する担当者から独立させます8。

市場データと取引の基本データのそろえ方

市場データは、金利、為替、価格、ボラティリティなど、時価とリスク量の計算に使う値です。フロントとバックが違う評価の前提や方法を使うと、財務報告と市場リスクの評価を誤るおそれがあります10。

市場データのもとには、取引所が公表する価格と、よく取引される店頭の商品について情報サービスが配る価格があります。取引所の価格は、トレーダーが付けた値を取引から独立して確かめる材料になります。一方、取引の少ない店頭の商品、特に複雑な店頭デリバティブは、確かめに使える市場の価格が少なくなります10。

取引相手と取引のデータは、1 つのデータベースで持つと、複数のもとから集める場合より正しさを保ちやすくなります。複数のデータベースを使うときは、データを持ち寄って合わせるところごとに照合します9。

日中の処理とその日の終わりの処理

システムの処理には、取引ごとにその場で行うものと、その日の取引をまとめて行うものがあります。取引ごとに行う処理の例は、約定の前の確かめです。トレーダーは約定を決める前に、取引が取引相手の与信枠と、認められた取引の限度に収まるかを確かめます2。この確かめをシステムで支えることもあります。

時価とリスクは、取引ごとの処理とは別に、決まった頻度で確かめて報告します。1998 年ごろの実務では、時価を日中と日次の両方で求めていました。トレーダーは自分の持ち高を見るために日中に、管理の担当者は損益への影響を確かめるために日次で求めていました12。検査の手引きは、リスクの報告の頻度も求めています。持ち高のリスクと損益は、取引の監督者に少なくとも毎日報告します13。取引の多い業務では、リスク管理が日中にもリスクの持ち高を見られるようにします14。

夜間のバッチ処理は、その日の取引をまとめて動かす処理です。主要行等向けの総合的な監督指針は、システム障害などへの備え（コンティンジェンシープラン）を作るとき、バッチ処理が大幅に遅れた場合なども想定するよう求めています15。

外部の機関とのつながり

金融機関のシステムは、社内だけで閉じず、照合のプラットフォーム、清算機関（CCP）、資金決済システム、取引情報蓄積機関とデータをやりとりします。それぞれの役割とやりとりするものは次のとおりです。

外部の機関 役割 金融機関とやりとりするもの
照合のプラットフォーム 取引の両当事者が、取引の条件を照合する 取引の条件、照合の結果、清算の申込み
清算機関 取引の当事者の間に入り、決済を保証する 清算の申込み、清算の状況、証拠金のレポート
資金決済システム 参加者の間で資金を移す 資金の支払いと受け取り
取引情報蓄積機関 取引のデータの記録を集めて管理する 取引情報の報告

2012 年の MarkitSERV の意見書は、照合のサービスを同様に提供する事業者がほかにもあると述べています17。

清算機関は、取引の当事者の間に入って、売り手に対しては買い手、買い手に対しては売り手になり、決済を保証します18。日本証券クリアリング機構（JSCC）の金利スワップでは、両当事者が照合のプラットフォームや取引執行のプラットフォームで取引を照合し、清算を申し込みます。JSCC は取引が清算の条件を満たすかと担保が足りているかを確かめて債務を引き受け、その状況と証拠金などのレポートを配信します19。

資金決済システムは、参加者の間で資金を移すための手段、手続き、規則のまとまりです20。取引情報蓄積機関は、取引のデータの電子的な記録を集めて管理する機関で、特に店頭デリバティブの市場で使われます21。

日本では、一定の店頭デリバティブの取引について、金融商品取引業者等と清算機関が取引情報蓄積機関に取引情報を提供します22。報告する事項には、取引の条件のほかに、契約の評価額、当初証拠金と変動証拠金の額も入ります23。

報告では、取引の当事者を示す取引主体識別子（LEI）と、取引を 1 件ずつ示す固有取引識別子（UTI）も使います24。

手作業を減らして一続きで処理する STP

STP（Straight-Through Processing）は、約定から決済までの処理を、標準の形式のメッセージでシステムどうしを自動でつなぎ、人の手を介さずに一続きで処理することです25。1998 年ごろの実務では、フロントとバックで取引を入力するシステムが別々の場合、トレーダーが手書きした取引の票をバックに届け、それをバックの入力のもとにしていました。STP や自動処理のシステムを使う場合でも、フロントが入力した内容をバックが確かめてから受け付けていました5。

1999 年ごろの証券取引では、フロント、ミドル、バックの各段階が別々に機械化され、段階ごとに違う形式やシステムを使っていたため、段階の境目で約定の内容を手で入れ直す例が多くありました26。STP にすれば手作業の入れ直しがなくなり、入力の誤りやデータの改ざんのリスクを減らせます。一方で、それまで複数の部署が分けて処理していた取引を、より少ない部署の入力だけで処理するようになるため、入力の権限の確認や、後から処理をたどれる記録（監査証跡）の確保が別に要ります27。

システムどうしを自動でつなぐには、データの形式をそろえる必要があります。店頭デリバティブでは、取引の情報を電子的にやりとりして処理するための XML の標準として FpML があります28。取引情報の報告のガイドラインも、日数計算の慣行の報告の値を、ISO 20022（金融の通信メッセージの国際規格）、FIX（主に証券取引の通信メッセージのプロトコル）、FpML のコードと対応させて示しています29。

1 つのシステムにまとめるか、分けるか

システムを 1 つにまとめるか、業務ごとに分けるかは、金融機関によって違います。検査の手引きの 1998 年ごろの時点では、店頭と上場のすべての商品について、データの入力からすべての処理と管理までを 1 つのシステムが受け持つことはまれで、ベンダーから買ったシステムと自社で作ったシステムを組み合わせることもありました9。すべてのシステムが一体につながっているとはかぎらず、途中に手作業が入ることもあります。検査の手引きは、手作業の箇所でデータの正しさが保たれているかを確かめるよう、検査官に求めています1。

違いが出る理由の 1 つは、取引の量です。取引の少ない金融機関では、リスク管理の報告を自動化しても費用に見合わず、多くの分析を手作業で済ませられます。取引が増えて手作業では遅れずにリスクを監視できなくなると、自動化が見合うことがあります9。金融機関は、どの形でも、入力から報告までのデータの流れを、流れ図か文章で示しておきます9。

システムを分けてつなぐ場合は、システムや会社の間でデータの表し方をそろえることが要ります。そのための取り組みには、FpML のほかに CDM（Common Domain Model）もあります。CDM は、金融商品、その商品の取引、取引のライフサイクル・イベントを、機械が読めて実行もできる形で表す標準のモデルです30。

注

  1. Board of Governors of the Federal Reserve System「Trading and Capital-Markets Activities Manual」の Section 2040.1「Operations and Systems Risk (Management Information Systems)」（1998 年 2 月）の 1〜2 ページ。 ↩ ↩2

  2. Board of Governors of the Federal Reserve System「Trading and Capital-Markets Activities Manual」の Section 2050.1「Front-Office Operations」（1998 年 2 月）の 2〜3 ページ。 ↩ ↩2

  3. Board of Governors of the Federal Reserve System「Trading and Capital-Markets Activities Manual」の Section 2020.1「Counterparty Credit Risk and Presettlement Risk」（2003 年 4 月）の 14 ページ。 ↩

  4. Board of Governors of the Federal Reserve System「Trading and Capital-Markets Activities Manual」の Section 2060.1「Operations and Systems Risk (Back-Office Operations)」（1998 年 2 月）の 3 ページ。 ↩ ↩2

  5. Board of Governors of the Federal Reserve System「Trading and Capital-Markets Activities Manual」の Section 2050.1（1998 年 2 月）の 2 ページ、"Transaction Flow"。 ↩ ↩2

  6. Board of Governors of the Federal Reserve System「Trading and Capital-Markets Activities Manual」の Section 2060.1（1998 年 2 月）の 3 ページ、"Confirmations"。 ↩

  7. Board of Governors of the Federal Reserve System「Trading and Capital-Markets Activities Manual」の Section 2060.1（1998 年 2 月）の 4 ページ、"Settlement Process"。 ↩

  8. Board of Governors of the Federal Reserve System「Trading and Capital-Markets Activities Manual」の Section 2060.1（1998 年 2 月）の 5 ページ、"Reconciliations"。 ↩

  9. Board of Governors of the Federal Reserve System「Trading and Capital-Markets Activities Manual」の Section 2040.1（1998 年 2 月）の 2 ページ（"COMPUTING SYSTEMS" の続き）。 ↩ ↩2 ↩3 ↩4 ↩5

  10. Board of Governors of the Federal Reserve System「Trading and Capital-Markets Activities Manual」の Section 2060.1（1998 年 2 月）の 6 ページ。 ↩ ↩2

  11. Board of Governors of the Federal Reserve System「Trading and Capital-Markets Activities Manual」の Section 2040.1（2003 年 4 月）の 3 ページ、"Parameter Selection and Review"。 ↩

  12. Board of Governors of the Federal Reserve System「Trading and Capital-Markets Activities Manual」の Section 2060.1（1998 年 2 月）の 6 ページ。 ↩

  13. Board of Governors of the Federal Reserve System「Trading and Capital-Markets Activities Manual」の Section 2040.1（1998 年 2 月）の 1 ページ。 ↩

  14. Board of Governors of the Federal Reserve System「Trading and Capital-Markets Activities Manual」の Section 2000.1「Overview of Risk Management in Trading Activities」（1998 年 2 月）の 6 ページ。 ↩

  15. 金融庁「主要行等向けの総合的な監督指針」（2026 年 10 月）のⅢ－３－７－１－２（９）③（267 ページ）。 ↩

  16. Board of Governors of the Federal Reserve System「Trading and Capital-Markets Activities Manual」の Section 2020.1（2003 年 4 月）の 14 ページ（日中の与信のエクスポージャーと、担保管理のシステムから与信枠のシステムへのデータの受け渡し）。 ↩

  17. MarkitSERV の欧州証券市場監督局への意見書（2012 年 8 月 5 日付）の "offered also by various other providers"。 ↩

  18. BIS 支払・決済システム委員会、証券監督者国際機構専門委員会「金融市場インフラのための原則」（仮訳、2012 年 4 月）のパラグラフ 1.13（11〜12 ページ）。 ↩

  19. 日本証券クリアリング機構「金利スワップ 債務負担」の「債務負担のワークフロー・イメージ」。 ↩

  20. 「金融市場インフラのための原則」（仮訳）のパラグラフ 1.10（10 ページ）。 ↩

  21. 「金融市場インフラのための原則」（仮訳）のパラグラフ 1.14（12 ページ）。確認・照合のプラットフォームを取引情報蓄積機関の利害関係者に挙げているのは、ボックス 1（13 ページ）。 ↩

  22. 金融庁企画市場局市場課「店頭デリバティブ取引等の規制に関する内閣府令第４条第１項で定める作成・保存・報告事項 ガイドライン」（2022 年 12 月。以下「ガイドライン」）の 1 ページ。ガイドラインは、根拠として「金融商品取引法」第 156 条の 63 と第 156 条の 64 を挙げています。 ↩

  23. 金融庁のガイドライン（2022 年 12 月）の「報告事項 一覧」。評価額は 39、当初証拠金は 45〜49、変動証拠金は 51。 ↩

  24. 金融庁のガイドライン（2022 年 12 月）の 1 ページ（別紙 2 の UTI）と「報告事項 一覧」の 9（取引当事者 2 の識別子が LEI かどうか）。 ↩

  25. 宮田慶一「証券取引のSTP化を巡る動きについて」（日本銀行調査月報、1999 年 10 月）の 1〜2 ページ。資料は証券取引について定義しています。 ↩

  26. 宮田慶一「証券取引のSTP化を巡る動きについて」（1999 年 10 月）の 5 ページ。 ↩

  27. 宮田慶一「証券取引のSTP化を巡る動きについて」（1999 年 10 月）の 7 ページ。 ↩

  28. TC68 国内委員会事務局「ISO 20022 の概要」（2015 年 3 月）の 6 ページ、脚注 13。資料は、FpML が国際スワップ・デリバティブズ協会（ISDA）の後援を受けて開発されたオープンソースの標準だとしています。 ↩

  29. 金融庁のガイドライン（2022 年 12 月）の別表 1「Day count convention」。ISO 20022 と FIX の説明は「ISO 20022 の概要」（2015 年 3 月）の 1 ページと 6 ページの脚注 14。 ↩

  30. FINOS「Common Domain Model」の冒頭の説明。 ↩