מרקטפלייס של אסטרטגיות מסחר: ביצוע מבודד ובדיקות לאחור

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

שירותי פיתוח בלוקצ'יין

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1376
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1350
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    798
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1088
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1034
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1130

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

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

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

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

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

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

מה נותן ביצוע מבודד של אסטרטגיות

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

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

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

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

מצבי בידוד: השוואת גישות

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

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

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

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

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

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

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

ארטיפקטים: תרשימים, מדיניות גישה, נהלים

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

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

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

מקרה בוחן: הבידוד הסיר כשלים מדורגים

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

מה שינו

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

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

מדדים לפני ואחרי

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

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

במה שונה ביצוע מבודד ממעגל משותף?

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

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

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

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

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

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

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

אנחנו כבר סוחרים — יהיה צורך לכתוב מחדש את האסטרטגיות?

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

מהי עומק ההיסטוריה הנדרש?

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

האם הפלטפורמה מקבלת גישה לחשבונות של המנויים?

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

מה קורה בשעות שיא?

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

עד כמה מהימנה הבדיקה של האסטרטגיה?

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

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

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

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

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

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

תארו את המשימה בצורה חופשית — נחזור עם הערכה ותכנית.