Regras de Velocidade e Detecção de Estruturação: Um Guia para Desenvolvedores (PT-BR)

Olhar para um único pagamento geralmente não diz nada. €9.700 para uma contraparte é algo comum. Mas dez pagamentos de €9.700 para a mesma contraparte ao longo de três dias, ou vinte transferências recebidas de vinte contas distintas em uma tarde, são as assinaturas de estruturação e atividade de mulas. Para detectá-los, é preciso olhar as transações como um fluxo — ao longo do tempo, com contagem e soma — e não uma por uma.

É isso que as regras de velocidade fazem, e são a parte mais difícil do monitoramento de transações para construir por conta própria. Você precisa de um processador de fluxo que mantenha janelas contínuas por usuário, conte, some e deduplique contrapartes dentro dessas janelas, e avalie limiares em tempo real. A API de Monitoramento de Transações do Didit oferece esse motor pronto para uso: defina uma janela, escolha uma agregação — contagem, soma ou distinta — defina um limite, e a regra será executada contra cada transação por US$ 0,02 por transação.

Este é um guia para desenvolvedores sobre como construir regras de velocidade e usá-las para detectar estruturação.

Principais pontos

• As regras de velocidade avaliam janelas de tempo — "nas últimas 24 horas", "ao longo de 7 dias" — em vez de pontuar uma única transação isoladamente.
• Três agregações: count (quantas), sum (valor cumulativo) e distinct (contrapartes ou atributos únicos) — os blocos de construção da detecção de estruturação e mulas.
• A estruturação — muitos pagamentos logo abaixo de um limite de relatório — é detectada combinando uma janela de soma com uma condição de proximidade ao limite.
• Os padrões de mula e smurfing são detectados com contagens de contrapartes distintas dentro de uma janela.
• Nenhum processador de fluxo necessário — o motor mantém as janelas; você declara a regra no Console.
• US$ 0,02 por transação, sem mínimos. A triagem AML de uma parte sinalizada é cobrada separadamente a US$ 0,20.

O que são regras de velocidade

Uma regra de velocidade tem três partes: uma janela (o período de análise — 1 hora, 24 horas, 7 dias), uma agregação sobre as transações nessa janela e um limite que, quando ultrapassado, aciona uma ação. As agregações são o cerne expressivo:

• count — quantas transações corresponderam às condições da regra na janela. "Mais de 5 transferências de entrada em 24 horas."
• sum — o valor cumulativo das transações correspondentes. "Volume cumulativo acima de €10.000 em 7 dias."
• distinct — o número de valores únicos de um atributo, geralmente a contraparte. "Transferências de mais de 8 remetentes distintos em 24 horas."

As janelas são indexadas por assunto por padrão — cada usuário tem seus próprios contadores contínuos — para que um dia agitado para toda a sua plataforma não afogue o sinal de um usuário individual.

Por que isso importa

A estruturação (também chamada de smurfing) é uma das técnicas de lavagem mais antigas e uma das mais explicitamente regulamentadas. Os limites de relatório — €10.000 em grande parte da UE, US$10.000 nos EUA — criam um incentivo para dividir grandes somas em pagamentos menores que ficam abaixo da linha. Uma regra pontual que verifica apenas valores únicos nunca a verá; o padrão completo vive no agregado.

O mesmo ocorre com as redes de mulas. O indicativo de uma mula de dinheiro não é uma única transferência — é a entrada de fundos de muitas contas distintas, seguida por uma rápida saída. Você só vê isso com contagens de contrapartes distintas ao longo de uma janela. Os reguladores esperam que as empresas detectem essas tipologias, e as regras de velocidade são a maneira de fazer isso sem montar sua própria pilha de análise de streaming.

Detalhes técnicos

As transações são criadas contra a API unificada /v3/, idempotente em um transaction_id que você controla:

curl -X POST https://verification.didit.me/v3/transactions/ \
  -H "x-api-key: $DIDIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "transaction_id": "txn_a19f04",
    "category": "finance",
    "amount": 9600,
    "currency": "EUR",
    "currency_kind": "fiat",
    "txn_date": "2026-05-21T13:18:00Z",
    "subject": { "vendor_data": "user_3310", "role": "SENDER", "entity_type": "INDIVIDUAL" },
    "counterparty": { "role": "RECEIVER", "entity_type": "INDIVIDUAL" },
    "payment_method": "BANK_TRANSFER"
  }'

Quando a transação completa um padrão de estruturação, a regra de velocidade dispara e a resposta a nomeia:

{
  "transaction_id": "txn_a19f04",
  "status": "IN_REVIEW",
  "risk_score": 66,
  "triggered_rules": [
    {
      "name": "Structuring — cumulative sum near threshold",
      "bundle": "Finance",
      "aggregation": "sum",
      "window": "7d",
      "action": "CHANGE_STATUS"
    }
  ],
  "alert_id": "alrt_b4d8e1"
}

