כלל נסיעות לתשלומי קריפטו

1) מהו כלל המסע ומדוע הוא נחוץ

חוק הנסיעות (באנגלית: Travel Rule) היא דרישה רגולטורית לספקי נכסים וירטואליים (VASPs) להחליף את השולח ואת הזהויות הנמענות בעת העברת נכסי ההצפנה. המטרה: להפחית סיכוני AML/CTF, לפשט את החקירות ולהגביר את השקיפות של העברות VASP, תוך שמירה על יכולת הפעולה של התשתית המקוונת.

• המידע ”עובר” עם התרגום (off-chain communication channel VASP↔VASP).
• דרישות וסף שונים על פי תחום השיפוט; לעתים קרובות הסף קרוב ל-1000 (שווה ערך), אבל במספר דרכים הוא חל על כמויות קטנות יותר - לתקן את הנורמה המקומית במדיניות שלך.
• דרישות מבדילות בין ארנקים (מארחים) לבין ארנקים (בלתי תלויים).

2) אובייקטים ואזורים ביישום

VASP * VASP (אירח ↔): החלפה מלאה של נתונים לפי הסטנדרט (רצוי לפני השידור המקוון).
VASP # Unhosted: איסוף/אימות של מידע אודות הכתובת ומקור הכספים תחת מדיניות RBA המקומית; אין חליפין עם ”VASP המקביל”.
השתמש בדיסקברי/ספרייה והסכמי נאמנות כדי למצוא מקביל וערוץ מאובטח.

3) אילו נתונים מועברים (הרכב מינימלי)

• שם (או שם. ), מזהה ייחודי של הלקוח (מהמערכת שלך),
• כתובת/מדינה או תאריך לידה (מדינה ספציפית),
• מספר חשבון/ארנק (זיהוי פנימי/כתובת),
• מגעים (אם נדרש), זיהוי VASP (LEI/BIC/Reg. מספר - שבו ישים).

• שם (אם הנמען נמצא ב-VASP אחר ומאומת),
• זיהוי חשבון/ארנק במוטב-VASP,
• מידע שנאסף מהלקוח בהתאם למדיניות שלך.

• נכס/רשת (BTC, ETH/chain), כמות, חותמת זמן,
• זיהוי תשלום/העברה, התייחסות לבדיקת TAC/סנקציה,
• זיהוי של כלל הנסיעה סשן/הודעה.

4) החלפת תקנים ופרוטוקולים

IVMS101 - מודל נתונים (מה ואיך לנקוב).
TRISA/TRP/OpenVASP - פרוטוקולי רשת ו ”רשתות אמון” (PKI, mTLS, ספריות VASP, ניתוב, אישור משלוח).
Hubs/Aggregators מסחרי יכול ליישם גישה בין-אופרטיבית (Gateway approach) ודיסקברי (Discovery).

המלצה: אבסטרקטי התעבורה (Adapter layer) ואחסון IVMS101 כ ”מודל קנוני” על מנת לשנות בחופשיות את הספק/פרוטוקול מבלי לשבור את API.

5) ארכיטקטורת יישום (התייחסות)

1. כלל תנועה (Microservice): קבלת/שליחת הודעות IVMS101, חתימה/הצפנה, מגשים מחדש, מכסות.

2. Directory/Discovery: חיפוש נגד VASP (רישום, PKI, מדיניות אמון).

3. מנוע KYT/סנקציות: כתובת/החלפה/סריקת אשכול, הערכת סיכונים לפני המשלוח.

4. מנוע ציות (RBA): אפשר/להחזיק/לדחות/לבקש מידע נוסף.

5. ניהול מקרים: מקרים, מצורפים, SLAs, הסלמה (L1/L2/L3).

6. כספת PII: אחסון מאובטח של נתונים אישיים (הצפנה, טוקניזציה, RBAC, ביקורת חשבונות).

1. הלקוח יוצר העברה = 2) TAC/preprechein-check survices # 3) Exchange of IVMS101 (לפני onchen) * 5) החלטה (let/hold) * 6) Onchein-broadcast # 7.

6) ארנקים לא מנותקים: פוליטיקה ובדיקות

אוסף מידע על המקביל מהלקוח (שם/מדינה/יחס), אישור הבעלות על הכתובת (חתימה עם הודעה, ”העברת הוכחה” קטנה, אימות על ההחלפה).
כללי סיכון: איסור/הגבלה על כתובות עם סיכון KYT גבוה (מערבלים, שווקים ”אפלים”, אשכולות סנקציות), איסור על אתרי P2P ללא KYC בהתאם למדיניות שלך.
פנקס כתובות/לובן עם TTL וסקירה.

