Complacência de pagamento de sanções
1) Por que isso é necessário (quadro de risco)
Risco legal: multas/revogação da licença por violação dos regimes de sanções.
Risco financeiro: congelamento de fundos/contas no corredor (correspondente/PSP/esquema).
Risco operacional: devoluções de força maior, transações dependentes, verificações manuais crescentes.
Reputação, os incidentes de «sanção» atingem os bancos parceiros e o acesso aos corredores.
2) Regimes e princípios
As listas são OFAC (SDN/SSI), EU, UK (OFSI), CA, AU, ONU, local.
Embargo geo, proibições completas por países/territórios.
Setoriais: restrições por setor/prazo de financiamento (SSI/Direction).
Regra de 50%: se um ou mais SDN possuem ≥50% somados - o sujeito é considerado bloqueado, mesmo que não seja nomeado.
Exportação, controle/duplo uso: pagamento por produto/serviço proibido (importante em remits A2A/SWIFT).
Kripto/Travel Rule: transferência de atributos KYC entre VASP em transferências.
3) Onde e como escavar (caminho de pagamento)
3. 1. Depósitos
Pagador: nome/endereço/data de nascimento (se disponível), cartão (BIN-geo), carteira, IP/ASN, device.
Provedor: PSP/MID e sua jurisdição; verificar a pureza da rota.
Eventos: criação de perfil (L0), primeiro depósito (L1), anomalias (velocity/geo-conflito).
3. 2. Conclusões
Beneficiário: IBAN/BIC/nome/endereço, cartão/carteira, endereço cripto (VASP).
Rota: same-method/return-to-nature, banco destinatário, correspondentes possíveis.
Travel Rule (cripto): compartilhamento de dados originator/benfiquiary, verificação de status VASP.
3. 3. Rotação/corredores
A2A/SEPA/FPS/PIX/RTP: banco destinatário e seu país/risco de sank.
Push-to-card: banco emissor de cartão (BIN-país/banco).
SWIFT: bancos correspondentes (todos os elos da cadeia).
E-wallets - jurisdição do emissor/operador de carteira.
4) Tipos de screening e sinais
Nome/alias/translitoração (phaszi-jogo, redução da diacrítica).
Endereço/cidade/código postal (geo-desencadeadores, localização «sanção»).
Data de nascimento/passaporte/MRN (quando disponível a partir de KYC).
Organizações/BENEFICIÁRIOS (UBO): dê diligence estendida.
O BAN/BIC e o banco destinatário: um país, um «banco de sanções» ou um banco subalterno UBO.
BIN/emissor de cartão: país/banco, cross-check com listas de sunk.
IP/ASN/VPN/hospedagem: sank geo, proxy/shadow ASN.
Device-graph/household: cruzamento com bloqueados anteriormente.
Os endereços cripto são os rótulos «sanção/mixers/clusters de risco» dos provedores de blockchain.
Conflito Geo: País KYC ≠ IP ≠ SIM ≠ BIN-geo.
5) Orquestra de screening: «onde incorporar»
1. Onboarding é um screening leve chamado/DR, country risk.
2. Payment init: hit-check sincronizado pagador/beneficiário, IBAN/BIN, IP/ASN.
3. Pré-roting: deny/hold/step-up (SoF/documentos) antes de ser enviado para o corredor.
4. In-flight: monitoramento de estatais de PSP/bancos (returns/holds).
5. Post-event: recrining retrospetivo quando as listas são atualizadas (backfill).
6) Política de soluções (risk-based)
AUTO-PASS: nenhum sucesso; baixo risco país/banco; same-method; ND≥0.
MANUAL REVIEW: Sucesso de fuzzy abaixo do limite alto; o novo beneficiário; conflito geo; country alto/sector risk.
DENY/BLOCK: hit SDN exato, «regra de 50%», embargo GEO, banco de sanções/corredor.
STEP-UP: solicitação de SoF/SoW, confirmação do endereço/nome do beneficiário, «name check/BAN» (onde está disponível).
7) Redução de falsos acionamentos (precisão)
Normalização do FIO (reposicionamento de nomes/nomes, nome, nome, cadeirantes, partículas).
Atributos contextuais: data de nascimento/cidade reduzem FPR.
White-lists: Beneficiários/bancos/IBAN verificados (com TTL e revalidação).
Lista ASN/VPN: Menos hits de IP barulhentos.
Liminares segmentais: mais rigoroso para high-risk GEO/corredores, mais suave para low-risk.
Resolução auto após APPROVE manual com o mesmo fingerprint (device/IBAN).
Os registros de explicação: por que é rejeitado/permitido (screen, regras, campos de correspondência).
8) UX e comunicações
Razões transparentes: «É necessário validar o destinatário por causa do banco/país».
Prazo: ETA honesto para verificação manual/SoF.
Retornos: Refand automático na carteira de jogo, link «escolher outro método/destinatário».
Localização: textos legais, links para políticas de sanções/suporte.
9) Engenharia: modelo de dados (mínimo)
sql sanctions.watchlists (
source TEXT, -- OFAC, EU, UK, UN, etc.
entity_id TEXT, -- уникальный ID записи entity_type TEXT, -- person org vessel bank name TEXT, aliases TEXT[], dob DATE, country TEXT,
programs TEXT[], -- санкционные программы ownership_json JSONB, -- связи для "50% правила"
updated_at TIMESTAMP
);
sanctions.hits (
hit_id PK, user_id, payout_id, deposit_tx_id,
entity_id, source, match_score NUMERIC, match_fields JSONB,
status TEXT, -- OPEN APPROVED DENIED ESCALATED FALSE_POSITIVE reviewer TEXT, decided_at TIMESTAMP, created_at TIMESTAMP
);
payments.endpoints (
beneficiary_id PK, user_id, type, -- IBAN CARD WALLET CRYPTO iban TEXT, bic TEXT, bin TEXT, wallet_ref TEXT, crypto_addr TEXT,
bank_country TEXT, bank_name TEXT, verified BOOLEAN,
last_screened_at TIMESTAMP, risk_tags TEXT[]
);
risk.context (
user_id, ip INET, asn INT, device_hash TEXT,
geo_ip TEXT, geo_kyc TEXT, geo_sim TEXT, updated_at TIMESTAMP
);10) Políticas pseudo-DSL
yaml policy: "sanctions_payments_v4"
lists:
sources: [OFAC, EU, UK, UN, CA]
refresh_interval_hours: 6 screening:
on_user_create: true on_deposit_init: true on_payout_init: true on_new_beneficiary: true rescreen_on_list_update: true thresholds:
name_fuzzy_pass: 0.72 name_fuzzy_manual: 0.62 org_fuzzy_pass: 0.80 crypto_risk_max: "MEDIUM"
routing_guards:
deny_if:
- geo in [EMBARGOED]
- bank_sanctioned == true
- ownership_sdn_agg >= 0.5 # "50% правило"
manual_review_triggers:
- fuzzy_hit == true
- new_beneficiary == true AND amount > 1000 EUR
- geo_conflict_score >= 2
- vasp_untrusted == true stepups:
- if: payout_amount > 2000 EUR then: ["name_check_iban"]
- if: crypto == true then: ["travel_rule", "beneficiary_vasp_check"]
audit:
store_feature_snapshot: true store_decision_tree: true exceptions:
whitelist_beneficiary_ttl_days: 18011) Modelos SQL
11. 1. Pesquisa Fazzi por nome/aliase
sql
SELECT w.entity_id, w.source, w.name,
similarity(unaccent(lower(:full_name)), unaccent(lower(w.name))) AS score
FROM sanctions.watchlists w
WHERE w.entity_type='person'
AND (unaccent(lower(:full_name)) % unaccent(lower(w.name))
OR EXISTS (SELECT 1 FROM unnest(w.aliases) a
WHERE unaccent(lower(:full_name)) % unaccent(lower(a))))
ORDER BY score DESC LIMIT 20;11. 2. Verificação de 50% da regra de posse
sql
SELECT entity_id
FROM sanctions.watchlists
WHERE entity_type='org'
AND (ownership_json->>'sdn_agg_share')::numeric >= 0.5;11. 3. Desencadear ressecrining ao atualizar a lista
sql
INSERT INTO sanctions.hits (user_id, entity_id, source, match_score, status, created_at)
SELECT u.user_id, w.entity_id, w.source, 0.0, 'OPEN', now()
FROM users u
JOIN sanctions.watchlists w ON w.updated_at >:last_run
WHERE u.country IN (:risk_geos);11. 4. IBAN/banco destinatário: risco-guard
sql
SELECT e.beneficiary_id,
(e.bank_country = ANY(:embargo_geos)) AS embargo_hit,
(e.bic IN (SELECT bic FROM ref.sanctioned_banks)) AS bank_hit
FROM payments.endpoints e
WHERE e.beneficiary_id=:bid;11. 5. Crypto Travel Rule (controle simplificado)
sql
SELECT v.vasp_id, v.trust_level, tx.crypto_addr
FROM crypto.transfers tx
JOIN ref.vasps v ON v.domain = tx.beneficiary_vasp
WHERE tx.payout_id =:pid;12) KPI e dashboards
Hit Rate: proporção de transações/beneficiários com sucessos de sanções.
False Positive % и Manual Approve %.
Manual TAT p50/p95 (tempo de decisão).
Denied% em regimes/geo/corredores/bancos.
Rescreen backlog após atualizar as listas.
Returns/holds% em código de sunk de PSP/bancos.
Travel Rule coverage% (kripto).
Whitelisted TTL breach% («confiáveis» vazados sem revalidação).
13) Alertas
Folha Update Spike: Crescimento acentuado de êxitos após a atualização das listas.
FPR Surfe: Falso Positivo%> limiar d/d.
Manual Backlog: malas abertas> limite ou p95 TAT> SLA.
Embargo Rota Hit: Tentativas de pagamento de geo/bancos proibidos.
Travel Rule Missing: Traduções cripto sem compartilhamento de dados VASP.
Policy Drift: transações sem regras/soluções.
14) Playbooks incidentes
A. Sucessos em massa após a atualização da OFAC/EU
1. Congelar o carro-roding nos corredores de risco → MANUAL.
2. Prioridade em montante/ETA, treinamento rápido para as operadoras de novas aliass/ortografias.
3. Comunicação PSP/bancos: Alerta para crescimento temporário manual.
B. Devoluções do banco correspondente
1. Normalizar código de causa, coletar amostras (BIC, corredor).
2. Excluir temporariamente o banco/corredor da cascata, rerute.
3. Pós-mortem, atualizar a guia de «banco de trenó», reforçar a preçeca.
C. Cripto sem Travel Rule
1. Bloquear conclusões em VASP não testados, solicitar dados.
2. Ativar «only trusted VASP» antes de corrigir a integração.
3. Retuíte e relatório ao regulador, se necessário.
15) Best pratices (curta)
1. Policy-as-código com versões e sinais/soluções.
2. Screening em vários pontos (perfil, init, pré-rota, post).
3. Leve em conta a regra de 50% e as ligações UBO, não apenas os registros de nome.
4. Name normalization e contexto (DR/cidade) para reduzir FPR.
5. Listas brancas de beneficiários/bancos testados com TTL e revalidação.
6. Segmenta liminares GEO/método/corredor.
7. «Quem/quando/porquê».
8. Negocie com o PSP/bancos sobre os códigos de reembolso e SLA manual.
9. Travel Rule e registro VASP de confiança para cripto.
10. Regularmente pós-incidentes e sintonização de regras.
16) Folha de cheque de implementação
- Fontes de lista e taxa de atualização (OFAC/EU/UK/UN/local).
- Política de 50% e conde de UBO.
- Screening em onboarding/deposit/payout/new beneficiary/rescreen.
- Integração: PSP/bancos/vaspas, códigos de retorno.
- Matriz de limite (pass/manual/deny), segmentos de GEO/métodos.
- Listas brancas/negras (beneficiary/bank/ASN/IP) com TTL.
- Logs de explicabilidade, indícios de sinais/decisões, relatórios para licenças.
- Dashboards KPI e alertas; SLA manual.
- Playbooks (Atualizar listas, restituições, Travel Rule).
- Treinamento dos operadores (alíquotas/translitorações, country-raridade).
Currículos
A complicação de pagamento de sanções é uma orquestração de regras, dados e rotas, não apenas «acertar a lista». Inclua o screening nos pontos-chave da via de pagamento, leve em conta o UBO e a regra de 50%, gerencie corredores/bancos, reduza os falsos efeitos através da normalização e do contexto, armazenando soluções e versões explicáveis de políticas como código. Assim, vai manter o acesso aos corredores, reduzir os custos operacionais e suportar as licenças sem matar a conversão.