要約

  • Murexは9月23日、MX.3がGoogle Cloudの認証を取得したと発表した。AzureやAWSを含む従来のクラウド展開に新しい候補を加える出来事だが、発表は本番稼働の顧客、移行期間、価格、性能値、復旧実績を示していない。
  • 認証は別の基盤を検討する費用を下げる。一方、最後に確定したポジション、担保、相場時点、権限、外部接続、照合結果や日次処理の順序は自動では移らない。それらを許容停止時間内に再構成できて初めて、退出先は実用的な選択肢になる。

障害対策の図面に新しい雲を描くのは簡単だ。そこへ生きた資本市場業務を移すには、図面に現れない順序が必要になる。どの市場データを評価に使ったのか。担保の移動は相手側で確定したのか。支払指図は取消可能な段階か。夜間処理のどこまでが承認済みか。復旧先のサーバーが動いても、この問いに同じ答えを返せなければ取引は再開できない。

9月23日のMurex発表は、MX.3がGoogle Cloudで認証され、取引、財務、リスク、ポストトレードの業務を配置できるとする。市場リスク、カウンターパーティーリスク、日中分析のような計算負荷の高い処理も対象に挙げる。複数顧客が可能性を検討しているとも説明した。

ここには重要な進展がある。同時に、公表された境界も明確だ。具体的な本番顧客、稼働開始、移行所要時間、回復時点、回復時間、契約価格や照合結果はない。認証は到着可能な場所を示すが、ある銀行が業務状態を壊さずにそこへ到着できることまでは示さない。

三つ目の行き先は行使前のオプションだ

MX.3のクラウド展開は今回から始まったわけではない。Murexは2017年にAzure認証を発表した。現在のクラウド紹介はAWSとMicrosoft Azureへの対応、概念検証から開発・試験、本番へ進む段階的な導入を説明する。2025年には、マネージドサービス拡大を含むAWSとの複数年契約も公表した。

Google Cloudの追加が生む最初の価値は、選択権である。新規導入なら、基盤、地域、セキュリティー、運用提案を競わせやすくなる。既存顧客なら、開発環境、災害復旧、弾力的なリスク計算を別の事業者へ置く議論ができる。Murexは販売・支援経路を増やし、Googleは金融機関の中核に近い処理を呼び込める。

この価値は、本番全体を移さなくても発生する。見積もり条件が変わり、試験環境の払い出しが速くなり、計算網だけを伸縮させられるかもしれない。ただし、部分ごとに意味が違う。リスク計算を別環境へ出せることは、フロントからバックまでの記録体系を交換可能にすることではない。調達先が増えることも、退出費用の削減を直接意味しない。

運用形態も分けて読む必要がある。MurexのAWS発表は、MXSaaSを基盤から更新までMurexが管理するサービスとして記し、XVA as a Serviceも別に説明する。Google Cloud発表はMX.3の配置を述べるが、MXSaaSをGoogle Cloudで提供すると発表してはいない。認証済みソフト、自社管理IaaS、製品化されたマネージドサービスでは、日常運用と障害・退出時の責任が異なる。

MX.3は一個の箱ではなく業務の連鎖である

MX.3のアーキテクチャー資料は、表示、業務、オーケストレーション、技術の各層を示す。技術層は認証、認可、サービス登録を担い、計算処理には複数の技術が使われる。複雑商品の評価はCPUまたはGPUのグリッドへ分散でき、市場リスクや報告処理ではKubernetesとコンテナも使う。

一部がコンテナだからといって、実装全体が密封された荷物になるわけではない。長年運用された環境には、商品、帳簿、参照データ、市場データ、証明書、鍵、権限、外部接続、バッチ順序、監視閾値、例外処理と、担当者だけが知る待ち合わせ条件が積み重なる。依存関係はコードだけでなく、データ契約、ライセンス、決済時間、社内承認にも存在する。

可搬性を四層に分けると誤解が減る。基盤の可搬性は計算、保存、ネットワークを再構成できるか。アプリケーションの可搬性は、対応するMX.3の部品と版が正しく動くか。データの可搬性は、順序と意味を保った状態を輸出し再生できるか。運用の可搬性は、新しい分担の下で安全に実行、照合、復旧できるかを問う。

認証は最初の二層について強い材料になる。後の二層は顧客ごとに異なる。どのマネージドサービスを使ったか、接続をどう設計したか、鍵と監視履歴をどこに置いたか、手順書を誰が所有し、代替先で業務復旧を実施したことがあるかによって決まる。

