אינטגרציה של Elliptic לסינון AML של עסקאות וארנקים

אינטגרציה עם Elliptic: היכן נשבר סינון AML ידני

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

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

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

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

מה משתנה לאחר ההטמעה: מהירות, סיכון, דיווח

שיעור הבדיקות הידניות יורד עד לסף היעד

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

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

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

יומן החלטות סוגר שאלות ביקורת

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

היסטוריית בדיקות העסקאות נשמרת לכל עומק

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

השוואת גישות: בקרה ידנית, מאגר עצמאי, שירות מוכן

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

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

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

איך עוברת האינטגרציה עם Elliptic: שלבי העבודה

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

שלבי הטמעת הסינון

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

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

מה נשאר אצל צוות הלקוח לאחר ההפעלה

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

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

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

מקרה בוחן: הפחתת שיעור הבדיקות הידניות וזמן התגובה

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

מה היה לפני ההטמעה

במשמרת הגיעו 400–600 בקשות לבדיקה, והן הצטברו: אותה כתובת נבדקה שוב אם הופיעה בתשלום אחר. האוטומציה סגרה כ-38% מהמקרים, והשאר נתלו בתור — זמן התגובה הממוצע ללקוח עמד על 6–8 שעות, ובימי שיא הגיע עד יממה.

סוג הסירוב העיקרי לא היה על איסור, אלא על שתיקה: המשתמש ראה "משיכה בטיפול" ולא הבין למה לצפות.

מה שינו ומה זה נתן

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

שיעור ההחלטות האוטומטיות עלה מ-38% ל-91%, זמן התגובה הממוצע בעסקאות שנויות במחלוקת התקצר מ-6–8 שעות ל-12–20 דקות. בדיקות ידניות נעשו פי ארבעה פחות, ופניות לתמיכה בנושא "איפה המשיכה שלי" — פי שלושה פחות. אפקט נפרד — נעלם סוג הסירובים בהפתעה: הלקוח מקבל סיבה וקישור להחלטה, ולא עיכוב שקט.

במה שונה חסימת כתובת מהורדת ציון סיכון

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

ב-Elliptic ובמקורות סקורינג דומים הכתובת מקבלת הערכה מספרית לפי מכלול מאפיינים: קרבה למיקסרים, קשר לרשימות סנקציות, מספר "הידיים" ממקור הכספים.

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

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

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

ספקות טכניים לפני חיבור הסינון

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

מה נחשב סיכון חלקי של כתובת?

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

אילו נתוני לקוחות יוצאים החוצה?

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

מי אחראי להתראות שווא?

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

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

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

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

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