Self-Match Prevention, Wash Trades తేడా ఏమిటి

Self-match prevention అనేది ఒకే సంస్థకు చెందిన రెండు ఆర్డర్లు పరస్పరం ట్రేడ్ కాకుండా అడ్డుకునే matching engine ఫీచర్. ఆర్డర్లు ప్రవేశించే సమయంలో ఒక identifierను కలిగి ఉంటాయి. ఆ identifier ఒకటే ఉన్న రెండు ఆర్డర్లు పరస్పరం cross అయ్యే పరిస్థితి ఏర్పడితే, ఏదైనా trade print కావడానికి ముందే engine వాటిలో ఒకదాన్ని లేదా రెండింటినీ cancel చేస్తుంది. Self-match prevention అనేది మీరు on చేసే venue-level వ్యవస్థ. Wash tradesపై నిషేధం చట్టపరమైనది. ఈ రెండూ ఒకే విషయం కావు.

మీ మొదటి strategy ఇప్పటికే 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. ఇది order ఏ సంస్థ, account లేదా strategy groupకు చెందినదో తెలిపే సంఖ్య లేదా string. రెండోది, అదే identifier ఉన్న రెండు live orders పరస్పరం ట్రేడ్ చేయబోతున్నప్పుడు engine ఏం చేయాలో తెలిపే instruction.

ఒక aggressing order, తాను match అయ్యే resting order ధరను చేరిన క్షణంలో ఈ తనిఖీ జరుగుతుంది. సాధారణంగా ఉపయోగించే నాలుగు ఫలితాలు ఇవి:

• Resting orderను cancel చేయడం. Incoming order bookలో ముందుకు సాగుతుంది. అదే ధర వద్ద దాని వెనుక ఉన్న ఇతర ordersతో match కావచ్చు.
• Incoming orderను cancel చేయడం. Resting order తన queue positionను నిలుపుకుంటుంది. Aggressor తొలగిపోతుంది.
• రెండు ordersనూ cancel చేయడం. ఇది అత్యంత కఠినమైన setting.
• Decrement and cancel. చిన్న order పరిమాణంతో పెద్ద order పరిమాణాన్ని తగ్గిస్తారు. చిన్న order cancel అవుతుంది. మిగిలిన పరిమాణం liveగా ఉంటుంది.

ఈ నాలుగు సందర్భాల్లోనూ trade జరగదు. Tapeపై ఏదీ print కాదు. Fill logలో ఏదీ చేరదు. బదులుగా ఒక legపై లేదా రెండు legsపై unsolicited cancel వస్తుంది.

Queue position కనిపించని ఖర్చు. Cancel-oldest instruction కింద cancel అయిన resting order, వేచి ఉండటం ద్వారా సంపాదించిన మొత్తం ప్రాధాన్యతను కోల్పోతుంది. ధర-సమయ ప్రాధాన్యత కింద ఈ నష్టం పూర్తిగా ఉంటుంది. మళ్లీ ప్రవేశపెట్టిన order, అది వేచి ఉన్న సమయంలో queueలో చేరిన అందరి వెనుకకు వెళ్తుంది. ఆ క్రమస్థాన విలువను ఎలా అంచనా వేయాలో మా queue position అంచనా guideలో ఉంది.

ఒక instrument, అనేక books

ఈ తనిఖీ venue స్థాయిలో జరుగుతుంది. ఒక engine తన వద్ద ఉన్న ordersనే పోల్చుతుంది. రెండు వేర్వేరు booksలో restingగా ఉన్న మీ రెండు orders ఒకదానికొకటి కనిపించవు. US equitiesలో ఏ mechanism కూడా వాటి మధ్య పనిచేయదు. ఒకే US stock అనేక booksలో ఒకేసారి quote కావచ్చు. 2026 జూన్ 10 ఉదయం, పదిహేను నిమిషాల windowలో ఆరు ప్రసిద్ధ పేర్లకు quote మరియు print చేసిన వేర్వేరు venues సంఖ్యను దిగువ panel చూపిస్తుంది.

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

