Iceberg Order کیا ہے؟ Hidden Liquidity کی وضاحت

An iceberg order ایک single limit order ہوتی ہے جو exchange book میں موجود رہتی ہے اور اس کے ساتھ دو quantities منسلک ہوتی ہیں: displayed size، جسے پورا market quote میں دیکھ سکتا ہے، اور اس کے پیچھے hidden reserve، جسے matching engine displayed حصے کے fill ہوتے ہی خودکار طور پر جاری کرتا ہے۔ اس کا نام اس کی شکل کی وضاحت کرتا ہے: پانی کی سطح کے اوپر ایک چھوٹا سا سرا اور زیادہ تر حجم اس کے نیچے۔ حجم چھپانے کی ایک قیمت ہوتی ہے، اور یہ queue position کی صورت میں ادا کی جاتی ہے: ہر refreshed slice کو نیا timestamp ملتا ہے اور وہ اس قیمت پر پہلے سے منتظر تمام orders کے پیچھے چلی جاتی ہے۔

Iceberg order کیا ہوتی ہے؟

فرض کریں ایک fund 50,000 shares خریدنا چاہتا ہے اور زیادہ سے زیادہ $50.00 ادا کرے گا۔ اگر اسے عام limit order کے طور پر داخل کیا جائے تو book میں اس قیمت پر 50,000 shares کی demand سب کو دکھائی دے گی۔ اگر اسے 500 کے display size والی iceberg order کے طور پر داخل کیا جائے تو book میں صرف 500 shares دکھائی دیں گے۔ جب وہ 500 shares trade ہو جائیں گے تو matching engine reserve سے مزید 500 shares نکال کر order book میں پوسٹ کرے گا، اور یہ عمل reserve ختم ہونے یا order cancel ہونے تک جاری رہے گا۔

اس پورے عمل کے دوران دو باتیں برقرار رہتی ہیں۔ یہ ایک ہی venue پر ایک ہی قیمت کی ایک order ہوتی ہے، اور exchange نے داخل کیے جانے کے لمحے سے پوری quantity اپنے پاس رکھی ہوتی ہے۔

جو وضاحت آپ اکثر سنیں گے، یعنی ایک trader کا بڑی order کو حصوں میں تقسیم کر کے گھنٹوں یا دنوں میں market میں بھیجنا، ایک مختلف technique ہے۔ یہ execution schedule ہوتا ہے، جسے algorithm چلاتا ہے۔ اس میں کئی venues پر متعدد الگ child orders بھیجے جاتے ہیں اور کارکردگی کو VWAP جیسے benchmark کے مقابلے میں ناپا جاتا ہے۔ Iceberg، venue order attribute ہے۔ اس میں slicing matching engine کے اندر، microseconds میں، ایک ہی book پر ہوتی ہے۔

مختلف venues میں terminology بدل سکتی ہے۔ ظاہر ہونے والے حصے کو display quantity یا tip کہا جاتا ہے، جبکہ باقی حصے کو reserve یا non-displayed portion کہا جاتا ہے۔ Nasdaq کے rulebook میں اس attribute کو Reserve Size کہا گیا ہے۔

Displayed slice کم سے کم کتنی ہو سکتی ہے؟

Venues displayed portion کے لیے minimum مقرر کرتے ہیں اور اسے fixed share count کے بجائے round lots میں ظاہر کرتے ہیں۔ Nasdaq کے مطابق reserve order کا displayed size entry کے وقت trading کی ایک یا اس سے زیادہ normal units پر مشتمل ہونا چاہیے۔ Mixed lot کو قریب ترین کم round lot تک round down کیا جاتا ہے۔ Cboe کا BZX book displayed quantity کو اس وقت replenish کرتا ہے جب وہ ایک round lot سے کم ہو جائے۔ الفاظ venue کے لحاظ سے مختلف ہوتے ہیں اور قواعد میں ترمیم بھی ہو سکتی ہے، اس لیے second-hand بتائی گئی کسی number پر بھروسا کرنے کے بجائے اس venue کا rulebook پڑھیں جہاں آپ order route کرتے ہیں۔

