از Trading Bots کے لیے Circuit Breakers کیا ہیں؟
Circuit breakers خراب session کا نقصان بڑھنے سے پہلے trading bot روکتے ہیں۔ جانیں daily loss limit کتنی بار فعال ہوتی ہے اور volatility scaling position size کو کیسے بدلتی ہے۔
Trading bots کے لیے circuit breakers وہ قواعد ہیں جو مقررہ حد پوری ہونے کے بعد automated strategy کو orders بھیجنے سے روک دیتے ہیں۔ یہ strategy اور broker کے درمیان risk layer میں موجود ہوتے ہیں، اور ہر order پر لاگو ہوتے ہیں، خواہ strategy ان سے متفق ہو یا نہ ہو۔ Strategy یہ طے کرتی ہے کہ کیا trade کرنا ہے۔ Risk layer یہ طے کرتی ہے کہ trading بالکل ہو گی بھی یا نہیں۔
یہ تقسیم پورے design کی بنیاد ہے۔ جو strategy خود ہی اپنی نگرانی کرے، اس وقت کوئی independent check موجود نہیں ہوتا جب اس کے اپنے assumptions ناکام ہو رہے ہوں۔ اور یہی وہ وقت ہے جب check کی سب سے زیادہ ضرورت ہوتی ہے۔
ٹریڈنگ bot میں circuit breaker کیا کرتا ہے
ایک risk layer کے چار حصے ہوتے ہیں، اور ہر حصہ ایک مخصوص مگر عام ناکامی کو روکنے کے لیے موجود ہوتا ہے۔
- پوزیشن کے سائز، ہر symbol پر notional exposure، اور order rate پر hard caps۔ یہ کسی ایسے bug سے ہونے والے نقصان کی حد مقرر کرتے ہیں جو بصورتِ دیگر بے قابو ہو سکتا ہے۔
- Drawdown circuit breaker، جو session کے دوران اکاؤنٹ میں مقررہ حد تک کمی آنے پر، یا equity peak سے مقررہ حد تک نیچے جانے پر، نئے orders روک دیتا ہے۔
- Scaled order sizing، جو حالیہ volatility یا Kelly bet کے ایک حصے کی بنیاد پر مقرر کیا جاتا ہے، نہ کہ shares کی ایک مقررہ تعداد پر۔ اس طرح مارکیٹ کی range بدلنے کے باوجود ہر trade کا risk تقریباً مستحکم رہتا ہے۔
- ہر فیصلے کا append-only audit log، جس میں وہ orders بھی شامل ہوں جنہیں risk layer نے مسترد کیا۔ یہی واحد record ہے جو یہ فرق واضح کرتا ہے کہ “strategy غلط تھی” یا “check کبھی چلا ہی نہیں”۔
ذیل کی ہر چیز انہی چار حصوں میں سے ایک کی عملی شکل ہے۔
trading bot کے لیے روزانہ نقصان کی مناسب حد کیا ہے؟
روزانہ نقصان کی حد اس وقت نئے orders روک دیتی ہے جب سیشن کا نقصان مقررہ threshold سے بڑھ جائے۔ اس حد کا انتخاب ذوق کا نہیں بلکہ calibration کا معاملہ ہے: اگر اسے معمول کی market noise کے اندر رکھا جائے تو bot زیادہ تر ہفتوں میں halted رہے گا، اور اگر اسے بہت دور رکھا جائے تو یہ کبھی trigger نہیں ہوگا۔ نقطۂ آغاز یہ دیکھنا ہے کہ market خود کسی مخصوص شدت کا down day کتنی بار فراہم کرتی ہے۔
ہر عدد کے پیچھے موجود درست 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 yearایک فیصد یا اس سے زیادہ کمی والے سیشنز کی تعداد 15 رہی، 2019 میں، اور 45، 2020 میں، جبکہ ایک سال میں تقریباً 250 trading days ہوتے ہیں۔ تین فیصد یا اس سے زیادہ کمی والے دنوں کی تصویر مختلف ہے: 0، 2019 کے مقابلے میں 16، 2020 میں۔ 9 کی آخری row میں صرف 31 جولائی 2026 تک کے سیشنز شامل ہیں۔
یہ سلسلہ ہموار نہیں بلکہ غیر یکساں ہے، اور یہی غیر یکسانیت اس design کا بنیادی نکتہ ہے۔ مشکل دن clusters کی صورت میں آتے ہیں۔ اگر bot کسی cluster کے پہلے دن halt ہو جائے اور دوسرے دن دوبارہ کام شروع کر دے تو اس نے حقیقتاً halt نہیں کیا۔
دو thresholds مختلف کام انجام دیتے ہیں۔ روزانہ نقصان کی حد، جو عموماً account equity کے 2% کے برابر ہوتی ہے، سیشن ختم کر دیتی ہے۔ Equity کے high-water mark سے ناپی جانے والی trailing drawdown limit، جو عموماً تقریباً 10% ہوتی ہے، human review تک strategy کو روک دیتی ہے۔ پہلی حد routine کے لیے ہے، جبکہ دوسری نایاب صورتوں کے لیے رکھی جاتی ہے۔ صرف پہلی حد رکھنے والا bot ہر بار 2% نقصان کے ذریعے account کو مسلسل کم کر سکتا ہے، بغیر اس کے کہ کوئی حد کبھی trigger ہو۔
Volatility scaling پوزیشن کا سائز کیسے تبدیل کرتی ہے؟
Volatility targeting حالیہ realized volatility کے الٹ نسبت سے پوزیشن کا سائز طے کرتی ہے: جب روزانہ کی range دگنی ہو جائے تو پوزیشن تقریباً نصف رہ جاتی ہے، اور ہر trade میں dollar risk تقریباً مستقل رہتا ہے۔ یہاں realized volatility سے مراد daily returns کا annualized 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)Realized volatility کو 11.1% میں annualized طور پر 2024-01 پر اور 12% کو 2026-07 میں، 31 ماہ کے دوران ناپا گیا۔ دوسرے کالم میں ہر reading کو اس پوزیشن میں تبدیل کیا گیا ہے جو 12% volatility target رکھنے والی strategy اختیار کرے گی، اور اسے full line تک محدود رکھا گیا ہے: 100% کو 2024-01 کے مقابل، جبکہ 99.7% کو 2026-07 کے مقابل۔ Strategy وہی ہے، conviction وہی ہے، مگر share count بہت مختلف ہے۔
Kelly criterion اسی مسئلے کو دوسری سمت سے دیکھتا ہے۔ اس میں sizing صرف volatility پر نہیں بلکہ estimated edge اور variance پر مبنی ہوتی ہے۔ زیادہ تر systematic operators اس کا ایک حصہ استعمال کرتے ہیں، یعنی half Kelly یا quarter Kelly، کیونکہ دونوں inputs محدود sample سے حاصل کیے گئے estimates ہوتے ہیں۔ Kelly criterion کے مطابق پوزیشن کا سائز طے کرنا اسی حساب کو واضح کرتا ہے۔
stop کے بعد trading bot دوبارہ داخل کیوں ہوتا رہتا ہے؟
stop فعال ہوتا ہے۔ پوزیشن بند ہو جاتی ہے۔ نوے سیکنڈ بعد entry condition دوبارہ درست ہو جاتی ہے، bot دوبارہ داخل ہوتا ہے، وہی نقصان اٹھاتا ہے اور یہ سلسلہ دہرایا جاتا ہے۔ کوئی ایک component خراب نہیں ہوتا۔ strategy نے وہی کیا جس کے لیے اسے لکھا گیا تھا، stop نے بھی اپنا مقررہ کام کیا، لیکن account ہر round trip میں مسلسل نقصان اٹھاتا رہتا ہے۔
یہ frequency براہِ راست price path سے پیدا ہوتی ہے۔ یہ 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 بار رہی۔ ایک session میں 2026-07 پر 5 crossings ریکارڈ ہوئیں۔ جو بھی rule level کے ایک جانب entry کھولتا ہے اور دوسری جانب stop لگاتا ہے، اسے ایک ہی دن میں اتنی بار فعال ہونے کا موقع ملتا ہے۔
چار mechanisms اس مسئلے کو محدود کرتے ہیں۔
- ہر stop کے بعد cooldown، جسے منٹوں یا bars میں ناپا جاتا ہے۔ اس دوران اس symbol کے لیے کوئی نیا order risk layer سے منظور نہیں ہوتا۔
- ہر symbol کے لیے روزانہ trade count cap، جو ایک غیر محدود loop کو محدود تعداد میں بدل دیتا ہے۔
- ایک halt flag جو latch ہو جاتا ہے۔ روزانہ loss limit فعال ہونے کے بعد یہ flag اسی وقت تک فعال رہتا ہے جب تک کوئی شخص اسے clear نہ کرے۔
- اس flag کو process memory سے باہر persist کرنا۔ crashed bot کو restart کرنے والا supervisor اسے clean slate دے سکتا ہے، جبکہ clean slate ہی وہ چیز ہے جسے یہ flag روکنے کے لیے بنایا گیا ہے۔
آخری نکتہ ان لوگوں کے لیے مسئلہ پیدا کرتا ہے جنہوں نے باقی سب کچھ درست کیا ہو۔ Grid trading bots ڈیزائن کے لحاظ سے orders کی ladders لگاتے ہیں، اس لیے trade-count cap محض نمائشی نہیں بلکہ بنیادی حفاظتی mechanism بن جاتا ہے۔
جب کوئی bot پرانے price feed پر trade کرتا ہے تو کیا ہوتا ہے؟
جو quote update ہونا بند ہو چکا ہو، وہ پھر بھی ایک number دکھائی دیتا ہے۔ bot اسے پڑھتا ہے، اسی کے مطابق order کی قیمت طے کرتا ہے، اور وہ order ایسی market میں بھیج دیتا ہے جو اس دوران حرکت کر چکی ہوتی ہے۔ خرابی خاموشی سے ہوتی ہے: کوئی exception نہیں آتی، error log نہیں بنتا، اور fills صرف بعد میں غیر معمولی دکھائی دیتے ہیں۔
اس کی واضح پیمائش overnight gap سے کی جا سکتی ہے۔ اس صورت میں ایک معلوم price کئی گھنٹوں تک تبدیل نہیں ہوتی، جبکہ tradable price حرکت کرتی رہتی ہے۔
ہر عدد کے پیچھے موجود درست 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 کے لحاظ سے سب سے بڑا نام TSLA تھا، جس کا gap 4.41% رہا، جبکہ KO کے لیے یہ 1% تھا۔ عام راتیں کہیں زیادہ پُرسکون تھیں: median gaps بالترتیب 1.01% اور 0.24% رہے۔ risk layer tail events سے نمٹنے کے لیے بنائی جاتی ہے، اور مذکورہ مدت میں TSLA پر سب سے بڑا single gap 14.57% ریکارڈ ہوا۔ یہ وہ فاصلے ہیں جن پر کوئی bot کچھ دیر پہلے پڑھی گئی price کی بنیاد پر عمل کر سکتا ہے۔ رات بھر stocks میں gap کیوں آتا ہے میں اس عمل کی وضاحت کی گئی ہے۔
دفاعی اقدامات کم لاگت ہیں۔ ہر quote کے لیے maximum age مقرر کریں جس کی بنیاد پر risk layer price طے کرے گی؛ intraday strategy کے لیے عموماً یہ چند seconds ہوتی ہے۔ feed سے heartbeat کو data سے الگ وصول کریں۔ اس سے خاموش socket اور پُرسکون market میں فرق کیا جا سکتا ہے۔ Missing data کو hold کے بجائے halt سمجھیں، کیونکہ prices نہ ہونے کی صورت میں bot اپنے exits کا بھی جائزہ نہیں لے سکتا۔
رسک layer میں کون سی hard caps شامل ہونی چاہییں؟
- ہر symbol کے لیے maximum notional، account equity کے تناسب سے۔ 10% کی حد اس بات کو روکتی ہے کہ ایک خراب symbol پورے account کو متاثر کرے۔
- تمام open positions میں maximum gross notional۔ اسے equity کے 100% پر مقرر کرنے کا مطلب leverage نہ لینا ہے۔ یہ فیصلہ واضح طور پر کرنا چاہیے، نہ کہ broker کی default setting کے تحت خود بخود قبول کر لینا چاہیے۔
- فی منٹ اور فی دن maximum order rate۔ زیادہ تر retail strategies کے لیے ایک منٹ میں 10 orders کافی گنجائش فراہم کرتے ہیں، جبکہ runaway loop کو ایک منٹ کے اندر محدود بھی رکھتے ہیں۔
- symbol کے average daily volume کے تناسب سے maximum order size۔ 1% کی حد bot کو اس قیمت کو متاثر کرنے سے روکتی ہے جس پر وہ trade کرنے کی کوشش کر رہا ہے، اور average daily volume اس کا denominator ہے۔
ان میں سے ہر cap کا تعلق strategy کے بجائے رسک layer سے ہے، اور ہر cap کو backtest، paper اور live میں ایک ہی code path سے نافذ ہونا چاہیے۔ جو limit صرف live ماحول میں موجود ہو، وہ ایسی limit ہے جسے کسی نے test نہیں کیا۔
trading bot کے audit log میں کیا ہونا چاہیے؟
Append-only log ہر decision کے لیے ایک record لکھتا ہے اور اسے کبھی edit یا delete نہیں کرتا۔ ہر record میں timestamp، استعمال کیا گیا quote اور اس کی عمر، چلائے گئے ہر limit check کا verdict، بھیجا گیا order، اور broker کا جواب شامل ہوتا ہے۔ Rejected orders بھی filled orders کے برابر اہمیت کے ساتھ درج کیے جاتے ہیں۔
Reconstruction بنیادی مقصد ہے۔ کسی خراب trading session کے چھ ہفتے بعد سوال یہ نہیں ہوتا کہ P&L کیا تھا۔ سوال یہ ہوتا ہے کہ کون سا check پاس ہوا، اور کس input پر۔ Recorded input کے بغیر آپ کو bot کی state کو market کی state سے دوبارہ اخذ کرنا پڑتا ہے۔ یہ بالکل وہی غلطی ہے جو backtesting میں look-ahead bias میں ہوتی ہے: ایسا information استعمال کرنا جو decision کے وقت system کے پاس موجود نہیں تھا۔
riskguard project اس separation کی ایک open-source implementation ہے۔ اس میں limit checks strategy کے اندر بکھری ہوئی logic کے بجائے ایک ایسے component میں رہتے ہیں جسے strategy call کرتی ہے۔ یہ کئی ممکنہ designs میں سے صرف ایک ہے، اس لیے اسے فوراً اپنانے کے بجائے پہلے پڑھنا چاہیے۔ آپ جس بھی چیز پر depend کریں، default branch کے بجائے tagged release کو pin کریں۔ ایک ہی backtest کے دو runs کے درمیان branch بدل سکتی ہے، اور خاموشی سے تبدیل ہونے والی risk layer، risk layer نہ ہونے سے بھی بدتر ہے۔
پہلی deployment paper broker پر کیوں چلتی ہے
Broker adapter بطور default paper mode پر چلتا ہے، جبکہ live trading کے لیے جان بوجھ کر ایک واضح flag set کرنا ضروری ہے۔ اس سے ایک عام مگر سنگین غلطی رکتی ہے: copied config file یا ایسی environment variable جسے override نہ کیا گیا ہو، حقیقی orders حقیقی رقم سے بھیج سکتی ہے۔
Paper run وہ اہم record بھی تیار کرتا ہے جو risk layer سے متعلق قابلِ استعمال ثبوت فراہم کرتا ہے۔ یہ record live prices پر اسی risk layer کے فیصلے دکھاتا ہے، یعنی کون سی limits فعال ہوئیں اور کون سی نہیں۔ یہ risk layer کے بارے میں evidence ہے؛ یہ اس سوال سے الگ ہے کہ strategy منافع کماتی ہے یا نہیں۔ حقیقی رقم لگانے سے پہلے paper trading میں بتایا گیا ہے کہ paper record کیا ثابت کرتا ہے اور کیا نہیں، جبکہ multi-agent AI trading systems واضح کرتا ہے کہ جب کئی agents orders place کر سکتے ہوں تو halt authority ہر agent سے باہر کیوں ہونی چاہیے۔
Trading bot circuit breaker سے متعلق عمومی سوالات
Trading bot میں circuit breaker کیا ہوتا ہے؟
یہ risk layer میں شامل ایک rule ہوتا ہے۔ مقررہ حد پوری ہوتے ہی یہ bot کو نئے orders بھیجنے سے روک دیتا ہے۔ عموماً یہ حد روزانہ کے نقصان یا account کی equity کی بلند ترین سطح سے drawdown ہوتی ہے۔ یہ strategy سے آزاد ہو کر ہر order پر لاگو ہوتا ہے، اور تب تک فعال رہتا ہے جب تک اسے باقاعدہ clear نہ کیا جائے۔
مارکیٹ میں 2% کمی والا دن کتنی بار آتا ہے؟
SPY میں 5 sessions کے دوران 2% یا اس سے زیادہ کمی ریکارڈ ہوئی، جبکہ 2019 میں یہ تعداد 25 رہی، 2020 میں ہر سال تقریباً 250 trading days میں سے۔ پُرسکون سال اور دباؤ والے سال کے درمیان یہی فرق بتاتا ہے کہ loss limit کو محض اندازے کے بجائے تاریخی data کی بنیاد پر calibrate کرنا چاہیے۔
stop کے بعد bot کو دوبارہ داخل ہونے سے کیسے روکا جا سکتا ہے؟
ہر stop کے بعد cooldown window اور ہر symbol کے لیے روزانہ کی trade cap مقرر کرنے سے غیر محدود loop ایک محدود عمل میں تبدیل ہو جاتا ہے۔ halt flag کو latch بھی ہونا چاہیے اور process memory سے باہر persist بھی کرنا چاہیے، کیونکہ بصورتِ دیگر crashed bot کو restart کرنے والا supervisor اسے دوبارہ فعال، یعنی unhalted، state دے دے گا۔
bot کیسے جان سکتا ہے کہ price feed پرانا ہو چکا ہے؟
ہر quote کے خلاف order کی pricing سے پہلے اس کی عمر جانچ کر، اور data سے الگ feed کی heartbeat مانیٹر کر کے۔ Overnight gaps سے اندازہ ہوتا ہے کہ stale price کس قدر خطرہ چھپا سکتی ہے: January 2024 اور July 2026 کے درمیان 4.41% کو 95th-percentile overnight move TSLA تک پہنچا۔
کیا ایک چھوٹے trading bot کو واقعی audit log کی ضرورت ہوتی ہے؟
Fills کا log یہ ریکارڈ کرتا ہے کہ کیا ہوا۔ Decisions کا log یہ ریکارڈ کرتا ہے کہ bot کے خیال میں اسے کیا کرنے کی اجازت تھی۔ غلط strategy اور ایسے risk check میں فرق معلوم کرنے کا یہی واحد طریقہ ہے جو کبھی چلا ہی نہیں۔ Append-only log، جس میں rejections بھی شامل ہوں، کم از کم مفید version ہے۔
اوپر دی گئی ہر figure minute bars پر مبنی stored query سے حاصل کی گئی ہے، اور ہر panel اپنے پیچھے موجود SQL کھولتا ہے۔ یہی queries اپنی symbol list پر Strasmore terminal میں چلائیں۔