Os limites Velocity e anti-abws

1) O que é velocity e o que é necessário

• reduzir o frod e a operação de bónus/promoção,
• proteger a infraestrutura de pagamento contra «tempestades» de retrações,
• manter a conversão saudável, traduzindo os esforços duvidosos em um desafio (3DS/SCA) em vez de «rejeição severa» sempre que possível.

Os controladores Velocity complementam o screen, AVS/CVV, 3DS2/SCA e smart-routing.

2) Quais as entidades de limitação (scopes)

• Entidades de pagamento: 'card _ tocen' (vault/network), 'bin', 'issuer', 'psp _ rota'.
• Personalizado: 'matt _ id', 'kyc _ level', 'email/phone'.
• Técnico: 'device _ id' (fingerprint/SDK), 'ip', 'asn', 'suisse _ id'.
• Contexto de negócios: 'bônus _ id', 'campaign _ id', 'country', 'mcc 7995' subtipo (depósito/retirada).
• Financeiro: 'amount _ bucket' (micro/médio/grande), 'currency', 'payment _ method'.

3) Janelas e contadores

Fixed window (T = 15m/1h/24h) - simples, mas sensível aos limites.
Sliding window - mais precisamente, conta para um intervalo «deslizante».
Leaky bucket/Tocken bucket - suavizam os destaques, definem a capacidade de banda sustentável.
Combinado: burst (curta) + sustained (longo fluxo).

• 'device _ id': ≤ 3 tentativas de autorização em 15 minutos; ≤ 10 em 24 horas.
• 'card _ tocen': ≤ 2 decline consecutivos sem 3DS; terceiro - 3DS obrigatório.
• 'ip': ≤ 5 'card _ token' exclusivo em 1 hora (senão, capcha/bloco).
• 'matt _ id': ≤ 2 depósitos cancelados consecutivos; a seguir, cooldown 1 hora.

4) Algoritmos de restrição (curto)

• Inicialize 'capacity' e 'refill _ rate'.
• Antes de cada tentativa, «tire» 1 token; se não houver tokens - challenge/decline.

• A fila desloca-se a uma velocidade constante; os eventos que chegam estão a sobrecarregar - throttle.

• 1 repetição: 2-5 min → 2: 10-20 min → 3: 1-2 h → stop, ou tradução para um método alternativo.

5) Políticas de decisão (decisioning)

• Allow: baixo risco, dentro dos limites.
• Challenge: superou o limite «macio» → 3DS/SCA/KBA (perguntas).
• Throttle: limite temporariamente (cooldown) com UX transparente.
• Decline: violações graves (excesso de mapas, bot pool, bónus-abuse).
• Rerute: mudança de PSP/método (por exemplo, A2A) quando o emissor sobe '91/96'.

Mini-matriz de exemplos

'device _ id' tentado ≥ 3 em 15 min e 'cvv = N' ≥2 → Decline + kupcha.
'card _ tocen' 2 soft-decline consecutivos → 3DS-challenge (obrigatório).
'ip' 5 exclusivos 'account _ id' em 30 min 'Throttle 30 min + teste KYC.
'conta _ id' depósito-retirada de 10 min (carrossel) → Challenge ou limite de valor.

6) Velocity para depósitos, retrações e conclusões

• Proteja «micro-entradas» (muitas transações pequenas): limite de quantidade e circulação total por T.
• Com a série '05 '/' 14 '/' 54' - Pare «excesso» de adereços, transfira para 3DS.

• Espalhe as filas CIT e MIT. Use janelas suaves T + 1/T + 24h para MIT.
• Soft-decline 'SCA required' → imediatamente 3DS, não crie tentativas.

• Limites individuais de soma/frequência: por exemplo, ≤ 2 saques/24h e ≤ N de soma/semana.
• «Escada» KYC: Quanto maior a verificação, maiores os limites.
• «Circling»: depósito rápido e saída instantânea - review manual/hold.

7) Promoção anti-abuse e bônus

Per-campaign caps: 'bônus _ id' ≤ X ativações em 'device _ id '/' ip '/' payment _ fingerprint'.
«Garfos» (sobrecarga de dinheiro entre as contas): análise gráfica de cartões compartilhados/IP/dispositivos.
Cool-off windows: após o depósito bónus - proibição de saída instantânea, regras transparentes no ToS.
Sanções de nível, de bloqueios temporários a «para sempre», com registros de razões.

