Automatização de Due Diligence do Cliente: Arquitetura para CDD Consciente de Jurisdição

---

Um cliente de alto risco na Alemanha requer Enhanced Due Diligence sob AMLD5 Art. 18. O mesmo perfil de risco na Espanha requer verificações adicionais sob Ley 10/2010 Art. 11. O mesmo cliente expandindo para os Países Baixos precisa de avaliação sob Wwft Art. 3. Cada jurisdição requer verificações ligeiramente diferentes, limiares diferentes e profundidade de documentação diferente.

A maioria dos sistemas lida com isso com instruções if:

if jurisdiction == "DE" and risk_level == "high":
    run_enhanced_checks_germany()
elif jurisdiction == "ES" and risk_level == "high":
    run_enhanced_checks_spain()
elif jurisdiction == "NL" and risk_level == "high":
    run_enhanced_checks_netherlands()

Isso funciona para um mercado. Falha ao expandir. Cada nova jurisdição requer um novo bloco de código, um novo ciclo de testes, um novo deploy. Mudanças regulatórias (uma nova diretiva, um limiar revisado, um tipo de verificação adicional) requerem modificação de código. A equipe de compliance depende de engenharia para cada ajuste de regra. O backlog de engenharia se torna um gargalo regulatório.

A alternativa é um modelo baseado em políticas: regras CDD armazenadas como dados, não como código. Decisões de compliance são derivadas da combinação (Jurisdição, Nível de Risco, Tipo de Verificação, Profundidade). Adicionar uma nova jurisdição é um registro de configuração, não uma mudança de código.

Regras CDD como Dados

Uma política CDD define: para esta combinação de jurisdição, nível de risco e tipo de verificação, que profundidade de verificação é requerida?

A tabela é a política. Não há instrução if. O motor consulta: "Para jurisdição=DE, risk_level=high, check_type=identity, qual é a profundidade requerida?" A resposta é um valor de dados, não uma ramificação de código.

Isso não elimina a complexidade. Os requisitos regulatórios SÃO complexos. O que elimina é o acoplamento entre complexidade regulatória e complexidade de código. A equipe de compliance pode definir e atualizar políticas. Engenharia mantém o motor que as executa. As duas preocupações evoluem independentemente.

Ciclo de Vida de Políticas: Rascunho → Ativa → Arquivada

As políticas CDD não são estáticas. Reguladores atualizam diretivas. Limiares de risco mudam. Novas jurisdições são adicionadas. Políticas precisam de versionamento.

Três estados:

A ativação substitui a política ativa atual para a mesma combinação (Jurisdição, Nível de Risco, Tipo de Verificação). A política anterior é arquivada automaticamente. Um auditor pode reconstruir qual política estava ativa em qualquer momento: consultar as políticas arquivadas por faixa de timestamp.

Isso satisfaz AMLD Art. 8 (medidas internas documentadas) e DORA Art. 11 (rastreabilidade TIC). O histórico de políticas não é um documento escrito em um wiki. É um registro de dados com timestamps, versionamento e transições de estado, consultável, auditável e à prova de manipulação.

Abstração de Provedores

As verificações CDD são executadas por provedores externos: Identomat para verificação de identidade, ComplyAdvantage para screening PEP/sanções, um provedor local para comprovante de endereço em certas jurisdições. Cada provedor tem uma API diferente, um formato de resposta diferente e um modelo de preços diferente.

O motor CDD não chama os provedores diretamente. Chama uma interface de provedor:

interface CddCheckProvider {
  executeCheck(customer, checkType, depth) → CddCheckResult
  getStatus(sessionId) → CheckStatus
}

A política especifica qual verificação executar. A configuração de provedor especifica quem a executa. Trocar de Identomat para Onfido para verificação de identidade na Alemanha é uma mudança de configuração, não uma mudança de código, não uma mudança de política, não um ciclo de testes do pipeline CDD.

Esta separação importa quando provedores falham. Se Identomat tem uma queda, o sistema pode rotear verificações de identidade para um provedor de backup, sem mudar a política CDD, sem mudar o fluxo de onboarding, sem um deploy de emergência. O provedor é uma preocupação de infraestrutura. A política é uma preocupação de compliance. Os dois falham independentemente e se recuperam independentemente.

