Iceberg Order म्हणजे काय? Hidden Liquidity समजून घ्या

Iceberg order म्हणजे exchange bookवर ठेवलेला एकच limit order असतो. त्याला दोन प्रमाणे जोडलेली असतात: quoteमध्ये संपूर्ण बाजाराला दिसणारे displayed size आणि त्यामागे लपवलेला reserve. Displayed slice भरला की matching engine हा reserveमधून पुढील slice आपोआप उपलब्ध करून देतो. या नावामागे हिमनगाची रचना आहे: पाण्याच्या पातळीवर दिसणारे छोटे टोक आणि खाली लपलेला मोठा भाग. लपवण्याची किंमत queue positionच्या रूपात द्यावी लागते. प्रत्येक नव्याने उपलब्ध केलेला slice नवीन timestampसह पोस्ट होतो आणि त्या किंमतीवर आधीपासून प्रतीक्षेत असलेल्या सर्व ordersच्या मागे जातो.

Iceberg order म्हणजे काय?

समजा, एखाद्या fundला 50,000 शेअर्स खरेदी करायचे आहेत आणि तो जास्तीत जास्त $50.00 देण्यास तयार आहे. तो साधा limit order म्हणून नोंदवला, तर त्या किंमतीवरची 50,000 शेअर्सची मागणी bookमध्ये सर्वांना दिसेल. तो 500 शेअर्सच्या display sizeसह iceberg order म्हणून नोंदवला, तर bookमध्ये केवळ 500 शेअर्स दिसतील. ते 500 शेअर्स trade झाले की matching engine reserveमधून आणखी 500 शेअर्स घेतो, ते पोस्ट करतो आणि reserve संपेपर्यंत किंवा order रद्द होईपर्यंत ही प्रक्रिया सुरू राहते.

या प्रक्रियेत दोन गोष्टी कायम राहतात. हा एका venueवर एका किंमतीचा एकच order असतो आणि नोंदवल्याच्या क्षणापासून exchangeकडे त्याचे संपूर्ण प्रमाण असते.

तुम्हाला सर्वाधिक आढळणारे वर्णन — trader मोठ्या orderचे तुकडे करून ते काही तास किंवा दिवस बाजारात पाठवत राहतो — हे वेगळे तंत्र आहे. ही execution schedule असते. Algorithm अनेक स्वतंत्र child orders विविध venuesवर पाठवतो आणि त्यांची कामगिरी VWAPसारख्या benchmarkविरुद्ध मोजतो. Iceberg हा venue order attribute आहे. त्याचे slicing एका bookवर, microsecondsमध्ये, matching engineच्या आत होते.

Venueनुसार terminology बदलते. दिसणाऱ्या भागाला display quantity किंवा tip म्हणतात. उर्वरित भागाला reserve किंवा non-displayed portion म्हणतात. Nasdaqच्या rulebookमध्ये या attributेला Reserve Size म्हटले आहे.

Displayed slice किती लहान असू शकतो?

Venues displayed portionसाठी किमान मर्यादा ठेवतात. ती ठरावीक शेअरसंख्येऐवजी round lotsमध्ये व्यक्त केली जाते. Nasdaqनुसार reserve orderचा displayed size नोंदणीच्या वेळी tradingच्या एक किंवा अधिक normal unitsइतका असावा. मिश्र lot असल्यास तो जवळच्या खालच्या round lotपर्यंत round down केला जातो. Cboeच्या BZX bookमध्ये displayed quantity एक round lotपेक्षा कमी झाल्यावर ती पुन्हा भरली जाते. Venueनुसार शब्दरचना वेगळी असू शकते आणि नियमांत दुरुस्तीही होत असते. त्यामुळे दुसऱ्याकडून ऐकलेल्या संख्येवर अवलंबून राहण्याऐवजी तुम्ही ज्या venueकडे order route करता त्याचे rulebook वाचा.

