取引の変更が起きたとき、報告のデータを作る担当者や取引システムの設計者は、その変更をどのデータに残すかを決めます。残したデータは、ほかのシステムへの受け渡しや、取引相手との記録の突き合わせにも使います。

イベントによる状態の変化

取引期間中のイベント（ライフサイクル・イベント）は、取引の状態を変えます。ここでいう取引の状態は、その時点の条件、残高、当事者と、取引が続いているか終わったかをまとめた呼び方です。金融庁の報告のデータでは、条件の変更では取引が続き、期限前解約や行使では取引が終わります。ノベーションや清算では元の取引が終わり、新しい取引ができます1。

この変化を、いつ、どのイベントで、何から何に変わったかが追える形で記録していないと、履歴をたどれません。市場全体でも、2005 年より前のクレジット・デフォルト・スワップ（CDS）の市場には、取引を集めた中央の記録がなく、四半期ごとの支払いのようなイベントを管理しにくい状態でした2。

権利行使の通知、確認、決済といった業務の流れは、取引期間中のイベント処理で扱います。

イベントの種類と、取引の状態の変わり方

取引情報蓄積機関への報告のデータは、取引にしたことを表す「アクションタイプ」と、その理由を表す「イベントタイプ」を分けています。金融庁の報告事項のガイドラインでは、アクションタイプは次の 9 つです。新規（New）、変更（Modify）、訂正（Correct）、エラー（Error）、終了（Terminate）、復元（Revive）、移管（Transfer out）、評価（Valuation）、担保（Collateral）。イベントタイプは次の 12 種類です3。

イベントタイプ 表すこと 組み合わせられるアクション
取引（Trade） 取引の作成または変更 新規、変更
ノベーション（Novation） 取引のリスクの一部か全部を、譲る側から譲り受ける側に法的に移す。元の取引は終わるか修正され、新しい取引ができる 新規、変更、終了
コンプレッションとリスク削減の行使（Compression or Risk Reduction Exercise） 既存の一連の取引を終えるか修正し、新しい取引を作る 新規、変更、終了
期限前解約（Early termination） 予定した終了日や満期日より前に取引を終える 変更、終了
清算（Clearing） 清算機関が当事者の間に入り、売り手と買い手の既存の取引を終える 新規、終了
行使（Exercise） オプションやスワップションの権利の全部か一部を行使する 新規、変更、終了
割り当て（Allocation） 複数の顧客のために取引した代理人が、取引の一部を顧客に割り当てる 新規、変更、終了
清算と割り当て（Clearing and Allocation） 清算機関での清算と割り当てが同時に起きる 新規、終了
クレジット・イベント（Credit event） すでに報告したクレジット・デリバティブの状況を変える事象 変更、終了
移管（Transfer） 取引を別の取引情報蓄積機関に移す 新規、移管
企業行動（Corporate event） 株式の取引に影響する、原株式への企業の行動 新規、変更、終了
アップグレード（Upgrade） 改訂された報告要件に、未処理の取引を合わせる 変更

組み合わせは、ガイドラインの別表 5 が認める範囲です。別表 5 にない組み合わせは、データの受け付けが認められない可能性があります4。たとえば、オプションの行使では、取引の終了（Terminate）とイベントの行使（Exercise）の組み合わせで報告します。権利を行使された側も同じです3。

イベントタイプの 12 種類に、金利の確定や利払いにあたるものはありません。契約上の満期日に終わる取引には、終了（Terminate）のアクションを使いません3。償却型スワップのように想定元本が予定どおり減る取引でも、予定表の段階はイベントにしません。取引の開始時に合意した当初の想定元本を報告し、変更やイベントがあった後は、その結果の残高を報告します5。

変更の前後をたどる履歴の持ち方

報告のデータは、取引が続くあいだは同じ固有取引識別子（UTI）で更新し、別の取引に置き換わるときに新しい UTI を付けます。取引が 1 対 1 または 1 対多で置き換わるときは、置き換わった新しい取引に前の取引の UTI を Prior UTI として添え、つながりを残します6。複数の取引が 1 つか複数の取引に置き換わるときは、Prior UTI を使いません7。

起きたこと UTI 前の取引との結び付け
条件の変更、時価評価の更新、期限前解約（部分的な解約も） 同じ UTI で報告を更新する 不要
完全なノベーション ノベーション後の取引に新しい UTI を付ける 終わった元の取引の UTI を Prior UTI として報告する
部分的なノベーション 元の取引の UTI は変わらず、取引は残る。ノベーション後の取引に新しい UTI を付ける 元の取引の UTI を Prior UTI として報告する
スワップションの行使 行使で生まれた原資産のスワップに新しい UTI を付ける スワップションの新規取引のときの UTI を Prior UTI として報告する
コンプレッションなど、複数の取引が別の取引に置き換わるとき 新しい UTI を付ける Prior UTI は使えない。イベントの識別子で結ぶ
はいいいえ元の取引とは別に、新しい取引ができるか同じ UTI で報告を更新するはいいいえ元の取引と新しい取引は、1対 1 または 1 対多で結ばれるか新しい UTI を付ける。PriorUTIは使えない新しい UTI にPrior UTI を添える
図 1取引が変わるときの UTI の付け方の分かれ目
図の説明

