ბლექლისტები და ბლოკის ფურცლები გადახდის ლოგიკაში

TL; DR

Blacklist/ბლოკის სია არის „მკაცრი“ და „რბილი“ აკრძალვების კონტროლირებადი ფენა გადახდის დალაგებაში. მისი ღირებულებაა განზრახ სარისკო იდენტიფიკატორების (რუქა, IBAN, კრიპტო მისამართები, მოწყობილობა, IP და ა.შ.) სწრაფი მოწევა ძვირადღირებული შემოწმებებისა და ჩამოწერის მცდელობებამდე. ეფექტურობის გასაღებია მონაცემთა მკაფიო მოდელი (მოქმედების დრო, წყარო, მიზეზი, იურისდიქცია, ნდობის დონე), იზოლირებული სერვისი ძლიერი ქეშით და აუდიტით, შეთანხმებული TTL/ამნისტიის პოლიტიკოსები, ასევე მეტრიკა „hit-rate-overblock“.

1) ტერმინები და განსხვავებები

Blacklist/Deny-list/ბლოკის სია არის იდენტიფიკატორთა ნაკრები, რომელთანაც ემთხვევა ოპერაცია მკაცრად გადახრილია (HARD BLOCK).
Stop-list (კონტექსტური) - დაბლოკვა კონკრეტულ კონტექსტში (მაგალითად, მხოლოდ დასკვნებზე, მხოლოდ X ქვეყანაში, მხოლოდ თანხისთვის> - Y).
Watchlist/Greylist - „დაკვირვება“: ოპერაცია დაუყოვნებლივ არ არის გადახრილი, მაგრამ გადადის STEP-UP (3DS/OTP/dop KYC) ან სახელმძღვანელო მიმოხილვა.
Allow-list/White-list არის აშკარა რეზოლუცია, რომელიც აღემატება ნაცრისფერ სიგნალებს (მაგალითად, VIP, დადასტურებული ბანკის ანგარიში).
Negative List (შინაგანი) - შინაგანი ინციდენტების საფუძველზე (charjbacks, bonus abuse, სანქციების დამთხვევები, მულტიკონტინგი).

2) რა არის „ფოთოლი“: იდენტიფიკატორები

გადახდის დეტალები

რუკა: PAN-token/FPAN-hash, BIN, ემიტენტი/ქვეყანა (გეო-პოლიტიკოსისთვის), ვადა, გადამზიდავის სახელი (სურვილისამებრ, Hash/faxi).
საბანკო: IBAN/BIC, ანგარიში/routing (ACH/SEPA), მფლობელის სახელი (ნორმალიზებული ჰაში).
E-wallet/fintech: საფულე (PayPal/Skrill/Neteller და ა.შ.), UPI/PIX ID, Open-Banking PISP გადამხდელი.
კრიპტო: მისამართები L1/L2, ეტიკეტები (mixer/სანქციები/მაღალი რისკი), ჯაჭვი (ETH/BTC/TON და ა.შ.).

საკომუნიკაციო და ქცევითი

Email/ტელეფონი (ნორმალიზაციით, „ერთჯერადი“ დომენების აღრიცხვა და გადანაწილებული ნომრები).
მოწყობილობა/ბრაუზერი-fingerprint, კლიენტის გასაღები, მობილური-ID.
ქსელის: IP (ASN/მარიონეტული/VPN/მონაცემთა ცენტრი) ,/24 ქვესახეობა, გეო-ლოკაცია.

ანგარიში და კონტრაგენტი

UserID/CustomerID, პარტნიორი/აფილიატი, პრომო წყარო.
PSP/MID/Acquirer (მარშრუტების ოპერაციული საკეტებისთვის).
მისამართი/FIO (ჰაშის ნორმალიზაცია, fuzzy-matching ნიშნები).

3) სიების შევსების წყაროები

შინაგანი მოვლენები: Charjebeki, frode alerts, bonus abuse (მულტიკულტურა, მორიელი „აიღო პრემია - გამოიტანა ბრუნვის გარეშე“), სანქციების დამთხვევები, სელფ-ექსკლუზიური/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"
}
}

სავალდებულო ველები: 'key', 'policy', 'reason _ code', 'წყარო', 'created _ at', 'expiry _ at/tl'.
კარგი პრაქტიკა: შეინახეთ სკოპი (მოქმედება/იურისდიქცია/პროდუქტი) და კონფიგურაცია (რბილი პოლიტიკოსისთვის).

5) სიების მომსახურების არქიტექტურა

გამოყოფილი ListService სერვისი („ჭეშმარიტების“ სტატუსი ყველა მიკრო მომსახურებისთვის).

