Self-Match Prevention اور Wash Trades کی وضاحت

Self-match prevention ایک matching engine feature ہے جو ایک ہی firm کے دو orders کو باہم trade کرنے سے روکتا ہے۔ Order submit کرتے وقت اس کے ساتھ ایک identifier منسلک ہوتا ہے۔ جب ایک ہی identifier والے دو orders ایک دوسرے سے cross ہونے والے ہوں تو engine trade print ہونے سے پہلے ایک order یا دونوں کو cancel کر دیتا ہے۔ Self-match prevention وہ venue plumbing ہے جسے آپ فعال کرتے ہیں، جبکہ wash trades پر پابندی قانون کا تقاضا ہے۔ دونوں ایک ہی دائرے کا احاطہ نہیں کرتے۔

جس لمحے دوسری strategy کسی ایسے instrument میں quote دینے لگتی ہے جس میں آپ کی پہلی strategy پہلے ہی quote دے رہی ہو، یہ rule آپ پر لاگو ہو جاتا ہے۔ ایک ہی symbol پر دو-ladder grid bot بھی اسی اصول کے تحت آتا ہے جس طرح کسی bank desk کا نظام۔

matching engine میں self-match prevention کیسے کام کرتا ہے

Venue کو موصول ہونے والے ہر order میں ایسے fields ہوتے ہیں جنہیں engine matching سے پہلے پڑھتا ہے: side، price، size، time in force۔ Self-match prevention میں دو مزید fields شامل ہوتے ہیں۔ پہلا identifier ہوتا ہے، یعنی number یا string جو بتاتا ہے کہ order کس firm، account یا strategy group سے تعلق رکھتا ہے۔ دوسرا instruction ہوتا ہے، جو engine کو بتاتا ہے کہ ایک ہی identifier والے دو live orders کے باہم trade کے قریب پہنچنے پر کیا کارروائی کرنی ہے۔

یہ check اس لمحے چلتا ہے جب 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 ہو جاتا ہے، اور باقی order live رہتا ہے۔

چاروں صورتوں میں trade نہیں ہوتا۔ Tape پر کوئی print نہیں آتا، fill log میں کچھ درج نہیں ہوتا، بلکہ ایک leg یا دونوں legs پر unsolicited cancel موصول ہوتا ہے۔

Queue position اس عمل کی پوشیدہ لاگت ہے۔ Cancel-oldest instruction کے تحت cancel ہونے والا resting order انتظار کے دوران حاصل کیا گیا پورا فائدہ کھو دیتا ہے۔ price-time priority کے تحت یہ نقصان مکمل ہوتا ہے: دوبارہ داخل کیا گیا order ان تمام orders کے پیچھے چلا جاتا ہے جو اس کے book میں موجود رہنے کے دوران queue میں شامل ہوئے تھے۔ ہماری queue position کا تخمینہ لگانے کی رہنما بتاتی ہے کہ queue میں اس مقام کی کیا قدر ہے۔

ایک instrument، کئی books

یہ check venue کی سطح پر ہوتا ہے۔ Engine صرف ان orders کا موازنہ کرتا ہے جو اسی کے اپنے پاس موجود ہوں۔ مختلف books میں resting آپ کے دو orders ایک دوسرے کو دکھائی نہیں دیتے، اور کوئی US equities mechanism ان books کے درمیان نہیں پھیلتا۔ ایک ہی US stock بیک وقت کئی books میں quote ہو سکتا ہے۔ ذیل کا panel 10 جون 2026 کی صبح پندرہ منٹ کی ایک window میں چھ معروف ناموں کے لیے الگ الگ quoting اور printing 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

AAPL نے اس پندرہ منٹ میں 16 الگ venues سے bids حاصل کیں، اور prints ان میں سے 17 venues پر آئے۔ Panel میں سب سے کم traded نام نے بھی 11 quoting venues سے bids حاصل کیں۔ Smart order router جو design کے تحت child orders تقسیم کرتا ہے، اکثر آپ کی دونوں strategies کو مختلف books میں بھیج دے گا، جہاں engine-level check لاگو نہیں ہوتا۔ Firms یہ خلا upstream، یعنی order management layer میں، orders کے building سے باہر جانے سے پہلے پُر کرتی ہیں۔ ایک ہی price پر مختلف books میں opposite sides پر موجود آپ کے orders locked یا crossed market بھی پیدا کر سکتے ہیں، جس کے اپنے rules ہوتے ہیں۔

ایک book ایک session میں کتنے matches بناتی ہے

