Saltar para o conteúdo principal
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. Última revisão: 2 de outubro de 2026.
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

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.

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. 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:

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/ contém uma entrada por verificação de identidade em id_verifications[].

As duas vias

O nível de garantia comunicado por cada carteira está listado na página de Carteiras de identidade digital. 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: 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. 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.
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)).
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/ 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)). 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.
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.
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.
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, 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.
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:

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.
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.
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:
Resposta (201 Created):
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:
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. 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

FAQ

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.
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.
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.
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.
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.
É “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.
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.
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)).
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.
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

Visão geral da solução AMLR

A perspetiva de negócio: a quem se aplica o AMLR e onde a Didit se enquadra.

Métodos de Verificação de identidade

Captura de documentos, consultas sem documentos e carteiras de identidade digital.

Carteiras de identidade digital

Disponibilidade e nível de garantia por carteira.

Verificação de empresas (KYB)

Consultas a registos, propriedade e pessoas-chave.

Triagem AML

Triagem de sanções, PEP e listas de vigilância com monitorização contínua.

Monitorização de transações

Regras, alertas, casos e preparação de relatórios para a UIF.

Questionários

Modelos para a finalidade da relação e a origem dos fundos.

Conservação de dados

Períodos de conservação e eliminação a pedido.

Webhooks

Tipos de evento, payloads e verificação da assinatura.

Preços

Pague por verificação. Consulte o preço atual de cada funcionalidade.
Última modificação em 7 de novembro de 2026