Integração KYC/AML com provedores de verificação

1) Para quê e quais KPI são importantes

Metas: conformidade com reguladores, prevenção de fraudes/lavagem, redução de charjbacks e riscos de parceiros/pagamentos com o mínimo de atrito.

Métricas-chave:

Approval rate (por segmentos de mercado/pagamento/VIP), FPR/FNR, tempo de pagamento (p95), custo de verificação por jogador.
Hit-rate sobre sanções/PEP/Adverse Media, proporção de malas manuais, porcentagem de verificações pendentes.
Provedor SLA (farmácia, latency, p95 resposta), retrai/erro de integração.

2) Arquitetura básica de integração

Camadas:

1. Orquestrator (seu serviço de risk-onboarding): routam as solicitações entre os provedores com regras/países/tipos de verificação.

2. Providers SDK/API: KYC (ID + Liveness), AML (санкции/PEP/Adverse Media), Address, Age, Device.

3. Função Store/Risk Engine: armazena resultados, bandeiras, fichas para escrutínio e antifrode.

4. Gestão de cases: verificações manuais, apelações, segunda-linha review.

5. Audit & Compliance: logs de soluções imutáveis, versionização de regras/modelos, relatórios ao regulador.

Fluxo de eventos:

Registration → Age/ID (KYC mínimo de jurisdição).
First Deposit/Withdrawal → Enhanced Du Diligence (EDD em somas/riscos).
Recurring AML Screening: recarga de sanções/RER agendada (diárias/semanais).
Trigger-based: mudança de adereços/dispositivo/geo-re-screen.

3) Tipos de verificação e exatamente o que eles fazem

Documento Verification: passaporte/ID/águas. identificação/autorização de residência; OCR + MRZ/Barcode, cheque de autenticidade.

Liveness & Biometrics: liveness ativo/passivo, face-match (selfie↔document).

Address Verification: proof of address (utility bill/extrato bancário), às vezes registros de endereços.

Sanches/PEP/Watchlists: OFAC/UN/EU/UK HMT + local; indivíduos politicamente significativos; listas de mídia indesejada/crônicas judiciais (Adverse Media).

Age Verification: data de nascimento vs liminares locais.

Device/Email/Phone: sinais de risco (domínios descartáveis, quartos virtuais, proxy/hospedagem).

KYB (para parceiros/merçantes): documentos estatutários, beneficiários (UBO), registros de registro, notícias negativas.

4) Orquestração e abordagem de risco baseada

Regras de roteiro: país do documento → provedor A se não houver cobertura → provedor B; VIP/alto valor → pacote EDD.

Step-up lógica: cheque soft (fontes de dados) → quando solicitamos selfies/documentos.

Composição: A combinação AML screening + IDV + Address depende da jurisdição (MGA/UKGC/Curacao etc.) e do estágio do ciclo de vida (onboarding vs payout).

Re-screening: periódico (por exemplo, diariamente sob sanções) e evento (alteração de país/documento).

5) Design de API e pattern de integração

Idempotency & retries: todas as chamadas - com a chave de idempotação; Retraias exponenciais, temporizadores, circuito-breaker.

Webhooks: estados assincrônicos (processing → completed → reviewed).

Validação de entrada: Controle de formato (MRZ, ISO country, documento-tapa).

Armazenamento de artefatos: criptografia, TTL/retenção por jurisdição, acesso pelo princípio «mínimo necessário».

Exemplo de consulta (pseudo):

http
POST /kyc/start
{
"user_id": "u_123",  "flows": ["IDV","AML"],  "country_hint": "DE",  "document_types": ["PASSPORT","NATIONAL_ID"],  "webhook_url": "https://risk. example. com/webhooks/kyc"
}

Resposta do provedor:

json
{
"session_id": "sess_abc",  "status": "pending",  "redirect_url": "https://provider/flow/sess_abc"
}

Webhook-total:

json
{
"session_id": "sess_abc",  "status": "approved",  "checks": {
"idv": {"liveness": "pass", "face_match": 0. 92, "doc_authenticity": "pass"},   "aml": {"sanctions": "clear", "pep": "clear", "adverse_media": "none"}
},  "risk_score": 18
}

6) Qualidade de dados: problemas e soluções típicas

Transmutação/variabilidade de nomes: use algoritmos fonóticos, normalização, alias-tabelas.

Links não-latinos: Comparando nomes em cirílico/visco/hanzhi árabe → módulos de comparação locais.

Data de nascimento/endereço: formatação, teste cruzado com documento e endereço de pagamento (BIN/AVS).

Falsas coincidências em sanções/RER: configuração de fuzzy-score e regras de escalação (teses jovens, nomes frequentes).

Qualidade da foto: dicas UX (luz, moldura, brilho), controle automático de nitidez/ângulo.

7) SLA, observabilidade e alertas

Latency Alvs: Conboarding interativo ≤ 60-120 ms para consulta ao diretório/screening + etapas asinhrônicas ≤ 2-3 min (documentos).

Farmácia, ≥ 99. 9% para endpointos críticos; provedor duplo (ativo-ativo/ativo-standard).

