ট্রেডিং বটের জন্য সার্কিট ব্রেকার
সার্কিট ব্রেকার খারাপ সেশনের ক্ষতি বাড়ার আগে ট্রেডিং বট থামায়। দৈনিক ক্ষতির সীমা কত ঘনঘন সক্রিয় হয় এবং volatility scaling position size-এ কী প্রভাব ফেলে, তা জানুন।
Trading bot-এর circuit breaker হলো এমন নিয়ম, যা নির্ধারিত সীমা ছুঁয়ে গেলে automated strategy-কে order পাঠানো বন্ধ করে দেয়। এগুলো strategy এবং broker-এর মাঝখানে risk layer হিসেবে কাজ করে। Strategy এতে সম্মত হোক বা না হোক, এই নিয়ম প্রতিটি order-এর ওপর প্রয়োগ হয়। কী trade করা হবে, তা strategy নির্ধারণ করে। আদৌ trading হবে কি না, তা risk layer নির্ধারণ করে।
এই বিভাজনই পুরো নকশার মূল বিষয়। যে strategy নিজেকেই নিয়ন্ত্রণ করে, তার নিজস্ব অনুমান ভেঙে পড়ার মুহূর্তে কোনো স্বাধীন যাচাই থাকে না। অথচ ঠিক সেই মুহূর্তেই যাচাই সবচেয়ে বেশি প্রয়োজন।
ট্রেডিং বটে একটি circuit breaker কী করে
একটি risk layer-এর 4টি অংশ থাকে। প্রতিটি অংশ নির্দিষ্ট একটি সাধারণ ত্রুটি ঠেকানোর জন্য কাজ করে।
- Hard caps থাকে position size, প্রতিটি symbol-এর notional exposure এবং order rate-এর ওপর। এগুলো এমন কোনো বাগের কারণে সম্ভাব্য ক্ষতির সীমা নির্ধারণ করে, যা না হলে সীমাহীন হতে পারত।
- একটি drawdown circuit breaker থাকে। সেশনে অ্যাকাউন্টের ক্ষতি নির্ধারিত পরিমাণে পৌঁছালে, অথবা equity peak থেকে নির্ধারিত পরিমাণ কমে গেলে এটি নতুন order স্থগিত করে।
- Scaled order sizing সাম্প্রতিক volatility অথবা Kelly bet-এর একটি অংশের ভিত্তিতে নির্ধারণ করা হয়। Fixed share count-এর পরিবর্তে এটি ব্যবহার করা হলে বাজারের range পরিবর্তিত হলেও প্রতিটি trade-এ ঝুঁকি মোটামুটি স্থির থাকে।
- একটি append-only audit log-এ প্রতিটি সিদ্ধান্ত নথিভুক্ত করা হয়। risk layer যেসব order প্রত্যাখ্যান করেছে, সেগুলোও এতে থাকে। "Strategy-টি ভুল ছিল" এবং "Check কখনও চালু হয়নি"—এই দুই অবস্থার পার্থক্য বোঝানোর একমাত্র নথি এটি।
নিচের প্রতিটি বিষয় এই 4টি অংশের একটির বাস্তব প্রয়োগ।
একটি trading bot-এর জন্য যুক্তিসংগত দৈনিক ক্ষতির সীমা কত?
দৈনিক ক্ষতির সীমা নির্ধারিত threshold অতিক্রম করলে নতুন order বন্ধ করে দেয়। সংখ্যাটি বেছে নেওয়া পছন্দের বিষয় নয়, calibration-এর বিষয়: এটিকে স্বাভাবিক বাজারের ওঠানামার মধ্যে রাখলে bot বেশিরভাগ সপ্তাহেই halt হয়ে থাকবে, আর অনেক ওপরে রাখলে কখনও সক্রিয় হবে না। শুরু করার বিন্দু হলো, নির্দিষ্ট মাত্রার পতনের দিন বাজার নিজে কত ঘন ঘন তৈরি করে তা দেখা।
প্রতিটি সংখ্যার পেছনের সঠিক 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বছরে মোটামুটি 250টি trading day-এর মধ্যে 1% বা তার বেশি পতনের session ছিল 15টি 2019-এ এবং 45টি 2020-এ। 3% বা তার বেশি পতনের সংখ্যা ভিন্ন চিত্র দেখায়: 0টি 2019-এর বিপরীতে 16টি 2020-এ। 9-এর শেষ সারিতে কেবল July 31, 2026 পর্যন্ত session অন্তর্ভুক্ত করা হয়েছে।
রেখাটি স্থির নয়, বরং গুচ্ছাকারে এগোয়। আর এই গুচ্ছাকৃতিই নকশার গুরুত্বপূর্ণ বিষয়। কঠিন trading day একসঙ্গে কয়েকটি করে আসতে পারে। কোনো bot যদি এমন গুচ্ছের প্রথম দিনে halt হয় এবং দ্বিতীয় দিনে আবার চালু হয়, তাহলে সেটি বাস্তবে যথেষ্ট সময়ের জন্য halt হয়নি।
দুটি threshold দুটি ভিন্ন কাজ করে। দৈনিক ক্ষতির সীমা, যা সাধারণত account equity-এর 2%, session শেষ করে দেয়। Equity-এর সর্বোচ্চ স্তর বা high-water mark থেকে মাপা trailing drawdown limit, যা সাধারণত প্রায় 10%, মানব পর্যালোচনা না হওয়া পর্যন্ত strategy বন্ধ রাখে। প্রথমটি নিয়মিত ব্যবহারের জন্য, দ্বিতীয়টি বিরল ঘটনার জন্য। কেবল প্রথম সীমা থাকা bot প্রতিবার 2% করে account কমাতে পারে, অথচ কোনো সীমাই কখনও সক্রিয় নাও হতে পারে।
ভোলাটিলিটি স্কেলিং কীভাবে পজিশনের আকার পরিবর্তন করে?
ভোলাটিলিটি টার্গেটিং সাম্প্রতিক realized volatility-এর বিপরীত অনুপাতে পজিশনের আকার নির্ধারণ করে। দৈনিক রেঞ্জ দ্বিগুণ হলে পজিশনও মোটামুটি অর্ধেক হয়। এতে প্রতি ট্রেডে ডলারে ঝুঁকি প্রায় স্থির থাকে। এখানে realized volatility বলতে দৈনিক রিটার্নের 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)11.1%-এ annualized realized volatility 2024-01 এবং 12%-এ 2026-07 জুড়ে 31 মাসে মাপা হয়েছে। দ্বিতীয় কলামে প্রতিটি রিডিংকে এমন পজিশনে রূপান্তর করা হয়েছে, যা 12% volatility target বহন করবে। তবে তা full line-এ সীমাবদ্ধ: 100% বনাম 99.7%, যথাক্রমে 2024-01 এবং 2026-07-এ। কৌশল একই, বিশ্বাসের মাত্রা একই, কিন্তু শেয়ারের সংখ্যা সম্পূর্ণ ভিন্ন।
Kelly criterion একই সমস্যার দিকে বিপরীত দিক থেকে এগোয়। এটি শুধু ভোলাটিলিটির ভিত্তিতে নয়, আনুমানিক edge এবং variance-এর ভিত্তিতে পজিশনের আকার নির্ধারণ করে। উভয় ইনপুটই সীমিত নমুনা থেকে নেওয়া অনুমান হওয়ায় অধিকাংশ systematic operator Kelly-এর একটি অংশ ব্যবহার করেন—সাধারণত half Kelly বা quarter Kelly। Kelly criterion-এর পজিশন সাইজিং-এ এই হিসাবটি দেখানো হয়েছে।
স্টপের পর একটি trading bot কেন বারবার পুনরায় প্রবেশ করে?
একটি স্টপ কার্যকর হয়। পজিশন বন্ধ হয়ে যায়। 90 সেকেন্ড পর entry condition আবার সত্য হয়, bot পুনরায় প্রবেশ করে, একই ক্ষতি নেয় এবং প্রক্রিয়াটি পুনরাবৃত্তি করে। কোনো একক component নষ্ট নয়। Strategy-টি যেভাবে লেখা হয়েছিল, সেভাবেই কাজ করেছে। Stop-ও নির্ধারিত কাজ করেছে। তবু account প্রতিটি round trip-এ ধীরে ধীরে ক্ষয় হতে থাকে।
এই পুনরাবৃত্তির মাত্রা সরাসরি 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)SPY প্রতি session-এ গড়ে 0.7 বার ওই band অতিক্রম করেছে 2025-08-এ এবং 1.5 বার অতিক্রম করেছে 2026-07-এ। একটি session-এ 2026-07 বার এমন crossing রেকর্ড হয়েছে, যার সংখ্যা ছিল 5। কোনো rule যদি level-এর এক পাশে entry নেয় এবং অন্য পাশে stop বসায়, তাহলে একদিনে সেটি সক্রিয় হওয়ার সুযোগও ওই সংখ্যক থাকে।
চারটি ব্যবস্থা এই পুনরাবৃত্তি নিয়ন্ত্রণ করে।
- প্রতিটি stop-এর পর cooldown। এটি মিনিট বা bar-এ মাপা হয়। এই সময়ে ওই symbol-এর জন্য কোনো নতুন order risk layer অতিক্রম করতে পারে না।
- প্রতি symbol-এর জন্য দৈনিক trade count cap। এটি সীমাহীন loop-কে একটি নির্দিষ্ট সীমার মধ্যে নিয়ে আসে।
- একটি halt flag, যা latch হয়ে থাকে। দৈনিক loss limit কার্যকর হলে flag-টি সক্রিয় অবস্থায় থাকে, যতক্ষণ না কোনো ব্যক্তি সেটি reset করেন।
- Process memory-এর বাইরে ওই flag-এর persistence। কোনো supervisor crash করা bot পুনরায় চালু করলে তাকে নতুন অবস্থায় শুরু করায়। অথচ এই flag-এর উদ্দেশ্যই হলো এমন নতুন সূচনা ঠেকানো।
শেষ ব্যবস্থাটি তাদের ক্ষেত্রেও সমস্যা তৈরি করে, যারা বাকি সবকিছু ঠিকভাবে করেছেন। Grid trading bots নকশা অনুযায়ী order-এর ladder বসায়। তাই trade-count cap এখানে আনুষ্ঠানিক ব্যবস্থা নয়; এটি পুরো risk control কাঠামোর একটি অপরিহার্য অংশ।
কোনো বট stale price feed-এ ট্রেড করলে কী ঘটে?
আপডেট বন্ধ হয়ে যাওয়া একটি quote এখনও একটি সংখ্যা হিসেবে দেখা যায়। বট সেটি পড়ে, ওই দামের ভিত্তিতে একটি order-এর মূল্য নির্ধারণ করে এবং সেই order এমন একটি market-এ পাঠায়, যা ইতিমধ্যে নড়ে গেছে। ব্যর্থতাটি নীরবে ঘটে: কোনো exception তৈরি হয় না, কোনো error log হয় না, এবং fill-গুলো অস্বাভাবিক মনে হয় কেবল পরে।
এটি পরিমাপের সবচেয়ে পরিষ্কার উপায় হলো overnight gap। এতে একটি পরিচিত দাম ঘণ্টার পর ঘণ্টা অপরিবর্তিত থাকে, অথচ 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 অনুযায়ী সবচেয়ে বিস্তৃত name ছিল TSLA, যার gap 4.41%; এর বিপরীতে KO-এর gap ছিল 1%। সাধারণ রাতগুলো অনেক শান্ত ছিল: median gap ছিল যথাক্রমে 1.01% এবং 0.24%। Risk layer মূলত এই tail risk সামলানোর জন্যই তৈরি করা হয়। পরিমাপ করা সময়সীমায় TSLA-এ একক বৃহত্তম gap ছিল 14.57%। কিছু সময় আগে পড়া একটি দামের ভিত্তিতে কাজ করা বটের জন্য এগুলোই সম্ভাব্য দূরত্ব। এর কার্যপ্রণালি overnight gap-এ stock-এর দামের পরিবর্তন কেন হয়-এ ব্যাখ্যা করা হয়েছে।
প্রতিরোধমূলক ব্যবস্থা সাশ্রয়ী। Risk layer যে প্রতিটি quote-এর ভিত্তিতে মূল্য নির্ধারণ করবে, তার জন্য সর্বোচ্চ বয়স নির্ধারণ করুন। Intraday strategy-র ক্ষেত্রে সাধারণত কয়েক সেকেন্ড যথেষ্ট। Feed-এর heartbeat data থেকে আলাদাভাবে নিন। এতে silent socket এবং শান্ত market-এর মধ্যে পার্থক্য বোঝা যায়। Data না থাকলে সেটিকে hold নয়, halt হিসেবে বিবেচনা করুন। কারণ কোনো দামের তথ্য ছাড়া বট তার exit-ও মূল্যায়ন করতে পারে না।
ঝুঁকি স্তরে কোন কঠোর সীমাগুলো থাকা উচিত?
- অ্যাকাউন্টের ইকুইটির অংশ হিসেবে প্রতিটি symbol-এর সর্বোচ্চ notional। 10% ceiling রাখলে একটি খারাপ symbol পুরো অ্যাকাউন্টকে ক্ষতিগ্রস্ত করতে পারে না।
- সব খোলা পজিশন মিলিয়ে সর্বোচ্চ gross notional। এটি ইকুইটির 100%-এ নির্ধারণ করলে leverage ব্যবহার হয় না। এই সিদ্ধান্তটি broker-এর default সেটিংস থেকে উত্তরাধিকারসূত্রে নেওয়ার বদলে স্পষ্টভাবে নেওয়া উচিত।
- প্রতি মিনিটে এবং প্রতিদিন সর্বোচ্চ order rate। বেশিরভাগ retail strategy-এর জন্য প্রতি মিনিটে 10টি order যথেষ্ট উদার সীমা। একই সঙ্গে এটি এক মিনিটের মধ্যে কোনো runaway loop-এর গতি নিয়ন্ত্রণ করে।
- symbol-এর average daily volume-এর অংশ হিসেবে সর্বোচ্চ order size। 1% ceiling রাখলে bot যে দামে trade করতে চাইছে, সেই দাম নিজেই উল্লেখযোগ্যভাবে বদলে দিতে পারে না। এখানে average daily volume-ই denominator।
এর প্রতিটি risk layer-এ থাকা উচিত, strategy-তে নয়। Backtest, paper এবং live—তিন ক্ষেত্রেই প্রতিটি সীমার জন্য একই code path ব্যবহার করা উচিত। কোনো limit যদি শুধু live পরিবেশে থাকে, তাহলে সেটি এমন একটি limit যা কেউ পরীক্ষা করেনি।
একটি trading bot-এর audit log-এ কী থাকা দরকার?
Append-only log প্রতিটি সিদ্ধান্তের জন্য একটি করে রেকর্ড লেখে এবং কোনো রেকর্ড সম্পাদনা বা মুছে ফেলে না। প্রতিটি রেকর্ডে timestamp, ব্যবহৃত quote এবং সেটির age, চালানো প্রতিটি limit check-এর verdict, পাঠানো order এবং broker-এর reply থাকে। Rejected order-ও filled order-এর সমান গুরুত্ব দিয়ে লেখা হয়।
পরে ঘটনাটি পুনর্গঠন করাই মূল উদ্দেশ্য। কোনো খারাপ সেশনের ছয় সপ্তাহ পর প্রশ্নটি কখনও শুধু P&L কত ছিল, তা নয়। প্রশ্ন হলো, কোন check পাস করেছিল এবং কোন input-এর ভিত্তিতে করেছিল। রেকর্ড করা input না থাকলে আপনি market-এর অবস্থা থেকে bot-এর state পুনরায় নির্ধারণ করতে বাধ্য হবেন। এটি backtesting-এ look-ahead bias-এর মতো একই ভুল: সিদ্ধান্ত নেওয়ার মুহূর্তে সিস্টেমের কাছে যে তথ্য ছিল না, তা ব্যবহার করা।
riskguard project এই পৃথকীকরণের একটি open-source implementation। এখানে limit check-গুলো strategy-র ভেতরে ছড়িয়ে থাকা logic নয়; বরং strategy যে component-কে call করে, সেখানে রাখা হয়। এটি কয়েকটি সম্ভাব্য design-এর একটি। সরাসরি গ্রহণ করার আগে পড়ে দেখা উচিত। আপনি যে implementation-এর ওপর নির্ভর করেন, default branch-এর বদলে tagged release pin করুন। একই backtest দুবার চালানোর মধ্যে branch পরিবর্তিত হতে পারে। নীরবে পরিবর্তিত risk layer কোনো risk layer না থাকার চেয়েও খারাপ।
কেন প্রথম deployment paper broker-এ চলে
Broker adapter ডিফল্টভাবে paper mode-এ থাকে। Live trading চালু করতে ইচ্ছাকৃতভাবে একটি explicit flag সেট করতে হয়। এতে একটি সাধারণ কিন্তু গুরুতর ভুল ঠেকানো যায়: কপি করা config file বা পরিবর্তন না করা environment variable-এর কারণে real order বাস্তব অর্থে পাঠিয়ে দেওয়া।
Paper run আরও একটি গুরুত্বপূর্ণ artifact তৈরি করে। সেটি হলো live price-এর ওপর একই risk layer থেকে তৈরি decision log। এতে কোন limit সক্রিয় হয়েছে এবং কোনটি হয়নি, তা দেখা যায়। এটি risk layer সম্পর্কে প্রমাণ দেয়। কৌশলটি লাভজনক কি না, সেটি আলাদা প্রশ্ন। বাস্তব অর্থ ব্যবহারের আগে paper trading-এ paper record কী প্রমাণ করে এবং কী প্রমাণ করে না, তা ব্যাখ্যা করা হয়েছে। আর multi-agent AI trading systems দেখায়, একাধিক agent order দিতে পারলে halt করার কর্তৃত্ব কেন প্রতিটি agent-এর বাইরে রাখতে হয়।
ট্রেডিং বটের সার্কিট ব্রেকার: প্রায়শই জিজ্ঞাসিত প্রশ্ন
ট্রেডিং বটে সার্কিট ব্রেকার কী?
এটি ঝুঁকি-নিয়ন্ত্রণ স্তরের একটি নিয়ম। নির্ধারিত সীমা ছুঁলে এটি বটকে নতুন অর্ডার পাঠানো বন্ধ করে। সাধারণত এই সীমা হলো দৈনিক লোকসানের threshold অথবা অ্যাকাউন্টের equity peak থেকে drawdown। এটি strategy থেকে স্বাধীনভাবে প্রতিটি অর্ডারে কার্যকর হয় এবং কোনো ব্যবস্থা নিয়ে সেটি clear না করা পর্যন্ত সক্রিয় থাকে।
বাজারে 2% পতনের দিন কত ঘন ঘন আসে?
প্রতি বছর প্রায় 250টি trading day-এর মধ্যে SPY-তে 2% বা তার বেশি পতন হয়েছিল 5টি session-এ 2019 সালে এবং 25টি session-এ 2020 সালে। শান্ত বছর ও চাপের বছরের এই পার্থক্যের কারণেই loss limit অনুমানের ভিত্তিতে নয়, ঐতিহাসিক তথ্যের ভিত্তিতে নির্ধারণ করা উচিত।
stop-এর পর বটকে পুনরায় প্রবেশ করা থেকে কীভাবে আটকাবেন?
প্রতিটি stop-এর পর একটি cooldown window এবং প্রতিটি symbol-এর জন্য দৈনিক trade cap নির্ধারণ করলে সীমাহীন loop একটি সীমাবদ্ধ loop-এ পরিণত হয়। Halt flag-ও process memory-এর বাইরে latch করে সংরক্ষণ করতে হবে। তা না হলে supervisor কোনো crashed bot পুনরায় চালু করার সময় সেটিকে নতুন, unhalted state দিয়ে শুরু করাবে।
price feed পুরোনো হয়ে গেছে কি না, বট কীভাবে বুঝবে?
অর্ডারের মূল্য নির্ধারণের আগে প্রতিটি quote কত পুরোনো তা পরীক্ষা করতে হবে। একই সঙ্গে data থেকে আলাদাভাবে feed-এর heartbeat পর্যবেক্ষণ করতে হবে। Overnight gap একটি stale price কী মাত্রার ঝুঁকি আড়াল করতে পারে, তা দেখায়: 2024 সালের January থেকে 2026 সালের July পর্যন্ত 4.41%-এ 95th-percentile overnight move TSLA-এ পৌঁছেছিল।
ছোট trading bot-এর কি সত্যিই audit log দরকার?
Fills-এর log কী ঘটেছে তা নথিবদ্ধ করে। Decisions-এর log নথিবদ্ধ করে বট কী করতে অনুমোদিত ছিল বলে মনে করেছিল। ভুল strategy এবং যে risk check কখনও চলেনি, তাদের পার্থক্য বোঝার একমাত্র উপায় এটিই। Append-only log, যেখানে rejections-ও অন্তর্ভুক্ত থাকবে, হলো কার্যকর ন্যূনতম সংস্করণ।
উপরের প্রতিটি figure minute bar-এর ওপর চালানো stored query থেকে নেওয়া হয়েছে, এবং প্রতিটি panel খুললে তার পেছনের SQL দেখা যায়। Strasmore terminal-এ একই query চালিয়ে আপনার নিজস্ব symbol list ব্যবহার করুন।