ٹک ڈیٹا آپ کے بیک ٹیسٹ کو نہیں بچائے گا — زیادہ تر حکمتِ عملیوں کے لیے یہ اسے بدتر بناتا ہے

عام مشورہ یہ ہے: اگر آپ دیانت دار بیک ٹیسٹ چاہتے ہیں تو ٹک ڈیٹا حاصل کریں۔ میرے خیال میں زیادہ تر حکمتِ عملیوں کے لیے یہ مشورہ غلط ہے، اور اس پر عمل کرنے سے عموماً بیک ٹیسٹ بہتر ہونے کے بجائے بدتر ہو جاتا ہے۔ اس لیے نہیں کہ ٹک ڈیٹا غلط ہے — یہ آپ کو ملنے والا سب سے درست ڈیٹا ہے — بلکہ اس لیے کہ زیادہ تر لوگ اسے جس طرح استعمال کرتے ہیں، اس میں سختی کی جگہ زیادہ ریزولیوشن لے لیتی ہے، حالاں کہ یہ دونوں ایک چیز نہیں۔

خرابی کا طریقہ یہ ہے۔ ایک محقق 1-minute بارز پر حکمتِ عملی بناتا ہے، اسے اپنی پسند کا Sharpe ملتا ہے، اور کوئی — سرپرست، فورم کی پوسٹ یا اس کا اپنا کھٹکتا ہوا شک — کہتا ہے کہ بیک ٹیسٹ بے دیانت ہے کیونکہ یہ بارز پر بنا ہے۔ چنانچہ وہ پوری پائپ لائن ٹک ڈیٹا پر دوبارہ بناتا ہے: ہر ٹریڈ، ہر کوٹ اپ ڈیٹ، مائیکرو سیکنڈ تک کے ٹائم اسٹیمپ کے ساتھ۔ بیک ٹیسٹ سست ہو جاتا ہے، کوڈ تین گنا پیچیدہ ہو جاتا ہے، اور Sharpe... بمشکل بدلتا ہے، یا ایسی سمت میں بدلتا ہے جس کی کوئی وضاحت نہیں کر پاتا۔ پھر بھی وہ اسے جاری کر دیتے ہیں، کیونکہ ٹک ڈیٹا زیادہ سخت جانچ جیسا محسوس ہوتا ہے، اور سختی کا احساس خود سختی نہیں ہوتا۔

ٹک ریزولیوشن حقیقتاً کیا فراہم کرتی ہے

ٹک ڈیٹا آپ کو ہر ٹریڈ کی ترتیب اور قیمت بتاتا ہے، اور (اگر آپ اس کی قیمت ادا کریں تو) آرڈر بُک کی ہر اپ ڈیٹ بھی۔ یہ حقیقی معلومات ہیں۔ اس سے آپ قطار میں اپنی پوزیشن دوبارہ بنا سکتے ہیں، کسی قیمت کی سطح پر فل ہونے کے امکان کا اندازہ لگا سکتے ہیں، اور adverse selection دیکھ سکتے ہیں — یعنی آیا آپ کے فرضی فل کے فوراً بعد مارکیٹ آپ کے خلاف چلی۔ یہ سب بہت اہم ہے، اگر آپ کی ہولڈنگ مدت سیکنڈوں میں ناپی جاتی ہو اور آپ کا ایج ٹک کے حصوں میں ہو۔

لیکن Stratmill میں ہمیں نظر آنے والی زیادہ تر حکمتِ عملیاں — اور وہ زیادہ تر حکمتِ عملیاں بھی جو ریٹیل اور نیم پیشہ ور محقق حقیقتاً چلاتے ہیں — منٹوں سے دنوں تک پوزیشن رکھتی ہیں۔ اس مدت میں آپ کے بیک ٹیسٹ کی دیانت کا تعین اس بات سے نہیں ہوتا کہ آپ نے کسی منٹ کے اندر 40ویں ٹریڈ کا ماڈل بنایا یا نہیں۔ اصل بات یہ ہے کہ آپ نے اسپریڈ، فنڈنگ ریٹ، سلپیج کے رجحان، اور اس حقیقت کا ماڈل بنایا یا نہیں کہ آپ کا لمٹ آرڈر قطار میں دوسروں کے آرڈرز کے پیچھے ہوتا ہے۔ ٹک ڈیٹا پر آپ ان چاروں کا حساب غلط لگا سکتے ہیں، اور 1-minute بارز پر چاروں کا درست۔ ریزولیوشن اور دیانت کا آپس میں کوئی براہِ راست تعلق نہیں۔

