לבדיקת ה־Backtest שלך יש בעיית שעון, גם כשכל חותמות הזמן נכונות

באג התזמון המסוכן ביותר בבדיקת Backtest יכול לשרוד ביקורת מושלמת של חותמות הזמן. שני אירועים יכולים לשאת את השעה 10:00:00.000, ובכל זאת להתרחש בסדר שהסימולטור שלכם ניחש.

זה חשוב בכל פעם שאסטרטגיה מגיבה ליותר מנרות שהושלמו: עדכון הצעת מחיר, עסקה, הודעת מימון, שינוי בסטטוס של זירה או אישור על פקודה שלכם. חותמת זמן אומרת מתי האירוע תויג. היא לא בהכרח אומרת מתי האסטרטגיה שלכם יכלה לפעול על סמך המידע הזה.

מה משתנה כשמשנים את סדר האירועים?

דמיינו אסטרטגיה שקונה כשההצעה הטובה ביותר יורדת מתחת ל־$100.00. באותה מילישנייה, הפיד מתעד עדכון להצעה ל־$99.99 ועסקה במחיר $99.99. אם בדיקת ה־Backtest שלכם מעבדת קודם את העסקה ואחר כך את הצעת המחיר, האסטרטגיה רואה את ההצעה החדשה ושולחת פקודה. גם עיבוד הצעת המחיר קודם עשוי להיות תקין, בתנאי שהאירוע אכן היה זמין. אבל אם העסקה ניצלה את הנזילות המוצגת לפני שהפקודה הגיעה, ביצוע במחיר $99.99 הוא בדיה.

מיון שורות לפי חותמת זמן בלבד משאיר לסימולטור לבחור את הסדר של אירועים בעלי אותה חותמת זמן. סדר הקובץ, סדר הסמלים או תוכנית שאילתת מסד הנתונים עלולים להפוך בטעות לכלל ביצוע. עקומת ההון עשויה להשתנות אף שנתוני המקור לא השתנו.

כך אפשר לראות עד כמה הסדר עלול להיות שרירותי: ממיינים אירועים בעלי אותה שעה לפי שם הסמל במקום לפי סדר ההגעה. אסטרטגיה רב־נכסית יכולה אז להתנהג אחרת רק מפני שסימול אחד מופיע לפני אחר במיון.

אילו שעונים צריך לשמור בבדיקת Backtest?

נתוני שוק וטיפול בפקודות מערבים לעיתים קרובות כמה זמנים נפרדים. שמרו את השדות שהמקור מספק, והגדירו במדויק למה הם מתייחסים. בפידים רבים, גם חותמת הזמן של הזירה וגם חותמת הזמן המקומית של קבלת ההודעה מועילות; אף אחת מהן אינה אמת מוחלטת לגבי מה שכל המשתתפים ראו.

בנתונים היסטוריים שאין בהם זמני קבלה, ציינו מה אתם מניחים. בדיקת Backtest עשויה לעבד את אירועי הזירה לפי הסדר ולהוסיף השהיה קבועה של 5 ms בין ההחלטה להגעת הפקודה. זהו מודל, לא היסטוריה ששוחזרה. אם אין לכם מספרי רצף לחותמות זמן זהות בזירה, גם כלל ההכרעה בין אירועים הוא הנחה.

איך ממדלים אירועים בעלי אותה חותמת זמן?

ראשית, שימרו מספרי רצף של המקור כשהם זמינים. מספר רצף מספק סדר חזק יותר בתוך הפיד שלו מחותמת זמן, אם כי מרחבי הרצף עשויים להיות נפרדים בין ערוצים או מוצרים.

לאחר מכן, הגדירו במפורש את כלל העיבוד של הסימולטור. לכל אירוע, קבעו אם הוא יכול לעדכן את המידע של האסטרטגיה, לשנות את הנזילות הזמינה, להפעיל פקודה או לאשר פקודה. אלה פעולות שונות; איחוד שלהן ל״עיבוד שורה״ הוא הדרך שבה ביצועים בלתי אפשריים חומקים פנימה.

1. החילו רק מידע על השוק שהגיע עד זמן ההחלטה של האסטרטגיה.
2. צרו את הפקודה, ואז קדמו אותה לזמן ההגעה שלה לזירה לפי המודל.
3. אפשרו ביצוע רק מול נזילות כשירה לאחר ההגעה, בהתאם להנחות הביצוע של סוג הפקודה.
4. תעדו את הקלטים, את סדר האירועים ואת ההשהיה ששימשו לכל ביצוע בסימולציה.

באסטרטגיה שמבוססת על נרות, ייתכן שזה יותר מורכב ממה שהשאלה מחייבת. אם האות משתמש בנרות 1-minute שהושלמו והפקודות מתבצעות בפתיחת הנר הבא עם מודל עלויות שמרני, סביר שסדר אירועים בתת־מילישנייה לא ישנה את מסקנת המחקר. העיקר הוא להתאים את רמת פירוט התזמון לטענה שבדיקת ה־Backtest מעלה.

אפשר לסמוך על בדיקת Backtest בלי נתונים על זמני הגעה?

אפשר עדיין להשתמש בה, אבל חשוב להבהיר את המגבלות. אם האסטרטגיה סוחרת בקצב איטי ומגבולות הסיכון שלה רחבים, כמה מילישניות עשויות להיות חסרות משמעות. אם היא מגיבה להצעות מחיר חולפות, מתחרה על מיקום בתור או תלויה באות מוביל־מובל בין זירות, היעדר זמני הגעה עלול להיות גורם מרכזי בתוצאה.

המבקרים צודקים בכך שתזמון מדויק של אירועים עלול ליצור דיוק מדומה. פידים היסטוריים אינם שלמים, שעונים סוטים, וחותמות הזמן של הזירות לא חושפות כל מעבר ברשת. גם סימולטור עם שדות בננו־שניות יכול להישען על הנחת ביצוע גסה.

לכן בדקו רגישות במקום לטעון לוודאות: הריצו מחדש עם כללי הכרעה סבירים בין אירועים ועם השהיות שונות לפקודות, ואז השוו את מספר העסקאות, מחיר הביצוע ואת האותות שנותרו תקפים. אם התוצאה תלויה בסדר שהנתונים אינם יכולים לקבוע, ציינו את התלות הזאת בדוח המחקר. בדיקת Backtest יכולה להיות שימושית גם כשהשעון אינו מושלם. היא רק צריכה להבהיר איזה מידע על הזמן באמת ידוע לה.