Alerts: crescimento de 'erro _ rate', degradação de 'hit _ rate', salto de 'review _ rate', 'janelas silenciosas' de webhooks, atrasos de OCR/Liveness.

Logi/trailing: correlation-ID da frente ao provedor; masked payloads; armazenamento da decisão e das razões.

8) Gerenciamento de casos (Case management)

A fila de malas é prioridade por soma/risco/região.

Playbooks: o que pedir ao cliente (selfies novamente, outro documento, proof of address).

SLA por mala manual: p95 ≤ 24 horas; high-value ≤ 2 ч.

Apelações: novo jogo + reviewer independente; documentação das causas da falha (adverse action notice).

9) Complaens e privacidade

GDPR/similares locais: purpose restrição, data minimization, direito de acesso/remoção (quando aplicável).

PCI DSS: se os dados de pagamento forem afetados.

PSD2/SCA: correlação com forte autenticação em passos de pagamento.

Retenção: Armazenar apenas os artefatos exigidos e apenas o tempo que a lei/regulador exige.

Explainability: Construa «definição rational» - em que o sistema se baseou (liveness fail, doc mismatch, PEP hit).

10) Custo e modelo de compra

Pricing: per-check, tarifas de pacote, coeficientes regionais, suplementos para EDD/Adverse Media.

Otimização: orquestração baseada em risco (provedor barato → caro para folback), armazenamento de resultados em TTL, re-screen para delta.

Folha de cheque RFP: coberturas por documentos/países, precisão liveness/face-match, frequência de atualização de sanções/RER, latency, webhooks, SDK, relatórios, DPIA/certificação, on-prem, práticas judiciais/regulatórias, iGaming.

11) KYB: quando você trabalha com B2V/parceiros

Registos Companies House, Registos Comerciais Locais, Cadeias UBO.

Documentos: incorporação, estatuto, e-mails bancários, diretores/procurações.

Screening: sanções/RER para a UBO e diretores, Adverse Media para a marca/pessoa jurídica.

Desencadeadores de ré-screen: mudança de diretor/endereço/beneficiário, aumento acentuado de rotação.

12) UX e Conversão: como não «quebrar» o onbordamento

Mobile-first: SDK com contos de fadas automáticos (moldura, inclinação, proteção em bloco).

Hyde para o usuário: o que preparar com antecedência (documento, iluminação), quanto tempo o processo vai demorar.

Um bar de progresso e estatais bem definidas.

Graceful fallback: se a câmera/sensor não estiver disponível → fluxo alternativo (manual upload + verificação posterior).

13) Incidentes e folbacks

Modo fail-safe: quando o provedor cai, alterna para reserva + aplicação de regras minimamente suficientes.

Degradation policy: Permitimos apenas depósitos de pequeno limite sem saída até que a verificação seja concluída.

A verificação adiada é a emissão de limites de tempo que indicam a necessidade de localização.

14) Testes e certificação de integração

Barras de areia dos provedores: «felizes «/« infelizes »caminhos, edge-mala (destaques, documento cortado, gémeos).

Testes Contracto: fixação do padrão de resposta, migração da API.

Carga: pico de lançamento/promoção (tráfego x5-x10), longos webhooks, reorder eventos.

Ensinamentos DR.: desativação de um provedor, queda de webhooks, versões rollback.

15) Regras de Decisão

Exemplo de definição-tabela (simplificado):

Condição	Ação	Comentário
Sanctions=hit (strong match)	DENY	Escalar para a complacência, relatório
PEP=possible + Adverse=negative	REVIEW/EDD	Dop. fontes de ferramentas
Liveness=fail или FaceMatch<0. 8	RETRY (1 a 2 vezes) → REVIEW	Dicas UX
Address=fail + High-risk country	HOLD	Proof of address novamente
Clean KYC/AML + Low risk score	APPROVE	Limites de política

16) Exemplo de mala completa (abreviado)

Cenário: novo jogador da Alemanha, depósito de €300, pedido de bónus.

1. Soft check (AML fast): clear.

2. IDV: passaporte + selfie, liveness = pass, face _ match = 0. 93, doc=authentic.

3. O Address: utility bill foi ultrapassado.

4. Decision: APPROVE, limite de saída de até €2.000, novo AML-re-screen diariamente.

5. Auditoria: versões do motor, provedor, regras, fici e rational gravadas.

17) Folha de cheque de implementação

Orquestrador com failover e routing por jurisdição.
Contratos/SLA/preços, DPIA e acordos legais.
Webhooks, idumpotência, retais, trailing.
Gestão de cases e playbooks EDD.
Pariodic re-screen (sanções/RER) e triggers event-based.
Monitoramento de qualidade (hit-rate, FPR/FNR, tempo de passagem).
Política de retenção/remoção e acessibilidade (RBAC).
Plano DR. e exercício de degradação.

Currículos

Uma forte integração KYC/AML não é «conectar um único provedor», mas construir uma orquestra a partir de várias fontes onde as decisões são tomadas de forma baseada, transparente e rápida. Combine IDV, Liveness, Sanções/RER e endereço, implemente gestão de case e auditoria rígida, mantenha os provedores de folback e não se esqueça do OX - para que você cumpra as exigências dos reguladores e mantenha a conversão de alto nível.