אינטגרציה של Notabene: ציות ל-Travel Rule עבור בורסות קריפטו

Travel Rule compliance עבור בורסות קריפטו: היכן נשבר חילוף הנתונים

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

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

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

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

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

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

מה משנה ההטמעה: לוחות זמנים לחיבור, דחיות, השבתות

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

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

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

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

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

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

דרכי חיבור: צומת משלכם, שירות מתווך, היברידי

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

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

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

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

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

מה מוסרים לידיים: תצורות, סכמות, נהלים

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

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

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

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

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

כיצד זה היה מסודר לפני ההטמעה

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

מה שינו

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

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

כיצד עוברת בדיקת הציות בעת חיבור צד שכנגד?

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

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

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

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

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

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

ספקות טכניים: יומנים, אחסון נתונים, התראות כוזבות

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

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

מה יקרה להעברה אם הערוץ אל הצד שכנגד נפל?

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

האם לא נטבע בהתראות כוזבות?

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

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

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

מה ייכלל בתכנית העבודה ובחיבור ניסיוני של צד שכנגד אחד:

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

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