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

# Regras e pontuação de KYT: velocidade e condições

> Configure regras de KYT na Didit com condições, janelas de velocidade e ações automáticas. 1,000 por mês incluídas, depois $0.001 cada.

Cada transação enviada à Didit é avaliada em relação a todas as regras ativas da sua aplicação. As regras definem condições, verificações de frequência e ações que determinam o status final e a pontuação da transação.

Este capítulo da aula da Didit Academy sobre o motor de regras de fraude retoma a partir da criação de uma regra.

A aula da Academy sobre o motor de regras mostra, em vídeo, a criação de uma regra aos 7:54: gatilho, condições, ações e pontuação e, em seguida, o backtesting antes da implantação.

[Criando uma regra — Didit Academy](https://www.youtube.com/embed/Yhm63_n7HuU?start=474\&rel=0\&playsinline=1)

> [!NOTE]
>
> As regras podem ser gerenciadas pelo **Business Console**, pela **Management API** e pelo **Didit MCP**. Use o console quando uma pessoa da sua equipe de conformidade precisar revisar cada alteração; use a API ou o MCP quando as regras forem criadas e ajustadas de forma programática, por exemplo, ao migrar um conjunto de regras de outro provedor. Consulte a [referência da API](https://docs.didit.me/pt-br/management-api/transactions/rules-list.md) e o [guia de gerenciamento de regras via API e MCP](https://docs.didit.me/pt-br/transaction-monitoring/rules-api.md). As regras são avaliadas em cada transação enviada via [`POST /v3/transactions/`](https://docs.didit.me/pt-br/management-api/transactions/create), e o resultado aparece no array `rule_runs[]` da transação (consulte o [esquema da resposta](https://docs.didit.me/pt-br/transaction-monitoring/response-schema.md)).

## Pacotes de regras integrados

A Didit oferece uma biblioteca de regras pré-configuradas que cobre as tipologias regulatórias mais comuns. Instale as predefinições (ou pacotes inteiros) que quiser a partir da biblioteca, no console, pela [API de instalação](https://docs.didit.me/pt-br/management-api/transactions/rules-install.md) ou com as ferramentas do MCP, e controle o modo de cada predefinição instalada. Para o catálogo completo de todas as regras predefinidas, com limiares e ações, consulte a [Biblioteca de regras](https://docs.didit.me/pt-br/transaction-monitoring/rules-library.md).

| Pacote | Exemplos |
| - | - |
| **Financeiro** | Detecção de fracionamento (entrada/saída), transações individuais de alto valor acima dos limiares de reporte |
| **AML/CTF** | Limites de volume acumulado, movimentação rápida de entrada e saída, correspondência de contrapartes com sanções, palavras-chave suspeitas na referência de pagamento |
| **Detecção de anomalias** | Alto volume de transações de entrada/saída em curto período, reativação de conta inativa após 12+ meses sem atividade |
| **FATF** | Exposição de contrapartes e IPs do titular a jurisdições de alto risco |
| **Inteligência de dispositivos** | Uso repetido de campanhas de bônus a partir da mesma impressão digital de dispositivo, múltiplas impressões digitais de dispositivo para o mesmo titular |
| **Prevenção de fraudes** | Múltiplas contas por meio de impressões digitais de dispositivo compartilhadas entre titulares distintos |
| **Monitoramento cripto** | Exposição a mixers/serviços de ofuscação, endereços de carteira de alto risco (darknet, sancionados, fundos roubados) |
| **Crypto screening** | Exposição a origens de recursos de alto risco (>30%), múltiplas contrapartes de risco, recusa automática por financiamento do terrorismo / exploração infantil, retenção enquanto a triagem está pendente, sinalização de pontuação de risco média da carteira |
| **Jogo responsável** | Picos de depósitos em curtos períodos |
| **E-commerce** | Padrões de transação específicos de e-commerce |

## Origens das regras

Toda regra tem um `source` que indica quem a gerencia:

| Origem | Descrição |
| - | - |
| **Predefinição** | Regras instaladas a partir da biblioteca integrada da Didit. Você escolhe quais predefinições (ou pacotes inteiros) instalar e controla o modo de cada predefinição instalada (`Active`, `Test`, `Disabled`). As condições e os limiares delas são fixos (para sobrescrever um deles, crie uma regra personalizada) e elas são removidas ao desinstalá-las, e não ao excluí-las. |
| **Personalizado** | Regras criadas pela sua equipe no Console Empresarial. Você tem controle total sobre as regras personalizadas: crie, edite e exclua conforme necessário. |

## Anatomia de uma regra

Cada regra é composta por:

| Componente | Descrição |
| - | - |
| **Título e descrição** | Nome legível e explicação do que a regra detecta |
| **Categoria** | Agrupamento lógico (por exemplo, `finance`, `aml_ctf`, `crypto_monitoring`, `device_intelligence`) |
| **Modo** | `Active` (avaliação em produção), `Disabled` (ignorada) ou `Test` (avaliada, mas os resultados não afetam a transação) |
| **Modo de avaliação** | `All` (todas as condições precisam corresponder) ou `Any` (pelo menos uma condição precisa corresponder) |
| **Escopo** | Limita a quais transações a regra se aplica. Chaves: `transaction_types`, `directions` (`INBOUND`/`OUTBOUND`), `action_types`; vazio ou ausente significa sem restrição |
| **Condições** | Verificações por campo: comparam campos da transação com valores usando operadores como `eq`, `lt`, `gte`, `in`, `contains_any`, `exists` |
| **Agregação** | Janelas de velocidade: agregam transações históricas ao longo de um período (por exemplo, contagem, soma ou contagem distinta em 1 hora, 7 dias, 30 dias) |
| **Ações** | O que acontece quando a regra corresponde (veja abaixo) |

## Ações

Quando uma regra corresponde a uma transação, uma ou mais ações são executadas. Cada regra pode ter várias ações, e todas são aplicadas em conjunto:

| Ação | `type` | Chaves | Descrição |
| - | - | - | - |
| **Adicionar pontuação** | `add_score` | `value` (inteiro, pode ser negativo) | Adiciona pontos à pontuação de risco da transação. A pontuação acumulada de todas as regras correspondentes determina se a transação ultrapassa o limiar de revisão ou de recusa. |
| **Alterar status** | `change_status` | `value` (`APPROVED`\|`IN_REVIEW`\|`DECLINED`\|`AWAITING_USER`, alias `status`), `workflow_id` (alias `remediation_workflow_id`) | Define diretamente o status da transação, independentemente da pontuação. `workflow_id` é obrigatório quando `value` é `AWAITING_USER`; omiti-lo retorna `400`. |
| **Adicionar etiquetas** | `add_tags` | `tag_uuid` ou `tag_name` (um dos dois), `tag_color` | Marca a transação com etiquetas para categorização e filtragem. Use o `tag_uuid` de uma etiqueta existente ou um `tag_name` que é criado no primeiro uso (armazenado em maiúsculas); `tag_color` define a cor hexadecimal de uma etiqueta recém-criada. |
| **Adicionar nota** | `add_note` | `note` (alias `value`) | Anexa uma nota de texto automática à transação para dar contexto ao analista. |
| **Adicionar à lista** | `add_to_list` | `list_id` | Adiciona o `vendor_data` do titular a uma lista de bloqueio, lista de permissão ou lista personalizada. |
| **Abrir caso** | `open_case` | `blueprint` (UUID do blueprint do caso, opcional), `grouping` (`by_applicant`\|`by_rule_and_applicant`), `attach_matched_transaction` (booleano) | Abre um caso de investigação (ou adiciona a um existente). Somente a primeira ação `open_case` de uma regra é aplicada. |

A maioria das regras predefinidas combina **Adicionar pontuação** com **Alterar status**. Por exemplo, uma regra de contraparte sancionada adiciona 90 pontos à pontuação *e* recusa a transação imediatamente.

### Exigir verificação do usuário (`AWAITING_USER`)

Uma ação **Alterar status → `AWAITING_USER`** faz mais do que definir um status: a Didit cria automaticamente uma sessão de verificação hospedada para o titular da transação (mesmo `vendor_data`) no momento em que a regra é acionada.
A sessão é retornada no bloco `action_required` da transação (e no objeto `remediation`) na resposta de criação e em todas as leituras posteriores, além de nos dois webhooks de transação. Assim, você pode redirecionar o usuário imediatamente; veja [ações exigidas do usuário](https://docs.didit.me/pt-br/transaction-monitoring/sdk-transaction-submission.md#ações-exigidas-do-usuário).

Regras personalizadas devem indicar o fluxo na própria ação (`workflow_id`): tanto o construtor de regras do console quanto a API de regras exigem isso.
As regras da biblioteca integrada não trazem um fluxo; para elas, o fluxo da sessão é definido nesta ordem:

1. O **fluxo de remediação** configurado nas suas [configurações de transações](https://docs.didit.me/pt-br/transaction-monitoring/settings.md#fluxo-de-remediação).
2. O fluxo de **Autenticação biométrica** da sua aplicação, quando o titular já tem um rosto de referência armazenado de uma verificação aprovada.
3. O fluxo padrão da sua aplicação.

Isso significa que as regras da biblioteca com `AWAITING_USER` sempre geram uma sessão acionável sem configuração adicional: uma autenticação biométrica adicional para usuários que você já verificou e uma verificação completa nos demais casos.
As transações de Travel Rule ficam fora desse fallback automático: nelas, a espera em `AWAITING_USER` é pela comprovação de propriedade da carteira, que tem [seu próprio fluxo](https://docs.didit.me/pt-br/transaction-monitoring/wallet-ownership-widget.md).

A opção mais robusta para transações de alto risco é um fluxo de **Autenticação biométrica**: como o titular é o usuário que você já verificou no KYC, a Didit reutiliza o rosto de referência verificado no onboarding dele (a selfie de prova de vida aprovada, a foto do chip do passaporte ou o retrato do documento). O usuário só tira uma selfie ao vivo, e a Didit executa a prova de vida e uma correspondência facial 1:1 com a identidade que abriu a conta.
Credenciais roubadas, OTPs obtidos por phishing e trocas de SIM (SIM swap) não passam por essa barreira.
Passo a passo completo: [autenticação biométrica adicional para um saque de alto valor](https://docs.didit.me/pt-br/transaction-monitoring/sdk-transaction-submission.md#exemplo-biometria-adicional-para-um-saque-de-alto-valor).

Quando a sessão chega a uma decisão, a transação segue essa decisão automaticamente e um webhook `transaction.status.updated` é disparado: uma sessão aprovada aprova a transação (`decision_reason_code: user_action_approved`), uma sessão recusada a recusa (`user_action_declined`) e uma sessão que termina em revisão envia a transação para `IN_REVIEW` (`user_action_in_review`).
Uma sessão expirada ou abandonada mantém a transação em `AWAITING_USER`.

> [!NOTE]
>
> Qualquer tipo de fluxo, exceto KYB, pode ser usado como ação de remediação.
> Fluxos de Autenticação biométrica (e fluxos em que a correspondência facial é executada antes da verificação de identidade) também exigem um rosto de referência armazenado para o titular: uma selfie de prova de vida aprovada, a foto do chip do passaporte, o retrato do documento ou um rosto de perfil cadastrado manualmente.
> Se nenhum existir, o usuário é solicitado a concluir o fluxo padrão da sua aplicação, o que também cadastra o rosto dele para a próxima vez, e uma nota na transação registra a substituição.
> Somente quando também não existe um fluxo padrão adequado é que a sessão é ignorada, com a nota explicando o motivo.

## Pontuação

Quando uma transação corresponde a uma ou mais regras, as pontuações são combinadas:

1. Cada correspondência de regra contribui para a **pontuação de risco** geral da transação por meio da ação `add_score`
2. A pontuação final determina o status da transação com base nos **limiares de pontuação** da sua aplicação
3. Se alguma regra tiver uma ação `change_status`, esse status é aplicado diretamente; `DECLINED` sempre tem prioridade

Limiares de pontuação padrão (configuráveis no console):

| Configuração | Padrão | Descrição |
| - | - | - |
| **Limiar de revisão** | 75 | Pontuações iguais ou superiores a este valor acionam `IN_REVIEW` |
| **Limiar de recusa** | 500 | Pontuações iguais ou superiores a este valor acionam `DECLINED`. O padrão (`500`) nunca resulta em recusa por pontuação |

## Criação de regras personalizadas

As regras personalizadas podem ser criadas no **Business Console** ou pela **Management API** (também acessível pelo [Didit MCP](https://docs.didit.me/pt-br/integration/mcp/tools.md) e por qualquer assistente de IA conectado via MCP).

> [tab] Console
>
> 1. Acesse **Transactions** > **Rules** no console
> 2. Clique em **Create Rule**
> 3. Defina o título, a descrição e a categoria da regra
> 4. Defina o **modo** - `Active` para executar em produção ou `Test` para avaliar sem afetar as transações
> 5. Escolha o **modo de avaliação** - `All` (todas as condições devem corresponder) ou `Any` (pelo menos uma)
> 6. Defina o **escopo** - a quais tipos ou direções de transação a regra se aplica
> 7. Adicione **condições** - comparações de campos, como limiares de valor, códigos de país e verificações de propriedades personalizadas
> 8. Opcionalmente, adicione uma **agregação** - verificações de velocidade em uma janela de tempo (contagem, soma, contagem distinta e outras)
> 9. Defina uma ou mais **ações** - adicionar pontuação, alterar o status, adicionar tags, adicionar notas, adicionar a uma lista ou abrir um caso
> 10. Salve e ative a regra

> [tab] API
>
> Chame [`POST /v3/transactions/rules/`](https://docs.didit.me/pt-br/management-api/transactions/rules-create) com os mesmos campos: `title`, `category`, `mode`, `evaluation_mode`, `scope`, `conditions`, `aggregation`, `actions`. A referência completa de campos, operadores e ações está nesta página, e [gerenciamento de regras via API e MCP](https://docs.didit.me/pt-br/transaction-monitoring/rules-api.md) mostra passo a passo o fluxo recomendado de criar -> fazer backtest -> ativar, incluindo a migração de um conjunto de regras a partir da exportação CSV de outro provedor.

As regras no modo `Active` entram em vigor imediatamente para todas as novas transações. Os títulos são únicos por aplicação.

## Backtesting

Antes de ativar uma regra, você pode validá-la com dados históricos:

* Coloque a regra no modo **Test** — a regra é avaliada em cada nova transação, mas os resultados não afetam o status nem a pontuação da transação. As estatísticas de execução (número de correspondências, entidades afetadas) se acumulam para que você possa avaliar o impacto antes de colocá-la em produção.
* Use o recurso de **backtest** - no console ou via [`POST /v3/transactions/rules/backtest/`](https://docs.didit.me/pt-br/management-api/transactions/rules-backtest) - para avaliar retroativamente as condições e a agregação de uma regra em transações de um período especificado. O backtest retorna o número de transações avaliadas, de transações que atenderam às condições e das entidades afetadas - sem modificar nenhum dado histórico. Envie os mesmos `conditions`, `aggregation`, `evaluation_mode` **e** `scope` da regra que você pretende ativar: omitir o escopo significa nenhuma restrição, então o backtest contaria transações que a regra salva ignora.

## Janelas de velocidade (agregação)

As regras de velocidade agregam dados históricos de transações ao longo de um período para detectar padrões que verificações de uma única transação não identificariam:

| Métrica | Descrição |
| - | - |
| `count` | Número de transações que correspondem aos filtros na janela |
| `sum` | Total de um `field` numérico (por exemplo, `preferred_currency_amount`) na janela |
| `max` / `min` / `avg` | Maior, menor ou valor médio de um `field` numérico na janela |
| `distinct_count` | Número de valores únicos de um `field` (por exemplo, impressões digitais de dispositivo distintas) na janela (`unique_count` é aceito como alias) |

Cada agregação especifica:

* Uma **janela de tempo**: `<N>m` (minutos), `<N>h` (horas) ou `<N>d` (dias) - por exemplo, `30m`, `6h`, `7d`, `30d`. Atenção: `m` significa **minutos**, não meses.
* **Filtros** para restringir quais transações históricas são incluídas. As chaves são caminhos de campo do [catálogo de campos](#catálogo-de-campos); o valor especial `"__current__"` corresponde ao valor do mesmo campo na transação que está sendo avaliada (por exemplo, `"subject_vendor_data": "__current__"` restringe a janela ao mesmo titular), e um valor de lista indica que o campo deve corresponder a um dos valores da lista. Os filtros comparam **apenas** por igualdade ou pertencimento - não existe filtro `lt`/`gte`, então um intervalo como *transações abaixo de 10,000* não pode ser expresso por um filtro. Coloque o intervalo na métrica (`max` abaixo de 10,000, `min` acima de 1,000) e lembre-se de que uma condição restringe a transação que está sendo avaliada, nunca a janela.
* Um **operador e limiar** (`eq`, `ne`, `gt`, `gte`, `lt`, `lte` em relação a `value`, por exemplo, count >= 20)

### Padrões de exemplo

| Padrão | Como funciona |
| - | - |
| **Fracionamento (structuring)** | Contagem de transações do mesmo titular em 30 dias >= 20, com valor `max` abaixo de \$10,000 na mesma janela |
| **Alta velocidade** | Contagem de transações de entrada do mesmo titular em 7 dias >= 20 |
| **Entrada e saída rápidas** | A transação atual é de saída + contagem de transações de entrada do mesmo titular em 6 horas >= 1 |
| **Múltiplas contas** | Contagem de titulares distintos que compartilham a mesma impressão digital de dispositivo em 7 dias >= 3 |
| **Reativação após inatividade** | Dias desde a transação anterior do titular >= 365, combinados com valor >= \$1,000 |

## Catálogo de campos

Condições e filtros de agregação referenciam os campos da transação pelo caminho:

| Campo | Descrição |
| - | - |
| `amount`, `currency` | O valor da transação e o código da moeda |
| `preferred_currency_amount`, `default_currency_code` | Valor convertido para a moeda preferencial da sua aplicação (usa `amount_in_default_currency` como alternativa) |
| `direction` | `INBOUND` ou `OUTBOUND` |
| `action_type` | O seu tipo de ação, por exemplo `withdrawal`, `deposit`, `bet` |
| `transaction_type` | `finance`, `kyc`, `travelRule`, `userPlatformEvent` |
| `payment_details` | Referência de pagamento em texto livre (o alvo de `contains_any` nas regras de palavras-chave) |
| `score`, `severity` | A pontuação de risco e a severidade atuais da transação |
| `subject_vendor_data`, `counterparty_vendor_data` | Os seus identificadores para as duas partes |
| `subject_country`, `counterparty_country` | Códigos de país das partes (ISO-2 e ISO-3 são aceitos; normalizados antes da comparação) |
| `subject_device_fingerprint`, `counterparty_device_fingerprint` | Impressão digital do dispositivo ou ID persistente do dispositivo |
| `subject_browser_family`, `subject_browser_version`, `subject_platform`, `subject_accept_language`, `subject_session_age_ms` | Detalhes do contexto do dispositivo (`counterparty_browser_family` também está disponível) |
| `subject_ip_address`, `subject_ip_country`, `counterparty_ip_address`, `counterparty_ip_country` | Contexto de rede |
| `subject_payment_method_type`, `subject_payment_method_country`, `subject_payment_method_fingerprint`, `subject_payment_method_account_id` | O método de pagamento da parte principal (os mesmos quatro campos existem para `counterparty_payment_method_*`) |
| `travel_rule_status`, `travel_rule_required`, `travel_rule_obligations_count` | Estado da verificação da Travel Rule |
| `counterparty_dd_status`, `counterparty_risk_level`, `counterparty_jurisdiction`, `counterparty_responsiveness` | O que você sabe sobre o VASP da contraparte contatado pela troca da Travel Rule: a sua decisão sobre ele (`APPROVED`, `RESTRICTED`, `BLOCKED`), o nível de risco dele (`LOW`, `MEDIUM`, `HIGH`; `HIGH` enquanto a sua própria triagem da contraparte estiver sinalizada), o país e a capacidade de resposta (`RESPONSIVE`, `UNRESPONSIVE`, `UNKNOWN`). Consulte [due diligence de contrapartes da Travel Rule](https://docs.didit.me/pt-br/transaction-monitoring/travel-rule.md#campos-e-presets-de-regras) |
| `subject_days_since_previous_transaction` | Dias desde a transação anterior do mesmo tipo dessa parte principal (regras de inatividade) |
| `tags` | Os nomes das tags da transação |
| `custom_values.<key>` | Qualquer chave que você enviou em `custom_properties` ao criar a transação |

## Operadores de condição

As regras aceitam os seguintes operadores de comparação nas condições:

| Operador | Descrição | Exemplo |
| - | - | - |
| `eq` / `ne` | Igual / diferente | `direction eq "OUTBOUND"` |
| `gt` / `gte` / `lt` / `lte` | Comparações numéricas e de datas; nunca correspondem quando qualquer um dos lados está ausente | `preferred_currency_amount gte 25000` |
| `in` / `not_in` | Pertencimento a uma lista (um único valor escalar também é aceito) | `counterparty_country in ["IRN", "PRK", "SYR"]` |
| `contains` / `not_contains` | Substring sem diferenciar maiúsculas de minúsculas em um valor de texto | `payment_details contains "refund"` |
| `contains_any` | Qualquer uma das strings de uma lista é substring do campo, sem diferenciar maiúsculas de minúsculas | `payment_details contains_any ["terror", "weapon"]` |
| `regex` | O padrão do valor corresponde ao campo | `subject_vendor_data regex "^guest-"` |
| `fuzzy_match` | Similaridade aproximada de strings; exige um limiar `score` (0-100) na condição | `counterparty_name fuzzy_match "Acme Corp"` com `score: 85` |
| `exists` / `is_not_empty` / `is_not_null` | O campo está presente (aliases; `value` é ignorado) | `subject_device_fingerprint exists` |
| `not_exists` / `is_empty` / `is_null` | O campo está ausente ou vazio (aliases; `value` é ignorado) | `subject_ip_address is_empty` |

Todos os demais operadores exigem um `value` não vazio, e a API responde com `400` quando ele não é informado.
`contains`, `not_contains` e `regex` recebem uma única string, não uma lista nem um objeto; `contains_any` recebe uma lista de strings.

### Tipos de valor de condição

Um `value_type` opcional em uma condição muda a forma como `value` é interpretado:

| `value_type` | Significado |
| - | - |
| `list` | `value` é o UUID de uma lista: as entradas da lista de bloqueio, da lista de permissão ou da lista personalizada passam a ser o valor de comparação, de modo que uma regra pode corresponder a "contraparte na minha lista de monitoramento personalizada". |
| `field` | `value` é o caminho de outro campo: a condição compara dois campos da transação, por exemplo, `subject_payment_method_account_id ne counterparty_payment_method_account_id`. |
| `relative_date` | `value` é uma data relativa, por exemplo, `{"direction": "past", "unit": "days", "amount": 30}`, para campos de data como `txn_date`. |

### Condições agrupadas

Uma lista simples de condições é combinada de acordo com o `evaluation_mode` da regra (`ALL`/`ANY`). Para lógica mista, atribua às condições um `group_index`: as condições que compartilham o mesmo índice formam um grupo, `group_logic` (`AND`/`OR`, padrão `AND`) combina as condições dentro de um grupo, e `groups_logic` na primeira condição (`AND`/`OR`, padrão `OR`) combina os resultados dos grupos. Quando qualquer condição tem um `group_index`, a avaliação agrupada substitui o `evaluation_mode`.

### Referência a propriedades personalizadas

Toda chave enviada no objeto `custom_properties` de [`POST /v3/transactions/`](https://docs.didit.me/pt-br/transaction-monitoring/transactions) é armazenada na transação como `custom_values` e pode ser usada em condições com o caminho de campo `custom_values.<key>`. Por exemplo, uma transação enviada com `"custom_properties": {"channel": "mobile_app"}` corresponde à condição `custom_values.channel eq "mobile_app"`. Todos os operadores acima funcionam com propriedades personalizadas, que também podem ser comparadas com outros campos ou usadas em filtros de velocidade.

No construtor de regras do Console, as chaves observadas em transações ingeridas recentemente aparecem automaticamente no seletor de campos da condição, em **Custom Properties**. Você também pode referenciar uma chave antes que qualquer transação a contenha: escolha **Enter custom property** no mesmo grupo e digite a chave exatamente como a sua integração a envia (as chaves diferenciam maiúsculas de minúsculas). A regra simplesmente não corresponde até que cheguem transações com essa chave.

## Recusa automática por lista de bloqueio

Antes de avaliar qualquer regra, a Didit verifica as entidades da transação nas listas de bloqueio da sua aplicação. Se **qualquer** correspondência for encontrada, a transação é **recusada imediatamente**, e as regras não são avaliadas.

As seguintes entidades são verificadas:

| Entidade | Tipo de lista de bloqueio | O que é verificado |
| - | - | - |
| **Usuário (solicitante)** | Lista de bloqueio de usuários | O identificador `vendor_data` do solicitante |
| **Empresa** | Lista de bloqueio de empresas | O identificador `vendor_data` da empresa |
| **Endereço da carteira** | Lista de bloqueio de endereços de carteira | O `account_id` dos meios de pagamento do tipo carteira cripto |
| **Conta bancária** | Lista de bloqueio de contas bancárias | O `account_id` dos meios de pagamento do tipo transferência bancária |
| **Endereço IP** | Lista de bloqueio de endereços IP | O endereço IP do contexto do dispositivo da parte (aceita intervalos CIDR) |
| **Impressão digital do dispositivo** | Lista de bloqueio de impressões digitais de dispositivo | A impressão digital do dispositivo ou o ID persistente do dispositivo |

Quando ocorre uma correspondência na lista de bloqueio:

* O status da transação é definido como `DECLINED`
* O motivo da decisão é definido como `blocklisted`
* Um registro de atividade é criado para fins de auditoria

> [!NOTE]
>
> As verificações de lista de bloqueio são executadas antes da avaliação das regras. Uma entidade na lista de bloqueio sempre será recusada, independentemente da configuração das regras ou dos limiares de pontuação.

## Triagem de transações

A Didit se integra a provedores externos de AML e de análise de blockchain para enriquecer as transações com inteligência de risco. Quando uma transação é enviada, o sistema pode:

* **Analisar contrapartes** em bases globais de sanções e listas de monitoramento
* **Avaliar endereços de carteira** (em transações cripto) com base em dados de inteligência de blockchain, incluindo exposição a mixers, conexões com entidades sancionadas e interações com serviços de alto risco
* **Verificar o status AML do solicitante** cruzando o usuário vinculado à transação com os resultados mais recentes da sua triagem de AML

Os resultados da triagem são anexados à transação e entram na pontuação do mecanismo de regras. Se uma contraparte ou carteira corresponder a uma lista de sanções, a regra correspondente sinaliza ou recusa a transação automaticamente.

## Próximos passos

> [card] [Envio de transações](https://docs.didit.me/pt-br/transaction-monitoring/transactions.md)
>
> Como as transações são estruturadas para a avaliação das regras.

> [card] [Triagem de cripto](https://docs.didit.me/pt-br/transaction-monitoring/aml-screening.md)
>
> Resultados da triagem de cripto e como as regras predefinidas os utilizam.

> [card] [Configurações](https://docs.didit.me/pt-br/transaction-monitoring/settings.md)
>
> Configure limiares de pontuação e fluxos de remediação.

> [card] [Referência da API](https://docs.didit.me/pt-br/management-api/transactions/create.md)
>
> Endpoint da API Create Transaction.


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