כללי ה-KYC המתחרים
כללי הכרת הלקוח (KYC) יוצרים מתח אמיתי עבור חברות פינטק. הרגולטורים רוצים בדיקות זהות יסודיות. הם מחייבים חברות לאסוף ולאמת מסמכים אישיים. אבל חוקי הגנת המידע דוחפים לכיוון ההפוך. הם מחייבים חברות למזער את הנתונים הללו לאחר שנאספו.
בנק שפותח חשבון חדש אוסף מסמכים רבים. אלה כוללים תעודות זהות לאומיות, דרכונים ורישיונות נהיגה. הוא גם אוסף אישורי כתובת ומסמכים פיננסיים. קבצים אלו מכילים נתונים אישיים דחוסים. GDPR, כללי AML ומפקחים בנקאיים כולם מחייבים טיפול קפדני.
כאשר הנתונים הללו עוברים למערכות הונאה או ניתוח, חלים כללים נוספים. כללי הנתונים של GDPR נכנסים לתמונה. נתונים אישיים חייבים להיות מוסתרים או דה-מזוהים לפני כל שימוש שני.
בעיית הצבר של יומיים
בנק דיגיטלי עיבד 5,000 בקשות KYC יומיות ב-15 מדינות באיחוד האירופי. שלב סריקת ה-PII שלהם גרם לבעיה חמורה. שיעור החיוביות השגויות היה גבוה מדי. תורי הסקירה גדלו עד שהגיעו לצבר של יומיים.
הסיבה השורשית הייתה ברורה. הכלי מבוסס ה-ML שלהם סימן כ-8% מהטקסט שאינו PII כנתונים אישיים. לכל קובץ היו עמודים רבים. נפח החיוביות השגויות היומי היה גדול מכדי שהצוות יסיים בתוך יום אחד. הם המשיכו להיפגר.
החיוביות השגויות נפלו לשלוש קבוצות:
- שמות חברות שסומנו כשמות אנשים (המודל בלבל שמות פרטיים)
- קודי הפניה שסומנו כמספרי זהות (לא נעשה שימוש בבדיקת checksum)
- שמות פרטיים נפוצים כמו "Chase" בשמות בנקים שסומנו כ-PII שם-אדם
כל חיובית שגויה דרשה סקירה אנושית. ב-8% מ-5,000 קבצים יומיים, הדבר הניב אלפי משימות יומיות. אף אחת מהן לא ניתנה לאוטומציה.
מה מחקר ACL מראה
מחקר ACL 2024 בדק מודלי NLP רב-לשוניים לזיהוי PII. הממצא היה חד. רק 5% ממודלי NLP רב-לשוניים מגיעים לציון F1 טוב מ-85% עבור PII שאינו אנגלי בכל 24 שפות האיחוד האירופי.
ציון F1 משלב דיוק ו-recall. דיוק נמוך משמעו חיוביות שגויות רבות. recall נמוך משמעו פריטים שהוחמצו רבים. שני התוצאות מקבלות ציון נמוך. שיעור הכישלון של 95% לעמוד ב-85% F1 מראה עד כמה קשה סריקת PII רב-לשונית בפועל.
לשם השוואה, XLM-RoBERTa משיג 91.4% F1 רב-לשוני למשימות PII. נתון זה הוא מ-benchmarking של HuggingFace 2024. הפער בין 91.4% לבין המודל החציוני מסביר מדוע כלים מן המדף נכשלים ב-KYC רב-לשוני.
עיצוב היברידי ל-KYC בנפח גבוה
בעיית החיוביות השגויות ניתנת לפתרון. שלוש בחירות עיצוב פותרות אותה.
ביטוי רגולרי עם בדיקת checksum: למספרי זהות לאומיים יש כללים קבועים. Steuer-ID גרמני, BSN הולנדי ו-PESEL פולני כל אחד משתמש בחישוב checksum. אם מספר נכשל ב-checksum, הוא אינו תעודת זהות לאומית. פורמט בשילוב checksum מניב כמעט אפס חיוביות שגויות עבור מזהים אלו.
NLP מודע-הקשר לשמות: שמות אנשים בקבצי KYC מופיעים במקומות ידועים. אלה כוללים "שם:", "שם משפחה:" ושדות טפסים קבועים. דרישת מילת הקשר לפני סימון שם מפחיתה חיוביות שגויות. הדבר מונע מהפעלת שמות חברות על ידי התראות שם-אדם.
כיול סף לפי סוג קובץ: קבצי KYC שונים מאימיילים של תמיכה או הערות רפואיות. לכל סוג יש תמהיל PII שונה. קביעת ספים לפי סוג קובץ מאפשרת לצוותים לכייל לצרכיהם. KYC בנפח גבוה מקבל דיוק גבוה יותר. דה-זיהוי רפואי מקבל recall גבוה יותר.
הצבר של יומיים אינו עלות בלתי נמנעת של סריקת PII. הוא עלות של שימוש בכלים גנריים על זרימת עבודה ספציפית. הפתרון הוא הגדרה, לא צוות גדול יותר.
מדריך ציות GDPR שלנו מכסה כללי מזעור נתונים. סקירת האבטחה והציות שלנו מסבירה את הבקרות הטכניות התומכות בזרימות עבודה KYC תואמות.