8) Arquitetura: onde viver as regras velocity

Real-time gateway (no orquestrador): solução ≤ 50-100 ms.
Armazenamento de contadores: in-memory (Redis/KeyDB) + Resumos de longo prazo (DWH).
Fichestor: janelas/unidades unificadas (15m/1h/24h/7d).
Rule engine + ML detalhe: «safety-net» regras sobre o modelo.
As bandeiras de config são «incluir 3DS», «mais rigoroso na região X», «pausa PSP-A».
Idempotidade: proteção contra duplicados em repetições/temporizações.

9) Pseudocode de regras (esboço)

pseudo on payment_attempt(ctx):
s = features(ctx) // device/ip/account/bin/score/avs/cvv/history if counter(device, 15m) >= 3 and cvv_fail(device, 15m) >= 2:
return DECLINE(reason="velocity_device_cvv")
if soft_declines(card_token, 1h) >= 2:
return CHALLENGE_3DS()
if uniq_accounts(ip, 30m) >= 5:
return THROTTLE(ttl=30m)
if score > T2 and velocity(account, 1h) > Vmax:
return DECLINE(reason="high_risk_burst")
return ALLOW

10) Pattern ux (sem quebra de conversão)

Mensagens claras: "Demasiadas tentativas em pouco tempo. Tente dentro de 15 minutos ou confira no banco".
Botão Repetir mais tarde com o timer.
A oferta de alternativas é A2A/carteiras locais de trottling.
Auto-3DS sem reinserir adereços no SCA-soft.
O capcha é apenas pontual (por IP/ASN/bot), não para todos.

11) Complaens e privacidade

GDPR/PII: Guarde identificadores mínimos (dispositivos hashs, tocadores de mapas, last4), políticas transparentes.
PCI DSS: Nada de PAN/CVV nos logs; eventos velocity sem dados sensíveis.
PSD2/SCA: transfira excesso em um challenge onde for apropriado, em vez de falhas totais.

12) Métricas, alertas, SLO

• Approval Rate (geral e quando as regras são ativadas).
• Falso Positivo Rate de regras de velocidade (proporção de blocos honestos → por legitimidade posterior).
• Número de «tempestades» de retais e tempo médio de recuperação.
• Proporção de traduções de decline → challenge com sucesso.
• Marceback rate em segmentos onde os limites foram executados (esperamos ↓).

• Spike 'n' + aumento de tentativas> X em 15 min no cluster BIN/ASN.
• Surto '91/96' - Elevação automática do limite T1 + routing no PSP-B.
• Regras FP> destino (por exemplo, 1. 5 x mediana semanal).

• Solução de velocity de 100 ms p95.
• Proporção de pagamentos bem-sucedidos transferidos para 3DS em vez de desistir ≥ destino.

13) Anti-pattern

Limite universal «total» para todos os mercados e tipos de clientes.
Bloquear por 'AVS = U/S/G' em países onde o AVS não funciona normalmente.
Não separar CIT/MIT - quebra assinaturas/repetições.
Retraia sem jitter e idempotação - duplos e tempestades.
Escondendo as razões da falha, cresce o safort e a toxicidade.

14) Folha de cheque de implementação

• Mapa de entidades (scopes) e janelas (15m/1h/24h/7d).
• Seleção de algoritmos: sliding + tocen bucket para bursts.
• Normalização de retrações: backoff + jitter, separados para CIT/MIT.
• Integração com 3DS/SCA: auto-challenge com excesso suave.
• Limites individuais para conclusões e bônus; Um conde para verificar as ligações.
• Observabilidade: dashboards KPI/alertas/auditoria de regras.
• Modelos de mensagem UX e métodos alternativos.
• Políticas PCI/GDPR: tokens, camuflagem, minimização do PII.
• Testes A/B de liminares de mercado/BIN/ASN e perfis de clientes.
• Playbooks de incidentes: degradação do emissor/PSP, explosão de bots.

15) Resumos

Os limites velocity eficientes são janelas e contadores de várias entidades, algoritmos de suavização (token/leaky bucket), retais inteligentes e conexão estreita com 3DS/SCA e screen. Este tipo de circuito reduz o frod e o abuse, não sufoca a conversão, e ajuda a manter a monetização estável com a volatilidade dos emissores e do tráfego.