Proteção de conta

!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. A trava não é técnica: é jurídica, e é a mesma do módulo Sinais do aparelho. Os sinais que dependem de device.fingerprint precisam do teste de balanceamento do legítimo interesse (art. 7º IX da LGPD), da transparência ao titular e de um mecanismo real de oposição antes de poderem pesar. O contrato de resposta abaixo é o que o backend já emite, para você planejar a integração.

O módulo conta é um gate síncrono de risco sobre um evento de conta: seu backend nos manda o evento e recebe na hora um veredito explicável, para decidir se pede uma prova a mais antes de deixar a ação seguir. São sete tipos de evento: login, login falhado, cadastro, troca de senha, recuperação de acesso, troca de e-mail e ação sensível.

!Este não é o módulo da seção acima, nem o da seção antes dela. O transacao avalia um pagamento parado esperando liberação. O transacao_monitor varre a janela de transações depois, sem ninguém esperando. O conta avalia um acesso, no instante em que ele acontece. E ele também não é o sessao_monitor: aquele observa a sessão já logada ao longo do tempo; este responde a um evento pontual e termina ali. São quatro produtos diferentes, com preços diferentes e payloads diferentes.

Os sinais da v1 são publicados pelo nome porque um gate que não diz o que olha é uma caixa preta: impossible_travel (dois acessos separados por uma distância que não dá para vencer no tempo entre eles), failed_login_burst (rajada de logins falhados), new_country (país que nunca apareceu para aquele titular), recent_credential_change (a credencial mudou há pouco), hosting_asn (o IP é de rede de hospedagem, não de acesso residencial ou móvel), ip_risk (o risco do próprio IP), no_verified_identity (o titular nunca fez onboarding com você aqui), dormant_reactivation (conta parada há muito tempo que volta a se mexer), new_isp (a operadora de rede nunca apareceu para aquele titular), odd_hour (horário sem nenhum acesso anterior no histórico dele), ip_shared (o mesmo IP falhando contra várias contas suas na mesma janela) e disposable_email (você nos declarou que o e-mail da conta é de domínio descartável).

disposable_email é o único que depende de você: mande account_event.disposable_email como true ou false quando souber. Sem o campo, o sinal não vira "e-mail limpo": ele volta em reasons como disposable_email_unknown, que é como declaramos todo sinal que não foi possível medir.

A comparação é com o histórico do próprio titular na sua base: países, ASNs, horários e a velocidade entre eventos consecutivos, tudo isolado por cliente. Não há consórcio: o histórico de outro cliente nunca entra na conta. Não compramos reputação de IP de terceiro: o país e o ASN saem da nossa base GeoIP local, e o resto sai do que você mesmo nos mandou.

// conta no check_details: um login pedindo prova adicional
{ "module": "conta", "passed": null, "outcome": "pending", "score": 40,
  "data": {
    "account": {
      "verdict": "step_up",
      "risk_score": 60,
      "reasons": ["new_country", "impossible_travel"],
      "type": "login",
      "step_up_session_id": "vs_..."
    }
  } }

Repare que o data é aninhado sob account. É a mesma razão do sessao_monitor e do transacao_monitor: o evento chega no mesmo verification.completed do onboarding, e um integrador que guarda "a última verificação por reference_id" sobrescreveria o KYC daquele titular com um veredito de login. Com a chave própria, o KYC e o acesso nunca disputam o mesmo lugar no seu banco.

São três vereditos, e nenhum deles bloqueia. allow é "nada anormal". step_up é "peça mais uma prova antes de deixar entrar", nunca um não, e ele jamais vira approved: step_up_session_id vem junto e é a sessão de verificação que você pode usar para pedir essa prova. deny é o corte mais alto, e mesmo ele sai do nosso motor como revisão. O pior desfecho que emitimos é revisar, e quem aplica qualquer consequência sobre a conta é você.

!O campo device.fingerprint é opcional. Ele é aceito no contrato de entrada e está descrito na referência da API, e o módulo decide com ou sem ele: a avaliação do evento de conta não depende desse campo para sair completa. É a mesma trava jurídica do módulo Sinais do aparelho, que continua pausado enquanto o pacote do legítimo interesse não fechar (o teste de balanceamento do art. 7º IX, a transparência e o mecanismo de oposição). Qualquer mudança no que o campo passa a valer é anunciada no changelog, nunca silenciosa.

O que este módulo não faz. Ele não bloqueia ninguém, como acabou de ser dito. Ele não autentica e não emite segundo fator: o step_up é uma recomendação, e quem pede a prova, escolhe qual é e opera o próprio login continua sendo você. Ele não consulta bureau nem compra reputação de IP. E ele não observa a sessão depois: terminado o evento, o módulo não tem mais nada a dizer sobre aquele titular até o próximo evento chegar.

A unidade cobrada é o evento de conta avaliado, e não a verificação nem o titular por mês. Um mesmo titular que faz vinte logins no mês gera vinte eventos avaliados, e a tabela de preços imprime a unidade ao lado do valor para a conta fechar antes da integração.

Tentativa de login com falha não é cobrada. O evento login_failed é avaliado, entra no histórico do titular e alimenta a rajada de logins falhados, mas sai do preço: ele é o rastro do ataque que a sua base sofre, e cobrar por ele faria o atacante gastar o seu saldo. A verificação dele sai com billable: false. E um 402 por saldo insuficiente num fluxo com este módulo nunca aciona a recarga automática do seu cartão.

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