条件の変更や時価評価の更新は、同じ UTI で更新します。部分的な解約のように取引が残る場合の細かい扱いは、前の表のとおりです。

取引 P の UTI が「A」の架空の例で考えます。条件を変更した後も UTI は A のままで、報告を更新します。その後、完全なノベーションで取引が譲られると、ノベーション後の取引に新しい UTI「B」を付け、終わった元の取引の UTI「A」を Prior UTI として添えます。A から B へ、履歴をたどれます。

Prior UTI は、取引どうしが 1 対 1、または 1 対多で結ばれるとき（ノベーション、行使、清算）に使えます。複数の取引が 1 つか複数の取引につながるとき（コンプレッションなど）は使えません。コンプレッションとクレジット・イベントでは、Prior UTI の代わりに、イベントから生じた取引を結ぶイベント識別子が要ります。報告する者や、サービスを提供する事業者が付けます7。

履歴には、イベントの日時も残ります。報告するイベントの日時は、実際にイベントが起きた時刻でなく、システムに入力した時刻やデータを作った時刻でも認められます。システムの制約で秒まで分からないときは、秒以下を 00 にしてよいとされています。清算のときは、元の取引を清算機関が受け入れ、清算機関のシステムが記録した日時を報告します8。

クレジット・イベントで想定元本が減るときの報告を、50 銘柄で作る CDS インデックスの取引で、想定元本 10 億円、1 銘柄あたり 2,000 万円の架空の例で考えます。そのうちの 1 銘柄にクレジット・イベントが起きて決済されると、取引は続き、想定元本が減ります。報告は、決済の後の想定元本と、決済の後の想定元本を決済前の想定元本で割ったインデックス・ファクター（決済で残った割合）で表します9。

時点 想定元本 インデックス・ファクター
新規の取引 10 億円 1.0
1 銘柄のクレジット・イベントの決済後 9 億 8,000 万円 0.98

訂正と取消の持ち方

報告では、条件の変更（Modify）、誤りの訂正（Correct）、取引全体の取消（Error）、取消や誤った終了の復元（Revive）を別のアクションにしています3。履歴の持ち方に関わるのは次の 2 点です。UTI 以外の誤りを訂正するときは、同じ UTI で報告を更新します6。訂正と時価評価が同じ日に起きたときは、訂正（Correct）と評価（Valuation）の 2 つの明細を報告します3。

社内のシステムでの訂正と取消については、外国為替の取引向けに 2010 年の実務指針があります。拘束力のある規則ではなく、業界の目標です10。入力の誤りは、相手先、受渡日、レートなどで起き、取引を事務に渡した後に直したり取り消したりすることがあります。指針は、その手続きの細部は金融機関ごとに違い、システムの制約で決まることが多いと書いています11。取引相手とは、誤りのあった側が、自社のシステムの取引を直し、訂正した確認書を出します12。

受け渡しと状態の食い違い

報告のデータとは別に、CDM（Common Domain Model）は、イベントのたびに変更前の取引の状態から変更後の取引の状態を作り、つなげて取引の経路をたどれるようにするデータモデルです14。CDM の詳しい構造はISDA CDMで扱います。

フロント（営業・トレーディング）とバック（事務・決済）が別のシステムを使うときは、取引、調整、取消を、電子的な連携で自動で一方から他方へ渡すよう、2010 年の実務指針は勧めています。できれば同じデータを、総勘定元帳への記帳、与信の情報の更新、資金の受け払いの指図の作成などにも、そのまま渡します15。バックのシステムに取引を入れ直すと誤りが起きうるため、一続きで渡すことは、誤りを減らし、データの届く時機を早める手立てです16。

フロントバック取引、調整、取消が生じる電子的な連携で自動で受け取る（再入力しない）同じデータを総勘定元帳、与信、資金の受け払いへ
図 2取引、調整、取消をフロントからバックへ渡す流れ
図の説明

図は、フロントとバックが別のシステムを使うときのデータの渡し方を示します。フロントで取引、調整、取消が生じると、電子的な連携でバックのシステムへ自動で渡し、バックでは入れ直しません。最後の手順は、できればそうする、という位置づけです。

報告のデータでは、評価額と担保の更新は、イベントとは別のアクション（Valuation、Collateral）で渡します3。

