מדוע רישוי VASP נתקע בשלב הבדיקה
הרגולטור בודק לא הצהרת כוונות, אלא את הקישוריות של הנתונים: מלקוח לפעולה, מפעולה למקור הכספים, ממקור לדיווח. לכן רישוי VASP נתקע לרוב לא בחלק המשפטי, אלא בממשק שבו תיעוד הציות חייב להיות מאומת על ידי פלטים ממערכת פעילה. התיק נאסף כאוסף קבצים, והבודק הולך לאורך השרשרת ובכל שלב מחפש אישור.
הכשל הטיפוסי הראשון — תיק לא שלם. חלק מהנהלים מתוארים במהדורות שונות, חלקם קיימים רק בהתכתבות, וגרסאות המדיניות אינן קשורות לתאריכי הצגתן.
השני — זרימות הפעולות אינן מתוארות: לא רואים אילו ערוצי קליטה ומשיכה משמשים, מי הצד שכנגד, כיצד מתועד סטטוס הפעולה ומי מהעובדים יש לו גישה אליה.
השלישי והיקר ביותר — מקור הכספים של הלקוח. אם הוא מאומת על ידי צילום מסך שנשמר ידנית, ולא על ידי פלט מהמערכת עם מזהה הלקוח, תאריך ואחראי, הבדיקה אינה מקבלת אישור כזה. כאן דרישות הרגולטור והתשתית מתפצלות: הנוהל קיים, אך אין עקבות לביצועו.
הניסיון שלנו: פער בין התהליך המתואר לבין מה שהמערכת בפועל מתעדת, הוא הסיבה העיקרית להחזרות ולבקשות נוספות. נסביר כיצד זה נסגר בשלב ההכנה לבדיקה.
מה משתנה לאחר היישום: לוחות זמנים, סירובים, בקשות
כאשר התיעוד והתשתית מתוכננים יחד, ההשפעה נראית במספרים, לא בתיאורים. לפני כן, התיק לרישיון נאסף במשך חודשים: חלק מהיסטוריית הפעולות חסר, חלק מההתכתבויות קיים בדואר, והפלטים מהמערכות אינם תואמים זה לזה. כל פער צריך לסגור ידנית — ועליו דווקא הבודק מתעכב בתשומת לב הרבה ביותר.
המדד המרכזי — שיעור הפעולות עם היסטוריה מלאה וניתנת לשחזור. אם זרימת העסקאות נכתבת ליומן בלתי ניתן לשינוי, אליו מקושרות בדיקות כתובות ומידע לפי כלל הנסיעה, שיעור זה נשמר בסביבות 95% במקום 60–70%.
אנליטיקה כמו Chainalysis מכסה את הערכת הסיכון של הצד שכנגד, ואחסון עצמאי — את משך והשלמות האחסון: הנתונים אינם תלויים בכך אם הספק או פורמט הפלט השתנו.
זמן הכנת התיק מתקצר משבועות למספר ימים, מכיוון שפרופיל הסיכון, תרשים תנועת הכספים ותיאור הנהלים נלקחים ממערכת פעילה. הם אינם משוחזרים מהזיכרון ואינם נכתבים מחדש עבור כל בקשה — רק החלק הנלווה משתנה.
לאחר מכן יורד מספר הבקשות החוזרות: החבילה הראשונית כבר מכילה תשובות לשאלות טיפוסיות בנוגע למקורות כספים, צדדים שכנגד ובקרה. זוהי עמידות בבדיקה — לא תיקיית מסמכים חד-פעמית, אלא מצב שמאומת בכל בדיקה עוקבת.
פורמטים של רישוי VASP: השוואת אפשרויות
רישוי VASP אינו מסתכם בהגשת חבילת מסמכים: קיימות מספר דרכים לקבלת המעמד, וכל אחת קובעת את היקף הפעולות שלה, דרישות לתשתית טכנית וזמן היציאה לשוק. הבחירה תלויה בכך אם אתם עובדים עם משמורת ופיאט או מסתפקים בהמרה.
להלן ארבע תוכניות, שביניהן בוחרים לרוב. ההשוואה נעשית בשלושה צירים: מהירות ההתחלה, היקף ההתחייבויות כלפי הרגולטור, ומידת הבעלות שלכם על התשתית.
| אפשרות | מתי מתאימה | מגבלות הגישה |
|---|---|---|
| רישוי עצמאי בתחום שיפוט | משמורת, המרה ועבודה עם תושבי השוק — נדרש שליטה ישירה | מחזור אישורים ארוך, דרישות הון ונוכחות מקומית, תוכנית AML ו-KYC מלאה, ביקורת בלתי תלויה |
| תחת רישיון של שותף (תוכנית סוכנות) | התחלה מהירה ובדיקת ביקוש ללא מעמד עצמאי | היקף השירותים נקבע על ידי השותף, כספי הלקוחות והדיווח נשארים מחוץ לשליטתכם |
| ישות משפטית עם מעמד פעיל | נדרש היקף פעיל מיידי: סליקה, משמורת, יחסי בנק | עוברים בירושה היסטוריית דיווח והתחייבויות, שינוי שליטה מתואם עם הרגולטור, התשתית מועברת מחדש |
| רישום במשטר מקל | מערך מצומצם של פעולות: ייעוץ, המרה ללא החזקת כספי לקוחות | איסור על משמורת ועבודה עם תושבי שווקים גדולים, קשיים עם בנקים מקבילים |
מגבלות הגישה אינן פורמליות: הן קובעות איזו תוכנית AML יהיה צורך לבנות והאם נדרש קצין ציות מקומי.
גם ליווי המעמד דורש תשתית: תיעוד יומן עסקאות, נוהל אחסון מפתחות ותקנות דיווח חייבים להיות מתועדים וניתנים לשחזור מהיום הראשון — אחרת בדיקה חוזרת של הרגולטור הופכת לעיבוד מחדש של התהליכים.
שלבי העבודה: ביקורת, הגדרת אינטגרציות, מסירה
סדר השלבים כאן אינו פורמליות: אם מחברים אינטגרציות לפני שתוארו זרימות הנתונים, הבדיקות מתחילות לשכפל, והדיווח נאסף ידנית. אנו הולכים מניתוח המערך הנוכחי לתרשים עובד, וכל שלב נשען על התוצר של השלב הקודם.
- ביקורת תשתית. בודקים היכן נשמרים המפתחות וכיצד נחתמות הפעולות, למי יש גישה למערכות, אילו שירותי בדיקה כבר מחוברים. בפלט — מפת פערים: חשבונות משותפים, יומנים לא שלמים, בדיקות שתוצאתן אינה ניתנת לשחזור.
- תרשים זרימות נתונים. מתארים את מסלול נתוני הלקוח, נקודות הצלבה עם רשימות, זמני אחסון ואירועים שנכנסים ליומן בלתי ניתן לשינוי ומופקים לפי דרישת הרגולטור.
- הפרדת הרשאות. בונים תפקידים כך שהגדרות הבדיקות לא ישונו על ידי מפעיל שמבצע את ניתוח ההתראות. אימות דו-שלבי, סביבות נפרדות לפעולות בדיקה ולעבודה מבצעית.
- הגדרת אינטגרציות. מחברים אימות זהות ומסמכים, הצלבה עם רשימות סנקציות ורשימות פוליטיות, אנליטיקה בלוקצ'יין, החלפת נתונים על העברות עם ספקים אחרים. לכל ערוץ — טיפול בסירובים ובניסיונות חוזרים.
- בדיקת תרחישים. מריצים מקרים מבוקרים: התאמה לרשימה, פיצול סכום, העברה לכתובת מקבוצת סיכון. התראה צריכה להוביל לפעולה מובנת, והתראת שווא — להיות מוסרת עם נימוק.
- תיעוד ותקנות. כללי בקרה פנימית, נוהל חקירה, מטריצת הסלמה, זמני עדכון רשימות. הכל מקושר לתצורה בפועל, ולא נכתב בנפרד ממנה.
- מסירה. מוסרים גישות, תרשימי זרימה, תקנות וצוות מאומן: מנתחים אירועים על דוגמאות חיות ומראים כיצד לשנות כללים ללא עצירת השירות.
בסופו של דבר הלקוח מקבל תרשים שניתן להציג לרגולטור ולהמשיך לתחזק בכוחות עצמו.
תצורות, מדיניות גישה וחבילת מסמכים
חבילת המסמכים אינה תיקייה שנאספה להגשה לרישיון VASP, אלא תיאור עבודה של המערכת. אם התצורות, מדיניות הגישה והתקנות סוטות מהאופן שבו התשתית בנויה בפועל, הבקשה הראשונה של הרגולטור או ניתוח אירוע חושפים את הפער. אנו אוספים את התוצרים כך שניתן יהיה לשחזר לפיהם את הסביבה ולהסביר כל החלטה.
- תצורת מערכות — הרכב הרכיבים, הקשרים ביניהם, פרמטרי פריסה והפרדת סביבות, כך שהמערך יוקם לפי התיאור, ולא לפי זיכרון המהנדס.
- מדיניות גישה — מטריצת תפקידים והרשאות, סדר מתן, סקירה ושלילה, כללים לאישור פעולות קריטיות על ידי שני עובדים.
- תיאור תפקידים — מי אחראי למה: ממנהל מערכת ועד האחראי על עמידה בדרישות, עם תחומי אחריות ונוהל החלפה.
- תרשימי זרימות נתונים — מהיכן מגיעים נתוני הלקוח, היכן נשמרים, לאן מועברים, באילו מקטעים מתועדים עקבות הפעולות.
- תקנות עבודה — טיפול בבקשות הרגולטור, תגובה לאירועים, התאוששות לאחר תקלה, נוהל שינוי תצורות.
- יומנים ועקבות פעולות — מה בדיוק מתועד, כמה נשמר, למי יש זכות הפקה.
- נוהל עדכון — הבעלים של כל מסמך, טריגרים לסקירה, כללי ניהול גרסאות ותיעוד שינויים.
לכל תוצר יש בעלים וכלל סקירה: בעת שינוי בהרכב המערכות, התפקידים או מסלולי הנתונים, המסמך מתעדכן יחד איתם, ולא לאחר הערה. הגרסאות נשמרות בסמוך, כך שניתן לראות איזו מהדורה הייתה בתוקף במועד הפעולה הספציפית. החבילה מפסיקה להיות פורמליות והופכת לכלי שבו משתמשים גם המהנדסים וגם האחראים על עמידה בדרישות.
מקרה בוחן: הכנה לבדיקה ללא עצירת השירות
הלקוח — ספק שירותים עם נכסים וירטואליים, התכונן לבדיקת רגולטור במסגרת הליך רישוי. היסטוריית הפעולות התקיימה בארבעה מקומות: מודול הבורסה, קופת פיאט, פנקסים ידניים לעסקאות גדולות ופלטים מאנליטיקת בלוקצ'יין.
איסוף תמונה מלאה על לקוח מסוים לתקופה שרירותית היה אפשרי רק ידנית: כל בקשה ארכה כתשעה ימי עבודה, ובחלק מהפעולות אבד הקשר למקור הכספים.
מה שינו
העברנו את ההיסטוריה למרשם אחיד עם יומן בלתי ניתן לשינוי: רשומה קיבלה מזהה לקוח, סכום וכיוון, קישור לעסקה ברשת וכלל הערכת סיכון שלפיו הפעולה עברה בדיקה בתאריכה.
השוואה יומית עם פלטי אנליטיקת עסקאות Chainalysis סגרה פערים בין הנהול הפנימי לנתוני הרשת — פער נכנס לתור נפרד לניתוח, ולא צף בבדיקה. כללי הערכת הסיכון נוהלו בגרסאות, כך שניתן לשחזר מדוע פעולה נחשבה בסיכון נמוך אז, ולא רק כעת.
דינמיקה לפי מדדי בקרה
| מדד | לפני | אחרי |
|---|---|---|
| שלמות היסטוריית הפעולות לתקופה | 74% | 99.6% |
| פעולות עם מקור כספים מאומת | 61% | 97% |
| זמן תגובה לבקשת הרגולטור | 9 ימי עבודה | 4 שעות |
| הפקה לפי לקוח לתקופה שרירותית | ידנית, שני מומחים | דוח אוטומטי לפי חתך מוגדר |
ההגירה בוצעה ללא עצירת השירות: המרשם החדש התמלא במקביל לעבודה השוטפת, המודולים חוברו בזה אחר זה עם מתג חזרה לאחור אם ההשוואה העלתה פער. הבדיקה עברה ללא הערות לגבי שלמות הנתונים, ובקשות הרגולטור נסגרות כעת באמצעות שליפה מהמרשם, ולא באמצעות איסוף דוחות מיחידות שונות.
מה לעשות אם התשתית כבר פרוסה?
תשתית פעילה לא בונים מחדש מאפס — לצידה בונים מערך שני, שהותאם לדרישות, ומעבירים אליו את העומס בהדרגה. השירות אינו נעצר באף שלב, ונסיגה לאחור היא החזרת מתג אחד, ולא שחזור מגיבוי עם אובדן פעולות שנשלחו בשעה האחרונה.
מתחילים בספירת מלאי של מערכות: אילו שירותים ממש משרתים פעולות לקוח, היכן נשמרים מפתחות החתימה וכיצד מאומתות עסקאות יוצאות, אילו אינטראקציות חיצוניות יוצאות מגבולות המערך, מי ועם אילו הרשאות מורשה לכל חוליה.
בפלט — תרשים של זרימת הפעולות בפועל ורשימת פערים בין מה שקיים במציאות לבין מה שמתואר בתיעוד. חלק מהפערים נסגר בהגדרה, וחלק דורש עדכון קוד.
הפרדת הרשאות מונהגת בשלבים: תחילה תפקידים עם הרשאות מינימליות נדרשות ואישור נפרד לפעולות קריטיות, אחר כך הפרדת תחומי אחריות בין מי שיזם פעולה למי שמאשר אותה. ההרשאות הרחבות הקודמות מבוטלות רק לאחר שהיומן יראה: מערך התפקידים החדש מכסה את כל תרחישי העבודה. אחרת פעולה לילית תיתקע בגלל גישה חסומה לשירות.
דרישות גופי הפיקוח, כולל גישת FATF לנכסים וירטואליים, נבדקות להתאמה בין התקנון לבין מערך הביצוע בפועל. התיעוד מתוקן באותה משמרת שבה משתנה ההגדרה: תרשימי ניתוב, מטריצת תפקידים, יומני אירועים ונוהל פעולה בעת אירוע מתעדכנים יחד עם הקוד, ולא בשלב נפרד בסוף.
בפלט — שירות פעיל ללא השבתה, הרשאות גישה פורמליות, יומני פעולות ניתנים לשחזור ותיאורים שהבודק יכול להשוות למערכת במעבר אחד. לאחר מכן נותר ליווי שוטף: כל שינוי עובר את אותו מסלול כמו הפיתוח הראשוני.
ספקות נפוצים: אחסון נתונים, אינטגרציות, דיווח
ההתנגדויות לרישוי VASP כמעט אף פעם לא נוגעות לחבילת המסמכים עצמה — הן נוגעות לתשתית שמתחתיה: כמה זמן ולכמה זמן לאחסן נתונים, כיצד לחבר מערכות קיימות, באיזה פורמט למסור דיווח ובמה להוכיח שהיסטוריית הפעולות לא נערכה. ננתח כל אחת.
כמה זמן ומה יצטרכו לאחסן?
תקופות האחסון נספרות מתאריך הפעולה, ולא מסגירת החשבון: לנתוני לקוח, עסקאות ופניות יש תקופות שונות, לכן המדיניות מתוארת לפי סוגי רשומות, ולא בשורה אחת "לאחסן הכל".
יומן מנוהל רק בתוספת בלבד — לא ניתן לשכתב או למחוק רשומה לפני תום התקופה, ועם תומה הנתונים מאורכבים ונמחקים לפי תקנון, ולא ידנית. כך נפח האחסון אינו גדל ללא בקרה, והמחיקה אינה שוברת דבר.
הנהול שלנו מפוזר על פני מספר מערכות — האם צריך לשכתב הכל?
בדרך כלל לא: נבנה שכבת אינטגרציה שמקשרת בין מערך הנהול, התשלומים והניטור לפי מזהה לקוח ופעולה אחיד. קליטת אירועים אידמפוטנטית — חבילה חוזרת אינה יוצרת כפילות, והמפתחות מוצמדים פעם אחת. הדיווח אז נבנה מתמונה אחת, ולא נבדק ידנית בין שלושה פלטים.
באיזה פורמט למסור דיווח וכיצד להוכיח את מהימנותו?
פורמט הפלט נבחר לפי דרישות הרגולטור, ולא לפי נוחות המערכות הפנימיות, ומקובע בסכימה — ההשוואה מתבצעת אוטומטית, פערים נראים לפני הבקשה, ולא אחריה.
שלמות ההיסטוריה נשענת על יומן בתוספת בלבד: כל רשומה מקבלת סכום ביקורת, הסכומים מקושרים זה לזה, לכן עריכה בדיעבד מתגלה ללא ספירת מלאי ידנית.
התקנות המפורטות, תרשים האינטגרציה וכללי האחסון מוצגים כתיעוד עבודה — ניתן למסור אותו לבודק ולהשתמש בו בעת החלפת צוות.נדון במשימה ונחזור עם הערכה ותוכנית
השיחה מתחילה בנתוני המקור, ולא במצגת: כדי לחזור עם הערכת היקף ותוכנית עבודה, עלינו לראות כיצד העסק בנוי כעת. ככל שנתוני המוצא קונקרטיים יותר, כך יש פחות הנחות בהערכה וגבולות השלבים מדויקים יותר.
מה לשלוח להתחלה:
- תחומי שיפוט לרישום ושווקי שירות מתוכננים — מהם תלויות דרישות הרגולטור, נהלי זיהוי וכללי דיווח;
- מודל עבודה עם נכסי לקוחות: משמורתי או לא-משמורתי, מי מחזיק במפתחות וכיצד מופרדים התפקידים;
- רשימת פעולות: המרה, העברות, קליטת והנפקת פיאט, סליקה עם צדדים שכנגד בפלטפורמות;
- תשתית נוכחית: מה כבר פרוס, אילו קבלנים ומערכות במערך, היכן נשמרים נתונים ויומנים;
- מצב התיעוד: האם קיימות טיוטות של מדיניות AML/CFT, תוכניות זיהוי לקוחות, תיאורי נהלים ובקרה פנימיים;
- מגבלות בלוחות זמנים להגשת בקשה וסדר אינטראקציה צפוי עם הרגולטור.
בתגובה נשלח תוכנית עבודה לפי שלבים, הרכב תיעוד עם אחראים וארכיטקטורה ראשונית של המערך. תארו את המשימה — נחזור עם הערכת היקף ופורמט עבודה.