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

# Monitoramento AML contínuo: reanálise diária

> A Didit reanalisa usuários verificados todos os dias contra listas AML e envia alertas de webhook para novas sanções e mudanças de status.

O monitoramento contínuo é um componente essencial de um programa AML completo. Ele garante que a sua devida diligência do cliente permaneça atualizada e ajuda a identificar riscos que possam surgir depois do onboarding inicial. Esse recurso é incluído automaticamente em todas as sessões em que uma verificação AML foi realizada, sem exigir nenhuma etapa adicional de integração.

![Painel de monitoramento AML contínuo da Didit com reanálise diária e alertas de webhook](https://mintcdn.com/didit-0f962782/z6T2GHM4Zh-iSj-K/images/aml-continuous-monitoring.png?fit=max\&auto=format\&n=z6T2GHM4Zh-iSj-K\&q=85\&s=8cf8c4ecef0f78953423a598defd2b2b)

### Como funciona

Nosso sistema de monitoramento contínuo verifica constantemente os seus usuários verificados contra diversas listas de vigilância, listas de sanções e fontes de mídia negativa. Veja uma visão detalhada do processo:

1. **Verificações automáticas diárias**:
   * Nosso sistema executa verificações automáticas diárias de todas as sessões aprovadas anteriormente
   * Cada verificação reanalisa o usuário contra nossa base abrangente de listas de vigilância e listas de sanções
   * O sistema compara quaisquer novos achados com os seus limites AML configurados

2. **Atualizações baseadas em limites**:
   * Se forem encontrados novos resultados que excedam o seu limite de revisão configurado, o status da sessão muda para "Em revisão"
   * Se os novos resultados excederem o seu limite de recusa, o status da sessão muda automaticamente para "Recusada"
   * Esses limites são os mesmos que você configurou nos seus [Fluxos de trabalho](https://docs.didit.me/console/workflows.md)

3. **Notificações em tempo real**:
   * Quando ocorre uma mudança de status, a sua aplicação recebe uma notificação de webhook
   * O payload do webhook inclui o status atualizado e informações detalhadas sobre os novos resultados AML
   * Essas notificações seguem o mesmo formato do nosso [sistema de webhooks](https://docs.didit.me/integration/webhooks.md) padrão

4. **Atualizações no Business Console**:
   * Todas as mudanças são refletidas imediatamente no seu Business Console
   * Sua equipe de conformidade pode inspecionar os novos resultados AML, revisar os achados detalhados e tomar as ações apropriadas
   * O console mantém uma trilha de auditoria completa de todas as atividades de monitoramento e mudanças de status

### Ativando o monitoramento para usuários e empresas

Você pode ativar ou desativar o monitoramento contínuo para usuários e empresas inteiros diretamente pelo console, inclusive para usuários que nunca passaram por uma verificação AML, como usuários importados.

1. Abra **Usuários** (ou **Empresas**) no seu Business Console, selecione os perfis que deseja monitorar e clique em **Monitoramento contínuo AML**.
2. A caixa de diálogo mostra uma estimativa de custo antes de qualquer execução: quantos perfis estão selecionados, quantos precisam de uma nova triagem AML, o custo único da triagem e o custo anual do monitoramento.
3. Clique em **Habilitar monitoramento**. Seleções pequenas são concluídas imediatamente; as maiores rodam em segundo plano enquanto a caixa de diálogo mostra o progresso ao vivo.
4. Quando a execução termina, a caixa de diálogo detalha o resultado por perfil: habilitado, triado e habilitado, já habilitado ou ignorado com o motivo (por exemplo, um perfil sem o nome completo, a data de nascimento e o país necessários para a triagem).

Alguns detalhes importantes:

* **Perfis sem triagem AML são triados primeiro.** A Didit cria uma nova verificação AML para eles (visível na aba **Verificações** do perfil), cobrada como uma triagem AML comum. O monitoramento é então habilitado nessa triagem.
* **Uma triagem monitorada por perfil.** Ao habilitar, fica exatamente uma triagem AML monitorada por usuário ou empresa, de modo que uma pessoa que se verificou várias vezes é monitorada - e cobrada - apenas uma vez. Desabilitar desliga o monitoramento em todas as triagens do perfil.
* **As listas mostram o monitoramento num relance.** As listas de **Usuários** e de **Empresas** incluem uma coluna **Monitoramento contínuo**; passe o mouse sobre ela para ver a próxima data de cobrança anual.
* **Selecionar tudo funciona com os seus filtros.** Com todas as linhas selecionadas, a ação se aplica à sua visão filtrada atual, e não apenas à página carregada.

### Ativando o monitoramento pela API

A mesma operação está disponível para o seu backend com a sua chave de API, para que você nunca precise reanalisar um perfil nem abrir o console para alterar o monitoramento:

* [`POST /v3/users/aml-monitoring/`](https://docs.didit.me/management-api/aml-monitoring/toggle-users) para usuários
* [`POST /v3/businesses/aml-monitoring/`](https://docs.didit.me/management-api/aml-monitoring/toggle-businesses) para empresas
* [`GET /v3/aml-monitoring/jobs/{job_id}/`](https://docs.didit.me/management-api/aml-monitoring/get-job) para consultar um job

Os dois endpoints de alternância aceitam uma lista dos seus próprios identificadores (`vendor_data_list`) e/ou ids da Didit (`didit_internal_id_list`), até 1000 por chamada, e seguem exatamente as regras do console: uma triagem monitorada por perfil, perfis sem triagem são triados primeiro e desabilitar desliga o monitoramento em todas as triagens do perfil.

```bash theme={null}
# 1. Preview the cost. Nothing is written.
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, "estimate_only": true, "vendor_data_list": ["user-123", "user-456"]}'

# 2. Enable monitoring. 20 profiles or fewer complete inline (200);
#    larger selections return 202 and a job_id to poll.
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"]}'
```

A resposta traz o mesmo detalhamento que a caixa de diálogo do console mostra, além de uma entrada em `results` por perfil com o seu resultado: `enabled`, `screened_and_enabled`, `already_enabled`, `disabled` ou um motivo de omissão como `skipped_no_identity_data`. Identificadores que não correspondem a nada voltam em `unmatched`. Alternar o monitoramento não emite nenhum webhook próprio; depois que o monitoramento está ativo, as reanálises disparam os eventos habituais `status.updated` e `data.updated`.

### Comprovando que o monitoramento rodou

Os alertas, as entradas de atividade e os webhooks acima disparam quando há **mudança**. Um sujeito analisado diariamente durante um ano sem novos resultados não produz nenhum deles, então "sem novidades" e "nada rodou" parecem idênticos - o que não é uma resposta que resista a uma auditoria. Três superfícies registram as próprias execuções.

**1. A data da última triagem, no relatório AML.** `last_ongoing_screening_at` avança a cada execução concluída, com ou sem mudança, nas decisões de sessão `/v2/` e `/v3/` e no relatório AML independente. `last_ongoing_screening_datasets_updated_at`, ao lado dele, é a atualização de conjunto de dados AML mais recente informada pelo provedor para aquela execução. Nenhum dos dois é jamais estimado: `null` significa "nunca reanalisado" e "nenhuma data de conjunto de dados informada", respectivamente, e não "desconhecido, então aqui vai uma data plausível". Não leia `next_ongoing_monitoring_bill_date` como data de triagem - é uma data de cobrança.

**2. O histórico de triagens, por sujeito.** `GET /v1/session/{session_id}/aml-screening-history/` retorna todas as execuções concluídas da verificação AML daquela sessão, da mais recente para a mais antiga, incluindo as execuções cujo resultado foi `NO_CHANGE`. Adicione `?node_id=` quando um fluxo em grafo tiver mais de um nó AML.

```bash theme={null}
curl https://verification.didit.me/v1/session/SESSION_ID/aml-screening-history/ \
  -H "x-api-key: YOUR_API_KEY"
```

```json theme={null}
{
  "count": 2,
  "results": [
    {
      "uuid": "0d1c...",
      "completed_at": "2026-09-12T04:03:11Z",
      "started_at": "2026-09-12T04:00:02Z",
      "outcome": "NO_CHANGE",
      "trigger": "ONGOING_MONITORING",
      "status": "Approved",
      "score": 0,
      "total_hits": 0,
      "dataset_freshness": null
    }
  ]
}
```

| Campo | Significado |
| - | - |
| `outcome` | `NO_CHANGE` - a execução foi concluída e o resultado não mudou. `CHANGED` - a execução foi concluída e a pontuação, o status ou os resultados mudaram. `FAILED` - o provedor não retornou uma resposta utilizável para esse sujeito, então nada foi analisado e nada foi alterado. Uma lacuna de cobertura é registrada, e não escondida. |
| `completed_at` / `started_at` | Quando a triagem desse sujeito terminou e quando começou o lote a que ela pertencia. |
| `status` / `score` / `total_hits` | O estado em que a execução deixou a verificação. |
| `dataset_freshness` | Quão atualizadas estavam as listas do provedor naquela execução, ou `null` quando não havia datas de conjuntos de dados disponíveis. |

**3. A evidência exportável.** `GET /v1/session/{session_id}/aml-screening-history/export/` transmite o mesmo histórico como um arquivo CSV - uma linha por triagem concluída, com a data de atualização do conjunto de dados por família de fontes quando o provedor informou uma e uma célula vazia quando não informou. Esse arquivo é o que uma equipe de conformidade entrega a um auditor. O Business Console expõe a mesma lista e a mesma exportação ao lado do resultado AML, então os revisores não precisam de acesso à API para gerá-la.

> [!NOTE]
>
> **Limites de disponibilidade, ditos com clareza.** O histórico é registrado a partir do momento em que esse recurso foi lançado; triagens anteriores não são reconstruídas e simplesmente não existem. As execuções são mantidas pela janela de retenção configurada (dois anos por padrão). A atualização dos conjuntos de dados depende de o provedor publicar as datas para o ambiente em que você está - quando não publica, todos os campos de conjunto de dados retornam `null` e `GET /v1/aml/dataset-freshness/` informa `availability: "not_configured"`. Uma data ausente nunca é substituída por outra.

### Benefícios do monitoramento contínuo

1. **Conformidade contínua**: garanta a aderência permanente às regulamentações AML/KYC sem nenhuma configuração adicional.
2. **Mitigação de riscos**: identifique e trate rapidamente riscos emergentes por meio do monitoramento automático.
3. **Eficiência operacional**: automatize processos manuais e demorados de reanálise sem trabalho extra de integração.
4. **Devida diligência reforçada**: mantenha os perfis de clientes atualizados automaticamente.
5. **Apoio regulatório**: demonstre com facilidade os esforços de conformidade contínua aos reguladores.
6. **Integração sem esforço**: aproveite o monitoramento contínuo sem nenhum trabalho adicional de desenvolvimento.


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