Strasmore Research
கற்றல் Matt Connorஆசிரியர் Matt Connor · புதுப்பிக்கப்பட்டது 2026-08-04

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-ல் செயல்படுகின்றன. Strategy அதற்கு உடன்பட்டாலும் இல்லாவிட்டாலும், ஒவ்வொரு order-க்கும் இவை பொருந்தும். எதை trade செய்ய வேண்டும் என்பதை strategy தீர்மானிக்கிறது. Trading நடைபெற வேண்டுமா என்பதையே risk layer தீர்மானிக்கிறது.

இந்தப் பிரிப்பே முழு வடிவமைப்பின் அடிப்படை. தன்னைத்தானே கண்காணிக்கும் strategy-க்கு, அதன் சொந்த முன்னெண்ணங்கள் முறியும் தருணத்தில் எந்தச் சுயாதீனச் சரிபார்ப்பும் இருக்காது. அத்தகைய தருணத்தில்தான் அந்தச் சரிபார்ப்பு மிகவும் அவசியமாகிறது.

ஒரு trading bot-இல் circuit breaker செய்யும் பணி

ஒரு risk layer-க்கு நான்கு பகுதிகள் உள்ளன. ஒவ்வொன்றும் குறிப்பிட்ட, எளிதில் தவிர்க்கக்கூடிய தோல்வியைத் தடுக்கிறது.

  • Position size, ஒவ்வொரு symbol-க்குமான notional exposure, மற்றும் order rate ஆகியவற்றுக்கு hard caps விதிக்கப்படுகின்றன. இல்லையெனில் வரம்பின்றி அதிகரிக்கக்கூடிய bug-னால் ஏற்படும் சேதத்தை இவை கட்டுப்படுத்துகின்றன.
  • Session-இல் கணக்கு குறிப்பிடப்பட்ட அளவு இழப்பைச் சந்தித்தவுடன், அல்லது equity peak-இலிருந்து குறிப்பிடப்பட்ட அளவு குறைந்தவுடன், புதிய orders-ஐ நிறுத்தும் drawdown circuit breaker.
  • நிலையான share count-ஐப் பயன்படுத்துவதற்குப் பதிலாக, சமீபத்திய volatility அல்லது Kelly bet-ன் ஒரு பகுதியை அடிப்படையாகக் கொண்டு scaled order sizing நிர்ணயிக்கப்படுகிறது. இதனால் சந்தையின் trading range மாறினாலும், ஒவ்வொரு trade-க்குமான risk ஏறத்தாழ நிலையாக இருக்கும்.
  • Risk layer நிராகரித்த orders உட்பட, ஒவ்வொரு முடிவையும் பதிவு செய்யும் append-only audit log. “Strategy தவறாக இருந்தது” என்பதையும் “check இயங்கவே இல்லை” என்பதையும் வேறுபடுத்திக் காட்டும் ஒரே பதிவாக இது உள்ளது.

கீழே உள்ள அனைத்தும் இந்த நான்கு பகுதிகளில் ஒன்றை நடைமுறையில் விளக்குகின்றன.

ஒரு trading bot-க்கான நியாயமான தினசரி இழப்பு வரம்பு எவ்வளவு?

ஒரு அமர்வின் இழப்பு நிர்ணயிக்கப்பட்ட வரம்பைத் தாண்டியவுடன், தினசரி இழப்பு வரம்பு புதிய orders-ஐ நிறுத்துகிறது. இந்த எண்ணைத் தேர்வு செய்வது விருப்பத்தின் அடிப்படையிலானது அல்ல; இது calibration தேவைப்படும் முடிவு. சாதாரண market noise-க்குள் வரம்பை அமைத்தால், bot பெரும்பாலான வாரங்களில் halted நிலையில் இருக்கும். மிகத் தொலைவான வரம்பை அமைத்தால், அது ஒருபோதும் செயல்படாது. எனவே, சந்தையே குறிப்பிட்ட அளவிலான சரிவு நாளை எவ்வளவு அடிக்கடி உருவாக்குகிறது என்பதே தொடக்கப் புள்ளியாகும்.

