פיתוח מערכת דיווח רגולטורי לעסקי קריפטו

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

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

שאלות נפוצות

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

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

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

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

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

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

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

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

מה נותן מתאר אחיד לדיווח ולהתאמת פעולות

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

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

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

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

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

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

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

אפשרויות בניית מערכת: איסוף ידני, אוטומציה, היברידי

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

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

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

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

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

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

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

ערכת תיעוד ותקנונים להיערכות לבדיקה

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

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

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

מקרה בוחן: פערים בהתאמת פעולות צומצמו פי שלושה

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

מה שינו

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

תוצאה במספרים

מדד לפני אחרי
זמן הרכבת הדוח עד הגרסה הראשונה 9 ימי עבודה 2 ימי עבודה
רשומות שאינן מתכנסות בהתאמה 6.3% 2.1%
שורות עם תיקון ידני 68% 12%
ניתוח פער בודד 30–40 דקות 5–7 דקות

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

במה נבדל דוח שוטף מייצוא חד-פעמי לפי דרישה

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

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

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

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

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

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

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

אילו הרשאות למערכות שלנו תצטרכו ומי מנהל אותן?

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

מה לעשות אם נתוני המקור חסרים או סותרים בין מערכות?

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

כיצד להוכיח יכולת בדיקה של רשומות בפני מבקר חיצוני?

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

נדון במשימה: מה נדרש להערכה ולתוכנית עבודה

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

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

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

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