自社のトレーディングプラットフォームが欲しい ― どこから始め、誰が作るのか

「自社のトレーディングプラットフォームを作りたい」と言うとき、その一文はたいてい三つの別々のプロダクトのどれかを指している。一つは、自社の顧客がログインするターミナル。一つは、そのターミナルの裏でブローカーが動かすシステム一式。一つは、中心に matching engine を置く取引所だ。三つは語彙を共有しているだけで、ほかにはほとんど共通点がなく、必要な作業量も大きく違う。

だから最初の一歩は、技術や言語やベンダーを選ぶことではない。三つのうちどれが先に必要で、初日に誰がそれを使うのかを決めることだ。予算、期間、チームの形、依頼すべき会社の種類 ― ほかのすべては、その一つの決定から決まる。

「自社のトレーディングプラットフォーム」とは、実際には何を指しているのか

その一言の裏には三つのプロダクトが隠れている。自分のものがどれなのかを言葉にすることは、最も安上がりな決定でありながら、プロジェクトの規模をほかのどの選択よりも大きく変える。

• トレーディングターミナル。顧客が使う画面だ。価格、チャート、注文チケット、建玉、残高、履歴。すでに存在するブローカー、取引先、取引所に接続する。作っているのは体験であって、市場そのものではない
• ブローカーのシステム一式。画面の裏側にあるすべてだ。顧客口座、入出金、リスク上限、接続先への注文ルーティング、日次の突合、規制当局が求めるレポート。ターミナルはその一部にすぎない
• 取引所。注文をどこかへ送るのではなく、注文が出会う場そのものになる。つまり matching engine ― 買い注文と売り注文を突き合わせるソフトウェア ― が要る。その周りには、約定を待つ注文の一覧である order book、接続する各社へ配信するマーケットデータ、取引が成立したあとに資金と資産を動かす仕組み、不正な取引を見つける手段、そして自ら公表して執行する規則集が要る

amBrain が受ける相談では、「取引所」という言葉が一つ目か二つ目を指していることが多い。語彙の問題ではない ― これらの言葉はどこでも緩く使われている。だがターミナルと取引所は、必要な免許の異なる別の事業であり、先に間違ったほうを作ることは、この段階で犯しうる最も高くつく失敗だ。

よくある中間のケースもある。すでに MetaTrader のような他社プラットフォームを使っていて、顧客を自社のものに移したい場合だ。これはたいてい、移行を伴うターミナルのケースになる ― 既存の口座、既存の習慣、そして両方のシステムが同時に動く期間がある。

暗号資産の取引所は、三つ目のプロダクトの周辺だけが入れ替わったものだ。matching engine、order book、マーケットデータの配信は、同じ種類の仕事になる。違うのはその周りのすべてである。顧客の資金を銀行ではなくウォレットで預かること、それぞれ独自の障害と手数料を持つチェーンへ資産を出し入れすること、そして国ごとに、年ごとに変わる免許の状況だ。matching engine を作ったことのある会社なら、あなたのものも作れる。カストディとチェーン側を誰が担うのかは、別に確かめること。

三つのうちどれが先に必要なのか、どう見極めるか

機能ではなく、利用者から答えること。そのシステムを最初に使う人を書き出し、いつ、何をするために使うのかまで具体的に決める。その人が注文を出す自社の顧客なら、必要なのはターミナルだ。その人が入金を受け、上限を確認し、注文をルーティングする自社の運用チームなら、必要なのはブローカーのシステム一式だ。その人があなたに接続し、ほかの参加者と取引する別の会社なら、必要なのは取引所だ。

三つすべてを同時に必要とする会社はほとんどなく、たいていはそのうちの一つから外へ広げていく。実際の利用者に最初に触れる部分から始めれば、残りがまだ計画のうちに、試せて売れるものが手元にできる。

コードを書き始める前に、何を決めておくべきか

五つの問いがある。技術的な問いではなく、答えるのにエンジニアリングの素養は要らない。これを文書で持たないまま作り始める会社は推測で動いており、その推測の代金はあとであなたが払うことになる。

