ऑर्डर बदलल्यास रांगेतील प्राधान्यक्रम गमावतो का?
Limit orderची किंमत किंवा दर्शविलेली मात्रा वाढवल्यास queue priority जाते. Fill probabilityवरील परिणाम आणि botसाठी break-even re-price distance समजून घ्या.
ऑर्डरमध्ये बदल करणे आणि रांगेतील प्राधान्य टिकवणे हे परस्परविरोधी असते. US equity books आणि बहुतांश futures venuesवर resting limit orderची किंमत बदलल्यास त्या नव्या किमतीवर ऑर्डर रांगेच्या शेवटी जाते. दर्शविलेला आकार वाढवल्यासही असेच होते. आकार कमी केल्यास रांगेतील स्थान कायम राहते. ऑर्डर cancel करून fresh order पाठवल्यास ती नवीन timestampसह आलेली नवीन ऑर्डर मानली जाते, तुमच्या प्लॅटफॉर्मवरील बटणाचे नाव काहीही असो.
ऑर्डरमध्ये बदल केल्याने रांगेतील प्राधान्यक्रम गमावला जातो का?
स्वतःहून व्यवहार करणारा ट्रेडर ज्या जवळपास सर्व trading venuesवर व्यवहार करतो, त्यांना चार नियम लागू होतात.
- किंमत बदलल्यास प्राधान्यक्रम गमावतो. ऑर्डर नव्या किमतीवर नव्याने आलेली मानली जाते आणि तेथे आधीपासून असलेल्या सर्व ऑर्डर्सच्या मागे जाते.
- दर्शविलेली मात्रा वाढवल्यास प्राधान्यक्रम गमावतो. काही venues केवळ वाढवलेली मात्रा पुन्हा रांगेत लावतात आणि मूळ मात्रा तिच्या जागी ठेवतात; तर काही संपूर्ण ऑर्डरची वेळ नव्याने नोंदवतात. कोणत्याही पद्धतीत अतिरिक्त शेअर्सना जुनी जागा मिळत नाही.
- दर्शविलेली मात्रा कमी केल्यास प्राधान्यक्रम कायम राहतो. Venue याकडे अंशतः केलेला cancel म्हणून पाहते. त्यामुळे मात्रेचा काही भाग काढून घेतल्याबद्दल रांगेतील स्थान गमवावे लागत नाही.
- Cancel करून ऑर्डर पुन्हा पाठवल्यास प्रत्येक वेळी प्राधान्यक्रम गमावतो. त्यादरम्यान काही काळ तुमची कोणतीही सक्रिय ऑर्डर बाजारात नसते.
या असममिततेमागे तर्क आहे. इतर सर्वजण प्रतीक्षा करत असताना एखाद्या किमतीवर थांबून राहिल्याबद्दल order book तुम्हाला time priority देते. मात्रा वाढवणे किंवा किंमत बदलणे म्हणजे नवा धोका स्वीकारणे; आणि नवा धोका रांगेच्या शेवटी सुरू होतो. मात्रा कमी करणे म्हणजे धोका कमी करणे; त्यासाठी कोणताही दंड आकारला जात नाही. Pro rata bookमध्ये गणित बदलते, कारण वाटप तुम्ही दर्शविलेल्या मात्रेनुसार होते, तुम्ही ऑर्डर कधी दाखल केली त्यानुसार नाही. Price time priority विरुद्ध pro rata या दोन्ही पद्धतींचे स्पष्टीकरण देते.
प्रत्यक्ष बदलणे की रद्द करून नवीन ऑर्डर देणे?
ट्रेडिंग venueवर या दोन वेगवेगळ्या सूचना असतात. Amendmentला तुमचे प्लॅटफॉर्म modify किंवा replace म्हणू शकते. यात विद्यमान ऑर्डर आणि करायचा बदल नमूद करणारा एकच संदेश पाठवला जातो. ही प्रक्रिया atomic असते: बदल लागू होतो किंवा ऑर्डर कोणताही बदल न होता तशीच राहते. Cancel केल्यानंतर नवीन ऑर्डर देणे म्हणजे त्यांच्यामध्ये अंतर असलेल्या दोन स्वतंत्र घटना. त्या अंतरात तुमची कोणतीही ऑर्डर बाजारात नोंदलेली नसते. त्या काळात बाजार तुमच्या किंमतीवर व्यवहार करून गेला, तर त्या व्यवहारासाठी तुम्ही ऑर्डरबुकमध्ये उपस्थित नव्हता.
काही venues amendmentची अंमलबजावणी अंतर्गत पातळीवर cancel आणि नवीन ऑर्डर अशा पद्धतीने करतात. काही brokers venue खरोखरच विद्यमान ऑर्डरमध्ये बदलाची सुविधा देत असतानाही, बाहेर पाठवताना amendmentचे रूपांतर cancel आणि replaceमध्ये करतात. परिणाम एकच असतो: तुमचा priority क्रमांक गमावला जातो. Amendment नाकारली गेल्यास मूळ ऑर्डर बाजारात कायम राहते. मात्र cancel यशस्वी झाल्यानंतर नवीन ऑर्डर नाकारली गेली, तर तुमची कोणतीही ऑर्डर कार्यरत राहत नाही. Priority कायम ठेवणाऱ्या amendmentलाही सहसा नवीन order identifier मिळतो. त्यामुळे तुमच्या नोंदींमध्ये नवीन ऑर्डर दिसते, पण order bookमध्ये अजूनही तीच जुनी ऑर्डर मोजली जाते.
दुरुस्तीची किंमत
Queue positionची किंमत tapeवर प्रत्यक्ष उपलब्ध असलेल्या व्यवहारक्षमतेइतकीच असते. तुमच्या पुढील शेअर्सचे व्यवहार आधी होणे आवश्यक असते. तसेच, एका सत्रात ते ज्या वेगाने trade होतात तो वेग मोठ्या प्रमाणात बदलतो.
प्रत्येक आकड्यामागील अचूक SQL
SELECT
formatDateTime(toStartOfFifteenMinutes(et), '%H:%i') AS et_time,
round(toFloat64(avg(volume)) / 1000, 1) AS avg_k_shares_per_min,
round(quantileDeterministic(0.5)(toFloat64(volume),
toUInt64(toUnixTimestamp(et))) / 1000, 1) AS median_k_shares_per_min
FROM
(
SELECT
toTimeZone(window_start, 'America/New_York') AS et,
volume
FROM global_markets.delayed_stocks_minute_aggs
WHERE ticker = 'AAPL'
AND window_start >= '2026-06-01'
AND window_start < '2026-07-01'
AND (toHour(toTimeZone(window_start, 'America/New_York')) * 60
+ toMinute(toTimeZone(window_start, 'America/New_York'))) >= 570
AND (toHour(toTimeZone(window_start, 'America/New_York')) * 60
+ toMinute(toTimeZone(window_start, 'America/New_York'))) < 960
)
GROUP BY et_time
ORDER BY et_timeJune 2026मध्ये 09:30 ET पासून सुरू होणाऱ्या पंधरा-मिनिटांच्या कालखंडात दर मिनिटाला AAPLच्या व्यवहार झालेल्या शेअर्सची median संख्या 182.8 हजार होती. 12:00 पासून सुरू होणाऱ्या कालखंडात ती 62 हजार होती. Order तोच आणि किंमतही तीच. मात्र, त्यापुढील प्रतीक्षा सत्राच्या सुरुवातीला आणि दिवसाच्या मध्यभागी पूर्णपणे वेगळी असते.
सुधारणेपूर्वी आणि नंतर ऑर्डर पूर्ण होण्याची संभाव्यता
सुधारणांची किंमत त्यांच्या संभाव्यतेनुसार ठरते. खालील पॅनेलमध्ये नियमित सत्रातील एका महिन्याच्या मिनिट-निहाय डेटावरून, किमान दिलेल्या संख्येइतके शेअर्स किती वेळा व्यवहारात आले याची गणना केली आहे. तुमच्यापुढे त्या आकाराची रांग असल्यास ती एका मिनिटाच्या आत पूर्ण होण्याची शक्यता म्हणून हे वाचा.
प्रत्येक आकड्यामागील अचूक SQL
WITH minute_volume AS
(
SELECT
ticker,
toStartOfMinute(toTimeZone(window_start, 'America/New_York')) AS et_minute,
sum(volume) AS shares
FROM global_markets.delayed_stocks_minute_aggs
WHERE ticker IN ('AAPL', 'KO')
AND window_start >= '2026-06-01'
AND window_start < '2026-07-01'
AND (toHour(toTimeZone(window_start, 'America/New_York')) * 60
+ toMinute(toTimeZone(window_start, 'America/New_York'))) >= 570
AND (toHour(toTimeZone(window_start, 'America/New_York')) * 60
+ toMinute(toTimeZone(window_start, 'America/New_York'))) < 960
GROUP BY ticker, et_minute
)
SELECT
q.ahead AS shares_ahead,
round(100 * countIf(mv.ticker = 'AAPL' AND mv.shares >= q.ahead) / countIf(mv.ticker = 'AAPL'), 1) AS aapl_pct_of_minutes,
round(100 * countIf(mv.ticker = 'KO' AND mv.shares >= q.ahead) / countIf(mv.ticker = 'KO'), 1) AS ko_pct_of_minutes
FROM minute_volume AS mv
CROSS JOIN
(
SELECT arrayJoin([500, 1000, 2000, 4000, 8000, 16000, 32000, 64000, 128000]) AS ahead
) AS q
GROUP BY q.ahead
ORDER BY q.aheadतुमच्यापुढे 500 शेअर्स असताना, AAPLच्या 100 टक्के मिनिटांमध्ये पुरेसा volume होता; KOसाठी हे प्रमाण 100 टक्के होते. 8000 शेअर्सच्या पातळीवर AAPLचे प्रमाण 100 टक्के आहे, तर 128000 शेअर्सपर्यंत ते 22.2 टक्क्यांवर येते. हा वक्र केवळ एका दिशेने उतार घेतो. Priority गमावणे म्हणजे या वक्रावर उजवीकडे सरकणे एवढेच.
या रेषेकडे आशावादी कमाल मर्यादा म्हणून पाहा. एका मिनिटातील volume अनेक किंमतपातळ्यांवर आणि बाजाराच्या दोन्ही बाजूंवर व्यवहारांत विभागलेला असतो. त्यातील केवळ काही भाग तुमच्या किंमतपातळीवर येतो. त्यामुळे प्रत्यक्षातील एक रांग यापेक्षा हळू पूर्ण होते. कोणतेही prints नसलेली मिनिटे मोजलेली नाहीत. तुमची रांगेतील स्थिती अंदाजित करणे यामध्ये market depth आणि cancel rates समाविष्ट करून अधिक अचूक चित्र देते.
ब्रेक-इव्हन re-price अंतर
आता amendmentची किंमत ठरवूया. समजा, खरेदीचा एक hypothetical order आहे. त्याच्या पुढे 8,000 शेअर्स आहेत आणि पुढील मिनिटात तो execute होण्याची शक्यता 60 टक्के आहे. Bid एक centने सुधारल्यास order कोणाच्याही पुढे नवीन सर्वोत्तम किमतीवर येतो. तेथे executionची शक्यता 99 टक्के आहे, असे धरूया. ही सुधारणा प्रत्येक fillमागे प्रति शेअर one cent खर्चिक ठरते.
प्रति शेअर fillचे मूल्य दर्शविण्यासाठी V लिहूया. यात तुमचा edge आणि कोणताही rebate समाविष्ट आहे. Re-price अंतरासाठी t लिहूया. सुधारलेल्या शक्यतेचा कमी payoff आणि जुन्या शक्यतेचा पूर्ण payoff समान झाल्यावर amendment break even ठरते. हे समीकरण पुढील एका ओळीत मांडता येते:
t = V x (1 - p0 / p1)
प्रति शेअर fillचे मूल्य 3 cents आणि executionची शक्यता 60 टक्क्यांवरून 99 टक्क्यांपर्यंत वाढत असल्यास break-even अंतर सुमारे 1.2 cents येते. One-centची सुधारणा स्वतःचा खर्च भरून काढते. Two-centचा पाठलाग मात्र फायदेशीर ठरत नाही.
ज्याचा एकमेव edge maker rebate आहे अशा botसाठीही हेच समीकरण वापरा. 2026च्या मध्यापर्यंत प्रकाशित fee schedulesनुसार मोठ्या US equity exchangesवरील उच्च-स्तरीय maker rebates प्रति शेअर सुमारे 0.20 ते 0.30 cents आहेत. त्यामुळे ते quarter of a cent, म्हणजे पाव cent, असे धरूया. या सूत्रानुसार break-even अंतर सुमारे 0.1 cents येते. मात्र कोणतेही US venue स्वीकारणारा सर्वात लहान price change पूर्ण one cent असतो—म्हणजे आवश्यक अंतरापेक्षा सुमारे दहापट जास्त. Rebate सुरक्षित ठेवण्यासाठी re-price करणारा bot पाव centच्या मागे जाण्यासाठी पूर्ण tick खर्च करतो.
Rebate केवळ fillsवर दिला जातो; हेतूवर कधीच नाही. उत्तम queue position असलेला order executeच झाला नाही, तर त्यातून काहीही मिळत नाही. तुम्ही कधी collect न केलेला rebate ही बचत नाही. Maker taker fees आणि rebates या fee schedulesमधून payment कसा होतो, हे स्पष्ट करते.
सुधारणेसाठी वाव नसताना
Bid आणि offer यांच्यात फरक असेल, तेव्हाच किंमत सुधारण्याचा पर्याय उपलब्ध असतो. सर्वात मोठ्या कंपन्यांच्या शेअर्समध्ये बहुतेक वेळा असा फरक नसतो.
प्रत्येक आकड्यामागील अचूक SQL
SELECT
ticker AS symbol,
round(avg(toFloat64(ask_price) - toFloat64(bid_price)) * 100, 2) AS avg_spread_cents,
round(100 * countIf(toFloat64(ask_price) - toFloat64(bid_price) <= 0.0105) / count(), 1) AS one_tick_wide_pct
FROM global_markets.cache_stocks_quotes
WHERE ticker IN ('AAPL', 'KO', 'SPY', 'NVDA', 'COST', 'NFLX')
AND sip_timestamp >= '2026-06-10 13:30:00'
AND sip_timestamp < '2026-06-10 20:00:00'
AND bid_price > 0
AND ask_price > bid_price
AND toFloat64(ask_price) - toFloat64(bid_price) < 5
GROUP BY ticker
ORDER BY one_tick_wide_pct DESCNFLX ने 10 June 2026 रोजी आपल्या quote updatesपैकी 81.4 टक्के updatesमध्ये one cent spread दाखवला. हा spread सरासरी 1.3 cents इतका होता. पॅनेलच्या दुसऱ्या टोकाला COST चा सरासरी spread 77.53 cents होता. One-tick marketमध्ये bid आणि offer यांच्या मध्ये जाण्यासाठी कोणतीही किंमत उपलब्ध नसते. Queueमध्ये पुढे जाण्याचा एकमेव मार्ग म्हणजे spread cross करणे. त्यामुळे तुम्ही taker बनता: rebate मिळवण्याऐवजी taker fee भरता आणि spreadमधील केवळ एका tickऐवजी संपूर्ण spread सोडता.
री-प्राइसिंग बॉटसमोरील निवड किती वेळा येते
बाजाराचा मागोवा घेणारा बॉट हा व्यवहार एकदाच करत नाही. त्याच्या ऑर्डरपासून बुकमधील सर्वोच्च पातळी दूर जाते तेव्हा तो प्रत्येक वेळी हा व्यवहार करतो.
प्रत्येक आकड्यामागील अचूक SQL
SELECT
formatDateTime(toStartOfFifteenMinutes(et), '%H:%i') AS et_time,
uniqExactIf(bid_price, ticker = 'AAPL') AS aapl_distinct_bids,
uniqExactIf(bid_price, ticker = 'KO') AS ko_distinct_bids
FROM
(
SELECT
toTimeZone(sip_timestamp, 'America/New_York') AS et,
ticker,
bid_price
FROM global_markets.cache_stocks_quotes
WHERE ticker IN ('AAPL', 'KO')
AND sip_timestamp >= '2026-06-10 13:30:00'
AND sip_timestamp < '2026-06-10 20:00:00'
AND bid_price > 0
)
GROUP BY et_time
ORDER BY et_time10 June 2026 रोजी 09:30 ET पासून सुरू झालेल्या पंधरा मिनिटांच्या कालावधीत AAPLमधील सर्वोत्तम bidने 359 वेगवेगळ्या किमतींना स्पर्श केला. 15:45 ET पासून सुरू झालेल्या पंधरा मिनिटांच्या कालावधीत त्याने 152 वेगवेगळ्या किमतींना स्पर्श केला. त्या सुरुवातीच्या कालखंडात KOच्या सर्वोत्तम bidने 78 किमतींना स्पर्श केला. यातील प्रत्येक बदल हा re-pricing bot पाठवू शकणारी amendment असतो आणि प्रत्येक amendmentमुळे त्याची प्रतीक्षा पुन्हा सुरू होते. Grid trading bots या निवडीची दुसरी बाजू स्वीकारतात. ते ठरावीक किमतींवर ladder ठेवतात. त्यामुळे किमती जुन्या ठरतात, पण priority कायम राहते.
Icebergs आणि self trade prevention
दुय्यम परिणामांपैकी दोन गोष्टी अनेकांना अडचणीत आणतात.
Reserve ordersना सामान्यतः iceberg orders म्हणतात. ते ऑर्डरचा एक भाग दाखवतात आणि उर्वरित भाग लपवून ठेवतात. बहुतेक order booksमध्ये displayed sliceचा प्रत्येक refresh त्या किमतीवरील रांगेच्या शेवटी जातो. त्यामुळे मोठा iceberg हा लहान ऑर्डर्सच्या मालिकेसारखा काम करतो. या ऑर्डर्स पूर्णपणे displayed sizeला आपले स्थान वारंवार सोडतात. Display sizeमध्ये बदल केल्यास हेच चक्र पुन्हा सुरू होते.
Self trade prevention हा दुसरा परिणाम आहे. एका participantची ऑर्डर त्याच participantच्या resting orderविरुद्ध execute होऊ नये, याची venues खात्री करतात. सामान्यतः दोन ऑर्डर्सपैकी एक cancel केली जाते; काही venuesमध्ये दोन्ही cancel केल्या जातात. अरुंद order bookमध्ये किंमतवारंवार बदलणारा bot विरुद्ध बाजूचा स्वतःचा quote काढून टाकू शकतो. त्यामुळे एका amendmentमुळे रांगेतील दोन स्थाने गमावली जातात. Amendmentsना साधारणतः मूळ time in force कायम राहतो. मात्र cancel and replace केल्यास तो पुन्हा मोजला जातो. या तपशीलाचे वर्णन order time in forceमध्ये केले आहे.
वारंवार विचारले जाणारे प्रश्न
Limit orderची किंमत बदलल्यास queueमधील माझे स्थान गमावले जाते का?
होय. US equity books आणि बहुतांश futures venuesवर orderची नवीन किंमत लागू झाल्यावर तो नवीन order मानला जातो. त्या किंमतीवर आधीपासून resting असलेल्या प्रत्येक shareच्या मागे त्याचा क्रम लागतो. त्याच किंमतीवर केवळ आकार कमी केल्यास priority कायम राहते.
Cancel and replace आणि orderमध्ये बदल करणे एकच आहे का?
Venueनुसार दोन्ही वेगळे असतात. Amendment हा एकच message असतो. केवळ आकार कमी केला असल्यास priority कायम राहू शकते. Cancel and replaceमध्ये दोन events असतात. या दोन्हींच्या दरम्यान तुमचा कोणताही order resting नसतो. Replacement नेहमी queueच्या शेवटी जातो.
Orderचा आकार कमी केल्यास queue priority कायम राहते का?
होय, त्याच किंमतीवर असल्यास. Venues आकारातील घट ही partial cancellation मानतात. त्यामुळे उरलेल्या sharesचा मूळ timestamp कायम राहतो. आकार वाढवल्यास असे होत नाही.
Queue positionचे प्रत्यक्ष मूल्य किती असते?
त्यामुळे मिळणाऱ्या fill probabilityचे मूल्य, आणि तुम्हाला मिळालेला fill किती मोलाचा आहे यांचा गुणाकार. या दोन्ही घटकांचे मोजमाप करता येते. वरील panelsमध्ये दर मिनिटाला किती volume prints होतात हे दाखवले आहे. तुमचा स्वतःचा edge आणि कोणतीही rebate मिळून fillचे मूल्य ठरते.
येथील प्रत्येक panel तयार करणारा SQL query सोबत दाखवतो. Ticker किंवा date range बदला आणि Strasmore terminalवरील कोणत्याही नावासाठी हाच प्रश्न विचारा.