Casos de uso

Verificar os dados de endereço de identidade no cadastro de uma fintech

Abrir uma conta em um banco digital envolve uma série de verificações de identidade, verificação de documentos, triagem de sanções e comprovante de endereço, executadas em sequência porque cada uma tem um custo real em tempo e às vezes em dinheiro, e faz sentido executar primeiro as verificações mais baratas e rápidas para filtrar as solicitações obviamente quebradas antes de gastar esforço com as caras.

A plausibilidade do endereço acabou sendo uma das verificações mais baratas e iniciais que um banco digital podia executar. Antes que uma solicitação avançasse para o envio de documentos e a verificação de identidade, o endereço que o novo cliente tinha digitado no formulário de cadastro passava por duas verificações rápidas. /v1/forward tentava encontrar a correspondência do endereço e informava com que confiança ele foi resolvido, detectando casos em que o nome da rua não existia, o endereço estava incompleto ou o formato não correspondia a nenhum local real. /v1/postcode verificava o código postal informado em relação à cidade e à região também informadas, detectando o erro específico e comum de um código postal copiado de outro local ou simplesmente digitado errado.

Nenhuma das verificações determina sozinha se alguém é quem diz ser, e o banco deixava claro internamente que essa etapa não substituía a verificação de identidade e o processo de conheça seu cliente (KYC) que vinham depois. O que ela fazia era detectar a baixo custo uma categoria de solicitação que, de outra forma, desperdiçaria o tempo das etapas posteriores mais caras: um endereço que não poderia ser real não precisa seguir para a análise de documentos, e sinalizá-lo na etapa de endereço, em segundos, economizava o custo de executar uma verificação mais completa em uma solicitação que ia falhar de qualquer forma.

As solicitações com um endereço limpo e bem formado seguiam direto para a fila padrão de verificação de identidade. As solicitações com um endereço que não era resolvido, ou em que o código postal e a cidade claramente divergiam, eram sinalizadas para um aviso rápido de correção ao solicitante ou, se o padrão parecesse mais deliberado do que acidental, direto para a análise manual de fraude em vez da fila padrão.

O banco mantinha um limite interno claro sobre a finalidade dessa etapa. A plausibilidade do endereço é um sinal de qualidade de dados e de fraude precoce, não um controle de conformidade por si só, e não substituía a documentação real de comprovante de endereço nem as verificações de sanções e de identidade que uma instituição financeira regulada precisa executar, por mais limpo que pareça o endereço digitado pelo solicitante. O valor estava inteiramente na filtragem e na triagem, tirando as solicitações obviamente quebradas da parte cara do fluxo mais cedo, e não em substituir qualquer parte do processo real de conformidade.

O volume acompanhava o volume de cadastros, um par de verificações por nova solicitação, uma carga de trabalho que ficava dentro da cota diária gratuita para um banco digital com volume moderado de cadastros, com o crédito pré-pago como o próximo passo natural durante um período de crescimento ou uma campanha de marketing que gerasse um pico de novas solicitações.

Para uma empresa regulada, o atrativo de uma verificação como esta tem menos a ver com detectar fraudes diretamente e mais com não desperdiçar etapas caras de verificação em solicitações que nunca iam a lugar nenhum. A documentação dos dois endpoints está em /docs/forward-geocoding/ e /docs/postal-code-lookup/.