வினவவும்2018 முதல் ஜூலை 2026 வரை, ஆண்டுவாரியாக SPY இறக்க நாட்களின் அளவு
ஒவ்வொரு எண்ணின் பின்னணியில் உள்ள துல்லியமான 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
Run this yourself

1% அல்லது அதற்கு மேல் சரிந்த sessions எண்ணிக்கை, ஆண்டுக்கு சுமார் 250 trading days-இல், 15 மற்றும் 45 ஆக இருந்தது; இவை முறையே 2019 மற்றும் 2020 காலகட்டங்களுக்கானவை. 3% அல்லது அதற்கு மேல் சரிந்த sessions எண்ணிக்கை வேறுபட்டது: 0 sessions 2019-இலும், 16 sessions 2020-இலும் பதிவானது. 9-ன் கடைசி வரி, July 31, 2026 வரையிலான sessions-ஐ மட்டுமே உள்ளடக்கியது.

இந்த வரிசை சீரானதாக இல்லாமல், தொகுதிகளாகக் காணப்படுகிறது. அந்தத் தொகுதிகளே வடிவமைப்பில் முக்கியமானவை. கடுமையான சரிவு நாட்கள் குழுக்களாக வரலாம். ஒரு cluster-ன் முதல் நாளில் bot-ஐ நிறுத்தி, இரண்டாவது நாளில் மீண்டும் இயக்கினால், அது உண்மையில் நிறுத்தப்பட்டதாகாது.

இரண்டு thresholds வெவ்வேறு பணிகளைச் செய்கின்றன. பொதுவாக account equity-யின் 2% ஆக அமைக்கப்படும் தினசரி இழப்பு வரம்பு, அந்த session-ஐ முடிவுக்குக் கொண்டுவருகிறது. Equity-யின் high-water mark-இலிருந்து அளவிடப்படும் trailing drawdown limit, பொதுவாக சுமார் 10% ஆக இருக்கும்; இது human review முடியும் வரை strategy-யை நிறுத்துகிறது. முதலாவது routine கட்டுப்பாடு. இரண்டாவது அரிதாகவே செயல்பட வேண்டிய கட்டுப்பாடு. முதலாவது வரம்பை மட்டும் கொண்ட bot, ஒவ்வொரு முறையும் 2% வீதம் account-ஐக் குறைத்துக்கொண்டே போகலாம்; இருந்தாலும் எந்தக் கட்டுப்பாடும் செயல்படாமல் இருக்கலாம்.

volatility scaling position size-ஐ எவ்வாறு மாற்றுகிறது?

Volatility targeting, சமீபத்தில் உணரப்பட்ட volatility-க்கு எதிர்மாறாக position size-ஐ நிர்ணயிக்கிறது: தினசரி trading range இரட்டிப்பானால், position பொதுவாக பாதியாகக் குறைக்கப்படும். இதனால் ஒவ்வொரு trade-க்கும் dollar risk ஏறத்தாழ நிலையாக இருக்கும். இங்கு realized volatility என்பது தினசரி returns-ன் annualized standard deviation ஆகும். அது பெரும்பாலானோர் எதிர்பார்ப்பதைவிட அதிகமாக மாறுபடும்.

வினவவும்மாதாந்திர SPY realized volatility மற்றும் 12% volatility target கொண்ட நிலை அளவு
ஒவ்வொரு எண்ணின் பின்னணியில் உள்ள துல்லியமான 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)
Run this yourself

