digital identity verification

KYC אינו אימות גיל: מתי פלטפורמות דיגיטליות צריכות אחד מהם, את השני או את שניהם?

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

Biplob Mudi עודכן 29 September 2026 7 min נקרא אימות זהות ו-KYC

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

האם הפלטפורמה השלימה KYC? האם היא אימתה את גיל המשתמש? או שהיא פשוט אימתה את זהותו?

השאלות האלה נשמעות דומות, אבל הן אינן אותו הדבר.

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

נקודת הפתיחה הנכונה פשוטה: מה הפלטפורמה באמת צריכה לוודא לגבי האדם הזה?

KYC עונה על שאלה רחבה יותר מגיל

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

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

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

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

אימות גיל עונה על שאלה אחרת

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

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

אין פירוש הדבר בהכרח שהשירות צריך לדעת את זהותו המלאה של האדם.

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

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

אימות גיל לא תמיד אומר שהזהות אומתה

נניח שפלטפורמה מקבלת תוצאה מהימנה מתהליך הבטחת גיל:

"המשתמש מעל גיל 18: כן."

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

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

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

זהות מאומתת אינה אומרת אוטומטית שהושלם KYC

גם אי-ההבנה ההפוכה נפוצה.

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

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

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

לכן אימות זהות יכול להיות חלק מ-KYC מבלי להיות זהה ל-KYC.

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

מתי פלטפורמה עשויה להזדקק לאימות גיל?

התחילו מהשירות עצמו.

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

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

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

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

זה שונה באופן מהותי מהצבת תיבת סימון "אני בן 18 ומעלה" בדף ההרשמה.

מתי KYC עשוי להידרש?

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

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

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

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

מתי פלטפורמה עשויה להזדקק לשניהם?

במקרים מסוימים, שתי הדרישות נפגשות.

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

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

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

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

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

ארבע שאלות שכדאי לשאול לפני שבונים את תהליך האימות

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

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

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

ההבחנה היא במטרה, לא במונחים

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

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

נקודת הפתיחה ההגיונית אינה "כמה אנחנו יכולים לאמת?"

אלא: "מה אנחנו צריכים לדעת, מדוע אנחנו צריכים לדעת זאת, ומהי הדרך המידתית לקבוע זאת?"

תגיות: אימות משתמש