ఆ పదిహేను నిమిషాల్లో AAPLలో 16 వేర్వేరు venues నుంచి bids వచ్చాయి. వాటిలో 17 venuesలో prints నమోదయ్యాయి. Panelలో అత్యల్పంగా ట్రేడ్ అయిన పేరు కూడా 11 quoting venues నుంచి ordersను ఆకర్షించింది. Child ordersను ఉద్దేశపూర్వకంగా విభజించే smart order router మీ రెండు strategiesను ఎక్కువసార్లు వేర్వేరు booksలో ఉంచుతుంది. అప్పుడు engine-level check వర్తించదు. Firms ఈ లోటును upstreamలో, orders buildingను వదిలి వెళ్లే ముందు order management layerలోనే పూడుస్తాయి. రెండు booksలో ఒకే ధర వద్ద opposite sidesలో మీ orders restingగా ఉంటే locked or crossed market కూడా ఏర్పడుతుంది. దానికి స్వంత నియమాలు ఉంటాయి.

ఒక sessionలో ఒక book ఎన్ని matches చేస్తుంది

Engine చేసే ప్రతి match మార్గంలో self-match check ఉంటుంది. Liquid nameలో ఈ మార్గం రోజంతా చురుకుగా ఉంటుంది. దిగువ panel ఒక stockకు చెందిన పూర్తి sessionను పదిహేను నిమిషాల భాగాలుగా విభజిస్తుంది. ప్రతి భాగంలోని printsను లెక్కిస్తుంది. కనీసం 200 prints ఉన్న భాగాలను మాత్రమే ఉంచుతుంది.

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 సమయంలో ఆ ఒక్క పేరులో పదిహేను నిమిషాల్లో 9402 trades print అయ్యాయి. 19:45 ET సమయంలో 1345 trades print అయ్యాయి. 200-print కనీస పరిమితిని దాటిన buckets సంఖ్య 64. ప్రతి print అనేది engine కలిపిన ఒక జత orders. ఆ orders కలుసుకునే ముందు రెండు వైపుల identifiersను check చేస్తుంది. Bookలో restingగా మారే ప్రతి order, అదే accountకు చెందిన మరో orderను రోజులో తరువాత కలుసుకునే అవకాశం ఉన్న candidate.

Self-trade print అయితే tapeపై కనిపించేది ఏమిటి

అడ్డుకున్న self-match ఎలాంటి ఆనవాళ్లూ వదలదు. 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% కవర్ చేస్తుంది. ఆ రోజులో అత్యంత సాధారణమైన 10 flagsను panel చూపిస్తుంది. జాబితాను పరిశీలించి అందులో లేనిదాన్ని గమనించండి. రెండు orders ఒకే firm నుంచి వచ్చాయని తెలిపే code ఏదీ ఉండదు. Self-trade జరిగి print అయితే, అదే ధర వద్ద జరిగిన ఇతర tradeలాగే కనిపిస్తుంది. అందువల్ల దాని surveillance tapeపై, venue వద్ద ఉన్న participant identifiersపై, ordersతో వచ్చిన account numbersపై ఆధారపడుతుంది.

Self-match prevention ఎక్కడ ముగుస్తుంది, wash trade చట్టం ఎక్కడ ప్రారంభమవుతుంది

Self-match prevention ఒక venue service. మీరు దాన్ని ఎంచుకుని, configure చేస్తారు. Setup చేయకపోతే engine మీ రెండు ordersను సాధారణంగానే match చేస్తుంది. Wash trade నిషేధం optional కాదు. అది ఏ settingపైనా ఆధారపడదు.

