Prediction market backtest सही दिखने वाला ticker और सही price history इस्तेमाल कर सकता है, फिर भी कॉन्ट्रैक्ट गलत हो सकता है। इस गलती को पकड़ना आसान नहीं, क्योंकि market के नाम छोटे होते हैं, event pages अपडेट होते रहते हैं, और YES share हमेशा 0 और 1 के बीच की कीमत जैसा दिखता है।
एक काल्पनिक market लें, जिसका नाम है “क्या Clean Transit Act पास होगा?” News signal मिलने के बाद एक strategy 0.42 पर YES खरीदती है। बाद में backtest उस position का मूल्य 1.00 मान लेता है। इस जीत पर भरोसा करने से पहले मैं जानना चाहूँगा कि कॉन्ट्रैक्ट ने ठीक-ठीक क्या वादा किया था: कौन-सा बिल, “पास” होने का क्या मतलब था, समय-सीमा क्या थी, और नतीजे का फैसला किस स्रोत ने किया।
शीर्षक: “क्या Clean Transit Act पास होगा?”
शीर्षक दिखाने के लिए लिखा गया टेक्स्ट है, स्थायी इंस्ट्रूमेंट पहचान नहीं। दो markets के शब्द लगभग एक जैसे हो सकते हैं, लेकिन वे अलग-अलग विधायी सत्रों, संशोधित बिलों या समय-सीमाओं से जुड़े हो सकते हैं। Venue underlying terms बदले बिना market का शीर्षक स्पष्टता के लिए बदल भी सकता है।
इसलिए backtest में position को venue के अपरिवर्तनीय market या contract ID से जोड़ना चाहिए, और rules का पूरा टेक्स्ट तथा उसका version भी सहेजना चाहिए। अगर ऐतिहासिक data में सिर्फ शीर्षक और ticker हैं, तो यह साबित नहीं किया जा सकता कि price series उसी कॉन्ट्रैक्ट की है जिसे आपकी strategy ट्रेड करना चाहती थी।
| पहचान का फ़ील्ड | इससे क्या तय होता है | छोड़ने पर क्या चूक हो सकती है |
|---|---|---|
| Venue और market ID | सूचीबद्ध विशिष्ट market | मिलते-जुलते शीर्षक आपस में जुड़ जाते हैं |
| Rules version | वे शर्तें जिन पर प्रतिभागियों ने सहमति दी | बाद में किया गया बदलाव पुराने trades पर लागू हो जाता है |
| Outcome token ID | ट्रेड किया जा रहा YES या NO दावा | YES और NO की कीमतें बदल जाती हैं या एक साथ जोड़ दी जाती हैं |
| Resolution source | नतीजा तय करने के लिए इस्तेमाल किया गया सबूत | Backtest किसी दूसरे प्राधिकरण को मान लेता है |
नियम: “पास” होने का क्या मतलब है?
मान लीजिए नियम कहता है कि बिल 30 जून तक House और Senate से पास हो, फिर राष्ट्रपति उस पर हस्ताक्षर करें। अगर backtest किसी भी एक सदन से पास होने को सफलता मानता है, तो दाँव बदल गया। अगले सत्र में उसी नाम वाले बिल को गिनना भी दाँव बदल देता है।
नतीजा तय करने के असली मानदंडों को ऐसे पढ़ें जैसे वे लागू की जाने वाली शर्तें हों। समय-सीमा और timezone, योग्य घटना, अपवाद और नामित resolution source दर्ज करें। अस्पष्टता भी मायने रखती है: अगर venue के नियम किसी संभावित स्थिति का नतीजा तय नहीं करते, तो ऐतिहासिक नतीजे से मेल खाने वाली व्याख्या चुपचाप न चुनें।
इस काम का एक बेहद साधारण हिस्सा है: कुछ दिलचस्प होने से पहले rules page सहेज लेना। Resolution के बाद ही कैप्चर किया गया पेज अंतिम शब्दावली दिखा सकता है, जबकि आपकी strategy ने किसी पुराने version के तहत entry ली हो।
समय-क्रम: strategy को जानकारी कब मिल सकती थी?
अब मान लें कि नियम सही हैं और news signal 14:05 UTC पर आया। Historical feed कहता है कि 14:05 पर 0.42 की कीमत पर trade हुआ। सिर्फ उस timestamp से यह पता नहीं चलता कि trade से पहले जानकारी उपलब्ध थी या नहीं, दर्ज की गई कीमत उसके बाद लागू हो सकती थी या नहीं, और bar किसी quote, trade या interval के सारांश को दिखाता है।
Signal के उपलब्ध होने का समय और market event का समय अलग-अलग रखें। फिर order को उस समय रखें जब strategy उसकी गणना करके उसे भेज सकती थी। कम गतिविधि वाले market में अगला दर्ज trade कई मिनट बाद हो सकता है; इससे यह साबित नहीं होता कि आपके order को वही कीमत मिली होती।
कीमत: quote का मतलब fill नहीं होता
0.42 पर YES का मतलब है प्रति share 42 सेंट की कीमत, लेकिन केवल last-trade series में spread और उपलब्ध मात्रा छिप जाती है। अगर सबसे अच्छा ask 20 shares के लिए 0.45 है, तो 100 shares की simulated खरीद पूरी की पूरी 0.42 पर नहीं हो सकती। Order book में आगे की कीमतों पर खरीदना पड़ सकता है, इंतज़ार करना पड़ सकता है या order पूरा न हो।
Prediction-market की कीमतें हिसाब में एक आसान रास्ता भी सुझाती हैं: 0.42 को 42% संभावना मान लेना और यह भूल जाना कि entry पर इतनी नकदी भी खर्च होती है। 100-share YES position की लागत fees से पहले $42 है। अगर इसका settlement $1 पर होता है, तो कुल प्राप्ति $100 होगी; अगर $0 पर होता है, तो कुछ नहीं। Fees, partial fills और venue के हिसाब से settlement की प्रक्रिया भी ledger में शामिल होनी चाहिए।
Settlement: trade किस चीज़ से बंद होता है?
Backtest अक्सर position को आखिरी market price पर बंद कर देता है। लेकिन resolution तक रखे गए कॉन्ट्रैक्ट का भुगतान नियमों के अनुसार होता है, और उसकी आखिरी quoted price पुरानी, बहुत दूर-दूर के bid-ask वाली या अंतिम भुगतान से काफी अलग हो सकती है। Resolution को एक अलग घटना मानें: outcome, settlement का समय और नकदी का लेन-देन contract record से आना चाहिए।
अगर venue के नियम invalid या विवादित नतीजे का प्रावधान रखते हैं, तो उसका भी हिसाब रखें। ऐसी स्थिति में दाँव की रकम लौट सकती है, अलग राशि मिल सकती है या भुगतान में देरी हो सकती है। हर resolution की राह को binary payout की धारणा नहीं दिखा सकती।
Backtest पर फैसला
इस उदाहरण में, मैं बताई गई जीत तभी स्वीकार करूँगा जब अपरिवर्तनीय market ID, entry के समय लागू rules version, YES token, signal के उपलब्ध होने का समय, लागू किए जा सकने वाले asks और उनकी मात्रा, fees और दर्ज settlement का मिलान हो जाए। अगर price archive इन जाँचों का आधार नहीं दे सकता, तो ईमानदार नतीजा संभावित परिणामों की एक सीमा या अप्रमाणित नतीजा होगा।
एक छोटे-से trade के लिए यह सख्त लग सकता है। यही गलत डेटा-जोड़ हजारों markets में दोहराएँ, तो backtest उन कॉन्ट्रैक्ट्स का सावधानीपूर्वक मापन बन सकता है जिन्हें आपकी strategy ने कभी ट्रेड ही नहीं किया।
← सभी पोस्ट
