بک‌تست قبول شد؛ استراتژی کاغذی ۳۷٪ سفارش‌هایش را از دست داد.

بک‌تست ما از 100 سفارش ثبت‌شده، 91 سفارش را پرشده شمرد. در معاملات کاغذی، همان استراتژی 63 سفارش را پر کرد. میانه زمان بین سیگنال تا تأیید دریافت سفارش 84 میلی‌ثانیه بود و 12 مورد از سفارش‌های کاغذیِ پرنشده، سفارش‌های لیمیتی بودند که بک‌تست فرض کرده بود به‌محض رسیدن قیمت به آن‌ها پر شده‌اند.

این شکاف 28 واحدی شبیه مشکل استراتژی به نظر می‌رسید، تا وقتی که تصمیم‌های سفارش‌گذاری را از تصمیم‌های مربوط به پرشدن سفارش جدا کردیم. استراتژی در هر دو اجرا تقریباً همان سمت، اندازه و قیمت را انتخاب کرد. مسیر اجرا تفاوت داشت: بعضی سفارش‌ها دیر رسیدند، بعضی باز ماندند و بعضی وقتی به بازار رسیدند که قیمت از آن‌ها عبور کرده بود.

هم‌خوانی سفارش‌ها بین بک‌تست و اجرای کاغذی یعنی چه؟

هم‌خوانی یعنی بک‌تست و سامانه کاغذی با اطلاعات یکسانِ در دسترس، تصمیم‌های قابل‌مقایسه‌ای بگیرند و سپس تفاوت مدل‌های اجرایی خود را به‌صراحت در محاسبات لحاظ کنند. این به آن معنا نیست که هر پرشدن شبیه‌سازی‌شده باید با یک پرشدن کاغذی مطابقت داشته باشد. کندل‌های تاریخی نمی‌توانند جایگاه سفارش در صف را بازسازی کنند و ممکن است محل اجرای کاغذی از مدلی برای تطبیق سفارش استفاده کند که با صرافی واقعی فرق دارد.

پرسش کاربردی‌تر این است: برای هر سفارشی که استراتژی قصد ثبتش را داشت، می‌توانید توضیح دهید بعدش چه اتفاقی افتاد؟ تعداد معاملات و بازده نهایی اطلاعات زیادی را پنهان می‌کنند. برای هر تصمیم، رکوردی یکپارچه نگه دارید و یک شناسه پایدار تصمیم استراتژی را در رویدادهای سیگنال، سفارش، تأیید دریافت، لغو و پرشدن ثبت کنید.

چرا سفارش‌های لیمیتی که قیمت به آن‌ها رسید، این‌همه مورد از دست‌رفته را تشکیل می‌دادند؟

بک‌تست ما از کندل‌های 1 دقیقه‌ای استفاده می‌کرد. اگر قیمت لیمیت در بازه سقف و کف یک کندل قرار می‌گرفت، سفارش را پرشده علامت می‌زد. این قاعده می‌گوید آیا بازار در مقطعی از آن دقیقه با آن قیمت معامله کرده است یا نه. اما نمی‌گوید سفارش ما آن زمان فعال بوده یا نه، در صف نفر اول بوده یا نه، یا پس از رسیدن سفارش، حجم کافی معامله شده یا نه.

گزارش‌های اجرای کاغذی مشکل زمان‌بندی را آشکار کردند. استراتژی در 12:03:00.000 سیگنالی محاسبه کرد، اما رویداد داده بازار 31 میلی‌ثانیه بعد به فرایند سفارش رسید. بررسی‌های ریسک 22 میلی‌ثانیه دیگر طول کشید و شبیه‌ساز محل اجرا 31 میلی‌ثانیه پس از آن دریافت سفارش را تأیید کرد. در حرکتی سریع، کندل تاریخی ممکن است قیمتی را دست‌یافتنی نشان دهد، در حالی که سفارش لیمیتی پس از عبور بازار از آن قیمت رسیده است.

یک پیچیدگی دیگر هم بود: وقتی بک‌تست از سفارش‌ها عبور کرده بود، 12 سفارش کاغذی هنوز باز بودند. شبیه‌ساز درخواست لغو را طوری پذیرفت که انگار سفارش بلافاصله ناپدید شده است. در سامانه کاغذی، تأیید لغو دیرتر رسید؛ 3 سفارش در فاصله بین این دو رویداد پر شدند. در نتیجه، موقعیتی که سیگنال بعدی می‌دید تغییر کرد.

چطور شکاف را بدون گمراه کردن خودم اندازه بگیرم؟