7) אינטגרציה עם TAC/סנקציות ו ־ AML

KYT (Know Your Transaction): הערכת סיכונים של כתובות/החלפות, קשרים עם N-hops עם אשכולות ”רעים”, אנומליות נפח/מסלול.
סנקציות: סריקת לקוח/עמיתים (KYC/KYB) ותשתיות (החלפות, משמורת).
SOF/SOW ו/או דחייה, במידת הצורך - SAR/STR.

8) נתונים ופרטיות (GDPR/אבטחה)

מזעור: שמרו רק את שדות כלל הנסיעות הנדרשים; להפריד את מח "ש מהתשלום PANs/keys.
הצפנה: במנוחה (KMS/HSM) ובמעבר (MTLS), סיבוב מפתח.
גישה: RBAC קפדני, יומן פעולה, עקרון הצורך לדעת.
שימור: לפי חוק השיפוט (לרוב 5 + שנים); תפוגה אוטומטית ודוחות מחיקה.
DSR: גישה/תיקון/הליכי מחיקה היכן שניתן.

9) SLA, מגשים מחדש והשפלה

• בדיקה מקדימה (KUT/סנקציות): דו-שיח 5-15 C p95.
• Discovery + Exchange (VASP↔VASP): 60- 120 C p95 (כולל מגשים מחדש).
• פתרון (let/hold/deme): 2-5 min p95 עבור מקרים אוטומטיים; סקירה ידנית בסיכון גבוה - 4 שעות.

• גיבוי מעריכי + jitter; נקודות סוף חלופיות.
• בעיית הזריחה (מקבילה אינה תומכת ב-Travel Rule): חריגים/גבולות RBA, החלפה ידנית על פני ערוץ מוצפן (אם מותר על ידי מדיניות/חוק) או סירוב.

10) תבניות UX (לא שבירת המרה)

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

11) מדדים ובקרת איכות

• כיסוי כלל תנועה% (הנתח של העברות VASP↔VASP עם החלפה מוצלחת של IVMS101).
• שיתוף של לא מנותק עם אימות כתובת עבר ו SOF (על ידי סף).
• קצב חיסול SLA על ידי החלפת/פתרונות; נתח של מקרים ידניים.

• שיעור סיכון גבוה של KYT, סנקציות, המרת SAR.
• התראות חוזרות ונשנות על ידי כתובות/אשכולות, חולקים ”חיובי כוזב” על ידי KYT.

• זמן להעביר p50/p95, סירוב עקב חוק הנסיעה (פגיעה), המרת העברות חוזרות (פנקס כתובות).

12) מטריצת החלטה (סקיצה)

13) אנטי דפוסים

שליחה מקוונת לפני סוף החלפת הנתונים VASP↔VASP (במצבים בהם היא נדרשת לפני התרגום).
”חירש” חסימה של כל לא מנותק ללא יוצא מן הכלל RBA ואימות כתובת.
העדר Discovery/Directory Liver לא יציב ואחיזת שווא תכופה.
אחסון של PII מיותר ללא יעד/חזרה; יומנים מופרדים ומח "ש.
עניבה קשיחה עבור ספק פרוטוקול אחד ללא אבסטרקציה (lockor-in).

14) רשימת מימושים

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

[ ] מודל IVMS101 קנוני ושכבת מתאם תחת TRISA/TRP/OpenVASP.

Directory/Discovery BrothPKI/mTLS; ניהול VASP מהימן.

[ ] אינטגרציה של TAC/סנקציות לבדיקה מראש; להחזיק/לדחות כללים.

[ ] כספת PII: הצפנה, RBAC, ביקורת, שימור/DSR.

[ ] SLA/מגשים/התראות, לוחות מחוונים של מדדים; מחברות משחקים מושחתות.

[ תהליכים ] ללא שינוי: אימות כתובת, בקשות SOF, הלבנות.

[ ] ניהול מקרה ותבנית תקשורת; נהלי SAR/STR.

[ ספסלי מבחן ]: הדמיה של מקביל VASP, תסריטי כישלון, בדיקת עומס.

[ ] תשלומים/סיכונים/ציות/אימוני תמיכה ותרגולים קבועים.

15) סיכום

כלל הנסיעה הוא לא ”על קריפטה”, אלא על החלפת מידע מבצעי מאובטח בין VASP. לבנות שער עם IVMS101 כמודל קנוני, לחבר את Discovery/Directory, לשלב את TAC/סנקציות ופתרונות RBA, להגן על PII ולציין SLAs מובנים. ואז העברות VASP↔VASP ועבודה עם כתובות לא מנותקות יהיו מהירות, צייתניות ולא יהרסו את ההמרה.