2024-01-இல் annualized ஆக அளவிடப்பட்ட realized volatility, 2026-07-இல் 12% ஆகவும், 11.1% மற்றும் 31 மாதங்களுக்கு இடையிலும் இருந்தது. இரண்டாவது column, ஒவ்வொரு reading-ஐயும் 12% volatility target அடிப்படையில் வைத்திருக்கக்கூடிய position-ஆக மாற்றுகிறது. இது முழு line அளவில் கட்டுப்படுத்தப்பட்டுள்ளது: 2024-01-க்கு எதிராக 2026-07, 100% மற்றும் 99.7% அடிப்படையில். Strategy ஒன்றே. Conviction ஒன்றே. ஆனால் share count மிகவும் வேறுபட்டது.

Kelly criterion, volatility-ஐ மட்டும் அடிப்படையாகக் கொள்ளாமல், மதிப்பிடப்பட்ட edge மற்றும் variance-ஐக் கொண்டு position size-ஐ நிர்ணயிப்பதன் மூலம் இதே பிரச்சினையை வேறு கோணத்தில் அணுகுகிறது. இந்த இரண்டு inputs-மும் வரையறுக்கப்பட்ட sample-இலிருந்து பெறப்பட்ட மதிப்பீடுகள் என்பதால், பெரும்பாலான systematic operators Kelly அளவின் ஒரு பகுதியை மட்டுமே பயன்படுத்துகின்றனர்; பொதுவாக half Kelly அல்லது quarter Kelly. Kelly criterion position sizing அந்தக் கணக்கீட்டை விளக்குகிறது.

Stop-loss செயல்பட்ட பிறகும் trading bot மீண்டும் entry எடுப்பது ஏன்?

Stop-loss செயல்படுகிறது. Position மூடப்படுகிறது. தொண்ணூறு விநாடிகளுக்குப் பிறகு entry condition மீண்டும் உண்மையாகிறது. Bot மீண்டும் entry எடுக்கிறது, அதே இழப்பைச் சந்திக்கிறது, பின்னர் இதையே தொடர்கிறது. எந்த ஒரு component-மும் பழுதாகவில்லை. Strategy எழுதப்பட்டபடியே செயல்பட்டது. Stop-loss எழுதப்பட்டபடியே செயல்பட்டது. இருந்தாலும் account ஒவ்வொரு round trip-லும் சிறிதுசிறிதாக இழப்பைச் சந்திக்கிறது.

இந்த நிகழ்வின் frequency, price path-இலிருந்தே நேரடியாக வருகிறது. இந்த panel, ஒவ்வொரு session-க்கும் SPY-யின் opening price-ஐவிட 0.1%-க்கும் அதிகமாக மேலே சென்ற நிலையிலிருந்து 0.1%-க்கும் அதிகமாகக் கீழே சென்றது, அல்லது மீண்டும் அதற்கு மாறாகச் சென்றது, எத்தனை முறை என்பதை எண்ணுகிறது.

வினவவும்ஒவ்வொரு session-லும் SPY தனது opening price-ஐ மீண்டும் கடக்கும் நிகழ்வுகளின் மாதாந்திர எண்ணிக்கை
ஒவ்வொரு எண்ணின் பின்னணியில் உள்ள துல்லியமான 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)
Run this yourself

2025-08 மற்றும் 2026-07 ஆகிய காலப்பகுதிகளில், SPY அந்த band-ஐ ஒரு session-க்கு சராசரியாக 0.7 மற்றும் 1.5 முறை கடந்தது. 2026-07-இல் நடந்த ஒரு session-ல் 5 crossings பதிவானது. ஒரு level-ன் ஒரு பக்கத்தில் position திறந்து, மறுபக்கத்தில் stop வைக்கும் எந்த rule-க்கும் ஒரே நாளில் இத்தனை முறை செயல்பட வாய்ப்பு உள்ளது.

