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

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

שירותי פיתוח בלוקצ'יין

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1375
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1349
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    794
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1087
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1032
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1129

תיעוד לרגולטורים: היכן החבילה מתפרקת בבדיקה

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

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

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

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

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

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

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

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

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

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

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

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

מצבי עבודה: חבילה חד-פעמית, חבילה לצורך רישוי, ליווי

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

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

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

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

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

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

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

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

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

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

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

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

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

לפני עיבוד מחדש

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

מה שינו

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

מה התקבל

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

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

במה שונה חבילה לצורך רישוי מהליך הודעה?

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

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

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

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

ספקות ומגבלות: תחומי שיפוט, נתונים, תקופות תוקף של גרסאות

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

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

כיצד לנהוג לגבי הזכות למחיקה אם הבלוקצ'יין בלתי ניתן לשינוי?

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

מה יקרה אם הדרישות בתחום השיפוט ישתנו?

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

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

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

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

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

בתגובה לנתוני הפתיחה נשלח מערכה קונקרטית:

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

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