העברת כספים לפי מספר טלפון

עובדה: המטרה העסקית - להעלות את נפח העברות ה-P2P ולהוריד את הנטישה בתהליך ההעברה. עובדה: התהליך כפוף לחוק איסור הלבנת הון ולמשטר ה-AML של הבנק. עובדה: הצו לחברות תשלום (נובמבר 2024) מחייב זיהוי לקוח, דיווח ורישום מסודר של פעולות התשלום. עובדה: הנחיית הזיהוי המקוון של רשות ניירות ערך (פברואר 2025) מאפשרת KYC ללא פגישה פיזית, אך מחייבת אחראי ציות ותהליך זיהוי מתועד. עובדה: מעל סף כספי מוגדר קיימת חובת דיווח ל-IMPA (הרשות לאיסור הלבנת הון ומימון טרור). דרישה עסקית: משתמש מזוהה יוכל לשלוח כסף לנמען לפי מספר טלפון בלבד. דרישה עסקית: המערכת תכבד מגבלת סכום יומית וחודשית לפי דרגת ה-KYC של המשתמש (KYC tier). דרישה עסקית: יוגדר חלון ביטול קצר להעברה, לפני שהיא נחשבת סופית. דרישה עסקית: פעולות מעל הסף הרגולטורי יסומנו לבדיקה ולדיווח. הנחה: דרגת KYC בסיסית תספיק למגבלת סכום נמוכה, ודרגה מלאה תדרוש להעלאת מגבלה. הנחה: הגורם הרגולטורי יאשר תהליך זיהוי מקוון כתחליף לפגישה פיזית. מחוץ להיקף (Out of Scope) לגרסה הזו: העברות בינלאומיות, העברות לבתי עסק, ומטבעות שאינם שקל. מדדי הצלחה: עלייה מדידה בנפח P2P החודשי מול ה-Baseline; שיעור השלמה גבוה יותר לתהליך שהתחיל; שיעור חסימות/דחיות שנשאר בטווח שהוגדר מראש עם הציות.

עובדה: מספר טלפון אינו מזהה יציב לצמיתות - אנשים מחליפים מספר, ומספרים ממוחזרים בין לקוחות שונים אצל המפעילים הסלולריים. עובדה: לא לכל מקבל פוטנציאלי יש חשבון קיים בבנק או באפליקציה. עובדה: מגבלת סכום לפי דרגת KYC כבר הוגדרה כדרישה עסקית. המתח החריף ביותר שצריך להכריע בו: מה קורה כשמספר טלפון עבר בעלות. אם המשתמש שומר איש קשר בשם "אמא", אבל המספר הזה כבר משויך לאדם אחר, הכסף עלול להגיע לזר. זו לא תקלה נדירה - זו שאלת ליבה של המוצר. הנחה: נזדקק לשלב אישור שבו המשתמש רואה את שם הנמען כפי שהוא רשום במערכת, לפני שההעברה יוצאת. הנחה: כשהנמען אינו לקוח קיים, נצטרך מנגנון הזמנה - קישור עמוק (deep link) או SMS - שמזמין אותו לפתוח חשבון ולמשוך את הכסף בתוך חלון זמן מוגבל. שאלות ליבה שדורשות הכרעה: סיכון גבוה: איך המשתמש מוודא שהמספר שייך למי שהוא חושב? האם נציג שם, ראשי תיבות, או תמונת פרופיל? סיכון גבוה: מה קורה לכסף שנשלח לנמען בלי חשבון ולא נמשך בתוך החלון - חוזר אוטומטית? סיכון בינוני: האם מגבלת הסכום מוצגת למשתמש מראש, או רק כשהוא חורג ממנה? סיכון בינוני: מה קורה כשהמשתמש מגיע למגבלה החודשית - חסימה מלאה, או הצעה לשדרג דרגת KYC? סיכון נמוך: האם מותר להעביר לעצמך בין חשבונות, וזה נספר במגבלה?

עובדה: הזרימה הבסיסית - המשתמש בוחר נמען מאנשי הקשר או מקליד מספר, מזין סכום, רואה מסך אישור, ומאשר. עובדה: לפני אישור, המערכת מציגה את שם הנמען כפי שהוא רשום, כדי לצמצם טעות זיהוי. עובדה: פעולה מעל הסף הרגולטורי מסומנת לבדיקת AML ולדיווח ל-IMPA לפי הצורך. כללי אימות ומגבלות: עובדה: לכל דרגת KYC מגבלת סכום יומית וחודשית. דוגמה לצורך ההמחשה - דרגה בסיסית עד 2,000 ש"ח ליום, דרגה מלאה עד 10,000 ש"ח ליום. המספרים הסופיים נקבעים מול הציות. עובדה: חלון ביטול קצר, לצורך ההמחשה 30 שניות, שבו המשתמש יכול לעצור העברה לפני שהיא סופית. זרימת נמען ללא חשבון: עובדה: אם המספר אינו משויך ללקוח קיים, נשלח לנמען קישור עמוק ב-SMS שמזמין אותו לפתוח חשבון ולמשוך את הכסף בתוך חלון מוגדר (לצורך ההמחשה 7 ימים). עובדה: אם הכסף לא נמשך עד תום החלון, הוא חוזר אוטומטית למשלם, והמשלם מקבל הודעה. מצבי שגיאה שחייבים טיפול: עובדה: מספר לא תקין או לא קיים ברשת - חסימה עם הסבר. עובדה: חריגה ממגבלת KYC - הודעה ברורה והצעה לשדרג דרגה, לא כישלון סתום. עובדה: זיהוי דפוס חשוד (סכום חריג, ריבוי נמענים חדשים בזמן קצר) - העברה מושהית לבדיקה. הנחה: רוב ההעברות יהיו לנמענים קיימים ובסכומים נמוכים, ולכן זרימת המקרה הנפוץ חייבת להיות קצרה, בעוד החיכוך שמור לקצוות המסוכנים.

