ציטוטים זורמים OTC: היכן הזרם נשבר ומה מפסיד הדסק
ציטוטים זורמים OTC הם זרם מחירים רציף שהדסק מעביר ללקוחות ולמערכות פנימיות: עושה השוק מפרסם שערים דו-כיווניים, האגרגטור מאחד אותם לספר אחד, ומעגל הסיכון מחשב מחדש את המגבלות בכל עדכון. כל עוד הכול מסונכרן, הדסק מרוויח מהספרד ומהמחזוריות. ברגע שאחד המשתתפים מפגר בשניות, הדסק החוץ-בורסאי מתחיל לסחור במחיר שכבר אינו קיים בשוק.
הכשל היקר ביותר הוא חוסר סנכרון הציטוטים בין המקור לצרכן. עושה השוק כבר הזיז את השער לאחר תנועת נכס הבסיס, אך שער הלקוח עוד מחזיק את הקודם: העסקה מתבצעת בשער מיושן, והפער הדסק מכסה מהמרווח שלו.
השני בשכיחותו הוא ניתוק הערוץ בין האגרגטור למודול הסיכון: המגבלות מחושבות לפי התמונה האחרונה שהגיעה, החשיפה גדלה מבלי לשים לב, והדבר מתגלה רק בהתאמה.
הסוג השלישי של כשלים הוא הידרדרות זרם המחירים עצמו: דילול עדכונים תחת עומס, אובדן רצף החבילות, כפילויות לאחר התחברות מחדש. כלפי חוץ המערכת חיה, הציטוטים זורמים, אך תדירותם יורדת פי כמה — וצדדי הארביטראז' הראשונים להסיר נזילות מהדסק, ומותירים לו את הצד הגרוע של הספרד.
בנפרד יש לציין חוסר סנכרון שעונים בין הצמתים: חותמות הזמן מתפצלות, ואי אפשר עוד לשחזר את סדר האירועים האמיתי לפי הלוגים.
המחיר של כל כשל כזה מדיד: ספרד מורחב, מגבלות שנשברו, בירורים ידניים של עסקאות ושעות מהנדסים שאבדו על התאמה. בהמשך נפרק כיצד זה נסגר — מארכיטקטורת הזרם ועד בקרת שלמותו.
ארכיטקטורת הזרימה: מצבי הפצה ומגבלותיהם
זרימת שידור
מחזיקה פיד שערים משותף אחד לכל הדסקים המחוברים: מכשיר מפורסם פעם אחת, ומשם מתפזר לכל המנויים. זהו המצב הזול ביותר מבחינת עומס — המקור מוסר את הנתונים פעם אחת, ולא N פעמים כמספר הנמענים.
המגבלה היא שכל דסק מקבל את כל הזרימה כולה: אם מתוך מאה מכשירים הוא זקוק לחמישה, תשעים וחמישה האחרים עדיין עוברים דרך הערוץ ויישום הלקוח. בערוץ צר זה יוצר השהיה, ובתנועות שיא של השוק — גידול בתור והתיישנות של השער עד שהוא מגיע למסך.
שערים ממוקדים
כאן הזרימה נבנית עבור נמען ספציפי: הדסק נרשם למכשירים שלו, והמקור מחזיק בחירה נפרדת לכל אחד. ההשהיה בצד הנמען יורדת, מכיוון שהערוץ אינו עמוס במיותר — בפועל זה ההבדל בין "השער הגיע ברגע הפרסום" לבין "הגיע באיחור של כמה עדכונים".
המחיר הוא מורכבות בצד המקור: יש לנהל מינויים, לעקוב אחר מחזור החיים שלהם ולהסיר אותם כראוי בעת ניתוק החיבור, אחרת המקור ימשיך לחשב עומס לפי דסק שהתנתק.
מודל היברידי
בפועל בוחרים לא "או-או", אלא שילוב: זרימת שידור כערוץ ראשי ומינויים ממוקדים עבור מכשירים בתדירות עדכון גבוהה. זה נותן עומס צפוי על המקור והשהיה נמוכה היכן שהיא קריטית.
יציבות הזרימה נשענת על שלושה דברים: בקרת שלמות הרצף (דילוג בעדכון חייב להיות גלוי, ולא נבלע), חיבור מחדש אוטומטי עם השלמת החסר, והפרדת הרשאות ברמת המינוי — הדסק רואה רק את מה שיש לו גישה אליו.
| וריאנט | מתי מתאים | מגבלות |
|---|---|---|
| שידור | הרבה דסקים, מגוון רחב של מכשירים, תדירות עדכונים נמוכה | תעבורה מיותרת לנמען, השהיה בערוץ צר |
| ממוקד | מעט נמענים, מגוון מצומצם של מכשירים, תדירות גבוהה | ניהול מינויים מורכב, העומס גדל עם מספר הדסקים |
| היברידי | דסקים הטרוגניים ודרישות שונות להשהיה | דורש הפרדה מפורשת של זרימות ולוגיקת חיבור מחדש אחידה |
FIX Protocol קובע את פורמט ההודעות ואת כללי המינוי, אך אינו מכתיב את טופולוגיית המסירה — אותה בוחרים לפי פרופיל העומס של הדסק הספציפי.
איך אנחנו בונים זרימה: מביקורת ערוצים ועד מסירה לדסק
קוטבוציות זורמות OTC — זה לא "לחבר API של בורסה", אלא לאסוף כמה מקורות הטרוגניים לזרימה אחת צפויה, שבה לדסק אין זכות להשהיה: בזמן שהניתוב חושב, הקוטבוציה מתיישנת, ואיתה הולכת גם העסקה. לכן את העבודה מתחילים לא מהקוד, אלא מסקר של מה שכבר קיים אצל הלקוח.
- ביקורת מקורות קוטבוציות. מפרקים כל ערוץ: פלטפורמות בורסאיות, אגרגטורים, מרקט-מייקרים, מחירונים פנימיים. מתעדים את תדירות העדכון, את הפורמט (FIX, WebSocket, REST-פולינג), את ההתנהגות בעת ניתוק ואת האופן שבו המקור מסמן נתונים מיושנים. בפלט — מפת מקורות עם החוזקות והחולשות שלהם.
- סכמת הזרימה. מתכננים את מסלול הקוטבוציה מהכניסה ועד הדסק: נרמול פורמטים, מודל אחיד של המכשיר, חוצץ למקרה של התפרצויות. הסכמה מסוכמת לפני תחילת הפיתוח — כך בשלב ההרכבה לא צצים "הפתעות" כמו בסיסי שעות שונים אצל הפלטפורמות.
- הגדרת ניתוב קוטבוציות. קובעים עדיפויות: איזה מקור נחשב ראשי, איזה משתלט בעת דגרדציה, לפי איזה כלל נבחר המחיר הטוב ביותר. כללי הניתוב מתוארים במפורש, ולא "כברירת מחדל" — אחרת בעת תקלה הדסק מקבל זרימה שפורמלית חיה, אך אינה ראויה לעסקאות.
- בדיקת עומס. מריצים את הזרימה בנפחים שיאיים ובתרחישי ניתוק קשר: בודקים איך מתנהג החוצץ, כמה זמן חי הקוטבוציה עד המסירה, מה קורה בעת כשל בו-זמני של שני מקורות. המטרה — לא "עבר", אלא הבנה של הגבולות שמעבר להם המערכת מדרדרת באופן צפוי.
- מסירה לדסק. מוסרים זרימה עובדת יחד עם תיעוד: סכמת ניתוב, תקנון החלפת מקורות, הוראות אבחון. הדסק צריך להיות מסוגל לתחזק את הזרימה בעצמו, בלי שיחת טלפון למפתח בכל ניתוק.
כל שלב מסתיים בארטיפקט שניתן לבדוק: מפת מקורות, סכמה, כללי ניתוב, דוח עומסים, תיעוד. תארו את המקורות שלכם ואת הדרישות לזרימה — נחזור עם הערכה ותוכנית עבודה.
במה שונה תפוצה ממוקדת מתפוצהbroadcast?
מודל הbroadcast הוא זרם אחד משותף שכל הצדדים הנגדיים המחוברים מקבלים, בלי התחשבות בתפקידם, במגבלותיהם ובמנויים שלהם. ה-deck מפרסם ציטוט לאוטובוס, ומכאן כל משתתף רואה את כל מערך הכלים, כולל אלה שהוא לא סוחר בהם.
זה פשוט ליישום, אבל השהיית המסירה גדלה באופן ליניארי עם מספר המנויים: ככל שהמניפה רחבה יותר, כך נדרש יותר זמן לסינון ולניתוב בצד המקבל, ואת מגבלות הצדדים הנגדיים יש לבדוק כבר לאחר קבלת הזרם — כלומר לסנן את העודף בדיעבד.
תפוצה ממוקדת בנויה הפוך: לכל צד נגדי יש פרופיל מנויים ומגבלות, והנתב שולח לו רק את הציטוטים שהוא רשאי לבצע. זה יקר יותר בכניסה — נדרש מרשם כללים ומצב עבור כל משתתף — אבל השהיית המסירה מפסיקה להיות תלויה במספר הכולל של המחוברים: הצד הנגדי מקבל זרם צר, ולא את כל השוק. מגבלות הצדדים הנגדיים נבדקות לפני השליחה, ולכן לערוץ לא יוצא ציטוט שאינו ניתן לביצוע מראש.
הבחירה במודל נקבעת לפי המשימה. תפוצהbroadcast מתאימה בשלב ההשקה, כאשר הצדדים הנגדיים מעטים וחשוב יותר לחבר את כולם במהירות באינטגרציה אחת.
תפוצה ממוקדת הופכת לחובה כאשר המשתתפים הם עשרות ויותר, לכל אחד מגבלות משלו ומערך כלים משלו, והפער בהשהיה בין מקבל מהיר למקבל איטי מתחיל להשפיע על איכות הביצוע.
בפועל משלבים בין המודלים: שכבת הbroadcast נושאת נתוני עזר ואינדיקטורים כלליים, והשכבה הממוקדת — את זרמי הציטוטים otc עצמם תוך התחשבות במגבלות. היבריד כזה נותן השהיית מסירה צפויה עבור צדדים נגדיים פעילים ולא מכריח את ה-deck להחזיק ערוץ נפרד עבור כל משתתף קטן.
מקרה בוחן: כיצד זרם הציטוטים הפסיק לפגר אחרי השוק
דסק OTC סחר בציטוטי זרם שנאספו ממספר מקורות ואוחדו ידנית. הפער בין הוויטרינה לביצוע בפועל הצטבר לעשרות שניות: עושה השוק הציג מחיר לפי חיתוך מיושן, והעסקה נסגרה כבר לפי מחיר אחר. כל מקרה כזה נבחן בדיעבד — השוו את יומן ההזמנות ליומן הציטוטים, וחיפשו באיזה שלב הנתונים התפצלו.
מה היה לפני
הזרם נאסף לפי לוח זמנים: האגרגטור סקר את המקורות, שמר את החיתוך במטמון, והדסק לקח אותו בשלמותו. בין הסקירה לבין ההגעה לוויטרינה חלפו כמה שניות, ועוד כמותן — על בדיקה ידנית בעת סטייה. הדסק לא ראה איזה מקור "פיגר", ולא יכול היה לחתוך ציטוט מיושן לפני הביצוע. התוצאה — אי-סנכרון שנתפס כבר בעסקה.
מה שינו
העבירו את האיסוף למודל מבוסס אירועים: כל עדכון מחיר מגיע כהודעה נפרדת, ולא כחבילה לפי טיימר. הוכנסה חתימת זמן של המקור וכלל חיתוך — ציטוט ישן מחלון מוגדר אינו נכנס לוויטרינה.
נוסף בקרת סטייה: אם מחיר המקור והמחיר האגרגטי נבדלים מעל הסף, הזרם מסמן את המכשיר כלא יציב ומסיר אותו מפרסום עד להתיישרות.
מה נהיה
| מדד הדסק | לפני | אחרי |
|---|---|---|
| השהיית הוויטרינה | שניות, משתנה | יציב בגבולות החלון |
| חישובים ידניים ביום | סדירים | בודדים, לפי אנומליות |
| סוג כשל "עסקה לפי מחיר מיושן" | חוזר | הוסר בתקנון החיתוך |
| בירור תקלה | השוואת יומנים ידנית | סימון מקור אוטומטי |
אי-הסנכרון הפסיק להיות תקלה שמחפשים בדיעבד: הוא נראה בזרם ברגע היווצרותו. הדסק קיבל זרם ציטוטים יציב וויטרינה צפויה — עושה השוק מציג מחיר לפי חיתוך עדכני, ולא לפי מה שהספיק להגיע.
את לוגיקת החיתוך ובקרת הסטייה בנו על עיבוד אירועים בזרם — Apache Kafka כתשתית וכללי ולידציה משלנו בצד הדסק.
ספקות לפני הטמעה: תאימות, חזרה לאחור, הרשאות גישה
לפני הפעלת ציטוטי OTC בזרימה, לקוחות שואלים לרוב את אותם הדברים: האם קווי המתאר החדשים ישברו ערוצים שכבר פועלים, האם ניתן לחזור לסכימה הקודמת, ואילו הרשאות גישה יהיה צורך לפתוח בפני הצוות שלנו. אנו עונים לגופו של עניין, משום ששלוש השאלות הללו הן שקובעות אם ההטמעה תהיה מבוקרת.
מה יקרה לערוצים הנוכחיים? קווי המתאר הזורמים מתחברים במקביל לקיימים: גשרי ברוקרים, סשנים של FIX וערוצים ידניים נשארים פעילים, והניתוב עובר למצב שונה ברמת השער.
תחילה הזרימה פועלת במצב השוואה — הציטוטים החדשים מחושבים אך אינם מפורסמים, ואתם רואים את הפער מול המקור הנוכחי לפני שמשהו משתנה בסביבת הייצור.
כיצד לחזור לאחור? תוכנית החזרה לאחור נקבעת לפני ההתחלה: החזרת הניתוב למקור הקודם היא החלפת תצורה, ולא כתיבה מחדש של קוד, ולכן אורכת דקות. מצב ספרי ההזמנות והמינויים של הלקוחות משוחזרים מהיומן, כך שהפער בציטוטים אינו נשאר בלתי מורגש.
האם יש לתת לצוות שלכם גישה לסביבת הייצור?
לא. אנו פועלים בקווי מתאר נפרדים עם רפליקה של נתוני השוק ומפרסים את הבנייה בעצמנו; הגישה לסביבת הייצור מתבצעת רק דרך נהלי האישור שלכם, עם הרשאות מוגבלות ותיעוד פעולות. ההרשאות נשללות עם סיום השלב.
מה אם יש לנו סטאק לא סטנדרטי? תאימות לערוצים הנוכחיים נבדקת בשלב הניתוח: אנו תומכים בפרוטוקולים נפוצים לאספקת ציטוטים ובפורמטים של הודעות, ומתאמים לא סטנדרטיים מתוארים בנפרד עם הערכת מאמץ.
הלקוח מקבל לידיו:
- תצורות השער וכללי ניתוב הציטוטים;
- תרשים זרימות נתונים עם נקודות כשל והטיפול בהן;
- מדיניות הרשאות ומטריצת הרשאות לפי תפקידים;
- נהלי חזרה לאחור עם תרחיש שלב-אחר-שלב;
- תיאור פורמטים של הודעות ומתאמים;
- יומני השוואה של הזרימה מול המקור הנוכחי;
- תיעוד לתפעול ולהעברת משמרת.
תארו את המשימה שלכם — נחזור עם הערכה ותוכנית המותאמת לקווי המתאר שלכם.
לוח זמנים ליישום זרם הציטוטים לפי שלבים
יישום זרם הציטוטים לשולחן OTC מחולק לשלבים בעלי רצף קבוע: כל צעד עוקב נשען על תוצאת הצעד הקודם, ולכן לא ניתן "להזיז ימינה" בלוק אחד בלי להרכיב מחדש את האחרים.
לוחות הזמנים המשוערים להלן הם משך העבודה, ולא תאריכים קלנדריים: התוכנית נשארת רלוונטית ללא תלות במועד ההתחלה, והמזמין רואה היכן בדיוק נמצא הפרויקט ומה קורה בכל קטע.
במקביל לליבה מובילים את חלק האינטגרציה — זהו המקור הנפוץ ביותר לעיכובים, מכיוון שפורמטים של מערכות מקבלות לעיתים רחוקות תואמים למודל הזרם. ההפעלה הניסיונית מתבצעת על נתונים אמיתיים, אך ללא ניתוק הערוץ הנוכחי: אי-ההתאמות מנותחות לפני שהזרם החדש הופך לעיקרי.
לוח הזמנים הסופי של היישום תלוי במספר המקורות המחוברים ומערכות הצריכה — לאחר הסקר נמסור משך עבור קווי המתאר שלכם, ולא ממוצע שוקי.