AWAITING_USER: Resolução Automática para Transações Sinalizadas (PT-PT)

A parte mais difícil da monitorização de transações não é detetar o pagamento suspeito — é o que se faz a seguir. Recusá-lo diretamente e bloqueia-se um cliente pagante que pode ser totalmente legítimo. Deixá-lo passar e aceita-se o risco que acabou de ser sinalizado. A maioria das equipas resolve isto com uma fila manual: um analista envia um e-mail ao utilizador, espera dias por um documento, e a transação fica congelada durante todo esse tempo.

A API de Monitorização de Transações da Didit tem um quarto estado construído exatamente para esta lacuna: AWAITING_USER. Em vez de uma aprovação ou recusa binária, uma transação sinalizada pode ser pausada, solicitar uma ação específica ao utilizador — reverificar a identidade, fornecer prova de fundos — e retomar automaticamente no momento em que é validada. A fricção ocorre apenas onde o risco existe, e custa os mesmos 0,02 € por transação como tudo o resto.

Este guia explica como funciona o caminho AWAITING_USER e como integrá-lo no seu fluxo.

Pontos-chave

• AWAITING_USER é um dos quatro estados de transação — juntamente com APPROVED, IN_REVIEW e DECLINED — por isso, a remediação é um resultado de primeira classe, não uma solução alternativa.
• Uma transação sinalizada pausa em vez de falhar, solicita uma ação de "step-up" ao utilizador e retoma automaticamente assim que a ação é concluída.
• O "step-up" pode ser um re-KYC, um carregamento de prova de fundos, ou qualquer passo de verificação gerado na API unificada /v3/.
• Os webhooks impulsionam o ciclo — transaction.status.updated é acionado quando a transação entra e sai de AWAITING_USER.
• O mesmo estado existe na gestão de casos, para que um analista possa mover um alerta para AWAITING_USER e deixar o utilizador resolvê-lo.
• 0,02 € por transação, sem mínimos. Um re-KYC ou verificação AML gerado durante a remediação é faturado à sua taxa publicada.

O que faz o AWAITING_USER

Quando uma regra é acionada, o motor atribui um estado. Três dos quatro são familiares: APPROVED permite a transação, IN_REVIEW abre um alerta para um analista, e DECLINED bloqueia-a. O quarto, AWAITING_USER, faz algo diferente — suspende a transação e sinaliza que o utilizador deve fazer algo antes que possa ser resolvida.

Concretamente: uma transferência aciona uma regra de alto valor ou alta velocidade, o motor retorna AWAITING_USER, a sua aplicação solicita ao utilizador para concluir o passo solicitado (uma nova verificação de vivacidade, um carregamento de documento, uma declaração de origem de fundos), e a sessão de verificação alimenta a plataforma. Uma vez concluído o passo, a transação é reavaliada e passa para APPROVED (ou escala se a nova evidência piorar as coisas). Nenhum analista precisa supervisioná-la.

Porquê é importante

As recusas diretas são caras. Cada bloqueio falso-positivo é um cliente legítimo frustrado, um ticket de suporte e, muitas vezes, uma conta cancelada. Mas deixar passar pagamentos sinalizados é como as empresas acabam em ações de fiscalização. A solução convencional — uma fila de remediação manual — troca um custo por outro: tempo do analista, tempo de resposta lento e uma transação congelada por dias.

AWAITING_USER elimina essa troca. O utilizador faz o trabalho, no momento, no ponto de fricção — exatamente quando está motivado a resolvê-lo porque a sua própria transação está à espera. Deteta o risco, mantém o cliente e não paga a um analista para procurar um documento. É a diferença entre um controlo de conformidade que lhe custa clientes e um que faz o seu trabalho discretamente.

Detalhes técnicos

Uma transação que o motor encaminha para remediação retorna com o estado AWAITING_USER e as regras que a acionaram:

{
  "transaction_id": "txn_77c9e2",
  "status": "AWAITING_USER",
  "risk_score": 71,
  "triggered_rules": [
    { "name": "High-value transfer — first 30 days", "bundle": "AML/CTF", "action": "CHANGE_STATUS" }
  ],
  "required_action": "PROOF_OF_FUNDS",
  "alert_id": "alrt_5e3f10"
}

Reage solicitando ao utilizador e gerando o passo de verificação na API unificada /v3/. Quando o passo é concluído, um webhook informa que a transação avançou:

# webhook payload: transaction.status.updated
{
  "event": "transaction.status.updated",
  "transaction_id": "txn_77c9e2",
  "previous_status": "AWAITING_USER",
  "status": "APPROVED"
}