Securities Exchange Act of 1934లోని Section 9(a)(1), beneficial ownershipలో ఎలాంటి మార్పు లేకుండా జరిగే securities transactionsకు వర్తిస్తుంది. చురుకైన trading జరుగుతున్నట్లు తప్పుదారి పట్టించే రూపాన్ని సృష్టించే ఉద్దేశంతో ఆ transactions నమోదు చేయబడితే ఈ నిబంధన వర్తిస్తుంది. Commodity Exchange Actలో futuresకు సమానమైన నిబంధన ఉంది. CME Rule 534 దానిని exchange rulebookలో మళ్లీ స్పష్టం చేస్తుంది. Broker-dealersకు FINRA Rule 5210 కూడా వర్తిస్తుంది. దాని supplementary material self-tradesను నేరుగా ప్రస్తావిస్తుంది. ఒక firmలోని సంబంధం లేని రెండు algorithms మధ్య trades జరిగినంత మాత్రాన అవి ఉల్లంఘన కావు. అయితే వాటిని సమీక్షించి తగ్గించే policiesను firm నిర్వహించాలి.

ఒకటి కంటే ఎక్కువ strategies నడిపేవారికి రెండు విషయాలు వర్తిస్తాయి. మీరు ఎలాంటి self-match instruction set చేయని venueలో కూడా self-cross నిషేధాన్ని ఉల్లంఘించవచ్చు. ఎందుకంటే ఆ నియమం transactionకు, దాని వెనుక ఉన్న ఉద్దేశానికి వర్తిస్తుంది. Self-match prevention అడ్డుకున్న self-cross ఎలాంటి ఉల్లంఘన కాదు. దాన్ని ఆపడం self-match prevention ఉద్దేశమే.

Operators దాన్ని ఎలా configure చేస్తారు: CME, ICE, LME మరియు MiFID II

CME Globexలో self-match prevention, order entry సమయంలో సమర్పించే identifierపై ఆధారపడి పనిచేస్తుంది. Firms ఉపయోగించే identifiersను ముందుగానే register చేస్తాయి. ప్రతి orderలో ఒక identifier ఉంటుంది. అదే identifier ఉన్న రెండు orders కలిసినప్పుడు engine ఏ sideను cancel చేయాలో paired instruction చెబుతుంది. Identifier లేకుండా పంపిన orders సాధారణంగా match అవుతాయి. కొత్త operatorకు ఇదే ప్రమాదం: defaultగా ఇది offలో ఉంటుంది.

ICE, Self-Trade Prevention Functionalityను అందిస్తుంది. ఇది ఒక్కో order ఆధారంగా కాకుండా trading firm identifierకు అనుసంధానించి configure చేస్తారు. Cancel outcomes కూడా ఇదే కుటుంబానికి చెందినవి. London Metal Exchange, LMEselectలో member trading identifiers కోసం Self-Execution Preventionను అందిస్తుంది. యూరప్‌లో MiFID II Article 17, algorithmic trading చేసే ప్రతి investment firmపై systems and controls బాధ్యతను ఉంచుతుంది. ఇందులో testing, kill functionality, disorderly trading నివారణ ఉన్నాయి. Article 48 venueపై కూడా సమాంతర బాధ్యతను ఉంచుతుంది. వీటితో పాటు venue-side prevention tools సాధారణ వ్యవస్థలుగా మారాయి.

Configuration symbol-by-symbolగా కాకుండా account లేదా firm స్థాయిలో ఉంటుంది. ఒకే 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 ఉన్న 1579 వేర్వేరు trade చేయగల contracts ఉన్నాయి. అవి 112 strikesలో విస్తరించాయి. ఇదే విధమైన నిర్మాణం ఉన్న 21 sessionsను panel కవర్ చేస్తుంది. ఆ సంఖ్యలో ప్రతి contractకు విడిగా rule set చేయడం ఆచరణ సాధ్యం కాదు. Identifier accountకు అనుసంధానమై, ఆ account పంపే ప్రతి orderతో పాటు ప్రయాణిస్తుంది.

మీ fill logs వివరించలేని failure mode

ఇది ఆచరణలో ఇలా కనిపిస్తుంది. Cancel-newest instruction మీరు ఇప్పుడే పంపిన orderను arrival సమయంలోనే తొలగిస్తుంది. అది match అయ్యే అవకాశం రాకముందే cancel అవుతుంది. Bot లోపల ఈ క్రమం కొత్త order, ఆ తర్వాత ఎవరూ కోరని cancelగా కనిపిస్తుంది. Fill ఉండదు. Reject ఉండదు. కారణాన్ని తెలిపే error string కూడా ఉండదు. అందువల్ల మొదటిసారి ఎదురైన operators తమ cancel pathలో bug కోసం వెతకడం ప్రారంభిస్తారు.