Webhooks. Assine transaction.created e transaction.status.updated para manter seu livro-razão sincronizado conforme os alertas são resolvidos.

Preço. US$ 0,02 por transação, cobrado por chamada, sem mínimos. A triagem AML de uma parte sinalizada é cobrada separadamente a US$ 0,20.

Construindo regras de estruturação e mulas

Estruturação (janela de soma). Combine uma agregação sum em uma janela de 7 dias com uma condição por transação de que o valor esteja logo abaixo do seu limite de relatório. A regra dispara quando os pagamentos cumulativos de um usuário, logo abaixo do limite, ultrapassam uma linha que você definiu — a grande transação agregada que a estruturação pretendia ocultar. Ajuste a proximidade do limite (o quão perto da linha de relatório conta como "logo abaixo") e o gatilho cumulativo.

Smurfing (janela de contagem). Uma agregação count em uma janela curta detecta uma explosão de pequenos pagamentos. "Mais de 10 transferências de saída abaixo de €1.000 em 24 horas" revela o padrão de fragmentação mesmo quando nenhum pagamento único é grande.

Entrada de mula (janela distinta). Uma agregação distinct na contraparte detecta a entrada: "Transferências de entrada de mais de 8 remetentes distintos em 24 horas." Combine-a com uma regra de contagem de saída rápida e você terá descrito a assinatura completa da mula.

Isso se mapeia nos pacotes pré-configurados — estruturação e evasão de limites vivem em Finanças, volume cumulativo e entrada/saída rápida em AML/CTF, picos de velocidade em Detecção de anomalias — e você pode estender qualquer um deles, ou construir o seu próprio, no pacote Personalizado. A ação de cada regra pode adicionar ao score de risco, alterar o status, adicionar tags ou adicionar a parte a uma lista.

Casos de uso

• Fintech — regras de estruturação de soma cumulativa em transferências e saques; regras de mulas de contrapartes distintas em depósitos de entrada.
• Cripto — janelas de contagem em atividade rápida de entrada e saída de carteiras; regras distintas em fundos chegando de muitos endereços antes de uma única grande saída.
• Empréstimos — regras de velocidade em padrões de desembolso e pagamento para detectar fraudes de bust-out.
• Mercados — regras de contagem de compradores distintos para detectar anéis de transação colusivos inflando o volume de um vendedor.
• iGaming — janelas de contagem de velocidade de depósito que também servem como um sinal de jogo responsável.

Como integrar com o Didit

1. Defina as janelas. No Console de Negócios, construa regras de velocidade com a janela, agregação (contagem/soma/distinta) e limite que sua política exige.
2. Envie transações. POST /v3/transactions/ do seu backend conforme o dinheiro se move, com um transaction_id estável e vendor_data para que o motor associe as janelas ao assunto correto.
3. Lide com webhooks. Escute por transaction.status.updated para reagir quando uma regra de velocidade for acionada e um analista resolver o alerta.
4. Ajuste ao longo do tempo. Ajuste os limites no Console à medida que você aprende suas taxas de verdadeiros positivos e falsos positivos — sem necessidade de implantação.

Como tudo está na API unificada /v3/, um usuário integrado com fluxos KYC vai direto para o mesmo motor que executa essas regras de velocidade — uma plataforma de identidade e fraude, de ponta a ponta.

Perguntas frequentes

Quais agregações uma regra de velocidade pode usar?

Três: count (número de transações correspondentes), sum (valor cumulativo) e distinct (contrapartes ou atributos únicos), cada uma avaliada em uma janela de tempo que você define.

Como detecto a estruturação especificamente?

Combine uma agregação sum em uma janela com uma condição de que cada pagamento esteja logo abaixo do seu limite de relatório. A regra dispara quando o total cumulativo ultrapassa a linha que a estruturação pretendia ocultar.

Preciso do meu próprio processador de fluxo?

Não. O motor mantém as janelas contínuas por assunto. Você declara a janela, agregação e limite no Console.

Quanto custa?

US$ 0,02 por transação, cobrado por chamada, sem mínimos. A triagem AML de uma parte sinalizada é cobrada separadamente a US$ 0,20.

Posso construir regras de velocidade que os pacotes pré-configurados não cobrem?

Sim. O pacote Personalizado oferece suporte a condições, janelas de velocidade e agregações para qualquer tipologia exclusiva do seu produto.

Pronto para começar?

Leia a visão geral de Monitoramento de Transações na documentação, veja como ele se encaixa no restante da plataforma na página do produto Monitoramento de Transações e verifique os preços transparentes por chamada na página de preços. Quando estiver pronto, comece gratuitamente — 500 verificações KYC gratuitas por mês e monitoramento de transações a US$ 0,02 por chamada.