Webhooks. Subscreva transaction.created e transaction.status.updated. O evento de atualização de estado é acionado tanto quando a transação entra em AWAITING_USER quanto quando sai — para que o seu livro-razão e a sua interface de utilizador permaneçam sincronizados sem necessidade de "polling".

Preço. 0,02 € por transação. O próprio passo de remediação é faturado à sua taxa publicada: um re-KYC às taxas de Verificação de Utilizador, uma verificação AML numa parte sinalizada a 0,20 €.

O ciclo de remediação, passo a passo

1. Acionar uma regra. Uma transação cruza um limite que a sua política diz que deve ser remediada em vez de recusada — por exemplo, uma primeira transferência de alto valor de uma nova conta.
2. Pausar, não falhar. O motor retorna AWAITING_USER em vez de DECLINED, com a ação necessária anexada.
3. Solicitar ao utilizador. A sua aplicação apresenta o "step-up" — uma nova verificação de vivacidade, um carregamento de documento, uma declaração de origem de fundos — e gera a sessão de verificação.
4. O utilizador resolve. O utilizador completa o passo dentro do mesmo fluxo em que já estava.
5. Retomar automaticamente. A transação é reavaliada com a nova evidência e passa para APPROVED — ou escala para IN_REVIEW/DECLINED se a evidência aumentar o risco. Um webhook transaction.status.updated informa o seu backend de qualquer forma.

Como o mesmo estado AWAITING_USER existe na gestão de casos, um analista a trabalhar num alerta IN_REVIEW também pode enviá-lo de volta ao utilizador em vez de o resolver ele próprio — o alerta passa por OPEN → INVESTIGATING → AWAITING_USER e resolve-se assim que o utilizador responde.

Casos de uso

• Fintech — uma primeira transferência de alto valor de uma conta recentemente registada pausa para prova de fundos em vez de bloquear o cliente.
• Cripto — uma transferência de saída para uma carteira com exposição elevada pausa para uma declaração de origem de fundos antes de ser liquidada.
• Empréstimos — um desembolso que aciona um sinal de identidade sintética pausa para uma verificação de vivacidade re-KYC.
• Marketplaces — um pagamento a um vendedor que aciona uma regra de velocidade pausa para reverificação antes da liberação dos fundos.
• iGaming — um pico de velocidade de depósito pausa para uma verificação de "step-up", que funciona também como um ponto de contacto de jogo responsável.

Como integrar com a Didit

1. Decida a sua política de remediação. Na Consola de Negócios, defina quais as regras que encaminham para AWAITING_USER em vez de DECLINED, e qual a ação de "step-up" que cada uma solicita.
2. Envie transações. POST /v3/transactions/ conforme o dinheiro se move, com um transaction_id estável e vendor_data ligando cada um ao seu utilizador.
3. Lide com a pausa. Quando uma transação retorna AWAITING_USER, solicite ao utilizador e gere o passo de verificação na API /v3/.
4. Ouça a retoma. Reaja a transaction.status.updated para liberar ou reter a transação assim que o utilizador concluir o passo.

Como tudo está na API unificada /v3/, o KYC de remediação que uma transação sinalizada gera é o mesmo KYC que utiliza para registar utilizadores — uma plataforma de identidade e fraude, de ponta a ponta.

Perguntas frequentes

O que é AWAITING_USER?

É um dos quatro estados de transação. Em vez de uma recusa direta, uma transação sinalizada pausa e solicita uma ação ao utilizador — reverificação ou prova de fundos — e retoma automaticamente assim que o utilizador a conclui.

A transação retoma por si própria?

Sim. Uma vez concluído o passo solicitado, a transação é reavaliada e passa automaticamente para APPROVED — ou escala se a nova evidência aumentar o risco. Um webhook transaction.status.updated é acionado na alteração.

Qual pode ser o "step-up"?

Qualquer passo de verificação na API unificada /v3/ — uma verificação de vivacidade re-KYC, uma reverificação de documento, uma verificação AML, ou um carregamento de prova de fundos.

Um analista tem de estar envolvido?

Não. O ciclo de auto-remediação funciona sem um analista. Mas o mesmo estado AWAITING_USER existe na gestão de casos, para que um analista também possa enviar um alerta de volta ao utilizador quando assim o desejar.

Quanto custa?

0,02 € por transação. O passo de remediação é faturado à sua própria taxa — um re-KYC às taxas de Verificação de Utilizador, uma verificação AML a 0,20 €.

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