復旧の中心は最後に承認された状態だ

資本市場の復旧は、プロセスが再起動しただけでは完了しない。二重に取り込んだ取引はエクスポージャーを膨らませる。片側だけが認めた担保移転は紛争になる。異なる時点の価格を使えば評価額と限度額が変わる。締切後に送信済みの支払いを未送信として扱うこともできない。

退出用の資産には、データベースの複製以上のものが要る。合意した復旧点、順序付きジャーナル、発生源、未処理メッセージ、外部応答、ジョブ依存、照合規則が必要だ。対象ごとに正本を定め、食い違いを誰が裁定するかも決めなければならない。ソフトの版、設定、権限と承認記録も業務状態の一部である。

同じ仕様の機器を用意できても、営業可能なサービスを戻せないことはある。クラウド固有のデータベース、ID、キュー、監視、鍵管理やネットワーク制御は平時の品質を高める一方、再構成の対象を増やす。すべての固有機能を避ければよいのでもない。信頼性と開発速度を失いかねないからだ。重要なのは依存を記録し、費用と責任者を定め、代替経路で実際に扱ったかである。

最初の訓練は範囲を絞れる。一つの重要業務と障害条件を決め、代替先にアプリと依存を再構築する。管理されたデータと接続を戻し、ポジション、現金、担保、感応度、確認、会計出力を承認済み基準と照合する。所要時間、手作業、欠損、例外と合格を決めた人物を記録する。この記録がなければ、二つのクラウドは冗長な絵にすぎない。

規制は別の配置先ではなく退出能力を問う

対象となるEU金融機関には、DORA第28条が明示的な基準を置く。重要または不可欠な機能をICTサービスが支える場合、業務、法令遵守、顧客サービスの継続性を損なわずに契約から退出できる戦略が要る。計画は包括的で文書化され、十分にテストされ、定期的に見直される必要がある。代替策と、サービス・データを安全かつ完全に移す手順も求められる。

DORAはMX.3やGoogle Cloudの個別構成を認定しないし、全処理を常時複数クラウドで動かせとも述べない。焦点は金融機関の責任にある。ソフト会社が別の行き先を支援していることは助けになるが、金融機関自身の退出証明ではない。

イングランド銀行の運用レジリエンス研究は、外部委託や少数の第三者への依存が金融システム内の連結性を生むと指摘する。認証先の追加は調達上の集中を和らげられる。実務上の集中が下がるのは、重要サービスを許容時間内に移動または復旧できる場合だけだ。

運用モデルごとに責任を引き直す

Murexはソフトの認証、対応する配置方式、リリースと技術運用の一部を担う。Google Cloudは地域、基盤容量、ネットワークと各種マネージド製品を運営する。インテグレーターは着地点を構築し、自動化や一部運用を引き受ける。マネージドサービスなら、提供者が更新や監視をさらに広く持つこともある。

それでも業務サービスの判断は金融機関に残る。重要度と復旧目標を決め、データ・ID設計を承認し、市場データや取引所との契約を維持し、照合結果を受け入れ、取締役会と監督当局へ説明する。作業を委託しても、復旧したポジションの意味まで委託することはできない。

平時と退出時を並べた責任表が要る。構成コードを保守するのは誰か。設定、ログ、鍵、監視履歴を輸出できるか。移行中のライセンスは誰が用意するか。ネットワークを開き市場データを検証するのは誰か。復旧帳簿の取引再開を承認できるのは誰か。契約終了後の支援期間はどれほどか。一般的な提携発表は、こうした顧客固有の問いに答えない。

選択肢の増加が一時的に固定化を深めることもある

新しい認証先は逆説を生む。そのクラウドの固有機能が開発を速めるから採用され、データ、セキュリティー、監視が徐々に密結合になる。通常運転は改善しても、他所での再現費用は上がる。この交換は合理的になり得るが、認証数だけで退出費用を測れない理由でもある。

反対に、Murexが移植可能な配置資産、複数の対応データベース、明確な部品境界、共通の運用証拠を整備すれば、認証の追加は道を標準化する。顧客の移行が重なれば、人材と再利用可能な道具も増える。市場が見るべきなのはロゴの数ではなく、こうした実行の記録だ。

最も情報量が多いのは対象範囲である。稼働事例は、開発・試験、リスクグリッド、災害復旧、本番、またはフロントからリスクまでの全体のどれかを示すべきだ。復旧実績には業務名、復旧点、経過時間、照合結果が要る。退出実績なら、形式、契約支援、人員、接続作業と費用まで含めなければならない。