> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# Guia de conformidade AMLR: APIs do Regulamento 2024/1624

> Associe cada requisito do Regulamento Antilavagem de Dinheiro da UE (AMLR) aos fluxos, endpoints de API e webhooks da Didit que o implementam.

O Regulamento Antibranqueamento de Capitais da UE (AMLR), Regulamento (UE) 2024/1624, reúne as regras de due diligence do cliente (CDD) em um único texto diretamente aplicável. Ele vincula instituições de crédito e financeiras, incluindo prestadores de serviços de criptoativos (CASPs), prestadores de serviços de jogos de azar e as demais entidades obrigadas listadas no Artigo 3. O regulamento entrou em vigor em 9 de julho de 2024 e será aplicável a partir de 10 de julho de 2027. Até lá, continuam valendo as leis nacionais que transpõem a diretiva atual.

Esta página é para os desenvolvedores e engenheiros de conformidade que precisam implementá-lo. Cada seção informa o que o regulamento exige, indica o artigo e mostra a etapa do workflow da Didit, o endpoint da API ou o webhook que você pode usar para essa parte. Para a visão geral de negócios, consulte a [página da solução AMLR](https://didit.me/solutions/amlr).

Última revisão: 2 de outubro de 2026.

> [!WARNING]
>
> **A Didit fornece as verificações e as evidências. Você continua sendo a entidade obrigada.** Você define o perfil de risco do cliente, decide se fará o onboarding e continua sendo totalmente responsável por qualquer tarefa que terceirizar (Artigo 18). Usar a Didit não torna, por si só, sua empresa em conformidade com o AMLR. Esta página não constitui aconselhamento jurídico: confirme com seu consultor jurídico e com sua autoridade supervisora como cada regra se aplica ao seu negócio.

## O que o AMLR exige em resumo

| Obrigação | Artigo | Onde encontrar na Didit |
| - | - | - |
| Saber quando a due diligence é acionada | Art. 19 | Sua própria lógica de roteamento e, depois, uma sessão por gatilho. Consulte [Quando a due diligence se aplica](#quando-a-due-diligence-se-aplica) |
| Identificar o cliente e verificar sua identidade | Art. 20(1)(a), Art. 22 | Verificação de identidade com carteiras de identidade digital ou captura de documentos. Consulte [Identificar e verificar pessoas](#identificar-e-verificar-pessoas) |
| Identificar os beneficiários finais e compreender a estrutura de propriedade | Art. 20(1)(b), Arts. 51 a 53 | Fluxo de Verificação de empresas. Consulte [Verificar empresas e beneficiários finais](#verificar-empresas-e-beneficiários-finais) |
| Verificar sanções e pessoas politicamente expostas | Art. 20(1)(d) e (g), Art. 42 | Triagem AML. Consulte [Triagem de sanções e PEPs](#triagem-de-sanções-e-peps) |
| Monitorar o relacionamento e manter os dados do cliente atualizados | Art. 26 | Monitoramento AML contínuo e validade de documentos. Consulte [Monitorar continuamente e atualizar](#monitorar-continuamente-e-atualizar) |
| Compreender a finalidade do relacionamento e, quando necessário, a origem dos recursos | Art. 25 | Questionários. Consulte [Finalidade e origem dos recursos](#finalidade-e-origem-dos-recursos) |
| Monitorar transações e comunicar suspeitas | Art. 26(1), Art. 69 | Monitoramento de transações e gestão de casos. Consulte [Monitorar transações e comunicar](#monitorar-transações-e-reportar) |
| Manter registros por 5 anos e, depois, excluir os dados pessoais | Art. 77 | Configuração de retenção, exportações e exclusão sob demanda. Consulte [Manter registros e depois excluir](#mantenha-registros-e-depois-exclua) |
| Incluir intervenção humana nas decisões automatizadas | Art. 76(5) | Revisão manual e atualizações de status. Consulte [Revisão humana de decisões automatizadas](#revisão-humana-de-decisões-automatizadas) |
| Governar o que você terceiriza | Art. 18 | Seu registro de terceirizações. Consulte [Terceirização](#terceirização) |

## Fluxo de ponta a ponta

Seu backend cria uma sessão, o usuário conclui o fluxo, a Didit notifica você e você recupera a decisão completa. A decisão de onboarding fica com a sua equipe. O monitoramento continua após o onboarding.

```mermaid theme={null}
sequenceDiagram
    autonumber
    participant User as Your customer
    participant You as Your backend
    participant Didit as Didit API
    participant Team as Your compliance team

    You->>Didit: POST /v3/session/ (workflow_id, vendor_data)
    Didit-->>You: session_id and url
    You->>User: Redirect to url
    User->>Didit: Completes the workflow
    Didit--)You: status.updated webhook
    You->>Didit: GET /v3/session/{sessionId}/decision/
    Didit-->>You: Decision with the result of every check
    You->>Team: Queue the case for a decision
    Note over You,Team: Risk profile and onboarding decision are yours (Article 18)
    Team->>Didit: PATCH /v3/session/{sessionId}/update-status/
    You->>Didit: POST /v3/users/aml-monitoring/
    Didit--)You: status.updated and data.updated on each change
```

## Quando a due diligence se aplica

O Artigo 19 define quando você deve aplicar a due diligence do cliente: ao estabelecer um relacionamento de negócios; em uma transação ocasional de pelo menos EUR 10,000, em uma única operação ou em transações vinculadas; quando houver suspeita de lavagem de dinheiro ou financiamento do terrorismo, independentemente do valor; e quando você tiver dúvidas sobre dados de identificação que já possui. Limiares mais baixos se aplicam em alguns setores: EUR 1,000 para transferências ocasionais de fundos e para CASPs, EUR 3,000 para transações ocasionais em espécie (no mínimo, a identificação e a verificação) e EUR 2,000 em jogos de azar. Um CASP deve, no mínimo, identificar e verificar o cliente em uma transação ocasional abaixo de EUR 1,000.

A Didit não decide se um gatilho se aplica. Você faz o roteamento por tipo e valor da transação no seu próprio código e, depois, inicia o fluxo correspondente.

| Requisito | Recurso da Didit | Endpoint ou configuração |
| - | - | - |
| Iniciar a due diligence para um novo relacionamento de negócios (Art. 19(1)(a)) | Sessão de verificação no seu fluxo de onboarding | [`POST /v3/session/`](https://docs.didit.me/pt-br/sessions-api/create-session) |
| Iniciar a due diligence quando uma transação ocasional ultrapassar seu limiar (Art. 19(1)(b), 19(2) a 19(5)) | Sessão de verificação no fluxo que você escolher para esse gatilho | [`POST /v3/session/`](https://docs.didit.me/pt-br/sessions-api/create-session) com o `workflow_id` correspondente |
| Detectar transações vinculadas que, juntas, ultrapassam um limiar | Regras de velocidade no Monitoramento de transações | [`POST /v3/transactions/`](https://docs.didit.me/pt-br/transaction-monitoring/transactions), [regras](https://docs.didit.me/pt-br/transaction-monitoring/rules.md) |
| Solicitar a verificação do cliente antes que uma transação sinalizada seja liquidada | Uma ação de uma regra move a transação para `AWAITING_USER` e uma sessão de verificação vinculada é criada | [Status de transações](https://docs.didit.me/pt-br/transaction-monitoring/statuses.md) |

Um esboço mínimo de roteamento para o seu backend. Ele não cobre todos os gatilhos do Artigo 19 (por exemplo, participar da constituição de uma pessoa jurídica), e as regras setoriais que se aplicam a você podem ser diferentes:

```python theme={null}
# Illustrative only. The figures are the Article 19 thresholds in EUR.
def due_diligence_for(event) -> str:
    """Return "full_cdd", "identify_and_verify" or "none"."""
    if event.new_business_relationship or event.suspicion or event.doubts_about_identity_data:
        return "full_cdd"

    amount = event.linked_total_eur  # one operation, or linked transactions added together

    if event.sector == "casp":
        return "full_cdd" if amount >= 1_000 else "identify_and_verify"
    if event.is_transfer_of_funds and amount >= 1_000:
        return "full_cdd"
    if event.sector == "gambling" and amount >= 2_000:
        return "full_cdd"
    if amount >= 10_000:
        return "full_cdd"
    if event.is_cash and amount >= 3_000:
        return "identify_and_verify"
    return "none"


WORKFLOWS = {
    "full_cdd": "YOUR_FULL_CDD_WORKFLOW_ID",
    "identify_and_verify": "YOUR_ID_ONLY_WORKFLOW_ID",
}
```

## Identificar e verificar pessoas

O Artigo 22(1) lista os dados que você deve manter sobre uma pessoa física: todos os nomes e sobrenomes, local e data de nascimento completa, nacionalidades, o número de identificação nacional, quando aplicável, o local de residência habitual e, quando disponível, o número de identificação fiscal. Em seguida, o Artigo 22(6) indica dois meios de verificar a identidade: um documento de identidade, passaporte ou equivalente, ou uma identificação eletrônica (eID) que atenda aos níveis de garantia "substancial" ou "elevado" do eIDAS, em conjunto com os serviços de confiança qualificados pertinentes.

### Os dados exigidos na decisão

A decisão retornada por [`GET /v3/session/{sessionId}/decision/`](https://docs.didit.me/pt-br/sessions-api/retrieve-session) traz uma entrada por verificação de identidade em `id_verifications[]`.

| Dado do Artigo 22(1)(a) | Campo em `id_verifications[]` | Observações |
| - | - | - |
| Todos os nomes e sobrenomes | `first_name`, `last_name`, `full_name` | Como aparecem no documento ou como a carteira os retorna |
| Local e data de nascimento completa | `place_of_birth`, `date_of_birth` | O local de nascimento está presente quando o documento o traz |
| Nacionalidades | `nationality` | Registre no seu próprio sistema as nacionalidades adicionais que o cliente declarar |
| Número de identificação nacional, quando aplicável | `personal_number` | O conteúdo deste campo depende do documento. Consulte o [relatório de Verificação de identidade](https://docs.didit.me/pt-br/core-technology/id-verification/report-id-verification.md) |
| Local de residência habitual | `address`, `formatted_address`, `parsed_address` | Passaportes raramente trazem endereço. Adicione [Comprovante de endereço](https://docs.didit.me/pt-br/core-technology/proof-of-address/overview.md) ou uma [validação de banco de dados](https://docs.didit.me/pt-br/core-technology/database-validation/overview.md) quando o documento não o trouxer |
| Número de identificação fiscal, quando disponível | `extra_fields.tax_number` | Somente quando o documento o traz. Caso contrário, colete-o com um [questionário](https://docs.didit.me/pt-br/core-technology/questionnaires/overview.md) |

### Os dois caminhos

| Requisito | Recurso da Didit | Endpoint ou configuração |
| - | - | - |
| Verificar com identificação eletrônica (Art. 22(6)(b)) | [Carteiras de identidade digital](https://docs.didit.me/pt-br/core-technology/id-verification/digital-id-wallets.md). Disponíveis em produção: MitID (Dinamarca), BankID Sweden, Finnish Trust Network (Finlândia), Smart-ID (Estônia, Letônia, Lituânia, Bélgica) e Mobile-ID (Estônia, Lituânia). Carteira Europeia de Identidade Digital (EUDI Wallet): **Em breve** | Configure os métodos por país na [etapa de Verificação de identidade](https://docs.didit.me/pt-br/console/id-verification-methods.md). O resultado informa `verification_method` e `wallet_provider` |
| Verificar com um documento de identidade (Art. 22(6)(a)) | [Captura de documentos](https://docs.didit.me/pt-br/core-technology/id-verification/overview.md) com verificações de autenticidade e [leitura do chip NFC](https://docs.didit.me/pt-br/core-technology/nfc-verification/overview.md) para passaportes e documentos de identidade eletrônicos. Para uso remoto, leia as normas preliminares abaixo | Etapas de Verificação de identidade e NFC no fluxo |
| Confirmar que a pessoa que apresenta o documento é o seu titular | [Prova de vida](https://docs.didit.me/pt-br/core-technology/liveness/overview.md) e [Correspondência facial](https://docs.didit.me/pt-br/core-technology/face-match/overview.md) com a foto do documento | Etapas de Prova de vida e Correspondência facial. Resultados em `liveness_checks[]` e `face_matches[]` |
| Manter evidências que você possa revisar depois | Registro da sessão com imagens, dados extraídos e carimbos de data e hora | [`GET /v3/session/{sessionId}/generate-pdf/`](https://docs.didit.me/pt-br/sessions-api/generate-pdf), [exportações](https://docs.didit.me/pt-br/console/export-pdf-csv.md) |

O nível de garantia informado por cada carteira está listado na página [Carteiras de identidade digital](https://docs.didit.me/pt-br/core-technology/id-verification/digital-id-wallets.md). Cabe a você avaliar se um determinado esquema atende ao Artigo 22(6)(b) no seu caso de uso. A Didit é a integração que permite ao seu cliente usar a carteira; ela própria não é um prestador qualificado de serviços de confiança nem um esquema de eID.

### O que as normas técnicas preliminares dizem sobre a verificação remota

As normas técnicas de regulamentação (RTS) sobre due diligence do cliente previstas no Artigo 28(1) são elaboradas pela Autoridade Antilavagem de Dinheiro (AMLA). O relatório final da AMLA tem data de 30 de setembro de 2026 e foi anunciado em 1º de outubro de 2026. **Trata-se de um projeto final submetido à Comissão Europeia. Ele não foi adotado e não tem força de lei.** A Comissão ainda pode alterá-lo, e o projeto propõe que ele passe a ser aplicado seis meses após a entrada em vigor.

Esse projeto trata os dois meios do Artigo 22(6) como o padrão. A verificação remota com documento é uma solução alternativa para quando não se pode razoavelmente esperar que a pessoa apresente o documento presencialmente e ela não tem acesso a uma eID elegível (Artigo 7(1) do projeto). Se você usar a alternativa, o projeto exige que você consiga justificar o motivo e demonstrar à sua autoridade supervisora que a solução conta com salvaguardas (Artigos 7(2) e 7(3) do projeto). O projeto é tecnologicamente neutro: não menciona nenhuma técnica.

Como as salvaguardas do projeto se relacionam com o que uma sessão da Didit registra:

| Salvaguarda no projeto (Artigo 7(2)) | O que você pode usar na Didit |
| - | - |
| Controles para verificar se a pessoa que apresenta o documento é seu titular | Resultados de Prova de vida e Correspondência facial na sessão |
| Imagens, vídeo e dados com qualidade suficiente para identificar a pessoa | Verificações de qualidade da captura durante o fluxo, com avisos no relatório |
| Interromper quando houver dúvidas sobre a identidade ou a integridade do processo | Avisos e um status de sessão `"Declined"` ou `"In Review"` |
| Cópias mantidas, com carimbo de data e hora e disponíveis para verificação posterior | Registro da sessão, relatório em PDF e a sua [configuração de retenção](#mantenha-registros-e-depois-exclua) |

Cabe a você registrar o motivo pelo qual um cliente passou pelo caminho do documento em vez da eID. Armazene-o no seu próprio sistema ou anexe-o à sessão com `metadata` ao criá-la.

## Verificar empresas e beneficiários finais

Para uma pessoa jurídica, o Artigo 22(1)(b) exige a forma jurídica e a denominação, o endereço da sede social, os representantes legais e, quando disponíveis, o número de registro, o número de identificação fiscal e o Legal Entity Identifier. Você também deve identificar os beneficiários finais e adotar medidas razoáveis para verificá-los, de modo a compreender a estrutura de propriedade e de controle (Artigo 20(1)(b)). Um beneficiário final é uma pessoa física com propriedade direta ou indireta de "25 % ou mais" das ações, dos direitos de voto ou de outra participação societária (Artigo 52(1)), ou que controla a entidade por meio de propriedade ou de outros meios (Artigos 51 e 53). O controle é avaliado em paralelo à propriedade.

| Requisito | Recurso da Didit | Endpoint ou configuração |
| - | - | - |
| Identificar a pessoa jurídica e verificá-la em um registro | [Verificação de empresas (KYB)](https://docs.didit.me/pt-br/business-verification/overview.md) (conheça sua empresa, KYB) com consulta ao registro de empresas no nível Lite, Shareholders ou UBOs. A disponibilidade dos níveis varia conforme o país | [`POST /v3/session/`](https://docs.didit.me/pt-br/sessions-api/create-session) com um `workflow_id` de KYB. Consulte os [países compatíveis](https://docs.didit.me/pt-br/business-verification/supported-countries.md) |
| Identificar os beneficiários finais (UBOs) com 25 % ou mais | [Propriedade](https://docs.didit.me/pt-br/business-verification/ownership.md) obtida do registro quando disponível, confirmada e complementada pelo representante da empresa | Limiar de UBO em **Workflows**, no fluxo de KYB. Resultados em `key_people_checks[]` |
| Verificar a identidade de proprietários, diretores e representantes | Verificações de identidade vinculadas: cada [pessoa-chave](https://docs.didit.me/pt-br/business-verification/key-people.md) recebe uma sessão de verificação filha no fluxo que você escolher para cada função | Configurações por função em **Key People** no fluxo de KYB |
| Comparar o que consta no registro com o que o cliente declara (Art. 22(7), Art. 24) | Partes do registro e partes enviadas exibidas lado a lado | `key_people_checks[].registry` e `key_people_checks[].submitted` na decisão |
| Analisar a empresa, seus proprietários e seus controladores | [Análise AML](https://docs.didit.me/pt-br/business-verification/aml.md) de empresas e de pessoas | Etapa de AML no fluxo de KYB |

Quatro pontos a considerar no desenho:

* **Quem define o limiar é você.** O valor da AMLR é "25 % ou mais", e não "mais de 25 %". O limiar de UBO no fluxo é configurável, portanto ajuste-o para corresponder a esse valor e revise-o se a sua política for mais rigorosa.
* **Um registro, por si só, não basta.** O Artigo 22(7) exige que você consulte os registros centrais além de verificar os beneficiários finais. Comunicar uma divergência ao registro em até 14 dias corridos (Artigo 24) é sua responsabilidade.
* **Um resultado vazio no registro não prova que uma empresa não tem proprietários.** Um registro pode não ter nenhum dado de propriedade para uma empresa ou para um país. Se você não identificar nenhum beneficiário final, o Artigo 22(2) exige que você registre esse fato e, em vez disso, identifique e verifique os dirigentes de nível hierárquico superior.
* **O monitoramento de registros chegará em breve.** O monitoramento contínuo de alterações nos registros ainda não está disponível. Até lá, execute novamente a Verificação de empresas de acordo com o seu calendário de atualização.

## Triagem de sanções e PEPs

Você deve verificar se o cliente ou seus beneficiários finais estão sujeitos a sanções financeiras específicas e se pessoas sancionadas controlam um cliente pessoa jurídica ou detêm mais de 50 % dele (Artigo 20(1)(d)). Na AMLR, sanções financeiras específicas são as sanções da UE. Você também deve determinar se o cliente ou um beneficiário final é uma pessoa politicamente exposta (PEP), um familiar ou um associado próximo (Artigo 20(1)(g)). Para PEPs, o Artigo 42 acrescenta a aprovação da alta direção, medidas para estabelecer a origem do patrimônio e a origem dos recursos, e um monitoramento contínuo reforçado.

| Requisito | Recurso da Didit | Endpoint ou configuração |
| - | - | - |
| Fazer a triagem no onboarding | Etapa de [Análise AML](https://docs.didit.me/pt-br/core-technology/aml-screening/overview.md) no fluxo, com consulta a listas de sanções, de PEPs e de monitoramento | Etapa de AML e seus limiares no fluxo. Resultados em `aml_screenings[]` |
| Fazer a triagem sem um fluxo hospedado | Triagem avulsa de uma pessoa ou de uma empresa | [`POST /v3/aml/`](https://docs.didit.me/pt-br/standalone-apis/aml-screening) |
| Saber quais listas são cobertas | [Base de dados de listas de monitoramento](https://docs.didit.me/pt-br/core-technology/aml-screening/watchlist-database-aml-screening.md), que inclui a lista consolidada de sanções financeiras da UE | Página de referência |
| Registrar uma decisão sobre cada ocorrência | Revisão de ocorrências com um `review_status` por ocorrência | [`PATCH /v3/session/{sessionId}/update-aml-hit-status/`](https://docs.didit.me/pt-br/sessions-api/update-aml-hit-status) |
| Encaminhar correspondências de PEPs e de sanções a uma pessoa | Limiares que movem a sessão para `"In Review"` | Limiares de AML no fluxo e, em seguida, [revisão manual](https://docs.didit.me/pt-br/console/manual-review.md) |

```bash theme={null}
curl -X POST 'https://verification.didit.me/v3/aml/' \
  -H "x-api-key: $DIDIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "full_name": "Javier Ejemplo Modelo",
    "entity_type": "person",
    "date_of_birth": "1974-01-01",
    "nationality": "ES",
    "vendor_data": "user-1234"
  }'
```

Registrar uma ocorrência como `Confirmed Match` ou `False Positive` dispara um webhook `data.updated` e, por si só, não altera a decisão da sessão. A aprovação da alta direção para uma relação com um PEP é um processo seu: encaminhe a sessão para revisão e registre quem a aprovou.

## Monitorar continuamente e atualizar

O Artigo 26 exige o monitoramento contínuo da relação de negócios e informações atualizadas do cliente. O intervalo entre as atualizações não pode exceder 1 ano para clientes de risco mais alto e 5 anos para todos os demais clientes (Artigo 26(2)). Você também precisa atualizar as informações quando as circunstâncias do cliente mudam ou quando toma conhecimento de um fato relevante (Artigo 26(3)). As verificações de sanções precisam ser repetidas regularmente e, no caso de instituições de crédito e financeiras, a cada nova designação (Artigo 26(4)).

| Requisito | Recurso da Didit | Endpoint ou configuração |
| - | - | - |
| Reavaliar clientes em relação às listas de sanções e de PEP | [Monitoramento AML contínuo](https://docs.didit.me/pt-br/core-technology/aml-screening/continuous-monitoring-aml-screening.md) com nova análise diária | Ative na etapa de AML ou por perfil com [`POST /v3/users/aml-monitoring/`](https://docs.didit.me/pt-br/management-api/aml-monitoring/toggle-users) |
| Reavaliar empresas | Monitoramento AML contínuo para perfis de empresas | [`POST /v3/businesses/aml-monitoring/`](https://docs.didit.me/pt-br/management-api/aml-monitoring/toggle-businesses) |
| Ser avisado quando uma nova análise altera o resultado | Webhooks da sessão | `status.updated` quando o status muda, por exemplo para `"In Review"`, e `data.updated`. O payload inclui `trigger: "ongoing_monitoring"` |
| Comprovar que o monitoramento foi executado mesmo sem alterações | Data da última análise e histórico de análises | `last_ongoing_screening_at` no relatório de AML e a exportação do histórico de análises |
| Identificar documentos de identidade expirados | [Monitoramento de documentos](https://docs.didit.me/pt-br/core-technology/id-verification/document-monitoring-id-verification.md) | A sessão passa de `"Approved"` para `"Kyc Expired"` e um webhook `status.updated` é disparado |

```bash theme={null}
curl -X POST https://verification.didit.me/v3/users/aml-monitoring/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"is_enabled": true, "vendor_data_list": ["user-123", "user-456"]}'
```

Ativar ou desativar o monitoramento não emite nenhum webhook próprio. Com o monitoramento ativado, as novas análises disparam os eventos habituais `status.updated` e `data.updated`.

### Agende atualizações anuais e a cada 5 anos no seu próprio sistema

O prazo de atualização depende da classe de risco que você atribui, e essa decisão não pode ser terceirizada. A Didit não armazena a sua classe de risco nem agenda a atualização periódica por você.

**1. Armazene a classe de risco e a data da última atualização**

Mantenha essas informações no registro do cliente, junto ao `vendor_data` que você envia para a Didit.

**2. Execute uma tarefa agendada**

Selecione os clientes cuja última atualização seja mais antiga que o seu intervalo: no máximo 1 ano para risco mais alto e no máximo 5 anos para os demais. Esses são prazos máximos, portanto adotar um intervalo menor é uma escolha sua.

**3. Crie uma nova sessão**

Chame [`POST /v3/session/`](https://docs.didit.me/pt-br/sessions-api/create-session) com o mesmo `vendor_data` e seu fluxo de atualização e, em seguida, envie a `url` ao cliente.

**4. Reaja também a eventos**

Trate `"Kyc Expired"`, um webhook de monitoramento que move uma sessão para `"In Review"` e uma mudança informada pelo cliente como gatilhos para uma atualização antecipada.

## Finalidade e origem dos recursos

Antes de iniciar uma relação de negócios ou realizar uma transação ocasional, o Artigo 25 exige que você entenda a finalidade e a natureza pretendida. Quando necessário, você obtém informações sobre a finalidade e a justificativa econômica, o volume estimado de atividade, a origem dos recursos, o destino dos recursos e a atividade empresarial ou ocupação do cliente. "Quando necessário" significa que a abrangência é definida com base no risco. A diligência reforçada pode incluir a origem do patrimônio (Artigo 34(4)).

| Requisito | Recurso da Didit | Endpoint ou configuração |
| - | - | - |
| Coletar a finalidade e a atividade esperada | [Questionários](https://docs.didit.me/pt-br/core-technology/questionnaires/overview.md) com o modelo Finalidade da conta | Etapa de questionário no fluxo |
| Coletar a origem dos recursos com documentos comprobatórios | Modelo Origem dos recursos com envio de arquivos | Etapa de questionário no fluxo |
| Coletar a ocupação e o empregador | Modelo Dados de emprego | Etapa de questionário no fluxo |
| Garantir que uma pessoa leia todas as respostas | Questionário configurado para sempre resultar em `"In Review"` | Configuração de revisão manual no questionário |

Os modelos são um ponto de partida. Edite as perguntas de acordo com a sua avaliação de risco e mantenha as respostas na sessão, para que fiquem no mesmo registro que a verificação de identidade.

## Monitorar transações e reportar

O monitoramento contínuo abrange as transações realizadas durante a relação de negócios, para que permaneçam coerentes com o que você sabe sobre o cliente (Artigo 26(1)). Quando você sabe, suspeita ou tem motivos razoáveis para suspeitar que os recursos são produto de atividade criminosa ou estão relacionados ao financiamento do terrorismo, você deve reportar à sua Unidade de Inteligência Financeira (UIF), nos termos do Artigo 69.

| Requisito | Recurso da Didit | Endpoint ou configuração |
| - | - | - |
| Enviar cada transação para avaliação | [Monitoramento de transações](https://docs.didit.me/pt-br/transaction-monitoring/overview.md) para moeda fiduciária e cripto | [`POST /v3/transactions/`](https://docs.didit.me/pt-br/transaction-monitoring/transactions) |
| Aplicar os critérios de detecção que você aprovou | Pacotes de regras predefinidos e [regras](https://docs.didit.me/pt-br/transaction-monitoring/rules.md) personalizadas, cada uma com um modo que você controla | Regras no console ou na API de regras |
| Ser informado do veredito | Webhooks | `transaction.created` e `transaction.status.updated` |
| Investigar | [Alertas](https://docs.didit.me/pt-br/transaction-monitoring/alerts.md) e [casos](https://docs.didit.me/pt-br/transaction-monitoring/cases.md) com uma linha do tempo de cada ação | Gestão de casos no console |
| Preparar o relatório | [Preparação de relatórios para a UIF](https://docs.didit.me/pt-br/console/case-management/fiu-reports.md) a partir dos dados do caso | Aba **FIU reports** em um caso |

```bash theme={null}
curl -X POST https://verification.didit.me/v3/transactions/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "transaction_id": "finance0001",
    "transaction_category": "finance",
    "transaction_details": {
      "direction": "outbound",
      "amount": "1200.00",
      "currency": "EUR"
    },
    "subject": { "entity_type": "person", "vendor_data": "user-123", "full_name": "John Doe" },
    "counterparty": { "entity_type": "person", "full_name": "Jane Doe" }
  }'
```

Duas limitações a ter em mente:

* **Você aprova os critérios de detecção.** A aprovação dos critérios para detectar transações suspeitas ou incomuns não pode ser terceirizada (Artigo 18(3)(f)). Revise cada regra que você instala e registre essa aprovação nas suas próprias políticas.
* **Você envia o relatório.** A Didit prepara os arquivos do relatório a partir do caso. Ela não envia nada a nenhuma UIF. O envio é feito pelo seu responsável por conformidade, por meio do canal da sua UIF.

## Mantenha registros e depois exclua

O Artigo 77 estabelece o seu dever de manutenção de registros. Você mantém por 5 anos os documentos e as informações obtidos na diligência do cliente, os registros das suas avaliações de suspeita e os registros de transações. O prazo começa quando a relação de negócios termina, quando a transação ocasional é realizada ou quando você se recusa a iniciar a relação (Artigo 77(3)). Quando os 5 anos expiram, você exclui os dados pessoais, a menos que outra lei se aplique ou que uma autoridade peça que você mantenha registros específicos por mais tempo.

A contagem começa a partir de um evento no seu sistema: o fim da relação. A Didit não conhece essa data, portanto a retenção que você configura e as exclusões que você solicita são decisões suas.

| Requisito | Recurso da Didit | Endpoint ou configuração |
| - | - | - |
| Manter os registros de sessão pelo tempo que durar o seu dever | [Configuração de retenção](https://docs.didit.me/pt-br/console/data-retention.md): um período de 1 mês a 10 anos, ou ilimitado | **Business Console → App Settings → Data retention** |
| Excluir quando o seu prazo de 5 anos terminar | Exclusão sob demanda de uma sessão | [`DELETE /v3/session/{sessionId}/delete/`](https://docs.didit.me/pt-br/sessions-api/delete-session) |
| Entregar um arquivo a um supervisor ou auditor | Relatório em PDF por sessão e por usuário, exportação em CSV em massa | [`GET /v3/session/{sessionId}/generate-pdf/`](https://docs.didit.me/pt-br/sessions-api/generate-pdf), [exportações](https://docs.didit.me/pt-br/console/export-pdf-csv.md) |
| Manter as evidências da triagem | Exportação do histórico de triagem por sessão | [Evidências do monitoramento contínuo](https://docs.didit.me/pt-br/core-technology/aml-screening/continuous-monitoring-aml-screening.md#comprovando-que-o-monitoramento-rodou) |

**1. Escolha um período de retenção que não possa terminar antes da hora**

Uma sessão que chega ao fim do período é excluída. Escolha um período que cubra a duração das suas relações com clientes mais 5 anos, ou deixe-o ilimitado e exclua sob demanda.

**2. Registre o fim da relação**

Armazene a data de encerramento, da transação ou da recusa no seu próprio sistema. Essa data inicia a contagem do prazo de 5 anos.

**3. Exclua quando o prazo expirar**

Chame `DELETE /v3/session/{sessionId}/delete/` para cada sessão desse cliente. A exclusão é irreversível e as URLs de mídia deixam de funcionar.

> [!WARNING]
>
> **Os registros de auditoria e o histórico de triagem não cobrem, sozinhos, o dever de 5 anos.** Os registros de auditoria ficam disponíveis por 30 dias a 3 anos, dependendo do seu [plano](https://docs.didit.me/pt-br/console/audit-logs.md#retenção-de-dados), e as execuções de triagem no histórico ficam disponíveis por dois anos por padrão. Se a sua política de registros depende deles, exporte-os para os seus próprios registros antes do fim desses prazos. São os registros de sessão mantidos conforme a sua configuração de retenção que correspondem ao Artigo 77.

## Revisão humana de decisões automatizadas

O Artigo 76(5) permite que você adote decisões resultantes de processos automatizados, incluindo perfilamento e sistemas de IA, sob três condições. Os dados se limitam aos dados de devida diligência. Qualquer decisão de iniciar, recusar ou manter uma relação de negócios, de realizar ou recusar uma transação ocasional, ou de alterar a escopo da devida diligência está sujeita a uma intervenção humana significativa. E o cliente pode obter uma explicação da decisão e contestá-la.

| Requisito | Recurso da Didit | Endpoint ou configuração |
| - | - | - |
| Encaminhar casos para uma pessoa | Limiares e ramificações do fluxo que terminam em `"In Review"` | [Fluxos de verificação](https://docs.didit.me/pt-br/console/workflows.md) |
| Revisar as evidências e decidir | [Revisão manual](https://docs.didit.me/pt-br/console/manual-review.md) com um motivo de recusa e notas de revisão | Console, ou [`PATCH /v3/session/{sessionId}/update-status/`](https://docs.didit.me/pt-br/sessions-api/update-status) |
| Exigir um segundo revisor | [Revisão de quatro olhos](https://docs.didit.me/pt-br/console/case-management/four-eyes.md) em um modelo de caso: um responsável diferente aprova ou rejeita a resolução | Gestão de casos no console |
| Explicar o resultado | Resultados por verificação, avisos e comentários do revisor na sessão | [`GET /v3/session/{sessionId}/decision/`](https://docs.didit.me/pt-br/sessions-api/retrieve-session) |

```bash theme={null}
curl -X PATCH https://verification.didit.me/v3/session/4c5c7f3a-.../update-status/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "new_status": "Approved",
    "comment": "Cleared after manual review by compliance team"
  }'
```

O status da sessão `"Approved"` ou `"Declined"` é o resultado das verificações que você configurou. Ele subsidia sua decisão de realizar o onboarding, que, nos termos do Artigo 18(3), continua sendo sua responsabilidade. Decida com a sua assessoria jurídica em que momentos uma pessoa precisa intervir e, em seguida, incorpore essa etapa ao fluxo e ao seu próprio back office.

## Terceirização

O Artigo 18 permite que você terceirize tarefas decorrentes do AMLR para um prestador de serviços. Ele estabelece condições: você notifica sua autoridade supervisora antes de o prestador começar (Artigo 18(1)), você continua integralmente responsável pelas tarefas terceirizadas (Artigo 18(2)) e você define as condições em um contrato escrito e realiza controles regulares sobre o prestador (Artigo 18(4)). O regulamento também afirma que usar software de terceiros, ou acessar bancos de dados ou serviços de triagem, quando você mesmo cumpre o requisito, não constitui terceirização (considerando 47). O fato de seu uso da Didit constituir terceirização ou não depende de como você a utiliza. As diretrizes da AMLA sobre terceirização devem ser publicadas até 10 de julho de 2027.

Seis tarefas não podem ser terceirizadas em nenhuma circunstância (Artigo 18(3)). Elas permanecem com você:

1. A proposta e a aprovação da sua avaliação de risco de toda a empresa.
2. A aprovação das suas políticas, procedimentos e controles internos.
3. A decisão sobre o perfil de risco a atribuir ao cliente.
4. A decisão de iniciar uma relação de negócios ou realizar uma transação ocasional.
5. A comunicação de atividades suspeitas e os relatórios baseados em limiares à UIF.
6. A aprovação dos critérios para detectar transações e atividades suspeitas ou incomuns.

As tarefas relacionadas a elas podem ser delegadas: coletar dados de identidade, executar a verificação do documento ou da eID, reunir dados de propriedade efetiva e fazer consultas a registros, realizar a triagem em listas de sanções e de PEP, executar o monitoramento de transações com base em critérios que você aprovou e preparar alertas e evidências.

O que registrar sobre a Didit no seu registro de terceirizações:

| Item | O que registrar | Onde encontrar |
| - | - | - |
| Contrato por escrito (Art. 18(4)) | Seu contrato com a Didit e o acordo de processamento de dados | Peça ao seu representante da Didit o DPA e as medidas técnicas e organizacionais |
| Tarefas delegadas | As verificações em cada fluxo de verificação (workflow) que você executa, por versão do fluxo | [Fluxos de trabalho](https://docs.didit.me/pt-br/console/workflows.md). Sessões e webhooks incluem `workflow_id` e `workflow_version` |
| Tarefas que você mantém | As seis tarefas acima, com o responsável na sua organização | Suas próprias políticas |
| Qualificação do prestador (Art. 18(4)) | Certificações e atestações | [Certificações](https://docs.didit.me/pt-br/getting-started/certifications.md) |
| Localização dos dados | Os dados são processados e armazenados na UE por padrão. O processamento no próprio país está disponível no plano Enterprise | [Retenção de dados](https://docs.didit.me/pt-br/console/data-retention.md#papel-e-local-de-processamento) |
| Controles regulares (Art. 18(4)) | Sua amostragem de sessões, exportações e trilhas de revisão, com uma frequência proporcional à criticidade da tarefa | [Exportações](https://docs.didit.me/pt-br/console/export-pdf-csv.md), [registros de auditoria](https://docs.didit.me/pt-br/console/audit-logs.md) |
| Notificação à autoridade supervisora (Art. 18(1)) | A data em que você notificou sua autoridade supervisora, antes da entrada em produção | É sua responsabilidade. A notificação não implica que a autoridade supervisora aceite o arranjo |

## Fluxo de referência

Um ponto de partida para um fluxo de onboarding de pessoas físicas. Adapte-o à sua avaliação de risco.

**1. Crie o fluxo**

No Business Console, abra **Workflows** e crie um fluxo de KYC (conheça seu cliente). Use o construtor visual se precisar de ramificações por país ou por resultado.

**2. Escolha os métodos de identidade por país**

Na etapa **ID Verification**, ative as carteiras de identidade digital disponíveis nos países que você atende e use a captura de documento como caminho para todos os demais. Consulte [Métodos de verificação de identidade](https://docs.didit.me/pt-br/console/id-verification-methods.md).

**3. Vincule o documento à pessoa**

No caminho por documento, adicione **Liveness** e **Face Match**, e **NFC** quando o documento tiver chip.

**4. Verifique o endereço**

Adicione **Proof of Address** para clientes cujo documento não traga um endereço.

**5. Faça a triagem e o monitoramento**

Adicione **AML Screening**, defina os limiares que enviam uma correspondência para revisão e ative o monitoramento contínuo.

**6. Pergunte sobre a finalidade e a origem dos recursos**

Adicione um **Questionário** a partir dos modelos Purpose of Account e Source of Funds.

**7. Inscreva-se nos webhooks**

Crie um destino do webhook inscrito nos eventos `status.updated` e `data.updated`. Consulte [Webhooks](https://docs.didit.me/pt-br/integration/webhooks.md).

**8. Publique e copie o ID do fluxo**

Publique o fluxo e use o `workflow_id` dele ao criar sessões.

Crie uma sessão:

```bash theme={null}
curl -X POST https://verification.didit.me/v3/session/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "workflow_id": "YOUR_KYC_WORKFLOW_ID",
    "vendor_data": "user-42",
    "callback": "https://yourapp.com/callback"
  }'
```

Resposta (`201 Created`):

```json theme={null}
{
  "session_id": "4c5c7f3a-1f82-4f3b-8d8e-1a8d2d2f9b7a",
  "session_kind": "user",
  "session_number": 1024,
  "session_token": "...",
  "url": "https://verify.didit.me/session/...",
  "status": "Not Started",
  "workflow_id": "YOUR_KYC_WORKFLOW_ID",
  "vendor_data": "user-42"
}
```

Redirecione o cliente para `url`. Quando a sessão recebe uma decisão, a Didit envia um webhook `status.updated`. Um trecho:

```json theme={null}
{
  "event_id": "9c0c8b8a-1111-4222-9333-444444444444",
  "webhook_type": "status.updated",
  "timestamp": 1774970000,
  "created_at": 1774969994,
  "application_id": "11111111-2222-3333-4444-555555555555",
  "environment": "live",
  "session_id": "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee",
  "status": "In Review",
  "workflow_id": "66666666-7777-8888-9999-000000000000",
  "workflow_version": 4,
  "vendor_data": "user_42",
  "decision": { "...": "see /sessions-api/retrieve-session" }
}
```

Verifique a assinatura, use `event_id` como chave de idempotência e compare `status` como uma string exata, diferenciando maiúsculas de minúsculas. Os valores estão listados em [Status de verificação](https://docs.didit.me/pt-br/integration/verification-statuses.md). Em seguida, leia a decisão completa com `GET /v3/session/{sessionId}/decision/` e encaminhe-a à pessoa ou ao processo que toma a sua decisão de onboarding.

## Cronograma

| Data | O que acontece |
| - | - |
| 19 de junho de 2024 | O AMLR, Regulamento (UE) 2024/1624, é publicado no Jornal Oficial da União Europeia |
| 9 de julho de 2024 | O AMLR entra em vigor |
| 30 de setembro de 2026 | A AMLA data seu relatório final sobre os projetos de normas de diligência devida em relação ao cliente (anunciado em 1º de outubro de 2026). Submetido à Comissão, não adotado |
| 10 de julho de 2027 | O AMLR passa a ser aplicável. Prazo para os Estados-Membros transporem a sexta Diretiva Antilavagem de Dinheiro, Diretiva (UE) 2024/1640. As diretrizes da AMLA sobre terceirização devem ser emitidas |
| 2028 | A AMLA inicia a supervisão direta de entidades financeiras selecionadas. A primeira rodada é limitada a 40 |
| 10 de julho de 2029 | O AMLR passa a ser aplicável a agentes de futebol e clubes de futebol profissional |

## Perguntas frequentes

> [accordion] Quando o AMLR passa a ser aplicável?
>
> O AMLR entrou em vigor em 9 de julho de 2024 e será aplicável a partir de 10 de julho de 2027. Para agentes de futebol e clubes de futebol profissional, será aplicável a partir de 10 de julho de 2029. Até 10 de julho de 2027, aplicam-se as leis nacionais que transpõem a diretiva atual.

> [accordion] Qual é a diferença entre AMLR, AMLD6 e AMLA?
>
> O AMLR é o Regulamento (UE) 2024/1624. Ele reúne as regras para as entidades obrigadas e é diretamente aplicável, sem transposição nacional. A AMLD6 é a Diretiva (UE) 2024/1640. Ela é dirigida aos Estados-Membros e trata de supervisores, registros e sanções, com transposição prevista até 10 de julho de 2027. A AMLA é a Autoridade para o Combate ao Branqueamento de Capitais (Anti-Money Laundering Authority), criada pelo Regulamento (UE) 2024/1620 e sediada em Frankfurt. Ela elabora as normas técnicas e as orientações e supervisionará diretamente um grupo selecionado de entidades financeiras a partir de 2028.

> [accordion] A verificação remota com documento de identidade ainda é permitida?
>
> Sim, com condições. O Artigo 22(6) indica dois meios: um documento de identidade ou uma eID com nível de garantia substancial ou elevado. As normas finais em projeto da AMLA, de 30 de setembro de 2026, mantêm a verificação remota com documento como alternativa para quando não se pode razoavelmente esperar que a pessoa apresente o documento presencialmente e ela não tem acesso a uma eID qualificada. Você precisa ser capaz de justificar o uso desse meio e demonstrar as salvaguardas. O projeto não indica nenhuma técnica e ainda não é lei.

> [accordion] As normas técnicas são definitivas?
>
> Não. A AMLA finalizou seu projeto em 30 de setembro de 2026 e o enviou à Comissão Europeia. Ele só se torna vinculante quando a Comissão o adotar e ele for publicado no Jornal Oficial, e a Comissão pode alterá-lo. O projeto propõe ser aplicável seis meses após sua entrada em vigor, por isso ainda não há uma data no calendário.

> [accordion] Sou obrigado a aceitar a EUDI Wallet, e a Didit oferece suporte a ela?
>
> O próprio AMLR lista a eID como um dos dois meios de verificação. Ele não obriga toda entidade obrigada a aceitar a EUDI Wallet. O dever de aceitação está no regulamento eIDAS: as partes confiantes privadas que precisam usar autenticação forte do usuário para identificação online aceitam a carteira a pedido do usuário, no máximo 36 meses após a entrada em vigor dos atos de execução, e as micro e pequenas empresas estão isentas. Se isso abrange o seu onboarding é uma questão para o seu assessor jurídico. Na Didit, a EUDI Wallet está marcada como **Coming soon**. As carteiras disponíveis em produção hoje são MitID, BankID Sweden, Finnish Trust Network, Smart-ID e Mobile-ID.

> [accordion] O limiar de beneficiário final é de 25% ou de 15%?
>
> É de "25 % ou mais" das ações, dos direitos de voto ou de outra participação de propriedade (Artigo 52(1)), com o controle avaliado em paralelo. O Artigo 52(2) permite que a Comissão defina, por ato delegado, um limiar mais baixo, de no máximo 15 %, para categorias de entidades de risco mais elevado. Nenhum ato desse tipo existe. Na Didit, o limiar de UBO é uma configuração do seu fluxo de verificação (workflow) de KYB.

> [accordion] Como implementar a atualização de 1 ano e de 5 anos?
>
> Armazene a classe de risco do cliente e a data da última atualização no seu próprio sistema, execute uma tarefa agendada que selecione os clientes cuja última atualização exceda o intervalo definido e crie uma nova sessão com `POST /v3/session/` e o mesmo `vendor_data`. Adicione gatilhos por evento: um status `"Kyc Expired"`, um webhook de monitoramento ou uma alteração informada pelo cliente. Os prazos de 1 ano e de 5 anos do Artigo 26(2) são períodos máximos.

> [accordion] O que posso terceirizar?
>
> Tarefas como coletar dados de identidade, executar a verificação, consultar registros, fazer a triagem e executar o monitoramento de transações com base em critérios aprovados por você. Seis tarefas não podem ser terceirizadas: aprovar a avaliação de riscos de toda a empresa, aprovar as políticas internas, decidir o perfil de risco do cliente, decidir pelo onboarding, comunicar à UIF e aprovar os critérios de detecção. Você continua integralmente responsável pelo que terceiriza (Artigo 18(2)).

> [accordion] Como configurar a retenção para a regra dos 5 anos?
>
> Os 5 anos começam a contar quando a relação termina, não quando o cliente foi verificado. Em **Business Console → App Settings → Data retention**, escolha um período longo o bastante para cobrir a duração da relação mais 5 anos, ou deixe-o ilimitado. Registre a data de término no seu próprio sistema e chame `DELETE /v3/session/{sessionId}/delete/` quando o seu prazo expirar. Exporte os registros de auditoria e o histórico de triagem se a sua política de registros depender deles.

> [accordion] Usar a Didit me deixa em conformidade com o AMLR?
>
> Não. A conformidade é uma característica do seu programa: a sua avaliação de riscos, as suas políticas, as suas decisões e os seus controles. A Didit fornece as verificações, o monitoramento e as evidências de que essas partes do programa estão em funcionamento. Não existe certificação nem aprovação do AMLR para fornecedores ou ferramentas.

## Recursos relacionados

> [card] [Visão geral da solução AMLR](https://didit.me/solutions/amlr)
>
> A visão de negócio: a quem o AMLR se aplica e onde a Didit se encaixa.

> [card] [Métodos de verificação de identidade](https://docs.didit.me/pt-br/core-technology/id-verification/verification-methods.md)
>
> Captura de documentos, consulta sem documento e carteiras de identidade digital.

> [card] [Carteiras de identidade digital](https://docs.didit.me/pt-br/core-technology/id-verification/digital-id-wallets.md)
>
> Disponibilidade e nível de garantia por carteira.

> [card] [Verificação de empresas](https://docs.didit.me/pt-br/business-verification/overview.md)
>
> Consultas a registros de empresas, propriedade e pessoas-chave.

> [card] [Análise AML](https://docs.didit.me/pt-br/core-technology/aml-screening/overview.md)
>
> Triagem de sanções, PEPs e listas de monitoramento com monitoramento contínuo.

> [card] [Monitoramento de transações](https://docs.didit.me/pt-br/transaction-monitoring/overview.md)
>
> Regras, alertas, casos e preparação de relatórios para a UIF.

> [card] [Questionários](https://docs.didit.me/pt-br/core-technology/questionnaires/overview.md)
>
> Modelos para o propósito da relação de negócios e a origem dos recursos.

> [card] [Retenção de dados](https://docs.didit.me/pt-br/console/data-retention.md)
>
> Períodos de retenção e exclusão sob demanda.

> [card] [Webhooks](https://docs.didit.me/pt-br/integration/webhooks.md)
>
> Tipos de evento, payloads e verificação de assinatura.

> [card] [Preços](https://docs.didit.me/pt-br/getting-started/pricing.md)
>
> Pague por verificação. Veja o preço atual de cada recurso.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.