מדוע הפרויקט שלך נמצא בסיכון ללא שירותי ציות לבלוקצ'יין?
אנו רואים שהנוף הרגולטורי בתעשיית הקריפטו משתנה מהר יותר מכפי שפרוטוקולים יכולים להסתגל. אם הפרויקט שלך פועל באיחוד האירופי, MiCA אינו עוד המלצה אלא דרישה מחייבת. כלל הנסיעות של FATF נמצא בתוקף כבר מספר שנים, אך האכיפה בפועל הולכת וגוברת. פרוטוקולים שמושקים ללא ארכיטקטורת ציות משנים אותה מאוחר יותר תחת לחץ—זה יקר יותר, כואב יותר, ומסכן את זמינות המערכת. שירותי ציות לבלוקצ'יין מכסים את המחזור המלא: מניתוח פערים ועד השקה ותמיכה במהלך קבלת רישיון. יישמנו 15+ פרויקטי AML/KYC עבור בורסות קריפטו ו-DeFi, תוך עבודה עם Chainalysis, Elliptic, Sumsub, TRM Labs. עיבדנו למעלה ממיליון עסקאות בניטור on-chain, עם שיעור חיובי שגוי ממוצע של 2.3% לבדיקת AML.
מדוע כלל הנסיעות הוא אתגר טכני, לא משפטי?
ההמלצה ה-16 של FATF (הידועה בבנקאות כ-FinCEN Travel Rule) מחייבת VASP להעביר נתוני KYC של שולח ומקבל מ-VASP אחד למשנהו עבור העברות מעל סף מסוים (משתנה לפי תחום שיפוט). דרישה זו, שהועתקה מהעברות בנקאיות מסורתיות, יוצרת בעיות טכניות בבלוקצ'יין שאינן קיימות ב-SWIFT.
הבעיה הראשונה היא קביעת VASP-ל-VASP. אם משתמש שולח מכתובת בורסה עם אחסון נאמנות לכתובת ארנק עצמי, כלל הנסיעות של FATF אינו חל מכיוון שצד אחד אינו VASP. אך כיצד VASP קובע אוטומטית שכתובת היעד היא אכן ארנק עצמי ולא VASP אחר? הפתרון: ניתוח on-chain (Chainalysis, Elliptic, TRM Labs) לקיבוץ כתובות + שימוש בפרוטוקול כלל הנסיעות רק עבור VASP-ל-VASP.
הבעיה השנייה היא יכולת פעולה הדדית בין VASP. קיימים מספר פרוטוקולים לכלל הנסיעות: TRUST (קונסורציום תחת Coinbase/SWIFT), TRISA (מבוסס gRPC, תקן פתוח), OpenVASP (מבוסס Ethereum), Sygna Bridge. הם אינם תואמים זה לזה. רוב הבורסות הגדולות תומכות במספר פרוטוקולים בו-זמנית. היישום הטכני הוא שער API שמזהה את הפרוטוקול של הצד השני ומנתב את הבקשה.
יישום TRISA (הפתוח ביותר): שירות gRPC, אימות mTLS, נתוני PII מוצפנים עם המפתח הציבורי של הנמען (הצפנת מעטפת, AES-256 + RSA-4096). כדי להירשם בשירות הספרייה של TRISA, נדרש אימות דרך חבר TRISA. הקוד הוא SDK פתוח ב-Go וב-Python.
נקודת כאב ספציפית: תזמון. נתוני כלל הנסיעות חייבים להיות מועברים לפני או במקביל לעסקה. בבלוקצ'יין של Ethereum, עסקה מאושרת תוך כ-12 שניות—בתוך זמן זה, לחיצת היד של TRISA חייבת להסתיים. אם הצד השני אינו מגיב, העסקה נחסמת או מתעכבת. ממשק המשתמש חייב להסביר זאת למשתמש, אחרת מובטח מבול של פניות תמיכה.
פרטי יישום לחיצת יד TRISA
דוגמה לבקשת gRPC להעברת נתוני כלל נסיעות:
service TRISANetwork { rpc Transfer(TransferRequest) returns (TransferResponse); } message TransferRequest { string identity_payload = 1; // зашифрованный PII-пакет string envelope_public_key = 2; string transaction_hash = 3; } לחיצת היד אורכת 3-5 סבבי HTTP, כולל אימות אישור mTLS של הצד השני דרך PKI Directory.
כיצד לבחור ספק KYC/AML לפרויקט קריפטו?
ספקי KYC לקריפטו מתחלקים למספר רמות:
רמה 1 (ארגוני, בדרגת רגולציה): Jumio, Onfido, Sumsub, Veriff. תומכים ב-200+ מדינות, אימות וידאו, בדיקות חיוניות, סינון AML דרך Refinitiv/Dow Jones. אינטגרציה דרך REST API + webhooks. Sumsub פופולרי בפרויקטי קריפטו אירופיים—תיעוד SDK טוב לאפליקציות מובייל.
רמה 2 (DeFi-native, ממוקדי פרטיות): Fractal ID, Synaps, Persona. פחות עומס רגולטורי, אינטגרציה מהירה יותר, אך כיסוי גלובלי פחות רחב לתחומי שיפוט בסיכון גבוה.
KYC on-chain דרך אישורים: Quadrata Passport, Civic, PolygonID—המשתמש מאמת פעם אחת, מקבל אישור on-chain, פרוטוקולים מאמתים אותו ללא אימות חוזר. שימור פרטיות דרך ZK. עדיין לא מיינסטרים, אך אנו מניחים את התשתית בארכיטקטורה.
| ספק | רמה | אישורי on-chain | זמן אינטגרציה ממוצע | תחומי שיפוט |
|---|---|---|---|---|
| Sumsub | 1 | לא | 3–4 שבועות | 220+ |
| Fractal ID | 2 | כן (Ethereum) | 2–3 שבועות | 80+ |
| Quadrata | 2 | כן (zk-proof) | 4–5 שבועות | גלובלי (לא-נאמנות) |
עיקרון ארכיטקטוני: נתוני KYC לעולם אינם מאוחסנים on-chain. נתונים אישיים מאוחסנים אצל הספק או במסד הנתונים המוצפן שלך; על ה-chain רק hash (התחייבות) או אישור (בגישת VC/SBT). זה מבטיח עמידה ב-GDPR: הזכות למחיקה ניתנת להשגה אם הנתונים off-chain.
טעות אופיינית: אחסון מיפוי ארנק-לזהות בטקסט פשוט ב-PostgreSQL ללא הצפנת שורות. הזרקת SQL אחת וכל מסד הנתונים של KYC נפגע. מינימום: הצפנת עמודות לשדות PII (PGP או AES דרך pgcrypto), ניהול מפתחות נפרד (AWS KMS, HashiCorp Vault), יומן ביקורת לכל גישה ל-PII.
לסינון AML, אנו משתמשים ב-Chainalysis, Elliptic, או TRM Labs. האינטגרציה היא אסינכרונית דרך webhook: תוצאות מגיעות תוך 1–5 שניות. חסימה מבוססת סף: סיכון HIGH — חסימה אוטומטית, MEDIUM — בדיקה ידנית. תקופת החזקה לעסקאות חשודות היא 24–72 שעות עד לבדיקה ידנית. סינון סנקציות בנפרד: רשימת OFAC SDN מתעדכנת מספר פעמים בשבוע; אנו משתמשים באינטגרציה ישירה של רשימת OFAC (חינם) עם לוגיקת התאמת כתובות מותאמת אישית.
כיצד אנו מיישמים תמיכה ב-MiCA?
תקנת Markets in Crypto-Assets (EU 2023/1114) דורשת רישוי CASP (Crypto-Asset Service Provider) במדינה אחת באיחוד האירופי עם פספורטינג. דרישות טכניות המשפיעות על הפיתוח:
נייר לבן הוא חובה למנפיקי ART (Asset-Referenced Tokens) ו-EMT (E-Money Tokens)—לא מסמך שיווקי אלא תשקיף מחייב מבחינה משפטית עם תיאור טכני, זכויות מחזיקים ומנגנוני פדיון.
דרישות אחסון נאמנות: נכסי לקוחות נפרדים מנכסים תפעוליים. טכנית: ארנקים/חשבונות נפרדים לכל לקוח (או omnibus עם מיפוי off-chain + התאמות תקופתיות), ללא אפשרות להשתמש בכספי לקוחות לצרכים תפעוליים.
ניטור ודיווח עסקאות: CASP חייבים לשמור רישומים של כל העסקאות למשך 5 שנים לפחות ולספק אותם לרגולטור לפי דרישה.
כלל הנסיעות ב-MiCA: הסף להעברות VASP-ל-VASP הוא אפס (לא סף FATF). היישום דורש נקודת קצה לכלל הנסיעות הפועלת 24/7.
| סוג ארגון | דרישות MiCA מרכזיות | השפעה טכנית |
|---|---|---|
| מנפיק ART/EMT | נייר לבן, מנגנון פדיון, ביקורת רזרבה | חוזה חכם עם פונקציית פדיון, oracle להוכחת רזרבה |
| CASP (בורסה, נאמן) | רישיון, הפרדת נאמנות, כלל נסיעות | ארנקים נפרדים לכל לקוח, אינטגרציית TRISA/TRUST |
| פרוטוקול DeFi (ללא מנפיק) | כרגע מחוץ לתחום MiCA (בבדיקה) | ניטור, הכנת ארכיטקטורה |
תהליך יישום תשתית ציות
ארכיטקטורת ציות אינה מתווספת על גבי מוצר קיים ללא כאב. הסדר הנכון: דרישות ציות → מודל נתונים → לוגיקה עסקית → ממשק משתמש. אם כבר יש לך מוצר ללא שכבת ציות, אנו מתחילים בניתוח פערים: אילו נתונים כבר נאספים, היכן הפערים, מה ידרוש מיגרציית סכמה.
- ניתוח פערים — ביקורת על הארכיטקטורה הנוכחית וזרימת הנתונים (1–2 שבועות).
- עיצוב — בחירת ספק KYC, פרוטוקול כלל נסיעות, כלי AML, מודל נתונים.
- אינטגרציה — חיבור API של KYC, יישום סינון AML בצנרת, הקמת שער כלל נסיעות.
- בדיקות — בדיקות end-to-end, סימולציית לחיצת יד Travel Rule, אימות סינון סנקציות.
- השקה וניטור — פריסה עם feature flags, הגדרת התראות לשגיאות שירותי ציות, נתיב ביקורת.
- תמיכה ברישוי — הכנת תיעוד לרגולטור, סיוע בבדיקות.
מה כולל שירות הציות לבלוקצ'יין?
- תיעוד ארכיטקטורת ציות (זרימת נתונים, דיאגרמות ER, מפרטי API).
- אינטגרציה של APIs של KYC/AML/Travel Rule עם השרת האחורי שלך.
- הקמת ניטור והתראות לשירותי ציות.
- הכשרת הצוות שלך על הכלים (Chainalysis, Sumsub וכו').
- תמיכה במהלך תהליך הרישוי (MiCA, FATF).
אמות מידה לזמנים
- אינטגרציית KYC/AML עם Sumsub או Jumio — מ-3 עד 6 שבועות.
- כלל נסיעות (TRISA או Sygna) — מ-6 עד 10 שבועות.
- תשתית ציות מלאה לרישוי CASP — מ-4 עד 8 חודשים.
- ציות on-chain דרך VC/SBT עם ZK (מוכן ל-MiCA) — מ-5 עד 9 חודשים.
ההיקף מעודן לאחר ניתוח פערים. כדי להעריך את הפרויקט שלך, צור איתנו קשר—נבצע ניתוח חינם של הארכיטקטורה הנוכחית שלך ונבחר את סט הכלים האופטימלי. קבל ייעוץ על ארכיטקטורת ציות ל-MiCA או לכלל הנסיעות. לצוות שלנו ניסיון של למעלה מ-7 שנים בפיתוח בלוקצ'יין ו-15+ פתרונות ציות פרוסים. בקש ביקורת על הפרוטוקול שלך לעמידה בדרישות רגולטוריות עדכניות.