Self-Match Prevention आणि Wash Trades समजून घ्या

Self-match prevention हे matching engineमधील असे feature आहे, जे एकाच firmकडील दोन ordersना परस्पर trade करण्यापासून थांबवते. Entryच्या वेळी ordersसोबत एक identifier पाठवला जातो. तोच identifier असलेल्या दोन ordersचे prices cross होणार असतील, तर trade print होण्यापूर्वी engine त्यांपैकी एक order किंवा दोन्ही orders cancel करते. Self-match prevention ही तुम्ही सुरू करणारी venue plumbing आहे. Wash tradesवरील बंदी हा कायदा आहे. या दोन्हींची व्याप्ती समान नाही.

तुमची पहिली strategy ज्या instrumentसाठी quote देत आहे, त्याच instrumentसाठी दुसरी strategy quote देऊ लागते, त्या क्षणापासून हा नियम तुमच्यावर लागू होतो. एका symbolवरचा two-ladder grid bot ज्या अटींना सामोरा जातो, त्याच अटींना bank deskही सामोरे जाते.

Matching engineमध्ये self-match prevention कसे काम करते

Venueला मिळणाऱ्या प्रत्येक orderमध्ये engine matchingपूर्वी वाचत असलेली fields असतात: side, price, size, time in force. Self-match preventionमध्ये आणखी दोन fields जोडल्या जातात. पहिला म्हणजे identifier. हा number किंवा string असतो आणि order कोणत्या firm, account किंवा strategy groupचा आहे हे सांगतो. दुसरा म्हणजे अशी instruction, जी तो identifier असलेले दोन live orders परस्पर trade करणार असतील तेव्हा engineने काय करावे हे सांगते.

Aggressing order resting orderच्या अशा priceपर्यंत पोहोचतो, जिथे त्याचा match होणार असतो, त्या क्षणी ही तपासणी होते. सामान्यतः चार परिणाम वापरले जातात:

• Resting order cancel करणे. Incoming order bookमध्ये पुढे जातो आणि त्या priceवर त्याच्या मागे असलेल्या ordersशी match होऊ शकतो.
• Incoming order cancel करणे. Resting orderची queue position कायम राहते आणि aggressor नाहीसा होतो.
• दोन्ही orders cancel करणे. ही सर्वांत कडक setting आहे.
• Decrement and cancel. मोठ्या orderचा size छोट्या orderच्या sizeइतका कमी केला जातो, छोटा order cancel केला जातो आणि उरलेला भाग live राहतो.

या चारही परिस्थितींमध्ये trade होत नाही. Tapeवर काहीही print होत नाही. Fill logमध्ये काहीही नोंदले जात नाही. त्याऐवजी एका legवर किंवा दोन्ही legsवर unsolicited cancel येतो.

Queue position ही शांतपणे होणारी किंमत आहे. Cancel-oldest instructionखाली resting order cancel झाल्यास, वाट पाहून मिळवलेले सर्वकाही गमावले जाते. Price-time priorityअंतर्गत हे नुकसान पूर्ण असते. पुन्हा entry केल्यास order bookमध्ये तोपर्यंत queueमध्ये आलेल्या प्रत्येकाच्या मागे जातो. Queue positionचा अंदाज घेण्याचे आमचे मार्गदर्शक या स्थानाची किंमत किती असते हे स्पष्ट करते.

एक instrument, अनेक books

ही तपासणी प्रत्येक venueपुरती मर्यादित असते. Engine स्वतःकडे असलेल्या ordersचीच तुलना करते. तुमचे दोन orders दोन वेगवेगळ्या booksमध्ये resting असतील, तर ते एकमेकांना दिसत नाहीत. कोणतीही US equities mechanism त्यांच्यामध्ये समन्वय साधत नाही. एकाच US stockसाठी एकाच वेळी अनेक booksमध्ये quotes असू शकतात. खालील panelमध्ये June 10, 2026च्या सकाळच्या एका fifteen minute windowमध्ये सहा परिचित namesसाठी quote देणाऱ्या आणि prints करणाऱ्या स्वतंत्र venuesची संख्या दाखवली आहे.

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

त्या quarter hourमध्ये AAPLने 16 स्वतंत्र venuesकडून bids घेतल्या आणि 17 venuesवर prints झाले. Panelमधील सर्वांत कमी traded असलेल्या nameलाही 11 quoting venuesकडून bids मिळाल्या. Child orders जाणीवपूर्वक विभागणारा smart order router तुमच्या दोन strategiesना बराच वेळ वेगवेगळ्या booksमध्ये ठेवेल. अशा वेळी engine-level check लागू होत नाही. Firms हा फरक upstream, order management layerमध्ये, कोणताही order इमारतीबाहेर जाण्यापूर्वी भरून काढतात. समान priceवर विरुद्ध बाजूंना दोन booksमध्ये resting असलेले तुमचे स्वतःचे orders locked किंवा crossed market तयार करतात. त्यासाठी स्वतंत्र नियम लागू होतात.

एका sessionमध्ये एक book किती matches करते

