Fluxo de Trabalho SAR Sem Ferramenta de Caso Separada (PT-BR)

Um disparo de regra é a parte fácil. O que acontece depois — o alerta, a investigação, a escalada, a decisão de registrar um Relatório de Atividade Suspeita (SAR) — é onde a maioria das operações de conformidade realmente vive, e onde a maior parte do custo se esconde. A configuração típica une três coisas: um fornecedor de monitoramento que produz alertas, uma ferramenta separada de gerenciamento de casos que mantém a investigação, e um processo manual de SAR que muitas vezes termina em uma planilha e um PDF. Os dados são redigitados entre os sistemas, o rastro de auditoria se fragmenta, e os analistas passam o dia trocando de abas.

A API de Monitoramento de Transações do Didit entrega todo o fluxo de trabalho em um único produto. Quando uma regra é acionada, um alerta é aberto; os alertas são agrupados em casos; os analistas são atribuídos; e o SAR é registrado a partir do mesmo console onde o alerta foi gerado. Não há uma ferramenta de caso separada para licenciar, integrar ou conciliar — e as transações que a alimentam custam US$ 0,02 cada.

Este guia descreve o fluxo de trabalho desde uma regra acionada até um SAR registrado.

Principais conclusões

• Os alertas são abertos automaticamente quando uma regra é acionada e seguem um ciclo de vida definido: OPEN (ABERTO), INVESTIGATING (INVESTIGANDO), AWAITING_USER (AGUARDANDO USUÁRIO), PENDING_SAR (SAR PENDENTE), SAR_FILED (SAR REGISTRADO), RESOLVED (RESOLVIDO), DISMISSED (IGNORADO).
• Os casos agrupam alertas relacionados, carregam prioridade e gravidade, e acompanham uma investigação através de OPEN (ABERTO), UNDER_REVIEW (EM REVISÃO), AWAITING_USER (AGUARDANDO USUÁRIO), ON_HOLD (EM ESPERA) e RESOLVED (RESOLVIDO).
• Os analistas são atribuídos a alertas e casos, para que a propriedade e o desempenho sejam mensuráveis.
• O registro de SAR reside no mesmo console que o alerta — sem exportação para uma ferramenta separada, sem dados redigitados.
• O caminho AWAITING_USER permite que um analista envie um alerta de volta ao usuário para correção, em vez de resolvê-lo manualmente.
• US$ 0,02 por transação, sem mínimos. A triagem AML de uma parte sinalizada é faturada separadamente a US$ 0,20.

O que o fluxo de trabalho de gerenciamento de casos faz

O monitoramento de transações produz sinais; o gerenciamento de casos os transforma em decisões defensáveis. Cada alerta no Didit carrega uma fonte — acionado por regra, acionado por provedor ou criado por analista — e um status que reflete sua posição na investigação. Um analista abre o alerta, revisa a transação e as regras que foram acionadas, e decide: descartá-lo como um falso positivo, resolvê-lo, escalá-lo para um caso, enviá-lo de volta ao usuário ou encaminhá-lo para um SAR.

Os casos são o contêiner para qualquer coisa maior que um único alerta. Vários alertas sobre o mesmo usuário — um pico de velocidade na segunda-feira, um acerto de contraparte sancionada na quarta-feira — agrupam-se em um único caso que contém o panorama completo, com sua própria prioridade e gravidade. O caso é o que um investigador trabalha, e o caso é o que documenta a decisão da empresa.

Por que isso importa

Os reguladores não esperam apenas que você detecte atividades suspeitas — eles esperam que você as investigue e as reporte, e que apresente um rastro de auditoria claro de como você passou do alerta à decisão. Uma pilha fragmentada trabalha contra você em todos os aspectos. Redigitar dados entre um fornecedor de monitoramento e uma ferramenta de caso introduz erros. Um processo de SAR em planilha é impossível de auditar e lento para defender. E cada junção de integração é um lugar onde um alerta pode se perder.

Colapsar a pilha em um único produto resolve o problema operacional e regulatório de uma vez. O alerta, a investigação, o analista que o possuiu e o SAR, tudo reside no mesmo registro. O rastro de auditoria é contínuo porque nada sai do sistema. E o custo escala com as transações, não com licenças por assento para uma ferramenta de caso que você também precisa manter.

Detalhes técnicos

Quando uma regra é acionada em uma transação, a resposta carrega o status e um alert_id:

{
  "transaction_id": "txn_3c81f0",
  "status": "IN_REVIEW",
  "risk_score": 64,
  "triggered_rules": [
    { "name": "Sanctioned counterparty", "bundle": "AML/CTF", "action": "CHANGE_STATUS" }
  ],
  "alert_id": "alrt_77a920"
}

