הטמעת הצבת פקודת סטופ באפליקציית המובייל של הבורסה

מדוע פקודת סטופ אינה מתבצעת באפליקציה לנייד

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

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

המקרה הקלאסי — אובדן פקודה בעת ניתוק התקשורת. המשתמש לחץ «קנה», הממשק הציג אישור, אך הבקשה לא הגיעה לליבת המסחר: בעת מעבר בין רשתות התשובה אובדת, והאפליקציה משלימה את ההצלחה לפי מצב מקומי.

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

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

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

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

מה מניבה עבודה תקינה של פקודות מותנות

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

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

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

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

מצבי הצבת פקודת סטופ: השוואת גישות

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

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

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

כיצד אנו מטמיעים פקודות מותנות: שלבי העבודה

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

1. ביקורת תרחישי פקודות. אוספים רשימה: סטופ-לוס וטייק-פרופיט, סטופ-לימיט, הצמדה לעסקה האחרונה או למחיר הסימון, התנהגות בעת גאפ וביצוע חלקי. בפלט — מטריצת «תרחיש / תנאי התבצעות / התנהגות צפויה», מתואמת עם הצוות שלכם.
2. תכנון הסכימה. מחליטים היכן מתקיים מצב הפקודה — בצד הלקוח, בשרת או בליבת המסחר — וכיצד הוא נבדק לאחר התחברות מחדש. בנפרד סוגרים הגנה מכפילויות: שליחה חוזרת בעת ניתוק רשת אינה אמורה ליצור פקודה שנייה.
3. מימוש. שכבת הפקודות המותנות נכתבת בנפרד מהממשק, כדי שניתן יהיה לשנות את לוגיקת ההתבצעות בלי לבנות מחדש את המסכים. עיבוד אירועי מחיר מתבצע בזרם אחד עם תור מפורש — זה מסיר מרוצים בעת תנועה חדה של השוק.
4. מתחם בדיקות. מקימים סביבה עם זרם ציטוטים ותגובת ליבת המסחר, כולל כשלים: פסקי זמן, פקודות נדחות, אי-סנכרון מצב. כל סעיף במטריצה מכוסה בבדיקה אוטומטית.
5. בדיקת פקודות על נתונים היסטוריים. מריצים ימי מסחר אמיתיים עם גאפים ונזילות נמוכה: בודקים היכן הפקודה התבצעה במחיר הצפוי, היכן החליקה, והיכן הלוגיקה סטתה מזו של הבורסה.
6. מסירה ותקנונים. מוסרים סכימת מצבים, תיאור תצורה, סדר טיפול בתקריות ומדדים: שיעור הפקודות הנדחות, השהיה מקבלת המחיר ועד השליחה, מספר אי-הסנכרונים.

תצורות, סכימות חישוב ותקנוני מסירה

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

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

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

מקרה בוחן: כיצד צמצמנו את מספר הפקודות שלא בוצעו

המצב לפני

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

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

מה שינינו ומה התקבל

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

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

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

פקודה מותנית בלימיט או לפי שוק: מה לבחור

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

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

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

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

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

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

ספקות טכניים: שאלות ותשובות בנוגע לפקודות

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

מה קורה בעת ניתוק תקשורת ברגע ההצבה?

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

כיצד לבדוק את הלוגיקה בלי לסכן פוזיציות?

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

האם פקודות יאבדו לאחר עדכון האפליקציה?

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

נדון במשימה: הכינו נתוני פתיחה בנוגע ללוגיקת המסחר

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

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

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