מערכת התחשבנות לעסקאות OTC: אוטומציה של סליקה עם DVP וריבוי חתימות

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

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

שאלות נפוצות

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

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

מדוע OTC settlement system מתפרקת בהתאמות ידניות

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

ברגע זה otc settlement system חיה רק בראשם של האופרטורים: מקור אמת אחיד לגבי מצב העסקה אינו קיים אצל אף אחד מהצדדים.

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

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

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

מה נותן settlement מנוהל: מהירות, מגבלות, כשלים

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

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

מה לבדוק בדוח ההשפעות

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

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

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

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

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

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

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

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

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

ערכת מסירה: נהלים, מפתחות, מדיניות חתימה

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

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

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

מקרה בוחן: קיצרנו את מחזור הסליקה והסרנו מחלקת כשלים

איך זה היה

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

מה שינינו ומה נהיה

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

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

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

במה סליקה «אספקה כנגד תשלום» שונה מהפקדה?

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

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

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

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

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

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

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

מי מחזיק במפתחות החתימה וכיצד לשחזר גישה?

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

מה קורה אם כשל יתרחש אצל הצד שכנגד?

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

כיצד זה משתלב עם מערכת הרישום שלנו?

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

כיצד מאושרת אספקה בפועל?

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

מה יקרה לעסקה שלא הושלמה?

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

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

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

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

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