Round lot اب ہر جگہ مقررہ 100 shares بھی نہیں ہوتا۔ amended Regulation NMS definition کے تحت، جو November 3, 2025 سے نافذ ہے، اس کا حجم price کے ساتھ بدلتا ہے: $250.00 اور اس سے کم قیمت پر 100 shares، $250.01 سے $1,000.00 تک 40 shares، $1,000.01 سے $10,000.00 تک 10 shares، اور اس سے زیادہ قیمت پر one share۔ Exchanges ہر stock کو سال میں دو مرتبہ، March یا September کے evaluation period کے دوران اس کی average closing price کی بنیاد پر دوبارہ assign کرتے ہیں۔ اس تبدیلی کے بارے میں Nasdaq کا vendor alert tiers اور dates فراہم کرتا ہے۔ چار ہندسوں والی price کے stock میں کم سے کم اجازت یافتہ tip ten shares ہوتی ہے۔

کیا iceberg orders queue priority کھو دیتی ہیں؟

ہاں، اور یہی وہ حصہ ہے جسے زیادہ تر وضاحتیں نظرانداز کر دیتی ہیں۔ US equity books میں resting orders کو پہلے price اور پھر time کی بنیاد پر rank کیا جاتا ہے۔ ایک ہی قیمت پر پہلے پہنچنے والی order پہلے trade کرتی ہے۔

Iceberg کا displayed slice پوسٹ ہوتے ہی queue میں شامل ہو جاتا ہے۔ جب یہ slice fill ہو جائے اور engine اسے reserve سے replenish کرے تو replenishment ایک نئی displayed order کے طور پر نئے timestamp کے ساتھ داخل ہوتی ہے اور اس price پر queue کے آخر میں چلی جاتی ہے۔ Nasdaq کا rule اس فرق کو واضح طور پر بیان کرتا ہے:

جب Reserve Order پوسٹ کی جاتی ہے، اگر displayed order کے خلاف execution اس کا size trading کی normal unit سے کم کر دے، تو ایک نئی displayed order داخل کی جائے گی اور اسے نیا timestamp ملے گا، جبکہ non-displayed order کا size اسی مقدار سے کم کیا جائے گا اور اسے نیا timestamp نہیں ملے گا۔

یہ Nasdaq Equity 4، Rule 4703(h) ہے، جسے reserve order rule change کی منظوری دینے والے SEC order مورخہ February 18, 2021 سے نقل کیا گیا ہے۔ Reserve اپنی اصل standing برقرار رکھتا ہے، جبکہ visible tip ہر refresh پر دوبارہ queue میں شامل ہوتا ہے۔ 50,000 shares کی order اگر ایک وقت میں 500 shares دکھائے تو وہ زیادہ سے زیادہ hundred times refresh ہو سکتی ہے، اور ہر refresh اس price پر پہلے سے موجود تمام displayed orders کے پیچھے دوبارہ شروع ہوتا ہے۔ یہی volume چھپانے کی حقیقی قیمت ہے۔

بہت سے venues ایک اضافی قیمت بھی عائد کرتے ہیں۔ ایک ہی price پر displayed interest کو non-displayed interest پر priority حاصل ہوتی ہے۔ اس لیے reserve وہاں موجود کسی بھی displayed order کے بعد trade کرے گا، چاہے reserve پہلے داخل ہوا ہو۔

Iceberg order بمقابلہ hidden order بمقابلہ dark pool

• Iceberg order ایک lit exchange پر resting ہوتی ہے اور اپنا displayed slice public quote میں شامل کرتی ہے، جہاں وہ national best bid or offer مقرر کر سکتی ہے۔ اس کے پیچھے موجود reserve quote میں کبھی ظاہر نہیں ہوتا۔
• Fully hidden order کچھ بھی display نہیں کرتی۔ یہ اسی lit exchange پر resting رہتی ہے، اپنی limit price پر execute ہوتی ہے، اور public data میں صرف trade ہونے کے بعد دکھائی دیتی ہے۔ Venues عموماً ایک ہی price پر اسے displayed orders کے پیچھے rank کرتے ہیں۔
• ایک dark pool الگ venue ہوتا ہے جس کا کوئی public quote نہیں ہوتا۔ Trade کے بعد print، trade reporting facility کے ذریعے tape تک پہنچتا ہے۔
• ایک block trade پوری quantity کو ایک negotiated print میں منتقل کرتا ہے۔ اس کا maximum size اور minimum duration مقرر ہوتا ہے، اور یہ quantity کو بتدریج market میں بھیجنے کے بالکل برعکس طریقہ ہے۔

