הגדרת FATF Travel Rule ל-VASP: Notabene וארנקים לא מאוחסנים

FATF Travel Rule: היכן נשבר חילוף הנתונים בין VASP

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

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

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

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

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

מה נותן חילוף נתונים מוגדר: אפקט במדדים מדידים

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

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

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

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

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

דרכים להעברת נתונים לפי Travel Rule: השוואת אפשרויות

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

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

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

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

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

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

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

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

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

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

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

מקרה בוחן: חילוף עם ארנקי unhosted בלי בקשות ידניות

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

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

מה שינו

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

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

מה התוצאה

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

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

במה ארנק hosted שונה מ-unhosted ומה זה משנה

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

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

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

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

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

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

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

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

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

מה יקרה במסירה חוזרת של העברה?

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

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

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

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

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

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