פיתוח מערכת מגבלות ואימות לבורסת קריפטו

מדוע מערכת המגבלות של הצ׳יינג׳ר נכשלת בעומס שיא

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

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

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

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

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

מה נותן בקרה אוטומטית על מגבלות ורמות אימות

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

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

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

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

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

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

דרכי ניהול רישום: השוואת גישות ומגבלות

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

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

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

שלבי העבודה: מניתוח זרימות בקשות עד מסירת נהלים

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

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

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

הרכב המסירה: תצורות, סכמות, נהלים, תיעוד

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

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

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

מקרה בוחן: איך צ׳יינג׳ר הסיר זיכויים כפולים בעומס שיא

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

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

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

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

מדדים לפני ואחרי: שיעור דחיות בגלל בקשות בו-זמניות — 4% מול 0.1%, תיקונים ידניים במשמרת — 34 מול 2, זמן סגירת פעולה שנויה במחלוקת — שעות מול 10 דקות. עומס שיא של בקשות גדל פי שלושה — תורים וזיכויים חוזרים לא הופיעו.

במה אימות לפי מסמכים שונה מאימות התנהגותי?

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

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

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

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

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

שאלות טכניות נפוצות על רישום פעולות ובדיקות

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

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

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

אפשר לחבר בדיקת לקוח חיצונית?

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

איך עוברת בדיקת קבלה לפני ההשקה?

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

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

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

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

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