ساعت 08:00 UTC روز سه‌شنبه، یک بازار کریپتو اندازه تیک قرارداد پرپچوال با قیمت متوسط را تغییر داد. استراتژی مبنای ما متوجه نشد. سیگنال آن همچنان همان فاصله میان اسپات و فیوچرز را می‌دید، محدودیت‌های ریسک تغییر نکرده بودند و بک‌تست هم همان نتایج قبلی را نشان می‌داد.
اما معامله کاغذی متوجه شد. آداپتور سفارش، قیمت سفارش خرید محدود را به پایین‌ترین قیمت مجاز گرد کرد. در نتیجه، سفارش یک تیک پایین‌تر از سطحی قرار گرفت که بک‌تست مدل کرده بود. بازار به قیمت قبلی رسید، سفارش شبیه‌سازی‌شده اجرا شد، اما سفارش کاغذی بی‌حرکت ماند. تا وقت ناهار، موجودی استراتژی نامتوازن شده بود.
این رخداد در نگاه اول یک ایراد کوچک در گرد کردن قیمت به نظر می‌رسید. اما در واقع، مشکل از مرز مدل‌سازی بود: استراتژی قیمت‌ها را می‌شناخت، ولی بک‌تست از شبکه قیمتی بازار خبر نداشت.
ما با یک سیگنال ساده مبنا معامله می‌کردیم: وقتی پریمیوم فیوچرز از یک آستانه فراتر می‌رفت، اسپات می‌خریدیم و پرپچوال می‌فروختیم. سفارش‌ها غیرفعال بودند، چون مزیت مورد انتظار از مبنا کم بود. چند تیک می‌توانست تعیین کند که ورود به معامله به‌اندازه کافی سود دارد تا کارمزدها و خروج نهایی را پوشش دهد یا نه.
با تغییر اندازه تیک چه چیزی عوض شد؟
پیش از به‌روزرسانی، قیمت‌های پرپچوال با گام‌های 0.01 پذیرفته می‌شدند. پس از آن، در بازه قیمتی مربوط، گام قیمت به 0.05 تغییر کرد. سیگنال، قیمت هدف فروش را 42,318.03 محاسبه کرد؛ قیمتی که طبق قانون قبلی معتبر بود. طبق قانون جدید، آن قیمت نامعتبر بود.
صرافی قیمت‌های نامعتبر را رد می‌کرد، اما آداپتور ما یک راه جایگزین داشت: قیمت فروش را به 42,318.00 گرد می‌کرد. آن قیمت هم نامعتبر بود. راه جایگزین دوم دوباره قیمت را گرد کرد، این بار به 42,318.05؛ قیمتی معتبر، اما برای فروشنده کمتر تهاجمی. دیگر نمی‌شد سفارش را با قیمت مدل‌شده فروخت. این مسیر کد برای بازاری متفاوت نوشته شده بود و رد سفارش را بی‌سروصدا به ثبت سفارشی با قیمتی تازه تبدیل می‌کرد.
آن یک سفارش، دو پرسش جداگانه را درهم آمیخت. اول، بازار چه قیمتی را می‌تواند بپذیرد؟ دوم، وقتی قیمت مطلوب استراتژی روی شبکه قیمتی قرار ندارد، استراتژی چطور باید واکنش نشان دهد؟ صرافی به پرسش اول پاسخ می‌دهد. پرسش دوم را استراتژی یا سیاست اجرا باید پاسخ دهد.
| قصد سفارش | قانون شبکه | جهت معمول گرد کردن | چیزی که ممکن است تغییر کند |
|---|---|---|---|
| خرید محدود | قیمت باید مضربی از تیک باشد | به پایین، تا در حد قیمت یا پایین‌تر از آن بماند | احتمال اجرای کمتر |
| فروش محدود | قیمت باید مضربی از تیک باشد | به بالا، تا در حد قیمت یا بالاتر از آن بماند | احتمال اجرای کمتر |
| سفارش محدودِ قابل اجرا در بازار | باید محدودیت‌های قیمت را هم رعایت کند | به بیشترین قیمت قابل‌قبول بستگی دارد | اینکه فاصله خرید و فروش را رد می‌کند یا نه |
هیچ قانون گرد کردن واحد و درستی وجود ندارد. گرد کردن سفارش خرید به پایین، محدودیت قیمت خریدار را حفظ می‌کند، اما ممکن است احتمال اجرا را کاهش دهد. گرد کردن به بالا می‌تواند سفارش را به سفارشی قابل اجرا در بازار تبدیل کند و در نتیجه کارمزد و اثر قیمتی را تغییر دهد. برای ورود غیرفعال به معامله مبنا، تغییر بی‌سروصدای قیمت سفارش رفتار درستی نبود. استراتژی یک قیمت هدف تعیین کرده بود؛ آداپتور اقتصاد معامله را تغییر داد.
چرا بک‌تست همچنان سالم به نظر می‌رسید؟
شبیه‌ساز سفارش تاریخی ما قیمت‌های محدود را اعداد پیوسته در نظر می‌گرفت. اگر کف کندل به قیمت خرید می‌رسید یا سقف آن به قیمت فروش می‌رسید، سفارش را اجراشده حساب می‌کرد. این خودش تقریب خوش‌بینانه‌ای برای سفارش غیرفعال است، چون معامله‌شدن در قیمت محدود چیزی درباره جایگاه سفارش در صف نمی‌گوید. اما تغییر اندازه تیک شکاف بنیادی‌تری را آشکار کرد: اصلاً نمی‌شد سفارشی با آن قیمت ثبت کرد.
همان تصمیم‌ها را با اعمال شبکه جدید از زمان اجرایی‌شدنش بازپخش کردیم. چند اجرای سفارش از بین رفت. تعدادی از سفارش‌ها با گرد شدن به قیمت‌هایی رسیدند که فاصله خرید و فروش را رد می‌کردند و به‌جای کارمزد maker، کارمزد taker گرفتند. مسیر موقعیت حاصل از آن متفاوت شد و در نتیجه پوشش ریسک‌ها و خروج‌های بعدی هم تغییر کردند. قانونی که شبیه فراداده به نظر می‌رسید، کل توالی معاملات را عوض کرده بود.
این به‌روزرسانی هم غافلگیرکننده و پنهان در نمودار نبود. بازار تغییر قانون ابزار معاملاتی را با زمان اجرایی‌شدن مشخص منتشر کرده بود. داده‌های بازار را با دقت ذخیره می‌کردیم، اما فراداده ابزار معاملاتی در حافظه نهانی بود که هنگام راه‌اندازی تازه‌سازی می‌شد. بک‌تست برای همه تاریخ‌های گذشته قوانین امروز را می‌خواند؛ معامله کاغذی هم تا راه‌اندازی دوباره فرایند، قوانین قدیمی را داشت. هیچ‌یک از دو محیط نشان نمی‌دادند صرافی در هر لحظه چه چیزی را مجاز می‌دانست.
بک‌تست چطور باید تغییرات اندازه تیک را مدل کند؟
قوانین ابزار معاملاتی را با بازه‌های اعتبار نسخه‌بندی کنید، درست مثل دیگر ورودی‌هایی که باید در همان زمان در دسترس بوده باشند. دست‌کم، زمان اجرایی‌شدن و مقادیر لازم برای اعتبارسنجی سفارش را نگه دارید: اندازه تیک، گام مقدار، حداقل مقدار و هرگونه بازه قیمتی. شبیه‌ساز باید مجموعه قوانینی را بارگیری کند که هنگام تصمیم‌گیری شبیه‌سازی‌شده در دسترس بوده است.
بعد، نحوه رسیدگی به سفارش را صریح کنید. اگر قیمت هدف نامعتبر است، آن را رد کنید، طبق سیاستی مستند گرد کنید یا هدف را روی شبکه دوباره محاسبه کنید. ثبت کنید کدام اتفاق افتاده است. بک‌تستی که هر سفارش را خودکار اصلاح می‌کند، ممکن است برای برآورد یک سیاست اجرای مشخص مفید باشد؛ اما نباید آن سیاست را پشت عنوان اجرای سفارش در صرافی پنهان کند.
برای سفارش‌های غیرفعال، معتبر بودن قیمت طبق اندازه تیک فقط شرط اول اجراست. همچنان به مدلی نیاز دارید که مشخص کند آیا بازار از قیمت شما عبور کرده، چه تعداد سفارش در صف جلوتر از شما بوده، چه لغوهایی رخ داده و چه سطح کارمزدی نصیبتان می‌شده است.
دو بررسی اضافه کردیم. یکی همه سفارش‌های تولیدشده را با قوانین ابزار معاملاتی در همان زمان اعتبارسنجی می‌کند و در صورت نامعتبر بودن قیمت یا اندازه، خطا را آشکارا اعلام می‌کند. دیگری سفارش نهایی نرمال‌شده آداپتور بک‌تست و معامله کاغذی را مقایسه می‌کند: سمت، قیمت، مقدار، مدت اعتبار و قصد کارمزدی. اگر تفاوتی باشد، آن اجرا را قابل‌مقایسه نمی‌دانیم.
بعد از آن، تغییر روز سه‌شنبه را دوباره بازپخش کردیم. بک‌تست دیگر پس از به‌روزرسانی شبکه، اجرای سفارش در 42,318.03 را ادعا نمی‌کرد. معامله کاغذی و شبیه‌سازی درباره هر قیمت هدف نامعتبر یک تصمیم یکسان می‌گرفتند، حتی وقتی تصمیم این بود که سفارش را ثبت نکنند.
سیگنال خراب نشده بود. فرض‌های آن درباره چیزی که می‌توانست معامله کند، قدیمی شده بود. استراتژی می‌تواند با اندازه تیک جدید کنار بیاید، اما فقط وقتی سامانه پژوهش، قوانین بازار را بخشی از بازاری بداند که شبیه‌سازی می‌کند.
← همهٔ مطالب
