著者: Matt Connor
セルフマッチ防止とウォッシュトレードの違い
セルフマッチ防止がマッチングエンジン内で二つの注文の約定を止める仕組みと、ウォッシュトレード規制の適用範囲を解説します。
セルフマッチ防止は、同一企業の二つの注文が互いに約定するのを止めるマッチングエンジンの機能です。注文の送信時に識別子を付け、同じ識別子を持つ二つの注文が交差する場合、取引が成立する前に一方または両方をキャンセルします。セルフマッチ防止は有効化する取引所機能です。一方、ウォッシュトレードの禁止は法律であり、両者の対象範囲は同じではありません。
二つ目のストラテジーが、最初のストラテジーがすでに気配を出している銘柄に気配を出した瞬間、このルールが適用されます。一つの銘柄で二つの段階的な注文を出すグリッドボットにも、銀行のトレーディングデスクと同じ条件で適用されます。
マッチングエンジンにおけるセルフマッチ防止の仕組み
取引所が受け付けるすべての注文には、マッチング前にエンジンが読み取る項目があります。売買区分、価格、数量、執行条件です。セルフマッチ防止では、さらに二つの項目を加えます。一つ目は識別子です。これは、注文がどの企業、口座、またはストラテジーグループに属するかを示す番号または文字列です。二つ目は、同じ識別子を持つ二つの有効な注文が互いに約定しそうな場合に、エンジンが取る処理を指定する指示です。
このチェックは、成行注文などの攻撃側注文が、約定可能な待機注文の価格に到達した瞬間に実行されます。一般的な処理は四つあります。
- 待機注文をキャンセルする。受信した注文は板に入り、その価格で後ろにある注文と約定できます。
- 受信した注文をキャンセルする。待機注文はキュー順位を維持し、攻撃側注文だけが消えます。
- 両方の注文をキャンセルする。最も厳格な設定です。
- 数量を減らしてキャンセルする。大きい注文を小さい注文の数量分だけ減らし、小さい注文をキャンセルします。残った数量は有効なままです。
四つの処理のいずれでも取引は成立しません。テープに約定が記録されることも、約定ログに残ることもありません。その代わり、一方または両方の注文に対して、予定外のキャンセル通知が届きます。
静かなコストはキュー順位です。cancel-oldestの指示で待機注文がキャンセルされると、待機によって得た優位性をすべて失います。価格・時間優先では、その損失は完全なものです。再送すると、待機中にキューへ加わったすべての注文の後ろに並ぶことになります。キュー順位の推定に関するガイドでは、その順位の価値を説明しています。
一つの銘柄、多数の板
このチェックは取引所ごとに実行されます。エンジンが比較するのは、自身が保有する注文だけです。二つの異なる板に待機する自社注文は互いに見えず、米国株式市場の仕組みが両者をまたいでチェックすることもありません。一つの米国株は、同時に多くの板で気配を形成します。下のパネルは、2026年6月10日の朝の15分間について、よく知られた六銘柄の気配提示・約定記録のある取引所の数を集計したものです。
各数値の背後にある正確なSQL
SELECT
q.ticker AS ticker,
q.quoting_venues AS quoting_venues,
t.printing_venues AS printing_venues
FROM
(
SELECT
ticker,
countDistinct(bid_exchange) AS quoting_venues
FROM global_markets.cache_stocks_quotes
WHERE ticker IN ('AAPL', 'MSFT', 'NVDA', 'SPY', 'KO', 'JNJ')
AND sip_timestamp >= toDateTime('2026-06-10 14:00:00', 'UTC')
AND sip_timestamp < toDateTime('2026-06-10 14:15:00', 'UTC')
AND bid_price > 0
GROUP BY ticker
) AS q
INNER JOIN
(
SELECT
ticker,
countDistinct(exchange) AS printing_venues
FROM global_markets.stocks_trades
WHERE ticker IN ('AAPL', 'MSFT', 'NVDA', 'SPY', 'KO', 'JNJ')
AND sip_timestamp >= toDateTime('2026-06-10 14:00:00', 'UTC')
AND sip_timestamp < toDateTime('2026-06-10 14:15:00', 'UTC')
GROUP BY ticker
) AS t ON t.ticker = q.ticker
ORDER BY quoting_venues DESC, tickerその15分間にAAPLは16の異なる取引所から買い気配を集め、約定記録はそのうち17に残りました。パネル内で最も取引の薄い銘柄でも、11の取引所から気配を集めています。子注文を意図的に分割するスマート・オーダー・ルーターでは、多くの場合、二つのストラテジーが異なる板に入ります。その場合、エンジンレベルのチェックは適用されません。企業は、注文が社外へ出る前に、注文管理レイヤーでこの隙間を埋めます。同じ価格で二つの板の売り買いの両側に自社注文を置くと、独自のルールが適用されるロックド・マーケットまたはクロスト・マーケットも生じます。
一つの板が一セッションで成立させる約定数
セルフマッチのチェックは、エンジンが成立させるすべての約定経路に組み込まれています。流動性の高い銘柄では、その経路は一日中稼働しています。下のパネルは、一銘柄の一セッション全体を15分単位に分け、各区間の約定記録を数えたものです。200件以上の区間だけを残しています。
各数値の背後にある正確なSQL
SELECT
formatDateTime(toStartOfInterval(toTimeZone(sip_timestamp, 'America/New_York'), INTERVAL 15 MINUTE), '%H:%i') AS et_time,
count() AS trade_count
FROM global_markets.stocks_trades
WHERE ticker = 'AAPL'
AND sip_timestamp >= toDateTime('2026-06-10 08:00:00', 'UTC')
AND sip_timestamp < toDateTime('2026-06-11 04:00:00', 'UTC')
GROUP BY et_time
HAVING count() >= 200
ORDER BY et_time04:00 ETには、その銘柄で15分間に9402件の取引が記録され、19:45 ETには1345件が記録されました。200件の基準を超えた区間は64あります。各約定記録は、エンジンが結び付けた一組の注文です。エンジンは注文を成立させる前に、両側の識別子を確認します。板で待機するすべての注文は、その日の後の時間帯に、同じ口座から出た別の注文と出会う候補になります。
セルフトレードが成立した場合にテープに表示されるもの
防止されたセルフマッチは何も残しません。テープに記録されるのは成立した取引だけであり、各約定記録には条件フラグが付いています。これは、取引がどのように成立したかを報告取引所が示すコードです。下のパネルは、一銘柄の一セッション全体をこれらのフラグ別に分解しています。
各数値の背後にある正確なSQL
SELECT
condition_name,
print_count,
round(100 * print_count / sum(print_count) OVER (), 2) AS share_pct
FROM
(
SELECT
cc.id AS condition_id,
any(cc.name) AS condition_name,
count() AS print_count
FROM
(
SELECT toInt32(arrayJoin(conditions)) AS condition_id
FROM global_markets.stocks_trades
WHERE ticker = 'AAPL'
AND sip_timestamp >= toDateTime('2026-06-10 08:00:00', 'UTC')
AND sip_timestamp < toDateTime('2026-06-11 04:00:00', 'UTC')
) AS f
INNER JOIN
(
SELECT
toInt32(id) AS id,
any(name) AS name
FROM global_markets.stocks_condition_codes
WHERE asset_class = 'stocks'
AND has(data_types, 'trade')
GROUP BY id
) AS cc ON cc.id = f.condition_id
GROUP BY condition_id
)
ORDER BY print_count DESC
LIMIT 10Odd Lot Tradeは、そのセッションのフラグ付き約定記録の48.34%を占めます。パネルには、その日の最も一般的なフラグ10件が示されています。リストを確認し、記載されていないものにも注目してください。同一企業から出た二つの注文であることを示すコードはありません。成立したセルフトレードは、その価格で行われた他の取引と同じように見えます。そのため、監視ではテープ、取引所が保有する参加者識別子、注文に付随する口座番号を使います。
セルフマッチ防止とウォッシュトレード規制の境界
セルフマッチ防止は取引所のサービスです。利用を申し込み、設定すると使えます。設定しなければ、エンジンは二つの自社注文をそのまま約定させます。ウォッシュトレードの禁止は任意ではなく、設定にも依存しません。
1934年証券取引法第9条(a)(1)は、実質的所有者の変更がなく、活発な取引があるとの誤解を生じさせる目的で行われた証券取引を対象とします。商品取引法には先物取引に対応する規定があり、CME規則534にも再掲されています。FINRA規則5210はブローカー・ディーラーに対して両者を補完し、その補足資料ではセルフトレードを直接扱っています。同一企業内の無関係な二つのアルゴリズム間で行われた取引は、それだけで違反とはならず、企業にはセルフトレードを確認し、削減する方針の整備が求められます。
複数のストラテジーを運用する場合、二つの帰結があります。取引所のセルフマッチ指示をまったく設定していない場合、自社注文同士のクロスは規制に抵触する可能性があります。規制は取引と、その背後にある意図に適用されるためです。一方、セルフマッチ防止によって自社注文同士のクロスが止められた場合、違反は生じません。それを止めることが、この機能の目的です。
CME、ICE、LME、MiFID IIにおける運用設定
CME Globexでは、セルフマッチ防止は注文送信時に付ける識別子を基に機能します。企業は使用する識別子を登録し、各注文に一つを付けます。さらに、同じ識別子を持つ二つの注文が出会った場合に、エンジンがどちらをキャンセルするかを指定します。識別子なしで送った注文は通常どおり約定します。新しい運用担当者が見落としやすい点であり、初期設定では機能が無効です。
ICEはSelf-Trade Prevention Functionalityを提供しています。注文ごとではなく、トレーディング企業の識別子に対して設定し、キャンセル処理の種類も同じです。London Metal Exchangeは、LMEselectで会員の取引識別子に対するSelf-Execution Preventionを提供しています。欧州では、MiFID II第17条により、アルゴリズム取引を行う投資企業にシステムと管理体制の整備が求められます。テスト、キル機能、無秩序な取引の防止が対象です。第48条は取引所にも同様の義務を課しており、取引所側の防止機能はこれと並ぶ標準装備になりました。
設定は、銘柄ごとではなく口座または企業レベルで行います。一つの原資産に対するオプションの広がりを見ると、その理由が分かります。
各数値の背後にある正確なSQL
SELECT
toString(date) AS session_date,
countDistinct(ticker) AS contracts_traded,
countDistinct(strike_price) AS strikes_traded
FROM global_markets.options_greeks
WHERE underlying_symbol = 'AAPL'
AND date >= '2026-06-01'
AND date <= '2026-06-30'
AND volume > 0
AND iv_converged = 1
GROUP BY date
ORDER BY date2026-06-01では、一つの原資産に取引可能な出来高付きコントラクトが1579あり、112の行使価格に分散していました。パネルは、同様の形状を持つ21セッションを対象としています。この数をコントラクトごとに設定するのは現実的ではありません。識別子は口座に付与され、その口座が送るすべての注文に付随します。
約定ログでは説明できない障害パターン
実際の動きは次のようになります。cancel-newestの指示では、送信したばかりの注文が到着時点でキャンセルされ、約定する前に消えます。ボット内部では、新規注文に続いて、誰も要求していないキャンセルが発生したように見えます。約定も拒否もなく、理由を示すエラー文字列もありません。そのため、初めて遭遇した運用担当者は、自社のキャンセル処理にバグがあると考えがちです。
二つの運用習慣によって、状況を把握しやすくなります。取引所の注文ステータスメッセージは、正規化した要約ではなく、そのまま記録してください。防止理由は通常、そのメッセージのフィールドに含まれるためです。自社コードが発生させていないキャンセルを検知したらアラートを出してください。このアラートは自動取引サーキットブレーカーと同じ場所で管理すべきです。障害の種類が同じだからです。取引所が注文状態を変更したにもかかわらず、プロセスが何も起きなかったかのように処理を続けています。
FAQ
セルフマッチ防止とは何ですか？
同じ企業または口座の識別子を持つ二つの注文が互いに約定するのを止める、マッチングエンジンのチェック機能です。約定しそうになった場合、注文に付いた指示に従い、エンジンが待機注文、受信注文、または両方をキャンセルします。
セルトレードはウォッシュトレードと同じですか？
いいえ。セルフトレードは、同じ実質的所有者に属する二つの注文間で成立する取引です。ウォッシュトレードは、実質的な市場リスクを負わず、取引が活発であるとの誤解を生じさせる意図で行われるセルフトレードです。無関係なアルゴリズム間で意図せず成立したセルフトレードは、意図的に仕組まれた取引とは異なる扱いを受けます。ただし、企業には引き続き監視が求められます。
異なる取引所間でもセルフマッチ防止は機能しますか？
いいえ。各マッチングエンジンは、自身の板にある注文だけを対象にチェックします。一企業の二つの注文が二つの取引所で待機している場合、両者は互いに約定できます。その管理は、取引所の上位にある企業独自の発注前チェックに委ねられます。
約定せず、理由もないまま注文がキャンセルされたのはなぜですか？
cancel-newestのセルフマッチ指示が一つの候補です。取引所が、同じ識別子を持つ待機注文と約定する前に、到着時点で注文をキャンセルした可能性があります。理由は通常、拒否通知ではなく、取引所のキャンセルメッセージのフィールドに表示されます。
セルフマッチ防止の識別子を求める取引所はどこですか？
要件は取引所と商品によって異なります。CMEでは、事前登録した識別子を注文送信時に付けます。ICEとLondon Metal Exchangeは企業レベルで独自の設定を提供しており、欧州の取引所にはMiFID IIに基づくシステムと管理体制の整備義務があります。取引する商品の取引所規則が最終的な基準です。
ここにあるすべてのパネルには、作成に使ったSQLが付いています。いずれかを展開して確認してください。取引する銘柄の気配提示取引所数を数える場合も、セッションを条件フラグ別に分解する場合も、Strasmore端末で平易な英語の質問を入力できます。