Regras de Velocidade e Deteção de Estruturação: Um Guia para Developers (PT-PT)

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 de vinte contas distintas numa tarde, são as assinaturas de estruturação e atividade de "mula". Capturá-los exige olhar para as transações como um fluxo — ao longo do tempo, com contagem e soma — não uma de cada vez.

É isso que as regras de velocidade fazem, e são a parte mais difícil da monitorização de transações para construir por conta própria. Precisa de um processador de fluxo que mantenha janelas contínuas por utilizador, conte e some e deduplique contrapartes dentro dessas janelas, e avalie limiares em tempo real. A API de Monitorização de Transações do Didit oferece-lhe esse motor pronto a usar: defina uma janela, escolha uma agregação — contagem, soma ou distinta — defina um limiar, e a regra é executada contra cada transação por 0,02 € por transação.

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

Principais pontos

• As regras de velocidade avaliam em 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 (montante cumulativo) e distinct (contrapartes ou atributos únicos) — os blocos de construção da deteção de estruturação e "mula".
• A estruturação — muitos pagamentos logo abaixo de um limiar de reporte — é detetada combinando uma janela de soma com uma condição de proximidade ao limiar.
• Os padrões de "mula" e smurfing são detetados com contagens de contrapartes distintas dentro de uma janela.
• Não é necessário um processador de fluxo — o motor mantém as janelas; declara a regra na Consola.
• 0,02 € por transação, sem mínimos. A triagem AML numa parte sinalizada é cobrada separadamente a 0,20 €.

O que são regras de velocidade

Uma regra de velocidade tem três partes: uma janela (o período de retrospetiva — 1 hora, 24 horas, 7 dias), uma agregação sobre as transações nessa janela e um limiar que, quando excedido, aciona uma ação. As agregações são o núcleo 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, por predefinição, chaveadas por sujeito — cada utilizador tem os seus próprios contadores contínuos — para que um dia agitado para toda a sua plataforma não afogue o sinal de um utilizador individual.

Porquê é importante

A estruturação (também chamada de smurfing) é uma das técnicas de lavagem mais antigas e uma das mais explicitamente reguladas. Os limiares de reporte — 10.000 € em grande parte da UE, 10.000 $ nos EUA — criam um incentivo para dividir grandes somas em pagamentos menores que ficam abaixo do limite. Uma regra pontual que apenas verifica valores únicos nunca o verá; todo o padrão reside no agregado.

O mesmo se aplica às redes de "mula". O sinal 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. Só se vê com contagens de contrapartes distintas ao longo de uma janela. Os reguladores esperam que as empresas detetem estas tipologias, e as regras de velocidade são a forma de o fazer sem montar a sua própria "stack" de análise de transmissão.

Detalhes técnicos

As transações são criadas contra a API unificada /v3/, idempotente num transaction_id que 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 é acionada e a resposta nomeia-o:

{
  "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. Subscreva transaction.created e transaction.status.updated para manter o seu livro-razão sincronizado à medida que os alertas são resolvidos.

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

Construir regras de estruturação e "mula"

Estruturação (janela de soma). Combine uma agregação sum sobre uma janela de 7 dias com uma condição por transação de que o montante se situe logo abaixo do seu limiar de reporte. A regra é acionada quando os pagamentos cumulativos de um utilizador, logo abaixo do limiar, somam um valor que excede uma linha que definiu — a grande transação agregada que a estruturação pretendia esconder. Ajuste a proximidade do limiar (quão perto da linha de reporte conta como "logo abaixo") e o gatilho cumulativo.

Smurfing (janela de contagem). Uma agregação count sobre uma janela curta deteta um pico 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 individual é grande.

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

Estas regras mapeiam-se para os pacotes predefinidos — estruturação e evasão de limiares residem em Finanças, volume cumulativo e entrada/saída rápida em AML/CTF, picos de velocidade em Deteção de anomalias — e pode estender qualquer um deles, ou construir os seus próprios, no pacote Personalizado. A ação de cada regra pode adicionar à pontuação de risco, alterar o estado, adicionar etiquetas ou adicionar a parte a uma lista.

Casos de uso

• Fintech — regras de estruturação de soma cumulativa em transferências e levantamentos; regras de "mula" de contrapartes distintas em depósitos de entrada.
• Cripto — janelas de contagem em atividade rápida de entrada e saída de carteira; regras distintas em fundos que chegam de muitos endereços antes de uma única grande saída.
• Empréstimos — regras de velocidade em padrões de desembolso e reembolso para detetar fraudes de "bust-out".
• Mercados — regras de contagem de compradores distintos para detetar anéis de transações colusivas que inflacionam o volume de um vendedor.
• iGaming — janelas de contagem de velocidade de depósito que servem como um sinal de jogo responsável.

Como integrar com o Didit

1. Defina as janelas. Na Consola de Negócios, construa regras de velocidade com a janela, agregação (contagem/soma/distinta) e limiar que a sua política exige.
2. Envie transações. POST /v3/transactions/ do seu backend à medida que o dinheiro se move, com um transaction_id estável e vendor_data para que o motor associe as janelas ao sujeito correto.
3. Lide com webhooks. Oiça por transaction.status.updated para reagir quando uma regra de velocidade é acionada e um analista resolve o alerta.
4. Ajuste ao longo do tempo. Ajuste os limiares na Consola à medida que aprende as suas taxas de verdadeiros positivos e falsos positivos — sem necessidade de implementação.

Como tudo está na API unificada /v3/, um utilizador integrado com fluxos KYC entra diretamente no mesmo motor que executa estas regras de velocidade — uma plataforma de identidade e fraude, de ponta a ponta.

Perguntas frequentes

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

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

Como deteto especificamente a estruturação?

Combine uma agregação sum sobre uma janela com uma condição de que cada pagamento se situe logo abaixo do seu limiar de reporte. A regra é acionada quando o total cumulativo excede a linha que a estruturação pretendia esconder.

Preciso do meu próprio processador de fluxo?

Não. O motor mantém as janelas contínuas por sujeito. Declara a janela, agregação e limiar na Consola.

Quanto custa?

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

Posso construir regras de velocidade que os pacotes predefinidos não cobrem?

Sim. O pacote Personalizado suporta condições, janelas de velocidade e agregações para qualquer tipologia única do seu produto.

Pronto para começar?

Leia a visão geral de Monitorização de Transações na documentação, veja como se encaixa no resto da plataforma na página do produto Monitorização 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 todos os meses, e monitorização de transações a 0,02 € por chamada.