> ## 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 AML da UE 2024/1624

> Mapeie cada requisito do Regulamento AML da UE (AMLR) para os 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 diligência devida relativa à clientela (CDD) num único texto diretamente aplicável. Vincula instituições de crédito e financeiras, incluindo prestadores de serviços de criptoativos (CASPs), prestadores de serviços de jogos de fortuna ou azar e as restantes entidades obrigadas enumeradas no Artigo 3.º. Entrou em vigor a 9 de julho de 2024 e será aplicável a partir de 10 de julho de 2027. Até lá, continuam a aplicar-se as leis nacionais que transpõem a diretiva em vigor.

Esta página destina-se aos programadores e engenheiros de conformidade que têm de implementar estes requisitos. Cada secção indica o que o regulamento exige, apresenta o respetivo artigo e mostra o passo do fluxo da Didit, endpoint de API ou webhook que pode utilizar para essa parte. Para uma visão geral do negócio, consulte a [página de soluções 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. A sua empresa continua a ser a entidade obrigada.** É você quem decide o perfil de risco do cliente, se procede ao onboarding e quem mantém a responsabilidade integral por qualquer tarefa subcontratada (Artigo 18.º). O recurso à Didit não coloca, por si só, a sua empresa em conformidade com o AMLR. Esta página não constitui aconselhamento jurídico: confirme junto da sua assessoria jurídica e do seu supervisor como cada regra se aplica à sua atividade.

## O que o AMLR exige em resumo

| Obrigação | Artigo | Onde se encontra na Didit |
| - | - | - |
| Saber quando a diligência devida é acionada | Art. 19.º | A sua própria lógica de encaminhamento e, em seguida, uma sessão por acionador. Consulte [Quando a diligência devida se aplica](#quando-a-diligência-devida-se-aplica) |
| Identificar o cliente e verificar a sua identidade | Art. 20.º(1)(a), Art. 22.º | Verificação de identidade com carteiras de identidade digitais ou captura de documentos. Consulte [Identificar e verificar pessoas](#identificar-e-verificar-pessoas) |
| Identificar beneficiários efetivos 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 efetivos](#verificar-empresas-e-beneficiários-efetivos) |
| Verificar sanções e pessoas politicamente expostas | Art. 20.º(1)(d) e (g), Art. 42.º | Triagem AML. Consulte [Verificar sanções e PEPs](#fazer-triagem-de-sanções-e-peps) |
| Monitorizar a relação e manter os dados do cliente atualizados | Art. 26.º | Monitorização AML contínua e expiração de documentos. Consulte [Monitorizar continuamente e atualizar](#monitorizar-de-forma-contínua-e-atualizar) |
| Compreender o propósito da relação e, se necessário, a origem dos fundos | Art. 25.º | Questionários. Consulte [Propósito e origem dos fundos](#finalidade-e-origem-dos-fundos) |
| Monitorizar transações e comunicar suspeitas | Art. 26.º(1), Art. 69.º | Monitorização de transações e gestão de casos. Consulte [Monitorizar transações e comunicar](#monitorizar-transações-e-comunicar) |
| Conservar registos durante 5 anos e, em seguida, eliminar dados pessoais | Art. 77.º | Definição de conservação, exportações e eliminação a pedido. Consulte [Conservar registos e depois eliminar](#conservar-registos-e-depois-eliminar) |
| Incluir intervenção humana em decisões automatizadas | Art. 76.º(5) | Revisão manual e atualizações de estado. Consulte [Revisão humana de decisões automatizadas](#revisão-humana-de-decisões-automatizadas) |
| Gerir o que subcontrata | Art. 18.º | O seu registo de subcontratação. Consulte [Subcontratação](#subcontratação) |

## Fluxo de ponta a ponta

O seu backend cria uma sessão, o utilizador conclui o fluxo, a Didit notifica-o e você obtém a decisão completa. A decisão de onboarding permanece a cargo da sua equipa. A monitorização 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 diligência devida se aplica

O Artigo 19.º define quando deve aplicar a diligência devida relativa à clientela: ao estabelecer uma relação de negócio; para uma transação ocasional de montante igual ou superior a 10.000 EUR, numa única operação ou em transações ligadas entre si; quando houver suspeita de branqueamento de capitais ou de financiamento do terrorismo, independentemente do montante; e quando houver dúvidas sobre os dados de identificação que já possui. Aplicam-se limiares mais baixos em determinados setores: 1.000 EUR para transferências ocasionais de fundos e para CASPs, 3.000 EUR para transações ocasionais em numerário (pelo menos a identificação e a verificação) e 2.000 EUR em jogos de fortuna ou azar. Um CASP deve, no mínimo, identificar e verificar o cliente para qualquer transação ocasional abaixo de 1.000 EUR.

A Didit não decide se um acionador se aplica. Você encaminha por tipo de transação e montante no seu próprio código e, em seguida, inicia o fluxo correspondente.

| Requisito | Funcionalidade da Didit | Endpoint ou definição |
| - | - | - |
| Iniciar diligência devida para uma nova relação de negócio (Art. 19.º(1)(a)) | Sessão de verificação no seu fluxo de onboarding | [`POST /v3/session/`](https://docs.didit.me/pt/sessions-api/create-session) |
| Iniciar diligência devida quando uma transação ocasional atinge ou ultrapassa o seu limiar (Art. 19.º(1)(b), 19.º(2) a 19.º(5)) | Sessão de verificação no fluxo escolhido para esse acionador | [`POST /v3/session/`](https://docs.didit.me/pt/sessions-api/create-session) com o `workflow_id` correspondente |
| Detetar transações ligadas que, em conjunto, atingem ou ultrapassam um limiar | Regras de velocidade na Monitorização de transações | [`POST /v3/transactions/`](https://docs.didit.me/pt/transaction-monitoring/transactions), [regras](https://docs.didit.me/pt/transaction-monitoring/rules.md) |
| Solicitar verificação ao cliente antes de liquidar uma transação sinalizada | Uma ação de regra altera a transação para `AWAITING_USER` e é criada uma sessão de verificação associada | [Estados de transação](https://docs.didit.me/pt/transaction-monitoring/statuses.md) |

Um esboço mínimo de encaminhamento para o seu backend. Não abrange todos os acionadores do Artigo 19.º (por exemplo, a participação na criação de uma pessoa coletiva), e as regras setoriais aplicáveis à sua atividade 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) enumera os dados que deve deter sobre uma pessoa singular: todos os nomes e apelidos, local de nascimento e data completa de nascimento, 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. O Artigo 22(6) indica de seguida dois meios de verificação da identidade: um documento de identificação, passaporte ou equivalente, ou identificação eletrónica (eID) que cumpra os níveis de garantia "substancial" ou "elevado" do eIDAS, juntamente com os serviços de confiança qualificados relevantes.

### Pontos de dados em relação à decisão

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

| Ponto de dados do Artigo 22(1)(a) | Campo em `id_verifications[]` | Notas |
| - | - | - |
| Todos os nomes e apelidos | `first_name`, `last_name`, `full_name` | Tal como constam no documento ou conforme devolvidos pela carteira |
| Local de nascimento e data completa de nascimento | `place_of_birth`, `date_of_birth` | O local de nascimento está presente quando consta no documento |
| Nacionalidades | `nationality` | Registe nacionalidades adicionais declaradas pelo cliente no seu próprio sistema |
| 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/core-technology/id-verification/report-id-verification.md) |
| Local de residência habitual | `address`, `formatted_address`, `parsed_address` | Os passaportes raramente contêm morada. Adicione o [Comprovativo de morada](https://docs.didit.me/pt/core-technology/proof-of-address/overview.md) ou uma [validação de base de dados](https://docs.didit.me/pt/core-technology/database-validation/overview.md) quando o documento não a tiver |
| Número de identificação fiscal, quando disponível | `extra_fields.tax_number` | Apenas quando consta no documento. Caso contrário, recolha-o através de um [questionário](https://docs.didit.me/pt/core-technology/questionnaires/overview.md) |

### As duas vias

| Requisito | Funcionalidade Didit | Endpoint ou definição |
| - | - | - |
| Verificar com identificação eletrónica (Art. 22(6)(b)) | [Carteiras de identidade digital](https://docs.didit.me/pt/core-technology/id-verification/digital-id-wallets.md). Disponível em produção: MitID (Dinamarca), BankID Suécia, Finnish Trust Network (Finlândia), Smart-ID (Estónia, Letónia, Lituânia, Bélgica) e Mobile-ID (Estónia, Lituânia). European Digital Identity (EUDI) Wallet: **Em breve** | Configure os métodos por país no [passo de Verificação de identidade](https://docs.didit.me/pt/console/id-verification-methods.md). O resultado indica `verification_method` e `wallet_provider` |
| Verificar com um documento de identificação (Art. 22(6)(a)) | [Captura de documentos](https://docs.didit.me/pt/core-technology/id-verification/overview.md) com verificações de autenticidade e [leitura de chip NFC](https://docs.didit.me/pt/core-technology/nfc-verification/overview.md) para passaportes eletrónicos e e-IDs. Para utilização remota, consulte o projeto de normas abaixo | Passos de Verificação de identidade e NFC no fluxo |
| Verificar se a pessoa que apresenta o documento é o seu titular | [Prova de vida](https://docs.didit.me/pt/core-technology/liveness/overview.md) e [Correspondência facial](https://docs.didit.me/pt/core-technology/face-match/overview.md) com a foto do documento | Passos de Prova de vida e Correspondência facial. Resultados em `liveness_checks[]` e `face_matches[]` |
| Conservar comprovativos para revisão posterior | Registo da sessão com imagens, dados extraídos e carimbos de data/hora | [`GET /v3/session/{sessionId}/generate-pdf/`](https://docs.didit.me/pt/sessions-api/generate-pdf), [exportar](https://docs.didit.me/pt/console/export-pdf-csv.md) |

O nível de garantia comunicado por cada carteira está listado na página de [Carteiras de identidade digital](https://docs.didit.me/pt/core-technology/id-verification/digital-id-wallets.md). Avaliar se um determinado esquema cumpre o Artigo 22(6)(b) para o seu caso de utilização cabe a si. A Didit é a integração que permite ao seu cliente utilizar a carteira; não é, por si só, um prestador qualificado de serviços de confiança nem um esquema de eID.

### O que o projeto de normas técnicas diz sobre a verificação remota

As normas técnicas de regulamentação (RTS) relativas à diligência devida quanto à clientela ao abrigo do Artigo 28(1) são elaboradas pela Autoridade de Combate ao Branqueamento de Capitais (AMLA). O relatório final da AMLA data de 30 de setembro de 2026 e foi anunciado a 1 de outubro de 2026. **Trata-se de uma versão final do projeto submetida à Comissão Europeia. Não foi adotada e não é lei.** A Comissão pode ainda alterá-la, e o projeto propõe que seja aplicável seis meses após a sua entrada em vigor.

Esse projeto considera os dois meios do Artigo 22(6) como o padrão. A verificação remota com um documento é uma solução alternativa para quando não se pode razoavelmente esperar que a pessoa apresente o documento presencialmente e esta não tenha acesso a um eID que cumpra os requisitos (projeto do Artigo 7(1)). Se utilizar a alternativa, o projeto pede-lhe que consiga justificar o motivo e demonstrar à autoridade de supervisão que a solução dispõe de salvaguardas (projeto do Artigo 7(2) e 7(3)). O projeto é tecnologicamente neutro: não especifica qualquer técnica.

Como as salvaguardas do projeto se articulam com o que uma sessão Didit regista:

| Salvaguarda no projeto (Artigo 7(2)) | O que pode utilizar na Didit |
| - | - |
| Controlos para verificar que a pessoa que apresenta o documento é o titular do documento | 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 de captura durante o fluxo, com avisos no relatório |
| Interromper quando existirem dúvidas sobre a identidade ou a integridade do processo | Avisos e um estado de sessão `"Declined"` ou `"In Review"` |
| Cópias conservadas, com carimbo de data/hora e disponíveis para verificação posterior | Registo da sessão, relatório em PDF e a sua [definição de conservação](#conservar-registos-e-depois-eliminar) |

O motivo pelo qual um cliente seguiu a via de documentos em vez do eID deve ser registado por si. Guarde-o no seu próprio sistema ou anexe-o à sessão através de `metadata` aquando da sua criação.

## Verificar empresas e beneficiários efetivos

Para uma entidade 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 registo, o número de identificação fiscal e o Identificador de Entidade Jurídica (LEI). Deve também identificar os beneficiários efetivos e adotar medidas razoáveis para os verificar, de modo a compreender a estrutura de propriedade e controlo (Artigo 20(1)(b)). Um beneficiário efetivo é uma pessoa singular que detém direta ou indiretamente "25 % ou mais" das ações, direitos de voto ou outra participação no capital (Artigo 52(1)), ou que controla a entidade através de propriedade ou outros meios (Artigos 51 e 53). O controlo é avaliado em paralelo com a propriedade.

| Requisito | Funcionalidade Didit | Endpoint ou definição |
| - | - | - |
| Identificar a entidade jurídica e verificá-la num registo | [Verificação de empresas](https://docs.didit.me/pt/business-verification/overview.md) (know your business, KYB) com consulta do registo de empresas no nível Lite, Shareholders ou UBOs. A disponibilidade do nível varia consoante o país | [`POST /v3/session/`](https://docs.didit.me/pt/sessions-api/create-session) com um `workflow_id` de KYB. Consulte os [países suportados](https://docs.didit.me/pt/business-verification/supported-countries.md) |
| Identificar os beneficiários efetivos finais (UBOs) com 25 % ou mais | [Propriedade](https://docs.didit.me/pt/business-verification/ownership.md) a partir do registo, quando disponível, confirmada e complementada pelo representante da empresa | Limiar de UBO em **Fluxos**, no fluxo de KYB. Resultados em `key_people_checks[]` |
| Verificar a identidade de proprietários, administradores e representantes | Verificações de identidade associadas: cada [pessoa-chave](https://docs.didit.me/pt/business-verification/key-people.md) obtém uma sessão de verificação filha no fluxo que escolher por função | Definições por função em **Pessoas-chave** no fluxo de KYB |
| Comparar o que consta no registo com o que o cliente declara (Art. 22(7), Art. 24) | Partes do registo e partes submetidas apresentadas lado a lado | `key_people_checks[].registry` e `key_people_checks[].submitted` na decisão |
| Realizar a triagem da empresa, dos seus proprietários e de quem a controla | [Triagem AML](https://docs.didit.me/pt/business-verification/aml.md) da empresa e de pessoas | Passo de AML no fluxo de KYB |

Quatro pontos a ter em conta no desenho da solução:

* **A definição do limiar cabe-lhe a si.** O valor previsto no AMLR é "25 % ou mais", e não "mais de 25 %". O limiar de UBO no fluxo é configurável, pelo que deve defini-lo em conformidade e revê-lo se a sua política for mais rigorosa.
* **Um registo não é suficiente por si só.** O Artigo 22(7) exige que consulte os registos centrais além de verificar os beneficiários efetivos. Comunicar uma discrepância ao registo no prazo de 14 dias de calendário (Artigo 24) é uma etapa da sua responsabilidade.
* **Um resultado vazio do registo não é prova de que uma empresa não tem proprietários.** Um registo pode não conter qualquer registo de propriedade para uma empresa ou país. Se não identificar nenhum beneficiário efetivo, o Artigo 22(2) exige que registe esse facto e identifique e verifique, em alternativa, os membros da direção de topo.
* **A monitorização de registos estará disponível em breve.** A monitorização contínua de alterações nos registos ainda não está disponível. Até que esteja, volte a executar a Verificação de empresas de acordo com o seu calendário de atualização.

## Fazer triagem de sanções e PEPs

Deve verificar se o cliente ou os seus beneficiários efetivos estão sujeitos a sanções financeiras específicas, e se pessoas sancionadas controlam um cliente que seja entidade jurídica ou detêm mais de 50 % da entidade (Artigo 20(1)(d)). No AMLR, sanções financeiras específicas significam sanções da UE. Deve também determinar se o cliente ou um beneficiário efetivo é uma pessoa politicamente exposta (PEP), um membro da família ou um associado próximo (Artigo 20(1)(g)). Para as PEPs, o Artigo 42 acrescenta a aprovação da direção de topo, medidas para determinar a origem da riqueza e a origem dos fundos, e uma monitorização contínua reforçada.

| Requisito | Funcionalidade Didit | Endpoint ou definição |
| - | - | - |
| Fazer a triagem no onboarding | Passo de [Triagem AML](https://docs.didit.me/pt/core-technology/aml-screening/overview.md) no fluxo, face a sanções, PEP e listas de vigilância | Passo de AML e respetivos limiares no fluxo. Resultados em `aml_screenings[]` |
| Fazer a triagem sem um fluxo alojado | Triagem autónoma de uma pessoa ou empresa | [`POST /v3/aml/`](https://docs.didit.me/pt/standalone-apis/aml-screening) |
| Saber quais as listas abrangidas | [Base de dados de listas de vigilância](https://docs.didit.me/pt/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 |
| Registar uma decisão sobre cada ocorrência | Revisão de correspondências com um `review_status` por correspondência | [`PATCH /v3/session/{sessionId}/update-aml-hit-status/`](https://docs.didit.me/pt/sessions-api/update-aml-hit-status) |
| Enviar correspondências de PEP e de sanções para uma pessoa | Limiares que fazem a sessão passar para `"In Review"` | Limiares de AML no fluxo e, em seguida, [revisão manual](https://docs.didit.me/pt/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"
  }'
```

Registar uma correspondência como `Confirmed Match` ou `False Positive` aciona um webhook `data.updated` e não altera a decisão da sessão por si só. A aprovação da direção de topo para uma relação com uma PEP é da sua responsabilidade: encaminhe a sessão para revisão e registe quem a aprovou.

## Monitorizar de forma contínua e atualizar

O Artigo 26 exige a monitorização contínua da relação de negócio e informações atualizadas sobre o cliente. O período entre atualizações não deve exceder 1 ano para clientes de maior risco e 5 anos para todos os restantes clientes (Artigo 26(2)), devendo também atualizar quando as circunstâncias do cliente mudarem ou quando tomar conhecimento de um facto relevante (Artigo 26(3)). As verificações de sanções têm de ser repetidas regularmente e, no caso de instituições de crédito e financeiras, perante qualquer nova designação (Artigo 26(4)).

| Requisito | Funcionalidade Didit | Endpoint ou definição |
| - | - | - |
| Fazer nova triagem de clientes contra listas de sanções e PEP | [Monitorização AML contínua](https://docs.didit.me/pt/core-technology/aml-screening/continuous-monitoring-aml-screening.md) com nova triagem diária | Ative-a no passo de AML, ou por perfil com [`POST /v3/users/aml-monitoring/`](https://docs.didit.me/pt/management-api/aml-monitoring/toggle-users) |
| Fazer nova triagem de empresas | Monitorização AML contínua para perfis de empresas | [`POST /v3/businesses/aml-monitoring/`](https://docs.didit.me/pt/management-api/aml-monitoring/toggle-businesses) |
| Ser notificado quando uma nova triagem altera o resultado | Webhooks na sessão | `status.updated` quando o estado muda, por exemplo para `"In Review"`, e `data.updated`. O payload inclui `trigger: "ongoing_monitoring"` |
| Comprovar que a monitorização foi executada quando nada mudou | Data da última triagem e histórico de triagens | `last_ongoing_screening_at` no relatório de AML e a exportação do histórico de triagens |
| Detetar documentos de identificação expirados | [Monitorização de documentos](https://docs.didit.me/pt/core-technology/id-verification/document-monitoring-id-verification.md) | A sessão passa de `"Approved"` para `"Kyc Expired"` e é acionado um webhook `status.updated` |

```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 a monitorização não emite nenhum webhook próprio. Uma vez ativada a monitorização, as novas triagens acionam os habituais eventos `status.updated` e `data.updated`.

### Agendar a atualização de 1 e 5 anos no seu próprio sistema

O prazo de atualização depende da classe de risco que atribuir, e essa decisão não pode ser externalizada. A Didit não guarda a sua classe de risco e não agenda a atualização periódica por si.

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

Mantenha-as no registo do seu cliente, junto ao `vendor_data` que envia para a Didit.

**2. Executar uma tarefa agendada**

Selecione os clientes cuja última atualização ocorreu há mais tempo do que o seu intervalo: no máximo 1 ano para risco mais elevado, no máximo 5 anos para os restantes. Estes são períodos máximos, pelo que um intervalo mais curto fica ao seu critério.

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

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

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

Trate `"Kyc Expired"`, um webhook de monitorização que mude uma sessão para `"In Review"`, e uma alteração comunicada pelo cliente como acionadores para uma atualização antecipada.

## Finalidade e origem dos fundos

Antes de estabelecer uma relação de negócio ou realizar uma transação ocasional, o Artigo 25 exige que compreenda a sua finalidade e a natureza pretendida. Quando necessário, obtém informações sobre a finalidade e a justificação económica, o volume estimado de atividade, a origem dos fundos, o destino dos fundos e a atividade comercial ou profissão do cliente. "Quando necessário" significa que a extensão se baseia no risco. A diligência reforçada pode acrescentar a origem da riqueza (Artigo 34(4)).

| Requisito | Funcionalidade Didit | Endpoint ou definição |
| - | - | - |
| Recolher a finalidade e a atividade prevista | [Questionários](https://docs.didit.me/pt/core-technology/questionnaires/overview.md) com o modelo Purpose of Account | Passo de questionário no fluxo |
| Recolher a origem dos fundos com documentos comprovativos | Modelo Source of Funds com carregamento de ficheiros | Passo de questionário no fluxo |
| Recolher a profissão e o empregador | Modelo Employment Details | Passo de questionário no fluxo |
| Ter uma pessoa a ler cada resposta | Questionário configurado para resultar sempre em `"In Review"` | Definição de revisão manual no questionário |

Os modelos são um ponto de partida. Edite as perguntas para corresponderem à sua avaliação de risco e mantenha as respostas associadas à sessão para que fiquem no mesmo registo da verificação de identidade.

## Monitorizar transações e comunicar

A monitorização contínua abrange as transações realizadas durante a relação, para que permaneçam coerentes com o que sabe sobre o cliente (Artigo 26(1)). Quando souber, suspeitar ou tiver motivos razoáveis para suspeitar de que os fundos provêm de atividades criminosas ou estão relacionados com o financiamento do terrorismo, deve comunicar à sua Unidade de Informação Financeira (UIF) ao abrigo do Artigo 69.

| Requisito | Funcionalidade Didit | Endpoint ou definição |
| - | - | - |
| Submeter cada transação para avaliação | [Monitorização de transações](https://docs.didit.me/pt/transaction-monitoring/overview.md) para moedas fiduciárias e cripto | [`POST /v3/transactions/`](https://docs.didit.me/pt/transaction-monitoring/transactions) |
| Aplicar critérios de deteção aprovados por si | Conjuntos de regras predefinidos e [regras](https://docs.didit.me/pt/transaction-monitoring/rules.md) personalizadas, cada uma com um modo que controla | Regras na consola ou a API de regras |
| Ser notificado do veredito | Webhooks | `transaction.created` e `transaction.status.updated` |
| Investigar | [Alertas](https://docs.didit.me/pt/transaction-monitoring/alerts.md) e [casos](https://docs.didit.me/pt/transaction-monitoring/cases.md) com uma cronologia de cada ação | Gestão de casos na consola |
| Preparar o relatório | [Preparação de relatórios UIF](https://docs.didit.me/pt/console/case-management/fiu-reports.md) a partir dos dados do caso | Separador **Relatórios UIF** num 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" }
  }'
```

Dois limites a ter em conta:

* **Aprove os critérios de deteção.** A aprovação dos critérios para detetar transações suspeitas ou invulgares não pode ser externalizada (Artigo 18(3)(f)). Reveja cada regra que instalar e registe essa aprovação nas suas próprias políticas.
* **Submeta o relatório.** A Didit prepara os ficheiros de relatório a partir do caso. Não submete nada a uma UIF. A submissão é efetuada pelo seu responsável pela conformidade através do canal da sua UIF.

## Conservar registos e depois eliminar

O Artigo 77.º estabelece o seu dever de conservação de registos. Deve conservar os documentos e as informações obtidas para a devida diligência quanto à clientela, os registos das suas avaliações de suspeitas e os registos de transações durante 5 anos. O período tem início quando a relação de negócio termina, quando a transação ocasional é realizada ou quando recusa estabelecer a relação (Artigo 77.º, n.º 3). Quando os 5 anos terminam, elimina os dados pessoais, a menos que outra lei se aplique ou que uma autoridade lhe solicite a conservação de registos 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, pelo que a retenção que configurar e as eliminações que solicitar são decisões suas.

| Requisito | Funcionalidade Didit | Endpoint ou definição |
| - | - | - |
| Conservar os registos de sessão durante o tempo em que o seu dever vigorar | [Definição de retenção](https://docs.didit.me/pt/console/data-retention.md): uma janela de 1 mês a 10 anos, ou ilimitada | **Business Console → App Settings → Data retention** |
| Eliminar quando o seu período de 5 anos terminar | Eliminação a pedido de uma sessão | [`DELETE /v3/session/{sessionId}/delete/`](https://docs.didit.me/pt/sessions-api/delete-session) |
| Entregar um ficheiro a um supervisor ou a um auditor | Relatório em PDF por sessão e por utilizador, exportação CSV em massa | [`GET /v3/session/{sessionId}/generate-pdf/`](https://docs.didit.me/pt/sessions-api/generate-pdf), [exportações](https://docs.didit.me/pt/console/export-pdf-csv.md) |
| Conservar as provas de triagem | Exportação do histórico de triagem por sessão | [Provas de monitorização contínua](https://docs.didit.me/pt/core-technology/aml-screening/continuous-monitoring-aml-screening.md#comprovar-a-execução-da-monitorização) |

**1. Escolha uma janela de retenção que não possa terminar antes do tempo**

Uma sessão atinge o fim da janela e é eliminada. Escolha uma janela que cubra a duração das suas relações com os clientes mais 5 anos, ou deixe-a como ilimitada e elimine a pedido.

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

Guarde a data de rescisão, de transação ou de recusa no seu próprio sistema. Essa data dá início aos seus 5 anos.

**3. Elimine quando o período expirar**

Chame `DELETE /v3/session/{sessionId}/delete/` para cada sessão desse cliente. A eliminação é irreversível e os URLs de ficheiros multimédia deixam de funcionar.

> [!WARNING]
>
> **Os registos de auditoria e o histórico de triagem não cobrem o dever de 5 anos por si só.** Os registos de auditoria estão disponíveis entre 30 dias e 3 anos, consoante o seu [plano](https://docs.didit.me/pt/console/audit-logs.md#conservação-de-dados), e as execuções do histórico de triagem estão disponíveis durante dois anos por predefinição. Se a sua política de registos depender deles, exporte-os para os seus próprios registos antes de esses períodos terminarem. Os registos de sessão sob a sua definição de retenção são os que correspondem ao Artigo 77.º.

## Revisão humana de decisões automatizadas

O Artigo 76.º, n.º 5, permite-lhe adotar decisões que resultem de processos automatizados, incluindo a criação de perfis e sistemas de IA, sob três condições. Os dados limitam-se a dados relativos à devida diligência. Qualquer decisão de estabelecer, recusar ou manter uma relação de negócio, de realizar ou recusar uma transação ocasional, ou de alterar a extensão da devida diligência está sujeita a uma intervenção humana significativa. E o cliente pode obter uma justificação da decisão e contestá-la.

| Requisito | Funcionalidade Didit | Endpoint ou definição |
| - | - | - |
| Enviar casos para uma pessoa | Limiares e ramificações de fluxo que terminam em `"In Review"` | [Fluxos](https://docs.didit.me/pt/console/workflows.md) |
| Rever as provas e decidir | [Revisão manual](https://docs.didit.me/pt/console/manual-review.md) com um motivo de recusa e notas de revisão | Consola, ou [`PATCH /v3/session/{sessionId}/update-status/`](https://docs.didit.me/pt/sessions-api/update-status) |
| Exigir um segundo revisor | [Revisão por quatro olhos](https://docs.didit.me/pt/console/case-management/four-eyes.md) num modelo de caso: um responsável diferente aprova ou rejeita a resolução | Gestão de casos na consola |
| Justificar 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/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"
  }'
```

Um estado de sessão `"Approved"` ou `"Declined"` é o resultado das verificações que configurou. Trata-se de um elemento que alimenta a sua decisão de onboarding, a qual o Artigo 18.º, n.º 3, mantém sob a sua responsabilidade. Decida com a sua assessoria jurídica onde uma pessoa tem de intervir e, em seguida, incorpore esse passo no fluxo e no seu próprio sistema interno.

## Subcontratação

O Artigo 18.º permite-lhe subcontratar a um prestador de serviços tarefas resultantes do AMLR. Estabelece condições: notificar a sua autoridade de supervisão antes de o prestador iniciar funções (Artigo 18.º, n.º 1), permanecer plenamente responsável pelas tarefas subcontratadas (Artigo 18.º, n.º 2), estipular as condições num contrato por escrito e realizar controlos regulares ao prestador (Artigo 18.º, n.º 4). O regulamento também estabelece que a utilização de software de terceiros, ou o acesso a bases de dados ou a serviços de triagem, em que o próprio sujeito obrigado executa a obrigação, não constitui subcontratação (considerando 47). A forma como a sua utilização da Didit se enquadra depende da forma como a utiliza. Está prevista a publicação das orientações da AMLA sobre subcontratação até 10 de julho de 2027.

Seis tarefas não podem ser subcontratadas em circunstância alguma (Artigo 18.º, n.º 3). Permanecem consigo:

1. A proposta e aprovação da sua avaliação de risco a nível de toda a empresa.
2. A aprovação das suas políticas, procedimentos e controlos internos.
3. A decisão sobre o perfil de risco a atribuir ao cliente.
4. A decisão de estabelecer uma relação de negócio ou realizar uma transação ocasional.
5. A comunicação de atividades suspeitas e comunicações baseadas em limiares à UIF.
6. A aprovação dos critérios para deteção de transações e atividades suspeitas ou invulgares.

As tarefas relacionadas com estas podem ser delegadas: recolha de dados de identidade, execução da verificação de documentos ou de eID, recolha de dados de beneficiários efetivos e consultas a registos, triagem contra listas de sanções e PEPs, execução da monitorização de transações de acordo com os critérios que aprovou, e preparação de alertas e provas.

O que deve incluir no seu registo de subcontratação sobre a Didit:

| Item | O que registar | Onde encontrar |
| - | - | - |
| Contrato escrito (Art. 18.º, n.º 4) | O seu contrato com a Didit e o acordo de tratamento de dados | Solicite ao seu representante da Didit o DPA e as medidas técnicas e organizativas |
| Tarefas delegadas | As verificações em cada fluxo executado, por versão de fluxo | [Fluxos](https://docs.didit.me/pt/console/workflows.md). As sessões e os webhooks contêm `workflow_id` e `workflow_version` |
| Tarefas retidas | As seis tarefas acima referidas, com o responsável na sua organização | As suas próprias políticas |
| Qualificação do prestador (Art. 18.º, n.º 4) | Certificações e atestações | [Certificações](https://docs.didit.me/pt/getting-started/certifications.md) |
| Localização dos dados | Os dados são processados e armazenados na UE por predefinição. O processamento no próprio país está disponível no plano Enterprise | [Conservação de dados](https://docs.didit.me/pt/console/data-retention.md#função-e-local-de-tratamento) |
| Controlos regulares (Art. 18.º, n.º 4) | A sua amostragem de sessões, exportações e registos de revisão, com uma frequência adequada ao grau de criticidade da tarefa | [Exportações](https://docs.didit.me/pt/console/export-pdf-csv.md), [registos de auditoria](https://docs.didit.me/pt/console/audit-logs.md) |
| Notificação à autoridade de supervisão (Art. 18.º, n.º 1) | A data em que notificou a sua autoridade de supervisão, antes da entrada em produção | A seu cargo. A notificação não implica a aceitação do acordo pela autoridade de supervisão |

## Fluxo de referência

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

**1. Criar o fluxo**

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

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

No passo **Verificação de identidade**, ative as carteiras de identidade digital disponíveis para os países onde presta serviços e a captura de documentos como a via para todos os outros. Consulte [Métodos de verificação de identidade](https://docs.didit.me/pt/console/id-verification-methods.md).

**3. Vincular o documento à pessoa**

Para a via de documentos, adicione **Prova de vida** e **Correspondência facial**, bem como **NFC** caso o documento possua um chip.

**4. Tratar da morada**

Adicione **Comprovativo de morada** para clientes cujo documento não contenha a morada.

**5. Fazer a triagem e monitorizar**

Adicione **Triagem AML**, defina os limiares que enviam uma correspondência para revisão e ative a monitorização contínua.

**6. Solicitar a finalidade e a origem dos fundos**

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

**7. Subscrever webhooks**

Crie um destino de webhook com subscrição aos eventos `status.updated` e `data.updated`. Consulte [Webhooks](https://docs.didit.me/pt/integration/webhooks.md).

**8. Publicar e copiar o ID do fluxo**

Publique o fluxo e utilize o seu `workflow_id` 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 o `url`. Quando for tomada uma decisão para a sessão, a Didit envia um webhook `status.updated`. Um excerto:

```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, utilize o `event_id` como chave de idempotência e compare o campo `status` como uma string exata e sensível a maiúsculas e minúsculas. Os valores encontram-se listados em [Estados de verificação](https://docs.didit.me/pt/integration/verification-statuses.md). Em seguida, leia a decisão completa através de `GET /v3/session/{sessionId}/decision/` e transmita-a à pessoa ou ao processo responsável por tomar a decisão de onboarding.

## Cronograma

| Data | O que acontece |
| - | - |
| 19 de junho de 2024 | O AMLR, Regulamento (UE) 2024/1624, é publicado no Jornal Oficial |
| 9 de julho de 2024 | O AMLR entra em vigor |
| 30 de setembro de 2026 | A AMLA fixa a data do seu relatório final sobre os projetos de normas de devida diligência relativa à clientela (anunciado a 1 de outubro de 2026). Submetido à Comissão, não adotado |
| 10 de julho de 2027 | O AMLR torna-se aplicável. Prazo para os Estados-Membros transporem a sexta Diretiva Antibranqueamento de Capitais, Diretiva (UE) 2024/1640. Está prevista a publicação das orientações da AMLA sobre subcontratação |
| 2028 | A AMLA inicia a supervisão direta de entidades financeiras selecionadas. A primeira ronda é limitada a 40 |
| 10 de julho de 2029 | O AMLR torna-se aplicável a agentes desportivos de futebol e clubes de futebol profissionais |

## FAQ

> [accordion] Quando é que o AMLR se aplica?
>
> O AMLR entrou em vigor a 9 de julho de 2024 e será aplicável a partir de 10 de julho de 2027. Para agentes desportivos 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 legislações nacionais que transpõem a diretiva atual.

> [accordion] Qual é a diferença entre o AMLR, a AMLD6 e a AMLA?
>
> O AMLR é o Regulamento (UE) 2024/1624. Contém as regras para as entidades obrigadas e aplica-se diretamente, sem transposição nacional. A AMLD6 é a Diretiva (UE) 2024/1640. É dirigida aos Estados-Membros e abrange autoridades de supervisão, registos e sanções, com transposição prevista até 10 de julho de 2027. A AMLA é a Autoridade de Combate ao Branqueamento de Capitais, criada pelo Regulamento (UE) 2024/1620 e sediada em Frankfurt. Elabora as normas técnicas e orientações e supervisionará diretamente um grupo selecionado de entidades financeiras a partir de 2028.

> [accordion] A verificação remota com documento de identificação ainda é permitida?
>
> Sim, com condições. O Artigo 22(6) indica dois meios: um documento de identificação ou eID com nível de garantia substancial ou elevado. O projeto final de normas da AMLA de 30 de setembro de 2026 mantém a verificação remota com um documento como alternativa para os casos em que não seja razoavelmente expectável que a pessoa apresente o documento presencialmente e esta não tenha acesso a um eID que cumpra os requisitos. Deve ser capaz de justificar a sua utilização e demonstrar as salvaguardas. O projeto não especifica nenhuma técnica e ainda não tem força de lei.

> [accordion] As normas técnicas são definitivas?
>
> Não. A AMLA finalizou o seu projeto a 30 de setembro de 2026 e enviou-o à Comissão Europeia. Só se tornará vinculativo quando a Comissão o adotar e for publicado no Jornal Oficial, podendo a Comissão introduzir alterações. O projeto propõe que a sua aplicação comece seis meses após a sua entrada em vigor, pelo que ainda não existe uma data de calendário definida.

> [accordion] Tenho de aceitar a EUDI Wallet e o Didit suporta-a?
>
> O próprio AMLR indica o eID como um de dois meios de verificação. Não obriga todas as entidades obrigadas a aceitar a EUDI Wallet. O dever de aceitação reside no regulamento eIDAS: partes utilizadoras privadas que devam recorrer a autenticação forte do utilizador para identificação online aceitam a carteira a pedido do utilizador, o mais tardar 36 meses após a entrada em vigor dos atos de execução, estando as micro e pequenas empresas isentas. Se isso se aplica ao seu onboarding é uma questão para a sua assessoria jurídica. No Didit, a EUDI Wallet está **Em breve**. 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 efetivo é de 25% ou de 15%?
>
> É "25 % ou mais" das ações, direitos de voto ou outro interesse de propriedade (Artigo 52(1)), sendo o controlo avaliado em paralelo. O Artigo 52(2) permite que a Comissão estabeleça um limiar inferior, no máximo de 15 %, para categorias de entidades de risco mais elevado através de ato delegado. Nenhum ato desse tipo existe atualmente. No Didit, o limiar de UBO é uma definição no seu fluxo de KYB.

> [accordion] Como implemento a atualização de 1 ano e de 5 anos?
>
> Guarde 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 que ultrapassaram o seu intervalo e crie uma nova sessão com `POST /v3/session/` e o mesmo `vendor_data`. Adicione acionadores de eventos: um estado `"Kyc Expired"`, um webhook de monitorização ou uma alteração comunicada pelo cliente. Os valores de 1 ano e 5 anos no Artigo 26(2) são períodos máximos.

> [accordion] O que posso subcontratar?
>
> Tarefas como a recolha de dados de identificação, a execução da verificação, consultas a registos, triagem e a execução da monitorização de transações segundo critérios aprovados por si. Seis tarefas não podem ser subcontratadas: aprovar a avaliação de risco a nível de toda a empresa, aprovar políticas internas, decidir o perfil de risco do cliente, decidir o onboarding, reportar à FIU e aprovar critérios de deteção. Permanece totalmente responsável pelo que subcontratar (Artigo 18(2)).

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

> [accordion] O uso do Didit garante a conformidade com o AMLR?
>
> Não. A conformidade é uma propriedade do seu programa: da sua avaliação de risco, das suas políticas, das suas decisões e dos seus controlos. O Didit fornece as verificações, a monitorização e as evidências sobre as quais essas partes do programa assentam. Não existe qualquer certificação ou aprovação AMLR para fornecedores ou ferramentas.

## Recursos relacionados

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

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

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

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

> [card] [Triagem AML](https://docs.didit.me/pt/core-technology/aml-screening/overview.md)
>
> Triagem de sanções, PEP e listas de vigilância com monitorização contínua.

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

> [card] [Questionários](https://docs.didit.me/pt/core-technology/questionnaires/overview.md)
>
> Modelos para a finalidade da relação e a origem dos fundos.

> [card] [Conservação de dados](https://docs.didit.me/pt/console/data-retention.md)
>
> Períodos de conservação e eliminação a pedido.

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

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


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