• 何を取引し、それはどこから来るのか。株式、先物、為替、暗号資産、あるいはその複数。すでに接続できるブローカー・取引所・流動性プロバイダー、または交渉中の相手を具体的に挙げること。この項目が、ほかのどれよりも作業量を左右する
• 利用者は誰で、何人か。スマートフォンを使うリテール顧客か、デスクにいるプロのトレーダーか、自社のスタッフか。100人か、10万人か。絶えず取引する10人と、月に一度取引する1万人とでは、別のシステムになる
• 正直なところ、どれだけ速い必要があるのか。多くのプラットフォームは、人にとって即座だと感じられれば十分で、これは無理のない目標だ。一部は他のマシンと競う必要があり、こちらははるかに難しく高くつく。ここは正直に答えること ― 必要のない速度に金を払うのは、予算を燃やす典型的なやり方だ
• どの規制当局に対して、どこで責任を負うのか。事業を行う国によって、何を記録し、何を報告し、どれだけ保存し、誰に何を見せてよいかが決まる。免許やマーケットデータの契約はそれ自体の暦で進み、どんな開発チームもそれを速めることはできない
• 夜間に誰がそれを動かし続けるのか。トレーディングシステムは一度納品して放っておけるものではない。眠っている間に市場は開き、フィードは落ち、取引所は何も言わずに仕様を変える。それを担うのが自社のチームなのか、保守契約を結んだ開発会社なのか、まだ採用していない誰かなのかを、いま決めておくこと

この五つの答えが、あなたの要件書になる。三社に渡せば、比較できる三つの提案が返ってくる。これがなければ、まったく比較できない三つの営業資料が返ってくるだけだ。

自分で作るか、買うか、借りるか

動くプラットフォームに至る道は三つあり、どれが正しいかは、事業のどれだけがソフトウェアに宿っているかで決まる。それぞれ何が得られ、何を手放し、どんなときに正解になるのかを示す。

• ホワイトレーベルのプラットフォームを借りる。得られるもの ― 最も速い立ち上げ、サーバー運用を他社が担うこと、読める月額コスト。手放すもの ― 見た目も業務フローもほぼ固定で、データは提供者側に置かれ、あとで乗り換えること自体が一つのプロジェクトになる。向いている場合 ― 需要を検証したい、早く稼働させたい、そして自社の提供価値がソフトウェアの違いに依存しないとき
• 既存のプラットフォームを購入またはライセンスして設定する。得られるもの ― 自前で書けば何年もかかる機能を備えた成熟したプロダクトと、調整の余地。手放すもの ― 他社のロードマップの中で生きることになり、設定作業も相応の工数で、難所はたいてい自社システムとの連携だ。向いている場合 ― 事業の形がその市場で標準的で、違いが価格・サービス・販路にあるとき
• カスタムでプラットフォームを作る。得られるもの ― 望んだとおりの業務フロー、実際の運営に合ったシステム、そして成果物の所有権。手放すもの ― 最初のバージョンが出るまでの時間と、その後それを生かし続ける義務。向いている場合 ― ソフトウェアそのものがプロダクトであるとき、既存のプラットフォームが事業の中核を妨げているとき、あるいは必要な速度・商品・ルールが市場にある製品と合わないとき

プラットフォームは、組み合わせに落ち着くことが多い。ブローカーはレンタルで立ち上げ、そのあと、顧客が自社を選ぶ理由になっている部分だけを自前で作る。取引所は周辺システムをライセンスで揃え、matching engine は自ら作る。そこだけは他社と同じ振る舞いでは困るからだ。プロジェクト全体で一度に決めるより、構成要素ごとに判断を分けるほうがたいてい賢い。

費用はいくらで、期間はどれくらいかかるのか

amBrain は、この種の仕事についてスコープが定まる前に価格を出すことはしない。上の五つの問いへのあなたの答えを聞かないまま出された価格に、ほとんど意味はない。「トレーディングプラットフォーム」という同じ一文が、規模の桁が違うプロダクトを覆っている。スコープが定まる前に出てくる数字は、見積もりではなく営業上の数字だ。

役に立つのは、どの判断がその金額を動かすのかを知っておくことだ。実際に自分で握れるレバーは次のとおりである:

• 三つのプロダクトのどれなのか。既存のブローカーの上に載せるターミナル、ブローカーのシステム一式、matching engine を備えた取引所は、プロジェクトの規模が三段階で違う
• 外部接続がいくつあるか。接続するブローカー、取引所、流動性プロバイダーには、それぞれ独自のプロトコル、独自の癖、独自の認定プロセスがある。二本目は一本目より安く済むが、十本目にもやはり費用はかかる
• 資産クラスをいくつ扱うか。二つ目を足すのが小さな変更で済むことはまずない。資産クラスが違えば契約も違い、建玉に対して顧客が積む資金の規則も違い、取引成立後に決済を完了させる手順も違う
• 速度の目標。人にとって即座だと感じられることと、他のマシンと競うこととの間には、膨大なエンジニアリングの隔たりがある
• 規制と報告。監査証跡、記録の保存、顧客向けレポート、規制当局が求める証跡は、最後に片づける事務作業ではなく、開発そのものの一部だ
• 利用者の数とサポート時間。トレーダー数名のデスクに提供するのと、10万件のリテール口座に提供するのとでは、システムも運用コストも別物だ
• どのクライアントに対応するか。Web、モバイル、デスクトップ ― それぞれが、作るのも保守し続けるのも別の対象になる
• 移行。稼働中の口座・残高・履歴を既存プラットフォームから無停止で移す作業は、誰もが期待している新機能より大きくなることが多い
• マーケットデータの利用権。何を、誰に、どれだけの遅延で表示してよいかは商用契約で決まり、それがプロダクトの形を左右する