Engine करत असलेल्या प्रत्येक matchच्या मार्गात self-match check असते. Liquid nameमध्ये हा मार्ग दिवसभर व्यस्त राहतो. खालील panelमध्ये एका stockचे संपूर्ण session fifteen minute slicesमध्ये विभागले आहे. प्रत्येक sliceमधील prints मोजले आहेत. किमान 200 prints असलेले slices ठेवले आहेत.

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_time

04:00 ET वाजता त्या nameमध्ये fifteen minutesमध्ये 9402 trades print झाले. 19:45 ET वाजता 1345 trades print झाले. एकूण 64 bucketsने 200 printsची किमान मर्यादा पार केली. प्रत्येक print म्हणजे engineने एकत्र आणलेल्या ordersची एक जोडी आहे. Ordersना परस्पर trade करू देण्यापूर्वी check दोन्ही बाजूंचे identifiers वाचते. Bookमध्ये resting होणारा प्रत्येक order त्या दिवशी नंतर त्याच accountच्या दुसऱ्या orderशी match होऊ शकतो.

Self-trade print झाल्यावर tapeवर काय दिसते

प्रतिबंधित self-matchमागे कोणताही record राहत नाही. Tapeवर फक्त executed trades असतात. प्रत्येक printसोबत condition flags येतात. Trade कसा झाला हे सांगण्यासाठी reporting venue हे codes जोडते. खालील panelमध्ये एका stockचे संपूर्ण session या flagsनुसार विभागले आहे.

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 10

त्या sessionमधील flagged printsपैकी Odd Lot Tradeमध्ये 48.34%चा वाटा आहे. Panelमध्ये त्या दिवसातील 10 सर्वांत सामान्य flags दिले आहेत. यादी वाचा आणि काय अनुपस्थित आहे ते पाहा. दोन orders एकाच firmकडून आले होते असे सांगणारा कोणताही code नाही. Self-trade print झालाच, तर तो त्या priceवरील इतर कोणत्याही tradeसारखा दिसतो. त्यामुळे त्याचे surveillance tapeवरून नव्हे, तर venueकडील participant identifiers आणि ordersसोबत असलेल्या account numbersवरून केले जाते.

Self-match prevention जिथे संपते आणि wash trade law जिथे सुरू होतो

Self-match prevention ही venueची service आहे. तुम्ही ती स्वीकारता, configure करता आणि सुरू करता. तुम्ही ती कधीच configure केली नाही, तर engine तुमचे दोन orders सहजपणे match करेल. Wash tradeवरील बंदी ऐच्छिक नाही. ती कोणत्याही settingवर अवलंबून नाही.

Securities Exchange Act of 1934मधील Section 9(a)(1) अशा securities transactionsना लागू होते, ज्यात beneficial ownershipमध्ये कोणताही बदल होत नाही आणि active tradingचे दिशाभूल करणारे चित्र निर्माण करण्याच्या उद्देशाने व्यवहार केले जातात. Commodity Exchange Actमध्ये futuresसाठी समतुल्य तरतूद आहे. CME Rule 534 exchange rulebookमध्ये हीच बाब पुन्हा स्पष्ट करते. Broker-dealersसाठी FINRA Rule 5210 ही दोन्ही चौकटींना पूरक आहे. त्यातील supplementary material self-tradesचा थेट उल्लेख करते: एका firmमधील दोन unrelated algorithmsमधील trades केवळ त्या कारणाने violative ठरत नाहीत. तरीही firmने अशा tradesचे review आणि reduction करण्यासाठी policies ठेवणे अपेक्षित आहे.

एकापेक्षा जास्त strategies चालवणाऱ्यांसाठी याचे दोन परिणाम आहेत. तुम्ही कोणतीही self-match instruction configure केली नसलेल्या venueवर self-cross झाल्यास prohibitionचे उल्लंघन होऊ शकते, कारण हा नियम transaction आणि त्यामागील intentला लागू होतो. Self-match preventionने थांबवलेला self-cross कोणत्याही नियमाचे उल्लंघन करत नाही. ते थांबवणे हाच या featureचा उद्देश आहे.

Operators हे CME, ICE, LME आणि MiFID IIमध्ये कसे configure करतात

CME Globexवर self-match prevention order entryवेळी पाठवलेल्या identifierवर चालते. Firms वापरणार असलेले identifiers आधी register करतात. प्रत्येक orderसोबत एक identifier असतो. तो identifier असलेले दोन orders भेटल्यास engineने कोणती बाजू cancel करावी, हे paired instruction सांगते. Identifierशिवाय पाठवलेले orders सामान्य पद्धतीने match होतात. नव्या operatorसाठी हा महत्त्वाचा धोका आहे: default setting off असते.

ICEमध्ये Self-Trade Prevention Functionality वापरली जाते. ती प्रत्येक orderनुसार नव्हे, तर trading firm identifierविरुद्ध configure केली जाते. Cancel outcomesची त्यातही अशीच मालिका असते. London Metal Exchange सदस्यांच्या trading identifiersसाठी LMEselectवर Self-Execution Prevention देते. Europeमध्ये MiFID II Article 17 algorithmic trading करणाऱ्या प्रत्येक investment firmवर systems and controlsची जबाबदारी ठेवते. यात testing, kill functionality आणि disorderly trading रोखणे यांचा समावेश आहे. Article 48 venueवरही समांतर जबाबदारी ठेवते. त्यासोबत venue-side prevention toolsही standard equipment झाले आहेत.

