Iceberg Orders: దాగిన లిక్విడిటీ ఎలా పనిచేస్తుంది

Iceberg order అనేది ఎక్స్చేంజ్ ఆర్డర్ బుక్‌లో ఉండే ఒకే limit order. దీనికి రెండు పరిమాణాలు ఉంటాయి. కోట్‌లో మొత్తం మార్కెట్ చూడగలిగే displayed size ఒకటి. దాని వెనుక దాచిన reserve మరొకటి. displayed భాగం పూర్తిగా నెరవేరినప్పుడు matching engine ఆ reserve నుంచి తదుపరి భాగాన్ని ఆటోమేటిక్‌గా విడుదల చేస్తుంది. ఈ పేరు నీటి పైభాగంలో కనిపించే చిన్న కొన, దిగువన దాగి ఉండే పెద్ద భాగం ఆకారాన్ని సూచిస్తుంది. దాచడానికి ఒక ఖర్చు ఉంటుంది. అది queue position రూపంలో చెల్లించాలి. ప్రతి కొత్త slice కొత్త timestampతో పోస్ట్ అవుతుంది. అదే ధర వద్ద ఇప్పటికే వేచి ఉన్న అన్ని ఆర్డర్ల వెనుకకు అది వెళ్తుంది.

Iceberg order అంటే ఏమిటి?

ఒక ఫండ్ 50,000 షేర్లను కొనుగోలు చేయాలని, ఒక్కో షేరుకు గరిష్ఠంగా $50.00 చెల్లించాలని అనుకుందాం. సాధారణ limit orderగా నమోదు చేస్తే, ఆ ధర వద్ద 50,000 షేర్ల డిమాండ్‌ను అందరూ చూడగలరు. display size 500గా ఉన్న iceberg orderగా నమోదు చేస్తే, బుక్‌లో 500 షేర్లు మాత్రమే కనిపిస్తాయి. ఆ 500 షేర్లు ట్రేడ్ అయినప్పుడు matching engine reserve నుంచి మరో 500 షేర్లను తీసుకుని పోస్ట్ చేస్తుంది. Reserve పూర్తయ్యే వరకు లేదా ఆర్డర్ రద్దయ్యే వరకు ఇదే విధానం కొనసాగుతుంది.

ఈ ప్రక్రియలో రెండు విషయాలు మారవు. ఇది ఒకే venueలో, ఒకే ధర వద్ద ఉన్న ఒకే ఆర్డర్. అలాగే ఆర్డర్ నమోదు చేసిన క్షణం నుంచే మొత్తం పరిమాణాన్ని ఎక్స్చేంజ్ తన వద్ద ఉంచుతుంది.

మీరు ఎక్కువగా వినే వివరణ వేరే విధానానికి చెందుతుంది. ఒక ట్రేడర్ పెద్ద ఆర్డర్‌ను చిన్న భాగాలుగా విభజించి, గంటలు లేదా రోజులు వాటిని క్రమంగా మార్కెట్‌లోకి పంపడం ఆ విధానం. అది execution schedule. Algorithm అనేక వేర్వేరు child ordersను పలు venuesకు పంపుతుంది. వాటి పనితీరును VWAP వంటి benchmarkతో పోలుస్తారు. Iceberg అనేది venueలోని order attribute. Slicing మాత్రం ఒకే order bookలో matching engineలో, microseconds వ్యవధిలో జరుగుతుంది.

పదజాలం venueను బట్టి మారుతుంది. కనిపించే భాగాన్ని display quantity లేదా tip అంటారు. మిగతా భాగాన్ని reserve లేదా non-displayed portion అంటారు. Nasdaq rulebookలో ఈ attributeకు Reserve Size అనే పేరు ఉంది.

Displayed slice ఎంత చిన్నగా ఉండవచ్చు?

Venues displayed portionకు కనీస పరిమాణాన్ని నిర్ణయిస్తాయి. దాన్ని సాధారణంగా fixed share countగా కాకుండా round lotsలో వ్యక్తం చేస్తారు. Nasdaq నిబంధనల ప్రకారం reserve orderలో displayed size, నమోదు చేసే సమయంలో ఒకటి లేదా అంతకంటే ఎక్కువ normal units of trading ఉండాలి. మిశ్రమ lot ఉంటే దాన్ని సమీపంలోని దిగువ round lotకు తగ్గిస్తారు. Cboe యొక్క BZX bookలో displayed quantity ఒక round lot కంటే తక్కువకు తగ్గినప్పుడు దాన్ని మళ్లీ replenishment చేస్తారు. Venueను బట్టి పదజాలం మారవచ్చు, నిబంధనలు సవరించబడవచ్చు. కాబట్టి ఇతరుల ద్వారా వినిన సంఖ్యను నమ్మకుండా, మీరు ఆర్డర్ పంపే venue rulebookను చదవాలి.

