מדריך לסינון סנקציות: איך עבודת הציות באמת מתבצעת

סינון סנקציות הפסיק להיות רשימת בדיקה חד-יומית מאז שמאגרי נתונים מסחריים מרכזיים החלו לרענן נתוני סנקציות מספר פעמים ביום על פני עשרות עד מאות רשימות רשמיות. LexisNexis מציינת שהכיסוי שלה משתרע על 180 רשימות סנקציות גלובליות בתוספת 1,700 מקורות אכיפה ותיקי בית משפט, עם עדכונים עד ארבע פעמים ביום תוך 24 שעות מפרסום המקור (LexisNexis WorldCompliance Data). היקף זה משנה את אופי העבודה. אנליסטים כבר לא בודקים שם מול רשימה סטטית, אלא מפעילים בקרה מתמשכת על לקוחות, צדדים נגדיים, תשלומים ושינויי בעלות, וזה חייב לפעול מהר מספיק כדי לעצור עסקה בעייתית לפני הסליקה.

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

תוכן העניינים

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

מהו באמת סינון סנקציות

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

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

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

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

הסביבה הרגולטורית ומדוע היא חשובה

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

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

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

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

כיצד פועלים מנועי ההתאמה מאחורי הקלעים

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

הנרמול מגיע ראשון

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

הדירוג מודד התאמות סבירות

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

החלטות תלויות בספי סף

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

לתצוגה עסקית מעמיקה יותר על זיהוי דפוסים אוטומטי, ראו ELECTE su ML per business.

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

התאמות שגויות ובעיית שלמות הנתונים

התראות שווא מסמנות תוכנית שנשענת יותר מדי על התאמה רופפת או על נתוני מקור חלשים. דיווחים מהתעשייה המצוטטים בתקציר מציינים כי בין 95 ל-99 אחוז מהתראות בדיקת הסנקציות הן התראות שווא, כלומר רק כ-1 עד 5 אחוזים הן התאמות אמיתיות המחייבות הסלמה (Ionova false positives). זו הסיבה שהוספת בודקים נוספים כמעט אף פעם לא פותרת את הבעיה. אם התור רועש, אנשים עדיין מבזבזים זמן על ניקוי רשומות שלא היו מסוכנות מעולם.

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

מזהים משניים עושים את העבודה הקשה

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

קלטים מלוכלכים יוצרים פלטים רועשים

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

הרגל שימושי הוא לבדוק את אותו התור בתנאי נתונים מרובים, לא רק בהתאמות שם מדויקות.

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

בעלות, כינויים ומורכבות חוצת-משטרים

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

מדוע כינויים חשובים בדיוק כמו שמות

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

בדיקות משטר יחיד משאירות פערים

קטע ההנחיות של התעשייה מציין שהמשיבים דירגו את איכות הנתונים (26.85%) לפני מורכבות בעלות מוטבת (16.11%) ו-ציות רב-משטרי (14.77%) (מדריך הסנקציות של AML Watcher). זה מצביע על בעיית נתונים לא פחות מאשר בעיית מדיניות. תוכנית הבנויה סביב משפחת רשימות אחת פשוטה יותר להפעלה, אך היא עלולה לפספס חשיפה כאשר אותו לקוח, תשלום, או צד נגדי נוגע ביותר מיקום סנקציות אחד.

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

היכן ELECTE משתלבת במערך הציות

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

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

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

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

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

עיקרי הדברים ורשימת בדיקה מעשית

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

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