Configuration symbol by symbol करण्याऐवजी account किंवा firm levelवर केली जाते. एका underlyingच्या option surfaceचा आकार याचे कारण स्पष्ट करतो.

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 date

2026-06-01वर एका underlyingमध्ये volume असलेले आणि स्वतंत्रपणे trade करता येणारे 1579 contracts होते. ते 112 strikesमध्ये विभागलेले होते. Panelमध्ये अशाच स्वरूपाच्या 21 sessionsचा समावेश आहे. इतक्या संख्येवर contract by contract rule set करणे अव्यवहार्य आहे. Identifier accountशी जोडला जातो आणि त्या accountकडून पाठवलेल्या प्रत्येक orderसोबत पुढे जातो.

तुमचे fill logs स्पष्ट करणार नाहीत असा failure mode

प्रत्यक्ष व्यवहारात हे असे दिसते. Cancel-newest instruction तुम्ही नुकताच पाठवलेला order arrivalवेळीच cancel करते. तो match होण्यापूर्वीच रद्द होतो. Botच्या आतून पाहिल्यास sequence अशी दिसते: नवीन order, त्यानंतर कुणीही मागितलेला नसलेला cancel. Fill नसतो. Reject नसतो. Reason सांगणारी error stringही नसते. त्यामुळे प्रथमच या परिस्थितीला सामोरे जाणारे operators स्वतःच्या cancel pathमध्ये bug शोधू लागतात.

दोन सवयींमुळे ही बाब स्पष्ट होते. Venueचे order status messages normalized summaryऐवजी verbatim log करा. Prevention reason सहसा त्या messageमधील fieldमध्ये असतो. तुमच्या codeने originate न केलेल्या प्रत्येक cancelसाठी alert लावा. हा alert तुमच्या automated trading circuit breakersसोबत असायला हवा. Failure याच वर्गातील आहे: venueने तुमच्या orderची state बदलली, पण तुमची process काहीही घडले नाही अशा पद्धतीने पुढे चालू राहिली.

वारंवार विचारले जाणारे प्रश्न

Self-match prevention म्हणजे काय?

एकाच firm किंवा account identifier असलेले दोन orders परस्पर trade करू नयेत यासाठी matching engineमध्ये केलेली तपासणी. ते match होणार असतील, तर orderसोबत जोडलेल्या instructionनुसार engine resting order, incoming order किंवा दोन्ही orders cancel करते.

Self-trade आणि wash trade एकच आहेत का?

नाही. Self-trade म्हणजे त्याच beneficial ownerच्या दोन ordersमधील कोणतेही execution. Wash trade म्हणजे genuine market risk न घेता आणि market activityचे दिशाभूल करणारे चित्र निर्माण करण्याच्या उद्देशाने केलेला self-trade. Unrelated algorithmsमधील अनवधानाने झालेले self-trades आणि जाणीवपूर्वक केलेले arranged trades वेगळ्या पद्धतीने हाताळले जातात. तरीही firmsने त्यांचे monitoring करणे अपेक्षित आहे.

वेगवेगळ्या exchangesवर self-match prevention काम करते का?

नाही. प्रत्येक matching engine ही तपासणी केवळ स्वतःच्या bookमधील ordersवर करते. एका firmचे दोन orders दोन venuesवर resting असतील, तर ते परस्पर trade करू शकतात. त्यामुळे ही जबाबदारी venuesच्या वरच्या स्तरावरील firmच्या स्वतःच्या pre-trade checksवर येते.

Fill न होता आणि reason न देता माझा order cancel का झाला?

Cancel-newest self-match instruction हे एक संभाव्य कारण आहे. तुमचा identifier असलेल्या resting orderशी match होण्यापूर्वीच venueने order arrivalवेळी cancel केला असू शकतो. Reason सहसा rejectionऐवजी venueच्या cancel messageमधील fieldमध्ये दिसतो.

कोणत्या venuesना self-match prevention identifier आवश्यक असतो?

Requirements venue आणि productनुसार बदलतात. CME order entryवेळी identifier मागते आणि तो आधी register केलेला असावा. ICE आणि London Metal Exchange firm levelवर त्यांच्या स्वतंत्र configurations देतात. European venuesवर MiFID IIअंतर्गत systems and controlsची जबाबदारी असते. तुम्ही trade करत असलेल्या productसाठी venue rulebookच अंतिम प्राधिकृत स्रोत आहे.

येथील प्रत्येक panel तयार करणारा SQL queryसोबत दिलेला आहे. कोणताही panel expand करून तो वाचा. तुम्ही trade करत असलेल्या nameसाठी quote देणाऱ्या venuesची संख्या मोजायची असेल किंवा sessionला condition flagsमध्ये विभागायचे असेल, तर Strasmore terminalवर plain Englishमध्ये प्रश्न विचारा.