Round lot आता सरसकट 100 शेअर्स राहिलेला नाही. November 3, 2025पासून लागू असलेल्या amended Regulation NMS definitionनुसार तो किंमतीनुसार बदलतो: $250.00 किंवा त्यापेक्षा कमी किंमतीसाठी 100 शेअर्स, $250.01 ते $1,000.00साठी 40 शेअर्स, $1,000.01 ते $10,000.00साठी 10 शेअर्स आणि त्यापेक्षा जास्त किंमतीसाठी एक शेअर. Exchanges प्रत्येक stockचे reassignment वर्षातून दोनदा करतात. यासाठी March किंवा September evaluation periodमधील average closing price वापरला जातो. या बदलासंबंधी Nasdaqचा vendor alert tiers आणि तारखा देतो. चार अंकी किंमत असलेल्या stockमध्ये अनुमत सर्वात लहान tip दहा शेअर्सचा असतो.

Iceberg ordersची queue priority कमी होते का?

होय. बहुतेक स्पष्टीकरणांमध्ये वगळला जाणारा हा महत्त्वाचा भाग आहे. US equity booksमध्ये resting ordersना प्रथम किंमतीनुसार आणि त्यानंतर वेळेनुसार क्रम दिला जातो. समान किंमतीवर आधी आलेला order आधी trade होतो.

Icebergचा displayed slice पोस्ट होताच त्या queueमध्ये प्रवेश करतो. तो slice पूर्ण भरल्यानंतर engine reserveमधून त्याची replenishment करतो. ही replenishment नवीन timestampसह नवीन displayed order म्हणून नोंदवली जाते आणि त्या किंमतीवरील रांगेच्या शेवटी जाते. Nasdaqच्या नियमात ही असममितता स्पष्टपणे नमूद आहे:

Reserve Order पोस्ट केल्यानंतर, displayed orderविरुद्ध execution होऊन त्याचे size normal unit of tradingपेक्षा कमी झाल्यास, नवीन displayed order नोंदवला जाईल आणि त्याला नवीन timestamp मिळेल. त्याच वेळी non-displayed orderचे size तितक्याच प्रमाणात कमी केले जाईल आणि त्याला नवीन timestamp मिळणार नाही.

ही Nasdaq Equity 4, Rule 4703(h) मधील तरतूद आहे. ती February 18, 2021 रोजी reserve order rule changeला मंजुरी देणाऱ्या SEC orderमधून उद्धृत केली आहे. Reserve आपली मूळ queue position ठेवतो, पण प्रत्येक refreshवेळी visible tipची queue position नव्याने सुरू होते. 50,000 शेअर्सचा order एका वेळी 500 शेअर्स दाखवत असल्यास तो जास्तीत जास्त एकशे वेळा refresh होऊ शकतो. प्रत्येक refreshनंतर तो त्या किंमतीवर आधीपासून resting असलेल्या सर्व displayed ordersच्या मागे जातो. लपवण्याची हीच खरी किंमत आहे.

अनेक venuesमध्ये आणखी एक किंमत द्यावी लागते. समान किंमतीवर displayed interestला non-displayed interestपेक्षा प्राधान्य मिळते. त्यामुळे reserve आधी आलेला असला तरी त्याच किंमतीवरील कोणत्याही displayed orderला तो मार्ग देतो.

Iceberg order, hidden order आणि dark pool यांतील फरक

• Iceberg lit exchangeवर resting असतो आणि त्याचा displayed slice public quoteमध्ये येतो. हा slice national best bid or offer ठरवू शकतो. त्यामागील reserve quoteमध्ये कधीही दिसत नाही.
• Fully hidden order काहीही प्रदर्शित करत नाही. तो त्याच lit exchangeवर resting असतो, आपल्या limit priceवर execute होतो आणि trade झाल्यानंतरच public dataमध्ये दिसतो. समान किंमतीवरील displayed ordersच्या मागे त्याला सामान्यतः क्रम दिला जातो.
• Dark pool हा public quote नसलेला स्वतंत्र venue असतो. Trade reporting facilityमार्फत transaction झाल्यानंतर त्याचा print tapeवर येतो.
• Block trade संपूर्ण प्रमाण एका negotiated printमध्ये हलवतो. ही quantity हळूहळू बाजारात सोडण्याच्या पद्धतीची उलट दिशा आहे.