Round lot ఇకపై స్థిరంగా 100 షేర్లు కాదు. November 3, 2025 నుంచి అమల్లో ఉన్న amended Regulation NMS నిర్వచనం ప్రకారం ఇది ధరతో మారుతుంది: $250.00 లేదా అంతకంటే తక్కువ ధరకు 100 షేర్లు, $250.01 నుంచి $1,000.00 వరకు 40 షేర్లు, $1,000.01 నుంచి $10,000.00 వరకు 10 షేర్లు, అంతకంటే ఎక్కువ ధరకు ఒక షేర్. March లేదా September evaluation periodలోని సగటు closing price ఆధారంగా ఎక్స్చేంజ్‌లు ప్రతి స్టాక్‌కి సంవత్సరానికి రెండుసార్లు ఈ వర్గీకరణను మార్చుతాయి. ఈ మార్పుపై Nasdaq vendor alert tiers, తేదీలను జాబితా చేస్తుంది. నాలుగు అంకెల ధర ఉన్న స్టాక్‌లో అనుమతించబడే అతి చిన్న tip పది షేర్లు.

Iceberg orders queue priority కోల్పోతాయా?

కోల్పోతాయి. చాలా వివరణలు దాటవేసే ముఖ్యమైన అంశం ఇదే. US equity booksలో resting ordersను ముందుగా ధర ఆధారంగా, ఆ తర్వాత సమయం ఆధారంగా క్రమబద్ధీకరిస్తారు. ఒకే ధర వద్ద ముందుగా చేరిన ఆర్డర్ ముందుగా ట్రేడ్ అవుతుంది.

Icebergలోని displayed slice పోస్ట్ అయినప్పుడు queueలో చేరుతుంది. ఆ slice పూర్తిగా నెరవేరిన తర్వాత engine reserve నుంచి దాన్ని replenishment చేస్తే, కొత్త displayed orderగా fresh timestampతో queueలో చేరుతుంది. అదే ధర వద్ద ఇప్పటికే ఉన్న అన్ని ఆర్డర్ల వెనుకకు అది వెళ్తుంది. Nasdaq rule ఈ వ్యత్యాసాన్ని స్పష్టంగా చెబుతుంది:

Reserve Order పోస్ట్ చేసినప్పుడు, displayed orderపై జరిగే execution కారణంగా దాని పరిమాణం normal unit of trading కంటే తక్కువైతే, కొత్త displayed order నమోదు చేయబడుతుంది మరియు దానికి కొత్త timestamp లభిస్తుంది. అదే సమయంలో non-displayed order పరిమాణం సమాన మొత్తంలో తగ్గుతుంది. దానికి కొత్త timestamp లభించదు.

ఇది Nasdaq Equity 4, Rule 4703(h)లోని నిబంధన. February 18, 2021న reserve order rule changeను ఆమోదించిన SEC order నుంచి దీనిని ఉటంకించారు. Reserve తన మొదటి timestampను కొనసాగిస్తుంది. Visible tip మాత్రం ప్రతి refreshలో కొత్త timestampను పొందుతుంది. 50,000 షేర్ల ఆర్డర్‌ను ఒకేసారి 500 షేర్లుగా చూపిస్తే అది వందసార్ల వరకు refresh కావచ్చు. ప్రతి refreshలో అదే ధర వద్ద ఇప్పటికే restingలో ఉన్న అన్ని displayed orders వెనుక నుంచి మళ్లీ ప్రారంభించాలి. దాచడానికి అయ్యే నిజమైన ఖర్చు ఇదే.

చాలా venuesలో మరో ఖర్చు కూడా ఉంటుంది. ఒకే ధర వద్ద displayed interestకు non-displayed interest కంటే ముందు priority ఉంటుంది. అందువల్ల reserve ముందుగా వచ్చినా, అక్కడి displayed orderకు అది వెనుకబడుతుంది.

Iceberg order, hidden order, dark pool మధ్య తేడా

