Monitoramento de sessão

!Ainda não está aberto para venda. O módulo aparece na tabela de preços com preço e com o selo "Em breve", e o create de flow o recusa até a abertura. O endpoint que recebe os eventos do navegador também ainda não está publicado. O contrato de resposta abaixo é o que o backend já emite, para você planejar a integração.

O módulo sessao_monitor observa o que acontece depois da aprovação. Na sessão já logada do seu site, ele acompanha ações de negócio (depósito, saque, aposta), um sinal de vida a cada trinta minutos, a localização que o navegador conceder e o aparelho. Regras determinísticas rodam no nosso servidor e, quando uma fecha, você recebe um alerta no mesmo webhook assinado de sempre, com o nome da regra, a severidade e a evidência em número.

A janela, o sinal de vida e os eventos são grátis: você paga só pelo achado. É o oposto do modelo por chamada: uma sessão de catorze eventos custa zero até encontrarmos alguma coisa. Cada alerta chega no webhook com a regra e a evidência em número.

// sessao_monitor no check_details: o alerta de sessão
{ "module": "sessao_monitor", "passed": null, "outcome": "pending", "score": 50,
  "data": { "monitoring": {
      "kind": "session_monitor_alert",       // distingue este evento de uma verificação de onboarding
      "alert_id": "mal_01H…",                // id opaco do achado
      "rule": "impossible_travel_session",   // qual regra fechou
      "severity": "high",                    // high | medium (não existe low)
      "evidence": { "distance_km": 412.7,    // a evidência é NUMÉRICA, nunca a coordenada
                    "interval_min": 18,
                    "implied_kmh": 1375.7 } } } }

No resumo checks o módulo sai com o nome da regra que fechou, ou "clean" quando a sessão foi observada e nada fechou. As regras respondem perguntas diferentes e você aciona coisas diferentes em cada uma, então um booleano ali esconderia a informação inteira. As chaves de evidence mudam conforme a rule, e são sempre números do achado.

!O alerta nunca recusa ninguém, e isso é estrutural. O dado vem do navegador do usuário final e é falsificável por construção, então o pior desfecho possível é review: não existe caminho de recusa automática neste módulo, em nenhuma severidade e com nenhuma calibração. E este evento não substitui a verificação de onboarding: se o seu sistema guarda "a última verificação por reference_id", use o kind para não sobrescrever o resultado do KYC com um alerta de sessão.

O que nunca sai no payload: a coordenada (o que viaja é distância, intervalo e velocidade implícita), o endereço de rede e o identificador do aparelho: os dois só existem no nosso banco como derivados por chave secreta, e devolvê-los serviria apenas para alguém testar palpites contra eles.

Não confunda com o monitoring_aml, que reconsulta listas de compliance sobre a pessoa e cobra por mês. Este observa uma sessão no tempo e cobra por achado.

Pronto para integrar? A chave de sandbox sai no painel, logo depois do cadastro. Criar conta grátis