מערכת KYC/AML מבוססת בינה מלאכותית: אוטומציה של ציות בפינטק

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

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

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

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

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

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

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

מה משתנה לאחר ההטמעה: השפעות מדידות

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

מהירות בדיקת לקוח

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

התראות שווא

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

סוג הסירובים שנעלם

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

בדיקת KYC: השוואת מצבים ומגבלות

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

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

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

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

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

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

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

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

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

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

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

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

כיצד צמצמנו בדיקה ידנית: מקרה בוחן עם מדדים

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

מה שינינו

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

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

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

במה שונים כללים וספים ממודלים להערכת סיכון

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

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

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

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

ספקות טכניים נפוצים לפני ההתחלה

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

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

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

כיצד מוגנים נתונים אישיים?

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

יש לנו כבר מערכת בדיקות פרוסה

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

כיצד להרחיב למוצרים חדשים?

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

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

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

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

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

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