Saltar para o conteúdo principal

Visão geral

A triagem AML cruza a identidade do sujeito verificado com conjuntos de dados globais de sanções, PEP, lista de vigilância e notícias adversas. Cada resultado devolve a entidade correspondente, o(s) conjunto(s) de dados que geraram a correspondência, duas pontuações — match_score (confiança na identidade) e risk_score (risco da entidade) — e uma discriminação estruturada por fonte (pep_matches[], sanction_matches[], warning_matches[], adverse_media_matches[]). O score agregado é o risk_score mais elevado entre os resultados que não estejam marcados como False Positive. A mesma estrutura é devolvida pela triagem AML em sessões de utilizador (KYC), sessões de empresas (KYB) e na API de AML autónoma.
Captura de ecrã do relatório de triagem AML da Didit com resultados de sanções, PEP e notícias adversas

Onde surge nas respostas da API

No endpoint de decisão da sessão, a triagem AML é devolvida como o array plural aml_screenings[]. Cada entrada corresponde a uma execução de AML no fluxo (uma verificação de AML executada duas vezes gera duas entradas com valores de node_id diferentes).
As sessões de AML autónomas e de empresas devolvem a mesma estrutura por registo. Os campos abaixo refletem o esquema canónico na página Modelos de dados.

Três pontuações, não um veredito

O status é um veredito; os números a partir dos quais foi calculado constam do mesmo payload. Leia-os quando construir a sua própria classificação de risco por níveis (por exemplo, combinando o risco de AML com respostas a questionários, tais como a origem da riqueza ou a autodeclaração de PEP), em vez de ramificar apenas com base em Approved / In Review / Declined: Todas as três estão presentes em todos os locais onde o relatório de AML é entregue: GET /v3/session/{sessionId}/decision/, no objeto decision dos webhooks status.updated e data.updated em todas as versões de webhook (aml_screenings[] na V3 e o singular legado aml na V2 / V1) e na API de AML autónoma. Um consumidor que veja apenas um indicador de sinalizado / sem sinalização está a ler o status (ou o review_status de um resultado) e a ignorar as pontuações ao lado. A consola mostra os mesmos números: o cabeçalho da secção de AML apresenta a Pontuação de risco agregada, e cada linha da tabela de correspondências inclui a Pontuação de correspondência e a Pontuação de risco com uma discriminação detalhada ao passar o cursor.

Esquema

Consulte Triagem AML na referência de Modelos de Dados para o esquema canónico. Campos de nível superior:

Campos por hit

Cada entrada em hits[] tem os seguintes campos (apresenta-se um subconjunto). Os arrays de fontes de correspondência — pep_matches[], sanction_matches[], warning_matches[], adverse_media_matches[] — são preenchidos apenas para os conjuntos de dados aos quais o hit pertence.
Os hits classificados como False Positive (porque match_score ficou abaixo do limiar da pontuação de correspondência ou porque um revisor os marcou) permanecem em hits[] para fins de auditoria. São excluídos apenas do cálculo do score agregado.

Monitorização contínua

Quando is_ongoing_monitoring_enabled é true, a Didit volta a fazer a triagem do sujeito continuamente e volta a emitir o relatório AML sempre que uma correspondência é adicionada, removida ou alterada. As retriagens que alteram o estado de AML acionam um webhook status.updated; as retriagens que apenas alteram dados de correspondências acionam data.updated. A janela de monitorização decorre a partir de last_aml_bill_date durante 365 dias; next_ongoing_monitoring_bill_date indica quando ocorre a próxima renovação anual. Esses sinais são todos acionados por alterações, pelo que um sujeito novamente triado durante meses sem novas correspondências não produz nenhum deles. last_ongoing_screening_at é o único campo que é atualizado em cada execução concluída, e o endpoint de histórico de triagens lista cada execução individualmente — incluindo aquelas que não alteraram nada. Consulte Monitorização AML contínua para ver o ciclo de vida completo.
Três datas neste relatório significam três coisas diferentes. next_ongoing_monitoring_bill_date é quando será faturado a seguir. last_ongoing_screening_at é quando o sujeito foi efetivamente triado pela última vez. last_ongoing_screening_datasets_updated_at é quando as listas subjacentes a essa triagem foram atualizadas pela última vez pelo fornecedor. Apenas a segunda comprova que o controlo foi executado.

Valores de estado

Os limiares são configuráveis por nó do fluxo — consulte Pontuação de risco de AML. As regras de estado personalizadas combinam-se com o estado derivado através da precedência Declined > In Review > Approved; os revisores também podem substituir o estado de AML a partir da consola ou do endpoint de estado de AML.

Exemplos

Aprovada — sem correspondências

Em análise — correspondência de PEP + notícias adversas

Todos os nomes, URLs e artigos abaixo são fictícios.

Relacionado

Última modificação em 7 de novembro de 2026