A transação em si é criada 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_3c81f0",
    "category": "finance",
    "amount": 24000,
    "currency": "EUR",
    "currency_kind": "fiat",
    "txn_date": "2026-05-21T14:50:00Z",
    "subject": { "vendor_data": "user_6610", "role": "SENDER", "entity_type": "INDIVIDUAL" },
    "counterparty": { "role": "RECEIVER", "entity_type": "INDIVIDUAL" }
  }'

Status de alerta. OPEN → INVESTIGATING → (AWAITING_USER) → PENDING_SAR → SAR_FILED, ou termina em RESOLVED ou DISMISSED.

Status de caso. OPEN, UNDER_REVIEW, AWAITING_USER, ON_HOLD, RESOLVED.

Webhooks. Assine transaction.created e transaction.status.updated para que seus sistemas permaneçam sincronizados enquanto um analista move um alerta através do fluxo de trabalho.

Preço. US$ 0,02 por transação. A triagem AML executada em uma parte sinalizada durante uma investigação é faturada separadamente a US$ 0,20.

Do alerta ao SAR registrado

1. Alerta aberto. Uma regra é acionada, a transação entra em IN_REVIEW, e um alerta é aberto no estado OPEN com as regras de acionamento anexadas.
2. Analista assume. O alerta passa para INVESTIGATING e é atribuído a um analista, que revisa o histórico da transação, o contexto de velocidade e qualquer triagem AML.
3. Escalar ou remediar. O analista agrupa alertas relacionados em um caso, ou envia o alerta para AWAITING_USER para que o cliente possa esclarecê-lo com prova de fundos ou uma nova verificação.
4. Decidir sobre um SAR. Se a atividade justificar o relatório, o alerta passa para PENDING_SAR, o SAR é preparado no mesmo console, e ao registrar o alerta passa para SAR_FILED.
5. Finalizar. Alertas que não justificam ação são resolvidos como DISMISSED (falso positivo) ou RESOLVED. Todo o rastro — quem decidiu o quê, quando — permanece registrado.

Como os alertas podem passar para AWAITING_USER, a investigação e o ciclo de autorremediação compartilham a mesma superfície: um analista pode devolver um alerta limítrofe ao usuário em vez de gastar tempo com ele, e o alerta é retomado automaticamente assim que o usuário responde.

Casos de uso

• Fintech — agrupe alertas de velocidade, estruturação e sanções em uma única conta em um único caso antes de decidir sobre um SAR.
• Cripto — investigue alertas levantados por exposição em triagem de carteira juntamente com a velocidade on-chain no mesmo arquivo de caso.
• Empréstimos — trabalhe alertas de padrões de fraude (mula, identidade sintética) até uma decisão documentada sem uma segunda ferramenta.
• Marketplaces — consolide alertas de abuso de reembolso e estorno em um vendedor em um caso, depois registre ou descarte.
• iGaming — gerencie alertas de jogos responsáveis e AML em um único fluxo de trabalho, com propriedade do analista e um rastro de auditoria.

Como integrar com o Didit

1. Ative seus pacotes. No Console de Negócios, habilite os pacotes de regras que se adequam ao seu negócio para que os alertas sejam abertos contra as tipologias corretas.
2. Envie transações. POST /v3/transactions/ à medida que o dinheiro se move, com um transaction_id estável e vendor_data vinculando cada um ao seu usuário ou entidade.
3. Trabalhe alertas no Console. Investigue, atribua analistas, agrupe alertas em casos e registre SARs — tudo na mesma interface.
4. Sincronize com webhooks. Ouça transaction.status.updated para que seus próprios sistemas reflitam as mudanças de estado de alerta e caso.

Como tudo está na API unificada /v3/, uma sessão KYB pode gerar as sessões KYC para seus UBOs, esses usuários fluem para o monitoramento de transações, e uma transação sinalizada pode gerar um KYC de remediação — uma plataforma de identidade e fraude, de ponta a ponta.

Perguntas frequentes

Preciso de uma ferramenta separada de gerenciamento de casos?

Não. Alertas, casos, atribuição de analistas, estados de investigação e registro de SAR são integrados ao mesmo produto e console.

Por quais estados um alerta passa?

OPEN, INVESTIGATING, AWAITING_USER, PENDING_SAR, SAR_FILED, RESOLVED e DISMISSED. Os casos passam por OPEN, UNDER_REVIEW, AWAITING_USER, ON_HOLD e RESOLVED.

Posso atribuir alertas a analistas específicos?

Sim. Alertas e casos são atribuídos a analistas, para que a propriedade seja clara e o desempenho mensurável.

Onde o SAR é registrado?

No mesmo console onde o alerta foi gerado. Não há exportação para uma ferramenta separada e nenhum dado é redigitado, o que mantém o rastro de auditoria contínuo.

Qual o custo?

US$ 0,02 por transação, cobrado por chamada sem mínimos. A triagem AML executada em uma parte sinalizada durante uma investigação é faturada separadamente a US$ 0,20.

Pronto para começar?

Leia a visão geral do 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 todos os meses e monitoramento de transações a US$ 0,02 por chamada.