Trading Botsसाठी Circuit Breakers कसे काम करतात
Circuit breakers खराब sessionमधील नुकसान वाढण्याआधी bot थांबवतात. Daily loss limit कितीदा लागू होते आणि volatility scalingमुळे position sizeवर काय परिणाम होतो ते जाणून घ्या.
Trading botsसाठीचे circuit breakers म्हणजे निर्दिष्ट मर्यादा गाठल्यानंतर automated strategyला orders पाठवण्यापासून थांबवणारे नियम. हे strategy आणि broker यांच्या दरम्यानच्या risk layerमध्ये असतात. Strategyची संमती असो वा नसो, ते प्रत्येक orderवर लागू होतात. काय trade करायचे हे strategy ठरवते. प्रत्यक्ष trading होणार की नाही हे risk layer ठरवते.
ही विभागणीच संपूर्ण रचनेचा आधार आहे. स्वतःचे नियंत्रण स्वतः करणाऱ्या strategyकडे तिचीच गृहितके मोडण्याच्या क्षणी स्वतंत्र तपासणी नसते. आणि स्वतंत्र तपासणी सर्वाधिक आवश्यक असते ती याच क्षणी.
ट्रेडिंग botमध्ये circuit breaker काय करतो
जोखीम-नियंत्रण स्तराचे चार भाग असतात. प्रत्येक भाग एका विशिष्ट आणि टाळता येण्याजोग्या बिघाडाला रोखण्यासाठी असतो.
- Position size, प्रत्येक symbolवरील notional exposure आणि order rate यांवर कठोर मर्यादा असतात. अन्यथा अमर्याद होऊ शकणाऱ्या bugमुळे होणारे नुकसान त्या मर्यादा बांधून ठेवतात.
- Drawdown circuit breaker accountमध्ये त्या sessionदरम्यान निश्चित रकमेइतकी घट झाली किंवा equityच्या उच्चांकापासून निश्चित रकमेइतकी घट झाली की नवीन orders थांबवतो.
- Scaled order sizing अलीकडील volatilityवर किंवा fixed share countऐवजी Kelly betच्या एका अंशावर आधारित असते. त्यामुळे बाजाराची range बदलत असतानाही प्रत्येक tradeमधील जोखीम साधारण स्थिर राहते.
- Append-only audit logमध्ये risk layerने नाकारलेल्या ordersसह प्रत्येक निर्णयाची नोंद केली जाते. “Strategy चुकीची होती” आणि “ही तपासणी कधीच चालली नाही” यांमधील फरक दाखवणारा हा एकमेव पुरावा असतो.
खालील सर्व मजकूर या चारपैकी एका घटकाचे प्रत्यक्ष स्पष्टीकरण आहे.
ट्रेडिंग बॉटसाठी वाजवी दैनिक तोटा मर्यादा किती असावी?
दैनिक तोटा मर्यादा म्हणजे सत्रातील तोटा ठरावीक उंबरठा ओलांडल्यानंतर नवीन orders थांबवणे. योग्य आकडा निवडणे ही calibrationची बाब आहे, पसंतीची नाही: मर्यादा बाजारातील नेहमीच्या चढ-उतारांच्या पातळीत ठेवली तर बॉट बहुतेक आठवडे halted राहतो; ती खूप दूर ठेवली तर कधीच सक्रिय होत नाही. सुरुवात करण्यासाठी बाजार स्वतः ठरावीक आकाराचा घसरणीचा दिवस किती वेळा नोंदवतो, हे पाहावे.
प्रत्येक आकड्यामागील अचूक SQL
WITH daily AS (
SELECT toDate(toTimeZone(window_start, 'America/New_York')) AS d,
argMax(toFloat64(close), window_start) AS close_px
FROM global_markets.delayed_stocks_minute_aggs
WHERE ticker = 'SPY'
AND toDate(toTimeZone(window_start, 'America/New_York')) >= toDate('2017-12-01')
AND toDate(toTimeZone(window_start, 'America/New_York')) <= toDate('2026-07-31')
AND (toHour(toTimeZone(window_start, 'America/New_York')) * 60
+ toMinute(toTimeZone(window_start, 'America/New_York'))) BETWEEN 570 AND 959
GROUP BY d
),
with_prev AS (
SELECT d,
close_px,
any(close_px) OVER (ORDER BY d ASC ROWS BETWEEN 1 PRECEDING AND 1 PRECEDING) AS prev_close
FROM daily
)
SELECT toYear(d) AS year,
countIf(close_px / prev_close - 1 <= -0.01) AS down_1pct_days,
countIf(close_px / prev_close - 1 <= -0.02) AS down_2pct_days,
countIf(close_px / prev_close - 1 <= -0.03) AS down_3pct_days
FROM with_prev
WHERE prev_close > 0
AND d >= toDate('2018-01-01')
GROUP BY year
ORDER BY year1% किंवा त्याहून अधिक घसरणीची सत्रे 15 मध्ये 2019 आणि 45 मध्ये 2020 इतकी होती. वर्षातील साधारण 250 trading daysपैकी ही संख्या होती. 3% किंवा त्याहून अधिक घसरणीची संख्या वेगळी आहे: 0 विरुद्ध 16, अनुक्रमे 2019 आणि 2020 मध्ये. 9 मधील शेवटची ओळ केवळ July 31, 2026पर्यंतची सत्रे समाविष्ट करते.
ही रेषा स्थिर नसून गटागटाने बदलते. हाच या मर्यादेचा महत्त्वाचा आधार आहे. कठीण दिवस सलग किंवा समूहाने येतात. एखादा बॉट अशा समूहाच्या पहिल्या दिवशी थांबला आणि दुसऱ्या दिवशी पुन्हा सुरू झाला, तर तो प्रत्यक्षात थांबलेला नाही.
दोन मर्यादा वेगवेगळी कामे करतात. साधारणतः account equityच्या 2% इतकी दैनिक तोटा मर्यादा सत्र समाप्त करते. Equityच्या high-water markपासून मोजली जाणारी trailing drawdown मर्यादा साधारणतः 10% असते आणि ती मानवी पुनरावलोकन होईपर्यंत strategy थांबवते. पहिली मर्यादा नियमित वापरासाठी असते; दुसरी क्वचितच लागू व्हावी यासाठी असते. केवळ पहिली मर्यादा असलेला बॉट कोणतीही मर्यादा सक्रिय न करता accountला प्रत्येक वेळी 2%ने हळूहळू खाली आणू शकतो.
अस्थिरतेनुसार मोजमाप केल्याने पोझिशनचा आकार कसा बदलतो?
Volatility targetingमध्ये अलीकडील realized volatilityच्या व्यस्त प्रमाणात पोझिशनचा आकार ठरवला जातो. दैनंदिन range दुप्पट झाल्यास पोझिशन साधारणतः निम्मी केली जाते. त्यामुळे प्रत्येक व्यवहारातील डॉलर-जोखीम जवळपास स्थिर राहते. येथे realized volatility म्हणजे दैनंदिन returnsचा वार्षिकीकृत standard deviation होय. त्यात बहुतेकांना अपेक्षित असते त्यापेक्षा मोठे बदल होतात.
प्रत्येक आकड्यामागील अचूक SQL
WITH daily AS (
SELECT toDate(toTimeZone(window_start, 'America/New_York')) AS d,
argMax(toFloat64(close), window_start) AS close_px
FROM global_markets.delayed_stocks_minute_aggs
WHERE ticker = 'SPY'
AND toDate(toTimeZone(window_start, 'America/New_York')) >= toDate('2023-12-01')
AND toDate(toTimeZone(window_start, 'America/New_York')) <= toDate('2026-07-31')
AND (toHour(toTimeZone(window_start, 'America/New_York')) * 60
+ toMinute(toTimeZone(window_start, 'America/New_York'))) BETWEEN 570 AND 959
GROUP BY d
),
rets AS (
SELECT d,
close_px / any(close_px) OVER (ORDER BY d ASC ROWS BETWEEN 1 PRECEDING AND 1 PRECEDING) - 1 AS ret
FROM daily
)
SELECT formatDateTime(toStartOfMonth(d), '%Y-%m') AS month,
round(stddevSamp(ret) * sqrt(252) * 100, 1) AS realized_vol_pct,
round(least(100.0, 1200.0 / (stddevSamp(ret) * sqrt(252) * 100)), 1) AS vol_target_size_pct
FROM rets
WHERE d >= toDate('2024-01-01')
AND isFinite(ret)
GROUP BY toStartOfMonth(d)
HAVING count() >= 15
ORDER BY toStartOfMonth(d)11.1% मध्ये मोजलेली realized volatility 2024-01 मध्ये वार्षिकीकृत असून, 12% ही 2026-07 मध्ये, 31 महिन्यांच्या कालावधीत आहे. दुसरा स्तंभ प्रत्येक readingचे रूपांतर 12% volatility targetनुसार ठेवता येणाऱ्या पोझिशनमध्ये करतो. ही पोझिशन पूर्ण lineपर्यंत मर्यादित आहे: 100% 2024-01च्या तुलनेत 99.7% 2026-07. धोरण तेच आहे आणि convictionही तीच आहे; मात्र sharesची संख्या मोठ्या प्रमाणात वेगळी आहे.
Kelly criterion हीच समस्या दुसऱ्या बाजूने सोडवते. ती केवळ volatilityवर आधारित नसून अंदाजित edge आणि varianceच्या आधारे पोझिशनचा आकार ठरवते. दोन्ही inputs मर्यादित sampleवर आधारित अंदाज असल्यामुळे बहुतेक systematic operators Kelly criterionचा काही अंश वापरतात—अर्धा किंवा चतुर्थांश Kelly. Kelly criterionनुसार पोझिशनचा आकार ठरवणे या गणिताची रूपरेषा स्पष्ट करते.
ट्रेडिंग bot stop लागल्यानंतर पुन्हा प्रवेश का करतो?
Stop लागतो. Position बंद होते. नव्वद सेकंदांनी entry condition पुन्हा खरी ठरते. Bot पुन्हा प्रवेश करतो, तोच तोटा सहन करतो आणि हीच प्रक्रिया पुन्हा सुरू राहते. कोणताही एक घटक बिघडलेला नसतो. Strategy जशी लिहिली आहे तशीच काम करते. Stop जसा लिहिला आहे तसाच काम करतो. तरीही प्रत्येक round tripमधून खात्यातील भांडवल कमी होत राहते.
ही वारंवारिता थेट किंमतीच्या मार्गातून येते. या panelमध्ये प्रत्येक sessionमध्ये SPY आपल्या opening priceपेक्षा 0.1%हून अधिक वरून 0.1%हून अधिक खाली, किंवा उलट, किती वेळा गेला याची मोजणी केली आहे.
प्रत्येक आकड्यामागील अचूक SQL
WITH mins AS (
SELECT toDate(toTimeZone(window_start, 'America/New_York')) AS d,
window_start AS ts,
toFloat64(close) AS px
FROM global_markets.delayed_stocks_minute_aggs
WHERE ticker = 'SPY'
AND toDate(toTimeZone(window_start, 'America/New_York')) >= toDate('2025-08-01')
AND toDate(toTimeZone(window_start, 'America/New_York')) <= toDate('2026-07-31')
AND (toHour(toTimeZone(window_start, 'America/New_York')) * 60
+ toMinute(toTimeZone(window_start, 'America/New_York'))) BETWEEN 570 AND 959
),
opens AS (
SELECT d, argMin(px, ts) AS open_px
FROM mins
GROUP BY d
),
zoned AS (
SELECT m.d AS d,
m.ts AS ts,
multiIf(m.px >= o.open_px * 1.001, 1,
m.px <= o.open_px * 0.999, -1,
0) AS zone
FROM mins AS m
INNER JOIN opens AS o ON m.d = o.d
),
flips AS (
SELECT d,
zone,
any(zone) OVER (PARTITION BY d ORDER BY ts ASC ROWS BETWEEN 1 PRECEDING AND 1 PRECEDING) AS prev_zone
FROM zoned
WHERE zone != 0
),
per_day AS (
SELECT d, countIf(prev_zone != 0 AND zone != prev_zone) AS crossings
FROM flips
GROUP BY d
)
SELECT formatDateTime(toStartOfMonth(d), '%Y-%m') AS month,
round(avg(crossings), 1) AS avg_crossings_per_session,
max(crossings) AS max_crossings_in_a_session
FROM per_day
GROUP BY toStartOfMonth(d)
ORDER BY toStartOfMonth(d)2025-08 मध्ये SPYने तो band प्रत्येक sessionमध्ये सरासरी 0.7 वेळा पार केला. 2026-07 मध्ये ही संख्या 1.5 वेळा होती. 2026-07 मधील एका sessionमध्ये 5 crossings नोंदवले गेले. एखाद्या levelच्या एका बाजूला position उघडणारा आणि दुसऱ्या बाजूला stop ठेवणारा कोणताही नियम एका दिवसात तितक्या वेळा सक्रिय होऊ शकतो.
चार यंत्रणा ही पुनरावृत्ती मर्यादित करतात.
- प्रत्येक stopनंतर cooldown ठेवणे. तो minutes किंवा barsमध्ये मोजला जातो. या काळात त्या symbolसाठी कोणताही नवीन order risk layerमधून मंजूर होत नाही.
- प्रत्येक symbolसाठी daily trade count cap ठेवणे. यामुळे अमर्याद loop मर्यादित संख्येच्या प्रक्रियेत बदलतो.
- latch होणारा halt flag ठेवणे. Daily loss limit लागू झाल्यावर तो flag तसाच सक्रिय राहतो, जोपर्यंत एखादी व्यक्ती तो clear करत नाही.
- हा flag process memoryच्या बाहेर persist करणे. Crashed bot restart करणारा supervisor त्याला स्वच्छ सुरुवात देतो. पण हा flag नेमका अशी स्वच्छ सुरुवात रोखण्यासाठीच असतो.
इतर सर्व उपाय योग्यरीत्या केले असतानाही शेवटचा मुद्दा अनेकांच्या लक्षात येत नाही. Grid trading bots रचनेनुसार ordersच्या ladders ठेवतात. त्यामुळे trade-count cap हा केवळ दिखाऊ उपाय न राहता आवश्यक नियंत्रण ठरतो.
बॉट कालबाह्य किंमत-फीडवर व्यवहार करतो तेव्हा काय होते?
अपडेट होणे थांबलेला quote अजूनही एक संख्या दिसतो. बॉट तो वाचतो, त्यावरून ऑर्डरची किंमत ठरवतो आणि बाजार पुढे सरकलेला असताना ती ऑर्डर बाजारात पाठवतो. ही चूक शांतपणे घडते: काहीही exception निर्माण होत नाही, error log होत नाही आणि व्यवहार पूर्ण झाल्यानंतरच fills असामान्य दिसतात.
हे स्पष्टपणे मोजता येण्याजोगे स्वरूप म्हणजे overnight gap. यात ज्ञात किंमत अनेक तास न बदलता राहते, तर व्यवहारयोग्य किंमत बदलत असते.
प्रत्येक आकड्यामागील अचूक SQL
WITH daily AS (
SELECT ticker,
toDate(toTimeZone(window_start, 'America/New_York')) AS d,
argMin(toFloat64(open), window_start) AS open_px,
argMax(toFloat64(close), window_start) AS close_px
FROM global_markets.delayed_stocks_minute_aggs
WHERE ticker IN ('SPY', 'KO', 'MSFT', 'AAPL', 'NVDA', 'TSLA')
AND toDate(toTimeZone(window_start, 'America/New_York')) >= toDate('2024-01-01')
AND toDate(toTimeZone(window_start, 'America/New_York')) <= toDate('2026-07-31')
AND (toHour(toTimeZone(window_start, 'America/New_York')) * 60
+ toMinute(toTimeZone(window_start, 'America/New_York'))) BETWEEN 570 AND 959
GROUP BY ticker, d
),
gaps AS (
SELECT ticker,
d,
open_px,
any(close_px) OVER (PARTITION BY ticker ORDER BY d ASC ROWS BETWEEN 1 PRECEDING AND 1 PRECEDING) AS prev_close
FROM daily
)
SELECT ticker,
round(quantileDeterministic(0.5)(abs(open_px / prev_close - 1) * 100, cityHash64(ticker, d)), 2) AS median_gap_pct,
round(quantileDeterministic(0.95)(abs(open_px / prev_close - 1) * 100, cityHash64(ticker, d)), 2) AS p95_gap_pct,
round(max(abs(open_px / prev_close - 1) * 100), 2) AS max_gap_pct
FROM gaps
WHERE prev_close > 0
GROUP BY ticker
ORDER BY p95_gap_pct DESC95th-percentile gapनुसार सर्वाधिक रुंद gap असलेले नाव TSLA होते, ते 4.41% इतके; त्या तुलनेत KOसाठी ते 1% होते. नेहमीच्या रात्री मात्र परिस्थिती खूपच शांत होती: median gap अनुक्रमे 1.01% आणि 0.24% होते. जोखीम-स्तराची गरज या tail eventsमुळे निर्माण होते. मोजलेल्या कालावधीत TSLAवरील सर्वात मोठा एकल gap 14.57% इतका होता. काही वेळापूर्वी वाचलेल्या किंमतीवर काम करणाऱ्या बॉटला उपलब्ध असलेले हेच अंतर आहे. शेअर्समध्ये overnight gap का निर्माण होतो येथे यामागील कार्यपद्धती स्पष्ट केली आहे.
प्रतिबंधक उपाय स्वस्त आहेत. जोखीम-स्तर ज्या प्रत्येक quoteवर आधारित किंमत ठरवेल, त्यासाठी कमाल वय निश्चित करा. Intraday strategyसाठी हे साधारणतः काही seconds असते. Feedकडून dataव्यतिरिक्त heartbeat स्वतंत्रपणे घ्या. त्यामुळे शांत market आणि प्रतिसाद देणे थांबवलेले socket यांत फरक करता येतो. Data उपलब्ध नसल्यास त्याला hold न मानता halt माना, कारण किंमती नसताना बॉट exitsचेही मूल्यांकन करू शकत नाही.
जोखमीच्या स्तरात कोणत्या कठोर मर्यादा असाव्यात?
- प्रत्येक symbolसाठी account equityच्या तुलनेत कमाल notional. 10%ची मर्यादा ठेवल्यास एखाद्या चुकीच्या symbolमुळे संपूर्ण account धोक्यात येत नाही.
- सर्व open positionsमधील कमाल gross notional. ती equityच्या 100%वर ठेवल्यास leverage राहत नाही. हा निर्णय brokerच्या defaultवर अवलंबून राहण्याऐवजी स्पष्टपणे घेणे योग्य आहे.
- प्रति मिनिट आणि प्रति दिवस कमाल order rate. बहुतांश retail strategiesसाठी प्रति मिनिट दहा orders ही उदार मर्यादा आहे. तरीही ती एका मिनिटात होणाऱ्या अनियंत्रित loopला आळा घालते.
- symbolच्या average daily volumeच्या तुलनेत कमाल order size. 1%ची मर्यादा botला ज्या किंमतीवर trade करण्याचा प्रयत्न आहे ती किंमत स्वतः बदलण्यापासून रोखते. average daily volume हा त्यासाठीचा denominator आहे.
यापैकी प्रत्येक मर्यादा strategyऐवजी risk layerमध्ये असावी. तसेच प्रत्येक मर्यादा backtest, paper आणि live या तिन्ही स्थितींमध्ये समान code pathमधून लागू झाली पाहिजे. केवळ liveमध्ये असलेली मर्यादा अशी मर्यादा असते जिची चाचणी कोणी केलेली नसते.
ट्रेडिंग बॉटच्या ऑडिट लॉगमध्ये काय असणे आवश्यक आहे?
Append-only लॉग प्रत्येक निर्णयासाठी एक रेकॉर्ड लिहितो आणि तो कधीही संपादित किंवा हटवत नाही. प्रत्येक रेकॉर्डमध्ये timestamp, वापरलेला quote आणि त्याचे वय, चालवलेल्या प्रत्येक limit checkचा verdict, पाठवलेली order आणि brokerचे उत्तर असते. Rejected ordersची नोंद filled ordersइतक्याच महत्त्वाने केली जाते.
पुनर्रचना हा यामागील मुख्य उद्देश आहे. एखाद्या खराब सत्रानंतर सहा आठवड्यांनी प्रश्न P&L किती होता हा नसतो. कोणती check पास झाली आणि कोणत्या inputवर झाली, हा खरा प्रश्न असतो. नोंदवलेला input नसल्यास तुम्हाला botची स्थिती marketच्या स्थितीवरून पुन्हा निर्धारित करावी लागते. ही backtestingमधील look-ahead bias सारखीच चूक आहे: निर्णयाच्या क्षणी systemकडे उपलब्ध नसलेली माहिती वापरणे.
riskguard प्रकल्प या विभाजनाची एक open-source अंमलबजावणी आहे. यात limit checks strategyमध्ये विखुरलेल्या logicऐवजी strategy ज्या componentला call करते त्यात असतात. अनेक डिझाइनपैकी हा एक पर्याय आहे. तो पाहण्यासारखा आहे; मात्र पाहताक्षणी स्वीकारण्यासारखा नाही. तुम्ही कोणत्याही घटकावर अवलंबून असलात तरी default branchऐवजी tagged release निश्चित करा. त्याच backtestच्या दोन runsदरम्यान branch बदलू शकते. शांतपणे बदललेली risk layer नसण्यापेक्षा अधिक धोकादायक असते.
पहिली तैनाती paper brokerवर का चालते
Broker adapterचे default paperवर असते आणि live trading सुरू करण्यासाठी मुद्दाम explicit flag सेट करावा लागतो. यामुळे टाळली जाणारी चूक साधी असते: कॉपी केलेली config file किंवा override न केलेला environment variable खऱ्या पैशांतून खरे orders पाठवू शकतो.
Paper runमधून आणखी एक महत्त्वाचा artifact तयार होतो. तो म्हणजे live pricesवर त्याच risk layerकडून तयार केलेला decision log. त्यातून कोणत्या limits लागू झाल्या आणि कोणत्या झाल्या नाहीत, हे दिसते. हा risk layerच्या कार्यक्षमतेचा पुरावा असतो. Strategy नफा कमावते की नाही, हा त्यापेक्षा वेगळा प्रश्न आहे. प्रत्यक्ष पैशांपूर्वी paper trading paper record काय सिद्ध करतो आणि काय सिद्ध करू शकत नाही, हे स्पष्ट करते. तसेच multi-agent AI trading systemsमध्ये अनेक agents orders देऊ शकत असताना halt authority प्रत्येक agentच्या बाहेर का ठेवावी लागते, हे दाखवले आहे.
Trading bot circuit breaker FAQ
Trading botमध्ये circuit breaker म्हणजे काय?
Risk layerमधील असा नियम, जो ठरवलेली मर्यादा गाठल्यानंतर botला नवीन orders पाठवणे थांबवतो. ही मर्यादा बहुधा दैनिक तोटा किंवा खात्याच्या equityच्या सर्वोच्च पातळीपासूनची drawdown असते. हा नियम strategyपासून स्वतंत्रपणे प्रत्येक orderवर लागू होतो. तोपर्यंत तो सक्रिय राहतो, जोपर्यंत कोणतीतरी प्रक्रिया तो reset करत नाही.
बाजारात 2% घसरणीचा दिवस किती वेळा येतो?
SPYमध्ये 5 सत्रांमध्ये 2% किंवा त्याहून अधिक घसरण झाली 2019 मध्ये. 2020 मध्ये अशी 25 सत्रे होती. प्रत्येक वर्षी साधारण 250 trading days असतात. शांत वर्ष आणि तणावपूर्ण वर्षातील हा फरक loss limit ठरवताना अंतःप्रेरणेऐवजी ऐतिहासिक आकडे वापरण्याचे कारण स्पष्ट करतो.
Stop लागल्यानंतर botला पुन्हा entry घेण्यापासून कसे रोखता?
प्रत्येक stopनंतर cooldown window आणि प्रत्येक symbolसाठी दैनिक trade cap वापरल्यास अमर्याद loop मर्यादित होतो. Halt flagने latch होऊन process memoryच्या बाहेरही टिकून राहिले पाहिजे. अन्यथा supervisorने crash झालेला bot पुन्हा सुरू केल्यावर त्याला halt नसलेली नवी state मिळू शकते.
Price feed stale झाल्याचे botला कसे कळते?
Orderची किंमत ठरवण्यापूर्वी प्रत्येक quote किती जुना आहे हे तपासून. Feedचा heartbeat dataपासून स्वतंत्रपणे पाहूनही हे करता येते. Overnight gapsमधून stale price काय लपवू शकतो याची व्याप्ती दिसते: January 2024 ते July 2026 या कालावधीत TSLA रोजी 95th-percentile overnight move 4.41%पर्यंत पोहोचला.
लहान trading botला खरोखर audit logची गरज असते का?
Fillsचा log काय घडले ते नोंदवतो. Decisionsचा log botला काय करण्याची परवानगी आहे असे वाटत होते ते नोंदवतो. चुकीची strategy आणि प्रत्यक्षात न चाललेली risk check यांमध्ये फरक ओळखण्याचा हा एकमेव मार्ग आहे. Append-only log, ज्यात rejectionsचाही समावेश असेल, ही किमान उपयुक्त आवृत्ती आहे.
वरील प्रत्येक आकडा minute barsवरील stored queryमधून घेतला आहे. प्रत्येक panelमधून त्यामागील SQL उघडता येते. Strasmore terminalवर त्याच queriesना तुमच्या स्वतःच्या symbol listवर लागू करा.