פיתוח מערכת לאיחוד יתרות במספר בורסות

מדוע אגרגציית יתרות בורסות נשברת כאשר מחזורי המסחר גדלים

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

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

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

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

חשבונאות מאוחדת של יתרות: מה משתנה בעבודה היומיומית

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

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

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

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

דרכים לאיחוד כספים: השוואת גישות

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

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

כיצד מתבצעת ההטמעה: שלבי העבודה ההנדסית

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

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

סכמות תזרים, מדיניות גישה ונהלי מסירה

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

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

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

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

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

מה היה לפני האיחוד

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

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

מה שינינו ואילו מדדים השגנו

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

• התאמת יתרות: 97.2% → 99.94%.
• זמן התאמה: 4–6 שעות של עבודה ידנית → עד 10 דקות לאישור הדוח.
• שיעור הפעולות ללא התערבות ידנית: 38% → 94%.
• בירור פערים: 3–5 תקלות בשבוע → 1–2 בחודש, כל אחת עם היסטוריית תיקונים מוכנה.

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

מה לעשות אם החשבונות כבר מפוזרים בין מספר מערכות?

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

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

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

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

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

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

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

כיצד מושוות הלכות חשבונאות שונות של פלטפורמות?

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

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

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

מה עם פערים בעת העברה וחיבור פלטפורמות חדשות?

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

נדון במשימה: ממה מתחילה העבודה המשותפת

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

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

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

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

לאחר הבירור אנו חוזרים עם הערכה, תוכנית והרכב — לאחר מכן נותר רק לתאם את ההתחלה.