CDM

FINOSという金融業界のオープンソース化を推進しようという団体がCommon Design Model(CDM)というデータモデルを提唱している。GS, JPM, MS, UBS, Barclay等々の業界のTopTierの銀行やISDA, ISLAといった業界団体が共同で進める金融データ（デリバやレポ）の標準データモデルである。えー、それってFpMLじゃないのー？と思ったあなた！私も初めて目にしたとき、同じ印象を持ちました。。。お客様や周辺の金融業界人も、ほぼ同じ反応をします。ただ、今度のモデルは一味違います。一言で説明するのが難しいのですが、Building Blockによるデリバティブ取引の経済条件＆イベント処理の表現の標準化と構造化と理解しています。とくにこのイベント定義と処理フローをモデル化しているところが肝です。取引条件を柔軟に表現することができるのが静的な表現力だとすると、取引のライフサイクル管理のモデル化は動的な表現力と言えるかもしれません。

Building Blockといえば、10年前にエキゾチック・デリバティブの評価ロジックの延長としてCVA評価モデルの開発などを行っていましたが、洗練されているとは言い難いものの、Building Block的にInstrument定義をして、それに対応した評価ロジックを当てはめて、少なくとも定義されたBlockの組み合わせの範囲では、汎用的に評価できるものを実装していました。そのさらに10年ほど前には色々な仕組み商品が登場しており、当時の私は計算ライブラリのプロトタイプも実装していたのですが、原型をとどめないまでに、ことごとく書き換えてくれた、C++の先輩から、「仕組系のデリバティブ商品のプライシングこそ、オブジェクト指向的に実装すべきだ。」と言われ、「あ、確かに～？！」と、目が覚めるような気付きがあったことは今では懐かしい思い出です。（いや、新人の頃から目にしてたクォンツライブラリのコードが、引数つぎはぎだらけだったのですがそれが当たり前だと疑いもしていませんでした）
当時のお客様から、ビジネスのスピード感を失わないような商品拡張ができる基盤が必要だと何度も言われ続け（・・・今も？）、ビジネスドメイン知識を体系的に構造化し、それをオブジェクト指向で表現するのが最も適していてその解としてBuilding Blockを提唱していたのですが、中々、エンジニア陣の理解を得ることが難しかったので、自チームのライブラリをBuilding Block型にリファクタしてました（＝先輩が）。
ただ、評価ロジックの内部はイベント管理を行う必要がなく、イベント適用後の状態でデータを受け取り、ペイオフ評価をするだけ(*)だったので、商品性表現にしか力を注いでいなかったのですが、今回、CDMについてキャッチアップするにつれ、イベント処理周りも標準化しているところが、久しぶりに「あ～、確かに～？！」となりました。

現在、お仕事絡みで、色々調べて、動画見て、深夜時間帯のワークショップやWGに参加して、アイデアまとめて、試作品を作ってます（＝生成ＡＩが）。
業界全体のコミュニケーション・コスト抑制が、本取り組みの背景にあるとは思うのですが、金融機関内部の非競争領域のコスト削減というテーマでみても重要な、もっと日本で広まるべき技術だと思っているので、CDMネタはもう少し続きます。

*: CVAの場合は将来複数時点のシミュレーションをしているので、経路依存性を適切に評価する必要があり、その範囲でイベント考慮が必要でしたが、ここまで整備はしていませんでした。