Self-match check engine کے بنائے ہوئے ہر match کے راستے میں موجود ہوتا ہے، اور 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 کے prints آئے، جبکہ 19:45 ET پر 1345 prints آئے۔ یہ تعداد ان 64 buckets میں تھی جنہوں نے 200 prints کی حد عبور کی۔ ہر print orders کی ایک ایسی جوڑی ہے جسے engine نے آپس میں ملایا، اور engine دونوں sides کے identifiers پڑھ کر ہی انہیں ملنے دیتا ہے۔ Book میں resting ہونے والا ہر order دن کے بعد کے حصے میں اسی account کے کسی دوسرے order سے match ہونے کا ممکنہ امیدوار ہوتا ہے۔

جب self-trade print ہو جائے تو tape کیا دکھاتی ہے

روکا گیا self-match اپنے پیچھے کچھ نہیں چھوڑتا۔ Tape صرف executed trades دکھاتی ہے، اور ہر print کے ساتھ condition flags ہوتے ہیں۔ یہ codes reporting venue trade کے طریقۂ کار کی وضاحت کے لیے منسلک کرتی ہے۔ ذیل کا 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 دکھاتا ہے۔ فہرست پڑھتے ہوئے اس چیز کو نوٹ کریں جو موجود نہیں۔ کوئی code یہ نہیں بتاتا کہ دونوں orders ایک ہی firm سے آئے تھے۔ جو 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 کرتے ہیں، اور اگر setup نہ کریں تو engine آپ کے دونوں orders کو معمول کے مطابق خوشی سے match کر دے گا۔ Wash trade prohibition optional نہیں ہے اور کسی 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 میں دوبارہ بیان کرتا ہے۔ FINRA Rule 5210 broker-dealers کے لیے دونوں کے تحت لاگو ہوتا ہے، جبکہ اس کا supplementary material self-trades سے براہِ راست نمٹتا ہے: ایک firm میں دو غیر متعلقہ algorithms کے درمیان trades بذاتِ خود خلاف ورزی نہیں ہوتے، لیکن firm سے توقع کی جاتی ہے کہ وہ انہیں review اور reduce کرنے کے لیے policies برقرار رکھے۔

ایک سے زیادہ strategies چلانے والوں کے لیے اس کے دو نتائج نکلتے ہیں۔ کسی ایسے venue پر self-cross prohibition کی خلاف ورزی کر سکتا ہے جہاں آپ نے کوئی self-match instruction مقرر ہی نہ کیا ہو، کیونکہ rule transaction اور اس کے پیچھے موجود intent سے منسلک ہوتا ہے۔ Self-match prevention جس self-cross کو روک دے، وہ کسی خلاف ورزی کا سبب نہیں بنتا: اسے روکنا ہی اس mechanism کا مقصد ہے۔

آپریٹرز اسے کیسے configure کرتے ہیں: CME، ICE، LME اور MiFID II

CME Globex پر self-match prevention order entry کے وقت submit کیے گئے identifier کے ذریعے چلتی ہے۔ Firms وہ identifiers پہلے register کرتی ہیں جنہیں وہ استعمال کریں گی۔ ہر order میں ایک identifier ہوتا ہے، اور paired instruction یہ بتاتی ہے کہ ایک ہی identifier والے دو orders ملنے پر engine کس side کو cancel کرے۔ Identifier کے بغیر بھیجے گئے orders معمول کے مطابق match ہوتے ہیں۔ نئے operator کے لیے یہی trap ہے: default حالت off ہوتی ہے۔

ICE، Self-Trade Prevention Functionality چلاتا ہے، جسے order by order کے بجائے trading firm identifier کے ساتھ configure کیا جاتا ہے۔ اس میں cancel outcomes کی یہی family استعمال ہوتی ہے۔ London Metal Exchange، LMEselect پر member trading identifiers کے لیے Self-Execution Prevention فراہم کرتا ہے۔ Europe میں MiFID II کا Article 17 algorithmic trading کرنے والی ہر investment firm پر systems and controls کی ذمہ داری عائد کرتا ہے۔ اس میں testing، kill functionality اور disorderly trading کی prevention شامل ہیں۔ Article 48 venue پر بھی اسی نوعیت کی ذمہ داری عائد کرتا ہے، اور venue-side prevention tools اس کے ساتھ standard equipment بن گئے ہیں۔

Configuration عموماً symbol by symbol کے بجائے account یا firm level پر ہوتی ہے۔ ایک single underlying کی option surface کا size اس کی وجہ واضح کرتا ہے۔

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 میں 1579 الگ سے trade کیے جا سکنے والے contracts موجود تھے جن میں volume تھا۔ یہ contracts 112 strikes میں پھیلے ہوئے تھے، جبکہ panel میں اسی نوعیت کے 21 sessions شامل ہیں۔ اتنی تعداد میں contract by contract rule مقرر کرنا ناقابلِ عمل ہے۔ اس کے بجائے identifier account کے ساتھ منسلک ہوتا ہے اور اس account کے بھیجے ہوئے ہر order کے ساتھ آگے جاتا ہے۔

