Peça uma prova a mais só no acesso estranho
Em breve A venda deste módulo está em preparação: ele ainda não entra num flow.
A conta tomada entra pela porta da frente, com a senha certa. O que denuncia o invasor é o contexto do acesso: um país que o titular nunca usou, dois logins separados por uma distância impossível, uma senha trocada pouco antes. Este módulo avalia cada evento de conta no instante em que ele acontece e diz se vale pedir mais uma prova.
Avalia na hora um evento de conta que você nos manda (login, login falhado, cadastro, troca de senha, recuperação, troca de e-mail e ação sensível) e devolve allow, step_up ou deny com as razões, para você decidir se pede uma prova a mais antes de deixar passar. Os sinais são publicados pelo nome: viagem impossível entre dois acessos, rajada de logins falhados, país novo para aquele titular, troca de credencial recente, rede de hospedagem, risco do IP, titular sem identidade verificada aqui e conta dormente que volta. A comparação é com o histórico do próprio titular na sua base (países, ASNs, horários e a velocidade entre os eventos), nunca com o de outro cliente. Não compramos reputação de IP de terceiro: os sinais saem da nossa base GeoIP local e do seu próprio histórico. Não bloqueamos ninguém: deny sai como revisão e step_up nunca aprova sozinho, e quem aplica qualquer consequência sobre a conta é você. Não é o Gate transacional, que avalia um pagamento, nem o Monitoramento de sessão, que observa a sessão já logada.
- Proteção de contaEm breve
"status": "approved"Para quem é
Serve a quem guarda saldo, dado ou benefício atrás de um login: bancos digitais, carteiras, programas de fidelidade e plataformas de assinatura. Nesses produtos a tomada de conta costuma custar mais do que a fraude de cadastro, porque o invasor herda um relacionamento já aprovado.
Cobre os momentos em que o ataque costuma aparecer: login, login com falha, cadastro, troca de senha, recuperação de acesso, troca de e-mail e ação sensível. O seu backend chama o módulo nesses pontos e decide, com a resposta, se deixa seguir ou se pede confirmação.
O que você recebe
A resposta vem no bloco account, separado do KYC para que um veredito de login nunca sobrescreva o resultado do onboarding no seu banco. Ele traz verdict, risk_score, reasons com os códigos que dispararam, como new_country ou impossible_travel, e o type do evento avaliado.
São três vereditos e nenhum bloqueia. allow diz que nada destoa. step_up pede mais uma prova e chega com step_up_session_id, uma sessão de verificação pronta para você usar nesse pedido. deny é o grau mais alto e ainda assim sai como revisão: quem aplica consequência sobre a conta é você.
Informação que não pôde ser avaliada aparece declarada, nunca como limpa. O e-mail descartável é o exemplo: você informa account_event.disposable_email quando souber, e sem o campo a razão volta como disposable_email_unknown.
O módulo conta é um gate síncrono de risco sobre eventos de conta, como login, troca de senha e recuperação de acesso.
O módulo se chama conta no flow e no webhook.
Como entra no seu flow
A comparação é com o passado do próprio titular na sua base, sem histórico de outro cliente no meio. Mande sempre o mesmo reference_id para a mesma pessoa, porque é por ele que o histórico se acumula e o contexto de cada acesso fica mais nítido.
O grupo do módulo
Sinais de risco da sessão, sem passo novo para o usuário.
Preço
R$ 0,05por evento de contaEm breve
A venda está em preparação e o valor acima é o de catálogo. Módulo marcado como "Em breve" não está à venda e não pode ser adicionado a um flow hoje.
Tentativa de login com falha não é cobrada: o evento login_failed é avaliado e responde normalmente, mas sai do preço. Os outros seis tipos de evento são cobrados por evento avaliado.
O valor é lido do mesmo catálogo que o painel usa para montar um flow, somando os módulos que este exige, se exigir. Ver preços.
Perguntas frequentes
Ler a documentaçãoTentativa de login com falha entra na fatura?
Não. O evento login_failed é avaliado, alimenta o histórico e ajuda a revelar a tentativa de força bruta, mas sai do preço com billable: false. Cobrar por ele deixaria o atacante gastar o seu saldo.
O módulo substitui o meu segundo fator?
Não. Ele não autentica nem emite código: diz quando vale pedir a prova, e a escolha da prova, a tela e o login continuam sendo seus. A sessão de step_up_session_id é uma opção pronta, e não uma obrigação.
Qual a diferença para o Monitoramento de sessão?
Este responde a um evento pontual e termina ali. O Monitoramento de sessão acompanha a sessão já logada ao longo do tempo. Para pagamento, o módulo certo é o Gate Transacional, que julga a transação parada esperando liberação.
Crie a conta, monte um flow com os módulos que já estão à venda e rode a verificação inteira no ambiente de teste, sem consumir saldo.
