Blacklists and block lists in payment logic

TL; DR

A blacklist/block list is a manageable layer of "hard" and "soft" prohibitions in a payment pipeline. Its value is the quick pruning of obviously risky identifiers (cards, IBAN, crypto addresses, devices, IP, etc.) to expensive checks and write-off attempts. The key to efficiency is a clear data model (validity period, source, reason, jurisdiction, level of confidence), an isolated service with a strong cache and audit, consistent TTL/amnesty policies, and hit-rate ↔ overblock metrics.

1) Terms and differences

Blacklist/Deny-list/Block list - a set of identifiers, if coincided with which the operation is hard rejected (HARD BLOCK).
Stop-list (context) - blocking in a specific context (for example, only for conclusions, only in country X, only for the amount> € Y).
Watchlist/Greylist - "observation": the operation is not rejected immediately, but translated into STEP-UP (3DS/OTP/add. KYC) or Manual Review.
Allow-list/White-list - explicit permission that outweighs gray signals (for example, VIP, confirmed bank account).
Negative List (internal) - a list based on internal incidents (chargebacks, bonus abuse, sanctions matches, multiaccounting).

💡 Recommendation: in terms of the platform, use Deny (hard), Stop (scoped hard), Observe (soft), Allow (override).

2) What exactly "leaf": identifiers

Payment details

Card: PAN token/FPAN hash, BIN, issuer/country (for geo-policies), term, media name (optional, hash/fuzzy).
Bank: IBAN/BIC, account/routing (ACH/SEPA), owner name (normalized hash).
E-wallet/fintech: wallet (PayPal/Skrill/Neteller, etc.), UPI/PIX ID, Open-Banking PISP payer.
Crypto: L1/L2 addresses, tags (mixer/sanctions/high-risk), chain (ETH/BTC/TON, etc.).

Communication and behavioral

Email/phone (with normalization, accounting for "one-time" domains and redistributed numbers).
Device/browser fingerprint, client key, mobile-ID.
Network: IP (ASN/proxy/VPN/data center) ,/24-subnets, geo-location.

Account and counterparty

UserID/CustomerID, partner/affiliate, promotional source.
PSP/MID/Acquirer (for route operational locks).
Address/full name (hash normalization, fuzzy-matching by tokens).

3) Sources of replenishment of lists

Internal events: chargebacks, fraud alerts, bonus abuse (multi-account, scoring "took a bonus - withdrew without turnover"), sanctions matches, self-exclusion/MLRO flags.
External sources: negative lists of PSP/acquirers, consortium bases (shared fraud intel), crypto tag providers, BIN bases, risk models.
Rules and manual entry: compliance/risk office decisions, "freeze" for an incident.

4) Data model (minimum sufficient)

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"
}
}

Required fields are 'key', 'policy', 'reason _ code', 'source', 'created _ at', 'expiry _ at/ttl'.
Good practice: keep scope (action/jurisdiction/product) and confidence (for soft policies).

5) List service architecture

Dedicated ListService (true status for all microservices).

API:

