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

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

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

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

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

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

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

תוצאה מדידה: מהירות, דיוק, יציבות

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

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

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

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

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

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

פורמטים של העתקת עסקאות: זרימה, מקבץ, הפעלה ידנית

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

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

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

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

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

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

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

ערכת מסירה: קונפיגורציות, תרשימים, מדיניות גישה

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

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

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

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

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

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

תמונת מצב של פוזיציות מושווית לבורסה כל 30 שניות, ופערים נסגרים אוטומטית, לא בידי תורן. לאחר שלושה חודשי עבודה: השהיית הביצוע ירדה מ-900–1200 ל-180–260 מילישניות, שיעור הדחיות — ל-1.2%, וחוסר הסנכרון — ל-0.3% מהעסקאות. טיפולים ידניים בתקלות ירדו מיומיים לבודדים ברבעון.

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

מה לעשות אם הברוקר לא מספק ממשק מסחר?

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

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

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

שאלות נפוצות: השהיות, מגבלות, יציבות תקשורת

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

מה יקרה כשהבורסה תגיע למגבלת פעולות?

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

היכן נשמרים מפתחות הגישה לחשבון?

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

איך הבוט מתנהג בעת ניתוק תקשורת?

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

נדון במשימה: מה נדרש להפעלה ולהערכה

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

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

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