ホワイトラベル取引所システムの選び方：6MM ホワイトラベル取引所の構築と受入テストガイド

1. ホワイトレーベル取引所の評価では、まず納品範囲を確認する

ホワイトレーベル取引所の2つのシステムは、デモ時点では非常に似ているように見えるかもしれません。どちらも市場データの表示、注文の送信、ポジションの照会が可能です。しかし実際のデプロイ段階になると、チームが答えるべき疑問はより具体的になります。取引ペアを上場させるのは誰か？注文と資金の履歴はエクスポート可能か？市場データは正常であるにもかかわらずユーザーが突然注文できなくなった場合、誰が最初に問題を特定するのか？

ホワイトレーベル取引所ソフトウェアの評価は、実際のビジネスプロセスから出発して行うことができます。無期限契約を例にとると、ユーザーのログイン、資金の振替、注文の送信から、約定と請求書の確認に至るまで、各ステップに関与するシステム、データ、担当者をリストアップします。これにより、どの機能を直接納品可能で、どの機能に二次開発が必要であるかがより明確になります。

2. デプロイ方法について確認すべき詳細とは？

ホワイトレーベル取引所は通常、パートナーのブランド名とドメイン名で外部に取引サービスを提供します。選定時には、デプロイの問題を3つの部分に分けることができます。

1. ドメイン名とフロントエンド。ドメイン名、証明書、フロントエンドの公開の責任者は誰か？ブランドスタイルの変更や新しい取引ページの公開時に、ベンダーの協力が必要か？
2. バックエンドと運用保守。どのサービスがベンダーによって保守されるか？パートナーはどの監視とログを確認できるか？障害発生時、双方はそれぞれどのような復旧作業を担当するか？
3. バージョンとデータ。アップグレード前にテスト環境で検証できるか？ロールバック時にアップグレード期間中の新しい注文はどのように処理されるか？注文、約定、口座履歴、バックエンドの操作記録を権限に応じてエクスポートできるか？

例えば、フロントエンドの公開後に注文リストに異常が発生した場合、チームはそれがページのレンダリングの問題、APIの応答異常、あるいは注文プッシュの遅延のいずれであるかを区別する必要があります。ログへのアクセス権限と障害対応プロセスを事前に取り決めておくことで、こうした問題の調査時間を短縮できます。

3. 流動性の検収では実際の約定を確認する

デモ環境の板情報は、取引インターフェースを理解するのに役立ちます。検収段階では、計画されている上場取引ペアと典型的な発注規模に応じて、売買スプレッド、板の深さ、実際の平均約定価格、未約定数量をそれぞれ確認する必要があります。

簡単な例を挙げます：売値1は100で、2口約定可能です。次の段階の売値は101で、3口約定可能です。1件の買い注文がこれら2つの段階をすべて消化した場合、5口の平均約定価格は100.6になります。この例は、フロントエンドに表示される平均約定価格、バックエンドに記録される約定明細、および請求書に採用される約定金額の3つの場所を照合するのに適しています。

プロジェクトに外部流動性の接続が含まれている場合、価格提示が中断したときの挙動もテストする必要があります。システムが期限切れの市場データをマークしているか、ルールに従って新規注文を制限しているか、また未完了の注文をバックエンドで追跡できるかを中心に確認します。

4. 運用バックエンドで1件の取引を追跡できること

ローンチ後、カスタマーサポートがよく直面する問題は「注文がキャンセルされたのに、なぜまだ手数料がかかっているのか？」というものです。ユーザーが10口発注し、4口約定した後に残りの6口をキャンセルした場合でも、約定済みの部分に対して手数料が発生する可能性があります。バックエンドでは、この手数料を対応する約定に遡って追跡でき、カスタマーサポートが元の注文、実際の約定数量、キャンセル数量、手数料の履歴を確認できるようにする必要があります。

バックエンドの検収時には、カスタマーサポート、運用、財務がそれぞれ自身のワークフローを一通り実行するように手配できます。

• カスタマーサポートが、ユーザーから提供された注文番号から注文状態、約定明細、関連手数料を照会する。
• 運用担当者が、取引ペアの設定、ポジション制限、リスク管理の操作記録を確認する。
• 財務担当者が合意された基準に従って資金履歴をエクスポートし、手数料、資金調達率、実現損益を照合する。

5. 6MM ホワイトレーベル取引所のローンチ前の検収方法は？

6MMは、ホワイトレーベル取引所、無期限契約API / SDK、機関投資家向け流動性、マッチング、リスク管理、清算・決済などの取引インフラストラクチャを提供します。接続を評価する際は、ローンチ予定の取引カテゴリ、取引ペア、既存の口座体系、バックエンドの要件を持参し、項目ごとに納品範囲を確認することができます。

最初の統合テストは、4つのシナリオから開始できます。

1. 注文のタイムアウト。 シミュレーション要求が受理されたものの応答が失われた場合、APIの規約に従って元の注文を照会できるかを検証し、重複した発注を回避する。
2. 部分約定後の注文キャンセル。 約定数量、キャンセル数量、ポジション、手数料が一致しているかを照合する。
3. 切断中の約定発生。 再接続後に注文、ポジション、残高を復元できるかを確認する。
4. 請求書の不一致。 資金履歴から注文と約定を逆引きし、不一致の発生源を特定できることを確認する。

各ユースケースの検収記録には、入力条件、期待される結果、照合データ、担当者を明記することができます。たとえば、切断復旧ユースケースの合格条件は次のように記述できます：再接続と同期の完了後、クライアントに表示される約定数量が注文照会結果と一致し、ポジションと請求書も同じ約定に遡って追跡できること。