情報技術のためのモスクワ取引所のマネージングディレクターであるセルゲイポリヤコフは、記者NAUFOR（全米株式市場参加者協会）のイリーナ・スリュサレワに、統合ITアーキテクチャの仕組み、積極的なリスク管理のコストについて、既製のものを購入するよりも早く構築できる理由について語っています。

「統合の構築」。

あらゆる状況で成長と発展を可能にするデザインを作成する際のアーキテクチャの変革のアイデア



-セルゲイ、モスクワ取引所では、すべての市場向けの統一技術プラットフォームの作成と開発を担当しています。 これについて詳しく話していただけますか？ プラットフォームはどのように進化しますか？



-現在、モスクワ取引所の3つの大きな取引フロア-株式、デリバティブ、および外国為替市場-は、2つの技術プラットフォームに基づいています。

ASTSプラットフォームは、元はMICEXの技術者によって構築されたNASDAQテクノロジーに基づいて開発されたシステムです。 株式、債券、通貨、貴金属、マネーマーケットが取引されています。 2番目のシステムはRTSから私たちに来て、SPECTRAと呼ばれます。それはデリバティブ市場です。

単一のMOEX ITプラットフォームは、一方の取引システムが他方の取引システムに置き換わるプロセスの結果であるか、両方を破棄してすぐに3番目のシステムが表示されるという意見があります。 質問は原則として実際にはそうではありません。 特定の市場の特性を考慮に入れた高度に専門化されたトレーディングシステムの完全な代替。 このような置換のプロセスでは、すべてのビジネスロジック、長年にわたってアプリケーションシステムに蓄積されたすべての知識を再作成する必要があります。 このようなプロセスには1年以上かかることがあり、通常は失敗に終わります。 不採算で、不合理で、危険です。

プラットフォームの組み合わせは発生しますが、彼らが考えている形ではありません-機能の統合が行われます。つまり、市場の軸ではなく、取引、清算、リスクなどの主要な機能領域に沿って技術の方向を決め始めます。



-そして、プラットフォームはどのような形で統合されますか？ 特定のプラットフォーム、特定の技術ユニット、またはあなたがそれを呼ぶようにゾーンの例で、技術的パスを正確に議論するかもしれません。



-繰り返しますが、アプリケーションを統合する際の主な難しさは、テクノロジーそのものではなく、さまざまなビジネスプロセスにあります。 市場は、参加者のカテゴリ、それらの要件、および彼らのビジネスのタイプに応じて異なって配置されます。 これらすべてをテクノロジーレベルで組み合わせることは、先ほど説明した機能分野のビジネスモデルが統一されるまでは意味がありません。

ビジネスプロセスが似ている場合、タスクは簡単です。 たとえば、入札は、継続的なオンラインオークションを使用するすべての市場でほぼ同じ入札プロセスです。 ここで単一のテクノロジーを作成または購入するのが最も簡単ですが、これは緊急には必要ありません-既存の取引機能はうまく機能します。 複雑で興味深いのは、リスクのクリアと計算を担当するシステムの部分から始まります。 参加者の種類、資産の種類の明確化、マージニングと担保、特に会計と決済のルールの違いなど、異なる市場のビジネスモデルの違いが明らかになることは明らかです。 したがって、クリアリングテクノロジーの統一は、ビジネスプロセスの調和に沿って行われる必要があり、まさにこれが現在起こっていることです。

たとえば、モスクワ証券取引所では、リスク管理をビジネス機能として標準化するための大規模なプロジェクトが現在実施されています。 次に、IT部門は、統合の原則に基づいて構築された、システム間の相互作用に必要な特性を作成する技術基盤を準備しています。 同時に、現在のトレーディングシステムに直接実装されている多くの非トレーディング機能を引き受ける並列情報構造を作成する最新のアーキテクチャおよびエンジニアリングソリューションが使用されています。 同時に、後者はアンロードされ、メイン機能の信頼性と生産性が向上します。 たとえば、外国為替市場の別の取引モジュールが最近テストされました。 現在のシステムは、1秒あたり2万件のトランザクションを処理できます（現在8〜12,000件のトランザクションがピークに達しています）。新しいモジュールは1秒あたり4万件のトランザクションのパフォーマンスを示しました。 同じ作業が他の市場でも行われています。



-大まかに言えば、平行な背骨を構築していますか？