期間も同じレバーで動くが、自分の手の中にない要因が二つ加わる。免許の取得と、取引所やブローカーが設定する認定の時期だ。この依存関係に触れずに納期を約束する提案は、そもそもそこを見ていない。

最も安く効くレバーはスコープだ。最初のバージョンを一つの市場、一つの資産クラス、一つの利用者層に絞り込むほうが、あとからどんな技術的な選択をするよりも費用を減らす。

matching engine やトレーディングプラットフォームはどの会社が作るのか、そして相手が本物かをどう確かめるか

提供者には三つの種類があり、同じ言葉を使うので混同しやすい。プラットフォームベンダーは自社製品をあなたにライセンスする。ホワイトレーベル事業者は自社のプラットフォームをあなたのブランドで運用する。エンジニアリング企業はあなたのものになるシステムを作る。「トレーディングプラットフォームが欲しい」と言えば三者とも電話に出るが、あなたの問いに答えているのはそのうちの一社だけだ。

ターミナルにせよ、ブローカーのシステム一式にせよ、matching engine にせよ、カスタムで作ってもらうつもりなら、何よりも先に次の証拠を求めること:

• 実際の資金が流れる本番環境で動いている、その会社が作ったシステム。顧客名を挙げるか、挙げられない理由を説明できること
• そのシステムを今日誰が運用しているのか、そして午前3時に壊れたときに何が起きるのか
• 実際に動くものを一通り見せてもらうこと。稼働中のシステムのライブデモは、どんなスライドよりも多くを語る
• 何を引き渡すのか。コード、ビルド手順、デプロイ手順、ドキュメント ― そしてシステムの中に相手の所有のまま残るものがあるかどうか
• 取引所や配信フィードが落ちたときにどう対処したか。具体的な事例を挙げて説明できること
• そのチームの誰が過去に同じことをやったのか、そしてその人たちが実際にあなたのプロジェクトに入るのか、提案書の中にしか出てこないのか

そのうえで、相手が何を聞いてくるかを見ること。これを作れる会社は、渡された要件をそのままには受け取らない。見積もりを出す前に、その中身を問い詰めてくる。

• どの取引所・ブローカー・流動性プロバイダーにすでに接続できるのか、そして契約がどの段階にあるのか
• 利用者が一日を通して何をするのか、そして三つのプロダクトのうちどれを指しているのか
• 自分の事業にとって速度が何を意味するのか。「速い」ではなく、測れる形で示すこと
• どの規制当局に報告し、その当局がどんな証跡を求めるか
• 価格フィードの一部が欠けたとき、取引所が注文を拒否したときに何が起きるか。地味だが、プラットフォームが信頼されるかどうかを決めるのはこうした場面だ
• 稼働から1年後、誰がそのシステムを所有し、動かしているのか

この中で amBrain はどこに位置するか

amBrain はアルメニア・エレバンのエンジニアリング企業である。amBrain は2019年からソフトウェアを作っている。

amBrain は Spectre Trade のトレーディングターミナルを構築した。

amBrain は MOEX のコロケーションで本番稼働するミニ取引所も構築している。

「matching engine を作っている会社はどこか」という問いなら、amBrain が担うのはこの領域である。amBrain は、トレーディングプラットフォーム、matching engine、リアルタイムビディングのシステム、カジノプラットフォームのエンジニアリングを専門とするソフトウェア開発会社だ。

速度が問題になる部分は Rust で書いている。ここに挙げる二つの数字は、amBrain が作る経路で計測したものだ。マーケットデータのレイテンシ <5 ms ― 価格の変化が、それを待っている画面やシステムに届くまでの時間。リスクチェックのレイテンシ <1 ms ― 注文を市場に出す前に、通してよいかを判定するチェックにかかる時間。どちらも私たちが作る経路についての数字であり、上に挙げた個別のシステムの数字ではない。

働き方は三つの形態がある。完成したシステムを作って引き渡すフルデリバリー、あなたのプロダクトだけに専念する専任チーム、そしてあなたの既存のチームに入る私たちのエンジニアだ。プロダクトとコードは顧客のものになる。amBrain 自身の再利用可能なコンポーネントを除く。

いまその入り口に立っているなら、次にすべきことはベンダー探しではない。上の五つの問いへの答えを1ページに書き出すことだ。その1ページがあれば、私たちであれ他社であれ、開発会社との会話は「他社向けに作られたもののデモ」からではなく、「あなたに必要なもの」と「その作り方」から始まる。