اس آخری عدد کو لوگ اس کی اہمیت سے کم سمجھتے ہیں۔ ٹک سطح کا بیک ٹیسٹ محض ”زیادہ قطاروں والا وہی بیک ٹیسٹ“ نہیں ہوتا۔ زیادہ تر ایکسچینجز پر ٹریڈز آپ کے ڈیٹا لینے کے ٹائم اسٹیمپ کے لحاظ سے بے ترتیب ترتیب میں پہنچتی ہیں، بعد میں ان کی درستی کی جاتی ہے، وہ متعدد میچنگ انجن شَارڈز میں بٹ جاتی ہیں، اور — جن کئی پلیٹ فارمز سے ہم نے ڈیٹا لیا ہے — کنکشن دوبارہ جڑنے پر کبھی کبھار پوری طرح دہرائی جاتی ہیں یا غائب ہو جاتی ہیں۔ ایسی ٹک پائپ لائن بنانا جو محض زیادہ باریک ہونے کے بجائے، حقیقتاً اچھی طرح بنائی گئی بار پائپ لائن سے زیادہ درست ہو، ایک حقیقی سسٹمز پروجیکٹ ہے۔ زیادہ تر ٹیمیں یہ پروجیکٹ نہیں کرتیں۔ وہ کسی وینڈر کی ٹک فائل بیک ٹیسٹر کو دیتی ہیں اور کام ختم سمجھتی ہیں۔ یوں وہ معلوم اور دستاویزی اندازوں (OHLCV) کے مجموعے کو ایک نامعلوم اور غیر دستاویزی مجموعے سے بدل دیتی ہیں (یعنی خراب دن میں وینڈر کا ٹک ڈیٹا درست کرنے کا جو بھی طریقہ ہو)۔

وہ شور جو آپ خرید رہے ہیں

ایک دوسرا خرچ ہے، جس کا تعلق انجینئرنگ سے کم اور شماریات سے زیادہ ہے۔ انفرادی ٹریڈ پرنٹس بولی اور طلب کے درمیان اچھلتے رہتے ہیں — اسے بولی اور طلب کا اتار چڑھاؤ کہتے ہیں، اور یہ 1980 کی دہائی سے مارکیٹ مائیکرو اسٹرکچر کے لٹریچر میں ایک معروف اثر ہے۔ اگر آپ کا سگنل چند سیکنڈ سے بھی تیز کام کرتا ہے تو ٹک سطح کا بیک ٹیسٹ آپ کو وہاں ساخت دکھا سکتا ہے جہاں دراصل صرف یہی اتار چڑھاؤ ہو۔ میں نے ایک محقق کو ٹریڈ بہ ٹریڈ ڈیٹا میں اوسط کی طرف واپسی کا ایک خوب صورت پیٹرن ڈھونڈتے دیکھا، جو 5-second بارز میں ڈیٹا جمع کرتے ہی غائب ہو گیا، کیونکہ وہ پیٹرن دراصل بولی اور طلب کا یہی اتار چڑھاؤ تھا۔

ایک quant جسے میں جانتا ہوں — پہلے مارکیٹ میکنگ کرتا تھا، اب کرپٹو کا ایک چھوٹا پورٹ فولیو چلاتا ہے — نے بات یوں سمجھائی: ”ٹک ڈیٹا ایک میگنیفائنگ گلاس ہے۔ اسے اپنے ایج پر رکھیں تو بہت خوب۔ اپنے شور پر رکھیں گے تو چھ ماہ اپنے شور کا نہایت خوب صورت ماڈل بنانے میں گزار دیں گے۔“ اب وہ تقریباً ہر چیز کا بیک ٹیسٹ 1-second یا 1-minute بارز پر کرتا ہے، اور صرف اس مخصوص سوال کے لیے ٹک ڈیٹا استعمال کرتا ہے کہ ”کیا یہ لمٹ آرڈر حقیقت میں فل ہوتا؟“ یہ فل ہونے کے امکان کا سوال ہے، سگنل کا نہیں۔

