Macro event thesis revalidation checklist
Post-release revalidation process बनाएं ताकि new data, spread behavior या liquidity setup को invalid साबित करे तो अच्छी macro thesis भी जल्दी close हो
सीधा जवाब
Macro-event thesis revalidation यह post-release test है कि data, liquidity, time window और account constraints अभी trade को support करते हैं या नहीं। Thesis economically reasonable रह सकती है जबकि position untradeable हो जाए, इसलिए first response आने से पहले invalidation triggers और next action define करें।
दो अलग checkpoints define करें: release window और revalidation window
अधिकांश setups इसलिए fail होते हैं क्योंकि trader release validation को follow-through validation जैसा मानता है।
पहले यह करें:
Pre-release confirmation preparation के बारे में है। Revalidation confirmation survival के बारे में है।
Macro events में survival अक्सर data sequence के आपके सामने बदलने पर निर्भर होती है। आपकी revalidation list real time में execute होने जितनी short होनी चाहिए।
- Pre-release checkpoint: schedule, liquidity baseline और planned position size confirm करें
- Revalidation checkpoint: अगले 5 से 15 minutes में thesis invalidate करने वाले exact facts define करें
Dozens नहीं, 4 invalidation conditions रखें
बहुत अधिक rules execution quality घटाते हैं। केवल वे conditions चुनें जो risk structure flip करती हैं।
Exactly इन four categories का उपयोग करें:
हर category को one number के साथ document करें:
कोई one condition meet हो तो trade जरूरी नहीं कि wrong हो; वह invalidated है और process को branch switch करना चाहिए।
- actual print से thesis contradiction
- spread और depth failure
- stop-window mismatch
- financing या assignment surprise
- कौन-सा print level directional assumption टूटने का अर्थ है
- कौन-सी spread width position रखने को बहुत महंगा बनाती है
- कौन-सी clock adjustment window को no longer valid बनाती है
- कौन-सी account state settlement/assignment risk को control से बाहर ले जाती है
Risk आकार लेने से पहले उसे rewrite करें
पहला invalidation fire होते समय exact next move पहले से पता होना चाहिए।
अपनी revalidation branches तय करें:
एक revalidation path ऐसा हो सकता है:
ये execution maps हैं, narrative plans नहीं। Plan तभी usable है जब branch specific size और rule से जुड़ी हो।
- immediate scale-down branch
- partial close और wait branch
- full disarm और later re-entry branch
- Print thesis confirm करे लेकिन spread double हो, तो reduced-size continuation पर जाएँ
- Print thesis तोड़े और spread normal रहे, तो जल्दी close करें या defined hedge में rotate करें
- Invalidation window में spread भी spike करे, तो exposure close करके stand down करें
Account reality के साथ stop logic refresh करें
Account reality के बिना लिखा risk logic काम नहीं करेगा।
Event से पहले:
Revalidation के दौरान कोई account capacity limit reach हो, तो invalidation logic hypothetical नहीं रहा। Conservative branch तुरंत execute करें।
- Forced adjustments के लिए required minimum buying power शामिल करें
- Overnight funding friction के लिए available credit line शामिल करें
- Short-side assignment path होने पर hard cap शामिल करें
- Late adjustments reject या delay करने वाले broker rule को शामिल करें
हर event को post-event evidence log से close करें
First 5 minutes गुजरने पर revalidation पूरी नहीं होती।
Event reaction period के अंत में record करें:
यह log one-off event trading को repeatable strategy learning में बदलता है। इसके बिना हर event नया start लगता है। इसके साथ हर event पिछली iteration का cleaner version बनता है।
- हर invalidation category hit हुई या नहीं
- Branch action plan के अनुसार execute हुआ या नहीं
- कौन-सी branch सबसे तेज trigger हुई और क्यों
- Next iteration के लिए क्या रखना है
आम सवाल
Thesis mostly correct हो लेकिन conditions fail हों तो क्या यह real loss है?
यदि revalidation rule है तो जरूरी नहीं। Spread, time या settlement constraints बदलने पर thesis tradeable exposure में convert होने से fail हो सकती है।
Revalidation window कितनी लंबी होनी चाहिए?
कम से कम release के बाद first 15 minutes तक और आपके strike तथा expiry के लिए normal spread और depth behavior लौटने तक।
क्या revalidation automate हो सकती है?
Reminders और snapshots automate कर सकते हैं, लेकिन branch decisions को व्यक्ति या strict policy द्वारा explicit execution चाहिए क्योंकि conditions उसी minute बदल सकती हैं।
“Invalidated” और “wrong” क्या एक ही हैं?
नहीं। इसका अर्थ है setup आपकी pre-defined risk constraints को अब satisfy नहीं करता। यह opinion disagreement से ऊँची bar है।