日本における証券ITのフロント、特に株式とFXの分野では、アルゴリズム(Algorithm)、ダークプール(DarkPool)、スマート・オーダー・ルーティング（SOR）、流動性のアグリゲーション(Aggregation)、という分野において、現在各大手証券会社、銀行、外国為替証拠金業者などで様々なシステムの選定や導入が進んでいます。

　ところが、実際に導入をはじめてみると中々難しい問題があります。

　たとえば自社開発（もしくはベンダに委託して開発）の場合は、それなりの開発期間が必要なため、本番稼働までに多大な開発期間を要し、また開発コストもかかります。そして、実績がないため、本番稼働後の障害リスクも高めです。また、このようなシステムは今後何年も改良を重ね続けていくシステムですので、柔軟で向こう３年から５年は最低使えるような設計にする必要があり、このようなシステムを全体的なシステム処理能力を落とさず綺麗に設計できるエンジニアを擁している会社も少ないでしょう。

　では、パッケージ製品はどうでしょうか？　　完全なパッケージ製品を導入するメリットは、安定性と導入期間の短縮、そしてコストの削減です。しかし、パッケージ製品は、柔軟性において問題がある場合がほとんどです。導入当初のシンプルなストラテジーや、機能の実装は簡単にできるとして、その後どんどん複雑なロジックを組み込もうとする際に、パッケージの開発元のベンダの都合で、組み込めなかったり、組み込めても時間がかかったり、コストが大幅に増えたりするというリスクがあり、実際によく起こることです。　それは、パッケージへのカスタマイズが、多くの場合ベンダ側でコントロールされているからです。

　それでは、CEP(Complex Event Processing)エンジンの利用ではどうでしょうか？確かに複雑なイベントの処理、という点においてこれらの製品は貢献しますが、導入に際しては、やはりかなり大がかりな肉付けを要します。例えば、イベント処理は、あくまで“イベント”ですので、”注文“とは違います。イベントは処理すれば終わりですが、注文は、親注文がどのように子注文に分割され、それぞれの子注文がどのように市場において発注され、約定したり、取り消されたり、また障害時に巻き戻すため、たえず注文の状態を把握しておく必要があります。

　スマートトレードテクノロジーズは、これらのいずれの方法とも違うシステムを提案しています。　　それは、「堅牢なパッケージでありながら、ユーザが柔軟に業務ロジックのカスタマイズや、社内外システムとの接続を行えるシステム」です。

　パッケージとして、非常に迅速な導入が可能で、最短３～６ヶ月で本番稼働にこぎつけることができます。また、同じコードベースを日本を含めた世界の18社の大手・準大手の金融機関で提供しているため、非常に動作が安定しています。それでいて、スマートトレード社の製品群は、ユーザが自由にロジックをカスタマイズできるようになっています。これにより、ユーザは、スマートトレード社の人的リソースに頼ることなく、独自にカスタマイズを自由に行えるのです。そして、すべての製品が、完全にクロスアセットです。たとえば、複合板を作ることができる、“Aggregator”という製品がありますが、こちらは、板を値段ベースはもちろん、たとえば債券であればイールドベースで生成したりすることができます。

　1999年にCitigroup、 Credit Agricole、Société GénéraleのITおよびトレーディングのプロフェッショナルによってフランスで設立、ロンドン、ニューヨーク、パリ、東京など世界各地に拠点を持つ。

　リアルタイムに同時に存在する多数の流動性（取引所、PTS、OTC、ダークプール）を効率的に運用することで収益の最大化を追求する流動性管理システムLMS（リクイディティマネジメントシステム)を中心に、世界の大手・準大手金融機関18社に導入。

　株、債券、為替、デリバティブなどクロスアセットに対応、それぞれの価格情報を集約して複合板を形成、独自のアルゴリズムによるSOR（スマートオーダールーティング）や内部クロッシングの他、顧客注文フローの管理、注文のライフサイクル管理、障害復旧機能を持つ。

　共通データモデルの採用により、ビジネス要件に応じた社内外の変化に対し迅速な対応が可能。

　先日開催されたＦＸウィークＵＳＡカンファレンスにおいて、何度も取り上げられたテーマは、ＦＸトレーディングプラットフォームの増加だった。少なくとも８つの新しい取引プラットフォームが、過去数か月の間に発表された（Tabbフォーラムの“Is FX Hot? The Marketplace Says Yes”より）。これは果たして良い事なのだろうか？　人々の見解は分かれる。