यापैकी प्रत्येक पद्धतीत quantity आधीच जाहीर न करता हलवली जाते. त्यांच्यातील फरक order कुठे resting आहे आणि public quoteमध्ये त्यातील किती भाग कधी दिसतो यावर आधारित आहे. Hidden interest अशा किंमतींवरही असू शकते ज्या quoteमध्ये दिसत नाहीत. त्यामुळे उपलब्ध liquidityचे visible book नेहमीच अपूर्ण चित्र दाखवते. locked and crossed markets समजून घेतानाही ही बाब लक्षात ठेवणे आवश्यक आहे.

Tapeवरील किती prints लहान आकाराचे असतात?

Icebergचा footprint वाचण्यापूर्वी tapeची सामान्य रचना समजून घेणे आवश्यक आहे. खालील panelमध्ये प्रत्येक महिन्याचे share volume त्या महिन्यातील trade countने भागले आहे. या कालावधीत stock split न झालेल्या दोन परिचित कंपन्यांसाठी ही गणना केली आहे.

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च्या एका executionमध्ये सरासरी 137.4 शेअर्स होते. Jun 2026पर्यंत ही सरासरी 39.5 शेअर्स झाली. त्याच महिन्यात Coca Colaसाठी ती 47.7 होती. Institutional orders लहान झालेले नाहीत. Prints लहान झाले आहेत. आता एक parent order शेकडो किंवा हजारो लहान executionsच्या स्वरूपात tapeवर येतो. तो order लपवलेला असो, schedule केलेला असो किंवा दोन्ही असो.

एकाच sessionमध्ये जवळून पाहिल्यास हीच रचना दिसते. पुढील 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 शेअर्सपेक्षा कमी आकाराच्या printsनी executionsपैकी 88.99% वाटा घेतला, पण शेअर्सपैकी त्यांचा वाटा 22.84% होता. दुसऱ्या टोकाला, 5000 and up bucketचा printsमध्ये 0.02% वाटा आणि volumeमध्ये 48.77% वाटा होता. या वितरणात 500 शेअर्सचा print असामान्य नाही. Iceberg शोधणे कठीण असण्याचे हे पहिले कारण आहे.

Tapeवर iceberg order कसा ओळखाल?

Consolidated tape प्रत्येक executionसाठी price, size, time आणि venue दाखवते. त्यात order IDs, display quantities किंवा reserves नसतात. मात्र ते एक footprint दाखवू शकते: एका किंमतीवर, काही काळ, एकच size पुन्हा पुन्हा print होणे. त्या sizeचा एकच displayed order सहसा इतका काळ टिकला नसता. खालील panelमध्ये त्याच sessionसाठी प्रत्येक किंमत प्रत्येक print sizeसोबत जोडली आहे आणि पुनरावृत्तींची संख्या मोजली आहे.

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

सर्वाधिक पुनरावृत्ती झालेले pairing 300 shares at $300.54 होते. ते 09:34 ते 09:58 ETदरम्यान 67 वेळा print झाले. हा कालावधी 0.4 तासांचा होता. आता sessionभर त्या pairingचा अर्ध्या तासाच्या bucketsमध्ये मागोवा घ्या. पुनरावृत्ती संपूर्ण दिवसात पसरल्या होत्या की एका कालखंडात एकवटल्या होत्या, हे त्यातून दिसेल.

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 एका अर्ध्या तासाच्या bucketमध्ये परत येतो. हा bucket 09:30 ETला सुरू झाला. त्यात 67 prints झाले आणि sessionची running count 67वर पोहोचली. एका किंमतीवर तीस मिनिटांची पुनरावृत्ती ही burst आहे, दिवसभर चाललेली उपस्थिती नाही. त्यामुळे पहिल्या दृष्टीने दिसते त्यापेक्षा असा लहान footprint कमकुवत पुरावा असतो. इतक्या active stockमध्ये त्या किंमतीवर त्या आकाराचा displayed order साधारणतः काही secondsमध्ये भरला गेला असता. कोणीतरी तो पुन्हा पुन्हा उपलब्ध करून देत होता.

