אינטגרציה של ספק KYC לפרויקטים של קריפטו: Sumsub, Onfido, Jumio

אינטגרציה של ספק KYC: היכן נשבר נתיב המשתמש

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

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

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

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

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

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

מה נותן אימות מחובר: מהירות, דחיות, עבודה ידנית

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

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

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

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

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

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

שלוש דרכים לחבר אימות זהות והמגבלות שלהן

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

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

שלבי ההטמעה: מביקורת זרם הבדיקות ועד העברה לתמיכה

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

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

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

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

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

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

מקרה בוחן: חיבור ספק שני בלי לעצור את ההרשמה

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

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

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

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

התוצאה

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

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

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

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

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

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

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

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

ספקות טכניים: אבטחת נתונים, דחיות, בדיקה חוזרת

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

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

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

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

כיצד אימות חוזר משפיע על הגישה לחשבון?

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

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

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

• תרחישי בדיקה: את מי בודקים (אדם פרטי, חברה, נציג, בעל שליטה) ובאיזה שלב — הרשמה, עסקה ראשונה, משיכת כספים.
• הרמות הנדרשות: אילו מסמכים ואישורים חובה ואילו רשות, עבור אילו סמכויות שיפוט.
• נתיב הנתונים הנוכחי: היכן נאספים כעת נתוני הלקוח ולאן צריכה לחזור התוצאה — לאזור האישי, למערכת הנהלת החשבונות, לתור הבדיקה הידנית.
• סטטוסי הספק: אילו תשובות нужно לתמוך (הצלחה, דחייה, השלמה, בדיקה ידנית) ומה לעשות בכל אחת מהן בהמשך.
• מדיניות שמירה: תקופות שמירת נתונים אישיים, סדר המחיקה, מי אחראי לעיבוד בקשות של לקוחות.
• ספק והרשאות: נבחר מהמאגר (Sumsub, Onfido, Jumio) או שאלה פתוחה, מפתחות בדיקה ואיש קשר לתמיכה מצד הספק.
• מגבלות: תאריך ההשקה, חלון התגובה ללקוח, העומס הצפוי ביממה.

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