Monitoramento contínuo
O módulomonitoring_aml é o único que não roda durante uma verificação. Depois que o titular foi aprovado, ele fica sob vigilância nas mesmas listas de PEP e de sanções do pep_sanctions, e quando o nome dele aparece numa lista em que não constava no onboarding, nós criamos uma verificação de acompanhamento e mandamos o webhook. Nenhuma captura nova, nenhum passo para o titular. A cobrança é por titular monitorado por mês, e os alertas entre as reconciliações já estão inclusos.
Disponível desde 11 de setembro de 2026, a 10 centavos por titular por mês. Ele aparece na tabela de preços e no GET /v1/capabilities com preço e status available.
Atenção a como ele se liga, porque não é como os outros: ele não é item do array modules de um flow, e pedir isso continua sendo recusado. Quem liga o monitoramento é o campo monitoring_enabled do flow, em POST /v1/flows e em PATCH /v1/flows/{id}, ou o bloco monitoring da criação da sessão. Esses campos deixaram de responder 422 monitoring_unavailable: agora são aceitos. A razão de ele ficar fora da lista de módulos é que ele não é etapa da verificação: nada dele roda enquanto o titular está na jornada.
changes é o delta, e hits_total é o total. Os dois quase nunca batem, e isso é o desenho: o alerta existe para dizer o que mudou, não para reenviar a triagem inteira toda vez. Um titular com três hits antigos e um novo chega com changes de tamanho 1 e hits_total 4. origin_verification_id é a verificação de onboarding que inscreveu o titular, e é por ela que você liga o alerta ao cadastro no seu lado. dataset_versions é opcional de verdade: a chave só aparece na varredura periódica, e some no alerta em tempo real.
Você só recebe evento quando algo mudou. A varredura que não encontra novidade nenhuma não emite webhook: ela registra internamente que o titular continua limpo e segue. Ou seja, não existe um “pulso” periódico de tranquilidade chegando no seu endpoint, e silêncio aqui significa nada mudou. Se você precisa provar diligência continuada numa data específica, a fonte disso é o painel, não a ausência de webhook.
Avisos de ciclo de vida. Além do alerta, o mesmo verification.monitoring carrega os seis avisos de que a assinatura do titular mudou de estado. Eles chegam como verificação failed, sem checks e sem cobrança, e o que os distingue é o decision_reason: monitor_paused_no_credits e monitor_paused_source_unavailable (a varredura parou, e retoma sozinha), monitor_resumed (voltou), monitor_ended_window (a janela acabou), monitor_ended_erased (o titular foi apagado a pedido dele) e monitor_ended_client (você encerrou). Tratar esses seis como alerta faria a sua fila de revisão encher de eventos que não são achado nenhum.
A carteira, a janela de cada titular e o encerramento ficam no painel, em Monitoramento: é lá que você vê quem está sendo verificado, até quando, quando foi a última varredura de cada um, e é de lá que se encerra o monitoramento de alguém.
O alerta nunca decide: ele sai sempre como revisão, com a evidência minimizada, e quem julga é você. E vale a mesma minimização do pep_sanctions: hit por nome traz fonte, lista, scores, datas e uma referência opaca, sem nome, documento ou texto livre do terceiro.