Blacklists e folhas em lógica de pagamento
TL; DR
O blacklist/lista é uma camada controlada de proibições «rígidas» e «suaves» na pipline de pagamento. Seu valor é o corte rápido de identificadores de risco (cartão, IBAN, endereço cripto, dispositivo, IP etc.) para verificações de custo e tentativas de cancelamento. A chave para a eficiência é um modelo de dados claro (data de duração, origem, causa, jurisdição, nível de confiança), um serviço isolado com forte dinheiro e áudio, políticas concordantes TTL/amnistia, bem como as métricas «hit-rate ↔ overblock».
1) Termos e diferenças
O Blacklist/Deny-list/Lista de blocos é um conjunto de identificadores com os quais a operação é severamente rejeitada (HARD BLOCK).
Stop-list (contextual) - Bloqueio em um contexto específico (por exemplo, apenas para conclusões, apenas no país X, somente para o valor> € Y).
Watchlist/Greylist - «observação»: a operação não é rejeitada imediatamente, mas é traduzida para STEP-UP (3DS/OTP/suprimento. KYC) ou Manual Review.
Allow-list/White-list é uma resolução clara que ultrapassa os sinais cinzentos (por exemplo, VIP, banco confirmado).
Lista de Negative (interna) - uma lista baseada em incidentes internos (charjbacks, bónus-abws, correspondências de sanções, multicaunts).
2) O que exatamente «listamos»: identificadores
Adereços de pagamento
Mapa de PAN-token/FPAN-hash, BIN, emissor/país (para geo-políticas), prazo, nome do hospedeiro (opcional, hash/phaszi).
Banco: BAN/BIC, conta/roting (ACH/SEPA), nome do proprietário (hash normalizado).
E-wallet/fintech: carteira (PayPal/Skrill/Neteller etc.), UPI/PIX ID, Open-Banking PISP pagador.
Kripto: endereços L1/L2, marcas (mixer/sanções/alto risco), cadeia (ETH/BTC/TON etc.).
Comunicação e Comportamento
Email/telefone (com normalização, registro de domínios «descartáveis» e números redistribuíveis).
Dispositivo/navegador fingerprint, chave de cliente, móvel-ID.
Rede: IP (ASN/proxy/VPN/Data Center) ,/24-Subrede, geo-local.
Contas e Contábeis
UserID/CustomerID, sócio/afiliada, fonte promocional.
PSP/MID/Aquirer (para bloqueios operacionais sobre rotas).
Endereço/FIO (hesh normalização, fuzzy-matching por tóquio).
3) Fontes de reposição de listas
Eventos internos: charjbacks, frod-alerts, bónus-abuse (multicaunt, screen «levou o bónus - tirou sem circulação»), correspondências de sanções, self-exclusion/bandeiras MLRO.
Fontes externas: páginas negativas PSP/Equeiros, bases de consórcios (shared fraud intel), provedores de rótulos criptos, base de dados BIN, modelos de risco.
Regras e entrada manual: soluções de complacência/escritório de risco, «freeze» para o incidente.
4) Modelo de dados (mínimo suficiente)
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"
}
}Os campos obrigatórios são 'key', 'policy', 'reason _ código', 'fonte', 'created _ at', 'expedy _ at/ttl'.
Boa prática: armazenar scope (ação/jurisdição/produto) e confidence (para políticas suaves).
5) Arquitetura de serviço de listas
Serviço de ListService selecionado (status de verdade para todos os microsserviços).
API:- `GET /v1/list/check? key =... & ctx =... '- Verificação sincronizada (p99 <5-10 ms do Redis).
- 'POST/v1/lista/upsert' é uma gravação em massa/única com validação e áudio.
- 'POST/v1/lista/bulk' - download CSV/NDJSON com dry-run.
- 'POST/v1/folha/review/id' - sinalização/amnistia/extensão.
- Armazenamento: Redis (dinheiro quente, TTL) + Postgres (histórico/auditoria) + DLQ/pneu logístico (Kafka) para event-surcing e replicação.
- Acessíveis: write - apenas risco/complacência/MLRO através do controle RBAC + 4 olhos para chaves sensíveis (banco/cripto).
- Confiabilidade: upsert idumpotentes, versionização de registros, exactly-once na linha de montagem de eventos, criptografia KMS/HSM.
6) Onde incorporar verificações
1. Registro/vinculação de meios de pagamento - Deny precoce para adereços «queimados».
2. Depósito (iniciação) - rápido Deny/Stop até 3DS/OTP para não pagar a permissão por chaves claramente ruins.
3. Conclusão/pagamento - listas individuais para os adereços payout (IBAN/cripto-endereço); muitas vezes mais rigoroso do que entrar.
4. Alteração de adereços - step-up + check-up; proteção contra «mudança de conta antes da retirada».
5. As operações de bónus são observo/stop sobre os esquemas de abyuz (multiaccount, cadeias de dispositivos).
7) Políticas (HARD/SOFT) e TTL
HARD (deny/stop) aplicar em: sanções, frod confirmado, charjbacks repetidos, cartões roubados, mulas.
SOFT (observe/step-up) com: sinais fracos (novo IP/dispositivo, domínio e-mail «frio», high-velocity), «duvidoso» BIN/ASN.
- Charjback: 180-540 dias (dependendo dos circuitos e riscos).
- Bónus-abuse: 90-365 dias (revisto).
- Sanções por tempo indeterminado com sincronização periódica das listas.
- Amnistia: após o sucesso do CUS/história do jogo «limpo» ≥ N dias e sem incidentes - rebaixamento automático para observa ou retirada.
8) Soluções e escalações (Decision Matrix)
9) Pseudocode de verificação online
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) Integração com o motor de risco e o pneu de pagamento
O motor de risco lê primeiro o ListService, depois o mapeamento/ML/regras.
Ordem em Pipeline: 'Pré-auth → ListService (hard/soft) → 3DS/OTP → Auth → Clearing'.
Routing: No nível de routing PSP, você pode «desfazer» os canais/aquíferos se 'MID '/' BIN' estiver incluído nas folhas dos provedores.
Eventos: Cada solução ('DENY/STOP/OBSERVE/ALLOW') vai para Kafka para auditar e concluir ML.
11) Operações e processos
Downloads em massa: CSV/NDJSON com validação e simulação (quantas operações serão afetadas).
Revezamento: amostra diária para extensão/retirada; SLA para processamento de malas.
Conflitos: Se "ALLOW" e "DENY" ao mesmo tempo, aplique a regra de "se", além de "VIP-override explícito.
Versioning: qualquer edição é uma nova versão da gravação; O antigo estado é armazenado para investigações.
Incidentes: modelos reason _ código, ligação com tíquetes (Jira/Case-ID).
12) Métricas de qualidade e propósito
Hit Rate (HR) = proporção de operações em qualquer lista.
Hard-Hit Rate (HHR) = proporção de bloqueados severamente.
Overblock Rate (OBR) = proporção de bloqueios «falsos» (posterior pagador de valor).
CB- Uplift↓/Fraud- Loss↓ após a implementação.
Approval Rate (AR) para depósitos/conclusões.
Time-to-Wallet (TTW) influencia medidas soft-up (step-up) na velocidade de pagamento.
Time-to-Decision (p95/p99) para cheques online.
13) Direito e privacidade
Fundamento do processamento: legítimo interesse/obrigação legal (AML/sanções/frod prevaricação).
Minimização: armazenando hash/tokens em vez de dados primários (PAN/IBAN), solim, controlando o acesso.
Prazo de armazenamento: TTL + políticas gerais de retenção (AML/contabilidade/regulação).
Direitos de sujeito: Processo DSAR/Remoção (com exceção de compliance).
Fronteiras: limites claros de replicação entre regiões/tenentes.
14) Erros frequentes e como evitá-los
Ovlock IP/ASN: data centers/CGNAT → use uma combinação de sinais (IP + dispositivo + comportamento).
Vazamento de dados pessoais: normalize o e-mail/telefone, leve em conta o recall de números.
Reimplantamento de cartões (PAN reemissão): Vincule-se ao PAN-token/cripto-tokenização, em vez de dados crus.
Casa IBAN geral: aplique scope (apenas payouts) e observa em vez de deny global.
Endereços criptos: não bloqueie tudo; leve em consideração as marcas/contexto (bolsas, carteiras castodiais).
15) Conexão com bônus-abyus e limites
Bónus-pattern: uma carteira/endereço → muitas contas, saída rápida sem circulação - em stop/deny em payouts.
Limites e TtW: «observe» pode exigir maior circulação/ TtW alargado até o revezamento.
16) Exemplos de chaves (formas canónicas)
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) Listas de controle (folha de cheque de implementação)
1. Definir policy set: deny/stop/outserve/allow + reason _ codes.
2. Esquema de dados: chaves, scope, ttl/expedy, confidence, auditoria.
3. Arquitetura: Redis + PG + Kafka, idempotency, controle de quatro olhos.
4. Fluxo pré-auth check, step-up, payout-hardening.
5. Métricas/dashboard: HR/HHR/OBR/AR/TTW, cortes por jurisdição/canal.
6. Processos: Revezamento/amnistia, downloads em massa, DSAR, incidentes.
7. Treinamento de equipes: sapport/risco/finanças, playbooks de solução de conflitos.
18) Mini playbooks
BIN X sobe CB para stop temporário (deposit) por 'bin: X' + reroute para outro equador, revidando 48 h.
Trocar adereços antes de sair → stop (withdrawal) + KYC-step-up + validação de benifero.
Um hit de consórcio de carteira → observo de depósito, stop em payouts até um revezamento MLRO.
As notícias de sanção do país Y → atualizar o country-scope, incluir deny em payouts, contar as listas.
19) Exemplo de interface de painel admin (lógica)
Pesquisa por chave/máscara, filtros: policy, scope, reason, fonte, expedy <30d.
Кнопки: Amnesty, Extend TTL, Lower to Observe, Convert to Deny, Add Allow.
Ações de massa com dry-run: mostrar quantas operações serão submetidas às novas regras.
20) Currículos
As folhas de bloco não são apenas uma «tabela de proibição», mas um serviço de nível de plataforma, com um modelo de dados claro, dinheiro forte, auditoria, TTL adequado e processos de revezamento nítidos. Se eles estiverem bem integrados com o risco-motor, eles encurtarão o vórtice sem quebrar a conversão e agilizarão os pagamentos onde for seguro.