“The Changing Frontier in FX Trading”　というパネルディスカッションで、何人かの参加者はプラットフォームのこのような増加傾向は、持続不可能であり、流動性にネガティブなインパクトをもたらすと言及した。他の参加者は、それぞれのプラットフォームは独自の価値提供を謳っており、新しい市場参加者をＦＸ市場に引き寄せることにより、市場全体の流動性を増加させることになると感じている。講演者の一人は、プラットフォームの増加により、ＦＸのような店頭市場において、流動性を発見することを更に困難にするのではないかと言及した。プラットフォームのいくつかは、ある特定の市場参加者グループを引き寄せるように特化しているように見える。

私はＦＸ市場を、グレート・バリア・リーフ（オーストラリア北東岸に広がる世界最大のサンゴ礁地帯）のように、生命体が織りなすエコシステムとみなすことができると考えている。　私がグレート・バリア・リーフでダイビングをした時、一番印象的だったのはあらゆる種類の生物が自然によって課された己が目的のために生存しながら、同時に共存しているその多様性だった。このような多様性の力が、グレート・バリア・リーフを世界最大の生命体による構築物にしたのだ。

同様にＦＸ市場は、シングル・バンク・プラットフォーム、ＥＣＮ、顧客向けのカスタマイズされた取引プラットフォームなど、生命体（私達）によって築き上げられた複雑な構築物である。これは異なった生命体（取引市場・プラットフォーム）が、「礁」に根付こうとする進化の過程と言える。ここで質問として、彼らは生き残ることができるだろうか？　生物界と同じように、全てが生き残ることは無理だろう。

市場が生き残っていくためには、当然顧客が必要だ。顧客にとって多様性というのは、すばらしいことだが、同時にあらゆる流動性のソースにアクセスできるかどうかが鍵になる。つまり、銀行や他の市場参加者は、今まで以上に更に多くの流動性を提供するソースと接続する必要に迫られることになり、市場の分裂や統合のサイクルが、すでに稼働限界となりつつある、対外接続チームやＩＴチームに更に負荷をかけることになる。多くの新しいプラットフォームにとって、顧客や銀行を接続し終わる頃には、勢いをなくしているということになりかねず、この要因がプラットフォームのリスク要因となる可能性が高い。

奇妙なのは、対外接続インテグレーションのパイプラインの滞留の原因はテクノロジーではないということだ。　　ほとんどのプラットフォームはＦＩＸプロトコルを採用しているし、ＦＩＸによる接続は容易だ。しかし、実際には新しいプラットフォームとの接続には、様々な困難が付きまとう。ＩＴ側にはキューがあり、一つの変更はそれに関連するワークフローの変更が必要となり、慣習は変更を困難にすることもある。また、たとえトレーダーが新プラットフォームに対して魅力を感じて利用したいと願っても、ＩＴリソースを確保できなければ、そのプラットフォームを利用することはできない。いずれにせよ、ほとんどの組織において、外部接続は時間がかかる。これは質問に値する：　外部接続のパイプラインをもっと効率良く運用する方法はないのだろうか？

いくつかの銀行は、すでに彼らの外部接続機能をアウトソースし始めている。　FX SpotStreamはその一例だ　－　単一のＡＰＩで複数の流動性プロバイダへのアグリゲーションとアクセスを提供している。　スマートトレード社のLiquidityFXは別の例だ。スマートトレードのようなベンダに接続とワークフローを任せることにより、市場参加者は新しいプラットフォームへの接続をより早くより確実に行うことができる。

ＦＸエコシステムの中で誰が生き残るのか、それは誰にもわからない。ただ言えるのは、「顧客」がいる限り異なるＦＸプラットフォームが共存することができるということだ。

Peter Atkinson,
FX Product Manager,
SmartTrade Technologies

ピーターは、ＦＸ　Ｅコマースのスペシャリストです。彼の経験は、いくつかの投資銀行における低レイテンシープライシング、マーケット・メイキング、トレーディングおよびリスク管理機能などの提供によって、培われてきました。
彼はビジネスとシステムの両方に明るく、30人以上の世界各地域に散らばった開発チームとの連携で仕事をしてきました。彼の得意な分野は、金融機関のアーキテクチャに対する現実的なアプローチをすることにより、ビジネスとしての結果にフォーカスすることです。
彼は、金融市場におけるクロス・アセットのフロントからバックオフィスまで、フロー商品（ＦＸ、株式、債券）のみならず複雑な商品（金利デリバティブ、エクイティデリバティブなど）の各分野で経験があります。　　

◎コラムの原文（英語）はこちらへ