• Iceberg order ఒక lit exchangeలో restingగా ఉంటుంది. దాని displayed slice public quoteలో కనిపిస్తుంది. ఆ slice national best bid or offerను నిర్ణయించవచ్చు. దాని వెనుక ఉన్న reserve quoteలో ఎప్పుడూ కనిపించదు.
• Fully hidden order ఏ భాగాన్నీ చూపించదు. అది అదే lit exchangeలో restingగా ఉండి, limit price వద్ద execute అవుతుంది. ట్రేడ్ అయిన తర్వాత మాత్రమే public dataలో కనిపిస్తుంది. సాధారణంగా అదే ధర వద్ద displayed orders కంటే దీనికి వెనుక priority ఉంటుంది.
• Dark pool పూర్తిగా వేరు venue. అందులో public quote ఉండదు. ట్రేడ్ జరిగిన తర్వాత trade reporting facility ద్వారా print tapeకు చేరుతుంది.
• Block trade మొత్తం పరిమాణాన్ని ఒకే negotiated printలో తరలిస్తుంది. ఇందులో గరిష్ఠ పరిమాణం, కనీస వ్యవధి ఉంటాయి. పరిమాణాన్ని క్రమంగా మార్కెట్‌లోకి పంపే విధానానికి ఇది వ్యతిరేకం.

ఈ విధానాలన్నీ పరిమాణాన్ని ముందుగానే బహిరంగంగా ప్రకటించకుండా తరలిస్తాయి. వాటి మధ్య తేడా order ఎక్కడ restingగా ఉందో, public quoteలో దాని ఎంత భాగం కనిపిస్తుందో అన్నదే. Quote చూపించని ధరల వద్ద కూడా hidden interest ఉండవచ్చు. అందువల్ల కనిపించే book అందుబాటులోని liquidityకి ఎప్పుడూ పాక్షిక చిత్రమే. దీన్ని locked and crossed marketsతో పాటు గుర్తుంచుకోవాలి.

Tapeలో ఎంత పరిమాణం చిన్న tradesగా నమోదవుతుంది?

Iceberg order footprintను చదవడానికి ముందు, tapeలో సాధారణంగా కనిపించే ట్రేడింగ్ నమూనా గురించి అవగాహన ఉండాలి. క్రింది panelలో ప్రతి నెల share volumeను అదే నెల trade countతో భాగించారు. ఈ కాలంలో 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కు చెందిన ఒక 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 printను పరిమాణం ఆధారంగా వర్గీకరించారు.

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 detection కష్టంగా ఉండటానికి ఇదే మొదటి కారణం.

Tapeపై iceberg orderను ఎలా గుర్తించాలి?

Consolidated tape ప్రతి executionకు price, size, time, venue వివరాలను చూపిస్తుంది. కానీ order IDs, display quantities, reserves చూపించదు. అది చూపించగలిగేది footprint మాత్రమే: ఒకే ధర వద్ద ఒకే పరిమాణం మళ్లీ మళ్లీ print కావడం, ఆ పరిమాణంలోని ఒక 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

అత్యధికంగా పునరావృతమైన జత 300 shares at $300.54. ఇది 09:34 నుంచి 09:58 ET వరకు 0.4 గంటల వ్యవధిలో 67 సార్లు print అయింది. ఈ పునరావృతాలు రోజంతా విస్తరించాయా, లేక ఒకే సమయంలో కేంద్రీకృతమయ్యాయా తెలుసుకోవడానికి ఆ జతను sessionంతా అరగంటల 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గా తిరిగి కనిపిస్తుంది. అది 09:30 ETకు ప్రారంభమై, 67 printsను కలిగి ఉంది. Sessionలో running countను 67 వద్ద ముగించింది. ఒకే ధర వద్ద ముప్పై నిమిషాల పునరావృతం ఒక burst మాత్రమే. రోజంతా కొనసాగిన activity కాదు. మొదట కనిపించినదానికంటే ఇంత చిన్న footprint బలహీనమైన ఆధారం. అంత చురుకైన స్టాక్‌లో, ఆ ధర వద్ద, ఆ పరిమాణంలోని displayed order సాధారణంగా కొన్ని secondsలోనే పూర్తవుతుంది. ఏదో ఒకటి దాన్ని మళ్లీ మళ్లీ ఉంచింది.

Iceberg detection ఎందుకు నమ్మదగినది కాదు?

ఏదో ఒకటి దాన్ని మళ్లీ ఉంచింది అనేది tape ఆధారంగా చెప్పగలిగే నిజాయితీగల పరిమితి. Reserve order అవసరం లేకుండానే ఇదే footprintకు సాధారణ వివరణలు ఉండవచ్చు:

• ఒక execution algorithm parent orderను సమాన child ordersగా విభజించి, broker సొంత server నుంచి వాటిని ఒక్కొక్కటిగా పంపడం.
• Round numbers ఒకే round quantity, ఒకే round priceను ఎంచుకునేలా చేయడం వల్ల సంబంధం లేని participants కూడా అదే పరిమాణం, అదే ధరను ఎంచుకోవడం.
• Market maker తాను కొనసాగించడానికి సిద్ధంగా ఉన్న ఒక level వద్ద అదే sizeను మళ్లీ మళ్లీ requote చేయడం.
• Print counts, order counts వేర్వేరుగా ఉండడం. ఒక resting orderను sweep నెరవేర్చినప్పుడు అది అనేక printsగా report కావచ్చు.

ఇంకో నిశ్శబ్ద పరిస్థితి కూడా ఉంది. ఎప్పుడూ ట్రేడ్ కాని iceberg ఎలాంటి footprintను వదలదు. Tape executionsను మాత్రమే నమోదు చేస్తుంది. Prints ఆధారంగా నిర్మించిన hidden liquidity కొలతలో ట్రేడ్ అయిన భాగం మాత్రమే కనిపిస్తుంది. వేచి ఉన్న భాగం ఎప్పుడూ కనిపించదు. కాబట్టి ఈ patternను ఒక hypothesisగా మాత్రమే చూడాలి. దాన్ని venue mix, quoteతో సరిపోల్చి పరిశీలించాలి. నిర్దిష్ట ఆర్డర్ గురించి వాస్తవంగా పరిగణించకూడదు.

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

Tradingలో iceberg order అంటే ఏమిటి?

ఇది రెండు పరిమాణాలు ఉన్న limit order. Public quoteలో కనిపించే చిన్న displayed size ఒకటి. ఆ displayed slice పూర్తయిన ప్రతిసారి ఎక్స్చేంజ్ ఆటోమేటిక్‌గా విడుదల చేసే పెద్ద hidden reserve మరొకటి. ఇది ఒకే venueలో, ఒకే ధర వద్ద, ఒకే ఆర్డర్‌గా ఉంటుంది.

Iceberg orders queueలో తమ స్థానాన్ని కోల్పోతాయా?

Displayed slice కోల్పోతుంది. ప్రతి replenishment కొత్త timestampతో కొత్త displayed orderగా పోస్ట్ అవుతుంది. అదే ధర వద్ద ఇప్పటికే restingలో ఉన్న అన్ని ఆర్డర్ల వెనుకకు అది వెళ్తుంది. Nasdaq rule ప్రకారం non-displayed reserve మాత్రం తన మొదటి timestampను కొనసాగిస్తుంది.

Level 2లో iceberg orders కనిపిస్తాయా?

కనిపించవు. Depth of book display displayed sliceను మాత్రమే చూపిస్తుంది. అది సాధారణ చిన్న limit orderలా కనిపిస్తుంది. Reserve ట్రేడ్ అయ్యే వరకు కనిపించదు. అది స్వతంత్ర lineగా ఎప్పుడూ కనిపించదు.

Iceberg order, dark pool order ఒకటేనా?

కాదు. Iceberg lit exchangeలో restingగా ఉండి, తనలోని కొంత భాగాన్ని public quoteలో చూపిస్తుంది. Dark pool order public quote లేని venueలో restingగా ఉంటుంది. అది print అయినప్పుడు మాత్రమే ట్రేడ్ public dataలో కనిపిస్తుంది.

Iceberg orders చట్టబద్ధమైనవేనా?

అవును. Reserve orders SECకు దాఖలు చేసిన exchange rulebooksలో documented order attributesగా ఉన్నాయి. ఇవి member firms, వారి customersకు అందుబాటులో ఉంటాయి. Order పరిమాణంలో కొంత భాగాన్ని దాచడం order typeలో వెల్లడించిన feature.

ఇక్కడి ప్రతి panelను రూపొందించిన SQL కూడా అందించబడుతుంది. అందువల్ల ప్రతి సంఖ్య ఎలా లెక్కించబడిందో మీరు చూడవచ్చు. మీకు నచ్చిన ticker, తేదీపై repeated print scan నిర్వహించాలంటే Strasmore terminalలో plain Englishలో అడగండి.