ان تمام طریقوں میں quantity کو پہلے سے ظاہر کیے بغیر منتقل کیا جاتا ہے۔ فرق یہ ہے کہ order کہاں resting ہے اور public quote میں اس کا کتنا حصہ دکھائی دیتا ہے۔ Hidden interest ان prices پر بھی موجود ہو سکتا ہے جو quote میں کبھی ظاہر نہیں ہوتیں۔ اس لیے visible book available liquidity کی ہمیشہ ایک جزوی تصویر ہوتی ہے، جسے locked and crossed markets کے ساتھ ذہن میں رکھنا چاہیے۔

Tape کے کتنے prints چھوٹے size میں ہوتے ہیں؟

Iceberg کے footprint کو سمجھنے سے پہلے tape کی معمول کی texture کو سمجھنا ضروری ہے۔ ذیل کا panel ہر ماہ کے share volume کو اسی ماہ کے trade count سے تقسیم کرتا ہے۔ اس میں دو معروف names شامل ہیں جن کے لیے اس مدت کے دوران stock splits نہیں ہوئے۔

SELECT
    toString(month_start)                                                            AS month,
    formatDateTime(month_start, '%b %Y')                                             AS month_label,
    round(sumIf(volume, ticker = 'MSFT') / sumIf(transactions, ticker = 'MSFT'), 1)  AS msft_shares_per_print,
    round(sumIf(volume, ticker = 'KO')   / sumIf(transactions, ticker = 'KO'), 1)    AS ko_shares_per_print
FROM
(
    SELECT
        toStartOfMonth(toDate(toTimeZone(window_start, 'America/New_York'))) AS month_start,
        ticker,
        volume,
        transactions
    FROM global_markets.delayed_stocks_minute_aggs
    WHERE ticker IN ('MSFT', 'KO')
      AND window_start >= toDateTime('2019-01-01 00:00:00', 'UTC')
      AND window_start <  toDateTime('2026-07-01 00:00:00', 'UTC')
)
GROUP BY month_start
HAVING sumIf(transactions, ticker = 'MSFT') > 0
   AND sumIf(transactions, ticker = 'KO') > 0
ORDER BY month_start

Jan 2019 میں Microsoft کی ایک average execution میں 137.4 shares شامل تھیں۔ Jun 2026 تک یہ average 39.5 shares رہ گیا، جبکہ اسی ماہ Coca Cola کے لیے یہ 47.7 تھا۔ Institutional orders چھوٹی نہیں ہوئی ہیں۔ Prints چھوٹے ہو گئے ہیں۔ اب ایک parent order tape تک سیکڑوں یا ہزاروں چھوٹی executions کی صورت میں پہنچتی ہے، خواہ وہ hide کی جائے، schedule کی جائے، یا دونوں طریقے استعمال کیے جائیں۔

ایک single session کو قریب سے دیکھیں تو یہی texture دوبارہ نظر آتی ہے۔ اگلا panel June 17, 2026 کو AAPL کے تمام prints کو size کے لحاظ سے گروپ کرتا ہے۔

WITH tape AS
(
    SELECT size
    FROM global_markets.stocks_trades
    WHERE ticker = 'AAPL'
      AND sip_timestamp >= toDateTime('2026-06-17 04:00:00', 'UTC')
      AND sip_timestamp <  toDateTime('2026-06-18 04:00:00', 'UTC')
)
SELECT
    multiIf(size < 100,  'under 100',
            size < 200,  '100 to 199',
            size < 500,  '200 to 499',
            size < 1000, '500 to 999',
            size < 5000, '1000 to 4999',
                         '5000 and up')                    AS print_size_bucket,
    count()                                                AS prints,
    round(100 * count() / sum(count()) OVER (), 2)         AS pct_of_prints,
    round(100 * sum(size) / sum(sum(size)) OVER (), 2)     AS pct_of_shares
FROM tape
GROUP BY print_size_bucket
ORDER BY min(size)

