רשימות שחורות ורשימות בלוקים בהיגיון התשלומים

TL; DR

רשימה שחורה/רשימת בלוקים היא שכבה הניתנת לניהול של איסורים ”קשים” ו ”רכים” בצינור תשלום. הערך שלו הוא הגיזום המהיר של מזהים מסוכנים (כרטיסים, IBAN, כתובות קריפטו, התקנים, IP וכו ') לבדיקות יקרות וניסיונות למחיקה. המפתח ליעילות הוא מודל נתונים ברור (תקופת תוקף, מקור, סיבה, סמכות שיפוטית, רמת ביטחון), שירות מבודד עם מטמון חזק וביקורת חשבונות, מדיניות TTL/אמנסטי עקבית וקצב פגיעה ↔ מדדי יתר.

1) תנאים והבדלים

רשימת Blacklist/Deserve-List/Block List - רשימה של מזהים, אם במקביל לה הפעולה נדחית קשות (HARD Block).
Stop-list (הקשר) - חסימה בהקשר מסוים (לדוגמה, רק עבור מסקנות, רק במדינה X, רק עבור הסכום> אירו Y).
Watchlist/Greylist - ”תצפית”: הפעולה אינה נדחית באופן מיידי, אלא מתורגמת ל ־ STEP-UP (3DS/OTP/add. KYC) או סקירה ידנית.
הרשו רשימה/רשימה-לבנה - אישור מפורש העולה על אותות אפורים (לדוגמה, VIP, אישור חשבון בנק).
רשימה שלילית (Internal) - רשימה המבוססת על מקרים פנימיים (chargebacks, bonus uply, סנקציות תואמות, רב-מספור).

💡 המלצה: במונחים של הפלטפורמה, השתמש מכחיש (קשה), עצור (נסקור חזק), התבונן (רך), הרשה (לעקוף).

2) איזה ”עלה” בדיוק: מזהים

פרטי תשלום

כרטיס: PAN token/FPAN hash, BIN, issuer/country (לגיאו-פוליסה), מונח, שם מדיה (אופציונלי, חשיש/פאזי).
בנק: IBAN/BIC, חשבון/ניתוב (ACH/SEPA), שם הבעלים (חשיש מנורמל).
ארנק (PayPal/Skril/Neteller, וכו '), UPI/PIX ID, Pop-Banking PISP Payer.
קריפטו: L1/L2 כתובות, תגיות (מיקסר/סנקציות/סיכון גבוה), שרשרת (ETH/BTC/TON וכו ').

תקשורת והתנהגות

דוא "ל/טלפון (עם נורמליזציה, חשבונאות לתחום" חד פעמי "ומספרים מחולקים מחדש).
טביעת אצבע של מכשיר/דפדפן, מפתח לקוח, זיהוי נייד.
רשת: IP (ASN/proxy/VPN/data center) ,/24-subnets, geo-location.

חשבון ומקביל

תעודה מזהה, שותפה/שותפה, מקור קידום.
PSP/Mid/Acquirer (עבור מנעולים מבצעיים).
כתובת/שם מלא (נורמליזציה של חשיש, התאמה מעורפלת של אסימונים).

3) מקורות לחידוש הרשימות

אירועים פנימיים: מטענים, התראות הונאה, ניצול בונוס (ריבוי חשבונות, ניקוד ”לקח בונוס - נסוג ללא תחלופה”), התאמות סנקציות, הדרה עצמית/דגלי MLRO.
מקורות חיצוניים: רשימות שליליות של PSP/רוכשים, בסיסי קונסורציום (אינטל הונאה משותפת), ספקי תגי קריפטו, בסיסי BIN, מודלי סיכון.
כללים וכניסה ידנית: ציות/סיכונים החלטות משרד, ”להקפיא” לתקרית.

4) מודל נתונים (מספיק מינימלי)

json
{
"key": "card:pan_token:9c4f...e1",
"scope": {
"action": ["deposit","withdrawal","payout"],
"jurisdiction": ["EEA","CA-ON"],
"product": ["casino","sports"]
},
"policy": "deny    stop    observe    allow",
"reason_code": "CHARGEBACK    BONUS_ABUSE    SANCTION_MATCH    MFA_BYPASS    KYC_FAIL    CONSORTIUM_HIT",
"source": "risk_engine    psp_x    mlro    consortium",
"confidence": 0. 92,
"created_at": "2025-10-01T12:30:00Z",
"expiry_at": "2026-01-01T00:00:00Z",
"ttl_days": 90,
"review_after": "2025-12-01T00:00:00Z",
"metadata": {
"case_id": "INC-2025-10344",
"notes": "2 CB in 45 days; bonus cycling through 3 wallets,"
"hash_algorithm": "sha256+salt",
"tenant": "brand_A"
}
}

שדות נדרשים הם "מפתח", "מדיניות", "סיבה _ קוד", "מקור", "נוצר _ at", "experience _ at/tl'.
תרגול טוב: לשמור על היקף (פעולה/סמכות שיפוט/מוצר) וביטחון עצמי (למדיניות רכה).