Iceberg detection अविश्वसनीय का असते?

कोणीतरी तो पुन्हा उपलब्ध करून देत होता, एवढीच tapeवरून प्रामाणिकपणे सांगता येणारी मर्यादा आहे. Reserve order नसतानाही याच footprintची सामान्य कारणे असू शकतात:

• Execution algorithm parent orderचे समान आकाराच्या child ordersमध्ये विभाजन करून ते brokerच्या स्वतःच्या serverवरून एकावेळी एक पाठवत असू शकतो.
• Unrelated participants समान round quantity आणि समान round price निवडत असू शकतात. Round numbersमुळे अशी निवड होण्याची शक्यता वाढते.
• Market maker एखाद्या पातळीवर तोच size पुन्हा पुन्हा requote करत असू शकतो, कारण तो त्या पातळीवर position ठेवण्यास तयार असतो.
• Print counts आणि order counts वेगळे असू शकतात. एकाच resting orderला sweepमधून अनेक fills मिळू शकतात आणि ते अनेक prints म्हणून report होऊ शकतात.

एक शांत परिस्थितीही असते. कधीही trade न झालेला iceberg कोणताही footprint सोडत नाही. Tapeवर फक्त executionsची नोंद होते. Printsवर आधारित hidden liquidityचे कोणतेही मोजमाप प्रत्यक्ष trade झालेला भाग मोजते; प्रतीक्षेत असलेला भाग त्यात कधीच येत नाही. त्यामुळे या patternकडे तपासण्यासारखी hypothesis म्हणून पाहा. Venue mix आणि quoteशी पडताळणी केल्याशिवाय त्याला विशिष्ट orderबद्दलचे तथ्य समजू नका.

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

Tradingमध्ये iceberg order म्हणजे काय?

हा दोन प्रमाणांचा limit order असतो: public quoteमध्ये दिसणारा लहान displayed size आणि displayed slice भरल्यावर exchange आपोआप उपलब्ध करून देत असलेला मोठा hidden reserve. तो एका venueवर एका किंमतीचा एकच order म्हणून resting असतो.

Iceberg ordersची queueमधील जागा कमी होते का?

Displayed sliceची जागा कमी होते. प्रत्येक replenishment नवीन timestampसह नवीन displayed order म्हणून पोस्ट केली जाते आणि त्या किंमतीवर आधीपासून resting असलेल्या सर्व ordersच्या मागे जाते. Nasdaqच्या नियमानुसार non-displayed reserve आपला मूळ timestamp कायम ठेवतो.

Level 2वर iceberg orders दिसतात का?

नाही. Depth of book displayमध्ये फक्त displayed slice दिसतो. तो सामान्य छोट्या limit orderसारखा दिसतो. Reserve trade होईपर्यंत अदृश्य राहतो आणि स्वतंत्र line म्हणून कधीही दिसत नाही.

Iceberg order आणि dark pool order एकच आहेत का?

नाही. Iceberg lit exchangeवर resting असतो आणि स्वतःचा काही भाग public quoteमध्ये दाखवतो. Dark pool order public quote नसलेल्या venueवर resting असतो. Trade print झाल्यावरच तो public dataमध्ये दिसतो.

Iceberg orders कायदेशीर आहेत का?

होय. Reserve orders हे SECकडे दाखल केलेल्या exchange rulebooksमध्ये documented order attributes आहेत. ते member firms आणि त्यांच्या customersसाठी उपलब्ध असतात. Orderच्या sizeचा काही भाग लपवणे हे order typeचे disclosed feature आहे.

येथील प्रत्येक panel तयार करणारी SQL query सोबत दिली आहे. त्यामुळे प्रत्येक संख्या कशी मोजली हे तुम्ही पाहू शकता. तुमच्या पसंतीच्या ticker आणि तारखेवर repeated print scan चालवण्यासाठी Strasmore terminalवर साध्या इंग्रजीत त्याची विनंती करा.