פיתוח sanctions screening: היכן נשברת הבדיקה
בדיקת צדדים נגדיים בקריפטו נשברת לא בחיבור, אלא ברגע שבו התשלום כבר יזום. סינון כתובות מופעל באופן סינכרוני עם משיכת הכספים, רשימות חיצוניות — OFAC, האיחוד האירופי, רגולטורים מקומיים — מגיבות בהשהיה שונה ולפי כללים שונים. הפעולה נכנסת לתור, הלקוח רואה שהתשלום לא הגיע, התמיכה מקבלת את הפנייה הראשונה.
נקודת הכשל השנייה — התראות שווא. התאמה לפי שם משפחה בתעתיק, כתובת שקשורה למיקסר דרך צד חמישי, ארנק בורסה עם היסטוריית כניסות לא אחידה — כל זה עובר לאנליסט לבדיקה ידנית. בתזרים של מאות פעולות ביום התור גדל מהר יותר מכפי שהצוות מספיק לסגור אותו, והבדיקה הופכת לפקק קבוע ביציאה.
המחיר צפוי: עיכוב בתשלומים, נטישת לקוחות ארגוניים למקום שבו הבדיקות אינן מורגשות, עבודה ידנית על התזרים. בנפרד — סיכון רגולטורי: בבדיקה יש להציג לא את עצם קיומו של הסינון, אלא את הנימוק לכל החלטה, כולל אלה שבהן ההתראה הוכרה כשווא והתשלום הועבר.
פיתוח sanctions screening הוא בדיוק הדבר שמפריד בין הצמתים האלה: בדיקה לפני ייזום התשלום, הערכת סיכון לפי רמה וסכום, כללי הסלמה שקופים במקום "בעין" ידני. בהמשך נבחן היכן בדיוק עובר הגבול בין החלטה אוטומטית לעבודת האנליסט.
מה נותן קו סינון עצמאי
קו בדיקות עצמאי נבנה סביב נתונים שאנחנו שולטים בהם: תגיות כתובות מ-Chainalysis, רשימות סנקציות רשמיות ורשימות חסימה פנימיות מתאחדים לזרימה אחת, וכללי ההתאמה מתוארים בקונפיגורציה ולא בסקריפט בצד.
אוטומציה של בדיקות מפסיקה להיות קופסה שחורה — שיעור ההחלטות ללא מעורבות אדם הופך לגודל מדיד וניהולי.
בפועל 85-95% מהבדיקות נסגרות אוטומטית, וזו אינה הגדרה חד-פעמית: ספי הרגישות משתנים יחד עם פרופיל הסיכון של הפלטפורמה. ניקוד סיכון חוסם התאמות שווא — אם השם תאם, אך המדינה, תאריך הלידה והמסמך אינם תואמים, ההתראה מוסרת ללא מהנדס. לאדם נשארים מקרים עם אי-ודאות אמיתית.
תור הבדיקה הידנית מקבל לא זרימה גולמית, אלא מקרים מדורגים: עם סיבת ההתראה, שרשרת העסקאות והיסטוריית הכתובת. לכן בדיקת התאמה אחת נעשית במעבר אחד, ולא דרך שלוש מערכות ברצף, וזמן הטיפול בהתראה יורד מעשרות דקות ליחידות.
בנפרד מטופל סוג הכשל היקר מכולם: בדיקה שהפסיקה בשקט לזהות כתובת לאחר שינוי בפורמט המאגר. כל כלל התאמה מקבל גרסה ומורץ על התראות שנצברו לפני עלייה לפרודקשן — את הרגרסיה רואים מראש, ולא בדיעבד אחרי הבדיקה.
כל החלטה שומרת נימוק: מי, מתי ולפי איזה כלל הסיר או אישר את הסיכון — את העקבות האלה מבקשים בבדיקה מצד הרגולטור.
דרכים לחיבור רשימות וכללי התאמה
רשימות אפשר לקבל ישירות מבעל הרשימה, דרך מקור מרוכז, או לנהל עותק מסוקר משלך — מכך תלויים השהיית העדכון, היקף הבדיקה הידנית וכיסוי מלא.
| אפשרות חיבור | מתי מתאימה | מגבלות |
|---|---|---|
| ייצוא ישיר מבעלי הרשימות: OFAC SDN, הרשימה המרוכזת של האיחוד האירופי, UN, רשימות לאומיות | נדרשים שלמות ממקור ראשוני והפניה לפרסום רשמי | לכל אחד סכימת שדות משלו ולוח פרסום משלו — נדרש טיפול נפרד בכל קובץ |
| אגרגטור מרוכז | התחלה מהירה, סכימת רשומות אחידה, הסרת כפילויות כבר בוצעה על ידי הספק | השהיה בין הפרסום לבין הכניסה לאגרגטור, תלות בלוח זמנים של אחרים |
| מאגר פנימי מסוקר | רשומות סיכון משלך והתראות שווא שהוסרו לשימוש חוזר | ליווי ידני, נדרש נוהל תחזוקה ואחראי עליו |
פורמטי הייצוא שונים (XML, CSV עם סכימה משל עצמם), ולכן שכבת הטעינה נשמרת בנפרד משכבת ההתאמה: שינוי סכימה לא אמור לשבור את כללי החיפוש.
עדכונים נמשכים בקבצי דלתא לפי לוח זמנים, ובשינוי מבנה — טעינה מלאה מחדש של סנאפשוט עם ניהול גרסאות, כדי שביומן יישמר על איזו גרסה של הרשימה התקבלה ההחלטה לגבי הלקוח.
מצבי התאמה וסף
התאמת שמות מתחילה בנורמליזציה: רישיות, סימנים דיאקריטיים, תעתיק, החלפת סדר "שם משפחה — שם פרטי", ראשי תיבות, תאריכי לידה ואזרחות כמאפיינים נוספים. לאחר מכן מתבצעת השוואה מטושטשת עם סף התאמה: סף נמוך מדי מייצר זרם של התראות שווא, גבוה מדי — סיכון להחמיץ רשומה.
את הספים מגדירים בנפרד לרשימות חוסמות ולשאר הרשימות, והתראות מעל הסף השני עוברות לאנליסט לבדיקה, ולא נחסמות אוטומטית.
תדירות עדכון הרשימות נבחרת לפי פרופיל הסיכון: סקירת דלתא יומית מכסה את רוב התרחישים, וברשימות חוסמות המרווח קצר יותר.
שלבי ההטמעה: מביקורת תהליכים ועד מסירה
הטמעת הסינון מתחילה לא בקוד, אלא בביקורת של תהליכי ציות: חשוב להבין היכן כיום נתפסת התאמה לסנקציות, אילו רשימות מחוברות ובאיזו תדירות מתעדכנות, מי עוצר את הפעולה ומה נכנס ליומן.
מתוצאות הביקורת רואים אילו בדיקות מוכפלות, היכן נתונים הולכים לאיבוד בין מערכות ואילו נקודות בזרימה יהיה צורך לסגור. בהמשך העבודה מתנהלת באיטרציות — מהסכימה ועד המסירה לתפעול.
- ביקורת תהליכי ציות. מנתחים את הבדיקות הנוכחיות: מקורות נתונים, שלבים ידניים, זמני טיפול בהתראות, היסטוריית כשלים ותקריות. מתעדים אילו פעולות כיום עוברות ללא בדיקה כלל.
- סכימת הבדיקות. מגדירים נקודות השתלבות — רישום לקוח, עסקה נכנסת ויוצאת, משיכת כספים. מתאמים פורמטי אירועים, תפקידים והרשאות, והתנהגות המערכת כשהרשימה החיצונית אינה זמינה.
- הגדרת כללים וספים. בוחרים לוגיקת השוואה של שמות: תעתיק, החלפת סדר חלקים, השוואה מטושטשת, משקל ההתאמה. מגדירים רמות סיכון ותורי בדיקה ידנית, כדי שהאנליסט יראה רק התראות משמעותיות.
- הרצת בדיקה על היסטוריה. מריצים את מכלול הפעולות שנצבר, משווים את התוצאה להחלטות של קציני ציות, ומחשבים את שיעור התראות השווא וההחמצות. לפי השוואה זו מכיילים את הספים, ולא "בעין".
- נוהל הבדיקה. מתארים את סדר הטיפול: זמני תגובה, קריטריונים להסלמה, עילות לחסימה, תיעוד חובה של ההחלטה. הנוהל מתואם עם המדיניות הקיימת ומשמש בסיס להדרכת הצוות.
- מסירה לתפעול. מוסרים קונפיגורציות, סכימת אינטגרציה, הוראות לאנליסטים ודשבורד עם מדדים. בשבועות הראשונים מלווים, עד שהצוות עובר למצב עצמאי.
קריטריון המוכנות המרכזי — לא שירות שהופעל, אלא עבודה צפויה: ידוע כמה פעולות עוברות לבדיקה ידנית ומדוע. דברו איתנו על המשימה — נחזור עם הערכה ותוכנית לפי שלבים.
מארז סכימות, נהלים והרשאות בסיום
לאחר ההשקה נשארים לצוות הלקוח לא רק קו בדיקות פעיל, אלא גם מארז מלא של ארטיפקטים: לפיהם מהנדס חדש או מומחה ציות נכנס למערכת בלי לפנות אלינו. התיעוד מקושר לשינויים — עריכת כללים או חיבור מקור רשימה חדש מעדכנים את התיאור באותו שינוי.
- סכימת אינטגרציה: נקודות חיבור לקו העסקאות ולמקורות רשימות חיצוניים, פורמטי בקשות ותשובות, התנהגות כשהמקור אינו זמין.
- סכימת זרימות הבדיקות: המסלול מהופעת הפעולה ועד ההחלטה, תורים, נקודות לוגים וזמני שמירת התוצאות.
- תיעוד הבדיקות: כללי התאמה — ספים, תעתיק, טיפול בהתאמות מטושטשות, בדיקות על התראות היסטוריות.
- מטריצת הרשאות: תפקידי האנליסט, הבודק הבכיר, מנהל הכללים והמבקר — מה כל אחד קורא, משנה ומאשר.
- נוהל טיפול בהתאמות: זמני תגובה לפי רמות סיכון, הרכב הכרטיס, תנאי הסלמה, מי מקבל את ההחלטה הסופית.
- יומן שינויים בכללים: מי ולמה שינה ספים או רשימת חריגים, עם חזרה לקונפיגורציה של הגרסה הקודמת.
- הוראות למשמרת: סדר התורנות, פעולות בעת חסימת מקור, העברת התראות שלא נסגרו.
את הארטיפקטים בודקים בתרגיל: מקימים סביבת בדיקה, מריצים תרחישים עם מקור לא זמין וזרם של התאמות שווא. אם לפי ההוראות מתקבלת החלטה בזמן שהוקצב — המארז נחשב כמאושר.
מקרה בוחן: איך צמצמנו התראות שווא בחצי
אצל הלקוח — בורסת קריפטו עם תזרים פעולות בכמה רשתות — הבדיקה הידנית כבר לא כיסתה את ההיקף. ההתאמה הייתה מקודדת בקשיחות: כל התאמה לפי שם או כתובת עברה לאנליסט, הטיפול ארך עד 40 דקות, והתור גדל מהר יותר משהספיקו לטפל בו.
בנינו מחדש את מסלול הבדיקה בשלושה שלבים: הצלבה מול רשימות סנקציות (OFAC SDN, EU, OFSI, UN), העשרת כתובות בנתוני Chainalysis וחישוב הערכת סיכון לפי משקלים ניתנים להגדרה. הספים וכללי הטיפול הוצאו לקונפיגורציה, ולכן הרגישות משתנה בלי לשחרר גרסה חדשה.
מדדים לפני ואחרי
| מדד | לפני | אחרי |
|---|---|---|
| שיעור החלטות אוטומטיות | ~35% | ~80% |
| טיפול בהתאמה אחת | עד 40 דקות | 6–9 דקות |
| תור ידני ביום | מאות פניות | בודדות |
| זמן תגובה להתאמה | שעות, ידנית | דקות, אוטומטית |
התראות השווא הצטמצמו בחצי: התאמות שם שמוסרות לפי תאריך לידה או מדינה עוברות לאישור אוטומטי עם רישום ביומן. כל החלטה שומרת איזה כלל ואיזו גרסת רשימה יצרו אותה — זה מסיר שאלות בבדיקות הרגולטור.
בנפרד הפעלנו ניטור מתמשך: בעת עדכון רשימה כל בסיס הלקוחות נבדק מחדש, וההתאמות מגיעות לתור בעצמן. קודם לכן עשו זאת באופן סלקטיבי ובידני, ולכן חלק מההתאמות צפו באיחור.
במה נבדלת בדיקת כתובת חד-פעמית מניטור מתמשך?
בדיקת כתובת חד-פעמית היא תצלום ליום מסוים: שאילתה אחת למאגרים אנליטיים, רשימות סנקציות ורשימות שירותים לא חוקיים, שתוצאתה מתועדת בכרטיס הלקוח. עבור תשלום נכנס או קבלה לשירות תצלום כזה מספיק: הוא מאשר שביום הבדיקה הכתובת נקייה, ומשאיר עקבה לביקורת.
אבל תגית אינה תכונה של הארנק, אלא מצב: כתובת שהייתה נקייה ברגע הקבלה עשויה מאוחר יותר להיות קשורה למיקסר, להיכנס לרשימה של תחום שיפוט חדש כמו OFAC SDN או לקבל העברה מאשכול שהוכר כפושע בדיעבד.
בדיקה חד-פעמית מביטה אחורה ואינה עוקבת אחרי שינויים. לכן במקום שבו היחסים עם הלקוח נמשכים חודשים, מוטמע ניטור מתמשך של ארנקים: הכתובות נבדקות מחדש לפי לוח זמנים ולפי אירועים — עסקה גדולה, שינוי תחום שיפוט, עדכון רשימות.
כל בדיקה חוזרת משווה את פרופיל הסיכון הנוכחי לתצלום הקודם ומעלה התראה על הדלתא: עלתה קטגוריית הסיכון, נוצר קשר ישיר או עקיף עם כתובת תחת סנקציות, התחלף בעל האשכול.
המצב השני לא נדרש לכולם. הוא הכרחי למשרדי המרה מורשים ולשירותי משמורת, לעבודה עם פיקדונות לקוחות, ליחסים ארוכי טווח ולמגבלות גבוהות — שם ויתור על בדיקות חוזרות משמעו שהסימנים הראשונים לסיכון יופיעו רק אצל הרגולטור.
בדיקה חד-פעמית מוצדקת עבור תשלום חד-פעמי ללא התחייבויות נוספות: הניטור שם לא נותן דבר מלבד רעש מיותר.
מבחינה הנדסית הניטור נבנה כשכבה מעל הבדיקה: השוואת דלתא של פסקי דין כדי לא להריץ את כל הבסיס בכל עדכון של מאגרים, מטמון תגיות עם תאריך עדכניות, תור התראות ויומן של כל גרסאות ההחלטה — לפי דרישת הרגולטור רואים בדיוק מה ומתי ידענו על הלקוח. בהמשך נבחן איך נבנה קו כזה.
ספקות טכניים: התאמות, עומס, הרחבות
ספקות הנדסיים בשלב הזה כמעט תמיד זהים: האם בדיקות לא ילכו לאיבוד בזינוק בפעולות, האם הצלבת שמות לא תהפוך לתור אינסופי של התראות שווא, האם אפשר לשנות כללים בלי לפרוס מחדש את השירות ואיך זה ישתלב במערכת הנה"ח של הלקוח. צריך לתכנן זאת לפני הגרסה הראשונה — לשנות אחר כך עולה יותר.
בקצרה נסגור ארבעה סעיפים למטה; את השאר נבחן יחד עם המהנדס שלנו בשיחה לפי סכימת התהליכים שלכם.
שמות דומים מייצרים התאמות שווא — מה עושים עם זה?
ההשוואה אינה נעשית על המחרוזת כולה: השם מנורמל — אלפבית אחיד, רישיות, חיתוך תוארים וקידומות שירות — ורק אחר כך מוצלבה באופן מטושטש, עם סף דמיון ניתן להגדרה. תאריך לידה, אזרחות ומדינה מחוברים כמאפיינים מדייקים, ולכן האנליסט מקבל רשימה קצרה של מועמדים במקום מאות בעלי שם משפחה זהה.
האם המערכת תעמוד בעומס שיא?
הבדיקות עוברות לתור: המעבדים לוקחים משימות ומתווספים ככל שעומק התור גדל, ולכן זינוק מביא לעלייה בהשהיה, ולא לרשומות שאבדו. פניות לרשימות חיצוניות מוגבלות בקצב ומתומצתות לזמן קצר, כדי לא להיתקל במכסה.
איך מרחיבים כללים אחרי ההשקה?
כללים הם נתונים, לא קוד: רשימה חדשה, סף ששונה או מאפיין נוסף מוכנסים לקונפיגורציה ומקבלים גרסה. לפני ההפעלה הכלל מורץ במצב צל על נתונים היסטוריים — רואים כמה התראות וסימוני שווא הוא יוסיף.
איך מתבצעת האינטגרציה עם מערכת הנה"ח?
עובדים גם דרך ממשק תוכנה בזמן אמת, וגם בהחלפת קבצים לפי לוח זמנים — הבחירה תלויה באופן שבו בנויה זרימת הפעולות. הבקשות אידמפוטנטיות, בעת ניתוק המשימה חוזרת, סטטוס הבדיקה מוחזר למערכת הנה"ח, וההחלטות עם הנימוקים נשמרות ביומן בלתי ניתן לשינוי לצורכי ביקורת.
נדון במשימה ונחזור עם הערכה ותוכנית
כדי שהערכת היקף העבודות תהיה עניינית ולא ממוצעת לפי השוק, נדרש קלט קצר מהצוות שלכם. אם חלק מהסעיפים עדיין פתוחים — זה בסדר, נבחן יחד בשיחה.
- אילו נכסים ורשתות אתם משרתים: בלוקצ'יינים, סוגי טוקנים, כתובות ארנקים וחוזים.
- מאין מגיעות העסקאות: בורסה, שירות משמורת, שער תשלומים, משרד המרה.
- איך בנויה הבדיקה כיום: באיזה שלב בודקים את הכתובת, האם יש תורים ידניים לטיפול.
- דרישות הרגולטור וכללים פנימיים: דיווח, זמני שמירת נתונים, מי אחראי על החסימות.
- היכן לשלב את התוצאה: ממשק מפעיל, ממשק תוכנה משלכם, מערכות הנה"ח.
- מי מצד הלקוח מקבל מקרים שנויים במחלוקת ומאשר את כללי הסף להערכת הסיכון.
בתגובה נחזור עם הערכת היקף העבודות ותוכנית הטמעה: שלבים, תלויות, הרכב הצוות ונקודות שבהן נדרשת החלטה שלכם. בנפרד נציג אפשרויות לבחירה — מהשקה מהירה של בדיקת כתובות ועד קו מלא עם חקירות ודיווח, כדי שתוכלו להשוות בין לוחות זמנים לעומק הבקרה.
המסירה לתפעול מתבצעת בשלב נפרד: נהלים לטיפול במקרים שנויים במחלוקת, בקרה על התראות שווא, הדרכת מפעילים. תארו את המשימה — נדון בפרטים ונחזור עם תוכנית.