5) ארכיטקטורת שירות רשימה

Listservice (מעמד אמיתי לכל המיקרו-רווחים).

API:

'קבל/v1/רשימה/לבדוק? מפתח = & ctx =... צ 'ק סינכרוני (p99 <5-10 ms מרדיס).
'POST/v1/list/upsart' - תקליט המוני/יחיד עם אימות וביקורת.
'POST/v1/list/balk' - טעינת CSV/NDJSON מהריצה היבשה.
'POST/V1/list/Review/id' - סימון/אמנסטי/סיומת.
אחסון: Redis (מטמון חם, TTL) + Postgres (היסטוריה/ביקורת) + DLQ/log bus (קפקא) עבור מיקור אירועים ושכפול.
גישה: כתיבה - סיכון/היענות/MLRO רק באמצעות RBAC + 4-eye control על מפתחות רגישים (בנקאי/קריפטו).
אמינות: אידמפוטנט למעלה, רשומות ורסיונינג, בדיוק-פעם אחת בצינור האירוע, הצפנת KMS/HSM.

6) היכן להטמיע צ 'קים

1. רישום/קישור של אמצעי התשלום - מכחיש מוקדם לפרטים ”נשרפו”.
2. הפקדה (חניכה) - מהר דחייה/עצור לפני 3DS/OTP, כדי לא לשלם עבור אישור עם מפתחות ללא ספק רעים.
3. משיכה/תשלום - רשימות נפרדות עבור פרטי תשלום (כתובת IBAN/קריפטו); לעתים קרובות יותר מחמיר מאשר בכניסה.
4. שינוי בפרטים - שלב למעלה + בדוק; הגנה מפני ”שינוי הספירה לפני הנסיגה”.
5. פעולות בונוס - התבוננות/עצירה בהתאם לתוכניות שימוש לרעה (רב-חשבון, רשתות התקנים).

7) מדיניות (קשה/רך) ו ־ TTL

סנקציות, הונאה מאושרת, תיקים חוזרים ונשנים, כרטיסים גנובים, פרדות.
אותות חלשים (IP/מכשיר חדש, ”קור” דואר אלקטרוני, מהירות גבוהה), ”מפוקפק” BIN/ASN.

TTL/פקיעה:

צ 'רג' בק: 180-540 ימים (תלוי במשטרים ובסיכון).
בונוס: 90-365 ימים (עם תיקון).
סנקציות: ללא הגבלת זמן עם סינכרון תקופתי של רשימות.
אמנסטי: לאחר היסטוריה מוצלחת של מחזה ”טהור” (CUS/True play) ימים ללא אירועים - הורדה אוטומטית לצפייה או נסיגה.

8) מטריצת החלטות

אות	מדיניות	פעולה	דוגמה
התאמה מדויקת של סנקציות (שם + דוב + כתובת)	להכחיש	לדחות, להודיע MLRO	נסיגה לאיי-באן מהמזחלת. מדינות
CB חוזר על ידי אסימון PAN	עצור (הפקדה, משיכה)	יחידת קלט/פלט, מקרה סיכון	2 × CB ב-45 ימים
IP ASN + התקן חדש חשוד	התבוננות	העלאה של 3DS סטפ-אפ/KYC-Tier	הפקדת 1000 אירו למרכז הנתונים
אח "מים עם איבן מאושר	הרשה	”עולים על המשקל”	גבול גבוה, היסטוריה נקייה

9) פסאודוקודה של אימות מקוון

python def is_blocked(keys: list[str], ctx: dict) -> Decision:
keys: ["card:pan_token:..", "ip:..", "device:..", "iban:.."]
ctx: {"action":"withdrawal","jurisdiction":"EEA","product":"casino","amount":1000}
hits = list_service. batch_check(keys, ctx) # из Redis + fallback PG if any(h. policy in ["deny","stop"] for h in hits if h. in_scope(ctx)):
return Decision(block=True, reason=top_reason(hits))
if any(h. policy == "observe" for h in hits if h. in_scope(ctx)):
return Decision(block=False, step_up="3DS_or_KYC", reason="OBS_HIT")
return Decision(block=False)

10) אינטגרציה עם מנוע סיכון ואוטובוס תשלומים

מנוע הסיכון קורא תחילה Listservice, ולאחר מכן ניקוד/ML/כללים.
סדר בצינור: ”Pree-auth # Listservice (hard/soft) # 3DS/OTP Auth * Slearing”.
ניתוב: ברמת הניתוב של PSP, אתה יכול ”אפס” ערוצים/אקווירים אם ”אמצע ”/” BIN” כלולים ברשימת הבלוקים של הספקים.
אירועים: כל פתרון (”Delief/Stop/Observe/ALLOW”) עובר לקפקא כדי לערוך ביקורת ולאמן את ML.

11) פעולות ותהליכים