同じ取引の状態をそろえる難しさと備えの例として、次の 3 つを挙げます。

  • 取引相手との記録の食い違い。2010 年の論文は、担保をめぐる争いを減らす方法として、取引相手と、デリバティブと担保の持ち高の主な経済条件が合っているかを定期的に照合することを挙げています。主要なディーラーの間では、独立した第三者が照合し、合わない取引を示すこともできます17。
  • 条件の変更が大量に起きるとき。円 LIBOR を参照する取引の参照金利を代替の金利指標に替えるには、当事者間の契約上の合意のほかに、取引で使うシステムの開発や変更と、事務の流れの見直しが欠かせませんでした。対象の取引が膨大で、合意も対応も容易ではないと指摘されていました（2022 年 5 月）18。
  • 履歴の監査での確かめ方。1998 年 2 月の米国の連邦準備制度理事会の検査の手引きは、検査の目的の 1 つに、自動化したシステムと手作業の処理が、データの正しさを評価し確保できる十分な監査証跡を持つように設計されているかを確かめることを挙げています19。

注

  1. 金融庁「店頭デリバティブ取引等の規制に関する内閣府令第４条第１項で定める作成・保存・報告事項 ガイドライン」（2022 年 12 月）。別紙 1 の 101「Action type」の備考（26 ページ）と 102「Event type」（27 ページ）、別紙 2 の 5（1）（6〜7 ページ）。 ↩

  2. Duffie, Li, Lubke "Policy Perspectives on OTC Derivatives Market Infrastructure"（Federal Reserve Bank of New York Staff Report no. 424、2010 年）の Table 1 の最初の項目（3 ページ）。 ↩

  3. 金融庁「店頭デリバティブ取引等の規制に関する内閣府令第４条第１項で定める作成・保存・報告事項 ガイドライン」（2022 年 12 月）の別紙 1 の 101「Action type」（26 ページ）と 102「Event type」（27 ページ）。PDF の 30、31 ページ目。表の「表すこと」は 102 の定義を要約したもの。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  4. 同じ資料の別表 5「アクションタイプ・イベントタイプの組み合わせ」（44 ページ）。PDF の 47 ページ目。表の「組み合わせられるアクション」は、この別表のチェックを行ごとに読んだもの。 ↩

  5. 同じ資料の別紙 1 の 87「Notional amount」（23 ページ）。PDF の 27 ページ目。 ↩

  6. 同じ資料の別紙 2 の 5（1）（6〜7 ページ）と、その脚注 8〜10。PDF の 54〜55 ページ目。 ↩ ↩2

  7. 同じ資料の別紙 1 の 26「Prior UTI」（9 ページ）、103「Event identifier」（27 ページ）。PDF の 13、31 ページ目。 ↩ ↩2

  8. 同じ資料の別紙 1 の 104「Event timestamp」（27 ページ）。PDF の 31 ページ目。 ↩

  9. 同じ資料の別紙 1 の 105「Index factor」（28 ページ）の参考例を、数値を変えずに言い換えたもの（想定元本 10 億円、1 銘柄 2,000 万円、決済後 9 億 8,000 万円）。PDF の 32 ページ目。 ↩

  10. The Foreign Exchange Committee「Management of Operational Risk in Foreign Exchange」（2010 年 11 月改訂）の序文（6 ページ）。 ↩

  11. The Foreign Exchange Committee「Management of Operational Risk in Foreign Exchange」（2010 年 11 月改訂）の Best Practice no. 11「Review Amendments」（18 ページ）。 ↩

  12. 同じ資料の「Confirmation」の節の Process Description（21 ページ。Best Practice no. 12 と no. 13 の間）。 ↩

  13. 同じ資料の Best Practice no. 11「Review Amendments」（18 ページ）の最後の段落。 ↩

  14. FINOS「Common Domain Model」の「Event Model」のページ（バージョン 7.0.0）の「Trade State」と「State」の節。 ↩

  15. 同じ資料の Best Practice no. 7「Use Straight-Through Processing」（15 ページ）。 ↩

  16. 同じ資料の Best Practice no. 7（16 ページ）。 ↩

  17. Duffie, Li, Lubke "Policy Perspectives on OTC Derivatives Market Infrastructure"（Federal Reserve Bank of New York Staff Report no. 424、2010 年）の 19 ページ。 ↩

  18. 日本銀行金融市場局・金融機構局、金融庁総合政策局・監督局「円LIBOR移行対応の振り返りと今後の取り組み」（日銀レビュー 2022-J-8、2022 年 5 月）の 2 ページ。 ↩

  19. Board of Governors of the Federal Reserve System "Trading and Capital-Markets Activities Manual" の Section 2040.2「Examination Objectives」の 7 番（1998 年 2 月）。 ↩

  20. The Foreign Exchange Committee「Management of Operational Risk in Foreign Exchange」（2010 年 11 月改訂）の Best Practice no. 24「Establish Exception Processing and Escalation Procedures」（27 ページ）。 ↩