రెండు అలవాట్లు దీనిని స్పష్టంగా చూపిస్తాయి. Venue పంపే order status messagesను normalized summaryగా కాకుండా, verbatimగా log చేయండి. Prevention reason సాధారణంగా ఆ messageలోని fieldగా వస్తుంది. మీ code సృష్టించని ఏ cancelపైనైనా alert ఇవ్వండి. ఈ alertను మీ automated trading circuit breakersతో కలిపి నిర్వహించాలి. ఎందుకంటే failure ఇదే వర్గానికి చెందుతుంది: venue మీ order stateను మార్చింది, కానీ ఏమీ జరగనట్లుగా మీ process కొనసాగింది.

తరచుగా అడిగే ప్రశ్నలు

Self-match prevention అంటే ఏమిటి?

ఒకే firm లేదా account identifier ఉన్న రెండు orders పరస్పరం ట్రేడ్ కాకుండా ఆపే matching engine check. అవి match అయ్యే పరిస్థితిలో orderకు జతచేసిన instruction ప్రకారం engine resting orderను, incoming orderను లేదా రెండింటినీ cancel చేస్తుంది.

Self-trade, wash trade ఒకటేనా?

కాదు. ఒకే beneficial ownerకు చెందిన రెండు orders మధ్య జరిగే ఏ execution అయినా self-trade. నిజమైన market risk లేకుండా, trading జరుగుతున్నట్లు తప్పుదారి పట్టించే రూపాన్ని సృష్టించే ఉద్దేశంతో నమోదు చేసిన self-trade wash trade. సంబంధం లేని algorithms మధ్య అనుకోకుండా జరిగే self-tradesను ఉద్దేశపూర్వకంగా ఏర్పాటు చేసిన trades కంటే భిన్నంగా పరిగణిస్తారు. అయినప్పటికీ firms వాటిని monitor చేయాలి.

వేర్వేరు exchangesలో self-match prevention పనిచేస్తుందా?

కాదు. ప్రతి matching engine తన సొంత bookలోని ordersకే ఈ checkను వర్తింపజేస్తుంది. ఒక firmకు చెందిన రెండు orders రెండు venuesలో restingగా ఉంటే అవి పరస్పరం trade కావచ్చు. వాటిని అడ్డుకునే బాధ్యత venues పైనున్న firm యొక్క pre-trade checksదే.

Fill లేకుండా, కారణం లేకుండా నా order ఎందుకు cancel అయింది?

Cancel-newest self-match instruction ఒక కారణం కావచ్చు. మీ identifier ఉన్న resting orderతో match అయ్యే ముందు venue మీ orderను arrival సమయంలోనే cancel చేసి ఉండవచ్చు. కారణం సాధారణంగా rejectionగా కాకుండా venue పంపిన cancel messageలోని fieldగా కనిపిస్తుంది.

Self-match prevention identifierను ఏ venues తప్పనిసరి చేస్తాయి?

అవసరాలు venue, productను బట్టి మారుతాయి. CME order entry సమయంలో ముందుగానే register చేసిన identifierను కోరుతుంది. ICE, London Metal Exchange తమ firm-level configurationsను అందిస్తాయి. European venuesలో MiFID II కింద systems and controls బాధ్యతలు ఉంటాయి. మీరు trade చేసే productకు సంబంధించిన venue rulebookనే తుది ఆధారంగా పరిగణించాలి.

ఇక్కడి ప్రతి panelను రూపొందించిన SQLను కలిగి ఉంటుంది. ఏ panelనైనా expand చేసి దాన్ని చదవండి. మీరు trade చేసే పేరు quote చేస్తున్న venuesను లెక్కించాలన్నా, ఒక sessionను condition flagsగా విభజించాలన్నా, Strasmore terminalలో ప్రశ్నను సాధారణ ఆంగ్లంలో అడగండి.