நான்கு mechanics இதைக் கட்டுப்படுத்துகின்றன.

  • ஒவ்வொரு stop-க்குப் பிறகும் cooldown வைக்க வேண்டும். இது minutes அல்லது bars-ஆக அளவிடப்படும். அந்தக் காலத்தில், அந்த symbol-க்கான புதிய order எதுவும் risk layer-ஐக் கடக்காது.
  • ஒவ்வொரு symbol-க்கும் daily trade count cap வைக்க வேண்டும். இது முடிவில்லாத loop-ஐ வரையறுக்கப்பட்ட எண்ணிக்கையாக மாற்றுகிறது.
  • Halt flag latch ஆக இருக்க வேண்டும். Daily loss limit செயல்பட்டவுடன், ஒருவர் அதைத் தெளிவுபடுத்தும் வரை அது செயல்பட்ட நிலையிலேயே இருக்க வேண்டும்.
  • அந்த flag-ஐ process memory-க்கு வெளியிலும் persist செய்ய வேண்டும். Crashed bot-ஐ supervisor restart செய்யும்போது clean slate வழங்கினால், அந்த flag தடுக்க வேண்டிய நிலை மீண்டும் உருவாகும். இதைத் தடுப்பதற்காகத்தான் அந்த flag உள்ளது.

மற்ற அனைத்தையும் சரியாகச் செய்தவர்களையும் கடைசி அம்சம் சிக்கலில் ஆழ்த்துகிறது. Grid trading bots வடிவமைப்பின்படியே order ladders-ஐ அமைக்கின்றன. எனவே trade-count cap என்பது அலங்கார அம்சம் அல்ல; செயல்பாட்டுக்கு அத்தியாவசியமான கட்டுப்பாடாகும்.

பழைய விலைத் தரவு feed-ல் bot வர்த்தகம் செய்தால் என்ன நடக்கும்?

புதுப்பிப்பு நிறுத்தப்பட்ட quote இன்னும் ஒரு எண்ணாகவே தெரியும். Bot அதைப் படித்து, அதனை அடிப்படையாகக் கொண்டு order-க்கு விலை நிர்ணயித்து, ஏற்கனவே நகர்ந்துவிட்ட market-க்கு அந்த order-ஐ அனுப்புகிறது. இந்தத் தோல்வி அமைதியாக நிகழ்கிறது: எந்த exception-மும் ஏற்படாது, error log எதுவும் உருவாகாது, fill-கள் பின்னர் மட்டுமே வழக்கத்திற்கு மாறாகத் தெரியும்.

தெளிவாக அளவிடக்கூடிய நிலை overnight gap ஆகும். இதில் அறியப்பட்ட ஒரு விலை பல மணி நேரம் மாறாமல் இருக்கும்; அதே நேரத்தில் வர்த்தகம் செய்யக்கூடிய விலை நகர்ந்துகொண்டிருக்கும்.

வினவவும்முந்தைய close முதல் அடுத்த open வரையிலான overnight gap: ஆறு names, ஜனவரி 2024 முதல் ஜூலை 2026 வரை
ஒவ்வொரு எண்ணின் பின்னணியில் உள்ள துல்லியமான 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 DESC
Run this yourself

95th-percentile gap அடிப்படையில் அதிகபட்சமாகப் பரவிய name TSLA ஆகும்; அதன் அளவு 4.41%. இதனுடன் ஒப்பிடுகையில், KO-க்கான அளவு 1%. வழக்கமான இரவுகளில் நிலை மிகவும் அமைதியாக இருந்தது: median gap முறையே 1.01% மற்றும் 0.24% ஆக இருந்தன. Risk layer உருவாக்கப்படுவதன் காரணம் இந்த tail நிகழ்வுகளுக்காகத்தான். அளவிடப்பட்ட காலப்பகுதியில் TSLA-இல் ஏற்பட்ட மிகப்பெரிய single gap 14.57% ஆகும். சில நேரத்திற்கு முன்பு படித்த விலையை அடிப்படையாகக் கொண்டு செயல்படும் bot எதிர்கொள்ளக்கூடிய விலைத் தூரங்கள் இவையே. பங்குகள் overnight gap ஏற்படுத்துவதற்கான காரணம் இதன் செயல்முறையை விளக்குகிறது.