「私たちはモジュール式の情報アーキテクチャを作成しています。実際には、2つの「スパイン」があります。取引オペレーション用の高速のものと、より機能豊富なものですが、他のすべてのものには遅いものです。 これらのスパイン（タイヤと呼びます）の周囲には、機能モジュールがあります：個別のリスク計算モジュール、クリアリングモジュール、取引モジュールが作成されます。 その後、ビジネスプロセスの編成方法に応じて、異なるスキームに従って、異なる組み合わせでモジュールを相互に接続することができます。 これが私たちの変革の意味です。 あるシステムを別のシステムに置き換えることではなく、既製のモジュールのセットが作成され、そこからビジネスに必要なものが作成されます。

タイヤとスパインについて話す場合、技術革新のプロセスで重要なことは統一プラットフォームであり、これが私たちの努力の焦点です。 取引所は、すべてのプロセスがハードリアルタイムモードで動作し、アカウントがマイクロ秒で費やされるビジネスと考えるのが一般的です（3億5千万秒でトランザクションを処理します）。 IBM LLM超高速バスに基づくテクノロジープラットフォームにこのようなプロセスを移行しています。 しかし、すべてのプロセスがそのような速度を必要とするわけではありません。 多くのこと-同じクリアリング、計算、担保管理-は、たとえば、10分の1秒に焦点を当てた「人間」の時間モードで実行できます。

したがって、私たちはデータグリッドとエンタープライズシステムバスというテクノロジーを組み合わせた新しいレイヤーを構築しています。 Data Gridを使用すると、多くの取引システムで生成された情報を1か所に統合​​し、100分の1秒の遅延で利用可能になり、その後のリスク計算や清算などに使用できます。 Enterprise System Busを使用すると、複数の独立したシステムにわたる分散トランザクションを管理できます。

新しい情報アーキテクチャにより、以前の要素を大量に削除することなく、新しいサービスとアプリケーションを十分に迅速に作成できます（もちろん、特定の交換が必要になったときに何かを交換します）。 これは、交換のためのまったく新しいアプローチです。

過去1年にわたって、新しい統合プラットフォームの多くのコンポーネントを構築してきました。現在、既存のアプリケーションの転送と新しいアプリケーションの構築を開始しています。

モジュールが分離された通貨およびデリバティブ市場の取引システムは11月に稼働し、すべての作業は2016年末までに完了します。



-システムを環境に適合させる問題、その開発はすでに建設のイデオロギーに組み込まれていることを正しく理解していますか？



「はい、正確に。」



-そして、どうなりますか？



-財務省やロシア銀行などの重要なクライアントからのものを含め、常に新しいタスクが表示されます。 たとえば、最近、通貨レポなどの複雑な製品や、額面インデックス付きのOFZを発売しました。 金融市場は発展途上にあり、新たな緊急課題が絶えず発生しています。 それらの実装には、主にクリア機能の変更が必要です。

今日、清算機能は取引および清算システムの一部です。 私たちが話しているITアーキテクチャの変革と、取引システムからのクリアリングの分離の後、システム全体の安定性に対するリスクを抑えて、より迅速に新製品を実装できます。



-印象的な計画を実行できる主な経済的パラメーターは何ですか？



-一般に、今後3年間のITインフラストラクチャの保守と開発にかかる費用は、64億ルーブルになると計画されています。 これらの製品は非常に慎重に使用しています。 既存のすべての代替品として、巨大な西洋システムを購入するというアイデアがありました。 しかし、このようなシステムは当社の取引ビジネスプロセスに対応しておらず、市場の要件に合わせるためのコストが購入価格を上回ることがすぐに明らかになりました。 しかし、最も重要なことは、新しいシステムを購入しても現在の問題が1つしか解決されず、さらなる開発の問題が解決されないことです。 適用された変換ではなく、アーキテクチャの概念は、どの方向に移動する必要があるのか​​まだわからない状況でも成長および発展できる構造を作成することです。

ITストラテジストのタスクは、現在存在する要件を理解し、10年前に要件の変化の程度を概算し、今後10〜20年にわたってそれに対応するために必要な技術設計のタイプを予測することです。 私の仕事は、安定した、変更しやすい技術アーキテクチャを作成することであり、現代の西洋システムを購入して、現在の特定の要件に従ってそれを完成させることではありません。 これは、特に、経済的により効果的なソリューションです。



