איך מתכננים תור בדיקות KYC שמתרחב

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

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

Straight-through הוא המטרה, התור הוא החריג

Straight-through processing (STP) אומר שבקשה נפתרת מקצה לקצה בלי מגע אנושי: מסמכים נקראים, זהות מותאמת, סינון סנקציות ו-PEP נקי, בדיקת liveness עברה, ההחלטה נרשמה. זו אמורה להיות הדרך הנפוצה, ושיעור הבקשות שעוברות בה, שיעור ה-STP, הוא המספר היחיד שמלמד אם התור יתרחב. אם תשעים ומשהו אחוזים נפתרים אוטומטית, התור האנושי מחזיק טפטוף סביר; אם חצי מהם נופלים לבדיקה, אתם מגייסים בודקים בקצב הצמיחה. התור הוא לא המקום שבו KYC מתרחש. הוא המקום שבו KYC אוטומטי מודה שאינו בטוח. הגדלת שיעור ה-STP משפרת בחינם כל מספר אחר: פחות מקרים בתור, המתנות קצרות יותר, פחות בודקים לגייס. שווה לתקוף אותו ישירות: צילום מסמכים טוב יותר בצד הלקוח, הוראות ברורות יותר לפני הצילום, ספי התאמה מכוונים כך שלקוחות אמיתיים לא יידחו בגלל כלל זהיר מדי. כי כל אחוז שמוחזר שם הוא מקרה שלעולם לא יהפוך לאחר הצהריים של מישהו.

מה מגיע לתור, ולמה

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

תור אחד לא מספיק: פלחו לפי סיבה

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

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

פעולות מבוקרות שחייבות נימוק

כל החלטה של סוקר — אישור, דחייה, הסלמה, בקשת מסמכים נוספים — חייבת לכלול נימוק ולהירשם. לא הערה חופשית שנוספה בדיעבד, אלא בחירה מובנית שמסבירה למה הפעולה בוצעה, ונשמרת ברגע ביצועה. זו לא בירוקרטיה; זה מה שהופך את התור לניתן להגנה. כשרגולטור, מבקר או סוקר מאוחר יותר שואלים למה חשבון אושר למרות דגל, התשובה היא סוקר מזוהה בשמו, חותמת זמן ונימוק מוצהר — לא משיכת כתפיים. נתיב הביקורת הוא append-only, ולכן אי אפשר לשכתב החלטה בשקט בדיעבד; תיקונים הם רשומות חדשות ולא עריכה של רשומות ישנות. בסטאק שלנו התור ומודל הביקורת שלו נמצאים ב-Protocore Center (/products/center), קונסולת המפעיל שבה כל פעולה מורשית דורשת נימוק ונרשמת ביומן שאי אפשר לשנות בלי להשאיר עקבות.

מקרי ארבע עיניים

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

תכנון לנפח: התיישנות, תעדוף, SLA

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

מדידת התור

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

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