• `GET /v1/list/check? key =... & ctx =... '- სინქრონული შემოწმება (p99 <5-10 ms Redis- დან).
• 'POST/v1/list/upsert' არის მასიური/ერთჯერადი ჩანაწერი, რომელსაც აქვს ვალიდაცია და აუდიტი.
• 'POST/v1/list/bulk' - CSV/NDJSON დატვირთვა dry-run- ით.
• 'POST/v1/list/მიმოხილვა/: id' - მარკირება/ამნისტია/გახანგრძლივება.
• საცავი: Redis (ცხელი ქეში, TTL) + Postgres (ისტორია/აუდიტი) + DLQ/ლოგის ავტობუსი (Kafka) ღონისძიებისა და რეპლიკაციისთვის.
• წვდომა: write - მხოლოდ რისკი/შესაბამისობა/MLRO RBAC + 4 - თვალის კონტროლი მგრძნობიარე გასაღებებზე (საბანკო/კრიპტო).
• საიმედოობა: idempotent upsert, ჩანაწერების ვერსია, ღონისძიების კონვეიერში ექსაქტიური - once, KMS/HSM დაშიფვრა.

6) სად შევადგინოთ შემოწმებები

1. გადახდის საშუალების რეგისტრაცია/დაკავშირება - ადრეული დენი „დამწვარი“ დეტალებისთვის.
2. ანაბარი (ინიციაცია) - სწრაფი Deny/Stop 3DS/OTP- მდე, რათა არ გადაიხადოს აშკარად ცუდი კლავიშები ავტორიზაციისთვის.
3. დასკვნა/გადახდა - ინდივიდუალური სიები payout დეტალებისთვის (IBAN/კრიპტო მისამართი); ხშირად უფრო მკაცრია ვიდრე შესასვლელი.
4. დეტალების ცვლილება - step-up + check; დაცვა „ანგარიშის შეცვლისგან დასკვნამდე“.
5. ბონუსის ოპერაციები - observe/stop აბიუზის სქემების მიხედვით (მულტიკულტურა, მოწყობილობების ჯაჭვები).

7) პოლიტიკა (HARD/SOFT) და TTL

გამოიყენეთ HARD (deny/stop): სანქციები, დადასტურებული frod, განმეორებითი charjbacks, მოპარული ბარათები, mulls.
SOFT (ofserve/step-up): სუსტი სიგნალები (ახალი IP/მოწყობილობა, „ცივი“ ელექტრონული ფოსტის დომენი, მაღალი დონის), „საეჭვო“ BIN/ASN.

• ჩარჟბეკი: 180-540 დღე (დამოკიდებულია სქემებზე და რისკზე).
• ბონუს აბიუსი: 90-365 დღე (გადასინჯვით).
• სანქციები: შეუზღუდავია სიების პერიოდული სინქრონიზაციით.
• ამნისტია: „სუფთა“ თამაშის წარმატებული CCC/ისტორიის შემდეგ, N დღე და ინციდენტების გარეშე - ავტომატური ვარდნა observe ან მოხსნა.

8) გადაწყვეტილებები და ესკალაცია (Decision Matrix)

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, შემდეგ - Scoring/ML/წესები.
შეკვეთა pline: 'Pre-aut-ListService (hard/soft) - 3DS/OTP - Auth - Clearing'.
მარშრუტიზაცია: PSP როუტინგის დონეზე, თქვენ შეგიძლიათ "გადატვირთოთ" არხები/აკვაერები, თუ 'MID '/' BIN "მოხვდება პროვაიდერების ბლოკირების სიებში.
მოვლენები: თითოეული გამოსავალი ('DENY/STOP/OBSERVE/ALLOW') მიდის Kafka- ში ML- ის აუდიტის და გადამზადების მიზნით.

11) ოპერაციები და პროცესები

მასობრივი დატვირთვები: CSV/NDJSON სავალდებულო და სიმულაციით (რამდენი ოპერაცია იმოქმედებს).
Review: ყოველდღიური ნიმუში გახანგრძლივების/მოხსნისთვის; SLA საქმეების დამუშავებისთვის.
კონფლიქტები: თუ ერთდროულად „ALLOW“ და „DENY“, გამოიყენეთ საშუალო რეაგირების წესი, გარდა აშკარა VIP-override.
ვერსია: ნებისმიერი რედაქტირება - ჩაწერის ახალი ვერსია; ძველი მდგომარეობა გამოძიებისთვის ინახება.
ინციდენტები: reason _ code შაბლონები, კომუნიკაცია თიკეტებთან (Jira/Case-ID).

12) თვისებებისა და მიზნების მეტრიკა

Hit Rate (HR) = ოპერაციების წილი ნებისმიერ სიაში.
Hard-Hit Rate (HHR) = მკაცრად დაბლოკილი წილი.
Overblock Rate (OBR) = „ყალბი“ ბლოკირების წილი (შემდგომში მოქმედი გადამხდელი).
დანერგვის შემდეგ CB-Uplift/Fraud-Loss ხდება.
Approval Rate (AR) დეპოზიტებზე/დასკვნებზე.
Time-to-Wallet (TTW) გავლენას ახდენს რბილი ზომების (ნაბიჯი) გადახდის სიჩქარეზე.
ონლაინ შემოწმების დრო (p95/p99).

13) იურიდიული და კონფიდენციალურობა

დამუშავების საფუძველი: ლეგიტიმური ინტერესი/იურიდიული მოვალეობა (AML/სანქციები/ფროიდის პრევენცია).
მინიმიზაცია: შეინახეთ ჰაში/ნიშნები პირველადი მონაცემების ნაცვლად (PAN/IBAN), ჩვენ ვატარებთ, ვაკონტროლებთ წვდომას.
შენახვის ვადა: TTL + ზოგადი რეაგირების პოლიტიკა (AML/ბუღალტრული აღრიცხვა/რეგულირება).
სუბიექტების უფლებები: DSAR/მოცილების პროცესი (შესაბამისობის გამონაკლისების გათვალისწინებით).
ტრანსსასაზღვრო: რეპლიკაციის მკაფიო საზღვრები რეგიონებს/ტენანტებს შორის.

14) ხშირი შეცდომები და როგორ მოვერიდოთ მათ

Overblock IP/ASN: მონაცემთა ცენტრები/CGNAT - გამოიყენეთ სიგნალების ერთობლიობა (IP + მოწყობილობა + ქცევა).
პერსონალური მონაცემების შერწყმა: ელექტრონული ფოსტის/ტელეფონის ნორმალიზება, გაითვალისწინეთ ნომრების გადამოწმება.
რუქების რეცირკულაცია (PAN რემისია): მიბმული PAN ნიშნით/კრიპტო-ტოკენიზაციით და არა „ნედლეული“ მონაცემებით.
ზოგადი IBAN შინამეურნეობები: გამოიყენეთ scope (მხოლოდ payouts) და observe გლობალური დენის ნაცვლად.
კრიპტო მისამართები: არ დაბლოკოთ ყველაფერი ზედიზედ; გაითვალისწინეთ ნიშნები/კონტექსტი (გაცვლა, კასტიური საფულეები).

15) კომუნიკაცია ბონუს აბუზთან და ლიმიტებთან

ბონუს ნიმუშები: ერთი საფულე/მისამართი - მრავალი ანგარიში, სწრაფი გაყვანა ბრუნვის გარეშე - stop/deny- ზე payouts- ზე.
ლიმიტები და TtW: „observe“ შეიძლება მოითხოვდეს გაზრდილი ბრუნვა/წაგრძელებული 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. განსაზღვრეთ policy set: deny/stop/observe/allow + reason _ codes.
2. მონაცემთა სქემა: გასაღებები, სკოპი, ttl/expiry, კონფერენცია, აუდიტი.
3. არქიტექტურა: Redis + PG + Kafka, idempotence, 4 - თვალის კონტროლი.
4. მშენებლობა ნაკადში: pre-aut შემოწმება, step-up, payout-hardening.
5. მეტრიკი/დაშბორდი: HR/HHR/OBR/AR/TTW, ჭრილობები იურისდიქციებით/არხებით.
6. პროცესები: რევიუმი/ამნისტია, მასობრივი დატვირთვა, DSAR, ინციდენტები.
7. გუნდების ტრენინგი: saport/რისკი/ფინანსები, კონფლიქტის მოგვარების ფლეიბუკები.

18) მინი ფლეიბუკები

• დეტალების ჩანაცვლება stop (withdrawal) + KYC-step-up + benitiar- ის გადამოწმებამდე.
• კონსორციუმის საფულის ჰიტი - observe დეპოზიტებისთვის, stop payouts- ზე MLRO- მდე.
• ქვეყნის მასშტაბით Y სანქციების ახალი ამბების განახლება, დენის ჩართვა და სიების დათვლა.

19) ადმინ პანელის ინტერფეისის მაგალითი (ლოგიკა)

ძებნა კლავიშზე/ნიღბზე, ფილტრები: პოლიტიკა, სკოპი, რეასონი, წყარო, ეგზიპირი <30d.
Кнопки: Amnesty, Extend TTL, Lower to Observe, Convert to Deny, Add Allow.
მასობრივი მოქმედებები dry-run- ით: აჩვენეთ რამდენი ოპერაცია დაექვემდებარება ახალ წესებს.

20) რეზიუმე

ბლოკის ფურცლები არ არის მხოლოდ „აკრძალვების ცხრილი“, არამედ პლატფორმის დონის მომსახურება: მკაფიო მონაცემთა მოდელი, ძლიერი ქეში, აუდიტი, კომპეტენტური TTL და მკაფიო შურისძიების პროცესები. რისკის ძრავასთან სათანადო ინტეგრაციით, ისინი შეამცირებენ ფროიდის ძაბვას კონვერტაციის განადგურების გარეშე და დააჩქარებენ გადახდებს, სადაც ეს უსაფრთხოა.