פיתוח מערכת היסטוריית מסחר מאומתת כפתרון מלא

היסטוריית מסחר מאומתת: היכן נשבר האמון בנתונים

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

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

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

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

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

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

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

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

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

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

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

מצבי רישום: מרשם מלא, היברידי ואישור חיצוני

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

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

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

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

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

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

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

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

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

4. התאמת בקרה. הרצה של נתונים היסטוריים, התאמת מצרפים מול מערכות הנהלת חשבונות, ניתוח אי-התאמות. סף המותר נרשם מראש.

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

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

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

קונפיגורציות, סכמות נתונים ומדיניות גישה

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

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

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

מקרה בוחן: איך התאמת עסקאות הפסיקה לארוך שבועות

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

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

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

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

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

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

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

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

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

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

ספקות טכניים: שלמות, עומס, שאילתות מבקרים

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

האם זה לא יעמיס יתר על המידה על מערכת המסחר?

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

לאן הולכים הנתונים האישיים של לקוחות?

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

כיצד מחברים מסלולים וזירות חדשים?

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

נדון במשימה: נבנה תכנית למסלול המסחר שלכם

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

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

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