தற்காப்பு நடவடிக்கைகள் குறைந்த செலவுடையவை. Risk layer விலை நிர்ணயிக்கப் பயன்படுத்தும் ஒவ்வொரு quote-க்கும் அதிகபட்ச வயது வரம்பை நிர்ணயிக்கவும்; intraday strategy-க்கு இது பொதுவாக சில விநாடிகளாக இருக்கும். Data-இலிருந்து தனியாக feed-ன் heartbeat-ஐப் பெறவும். இதன் மூலம் அமைதியாக இருக்கும் market-ஐச் சேர்ந்த feed-க்கும், செயலிழந்த socket-க்கும் இடையிலான வேறுபாட்டைக் கண்டறியலாம். Data காணாமல் போனால் அதை hold ஆகக் கருதாமல் halt ஆகக் கருதவும். ஏனெனில் விலைகள் இல்லாத bot-ஆல் அதன் exit-களையும் மதிப்பிட முடியாது.

எந்தக் கடின வரம்புகள் risk layer-இல் இருக்க வேண்டும்?

  • ஒவ்வொரு symbol-க்கும் account equity-யில் உள்ள பங்காகக் கணக்கிடப்படும் அதிகபட்ச notional. 10% உச்சவரம்பு வைத்தால், ஒரு மோசமான symbol முழுக் கணக்கையும் பாதிப்பதைத் தடுக்கலாம்.
  • திறந்துள்ள அனைத்து positions-களையும் சேர்த்த அதிகபட்ச gross notional. இதை equity-யின் 100% ஆக நிர்ணயிப்பது leverage இல்லாத நிலையை ஏற்படுத்தும். இந்த முடிவை broker-ன் இயல்புநிலை அமைப்பிலிருந்து தானாகப் பெறுவதற்குப் பதிலாக, வெளிப்படையாக எடுக்க வேண்டும்.
  • நிமிடத்திற்கு மற்றும் நாளொன்றுக்கு அனுமதிக்கப்படும் அதிகபட்ச order rate. பெரும்பாலான retail strategies-க்கு நிமிடத்திற்கு பத்து orders போதுமான அளவு அதிகமாகும். அதே நேரத்தில், கட்டுப்பாடின்றி இயங்கும் loop ஒரு நிமிடத்துக்குள் ஏற்படுத்தக்கூடிய பாதிப்பையும் இது கட்டுப்படுத்தும்.
  • symbol-ன் average daily volume-இன் பங்காகக் கணக்கிடப்படும் அதிகபட்ச order size. 1% உச்சவரம்பு வைத்தால், bot வர்த்தகம் செய்ய முயலும் விலையைத் தானே மாற்றிவிடுவதைத் தடுக்கலாம்; இதற்கான denominator average daily volume ஆகும்.

இவை அனைத்தும் strategy-யில் அல்ல, risk layer-இல்தான் இருக்க வேண்டும். மேலும், இவை அனைத்தும் backtest, paper மற்றும் live ஆகிய மூன்று சூழல்களிலும் ஒரே code path வழியாகச் செயல்பட வேண்டும். live சூழலில் மட்டுமே இருக்கும் வரம்பை யாரும் சோதித்திருக்கவில்லை.

trading bot audit log-க்கு என்ன தேவை?

Append-only log ஒவ்வொரு முடிவுக்கும் ஒரு record-ஐ எழுதும்; அதை ஒருபோதும் திருத்தவோ நீக்கவோ செய்யாது. ஒவ்வொரு record-லும் timestamp, பயன்படுத்தப்பட்ட quote மற்றும் அதன் வயது, இயக்கப்பட்ட ஒவ்வொரு limit check-ன் முடிவு, அனுப்பப்பட்ட order, broker-ன் பதில் ஆகியவை இடம்பெறும். நிராகரிக்கப்பட்ட orders-க்கும் நிறைவேற்றப்பட்ட orders-க்கு அளிக்கப்படும் அதே முக்கியத்துவம் அளிக்கப்பட வேண்டும்.