`GET /v1/list/check? key =... & ctx =... '- synchronous check (p99 <5-10 ms from Redis).
'POST/v1/list/upsert '- mass/single record with validation and audit.
'POST/v1/list/bulk '- loading CSV/NDJSON from dry-run.
'POST/v1/list/review/: id '- markup/amnesty/extension.
Storage: Redis (hot cache, TTL) + Postgres (history/audit) + DLQ/log bus (Kafka) for event-sourcing and replication.
Accesses: write - risk/compliance/MLRO only via RBAC + 4-eye control on sensitive keys (banking/crypto).
Reliability: idempotent upsert, versioning records, exactly-once in the event pipeline, KMS/HSM encryption.

6) Where to embed checks

1. Registration/linking of the means of payment - early Deny for "burned" details.
2. Deposit (initiation) - fast Deny/Stop before 3DS/OTP, so as not to pay for authorization with obviously bad keys.
3. Withdrawal/payment - separate lists for payout details (IBAN/crypto address); often stricter than at the entrance.

4. Change of details - step-up + check; protection against "change of count before withdrawal."

5. Bonus operations - observe/stop according to abuse schemes (multi-account, device chains).

7) Policies (HARD/SOFT) and TTL

HARD (deny/stop) apply when: sanctions, confirmed fraud, repeated chargebacks, stolen cards, mules.
SOFT (observe/step-up) at: weak signals (new IP/device, "cold" e-mail-domain, high-velocity), "dubious" BIN/ASN.

TTL/expiry:

Chargeback: 180-540 days (depending on regimens and risk).
Bonus bonus: 90-365 days (with revision).
Sanctions: indefinitely with periodic synchronization of lists.
Amnesty: after a successful CUS/history of "pure" play ≥ N days and without incidents - automatic demotion to observe or withdrawal.

8) Decision Matrix

Signal	Policy	Action	Example
Exact match of sanctions (name + dob + address)	DENY	Reject, notify MLRO	Withdrawal to IBAN from the sled. countries
Repeated CB by PAN token	STOP(deposit,withdrawal)	Input/output unit, risk case	2 × CB in 45 days
Suspicious IP ASN + new device	OBSERVE	3DS Step-Up / KYC-Tier raise	Deposit €1000 per data center
VIP with confirmed IBAN	ALLOW	Outweighs observe	High limit, clean history

9) Pseudocode of online verification

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) Integration with risk engine and payment bus

The risk engine first reads ListService, then scoring/ML/rules.
Order in the pipeline: 'Pre-auth → ListService (hard/soft) → 3DS/OTP → Auth → Clearing'.
Routing: at the PSP-routing level, you can "zero" channels/aquiers if 'MID '/' BIN' are included in the block lists of providers.
Events: Each solution ('DENY/STOP/OBSERVE/ALLOW') goes to Kafka to audit and further train ML.

11) Operations and Processes

Mass downloads: CSV/NDJSON with validation and simulation (how many operations will be affected).
Review: Daily Extension/Withdrawal Sample; SLA for case processing.
Conflicts: If both'ALLOW 'and'DENY' apply the most-restrictive rule except for explicit VIP override.
Versioning: any edit - new version of the record; the old state is kept for investigations.
Incidents: reason_code templates, connection with tickets (Jira/Case-ID).

12) Quality metrics and goals

Hit Rate (HR) = Percentage of transactions on any list.
Hard-Hit Rate (HHR) = proportion of hard-locked.
Overblock Rate (OBR) = proportion of false locks (subsequent valid payer).
CB- Uplift↓/Fraud- Loss↓ after implementation.
Approval Rate (AR) on deposits/withdrawals.
Time-to-Wallet (TTW) the impact of soft-measures (step-up) on the speed of payments.
Time-to-Decision (p95/p99) for online checks.

💡 Targets: HHR rises without appreciable AR worsening; OBR ≤ acceptable threshold (e.g. <0. 3%); p99 check ≤ 10 ms.

13) Legal and privacy

Basis of processing: legitimate interest/legal obligation (AML/sanctions/fraud prevention).
Minimization: store hashes/tokens instead of primary data (PAN/IBAN), salt, control access.
Retention: TTL + general retention policies (AML/accounting/regulatory).
Rights of subjects: process for DSAR/deletion (taking into account compliance exceptions).
Cross-border: clear replication boundaries between regions/tenants.

14) Frequent mistakes and how to avoid them

Overblock by IP/ASN: data centers/CGNAT → use a combination of signals (IP + device + behavior).
Sticking personal data: normalize e-mail/phone, take into account number recycling.
Card recycling (PAN re-emission): bind by PAN token/crypto tokenization, not raw data.
Household total IBAN: use scope (payouts only) and observe instead of global deny.
Crypto addresses: don't block everything; consider labels/context (exchanges, custodial wallets).

15) Connection with bonus abuse and limits

Bonus patterns: one wallet/address → many accounts, quick output without turnover - in stop/deny on payouts.
Limits and TtW: "observe" may require increased turnover/elongated TtW prior to review.

16) Examples of keys (canonical forms)


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) Checklists (implementation checklist)

1. Define policy set: deny/stop/observe/allow + reason_codes.
2. Data schema: keys, scope, ttl/expiry, confidence, audit.
3. Architecture: Redis + PG + Kafka, idempotency, 4-eye control.
4. Integration into the stream: pre-auth check, step-up, payout-hardening.
5. Metrics/dashboard: HR/HHR/OBR/AR/TTW, cross-sectional by jurisdiction/channel.
6. Processes: Review/Amnesty, Bulk Downloads, DSAR, Incidents.
7. Team training: support/risk/finance, conflict resolution playbooks.

18) Mini playbooks

CB surge on BIN X → temporary stop (deposit) on 'bin: X' + reroute to another acquirer, review after 48 hours.
Change of details before displaying → stop (withdrawal) + KYC-step-up + verification of the fingerprint.
Consortium hit on wallet → observe on deposits, stop on payouts before MLRO review.
Sanctions news for country Y → update country-scope, enable deny on payouts, recalculate lists.

19) Example of admin panel interface (logic)

Key/mask search, filters: policy, scope, reason, source, expiry <30d.
Кнопки: Amnesty, Extend TTL, Lower to Observe, Convert to Deny, Add Allow.
Bulk actions with dry-run: show how many operations will fall under the new rules.

20) Summary

Block lists are not just a "table of prohibitions," but a platform-level service: with a clear data model, strong cache, listening, competent TTL and clear review processes. When properly integrated with the risk engine, they will narrow the fraud funnel without destroying the conversion and speed up payments where it is safe to do so.

Blacklists and block lists in payment logic

TL; DR

Communication and behavioral

Account and counterparty

Get in Touch

Quick Contact

The video will be updated soon

We are currently very busy with projects