रणनीति के कोड की एक भी पंक्ति बदले बिना ऑप्शंस बैकटेस्ट बदल सकता है। कोई वेंडर खराब कोट सुधारता है, देर से आया ट्रेड जोड़ता है, कॉन्ट्रैक्ट मेटाडेटा संशोधित करता है या क्रॉस्ड मार्केट के लिए अपना फ़िल्टर बदलता है। आप उन्हीं तारीखों पर दोबारा रन करते हैं और आपको अलग फिल, अलग पोज़िशन, शायद अलग Sharpe मिलता है। ज़रूरी नहीं कि यह रणनीति में कोई बग हो। दरअसल, रणनीति को जिस डेटा के आधार पर परखा गया था, उसमें बदलाव हुआ है।
ऑप्शंस बैकटेस्ट को दोहराने योग्य बनाने के लिए, मार्केट डेटा को संस्करण वाले इनपुट की तरह लें। दर्ज करें कि आपने कौन-सा स्नैपशॉट इस्तेमाल किया, हर फ़ैसले को प्रभावित करने वाले मूल ऑब्ज़र्वेशन सुरक्षित रखें, और नए कुल नतीजे पर भरोसा करने से पहले कॉन्ट्रैक्ट और टाइमस्टैम्प के स्तर पर बदलावों की तुलना करें।
कोड वही रहने पर भी मेरा ऑप्शंस बैकटेस्ट क्यों बदल गया?
सुधारों के प्रति ऑप्शंस रिकॉर्ड असामान्य रूप से संवेदनशील होते हैं, क्योंकि किसी कॉन्ट्रैक्ट के ट्रेड किए जा सकने का आभास कई फ़ील्ड के एक साथ बदलने पर निर्भर करता है: बिड, आस्क, साइज़, अंडरलाइंग प्राइस, एक्सपायरी, स्ट्राइक और कॉन्ट्रैक्ट का मल्टिप्लायर या डिलिवरेबल। कोट में सुधार किसी दिखते हुए अवसर को क्रॉस्ड मार्केट में बदल सकता है। मेटाडेटा में सुधार से पोज़िशन के मल्टिप्लायर का अर्थ बदल सकता है।
मान लें कि एक रणनीति तब कॉल खरीदती है जब आस्क $2.00 से कम हो। पहली बार डेटा लोड करने पर, 10:14 का कोट $1.95 आस्क, $1.90 बिड और साइज़ 5 है। बाद में, एक्सचेंज के देर से आए संदेश का मिलान करने के बाद वेंडर का संशोधित डेटा आस्क को $2.05 कर देता है। एक ऑब्ज़र्वेशन से सिग्नल बदल जाता है। अगर उस कॉन्ट्रैक्ट में उस दिन रणनीति का सिर्फ़ यही एक ट्रेड था, तो डेटा में मामूली सुधार भी दिन के रिटर्न पर हावी हो सकता है।
कोट फ़िल्टरिंग भी मायने रखती है। वेंडर पुराने कोट हटा सकते हैं, क्रॉस्ड मार्केट निकाल सकते हैं या टाइमस्टैम्प को अलग ढंग से सामान्यीकृत कर सकते हैं। ये नीतियाँ उचित हो सकती हैं, लेकिन ये डेटासेट की पहचान का हिस्सा हैं। “SPY ऑप्शंस, जनवरी से मार्च तक” कहने भर से दोहराने योग्य हिस्ट्री तय नहीं होती।
ऑप्शंस डेटा विंटेज क्या है?
डेटा विंटेज, किसी खास रिसर्च रन के लिए उपलब्ध ऐतिहासिक ऑब्ज़र्वेशन का सटीक संस्करण होता है। वेंडर और डेटासेट का नाम, डेटा लेने का समय, तारीखों की सीमा, स्कीमा संस्करण और डेटा साफ़ करने या फ़िल्टर करने के नियम दर्ज करें। अगर वेंडर स्नैपशॉट ID या संशोधन टाइमस्टैम्प देता है, तो उन्हें भी सहेजें।
हर सिम्युलेटेड फ़ैसले के लिए इतना विवरण रखें कि आप बता सकें: किस कॉन्ट्रैक्ट पर विचार किया गया, कौन-सा कोट चुना गया, वह कोट कब प्रकाशित हुआ या प्राप्त किया गया, और किस नियम के तहत वह योग्य ठहरा? मूल रिकॉर्ड और उससे निकला रिकॉर्ड, दोनों मायने रखते हैं। स्रोत टाइमस्टैम्प के बिना साफ़ किया हुआ NBBO यह छिपा सकता है कि कोट पुराना था या सिम्युलेटेड फ़ैसले के बाद आया था।
| सहेजने वाला रिकॉर्ड | यह क्यों मायने रखता है | उदाहरण |
|---|---|---|
| स्रोत स्नैपशॉट | रन में इस्तेमाल हुई हिस्ट्री की पहचान करता है | वेंडर संशोधन ID और डेटा लेने का टाइमस्टैम्प |
| कोट का स्रोत-विवरण | चुने गए मार्केट को समझाता है | एक्सचेंज, घटना का समय, प्राप्ति का समय, बिड/आस्क और साइज़ |
| कॉन्ट्रैक्ट की शर्तें | बताती हैं कि ऑप्शन किस चीज़ का प्रतिनिधित्व करता था | स्ट्राइक, एक्सपायरी, मल्टिप्लायर और डिलिवरेबल |
| डेटा साफ़ करने की नीति | दिखाती है कि कौन-से ऑब्ज़र्वेशन हटाए गए | पुराने कोट की समय-सीमा और क्रॉस्ड कोट को संभालने का तरीका |
कैसे जाँचूँ कि वेंडर के संशोधन से मेरे नतीजे बदले हैं या नहीं?
दोनों स्नैपशॉट पर एक ही रणनीति और कॉन्फ़िगरेशन चलाएँ। पहले तारीख के अनुसार योग्य ऑब्ज़र्वेशन और कॉन्ट्रैक्ट की संख्या की तुलना करें। फिर फ़ैसलों और फिल की तुलना करें: कौन-से सिग्नल आए या गायब हुए, कौन-सा कोट बदला और क्या नए रिकॉर्ड से मॉडल किया गया एक्ज़ीक्यूशन प्राइस बदला।
कुल रिटर्न पर ही न रुकें। ट्रेड की संख्या, एंट्री और एग्ज़िट प्राइस, अस्वीकृत सिग्नल और केवल एक विंटेज में मौजूद ट्रेडों से आए P&L के अनुपात में बदलाव दर्ज करें। व्यक्तिगत ट्रेड बदलते रहने पर भी रन का Sharpe मिलता-जुलता रह सकता है; मुख्य आँकड़ा यह नहीं बताएगा कि उसके नीचे की हिस्ट्री बदल गई।
काम की जाँच के लिए रणनीति, शुल्क और एक्ज़ीक्यूशन की मान्यताएँ स्थिर रखें। अगर एक साथ कई चीज़ें बदलेंगी, तो आपको पता नहीं चलेगा कि अंतर वेंडर के सुधार से आया या आपके अपने प्रयोग से।
क्या मुझे हमेशा ऑप्शंस हिस्ट्री का सबसे नया संस्करण इस्तेमाल करना चाहिए?
जब लक्ष्य वेंडर के मौजूदा सबसे अच्छे पुनर्निर्माण से काम करना हो, तो सबसे नई हिस्ट्री इस्तेमाल करें। जब आपको पहले के नतीजे दोहराने हों या समझना हो कि उस समय आपका रिसर्च सिस्टम क्या जानता था, तो पुराना स्नैपशॉट रखें। ये दोनों अलग सवालों के जवाब देते हैं।
समय-बिंदु आधारित रिसर्च में, सुधारा गया रिकॉर्ड अब अधिक सटीक हो सकता है, फिर भी उस समय रणनीति के लिए उपलब्ध नहीं था। जहाँ संभव हो, प्रकाशन और प्राप्ति के समय सुरक्षित रखें; वरना सीमा को साफ़-साफ़ लिखें। आज का पुनर्निर्माण अपने-आप ऐतिहासिक सूचना-संग्रह नहीं बन जाता।
ऑप्शंस बैकटेस्ट बदलने पर पहला सवाल होना चाहिए, “कौन-से ऑब्ज़र्वेशन बदले?” “कौन-सा रन सही है?” यह सवाल तब आएगा, जब आप पहले वाले का जवाब दे सकें।
हर बैकटेस्ट के साथ मुझे क्या सहेजना चाहिए?
नतीजों के साथ एक संक्षिप्त मेनिफ़ेस्ट सहेजें: डेटा प्रोवाइडर और स्नैपशॉट, डेटा लेने का समय, स्कीमा और डेटा साफ़ करने के संस्करण, कॉन्ट्रैक्ट मेटाडेटा का स्रोत, रणनीति कमिट, एक्ज़ीक्यूशन की मान्यताएँ और रन कॉन्फ़िगरेशन। हर ट्रेड के साथ उन कोट रिकॉर्ड की कड़ी रखें जिनके आधार पर वह लिया गया।
यह छोटा-सा रिकॉर्ड रहस्यमय दोबारा रन को ऐसे बदलावों में बदल देता है जिनकी जाँच की जा सकती है। ऑप्शंस हिस्ट्री में सुधार होते रहेंगे। आपकी रिसर्च प्रक्रिया को हर सुधार साफ़ दिखाना चाहिए, ताकि बेहतर आर्काइव प्रयोग को चुपचाप दोबारा लिखे बिना सबूतों को बेहतर बनाए।
← सभी पोस्ट
