ארביטראז' בין בורסות: היכן אובד הרווח
ארביטראז' בין בורסות נראה כמו האסטרטגיה הפשוטה ביותר: ראית פער מחירים בין בורסות, קנית בזול יותר, מכרת ביוקר יותר, קיבעת את ההפרש.
בפועל, את הרווח לא אוכל השוק, אלא השהיית ביצוע העסקה — מרגע שהציטוט נכנס לזרם הנתונים שלנו ועד לרגע שפקודת הצד הנגדי באמת נכנסה לספר הפקודות בפלטפורמה השנייה.
פער המחירים חי שברירי שנייה. עד שהאות מגיע למבצע, עוברות בדיקות מגבלות וסיכונים, נשלחת ומאושרת פקודה — הספרד מתקפל, ושתי הפלטפורמות כבר בנו מחדש את ספרי הפקודות. אנחנו תופסים לא את המחיר שראינו, אלא את זה שנשאר אחרינו.
צוואר הבקבוק השני — החלקת מחיר. הרמה שבה נראה הנפח הנדרש היא בדרך כלל דקה: חלק מהפקודה נסגר במחיר המוצהר, והשאר — במחירים הבאים, גרועים יותר. ככל שהנפח גדול יותר, כך בולט יותר הפער בין מחיר העסקה הממוצע הצפוי לזה שבפועל.
הבעיה השלישית — אי-סנכרון מצב הפוזיציות. רגל אחת בפלטפורמה אחת בוצעה, בשנייה נדחתה או נסגרה חלקית, הכספים מפוזרים בין יתרות, והשערים כבר זזו. תוכנית בלי בקרה על שתי הרגליים הופכת לפוזיציה לא מתוכננת עם סיכון שוק.
לכן העבודה מתחילה לא מאותות, אלא מתקציב זמן ומהערכת נזילות של כל פלטפורמה: כמה זמן אורך מחזור מלא, איזה נפח עובר בלי החלקה מורגשת, ומה עושים כשאחת הרגליים לא בוצעה. בהמשך נפרט כיצד נקודות אלה נסגרות בארכיטקטורה.
הפחתת החלקה ובקרת ביצוע
עסקת ארביטראז' חיה שניות: הפער בין הפלטפורמות נפתח ונסגר מהר יותר משהמפעיל מספיק להסתכל על ספר הפקודות. לכן הביצוע נבנה על חוקים שפועלים בלי אדם — חיבור ל-Binance ולפלטפורמות אחרות מחזיק זרם ציטוטים אחיד, והחלטה על כניסה מתקבלת על ידי אלגוריתם.
מהירות תגובה לפער מחירים
אות מהסורק הופך אוטומטית לזוג פקודות מנוגדות: הנפח מתחלק בין הפלטפורמות בהתחשב בעומק הזמין, ולא «בעין». התגובה לפער הצטמצמה מ-20–30 שניות ידניות לשברירי שנייה, וחלק העסקאות שנסגרו במחיר הצפוי עלה מ-60–70% ל-90%+. פקודה שלא עברה לפי מחיר מבוטלת ומחושבת מחדש, במקום להיתלות בספר הפקודות.
בקרת סיכון על פוזיציה
מגבלות על פוזיציה מוגדרות לפי כל מכשיר ופלטפורמה: האלגוריתם לא יצבור נפח גדול מהמוגדר, גם אם הפער נראה משתלם. עמלות — מסחר ומשיכה — מוטמעות בחישוב הספרד, ולכן לעבודה נכנסים רק פערים שנשארים רווחיים אחרי כל העלויות.
אם רגל אחת לא בוצעה, השנייה נסגרת אוטומטית: מספר הפערים הלא סגורים ירד מעשרות בחודש למקרים בודדים, וסוג הכשל «פוזיציה חד-צדדית תקועה» בתרחישים המטופלים הפסיק להופיע.
השוואת מצבי ארביטראז' בין בורסות
מצב הביצוע נבחר לא לפי נוחות, אלא לפי זמן החיים של חלון העסקה: פער מחירים בין פלטפורמות נסגר בשניות, בעוד העברת כספים אורכת עשרות דקות. מכאן ארבע אפשרויות שבהן באמת בוחרים.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| אוטומט מלא עם ביצוע עצמי | זרם האותות יציב, הכספים מונחים בשתי הפלטפורמות | נדרשים מפתחות עם הרשאת מסחר, הגנה מפני ביצוע חלקי |
| חצי-אוטומט עם אישור מפעיל | גודל פוזיציה גדול, רשימת פלטפורמות מצומצמת | מהירות התגובה נקבעת על ידי אדם, חלק מהאותות מחמיצים |
| מצב אותות | בדיקת הלוגיקה, מסחר ידני | אין ביצוע אוטומטי — רק התראה וחישוב |
| שדרוג מערכת קיימת | יש בוט עובד וחשבונאות, נדרשת מערכת שנייה | הארכיטקטורה הקודמת מגבילה את המהירות ואת מגוון הפלטפורמות |
זוגות פלטפורמות וסוגי מכשירים
אנחנו מתייחסים כאל עובדים לא לפלטפורמות עצמן, אלא לזוגות שלהן. ספוט-ספוט נותן לוגיקה פשוטה, אך דורש העברת כספים בין בורסות; ספוט-פיוצ'רס ופיוצ'רס-פיוצ'רס מאפשרים להחזיק את שתי הרגליים בלי משיכה. המכשיר בשני הצדדים חייב להתאים לפי נכס הבסיס ולפי מכפלת החוזה — אחרת חישוב הפער מאבד משמעות.
מה מטיל מגבלות: נזילות, מגבלות, מהירות משיכה
עומק ספר הפקודות קובע את תקרת הנפח: ההחלקה אוכלת את הספרד מהר יותר משהפוזיציה גדלה. מגבלות הפלטפורמות מגבילות את תדירות הבקשות ואת מספר הפקודות בחשבון, ולכן אנחנו מסננים אותות לפני שליחה.
במקום שבו המשיכה לא נכנסת לחלון, בונים מערכת בלי העברה — דרך רגל פיוצ'רס ובדיקה לפני מסחר עם חישוב מחדש אחרי עמלות.
כיצד נבנה האלגוריתם: שלבי עבודת הנדסה
ארביטראז' בין בורסות חי על פער מחירים בין פלטפורמות, וכמעט כל המרווח נאכל על ידי ארבעה דברים: השהיה בין הציטוט לביצוע, עמלות של שתי הרגליים, עומק ספר הפקודות וביצוע חלקי. לכן אנחנו לא מתחילים מקוד — קודם מתעדים מה כבר קיים בתשתית ובנתונים, ורק אחר כך כותבים לוגיקה. להלן רצף של שבעה שלבים, שכל אחד מהם מסתיים בתוצר ניתן לבדיקה.
ביקורת תשתית ונתונים
- ביקורת תשתית: בודקים חיבורים לפלטפורמות, הרשאות מפתחות, מגבלות בקשות, השהיות רשת לנקודות פריסה והיכן נשמר מצב הפוזיציות.
- איסוף וניקוי נתונים היסטוריים: מרימים ספרי פקודות ועסקאות לתקופה הנדרשת, מסירים חריגים, משחזרים חסרים, ומביאים סימוני זוגות וצעדי מחיר לצורה אחידה.
- תרשים לוגיקה ומגבלות: מתארים מה נחשב להזדמנות, סף כניסה עם התחשבות בעמלות, מגבלות לזוג ולפלטפורמה, התנהגות בביצוע חלקי וכללי עצירה.
בדיקה על היסטוריה ובנפח קטן
- מימוש: בונים מודולים לאיסוף, חישוב וביצוע בנפרד, כך שכשל של חלק אחד לא יגרור אחריו את האחרים.
- מערכת בדיקה: מריצים את הלוגיקה על חלונות היסטוריים, כולל ניתוקי תקשורת ותנועות שוק חדות.
- בדיקה בנפח קטן: מפעילים גדלי עסקאות מינימליים, ומשווים את התוצאה הצפויה לזו שבפועל בכל רגל ובפער בעמלות.
- מסירה ותמיכה: מוסרים תיעוד, הגדרת ספים ונוהל לניתוח חריגות במערכת חיה.
אחרי השלב השישי נראה הפער בין החישוב לביצוע בפועל — הוא בדיוק קובע אילו ספים להציב והאם בכלל להריץ את האסטרטגיה בנפח מלא.
קונפיגורציות, נהלים ותיעוד למסירה
עבודה נחשבת למסורה לא ברגע שהאלגוריתם הביא את העסקה הראשונה, אלא כשהצוות שלכם יכול לשנות את הפרמטרים שלו, לעצור ולהעלות אותו בלי ההשתתפות שלנו.
לכן חבילת המסירה נאספת מהיום הראשון לפיתוח, ולא נכתבת בסוף: קונפיגורציות מופרדות מהקוד, וכל המגעים החיצוניים — בורסות, התראות, הרשאות — מתוארים כך שאפשר לשחזר אותם בסביבת בדיקה.
תיעוד ונהלי תגובה
- קובצי קונפיגורציה לכל בורסה וזוג: מגבלות נפח, ספי כניסה ויציאה, התחשבות בעמלות ובהשהיות — נערכים ומיושמים בלי לבנות מחדש את האלגוריתם.
- תרשים אינטראקציה בין רכיבים: איסוף ציטוטים, חישוב פער מחירים, מודול ביצוע, בקרת יתרות והתאמה מול דוחות הבורסה — עם ציון מרווחים ונקודות כשל.
- יומני אירועים והתראות עם רמות חשיבות: עסקאות, דחיות בורסה, פערי יתרה, השבתת ערוץ; ייצוא לתקופה לצורך ניתוח תקלה.
- הוראות הפעלה, עצירה שגרתית ועצירת חירום — עם תיאור מצבים: היכן נשארות פוזיציות פתוחות וכיצד לסגור אותן ידנית.
- נוהל תגובה לתקלה: רצף צעדים, מי מקבל החלטה על עצירה, תוך כמה זמן יוצרים קשר ואילו נתונים לצרף לפנייה.
הרשאות גישה וחלוקת תפקידים
- תפקידים עם היקף הרשאות שונה: צופה, מפעיל, מנהל קונפיגורציה. שינוי מגבלות ועצירת מודול — רק אצל שני האחרונים.
- מפתחות בורסה בלי הרשאת משיכת כספים; נשמרים בצד שלכם, ובקונפיגורציה נשארות רק הפניות אליהם.
- מדיניות החלפת מפתחות ושלילת גישות עם עזיבת עובד — כתובה כנוהל, לא כמשאלה.
- יומן פעולות מפעילים: מי, מתי ומה שינה בפרמטרים ומתי עצר את האלגוריתם.
מקרה בוחן: העברת פוזיציות בין בורסות בלי הפסדים
צוות מסחר החזיק פוזיציות בארבע פלטפורמות והעביר אותן ידנית: עיקר המחזור עבר דרך Binance, והשאר דרך בורסות פחות נזילות. את הפער מצאו בטרמינל, משכו כספים, חיכו לזיכוי ורק אז פתחו את הרגל השנייה — מחיר הנטו עד אז כבר זז. במשמרת, סוחר תורן הספיק לטפל במקרים בודדים של פערים, והשאר פשוט הוחמצו.
מה היה לפני ומה נהיה אחרי
| מדד | לפני | אחרי |
|---|---|---|
| עסקאות במחיר הצפוי | כשליש מהכניסות | תשעה מתוך עשרה |
| תגובה לפער | עשרות שניות | שברירי שנייה |
| התערבויות ידניות במשמרת | 30–40 | בודדים |
| החלקה בהעברה | עשיריות האחוז | בתוך המגבלה שהוגדרה |
אספנו זרם ציטוטים אחיד מכל הפלטפורמות ומחשבים מחיר נטו עם התחשבות בעמלות, בעומק ספר הפקודות ובהשהיית הביצוע. הרגליים מוצבות בו-זמנית, והיתרות מפוזרות מראש בין הבורסות — העברת כספים הופכת לחריג נדיר ומתבצעת ברקע, בלי לחסום עסקאות. אם מחיר הנטו חורג מהסף, האלגוריתם לא פותח פוזיציה בכלל: עדיף להחמיץ פער מאשר להיכנס במחיר גרוע.
ההחלקה הפסיקה לאכול את התוצאה, והעבודה הפסיקה להיות תלויה במי שנמצא במשמרת. לכל זוג פקודות נשמר יומן: רואים היכן עברה ההשהיה ולמה העסקה לא התקיימה. ספים, מגבלות נפח ורשימת הפלטפורמות הוצאו לקונפיגורציה ומשתנים בלי לכתוב מחדש את הליבה.
מה לעשות אם בין הבורסות כבר פועל בוט
רובוט שכבר סוחר בין בורסות אינו סיבה לכתוב את המערכת מאפס. הוא משמש מקור לדרישות: בפנים מוטמעות הנחות לגבי עמלות, מגבלות משיכה, פערי ספרי פקודות וספרד מינימלי שבו העסקה עדיין נשארת רווחית. המשימה היא לחלץ את הלוגיקה הזו ולבדוק אותה מול עובדות, ולא לנחש מחדש.
מתחילים בביקורת של הקוד הנוכחי ויומני הביצוע. משחזרים כיצד מחושב הספרד עם התחשבות בעמלות כניסה ויציאה, כיצד נבחר גודל הפוזיציה, מה קורה בביצוע חלקי ולאן הולך שארית הפקודה שבוטלה. אחר כך משווים את החוקים שנמצאו להיסטוריית העסקאות בפועל — הפערים מראים היכן הלוגיקה כבר תוקנה ידנית.
העברת מצב הפוזיציות הפתוחות מתבצעת לפי תמונת מצב ויומן אירועים. מתעדים מה פתוח בכל מכשיר בכל פלטפורמה, מחיר כניסה ממוצע, חלקים שלא בוצעו בפקודות ועמלות שנצברו. את תמונת המצב משווים לייצוא מהבורסות — דרך Binance ושאר הפלטפורמות, באמצעות היסטוריית עסקאות ודוחות יתרות. אם ההתאמה לא מסתדרת, המערכת החדשה תחשב תשואה שגויה ותקבל החלטות על נתונים עקומים.
העברת השליטה מתבצעת בלי לשבור את העבודה. הרובוט החדש מופעל במקביל במצב צפייה: חוזר על החלטות הישן וכותב ליומן כל פער. כשההתנהגות זהה על היסטוריית עסקאות מספקת, מעבירים מכשיר אחד בכל פעם — הרובוט הישן נשאר במצב סגירת פוזיציות ולא פותח חדשות.
הפעולה ההפוכה — החזרת שליטה במכשיר מסוים, ולא שחזור מגיבוי: הפוזיציות הפתוחות ממשיכות להיות מטופלות, ומפתחות הגישה לבורסות לא מונפקים מחדש.
חששות לקוחות לגבי אמינות וסיכונים
החששות של לקוחות הם בדרך כלל אותם חששות: מה יקרה אם הפלטפורמה תתחיל להאט, כיצד האלגוריתם יתנהג בתנועה חדה והאם אפשר להאמין לתוצאות בדיקה על נתוני עבר. להלן תשובות לשאלות טכניות שנשמעות לרוב לפני תחילת העבודה.
מה אם משיכת הכספים מתעכבת?
הפוזיציה נסגרת ברגע ששתי רגליות העסקה בוצעו. אם הפלטפורמה מעכבת משיכה, הנכס התקוע מוחרג מחישוב הנזילות הזמינה — האלגוריתם מסמן את הפוזיציה כלא סגורה ואינו מתחשב בה בחיפוש ההזדמנות הבאה.
בהמשך פועל תרחיש שנכתב מראש: המתנה עם בקרת סטטוס, ואם עוברים את הסף — ניסיון סגירה בפלטפורמה השנייה או קיבוע הפוזיציה עד להתאוששות.
הפלטפורמה מגבילה נפח או תדירות בקשות?
מגבלות הפלטפורמה מוטמעות במודל, ולא נחשבות לתקלה. האלגוריתם מעריך את הנפח הזמין בכל זוג, מפצל פקודה גדולה ושומר על השהיה כשמתקרבים למגבלת הבקשות. כשפלטפורמה סוגרת כיוון, הזוג שלה מנותק, והזרם מתחלק מחדש לאחרים — בלי התערבות ידנית.
כיצד יתנהג בתנועה חדה של השוק?
כאן הסיכון העיקרי הוא נזילות: בתנועה חדה העומק יורד, ופער המחירים גדל מהר יותר משמבוצעת הפקודה. לכן לפני שליחה מתבצעת בדיקה שמסננת הזדמנויות שבהן ההפרש הצפוי קטן מההחלקה האפשרית. חלק מהאותות לא עוברים את המסנן — זו עבודה שגרתית, לא רווח שהוחמץ.
עד כמה אפשר להאמין לבדיקה על נתוני עבר?
בדיקה על היסטוריה מתבצעת עם התחשבות בעמלות, בהשהיות ובביצוע חלקי, ולא על מילוי «אידיאלי» של ספר הפקודות. קונפיגורציה עוברת לעבודה אם התוצאה מחזיקה מעמד גם בעלויות מכוונות גבוהות מדי; אם היא מתפרקת — מתקנים את הלוגיקה, ולא מכווננים פרמטרים לעקומה יפה.
למי שייך קוד המקור?
קוד המקור, הקונפיגורציות והתיעוד נמסרים לכם — עם תיאור הלוגיקה, נקודות כשל ונוהל ההתאוששות אחרי תקלה. אין תלות נסתרת בצד שלנו: אפשר לפתח את המערכת עם הצוות שלכם או עם קבלן אחר.
נדון במשימה ונחזור עם תוכנית
כדי שהערכת היקף העבודה תהיה מציאותית ולא ממוצעת לפי השוק, אנחנו צריכים מכם מינימום נתוני פתיחה. הם מספיקים כדי לחשב שעות עבודה, להרכיב הרכב צוות ולא להכניס לתוכנית שלבים מיותרים.
- רשימת פלטפורמות: היכן אתם סוחרים כיום ולאן אתם מתכננים לצאת — מכך תלוי מספר מודולי החיבור והיקף העבודה בכל אחד.
- סוגי חשבונות והרשאות מפתחות: מסחר, משיכת כספים, מגבלות בקשות — קובעים אילו פעולות האלגוריתם סוגר בעצמו והיכן נדרשת פעולה ידנית.
- גישה לסביבות בדיקה של הפלטפורמות — בהן בודקים את הלוגיקה של הצבת וביטול פקודות בלי סיכון ליתרה.
- אחראים מצד הלקוח: מי מקבל החלטות בנוגע ללוגיקת המסחר ומי אחראי לאבטחת המפתחות.
- נכסים קיימים — סקריפטים, חישובים ידניים, טבלאות עם ספרדים ועמלות: לוקחים כבסיס, ולא ממציאים מחדש.
- גבולות סיכון: ירידה מותרת, מגבלה לעסקה, התנהגות האלגוריתם בניתוק תקשורת ובאי-סנכרון מחירים בין הפלטפורמות.
- דרישות לפריסה: השרת שלכם או שלנו, האם יש מגבלות על גישות רשת ותיעוד פעולות.
תארו את המשימה בצורה חופשית — לפי נתוני הפתיחה האלה נחזור עם הערכת היקף, תוכנית עבודה לפי שלבים והרכב צוות שמתאים למערכת שלכם.