הורדות המוניות: CSV/NDJSON עם אימות וסימולציה (כמה פעולות יושפעו).
סקירה: Daily Extension/Regress Section; SLA לעיבוד מקרה.
קונפליקטים: אם הן 'אללו' והן 'מכחישים' את החוק המגביל ביותר מלבד עקיפה מפורשת של אח "מים.
ורסיונינג: כל עריכה - גרסה חדשה של התקליט; המדינה הישנה נשמרת לחקירות.
תקריות: תבניות reason_code, חיבור לכרטיסים (Jira/Case-ID).

12) מדדים איכותיים ומטרות

שיעור הלהיט (HR) = אחוז העסקאות בכל רשימה.
קצב פגיעה קשה (HHR) = פרופורציה של קשיחות נעולה.
Overblock Rate (OBR) = פרופורציה של מנעולים שגויים (לאחר מכן payer תקף).
CB- Uplift/Fraud- הפסד לאחר יישום.
שיעור אישור (AR) על הפקדות/משיכות.
Time-to-Wallet (TTW) ההשפעה של אמצעים רכים (step-up) על מהירות התשלומים.
זמן להחלטה (p95/p99) לבדיקות מקוונות.

💡 מטרות: HHR עולה ללא הערכה AR מחמיר; OBR סימנה את הסף המקובל (למשל. <0. 3%); בדיקת p99 10 ms.

13) חוקיות ופרטיות

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

14) טעויות תכופות וכיצד להימנע מהן

בלוק יתר על ידי IP/ASN: מרכזי נתונים/CGNAT * משתמשים בשילוב של אותות (IP + התקן + התנהגות).
דבק נתונים אישיים: לנרמל דואר אלקטרוני/טלפון, לקחת בחשבון מיחזור מספר.
מיחזור קלפים (PAN re-pission): נקשר על ידי PAN token/crypto tokenization, לא מידע גולמי.
משק בית כולל IBAN: השתמש בהיקף (תשלומים בלבד) וצפה במקום בהכחשה גלובלית.
כתובות מוצפנות: לא לחסום הכל; שקול תוויות/הקשר (החלפות, ארנקים משמורת).

15) קשר עם בונוס שימוש לרעה ומגבלות

דפוסי בונוס: ארנק אחד/כתובת = חשבונות רבים, תפוקה מהירה ללא תחלופה - בעצירה/דחייה בתשלומים.
Limits and TTW: ”התבוננות” עשויה לדרוש תחלופה מוגברת/מוארכת של TTW לפני הסקירה.

16) דוגמאות של מפתחות (צורות קנוניות)


card:pan_token:<sha256>
iban:<sha256>
wallet:skrill:<normalized_id_hash>
upi:<vpa_hash>
pix:<pix_key_hash>
crypto:eth:<address_lower>
email:<local+domain_hash>
phone:+<E164_hash>
device:<fp_hash>
ip:<ipv4/6 or /24>
asn:<asn_id>
affiliate:<id>
psp:mid:<id>

17) רשימות בדיקה (רשימת יישומים)

1. הגדר מדיניות: הכחיש/עצור/התבונן/הרשה + reason_codes.
2. סכימת נתונים: מפתחות, היקף, tl/פקיעה, ביטחון עצמי, ביקורת.
3. ארכיטקטורה: Redis + PG + Kafka, idempotency, 4-eye control.
4. אינטגרציה לתוך הזרם: בדיקת קדם-אוטומטית, עליית מדרגה, התקשות בתשלום.
5. Metrics/Dashboard: HR/HHR/OBR/AR/TTW, חוצה-חתך על ידי תחום שיפוט/ערוץ.
6. תהליכים: סקירה/אמנסטי, Bulk Downloads, DSAR, תקריות.
7. הכשרה קבוצתית: תמיכה/סיכון/מימון, ספרי משחק לפתרון סכסוכים.

18) ספרי משחק קטנים

נחשול CB על BIN X # עצירה זמנית (הפקדה) על ”bin: X” + ניתוב מחדש לרוכש אחר, סקירה לאחר 48 שעות.
שינוי פרטים לפני הצגת העצירה (region) + KYC-step-up + אימות טביעת האצבע.
Consortium פגע בארנק פי לצפות על הפקדות, לעצור על תשלום לפני בדיקת MLRO.
סנקציות חדשות למדינה Y # עדכון מדינה-היקף, לאפשר הכחשה בתשלומים, לחשב רשימות מחדש.

19) דוגמה לממשק לוח ניהול (לוגיקה)

חיפוש מפתח/מסכה, מסננים: מדיניות, היקף, סיבה, מקור, פקיעת <30d.
אמנסטי, Extreme TTL, Lower to Observe, Convert to Design, Over Low.
פעולות גדולות עם יבש לרוץ: להראות כמה מבצעים ייפלו תחת הכללים החדשים.

20) סיכום

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

רשימות שחורות ורשימות בלוקים בהיגיון התשלומים

TL; DR

תקשורת והתנהגות

חשבון ומקביל

צרו קשר

חיבור מהיר

הווידאו יעודכן בקרוב

אנחנו עמוסים מאוד בפרויקטים כרגע