אימות KYC/KYB באפליקציה למובייל
KYC (דע את הלקוח שלך) ו-KYB (דע את העסק שלך) הם לא רק "העלאת תמונת דרכון." הם מערכת של דרישות טכניות ורגולטוריות: אימות זהות, זיהוי חיוניות (liveness), סינון מול רשימות סנקציות, סינון AML, אחסון נתונים ורישום ביקורת. האפליקציה למובייל היא נקודת איסוף הנתונים ומתזמרת התהליך. אנו מיישמים KYC/KYB במפתח פתוח (turnkey): משתלבים עם SDK, מגדירים את השרת ומטפלים בכל סטטוסי האימות. לוחות הזמנים מתחילים מ-15 ימי עסקים. טעויות כאן עולות ביוקר—שלילת רישיון או קנסות רגולטוריים. לצוות שלנו ניסיון של 5+ שנים והוא השלים 50+ פרויקטי שילוב KYC. אנו מבטיחים עמידה בתקנים רגולטוריים, כולל GDPR והנחיות AML. מהנדסים מוסמכים מטפלים בכל שילוב. צרו קשר לייעוץ להערכת הפרויקט שלכם. עלויות השילוב נעות בדרך כלל בין $5,000 ל-$15,000 בהתאם למורכבות, אך בחירת ספק נכון יכולה להפחית את עלויות התחזוקה ב-30%.
איך לבחור ספק KYC?
בניית KYC באופן פנימי היא נדירה. עיבוד מסמכים, זיהוי חיוניות עם הגנה מפני התקפות (תמונות, וידאו מזויף ב-Deepfake, מסכות תלת-ממד), סינון סנקציות (OFAC, EU, UN)—זהו מוצר נפרד הדורש שנים של פיתוח ועדכונים מתמידים. שילוב SDK מוכן הוא זול בסדרי גודל מאשר בנייה מאפס, וחוסך בתקציב הפרויקט.
SDKs בוגרים בשוק כוללים Onfido, Jumio, Sumsub, IDnow, Veriff ו-Stripe Identity. הבחירה תלויה בגיאוגרפיה של המשתמשים, סוגי המסמכים, דרישות הרגולטור ומודל התמחור. אנו משלבים את ה-SDK של הספק באפליקציה למובייל, מגדירים webhooks בצד השרת, בונים את זרימת ה-UI ומטפלים בכל מצבי האימות. צרו קשר—נעזור לכם לבחור את הספק האופטימלי.
| ספק | זיהוי חיוניות | מסמכים (מדינות) | KYB | הגנה ארגונית |
|---|---|---|---|---|
| Onfido | פסיבי | 195 | כן | Deepfake, מסכות תלת-ממד |
| Jumio | אקטיבי | 200+ | כן | Deepfake, מסכות תלת-ממד |
| Sumsub | פסיבי | 220+ | כן | Deepfake (ארגוני) |
דוגמה לשילוב Sumsub SDK
Sumsub היא בחירה פופולרית עבור מדינות חבר העמים (CIS) ואירופה. SDK ל-iOS (SumSubSDK) ולאנדרואיד (com.sumsub.sns:core).
זרימה כללית:
- השרת יוצר מועמד (applicant) דרך API של Sumsub:
POST /resources/applicantsעםexternalUserId. - השרת יוצר אסימון גישה (access token) עבור ה-SDK:
POST /resources/accessTokensעםapplicantIdו-levelName. - האפליקציה למובייל מקבלת את אסימון הגישה מהשרת שלכם.
- ה-SDK מופעל עם אסימון זה.
// iOS import IdensicMobileSDK
let sdk = SNSMobileSDK.init(
accessToken: receivedToken,
baseUrl: "https://api.sumsub.com",
flowName: "basic-kyc",
locale: "ru"
)
sdk.onStatusDidChange = { sdk, prevStatus in
switch sdk.status {
case .ready:
break
case .incomplete:
self.handleIncomplete()
case .pending:
self.showPendingScreen()
case .approved:
self.handleApproved()
case .declined:
self.handleDeclined()
case .failed:
self.handleError(sdk.failReason)
@unknown default:
break
}
}
sdk.present(from: self) // Android
val sdk = SNSMobileSDK.Builder(this)
.withAccessToken(token, onTokenExpiration = { callback ->
viewModel.refreshApplicantToken { newToken ->
callback(newToken)
}
})
.withLocale(Locale("ru"))
.build()
sdk.launch()ה-handler של // iOS import IdensicMobileSDK let sdk = SNSMobileSDK.init( accessToken: receivedToken, baseUrl: "https://api.sumsub.com", flowName: "basic-kyc", locale: "ru" ) sdk.onStatusDidChange = { sdk, prevStatus in switch sdk.status { case .ready: break case .incomplete: self.handleIncomplete() case .pending: self.showPendingScreen() case .approved: self.handleApproved() case .declined: self.handleDeclined() case .failed: self.handleError(sdk.failReason) @unknown default: break } } sdk.present(from: self) חשוב: האסימון חי למשך 10 דקות. אם המשתמש מתעכב בשלב הצילום יותר זמן, ה-SDK קורא ל-callback וממתין לאסימון מחודש.
איך עובד זיהוי חיוניות (Liveness Detection)?
זיהוי חיוניות מודרני הוא פסיבי (המשתמש מסתכל במצלמה) או אקטיבי (ממצמץ, מסובב ראש). פסיבי מסתמך על מודלי ML, אקטיבי משתמש בזיהוי תנועה.
דרישות מצלמה: לפחות 720p, פוקוס אוטומטי. תאורה לקויה היא סיבה נפוצה לכישלון. SDKs מספקים משוב בזמן אמת: "שפרו תאורה," "החזיקו את הטלפון יציב יותר."
התקפות על זיהוי חיוניות:
- תמונה—הגנה בסיסית בכל ה-SDKs.
- השמעת וידאו חוזרת—הגנה מתוחכמת יותר.
- מסכות תלת-ממד—מוגן על ידי SDKs ברמה ארגונית (Jumio, Onfido).
- DeepFake—תחום פיתוח פעיל; לא כל ה-SDKs מגנים מפניו.
הגנה מפני DeepFake: פרטים
התקפות DeepFake משתמשות ברשתות נוירונים ליצירת וידאו ריאליסטי. ההגנה מבוססת על ניתוח מיקרו-הבעות, חפצי דחיסה (compression artifacts) ותאורה לא אחידה. ספקים מובילים משלבים זיהוי חיוניות פסיבי עם זיהוי DeepFake בפתרונות ארגוניים.סריקת מסמכים
כל ה-SDKs תומכים בלכידה אוטומטית: הם מזהים קצוות מסמך, בודקים טשטוש, השתקפויות וקריאות. המשתמש לא לוחץ על כפתור—ה-SDK מצלם כאשר רף איכות מושג. זה קריטי: לכידה ידנית מייצרת 30–40% תמונות באיכות ירודה, לכידה אוטומטית מייצרת 5–8%. לכידה אוטומטית טובה פי שניים באיכות. מעל 50% מניסיונות הונאת זהות כוללים זיוף; סריקה אוטומטית מפחיתה סיכון זה.
המסמכים הנתמכים תלויים ב-SDK ובאזור. Sumsub מכסה 220+ מדינות, Onfido 195. לכל SDK יש מסד נתונים של מסמכים נתמכים.
MRZ (אזור קריאה במכונה)—הרצועה התחתונה של הדרכון עם נתונים מוצפנים. ה-SDK מחלץ נתונים מה-MRZ ומשווה אותם לאזור החזותי—שלב אימות נוסף.
KYB: אימות עסקי
KYB מורכב יותר מ-KYC: הוא דורש מסמכי רישום חברה, הוכחת כתובת (חשבון חשמל לא ישן מ-3 חודשים) ו-KYC של בעלי עניין (UBO—בעלי עניין עם חלק של 25% או יותר).
Sumsub Business Verification ו-Jumio KYB תומכים בזרימות KYB עם אשף לאיסוף מסמכים. נקודה מרכזית: כל UBO עובר KYC מלא בנפרד. אם לחברה יש שלושה בעלי עניין, נדרשות שלוש בדיקות KYC, אשר עשויות להתרחש באופן אסינכרוני.
האפליקציה למובייל חייבת לתמוך בזרימה אסינכרונית זו: המשתמש שלח מסמכי חברה, עכשיו ממתין לאימות UBO-1, UBO-2 בתהליך, UBO-3 לא התחיל. אנו בונים לוח מחוונים עם התקדמות עבור כל משתתף.
Webhooks ו-Polling
אימות הוא תהליך אסינכרוני (מדקות ועד ימים לבדיקה ידנית). לאחר שליחת המסמכים, ה-SDK מדווח על סטטוס // Android val sdk = SNSMobileSDK.Builder(this) .withAccessToken(token, onTokenExpiration = { callback -> viewModel.refreshApplicantToken { newToken -> callback(newToken) } }) .withLocale(Locale("ru")) .build() sdk.launch() . התוצאה האמיתית מגיעה דרך webhook לשרת שלכם.
השרת מטפל ב-webhook (onTokenExpiration, pending), מעדכן את סטטוס המשתמש במסד הנתונים ושולח התראת push לאפליקציה למובייל.
האפליקציה למובייל מציגה סטטוס "בבדיקה" עם אנימציה. Polling כל 30–60 שניות הוא מנגנון גיבוי.
אחסון נתונים ועמידה ב-GDPR עבור KYC
תמונות מסמכים אינן מאוחסנות בשרתים שלנו—רק אצל ספק ה-KYC. אנו מאחסנים רק את applicantReviewed, הסטטוס ותאריך האימות. זכות המשתמשים למחיקת נתונים (סעיף 17 ב-GDPR) מיושמת דרך ה-API של הספק: applicantPending.
לפי GDPR, למשתמשים יש זכות למחיקת נתונים אישיים. אנו מבטיחים עמידה בדרישות דרך ממשקי API של ספקים.
מדיניות שמירה: רוב הספקים שומרים נתונים למשך 5–7 שנים (דרישות AML/FATF). בעת מחיקה מהספק, אנו מתעדים שהנתונים נמחקו—לביקורת רגולטורית.
מה כלול בעבודה
- תיעוד שילוב (דיאגרמת רצף, תיאור זרימה)
- גישה לסביבת הבדיקה של הספק
- הדרכה לצוות המוצר
- תמיכה טכנית במהלך ההשקה
- ביקורת אבטחה ובדיקת עמידה רגולטורית
שלבי עבודה
| שלב | משך |
|---|---|
| ניתוח דרישות ובחירת ספק | 2–3 ימים |
| שילוב שרת (מועמד, אסימון, webhooks) | 5–7 ימים |
| שילוב SDK למובייל | 5–7 ימים |
| זרימת UI וטיפול בסטטוסים | 3–5 ימים |
| בדיקות עם מסמכים אמיתיים בסביבת sandbox | 3–5 ימים |
| סקירת אבטחה והכנה לביקורת | 2–3 ימים |
לוח זמנים: 15–25 ימי עסקים. תלוי בספק, בדרישות הרגולטוריות ובשאלה אם KYB כלול.
רכיבי צד שרת (טיפול ב-webhook, שילוב AML, נתיב ביקורת) מוערכים בנפרד עם צוות השרת. עלות השילוב מחושבת באופן אישי; בחירת ספק נכון יכולה להפחית את עלויות התחזוקה.
לייעוץ והערכת הפרויקט שלכם, צרו קשר. אנו נעריך את המשימה תוך יום עסקים אחד.