மீள்கட்டமைப்பே இதன் நோக்கம். மோசமான trading session-க்கு ஆறு வாரங்களுக்குப் பிறகு கேட்கப்படும் கேள்வி, P&L எவ்வளவு என்பதல்ல. எந்த input-ன் அடிப்படையில் எந்த check நிறைவேற்றப்பட்டது என்பதே கேள்வி. பதிவு செய்யப்பட்ட input இல்லையெனில், market-ன் நிலைமையிலிருந்து bot-ன் நிலையை மீண்டும் உருவாக்க வேண்டியிருக்கும். இது backtesting-இல் காணப்படும் look-ahead bias போன்ற அதே தவறாகும்: முடிவு எடுக்கப்பட்ட தருணத்தில் system-ல் இல்லாத தகவலைப் பயன்படுத்துவது.

riskguard project, இந்தப் பிரிப்பைச் செயல்படுத்தும் open-source implementation-களில் ஒன்றாகும். இதில் limit checks, strategy-க்குள் சிதறிக் கிடக்கும் logic ஆக இல்லாமல், strategy அழைக்கும் ஒரு component-ல் இடம்பெறுகின்றன. இது பல வடிவமைப்புகளில் ஒன்றே; உடனடியாக ஏற்றுக்கொள்வதற்குப் பதிலாகப் படித்துப் புரிந்துகொள்ள வேண்டிய ஒன்று. நீங்கள் எந்த implementation-ஐச் சார்ந்திருந்தாலும், default branch-க்குப் பதிலாக tagged release-ஐ pin செய்யுங்கள். ஒரே backtest-ன் இரண்டு runs-க்கிடையில் branch மாறக்கூடும். அமைதியாக மாறிய risk layer, risk layer இல்லாததைவிட மோசமானது.

முதல் deployment ஏன் paper broker-ல் இயங்குகிறது

Broker adapter இயல்பாக paper முறையில் அமைக்கப்பட்டுள்ளது. Live trading-ஐ இயக்குவதற்கு திட்டமிட்டே explicit flag அமைக்க வேண்டும். இதனால் தவிர்க்கப்படும் தோல்வி மிகவும் சாதாரணமானது: நகலெடுக்கப்பட்ட config file அல்லது மாற்றப்படாமல் விடப்பட்ட environment variable, உண்மையான பணத்தில் உண்மையான orders-ஐ அனுப்பிவிடலாம்.

Paper run, மேலும் முக்கியமான artifact-ஐ உருவாக்குகிறது. Live prices மீது அதே risk layer செயல்பட்டபோது உருவாகும் decision log அது. எந்த limits செயல்பட்டன, எவை செயல்படவில்லை என்பதையும் அது காட்டுகிறது. இது risk layer பற்றிய ஆதாரம். Strategy பணம் ஈட்டுகிறதா என்பது அதிலிருந்து வேறுபட்ட கேள்வி. உண்மையான பணத்திற்கு முன் paper trading paper record எதை நிரூபிக்கிறது, எதை நிரூபிக்காது என்பதைக் கூறுகிறது. மேலும், பல agents orders வைக்கக்கூடிய சூழலில் halt authority ஒவ்வொரு agent-க்கும் வெளியே இருக்க வேண்டியதன் காரணத்தை பல-agent AI trading systems விளக்குகிறது.

Trading bot circuit breaker குறித்த அடிக்கடி கேட்கப்படும் கேள்விகள்

Trading bot-இல் circuit breaker என்றால் என்ன?

