# Proteção de conta ## Proteção de conta ! **Ainda não está aberto para venda.** O módulo aparece na [tabela de preços](https://unifokal.com/precos) 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](https://unifokal.com/precos) 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.