Perfiles de Jurisdição

Cada jurisdição traz parâmetros regulatórios além das políticas CDD: calendários de feriados (para cálculos de dias úteis), limites de transação (PSD2 Art. 87 requisitos de data valor variam por esquema), períodos de retenção para documentos de compliance (GoBD: 10 anos na Alemanha, Ley 10/2010: 10 anos na Espanha).

Um perfil de jurisdição consolida estes parâmetros:

{
  "jurisdiction": "DE",
  "regulatoryFramework": ["AMLD5", "KWG", "GwG", "GoBD"],
  "holidays": "TARGET2 + DE national",
  "retentionPeriod": "10 years (GoBD §147)",
  "transactionLimits": {
    "sctInstant": { "max": 100000, "currency": "EUR" }
  },
  "cddRequirements": {
    "documentTypes": ["passport", "nationalId", "residencePermit"],
    "addressProof": "required for high-risk",
    "sourceOfFunds": "required for high-risk"
  }
}

Expandir para uma nova jurisdição significa: criar o perfil de jurisdição, definir as políticas CDD, configurar as atribuições de provedores. Zero mudanças de código. Zero deploys (a menos que o novo perfil requeira um novo tipo de verificação que ainda não exista, esse é o caso onde uma mudança de código é necessária).

O Impacto Operacional

Três capacidades que instruções if codificadas não podem fornecer:

Expansão de mercado sem engenharia. A equipe de compliance define as políticas CDD para Portugal. A equipe de operações configura a atribuição de provedores. A equipe de produto habilita a jurisdição na interface de onboarding. Nenhum engenheiro escreveu uma instrução if. Nenhum deploy requereu ciclo de testes do motor CDD. A plataforma suporta um novo mercado através de configuração.

Mudanças de regra sem deploys. O regulador alemão atualiza os limiares de EDD. A equipe de compliance cria uma nova versão da política CDD (Rascunho), a revisa, a ativa. A versão anterior é arquivada automaticamente. A mudança é efetiva imediatamente. O registro de auditoria mostra quando a mudança ocorreu e qual política foi substituída.

Prontidão para exame regulatório. Um auditor pergunta: "Mostre-me seus procedimentos CDD para clientes de alto risco na Espanha em junho de 2025." O sistema consulta as políticas arquivadas: Jurisdição=ES, NívelDeRisco=alto, com validade naquela data. A resposta é uma consulta ao banco de dados, não um exercício de busca de documentos.

Cinco Perguntas para Avaliar Seu CDD

1. Sua equipe de compliance pode mudar limiares CDD sem um ticket de engenharia? Se não: as regras CDD estão codificadas. Cada mudança regulatória requer um ciclo de desenvolvimento.

2. Pode expandir para uma nova jurisdição sem um release de código? Se não: os requisitos de jurisdição estão codificados. A expansão está limitada pela capacidade de engenharia.

3. Pode reconstruir qual política CDD estava ativa em uma data específica? Se não: as políticas não são versionadas. Auditores não podem verificar conformidade histórica.

4. Pode trocar de provedor KYC sem modificar seu fluxo de onboarding? Se não: provedor e fluxo estão acoplados. Falhas de provedor são falhas de plataforma.

5. Seus registros de decisão CDD são consultáveis por jurisdição, nível de risco e período de tempo? Se não: a prontidão para auditoria depende de agregação manual de dados.

---

Leia mais: Compliance, Infraestrutura de Compliance | Segurança e Compliance

---

Fontes:

• AMLD5, Diretiva (UE) 2018/843, Art. 8 (medidas internas), Art. 13 (CDD padrão), Art. 18 (EDD)
• DORA, Regulamento (UE) 2022/2554, Art. 11 (rastreabilidade TIC)
• GwG (Alemanha), Geldwäschegesetz, §10-15 (obrigações CDD)
• Ley 10/2010 (Espanha), Prevenção de lavagem de dinheiro, Art. 3-11 (obrigações de due diligence)
• Wwft (Países Baixos), Wet ter voorkoming van witwassen, Art. 3 (obrigações CDD)