குறிப்பிட்ட வரம்பு எட்டப்பட்டவுடன் bot புதிய orders அனுப்புவதை நிறுத்தும் risk layer விதி. இது பொதுவாக தினசரி loss threshold அல்லது account equity-யின் உச்சத்திலிருந்து ஏற்பட்ட drawdown ஆக இருக்கும். இது strategy-யிலிருந்து சுயாதீனமாக, ஒவ்வொரு order-க்கும் செயல்படும். ஏதேனும் ஒன்று அதை clear செய்யும் வரை இது செயலிழந்த நிலையில் தொடரும்.

சந்தையில் 2% சரிவு ஏற்பட்ட நாள் எவ்வளவு அடிக்கடி வருகிறது?

SPY-யில் 5 sessions-ல் 2% அல்லது அதற்கு மேற்பட்ட சரிவு பதிவானது 2019-ல்; 25 sessions 2020-ல் பதிவானது. ஒவ்வொரு ஆண்டும் சுமார் 250 trading days உள்ள நிலையில், அமைதியான ஆண்டுக்கும் நெருக்கடியான ஆண்டுக்கும் இடையிலான இந்த வேறுபாடு முக்கியமானது. அதனால் loss limit-ஐ ஊகத்தின் அடிப்படையில் அல்லாமல் வரலாற்றுத் தரவின் அடிப்படையில் நிர்ணயிக்க வேண்டும்.

stop ஏற்பட்ட பிறகு bot மீண்டும் entry எடுக்காமல் இருப்பதை எவ்வாறு உறுதி செய்வது?

ஒவ்வொரு stop-க்குப் பிறகும் cooldown window ஒன்றையும், ஒவ்வொரு symbol-க்கும் தினசரி trade cap ஒன்றையும் அமைக்க வேண்டும். இதனால் வரம்பற்ற loop கட்டுப்படுத்தப்பட்ட loop ஆக மாறும். halt flag latch செய்து, process memory-க்கு வெளியிலும் persist ஆக வேண்டும். இல்லையெனில் supervisor crash ஆன bot-ஐ restart செய்யும்போது, அது மீண்டும் halt செய்யப்படாத புதிய state-இல் தொடங்கும்.

price feed பழையதாகிவிட்டதை bot எவ்வாறு கண்டறியும்?

ஒவ்வொரு quote-ன் வயதையும் சரிபார்த்த பிறகே அதைப் பயன்படுத்தி order-க்கு pricing செய்ய வேண்டும். அதேசமயம், data-விலிருந்து தனியாக feed-ன் heartbeat-ஐயும் கண்காணிக்க வேண்டும். Stale price மறைக்கும் அபாயத்தின் அளவை overnight gaps காட்டுகின்றன: January 2024 முதல் July 2026 வரை, TSLA அன்று 95th-percentile overnight move 4.41%-ஐ எட்டியது.

சிறிய trading bot-க்கும் audit log உண்மையில் தேவையா?

Fills-ன் log என்ன நடந்தது என்பதைப் பதிவு செய்கிறது. Decisions-ன் log, bot எதைச் செய்ய அனுமதிக்கப்பட்டதாகக் கருதியது என்பதைப் பதிவு செய்கிறது. செயல்படாத risk check-இலிருந்து தவறான strategy-யை வேறுபடுத்திக் கண்டறிய இதுவே ஒரே வழி. Rejections உட்பட append-only log அமைப்பே பயனுள்ள குறைந்தபட்ச வடிவமாகும்.


மேலுள்ள ஒவ்வொரு figure-மும் minute bars மீது இயக்கப்பட்ட stored query-யிலிருந்து பெறப்பட்டது. ஒவ்வொரு panel-ஐத் திறந்தால் அதன் பின்னுள்ள SQL-ஐக் காணலாம். அதே queries-ஐ உங்கள் சொந்த symbol list-க்கு Strasmore terminal-ல் பயன்படுத்துங்கள்.

#risk-management#trading-bots#drawdown#position-sizing#automation