פיתוח מערכת לבדיקת PEP (אנשים בעלי חשיפה פוליטית)

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

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

שאלות נפוצות

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

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

בדיקת PEP: היכן התהליך נשבר ומה החברה מפסידה

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

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

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

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

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

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

מה נותן סינון לקוחות וצדדים נגדיים בנוי היטב

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

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

מהירות קליטה ובקשות חוזרות

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

פחות בדיקות ידניות וסירובים שהוחמצו

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

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

מצבי סינון: חד-פעמי, תקופתי, רציף

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

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

סינון חד-פעמי בכניסה

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

בקרה רציפה ובדיקה חוזרת של המאגר

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

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

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

ביקורת המאגר והכללים הנוכחיים

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

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

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

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

מה אנו מוסרים לידיים: תקנונים, מדיניות, הגדרות

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

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

תרשים נתונים וכללי גישה

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

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

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

מה היה לפני ומה נהיה אחרי

מדד סינון לפני אחרי
שיעור התראות שווא 74% 18%
בקשות לבדיקה ידנית ביממה 1200 260
זמן עד הסרה מבדיקה ידנית 40 דקות 6 דקות
בדיקת בקשה אחת בידי אנליסט 25 דקות 8 דקות

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

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

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

במה שונה בדיקת PEP חד-פעמית מבקרה רציפה?

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

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

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

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

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

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

מה לעשות אם בנתוני המקור יש פערים?

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

כיצד מופרדת הגישה לתוצאות?

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

מה עם סודיות ואחסון רשומות?

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

נדון במשימה ונחזור עם הערכה ותוכנית

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

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

מה נדרש מכם להתחלה ומה אנו מוסרים בשלב הראשון:

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

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