یہی تقسیم درست سوچ ہے، اور ٹک ڈیٹا کے زیادہ تر حامی اسے نظرانداز کرتے ہیں۔ ٹک ڈیٹا کا دیانت دارانہ استعمال پوری حکمتِ عملی کو اس پر چلانا نہیں، بلکہ اسے نپی تلی جگہ پر صرف ایک دو ایسے سوالات کے لیے استعمال کرنا ہے جن کا جواب بار ڈیٹا واقعی نہیں دے سکتا۔

ناقدین کہاں درست ہیں

یہ سب کہنے کے بعد، کچھ حکمتِ عملیاں ایسی ہیں جن کے لیے ٹک ڈیٹا لازمی ہے، اور اس حقیقت سے انکار کرنا بات کو بڑھا چڑھا کر پیش کرنا ہوگا۔ اگر آپ مارکیٹ میکنگ جیسی کوئی حکمتِ عملی چلا رہے ہیں — دونوں جانب کوٹ دینا، ہر ٹک پر انوینٹری سنبھالنا، کسی مخصوص قیمت کی سطح پر قطار میں اپنی جگہ کا خیال رکھنا — تو بار ڈیٹا آپ کے مسئلے کی نمائندگی ہی نہیں کر سکتا۔ اس حکمتِ عملی کی پوری معاشیات منٹ کے اندر ہے، منٹوں کے درمیان نہیں۔ یہی بات پلیٹ فارمز کے درمیان latency-sensitive شماریاتی ثالثی پر بھی لاگو ہوتی ہے، جہاں اصل سوال یہ ہے کہ ”پہلے کون سی ٹریڈ ہوئی؟“، اور بڑی مقدار کے آپشنز کی مارکیٹ میکنگ پر بھی، جہاں ٹریڈ پرنٹ کے بعد adverse selection کے چند سو milliseconds ہی پورا کھیل ہوتے ہیں۔ ان حالات میں بارز پر بیک ٹیسٹ کرنا محض سادہ کاری نہیں، بلکہ بنیادی نوعیت کی غلطی ہے — آپ اپنی حکمتِ عملی کے کم ریزولیوشن ورژن کو نہیں پرکھ رہے، بلکہ ایک مختلف حکمتِ عملی کو آزما رہے ہیں جس کا نام اصل حکمتِ عملی جیسا ہے۔

تو دعویٰ یہ نہیں کہ ”ٹک ڈیٹا برا ہے۔“ بات یہ ہے کہ اس کی طرف لپکنا اکثر ایک مشکل اور کم دلکش سوال سے بچنے کا طریقہ ہوتا ہے: کیا میرا لاگت کا ماڈل درست ہے؟ کیا فل ہونے کا میرا مفروضہ درست ہے؟ کیا یہ آرڈر حقیقتاً فل ہوتا، یا میں ایسی قیمت پر فل فرض کر رہا ہوں جو بُک نے کبھی پیش ہی نہیں کی؟ اگر آپ قطار میں اپنی جگہ اور اسپریڈ کے بارے میں دیانت دار ہوں تو ان سوالوں کے جواب 1-minute یا حتیٰ کہ 1-second بارز پر بھی دیے جا سکتے ہیں۔ ٹک ڈیٹا ان کے زیادہ دقیق جواب دیتا ہے، انجینئرنگ کی کئی گنا لاگت پر، ان حکمتِ عملیوں کے لیے جہاں اس اضافی دقت سے نتیجہ نہیں بدلتا۔ اضافی محنت وہاں کریں جہاں حکمتِ عملی کی مدت واقعی اس کا تقاضا کرتی ہے، اور باقی ہر جگہ اسے چھوڑ دیں — دستیاب باریک ترین ڈیٹا کو صرف اس لیے چننے کے بجائے کہ باریک ڈیٹا زیادہ سخت جانچ جیسا محسوس ہوتا ہے، یہ تحقیقی ٹیم کے وقت کا بہتر استعمال ہے۔