با یک گزارش تطبیق کوچک که بر اساس قصد سفارش گروه‌بندی شده باشد شروع کنید. مخرج کسر را هم مشخص نگه دارید. «نرخ پرشدن» می‌تواند تعداد سفارش‌های پرشده به‌ازای هر سفارش ثبت‌شده، مقدار پرشده تقسیم بر مقدار درخواستی، یا سفارش‌های پرشده تقسیم بر سفارش‌هایی باشد که به محل اجرا رسیده‌اند. هرکدام به پرسشی متفاوت پاسخ می‌دهد.

1. رویدادها را با شناسه تصمیم یا شناسه سفارش مشتری به هم پیوند دهید، نه با زمانی که بعداً حدس زده‌اید.
2. اول تصمیم‌ها را مقایسه کنید: زمان سیگنال، جهت، مقدار درخواستی، نوع سفارش و قیمت لیمیت.
3. برای تصمیم‌های منطبق، تأخیر تأیید دریافت، رد سفارش، مدت بازماندن، زمان لغو، مقدار پرشده و قیمت میانگین وزنی برحسب حجم را مقایسه کنید.
4. نرخ‌ها را بر اساس نوع سفارش و شرایط بازار گزارش کنید. نرخ پرشدن کلی 63% ممکن است نرخ 90% برای سفارش‌های بازار و 35% برای سفارش‌های لیمیتی منفعل را پنهان کند.

دسته‌بندی‌ها را از هم روشن و مشخص نگه دارید. سفارش ردشده، سفارش پرنشده نیست؛ سفارش نیمه‌پر، پرشدن کامل نیست؛ و سفارشی که پس از پرشدن جزئی لغو می‌شود، همچنان موقعیت را تغییر داده است. هم تعداد سفارش‌ها و هم مقدار درخواستی را بشمارید تا انبوهی از سفارش‌های کوچک نتیجه را بهتر از واقعیت نشان ندهد.

چه چیزی را باید در بک‌تست تغییر دهم؟

قاعده‌ای برای پرشدن به کار ببرید که با وضوح داده و رفتار موردنظر سفارش سازگار باشد. در داده‌های کندلی، رسیدن قیمت به سفارش لیمیتی نشانه‌ای از احتمال پرشدن است، نه اثبات آن. می‌توانید پرشدن جزئی را با رویکردی محافظه‌کارانه مدل کنید، عبور معامله از قیمت سفارش را شرط بگذارید یا سفارش‌های منفعل را که جایگاهشان در صف قابل برآورد نیست کنار بگذارید. هر انتخاب به پرسشی متفاوت پاسخ می‌دهد؛ آن را مستند کنید و نتیجه را با بیش از یک قاعده محتمل مقایسه کنید.

وضعیت سفارش را هم مدل کنید. سفارش تا وقتی سامانه رویدادی نهایی دریافت نکرده، فعال می‌ماند و درخواست لغو، ریسک را از بین نمی‌برد. اگر استراتژی می‌تواند وقتی سفارش اول هنوز در انتظار است سفارش دومی ثبت کند، بک‌تستش باید این رقابت زمانی را بازنمایی کند یا از ابتدا با طراحی مانع آن شود.

مدل پرشدن ادعایی است درباره اینکه سفارش شما چه نتیجه‌ای می‌توانست داشته باشد. قاعده‌ای برایش تعیین کنید که بتوانید توضیحش دهید، سپس آن را با گزارش‌های اجرای کاغذی بسنجید.

در شکاف 28 واحدی ما، نکته شگفت‌آور این نبود که بک‌تست مبتنی بر کندل 1 دقیقه‌ای، پرشدن سفارش‌های منفعل را بیش‌برآورد کرده بود. نکته این بود که چون زمان‌بندی لغو را در نظر نگرفته بودیم، موقعیت استراتژی پیش از تصمیم بعدی‌اش از موقعیت اجرای کاغذی فاصله گرفت. وقتی مدل وضعیت سفارش را اصلاح کردیم و دیگر هر سفارش لیمیتی را که قیمت به آن می‌رسید پرشده فرض نکردیم، مقایسه با اجرای کاغذی کمتر دلگرم‌کننده اما مفیدتر شد.

این معیار عملی هم‌خوانی است: هر تفاوت معنادار میان رفتار شبیه‌سازی‌شده و کاغذی، علت ثبت‌شده‌ای دارد و بک‌تست در جایی که داده‌هایش قطعیتی فراهم نمی‌کنند، ادعای قطعیت نمی‌کند.