पहले नुकसान के बाद अगली पोज़िशन खुल जाए, तो ड्रॉडाउन केवल बाज़ार की चाल नहीं रहता। वह नियंत्रण की समस्या बन जाता है, क्योंकि ट्रेडर को नई जानकारी समझने, जोखिम घटाने या रणनीति रोकने का मौका ही नहीं मिला।
1 अगस्त 2012 को अमेरिका में Knight Capital के सिस्टम ने शेयर बाज़ार खुलते ही अनचाहे ऑर्डर भेजने शुरू कर दिए। कंपनी के पास यह तय करने के लिए बहुत कम समय था कि सामने सामान्य ट्रेडिंग नुकसान है या अपने ही सिस्टम से पैदा हुआ संकट।
जब हर नया ऑर्डर पुरानी धारणा को दोहराता है
Knight Capital उस समय अमेरिकी शेयर बाज़ार की बड़ी ट्रेडिंग फर्मों में थी। अमेरिकी Securities and Exchange Commission के आदेश के अनुसार, नए सॉफ़्टवेयर की तैनाती में हुई गलती ने एक पुराने फ़ंक्शन को सक्रिय कर दिया। सिस्टम ने लगभग 45 मिनट में लाखों ऑर्डर भेजे और कंपनी को करीब 44 करोड़ डॉलर का नुकसान हुआ।
यह घटना किसी एक खराब ट्रेड तक सीमित नहीं रही। सिस्टम लगातार नए ऑर्डर बनाता रहा, जबकि मूल समस्या की पहचान और रोकथाम अभी बाकी थी। हर अगला ऑर्डर कंपनी के जोखिम को बढ़ा रहा था।
रिटेल ट्रेडिंग में रकम और गति अलग हो सकती है, लेकिन नियंत्रण की बुनियादी समस्या वही है। पहला नुकसान आपकी बाज़ार संबंधी धारणा पर सवाल उठाता है। उससे पहले कि आप उस सवाल की जाँच करें, बॉट दूसरी पोज़िशन खोल देता है। अब आपका नुकसान केवल गलत दिशा चुनने से नहीं बना। उसमें बिना समीक्षा दोहराए गए निर्णय का जोखिम भी जुड़ गया।
दूसरी पोज़िशन कौन-सी नई जानकारी लेकर आई?
मान लीजिए किसी रणनीति ने ₹50,000 की पूँजी पर पहली पोज़िशन में ₹500 का नियोजित जोखिम लिया। स्टॉप लग गया। यह नुकसान अपने आप में रणनीति की विफलता साबित नहीं करता। वैध सेटअप भी असफल होते हैं।
इसके तुरंत बाद उसी संकेत परिवार पर दूसरी पोज़िशन खुलती है। अब कुछ सवाल पूछने जरूरी हैं:
- क्या दूसरी एंट्री स्वतंत्र सेटअप थी, या पहली धारणा की पुनरावृत्ति?
- क्या बाज़ार की अस्थिरता बदल चुकी थी?
- क्या दोनों पोज़िशन एक ही दिशा या एक ही जोखिम कारक पर निर्भर थीं?
- क्या कुल खुला जोखिम पहले से तय सीमा के भीतर था?
- क्या पहला स्टॉप रणनीति की सामान्य लागत था, या बाज़ार की स्थिति बदलने का संकेत?
यदि बॉट ने ट्रेडर के उत्तर देने से पहले दूसरी एंट्री कर दी, तो पोज़िशन साइजिंग का हिसाब अधूरा है। हर ट्रेड पर जोखिम सीमा होना पर्याप्त नहीं। लगातार पोज़िशनों के बीच समीक्षा का अधिकार भी जोखिम नियंत्रण का हिस्सा है।
यहीं approval gate उपयोगी होता है। AI संकेत बना सकता है, प्रस्तावित एंट्री, स्टॉप और पोज़िशन साइज दिखा सकता है। अगला आदेश तभी जाना चाहिए जब इंसान देख ले कि पहली हानि के बाद भी मूल धारणा बची हुई है। अनुमोदन का मतलब संकेत सही घोषित करना नहीं है। इसका मतलब है कि नई पूँजी लगाने से पहले निर्णय दोबारा देखा गया।
ड्रॉडाउन को दो हिस्सों में दर्ज करें
ट्रेडिंग जर्नल में केवल कुल नुकसान लिखने से नियंत्रण की समस्या छिप सकती है। ड्रॉडाउन को कम से कम दो हिस्सों में बाँटें:
- रणनीति से हुआ नुकसान: नियमों के भीतर लिया गया ट्रेड असफल हुआ।
- नियंत्रण से हुआ नुकसान: समीक्षा से पहले अतिरिक्त पोज़िशन खुली, जोखिम सीमा बदली या एक ही धारणा पर एक्सपोज़र बढ़ा।
यह वर्गीकरण परिणाम बदलता नहीं, लेकिन निदान बदल देता है। यदि दस ट्रेड नियमों के भीतर असफल हुए, तो रणनीति, बाज़ार की अवस्था और बैकटेस्ट की जाँच चाहिए। यदि नुकसान का बड़ा हिस्सा जल्दबाज़ दोहराव से आया, तो पहले ऑर्डर प्रवाह और approval gate सुधारना चाहिए।
दस लाल जल्दबाज़ ट्रेड, और जर्नल ने किस गहरे नुकसान की ओर इशारा किया इसी फर्क को जर्नल के स्तर पर दिखाता है। बैकटेस्ट में भी देखें कि लगातार संकेतों को स्वतंत्र ट्रेड माना गया है या एक ही बाज़ार धारणा का जुड़ा हुआ जोखिम।
अगला नियम पहले से लिखें: स्टॉप के बाद कितनी देर या किस नई पुष्टि तक कोई दूसरी पोज़िशन मंज़ूर नहीं होगी। समय अकेला पर्याप्त मापदंड नहीं हो सकता। बेहतर नियम यह बताएगा कि दोबारा प्रवेश से पहले कौन-सी जानकारी बदलनी चाहिए।
रोकना भी ट्रेडिंग निर्णय है
Knight Capital की घटना का सबक केवल खराब सॉफ़्टवेयर से बचना नहीं है। असली सबक यह है कि गलत प्रक्रिया को तेज़ी से दोहराने वाला सिस्टम हर नए आदेश के साथ निदान कठिन और नुकसान बड़ा कर सकता है।
ट्रेडिंग बॉट की गति तभी उपयोगी है जब रोकने का अधिकार उससे अधिक मजबूत हो। पहला नुकसान रणनीति की लागत हो सकता है। दूसरी पोज़िशन यह दिखाती है कि नियंत्रण वास्तव में किसके पास है।
हर ड्रॉडाउन समीक्षा में यह प्रश्न जोड़ें: पहले नुकसान और अगले आदेश के बीच किस इंसान ने क्या जाँचा? यदि उत्तर “किसी ने नहीं” है, तो पहले रणनीति बदलने की जरूरत नहीं। पहले नियंत्रण वापस लेने की जरूरत है।
शैक्षिक सामग्री, वित्तीय सलाह नहीं।
टिप्पणियाँ
अभी कोई टिप्पणी नहीं।