100 shares سے کم prints اس دن کی 88.99% executions پر مشتمل تھے، لیکن ان میں shares کا صرف 22.84% حصہ شامل تھا۔ دوسری طرف 5000 and up bucket میں prints کا 0.02% اور volume کا 48.77% حصہ تھا۔ اس distribution میں 500 shares کا print غیر معمولی نہیں ہے، اور یہی iceberg detection مشکل ہونے کی پہلی وجہ ہے۔

Tape پر iceberg order کو کیسے پہچانا جائے؟

Consolidated tape ہر execution کے لیے price، size، time اور venue فراہم کرتی ہے۔ اس میں order IDs، display quantities یا reserves شامل نہیں ہوتے۔ Tape جو چیز دکھا سکتی ہے وہ ایک footprint ہے: ایک ہی price پر ایک ہی size کا بار بار print ہونا، ایسے دورانیے میں جس میں اتنے size کی ایک single displayed order عموماً برقرار نہ رہتی۔ ذیل کا panel اسی session کے لیے ہر price کو ہر print size کے ساتھ ملاتا ہے اور repetitions شمار کرتا ہے۔

SELECT
    concat(toString(size), ' shares at $', toString(round(toFloat64(price), 2)))                  AS level_and_size,
    count()                                                                                       AS prints,
    formatDateTime(toTimeZone(min(sip_timestamp), 'America/New_York'), '%H:%i')                    AS first_et,
    formatDateTime(toTimeZone(max(sip_timestamp), 'America/New_York'), '%H:%i')                    AS last_et,
    round(dateDiff('minute', min(sip_timestamp), max(sip_timestamp)) / 60.0, 1)                    AS hours_spanned
FROM global_markets.stocks_trades
WHERE ticker = 'AAPL'
  AND sip_timestamp >= toDateTime('2026-06-17 04:00:00', 'UTC')
  AND sip_timestamp <  toDateTime('2026-06-18 04:00:00', 'UTC')
  AND size >= 200
GROUP BY price, size
ORDER BY prints DESC
LIMIT 12

سب سے زیادہ repeated pairing 300 shares at $300.54 تھی۔ یہ 67 مرتبہ، 09:34 اور 09:58 ET کے درمیان، 0.4 گھنٹوں کے عرصے میں print ہوئی۔ اب session کے دوران اس pairing کو half-hour buckets میں follow کریں تاکہ معلوم ہو سکے کہ repetitions پورے دن میں پھیلی ہوئی تھیں یا ایک ہی مختصر مدت میں جمع تھیں۔

WITH top_level AS
(
    SELECT
        price,
        size
    FROM global_markets.stocks_trades
    WHERE ticker = 'AAPL'
      AND sip_timestamp >= toDateTime('2026-06-17 04:00:00', 'UTC')
      AND sip_timestamp <  toDateTime('2026-06-18 04:00:00', 'UTC')
      AND size >= 200
    GROUP BY price, size
    ORDER BY count() DESC, size DESC, price DESC
    LIMIT 1
)
SELECT
    formatDateTime(toStartOfInterval(toTimeZone(sip_timestamp, 'America/New_York'), INTERVAL 30 MINUTE), '%H:%i') AS et_time,
    count()                                    AS prints,
    sum(count()) OVER (ORDER BY et_time)       AS cum_prints
FROM global_markets.stocks_trades
WHERE ticker = 'AAPL'
  AND sip_timestamp >= toDateTime('2026-06-17 04:00:00', 'UTC')
  AND sip_timestamp <  toDateTime('2026-06-18 04:00:00', 'UTC')
  AND (price, size) IN (SELECT price, size FROM top_level)
GROUP BY et_time
ORDER BY et_time

وہ ایک جگہ جمع تھیں۔ Trace دوبارہ ایک single half-hour bucket کے طور پر سامنے آتی ہے، جو 09:30 ET پر شروع ہوئی۔ اس bucket میں 67 prints تھے اور session کا running count 67 تک پہنچا۔ ایک ہی price پر thirty minutes کی repetition ایک burst ہے، پورے دن جاری رہنے والی سرگرمی نہیں۔ اس لیے اتنا مختصر footprint بظاہر نظر آنے والے pattern سے کمزور evidence فراہم کرتا ہے۔ اتنی active name میں اس price پر اتنے size کی displayed order عموماً seconds میں consume ہو جاتی۔ کوئی چیز اسے بار بار واپس لا رہی تھی۔