-モスクワ証券取引所が非常に複雑な場合、西側ではどのように配置されていますか？参加者にライセンスを与え、リスク評価に従って誰もが望むように取引しますか？



-外国のサイトでは、原則として、参加者には取引制限が与えられます。 それがリアルタイムで現在の値に対応するかどうかを確認することはできませんし、しません。また、清算機関が組織的に取引所と接続されていないDTCCまたはOCCであるニューヨークなど、単に構造的に不可能な場合もあります。 ロンドンでも状況は似ていますが、LCHはLSEの一部になっています。 これらの取引所では、ブローカーは予備的なリスク評価機能を実行します。これは、これらの取引所の参加者の規模と信用の質を考えると、非常に信頼できます。 もっと「トリッキー」なやり取りがあります。 たとえば、Deutsche Borseは注文をコンパイルし、トランザクションがクライアントの許容リスク値に対応するかどうかをトランザクションがチェックした直後に。 そうでない場合、これらのクライアントの交換は「切断」されますが、これはトランザクション後に発生します。

ロシアでは、証券会社の規模がはるかに小さいため、モスクワ取引所がリスク評価機能を引き継ぎます。 実際、私たちはリアルタイムで各アプリケーションのリスク評価を行う世界で唯一の取引所です。



-ITシステムにとってこれはどういう意味ですか？



-モスクワ取引所では、平均して、取引プラットフォームは1秒あたり6〜1万のアプリケーションを占めています。 これは、マッチングモジュールに入る前に、アプリケーションがクリアリング/リスクモジュールに移動し、参加者の担保とマージンのコンプライアンスのチェックに合格する必要があることを意味します。 これはプロアクティブなリスク管理と呼ばれ、この検証は試合自体よりもはるかに複雑です。 お気づきのように、リスク/クリアリングモジュールはアプリケーションの情報モジュールよりもはるかに複雑であり、さらに、絶えず変更が行われています。新しい製品やサービスが導入されています。 したがって、さまざまな問題の原因は常に取引モジュールではなく、リスクと清算モジュールにあります。 典型的な西側の取引所にはそのような問題はありません-マッチングのみがあります。

モスクワ証券取引所で、ニューヨークで起こっているように注文のみを組み合わせていた場合、過去2年間で実質的に停止はなかったと思われます。 これは、リスク管理プロセスの並外れた品質の代価です。 他のサイトの同僚にこれをやっていると伝えると、彼らはただ驚いて口を開くだけです。

私たちの変更と革新の10のうち9は、クリアリングモジュールで発生します。クリアリングモジュールは、毎秒数千回、各注文のリスクを解決してチェックする必要があります。

新しいアーキテクチャでは、取引モジュールと清算モジュールを分離し、オフライン取引モードを確立することを計画しています。このモードでは、制限を使用してリスク注文を確認します。2分とすると、必要に応じて取引を停止せずに清算モジュールを再起動できます。



-アルゴリズム取引の開発は、取引技術にどのような影響を与えましたか？ MOEX取引ロボットはどこから来たのですか？ どの市場で最も活発で、どのような問題が生じていますか？



-クライアント取引の技術および技術としてのアルゴ取引は、10年前から行われています。 Moscow Exchangeで使用されるITシステムは、もともとアルゴリズムの取引に必要な実行速度とサービスレベルのために作成されました。 交換の主なタスクは、アルゴリズム取引をサポートすることです。 これは速度ではありませんが、速度と制御のバランスを維持します。 ほとんどのプログラマーは、技術的にブローカーをバイパスして市場に直接接続する必要がありますが、ブローカーはすべてのトランザクションを担当します。 したがって、アルゴリズム主義者の市場への直接アクセスをサポートする（「スポンサー」）ブローカーは、彼らの業務を管理できなければなりません。 これを行うには、特殊な技術（スポンサー付きアクセス）が必要です。これは現在再構築中です。

ちなみに、これは新しいプラットフォームの別のコンポーネントです-取引所への直接アクセスのためにスポンサーしたアルゴリズムトレーダーの操作をよりよく監視できるブローカー専用のサービスの開発。

