Macro event recovery protocol checklist
Macro releases और release-linked volatility breaks के बाद केवल outcomes monitor नहीं, risk control recover करने के लिए disciplined post-spike protocol चलाएँ
सीधा जवाब
Macro-event recovery protocol spike के बाद usable baseline फिर बनाने की प्रक्रिया है, इससे पहले कि आप position रखें, hedge करें या close करें। यह initial reaction को next decision से अलग करता है ताकि once-valid thesis unmanaged risk बनने से पहले नई volatility, liquidity और account constraints जाँची जा सकें।
Post-event period को separate operating phase मानें
First trade setup आपका पूरा workflow नहीं है। Workflow को तीन phases के आसपास बनाएं:
अधिकांश teams phase two में टूटती हैं और phase three अपने-आप होने का इंतजार करती हैं। Recovery automatic नहीं है। यह fixed checks वाली routine है।
Entry से पहले strict recovery timer तय करें:
यह “we will decide later” वाले common trap को रोकता है।
- pre-event readiness
- event reaction execution
- post-event recovery
- recovery कब शुरू होती है, जैसे release के +3 minutes बाद या first-print normalization के बाद
- recovery कब खत्म होती है, जैसे first normal-depth window close होने पर
- recovery conditions पूरी न हों तो कौन क्या करेगा
Publication के तुरंत बाद fresh baseline capture करें
Size रखने, rotate करने या close करने से पहले नया baseline चाहिए।
Capture करें:
Pre-release का old baseline भरोसेमंद न मानें। Macro events इसे seconds में invalidate कर सकते हैं।
Spread, depth और IV सभी बदलें लेकिन अलग directions में, तो recovery decision के लिए least favorable condition उपयोग करें। Recovery survivability के बारे में है, best-case outcome के बारे में नहीं।
- Current chain पर spread और depth
- Strike के अनुसार implied volatility level
- Time-to-expiry liquidity drift
- Margin और assignment surprises के विरुद्ध account constraints
किसी भी नए action से पहले three-step triage चलाएं
Size add, keep या hedge add करने से पहले क्रम में triage चलाएँ।
1) Execution viability - क्या posted spread पर अभी move कर सकते हैं? - क्या pre-set shock line से आगे spread push किए बिना rehedge कर सकते हैं? - क्या routing अभी भी order changes accept कर रही है?
2) Thesis relevance - क्या नया print आपकी directional assumption को support करता है? - क्या उसने direction नहीं, केवल timing बदली है? - New IV regime के लिए adjust करने के बाद thesis अभी true है?
3) Loss geometry - Spread धीरे normalize हो तो current risk अभी भी budget के भीतर है? - नहीं है तो exposure controllable रखने वाली minimum risk geometry क्या है?
कोई step fail हो तो recovery action mandatory है। Recovery action optional नहीं है।
Binary decision नहीं, rollback ladder उपयोग करें
Binary choices delay कराती हैं। Ladder order देती है।
Ladder thresholds को numbers में एक बार document करें और consistently execute करें।
Visual चाहिए तो ऐसे सोचें:
हर transition का hard trigger हो, mood-based timing नहीं।
- Depth weak हो लेकिन thesis valid हो, तो size घटाएँ और lower-risk layer पर wait करें
- Thesis weak हो लेकिन spread reasonable हो, तो close करें और postpone करें
- Spread और thesis दोनों fail हों, तो neutral reset करें और selected legs पहले liquidate करें
- current risk layer -> next lower layer -> fully safe layer
Protocol green होने के बाद ही re-open करें
Protocol तभी complete है जब ये बातें true हों:
कोई fail हो तो position को reduced या flat recovery state में रखें।
Recovery weakness नहीं है। यह high-volatility moments को repeatable opportunities में बदलने वाला mechanism है।
- Spread और depth pre-event operating window के भीतर लौट आए हों
- Loss geometry original plan के भीतर हो
- Thesis और account state दोनों फिर aligned हों
- Execution history के बाद re-entry rules अभी valid हों
आम सवाल
Market calm दिखे तो recovery skip कर सकते हैं?
केवल तब जब post-event baseline आपके pre-set window में लौट आया हो। Spread और depth अभी unstable हों तो calmness short-lived हो सकती है।
Recovery आम तौर पर कितनी देर लेती है?
कोई fixed clock नहीं है। Normal depth recovery और stable execution capacity से जुड़ा hard end point उपयोग करें।
सबसे dangerous recovery mistake क्या है?
Execution baseline फिर बनाए बिना बेहतर narrative का इंतजार करना। Thesis सही लग सकती है जबकि risk conditions पहले ही invalid हो चुकी हों।
क्या automatically re-enter कर सकता हूँ?
Auto-reentry forbidden रहना चाहिए, जब तक spread, depth और execution checks green न हों और rollback thresholds meet न हों।