פיתוח מערכת RFQ: היכן נשברת הזרימה הידנית של בקשות
כל עוד יש עשר בקשות למחיר ביום, הזרימה חיה בהתכתבות. לקוח כותב בצ׳אט, סוחר עובר בין צדדים נגדיים בזה אחר זה, התשובה נאספת ידנית בטבלה — ולא כל בקשה מגיעה לעסקה. כשהנפח גדל לכמה עשרות בקשות ביום, ועם סט צדדים נפרד לכל נכס, הסכמה נתקלת בזמן הפיזי של אדם אחד.
צוואר הבקבוק כאן אינו בנזילות, אלא בהשהיית התשובה. כל עוד הציטוט עובר בשלושה ערוצים מפוזרים, המחיר בנכס תנודתי בורח, והלקוח — למי שענה ראשון. פער של דקות במשא ומתן הופך לנפחים אבודים ולהרגל לשאול לא אתכם.
איסוף ציטוטים ידני מוסיף גם שגיאות במחירים. שורה מיושנת בטבלה, ציטוט שהועתק לא נכון, גודל לוט בלי התחשבות בעמלת הצד הנגדי — והעסקה נסגרת במחיר שאף אחד לא מוכן לבצע בו. פערים כאלה צפים מאוחר יותר, בבדיקה, כשכבר אין מה לשנות.
בהמשך נפרק איך זה נסגר: היכן מערכת RFQ מסירה את ההשהיה באמצעות שאילתה בו-זמנית של צדדים נגדיים, היכן נדרשים בקרת סיכון ומגבלות, והיכן אוטומציה לא תיתן דבר בלי נתונים מנורמלים על מכשירים.
מה משתנה במעגל המסחר לאחר ההשקה
את ההשקה יש להעריך לא לפי עצם ההטמעה, אלא לפי מדדי מעגל המסחר. בפיתוח מערכת RFQ אנו קובעים מדידה בסיסית לפני ההתחלה, ואחר כך מציגים את אותם מדדים בפרודקשן — אחרת אין במה להוכיח את האפקט.
מהירות עיבוד בקשה
לפני ההשקה הבקשה עברה דרך צ׳אט וטבלה: בזמן שהסכימו על צד וגודל, המחיר ברח, וחלק מהבקשות נסגרו בסירוב. במעגל החדש הבקשה נכנסת לתור עם עדיפות, המנוע בוחר את הציטוטים הטובים ביותר לפי מאגר נזילות ומחזיר תשובה בשברירי שנייה.
תפוקה גדלה לא על חשבון אנשים: מעגל אחד מחזיק מאות בקשות בו-זמנית, וזמן התשובה נשאר יציב בשיאי תנודתיות. חציון זמן התשובה ושיעור הבקשות שנענו בתוך סף מוגדר מוצגים בדשבורד בנפרד לכל נכס ולכל צד נגדי.
שיעור הציטוטים האוטומטיים ללא מעורבות ידנית
האפקט המרכזי — ציטוטים שנשלחים ללקוח בלי סוחר. כללי תמחור, מגבלות לפי צדדים נגדיים וספרד מתוארים בקונפיגורציה: המערכת מחליטה בעצמה מה לצטט, מה לדחות והיכן נדרשת אסקלציה לאדם.
ידניים נשארים חריגים מודעים — נפח גדול, נכס לא סטנדרטי, צד נגדי חדש בלי היסטוריית עסקאות. השיעור שלהם נמדד ויורד ככל שהכללים מתרחבים, ולא נקבע לפי העין.
בנפרד אנו סופרים סירובים שנמנעו: בקשות שאבדו בעבר בגלל פסקי זמן, אי-התאמת נתונים בין הצ׳אט לעסקה או יתרה שגויה בחשבון. כעת לכל אחת יש סטטוס וסיבה — לפי הסטטיסטיקה הזאת רואים מיד היכן נשאר צוואר בקבוק.
דרכי ביצוע RFQ: מאגר, עושה שוק, היברידי
בקשת ציטוטים נסגרת בשלוש דרכים, והבחירה ביניהן היא בחירה בין שליטה במחיר להבטחת ביצוע. מאגר נזילות מעביר חישוב המחיר הטוב ביותר לאלגוריתם, עושה שוק — לצד נגדי מסוים, והיברידי מחלק את הנפח בין שניהם. ההבדל מתגלה בתנועות חדות בשוק, כשציטוטים אינדיקטיביים מתרחקים ממחיר העסקה בפועל.
| אפשרות | מתי מתאים | מגבלות |
|---|---|---|
| מאגר נזילות | עסקאות שוטפות בזוגות נזילים, נפח בגבולות עומק המאגר | ציטוט מחייב אינו מובטח: המחיר תלוי בהחלקה |
| עושה שוק | נפח גדול או לא סטנדרטי, מכשירים מחוץ לבורסה | תלות בצד הנגדי: מגבלות, סירוב בתנועת שוק חדה |
| היברידי | נפח גדול מעומק המאגר, נדרש תקרת סיכון לצד הנגדי | ניתוב וחשבונאות ביצועים חלקיים מורכבים יותר |
איך לבחור לפי נזילות
הפרמטר המרכזי — יחס בין נפח הבקשה לעומק המאגר. כל עוד הנפח נכנס בעומק, הבקשה עוברת למאגר: עושה שוק בגודל כזה ייתן ציטוט גרוע יותר. כשהנפח עולה עליו, המאגר מתחיל להזיז את המחיר — ואז ציטוטים אינדיקטיביים נאספים מעושי שוק, ומחייבים נקבעים לתקופה מוגבלת.
סכמות משולבות
ביצוע היברידי מאפשר לסגור את רוב הנפח במאגר ולהשלים את היתרה אצל עושה שוק, בלי לחשוף את הבקשה כולה. חשובים כללי עדיפות: איזה מקור מקבל נפח ראשון, איך מתחלק ביצוע חלקי ומה קורה אם ציטוט מחייב בוטל לפני העסקה. כללים אלה נקבעים בקונפיגורציה של המערכת, ולא בתקנון על הנייר.
שלבי הטמעה: אבחון, סכמה, הגדרה, מסירה
סדר העבודות זהה גם כשהמערכת נבנית מאפס וגם כשהיא מחליפה תיאום מחירים ידני בהתכתבות. כל שלב נסגר בארטיפקט — סכמה, קונפיגורציה, פרוטוקול בדיקה — שאתם מאשרים לפני תחילת השלב הבא. בסיום לא מתגלה שלוגיקת החישובים סוטה מהחשבונאות.
- אבחון תהליכים — מפרקים איך כיום נאספות בקשות, מי מאשר מחיר, היכן נרשמות המגבלות ואילו פערים כבר נוצרים.
- סכמת זרימות — מתארים את מסלול בקשת הציטוט מהלקוח ועד אישור העסקה, כולל סירוב, ביצוע חלקי ותפוגת תוקף.
- מודל תפקידים — מפרקים הרשאות: לקוח, סוחר, בקרת סיכון, מפעיל סליקה; לכל תפקיד סט פעולות ומגבלות משלו.
- הגדרת ציטוט — כללי בחירת מחיר, תוקף הציטוט, מגבלות לפי צד נגדי, מכשיר ונפח.
- בדיקת חישובים במעגל בדיקות — הרצת תרחישים עם תוצאה ידועה מראש והשוואה לחישוב ידני.
- קבלה — הדגמה על הנתונים שלכם, רישום הערות והרצה חוזרת של תרחישים בעייתיים.
- מסירת תיעוד — קונפיגורציות, נהלי עבודה, הוראות לסוחרים ולתמיכה.
אישור סכמת זרימות
את הסכמה מגנים לפני ההגדרה: עליה רואים היכן בקשה יכולה להיתקע, כיצד המערכת מתנהגת בביצוע חלקי ומה קורה לציטוט לאחר תום התוקף. תיקונים בשלב הזה עולים שעות, אחרי ההשקה — שבועות של עבודות מחדש בחשבונאות.
בדיקת חישובים במעגל בדיקות
מעגל הבדיקות חוזר על כללי הפרודקשן, אך עם נתונים וחשבונות נפרדים. מריצים תרחישים עם תשובה ידועה, משווים תוצאות לחישוב בלתי תלוי, ורק לאחר התאמה מעבירים את ההגדרות למעגל העבודה.
חבילת מסירה: קונפיגורציות, סכמות, תפקידים, נהלים
לאחר השקת מערכת RFQ נשאר אצל המזמין לא רק מעגל עבודה, אלא גם סט מלא של ארטיפקטים — בלי ״קופסאות שחורות״ שרק הקבלן יכול לתחזק. מאגר עם קונפיגורציות ותיאורים נמסר לצוות המזמין, והוא מפתח את המערכת בכוחות עצמו.
- קונפיגורציות סביבות: מגבלות לפי מכשירים, זמן תגובה מקסימלי לציטוט, כללי חישוב מרג׳ין.
- סכמות אינטגרציות: זרימות נתונים בין הממשק, שירות הציטוט, מודול הסיכון והצדדים הנגדיים.
- מדיניות גישה: מטריצת תפקידים עם תיאור הנתונים והפעולות המותרות.
- נהלים: הפצת עדכונים, תוכנית חזרה לאחור, פעולות תורן בעת ירידה באיכות הציטוט.
- יומני ביקורת: פורמט רישום, תקופות שמירה, סדר ייצוא לאחסון חיצוני.
- סט בדיקות אוטומטיות: חישוב ציטוט, הפעלת מגבלות, ביצוע עסקה.
מדיניות גישה
התפקידים מתוארים דקלרטיבית ונמצאים במאגר לצד הקוד, ולא רק בפאנל הניהול. עושה שוק רואה את הציטוטים שלו, הסוחר מוגבל במגבלה לצד נגדי, המבקר קורא נתונים בלי הרשאת שינוי. עריכה של מטריצת התפקידים עוברת רוויו ונרשמת ביומן — הרחבת הרשאות לא נשארת בלתי מורגשת.
יומני ביקורת
כל פעולה משמעותית — בקשת ציטוט, אישור עסקה, שינוי מגבלה או תפקיד — נרשמת עם מזהה משתמש וחתימת זמן בלתי ניתנת לשינוי. הרשומות מיוצאות לאחסון חיצוני, השלמות מאוששת בשרשרת האשים, ולכן אי אפשר להכניס תיקון בדיעבד. השכבה הזאת מאפשרת לעבור בדיקת צד נגדי בלי השוואה ידנית של ייצואים.
מקרה בוחן: כיצד גדלה תפוקת הבקשות
את התור הראשון של מערכת RFQ בנינו לדסק מחוץ לבורסה Aurum Markets: בקשות לעסקאות גדולות אוחדו ידנית, הסוחר אסף ציטוטים בטבלה ואישר כל זוג בקול. כבר בשיא של 300 בקשות בשעה התור גדל מהר יותר מקצב התשובות של הסוחרים, וחלק מהבקשות עברו לצדדים נגדיים אחרים.
המדידות נלקחו על אותו נפח בקשות לפני הריליז ואחרי חודשיים של עבודה. זמן העיבוד הממוצע של בקשה ירד מ-40–50 שניות ל-6. שיעור הסירובים בגלל חריגת זמן המתנה ירד מ-8% ל-0.4%. עומס שיא המערכת מחזיקה כעת בלי ירידה בביצועים — 1200 בקשות בשעה לעומת 300 לפניה.
״בשיא איבדנו בקשות רק מפני שחישבנו מחיר זמן רב יותר ממה שהלקוח היה מוכן לחכות״, — מנהל תחום המסחר.
״צוואר הבקבוק לא היה בציטוט, אלא בתיאום: כל שלב חיכה לאדם״, — מהנדס פרויקט ראשי.
מה נשאר מחוץ לתור הראשון
לתור השני הועברו גידור אוטומטי בזירות בורסה, תמיכה באופציות וחלוקת מגבלות בין צדדים נגדיים. התור הראשון סגר את זרימת הבקשות, כללי התמחור וביקורת מלאה של עסקאות — זה הספיק כדי להסיר את העומס בשיא ולסלק אישורים ידניים.
במה שונה ציטוט אינדיקטיבי מציטוט מחייב
ציטוט אינדיקטיבי הוא נקודת ייחוס, לא התחייבות: עושה שוק מציג הערכה שבה הוא מוכן לדון בעסקה, אך שומר לעצמו זכות לעדכן אותה לפני אישור. מצב כזה מתאים בשלב הערכת טרום-מסחר, כשהלקוח מעריך נפח ומכשיר ולזירה חשוב לא לחשוף עניין אמיתי בנכס לפני הזמן.
ציטוט מחייב הוא התחייבות לבצע במחיר נקוב בתוך תוקף הציטוט. התוקף נקבע בבקשה עצמה או בפרופיל המכשיר: קצר לזוגות תנודתיים, שבהם הסיכון להערכה מחדש גבוה, ארוך לנפחים גדולים שעושה השוק מספיק לסגור בגידור.
חשיפת המחיר מפרידה בין המצבים עוד יותר. ציטוטים אינדיקטיביים נמסרים לעיתים עם נפח מוסתר חלקית — כדי שהעניין לא ידלוף לספר הפקודות ולא יזיז את השוק לפני העסקה. ציטוט מחייב נחשף ממוקד ובאופן מלא: הצד הנגדי רואה מחיר, נפח ותוקף, כי הוא חותם על ביצוע בדיוק לפי התנאים האלה.
כשמחירים מתרחקים עד רגע העסקה, פועל מודל מצבים. הציטוט חי כעצם עם טיימר: כשהתוקף פג, הוא עובר למצב לא פעיל, ואי אפשר לחתום לפיו. אם המחיר ברח בתוך התוקף — או שעושה השוק מבצע לפי שלו ונושא בסיכון הערכה מחדש, או שנדלק אישור חוזר, והציטוט חוזר למצב אינדיקטיבי.
לכן במערכת RFQ תוקף, כללי חשיפה ורגע קיבוע המחיר נקבעים במודל הנתונים, ולא נשארים לשיקול דעת המשתתפים. אז השאלה ״איזה מחיר היה רלוונטי״ נפתרת לפי לוג המצבים של הציטוט, ולא לפי התכתבות בין הצדדים.
ספקות טכניים: גישות, מגבלות, אמינות
לפני תחילת פיתוח מערכת RFQ המזמין בודק בדרך כלל כמה היבטים טכניים: איך מופרדות הגישות של עושי שוק, מה יקרה בניתוק תקשורת והאם אפשר לשחזר אחר כך את תמונת המסחר. להלן תשובות לשאלות שעולות לרוב בשלב ההערכה.
הפרדת הרשאות של עושי שוק
לכל עושה שוק מוקצה תפקיד נפרד עם סט מכשירים ומגבלות נפח משלו. הוא רואה רק בקשות שנשלחו אליו ואינו יכול להציע ציטוט מעל המסדרון המוסכם. המגבלות נקבעות לזוג נכסים ומשתנות בלי לעצור את המסחר, וכל פעולות התפקיד נרשמות ביומן העסקאות.
איך מונפקות גישות לעושי שוק ומי מבטל אותן?
גישה מונפקת לתפקיד מסוים, ולא ״לאדם״: מפתחות חיים זמן מוגבל ומבוטלים בפעולה אחת של מנהל. הביטול נכנס לתוקף מיד — סשנים פעילים נסגרים בצד השירות.
מה יקרה בניתוק תקשורת או נפילת צומת?
המערכת נפרסת בכמה צמתים, התעבורה עוברת אוטומטית. בקשות שלא הושלמו משוחזרות מהיומן — הציטוט לא הולך לאיבוד ברגע התקלה.
איך בודקים שהעסקה בוצעה לפי התנאים המוצהרים?
כל עסקה נבדקת מול היומן ומקור מחיר בלתי תלוי. פער נראה מיד ומטופל לפני סגירת היום.
האם אפשר להגביל נפח לעושה שוק מסוים?
כן — המגבלות נקבעות לתפקיד ולזוג נכסים, בנפרד לפי מספר בקשות ולפי נפח. עם מיצוי המגבלה עושה השוק מקבל סירוב, והמסחר של האחרים אינו נפגע.
איך עובר בדיקות לפני ההשקה?
תחילה מצב צל: זרימת בקשות עוברת, ציטוטים מחושבים, אך עסקאות אינן נסגרות. זה מאפשר להשוות את התנהגות המערכת ורשומות היומן לפני תחילת העבודה.
נדון במשימה ונחזור עם הערכה ותוכנית
כדי לחזור עם הערכה ותוכנית, ולא עם תור של שאלות הבהרה, חלק מהנתונים המקדימים כדאי לאסוף מראש. להלן מה שבאמת משפיע על הארכיטקטורה של מערכת RFQ, על מאמץ העבודה ועל סדר העבודות; את השאר המהנדסים שלנו יבהירו בעצמם.
- הרכב הבקשה: אילו שדות מכילה בקשת הציטוט — נכס, נפח, כיוון, תוקף מחיר — ומי עונה עליה: ספק נזילות אחד או מאגר.
- רשימת אינטגרציות: מקורות מחיר, ספק קסטודיה, מערכת חשבונאית או לקוחית, ערוצי התראות. סמנו היכן כבר קיים ממשק תוכנה מוכן והיכן החילוף נעשה ידנית.
- תפקידים וגישות: מי מהעובדים רואה ציטוטים של אחרים, מי מאשר עסקה, איך נרשמת היסטוריית פעולות ומה מכך רואה הלקוח.
- נהלים ומגבלות: הגבלות לפי נפח ונכס, כללי דחיית בקשה, דרישות אבטחת מידע לשמירת מפתחות חתימה.
- תהליך נוכחי: איך עסקאות עוברות כיום — טבלאות, התכתבות, מסוף. זה מיד מראה מה מתומכן ראשון.
- דיווח: אילו ייצואים ויומנים נדרשים, באיזו תדירות ובאיזה פורמט מצפים לקבל אותם.
מהסט הזה אנו מרכיבים הערכת לוחות זמנים לפי שלבים, תוכנית הטמעה עם נקודות קבלה ביניים ורשימת תלויות בצד המזמין. שלחו נתונים בחלקים — די במה שכבר נאסף כדי להתחיל לפרק את המשימה.