アルゴトレーダーに戻ると、アルゴトレーダーと高周波トレーダーは必ずしも同じものではないことを理解すべきです。 高周波トレーダーの場合、戦略は、可能な限り高速なオペレーションの実行に基づいています-たとえば、1ミリ秒の間、市場に存在する機会をつかむためです。 中頻度戦略を実装するアルゴリズムトレーダーがいます。 彼らはマクロトレンドで稼ぎます、彼らにとって最大の実行速度は重要ではありません。 市場からアルファをまったく抽出しようとしない3番目の種類のプレーヤーがいます。 彼らは単に、購入/販売注文を実行するプロセスの自動化に努めています。 そのようなブローカーがクライアントから大量の注文をしていると仮定すると、価格を落とさないように、彼はアプリケーション全体をすぐに市場に投入したくありません。 次に、特定のアルゴリズムで操作を取り戻すロボットをセットアップし、市場全体よりも優れた行使価格を探しません。

異なるアルゴリズムトレーダーは、交換システムに異なる方法で影響を及ぼします。なぜなら、それらの一部は原則として人々の代わりであり、他の人はテクニカルアナリストになろうとし、他の人は非常に迅速に取引してそれからお金を稼ごうとするからです。 取引所市場でのアルゴリズムトレーダーのシェアは、取引量の約50％です。



-MOEXシステムが市場参加者と対話するときに生じる主な問題は何ですか？ ロシアのブローカーと外国のブローカーとのやり取りに違いはありますか？



-大規模なブローカーと小規模なブローカーの間には違いがありますが、それは単に彼らが手に入れることができるインフラストラクチャのレベル、つまり自動化と製造性のレベルが非常に異なるからです。 ロシアの大手ブローカーは、サポートや取引プラットフォームとの相互作用の点で、使用されているテクノロジーの品質において何らかの点で外国の大手ブローカーより劣っているとは言えません。



-したがって、次の質問にスムーズに進みます。 市場に技術的な遅れはありますか？



-ロシアの株式市場には技術的な遅れはまったくありません。 何らかの種類のバンドルがある場合は、既に述べたように、ビジネスの規模に応じて発生します。 この市場の配置方法には違いがあります。

ブローカーの典型的な西部のエコシステムは次のように配置されます。 特定の数のブローカーが、清算機能と、注文の履行、マーケティングサービス、およびクライアントとの連携の両方の機能を実行します。 他のブローカーは、ブローカーの実行という1つの特殊な機能のみを引き受けます。 別のカテゴリーのブローカーは、取引所への最速のアクセス技術を構築するのは高価であると考えていますが、クライアントとうまく機能する方法を知っています（ブローカーの紹介）。 したがって、彼らはクリアリング構造を構築することを気にしません、非常に高価な実行技術に投資します。 彼らの主なスキルはバイヤーを見つけることです。

このような層別化は行われていないため、さまざまなサイズと機能、そしてその両方、および3番目を扱うブローカーがたくさんいます。 一部の企業は優れたリスク管理を備えており、独自のシステム、十分に構築されたインフラストラクチャを備えており、欧米のブローカーと違いはありません。 小規模のブローカーは、取引所が提供するサービスにより依存しています。 そして、これはロシア市場の特徴です。



-ECNの経験はロシア市場で使用できますか？ たとえば、人々が単純に注文を減らし、このために市場に顧客を引き付けるときに、取引形式が発生する可能性がありますか？



-ビジネスを行っているブローカーの資本が比較的低いロシアの状況では、単に取引を終了する取引プラットフォームは、それ自体または他の誰かの崩壊につながります。 これは問題外です。 清算のリスクとセキュリティの両方に注意する必要があります。

清算を脇に置いておくと、ECNは上場がないという点で取引所と形式的に異なります。 リスティングは何のために必要ですか？ たとえば、1,000万人が不動産に投資するのではなく、会社を買収したいとします。 上場手続きにより、投資家はあなたの会社が信頼できる管理下にあり、最新の会計があり、すべてが透明で、そこにお金を投資しても安全であると確信できます。 西洋では、外国企業に投資する文化が長い間存在していました。 取引所に上場すると、投資家は多くの要因が検証されたことがわかり、他の人のビジネスへの投資がより魅力的になります。

ECN : , . ECN, , , , . — , «best execution». , ECN, . , , , , «» . , — . , - . , , , . — «».



— , . , ?



— ECN, — , .

- . ECNs 90- — 2000-, , , .

, . — - ( ). , . , , ITG , , .

. , .

, ECN, — . , , , , — . , .



— - ?



— - Data Space. Tier III Gold. . 2016 - .

— . . , - 10 15.30-16.00. . 36 . - . , , — , .



— ?



— , , . 10 12 . . IT- (). , , . , , , . , , « ».



( )