1. התייחסו לקליטת הנתונים כאמצעי בקרה. ודאו ששמות, כתובות, מספרי זיהוי ונתוני בעלות מתקבלים במלואם מכל מערכת מקור.
2. כוונו את הספים לתיק הלקוחות שלכם. בדקו מחדש לאחר שינויים באוכלוסיית הלקוחות, במקום להסתמך על ההגדרות המובנות של הספק.
3. העשירו עם מזהים משניים. הפכו את תאריך הלידה, המדינה ומספר הזיהוי לחלק מלוגיקת הבדיקה.
4. בצעו סינון גם בקליטת הלקוח וגם בעת תשלום. אל תניחו שבדיקה אחת מכסה את מחזור החיים המלא.
5. כללו בעלות עקיפה. תעדו כיצד אתם מיישמים את כלל ה-50 אחוזים ולוגיקת הבעלות הנלווית.
6. רעננו רשימות במהירות. התאימו את אימוץ הרשימות לרמת הסיכון התפעולי ולתדירות הריענון שלכם.
7. עקבו אחר זמני טיפול בהתראות שגויות. מחזורי בדיקה איטיים הם בעיית בקרה, לא רק בעיה תפעולית.
8. שמרו עדויות ביקורת. שמרו את הלוגיקה, נקודות הנתונים וההחלטה הסופית עבור כל מקרה.
9. בדקו נתיבי תעתיק. כללו וריאציות שמות בערבית-לטינית ואחרות במדגמי האימות.
10. סקרו פערי כיסוי ברשימות. בדקו אם משטר אחד או משפחת מקורות אחת יוצרים נקודות עיוורות.
11. הגדירו בעלות על הבקרה. ציינו בעל עסקי, לא רק בעל טכני.
12. בדקו מחדש לאחר שינויים. כל רשימה, שדה או שינוי באוכלוסייה חדשים צריכים להפעיל סקירת בקרה.

שאלות נפוצות על סינון סנקציות

באיזו תדירות יש לרענן רשימות מעקב? בתדירות הנדרשת על פי הסיכון התפעולי שלכם, אך הנתונים המאומתים בתדריך מראים שמסדי נתונים מסחריים מרכזיים מתעדכנים כיום מספר פעמים ביום, כאשר LexisNexis מציינת עד ארבעה עדכונים ביום בתוך 24 שעות מפרסום המקור (LexisNexis WorldCompliance Data). אם עדכון הזנה נכשל, השעו את תלות הסינון המושפעת, תעדו את התקרית והחילו את הפתרון החוזר המתועד שלכם כדי שתוכלו להוכיח שלא נעשה שימוש עיוור בהזנה לא מעודכנת.

כיצד מאמתים ספי התאמה מקורבת (fuzzy matching) מבלי לגרום להתאמת יתר (overfitting)? השתמשו בסט אימות מתויג הכולל התאמות מדויקות, תעתיקים, וריאציות רווחים ושליליים אמיתיים, ולאחר מכן בדקו מחדש לאחר שינויים ברשימות או באוכלוסיית הלקוחות. אל תכוונו את המודל רק על סמך התור הישן, כי הדבר עלול לגרום למודל להיראות טוב על מקרים היסטוריים בעוד שהוא מפספס דוגמאות חדשות.

כיצד סינון בעלות מתמודד עם ספי אגרגציה של 50 אחוז ומעלה? במודל של OFAC, המבחן המרכזי הוא האם אדם חסום אחד או יותר מחזיקים 50 אחוז או יותר באגרגציה, במישרין או בעקיפין (OFAC FAQ). זה אומר שאתם זקוקים לנתוני בעלות, לא רק לנתוני שמות, ולדרך לעקוב אחר חשיפה עקיפה באמצעות חברות בת וגופים קשורים.

מהו ההבדל בין בדיקת עסקאות (transaction screening) לבדיקת לקוחות (customer screening)? בדיקת לקוחות בוחנת את הקשר בעת קליטת הלקוח (onboarding) ובמהלך שינויים במחזור החיים שלו. בדיקת עסקאות בוחנת את אירוע התשלום, ההעברה הבנקאית או העסקה עצמה, כך שהיא יכולה לזהות סיכון שמופיע לאחר פתיחת החשבון.

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

מתי יש להעביר התאמת שם לבדיקה נוספת (escalate) ומתי לאשר אוטומטית (auto-clear)? יש לאשר אוטומטית רק כאשר מזהים משניים והמדיניות המתועדת שלכם תומכים בתוצאה זו. אם המזהים חלקיים, סותרים או באיכות נמוכה, יש להעביר את המקרה לבדיקה נוספת ולשמור את מסלול ההחלטה.

בדיקת סנקציות (sanctions screening) עובדת בצורה הטובה ביותר כאשר מתייחסים אליה כאל בקרה חיה, ולא כמסנן סטטי. ELECTE עוזרת לצוותים להפוך נתוני התראות, ראיות בעלות ובעלים, ותוצאות בדיקה לניתוחים ברורים התומכים בבדיקה ובממשל תאגידי. אם אתם מחפשים דרך מדידה יותר לניהול פעילות ציות (compliance operations), בקרו באתר ELECTE וגלו כיצד הפלטפורמה יכולה לעזור לכם להפוך נתוני בקרה מבולגנים להחלטות שאתם יכולים להגן עליהן.