Iceberg detection قابلِ اعتماد کیوں نہیں؟

“کوئی چیز اسے بار بار واپس لا رہی تھی” tape کی فراہم کردہ معلومات کی حقیقی حد ہے۔ اسی footprint کی عام وضاحتیں بھی ہو سکتی ہیں جن میں reserve order شامل نہ ہو:

• کوئی execution algorithm parent order کو برابر child orders میں تقسیم کر کے broker کے اپنے server سے ایک ایک order بھیج رہا ہو۔
• غیر متعلقہ participants ایک ہی round quantity اور ایک ہی round price اختیار کر رہے ہوں، کیونکہ round numbers اس رویے کی حوصلہ افزائی کرتے ہیں۔
• کوئی market maker اس level پر بار بار وہی size requote کر رہا ہو جہاں وہ position برقرار رکھنے پر آمادہ ہو۔
• Print counts اور order counts مختلف ہوں، کیونکہ ایک resting order ایسی sweep سے fill ہو سکتی ہے جو کئی prints کے طور پر report ہو۔

ایک خاموش صورت بھی موجود ہے۔ جو iceberg کبھی trade نہ کرے وہ کوئی footprint نہیں چھوڑتی، اور tape صرف executions record کرتی ہے۔ Prints سے بنائی گئی hidden liquidity کی کوئی بھی پیمائش صرف traded حصے کو ناپتی ہے، اس حصے کو نہیں جو انتظار کرتا رہا۔ اس pattern کو ایک ایسی hypothesis سمجھیں جسے venue mix اور quote کے مقابلے میں جانچنا چاہیے، نہ کہ کسی مخصوص order کے بارے میں ثابت شدہ حقیقت۔

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

Trading میں iceberg order کیا ہوتی ہے؟

یہ دو quantities والی limit order ہوتی ہے: ایک چھوٹا displayed size جو public quote میں ظاہر ہوتا ہے، اور ایک بڑا hidden reserve جسے exchange ہر بار displayed slice fill ہونے پر خودکار طور پر جاری کرتا ہے۔ یہ ایک ہی venue پر ایک ہی price کی single order کے طور پر موجود رہتی ہے۔

کیا iceberg orders queue میں اپنی جگہ کھو دیتی ہیں؟

Displayed slice اپنی جگہ کھو دیتی ہے۔ ہر replenishment نئے timestamp کے ساتھ نئی displayed order کے طور پر پوسٹ ہوتی ہے اور اس price پر پہلے سے resting تمام orders کے پیچھے چلی جاتی ہے۔ Nasdaq کے rule کے تحت non-displayed reserve اپنا original timestamp برقرار رکھتا ہے۔

کیا Level 2 پر iceberg orders دیکھی جا سکتی ہیں؟

نہیں۔ Depth of book display صرف displayed slice دکھاتا ہے، جو ایک عام چھوٹی limit order جیسی نظر آتی ہے۔ Reserve اس وقت تک پوشیدہ رہتا ہے جب تک وہ trade نہ کرے، اور اپنی الگ line کے طور پر کبھی ظاہر نہیں ہوتا۔

کیا iceberg order اور dark pool order ایک ہی چیز ہیں؟

نہیں۔ Iceberg order ایک lit exchange پر resting رہتی ہے اور public quote میں اپنا کچھ حصہ شائع کرتی ہے۔ Dark pool order ایسے venue پر resting رہتی ہے جس کا کوئی public quote نہیں ہوتا، اور trade صرف print ہونے کے وقت public data میں ظاہر ہوتی ہے۔

کیا iceberg orders قانونی ہیں؟

ہاں۔ Reserve orders، SEC کے پاس filed exchange rulebooks میں documented order attributes ہیں اور member firms اور ان کے customers کے لیے دستیاب ہیں۔ Order size کا ایک حصہ چھپانا order type کی disclosed feature ہے۔

یہاں موجود ہر panel اس کی تیاری میں استعمال ہونے والی SQL کے ساتھ فراہم کیا گیا ہے، تاکہ آپ دیکھ سکیں کہ ہر number کیسے شمار کیا گیا۔ اپنی پسند کے ticker اور date پر repeated print scan چلانے کے لیے Strasmore terminal پر plain English میں اس کی درخواست کریں۔