وہ failure mode جس کی وضاحت آپ کے fill logs نہیں کریں گے

عملی صورت یہ ہے۔ Cancel-newest instruction آپ کے بھیجے ہوئے order کو arrival کے وقت ہی ختم کر دیتی ہے، اس سے پہلے کہ وہ match ہو سکے۔ Bot کے اندر سے sequence ایک نئے order کے بعد ایسے cancel کے طور پر دکھائی دیتا ہے جس کی درخواست کسی نے نہیں کی۔ نہ fill ہوتا ہے، نہ reject، اور نہ ہی error string میں وجہ لکھی ہوتی ہے۔ اس لیے پہلی بار اس صورتحال کا سامنا کرنے والے operators عموماً اپنے cancel path میں bug تلاش کرتے ہیں۔

دو عادات اس صورتحال کو سمجھنے میں مدد دیتی ہیں۔ Venue کے order status messages کو normalized summary کے بجائے لفظ بہ لفظ log کریں، کیونکہ prevention reason عموماً اسی message کے ایک field میں موجود ہوتی ہے۔ ایسے ہر cancel پر alert جاری کریں جسے آپ کے اپنے code نے originate نہ کیا ہو۔ یہ alert آپ کے automated trading circuit breakers کے ساتھ ہونا چاہیے، کیونکہ failure اسی نوعیت کا ہے: venue نے آپ کے order کی state تبدیل کی اور آپ کا process ایسے چلتا رہا جیسے کچھ ہوا ہی نہ ہو۔

اکثر پوچھے جانے والے سوالات

self-match prevention کیا ہے؟

یہ matching engine کا ایک check ہے جو ایک ہی firm یا account identifier والے دو orders کو باہم trade کرنے سے روکتا ہے۔ جب دونوں orders match ہونے والے ہوں تو engine order کے ساتھ منسلک instruction کے مطابق resting order، incoming order یا دونوں کو cancel کر دیتا ہے۔

کیا self-trade اور wash trade ایک ہی چیز ہیں؟

نہیں۔ Self-trade ایک ہی beneficial owner کے دو orders کے درمیان ہونے والی کوئی بھی execution ہے۔ Wash trade ایسا self-trade ہے جس میں حقیقی market risk لینے کے بغیر اور activity کا گمراہ کن تاثر پیدا کرنے کے ارادے سے order داخل کیا جائے۔ غیر متعلقہ algorithms کے درمیان غیر ارادی self-trades کو arranged trades سے مختلف سمجھا جاتا ہے، تاہم firms سے پھر بھی ان کی نگرانی کی توقع کی جاتی ہے۔

کیا self-match prevention مختلف exchanges کے درمیان کام کرتی ہے؟

نہیں۔ ہر matching engine یہ check صرف اپنی book میں موجود orders پر لاگو کرتا ہے۔ ایک firm کے دو orders جو دو مختلف venues پر resting ہوں، ایک دوسرے کے ساتھ trade کر سکتے ہیں۔ اس صورت میں venues سے اوپر firm کے اپنے pre-trade checks کو یہ کام کرنا ہوتا ہے۔

میرا order fill اور وجہ کے بغیر cancel کیوں ہوا؟

Cancel-newest self-match instruction اس کی ایک ممکنہ وجہ ہے۔ Venue نے آپ کے identifier والے resting order سے match ہونے سے پہلے، arrival کے وقت order cancel کر دیا۔ وجہ عموماً rejection کے بجائے venue کے cancel message کے ایک field میں ظاہر ہوتی ہے۔

کن venues پر self-match prevention identifier ضروری ہے؟

تقاضے venue اور product کے لحاظ سے مختلف ہوتے ہیں۔ CME order entry کے وقت identifier طلب کرتا ہے، جسے پہلے register کرنا ہوتا ہے۔ ICE اور London Metal Exchange firm level پر اپنی configurations فراہم کرتے ہیں، جبکہ European venues پر MiFID II کے تحت systems and controls کی ذمہ داریاں عائد ہوتی ہیں۔ آپ جس product میں trade کرتے ہیں، اس کا venue rulebook حتمی اتھارٹی ہے۔

یہاں موجود ہر panel کے ساتھ وہ SQL شامل ہے جس سے اسے تیار کیا گیا۔ کسی بھی panel کو expand کر کے اسے پڑھیں۔ جس نام میں آپ trade کرتے ہیں اس کے quoting venues گننے، یا کسی session کو condition flags میں تقسیم کرنے کے لیے Strasmore terminal پر سوال سادہ English میں لکھیں۔