עובדה: ה-Backlog בנוי סביב אפיקים ראשיים, וכל אפיק מתפרק למשימות פיתוח. אפיק - זרימת העברה בסיסית (MVP): עובדה: בחירת נמען מאנשי קשר או הקלדת מספר, מסך סכום, מסך אישור עם שם הנמען. הערכה גסה - כ-15 ימי פיתוח. אפיק - אימות זהות ומגבלות KYC (MVP): עובדה: אכיפת מגבלת סכום יומית וחודשית לפי דרגה, והצגת הודעת חריגה. הערכה גסה - כ-10 ימי פיתוח. אפיק - חלון ביטול (MVP): עובדה: השהיית ההעברה למשך חלון קצר עם אפשרות ביטול. הערכה גסה - כ-6 ימי פיתוח. אפיק - נמען ללא חשבון (אחרי MVP): עובדה: שליחת קישור עמוק ב-SMS, חלון משיכה, והחזרה אוטומטית של כסף שלא נמשך. הערכה גסה - כ-12 ימי פיתוח. אפיק - זיהוי הונאה ודיווח (MVP חלקי): עובדה: סימון פעולות מעל הסף לבדיקה, והשהיה אוטומטית של דפוסים חשודים. חלק זה הכרחי כבר ב-MVP בגלל הרגולציה. הערכה גסה - כ-10 ימי פיתוח. הנחה: אפיק הנמען ללא חשבון הוא הכבד ביותר מבחינת קצוות, ולכן נדחה לאחרי ה-MVP, כדי לצאת לאוויר עם זרימה בין לקוחות קיימים תחילה. הנחה: ההערכות הן גסות ומיועדות לתעדוף בלבד, לא להתחייבות לוחות זמנים.

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

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

עובדה: ה-KPI העסקי המרכזי - נפח העברות P2P החודשי ושיעור ההשלמה של תהליך שהתחיל. אירועים לתיעוד לאורך המשפך: עובדה: פתיחת מסך העברה, הזנת נמען, הצגת מסך אישור, אישור סופי, השלמת העברה. כל שלב הוא נקודת נשירה אפשרית. עובדה: אירוע חריגת מגבלת KYC, אירוע ביטול בתוך החלון, אירוע השהיה לבדיקת הונאה. מדדי משפך: עובדה: שיעור המעבר בין כל שלב לשלב הבא. כאן נראה איפה בדיוק אנשים נוטשים - האם במסך האישור, בגלל מגבלת סכום, או קודם. עובדה: שיעור ההעברות שנחסמו מסך הכל, מפוצל לפי סיבה - מגבלה, זיהוי הונאה, מספר לא תקין. מדדי בריאות: עובדה: זמן ממוצע להשלמת העברה מרגע הפתיחה. עובדה: שיעור ההעברות לנמענים חדשים מול נמענים חוזרים. עובדה: שיעור הכסף שנשלח לנמען ללא חשבון ולא נמשך (חזר אוטומטית). הנחה: ירידה בנטישה במסך האישור תעיד שהצגת שם הנמען עובדת. אם דווקא שם הנטישה עולה, ייתכן שהשם שאנחנו מציגים מבלבל ולא מרגיע. הנחה: עלייה חדה בשיעור החסימות בגלל הונאה עשויה להיות סימן טוב (המנגנון תופס) או רע (יותר מדי false positives). צריך לפצל את המדד כדי להבחין.

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

עובדה: זהו תוצר תקשורת, לא תוצר תכנון. המטרה שלו היא שמנהל יקרא אותו בדקה וידע בדיוק מה מצב הפרויקט ומה נדרש ממנו. מה הושג: עובדה: הושלמו BRD ו-PRD, כולל אילוצי הרגולציה (AML, KYC, סף דיווח ל-IMPA). עובדה: ה-Backlog מתועדף, וזרימת ההעברה בין לקוחות קיימים מוגדרת כ-MVP. עובדה: מטריצת תרחישי הבדיקה של הקצוות - זהות, הונאה ורגולציה - מוכנה. מה בסיכון: עובדה: זרימת הנמען ללא חשבון נדחתה לאחרי ה-MVP. אם הצוות העסקי רואה בה דרישה חוסמת, לוח הזמנים ישתנה. עובדה: מגבלות הסכום לכל דרגת KYC עדיין ממתינות לאישור סופי מהציות, וזה חוסם חלק מהפיתוח. עובדה: יש תלות במערכת זיהוי הונאה חיצונית - אם היא לא מוכנה בזמן, ה-MVP מתעכב. מה נדרש מההנהלה: עובדה: החלטה - האם MVP ללקוחות קיימים בלבד מספיק להשקה, או שחייבים בו גם נמען ללא חשבון. עובדה: זירוז אישור הציות למגבלות הסכום, כי זה חוסם היום. הנחה: הצגה כנה של מה שבסיכון עכשיו שווה יותר מהצגה ורודה שתתפוצץ בהמשך. מנהל שיודע מוקדם על תלות חיצונית יכול לעזור להסיר אותה.