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

Um disparo de regra é a parte fácil. O que acontece depois — o alerta, a investigação, a escalada, a decisão de apresentar 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 junta três coisas: um fornecedor de monitorização que produz alertas, uma ferramenta de gestão de casos separada que detém a investigação, e um processo SAR manual que muitas vezes termina numa folha de cálculo e um PDF. Os dados são reintroduzidos entre sistemas, o registo de auditoria fragmenta-se e os analistas passam o dia a mudar de separadores.

A API de Monitorização de Transações da Didit envia todo o fluxo de trabalho num único produto. Quando uma regra é acionada, um alerta é aberto; os alertas agrupam-se em casos; os analistas são atribuídos; e o SAR é registado a partir da mesma consola onde o alerta foi levantado. Não há uma ferramenta de caso separada para licenciar, integrar ou reconciliar — e as transações que a alimentam custam 0,02€ cada.

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

Principais conclusões

• Os alertas abrem automaticamente quando uma regra é acionada e movem-se através de um ciclo de vida definido: OPEN, INVESTIGATING, AWAITING_USER, PENDING_SAR, SAR_FILED, RESOLVED, DISMISSED.
• Os casos agrupam alertas relacionados, carregam prioridade e gravidade, e acompanham uma investigação através de OPEN, UNDER_REVIEW, AWAITING_USER, ON_HOLD e RESOLVED.
• Os analistas são atribuídos a alertas e casos, para que a propriedade e o desempenho sejam mensuráveis.
• O registo de SAR reside na mesma consola que o alerta — sem exportação para uma ferramenta separada, sem dados reintroduzidos.
• O caminho AWAITING_USER permite que um analista envie um alerta de volta ao utilizador para remediação em vez de o resolver manualmente.
• 0,02€ por transação, sem mínimos. A triagem AML de uma parte sinalizada é faturada separadamente a 0,20€.

O que faz o fluxo de trabalho de gestão de casos

A monitorização de transações produz sinais; a gestão de casos transforma-os em decisões defensáveis. Cada alerta na Didit tem uma origem — acionado por regra, acionado por fornecedor ou criado por analista — e um estado que reflete onde se situa na investigação. Um analista abre o alerta, revê 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 utilizador ou encaminhá-lo para um SAR.

Os casos são o contentor para algo maior do que um único alerta. Vários alertas sobre o mesmo utilizador — um pico de velocidade na segunda-feira, um contacto com uma contraparte sancionada na quarta-feira — agrupam-se num único caso que contém a imagem completa, com a sua própria prioridade e gravidade. O caso é o que um investigador trabalha, e o caso é o que documenta a decisão da empresa.

Porquê é importante

Os reguladores não esperam apenas que detete atividades suspeitas — esperam que as investigue e as reporte, e que apresente um registo de auditoria claro de como passou do alerta à decisão. Uma arquitetura fragmentada trabalha contra si em todos os aspetos. A reintrodução de dados entre um fornecedor de monitorização e uma ferramenta de caso introduz erros. Um processo SAR em folha de cálculo é impossível de auditar e lento de defender. E cada ponto de integração é um local onde um alerta pode falhar.

Colapsar a arquitetura num único produto resolve o problema operacional e regulatório de uma só vez. O alerta, a investigação, o analista que o detinha e o SAR vivem todos no mesmo registo. O registo de auditoria é contínuo porque nada sai do sistema. E o custo escala com as transações, não com licenças por posto para uma ferramenta de caso que também tem de manter.

Detalhes técnicos

Quando uma regra é acionada numa transação, a resposta contém o estado 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 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_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" }
  }'

Estados do alerta. OPEN → INVESTIGATING → (AWAITING_USER) → PENDING_SAR → SAR_FILED, ou terminar em RESOLVED ou DISMISSED.

Estados do caso. OPEN, UNDER_REVIEW, AWAITING_USER, ON_HOLD, RESOLVED.

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

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

Do alerta ao SAR registado

1. O alerta abre. Uma regra é acionada, a transação entra em IN_REVIEW, e um alerta abre no estado OPEN com as regras acionadoras anexadas.
2. O analista assume. O alerta move-se para INVESTIGATING e é atribuído a um analista, que revê o histórico de transações, o contexto de velocidade e qualquer triagem AML.
3. Escalar ou remediar. O analista agrupa alertas relacionados num caso, ou envia o alerta para AWAITING_USER para que o cliente possa resolvê-lo com prova de fundos ou uma nova verificação.
4. Decidir sobre um SAR. Se a atividade justificar o relatório, o alerta move-se para PENDING_SAR, o SAR é preparado na mesma consola, e após o registo o alerta move-se para SAR_FILED.
5. Concluir. Alertas que não justificam ação resolvem-se como DISMISSED (falso positivo) ou RESOLVED. Todo o registo — quem decidiu o quê, quando — permanece no registo.

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

Casos de uso

• Fintech — agrupar alertas de velocidade, estruturação e sanções numa única conta num caso antes de decidir sobre um SAR.
• Cripto — investigar alertas levantados por exposição de triagem de carteira juntamente com velocidade on-chain no mesmo arquivo de caso.
• Empréstimos — trabalhar alertas de padrões de fraude (mula, identidade sintética) até uma decisão documentada sem uma segunda ferramenta.
• Marketplaces — consolidar alertas de abuso de reembolso e estorno num vendedor num caso, depois registar ou descartar.
• iGaming — gerir alertas de jogo responsável e AML num único fluxo de trabalho, com propriedade do analista e um registo de auditoria.

Como integrar com a Didit

1. Ative os seus pacotes. Na Consola de Negócios, ative os pacotes de regras que se adequam ao seu negócio para que os alertas abram 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 ligando cada um ao seu utilizador ou entidade.
3. Trabalhe alertas na Consola. Investigue, atribua analistas, agrupe alertas em casos e registe SARs — tudo a partir da mesma superfície.
4. Sincronize com webhooks. Ouça transaction.status.updated para que os seus próprios sistemas reflitam as alterações de estado do alerta e do caso.

Como tudo está na API unificada /v3/, uma sessão KYB pode gerar as sessões KYC para os seus UBOs, esses utilizadores fluem para a monitorização 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 de gestão de casos separada?

Não. Alertas, casos, atribuição de analistas, estados de investigação e registo de SAR estão integrados no mesmo produto e consola.

Por que 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 é registado o SAR?

Na mesma consola onde o alerta foi levantado. Não há exportação para uma ferramenta separada e não há dados reintroduzidos, o que mantém o registo de auditoria contínuo.

Quanto custa?

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

Pronto para começar?

Leia a visão geral da 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.