O novo bloco de construção do compliance

Toda empresa que lida com dinheiro realiza o mesmo ritual com seus clientes. Ela pede informações, o cliente fornece as informações, a empresa verifica as informações. A coreografia pode variar de empresa para empresa, mas, em essência, é a mesma dança.

Isso não diminui o propósito dessa troca de informações: as instituições financeiras têm obrigações com seus reguladores, seus parceiros e sua base de clientes de garantir que estão permitindo apenas clientes seguros e confiáveis em seus trilhos. Essas trocas foram concebidas para reduzir riscos, e cumprem esse papel.

No entanto, essa abordagem para gerenciar a triagem de sanções, as verificações de crimes financeiros e as medidas antifraude ignora duas outras dimensões de risco, tanto para a empresa quanto para o cliente: as instituições financeiras carregam a responsabilidade pela pilha de dados de clientes coletados ao longo do processo de onboarding. O risco do cliente é ainda maior. Todo cliente que faz onboarding em uma nova instituição financeira precisa compartilhar o mesmo conjunto de dados com cada empresa seguinte em que abre uma conta, multiplicando sua exposição de dados entre várias entidades.

Existe uma forma diferente de construir isso. Uma verificação de compliance pode existir em uma rede compartilhada como um bloco de construção auditado, chamado de “política”. Qualquer instituição da rede pode confiar em uma política, enquanto os dados pessoais do cliente nunca tocam a rede.

Dois tipos de segurança

Com uma política, as informações pessoais do cliente ficam em um único lugar. Como uma rede compartilhada mantém um registro permanente, os dados pessoais nunca vão para ela. Em vez disso, o que trafega pela rede é uma “prova de conhecimento zero” (“ZKP”, na sigla em inglês). Uma ZKP é uma forma de mostrar que uma afirmação sobre o cliente é verdadeira sem revelar as informações por trás dela. Você pode provar que tem dezoito anos sem entregar sua carteira de motorista. Uma empresa pode atestar sua saúde financeira sem entregar extratos bancários. A instituição financeira que está fazendo o onboarding do cliente obtém as informações de que precisa por meio da ZKP, enquanto os dados subjacentes do cliente permanecem confidenciais.

A segunda dimensão de segurança está no código. Quando cem empresas escrevem, cada uma, sua própria lógica de triagem, há cem lugares diferentes onde um erro pode se esconder, e cada um deles é revisado apenas pela equipe que o escreveu. Consolide tudo em uma única política compartilhada e passa a haver uma superfície única e pequena para verificar, observada por todos que dependem dela. Uma superfície menor significa menos lugares para uma vulnerabilidade existir. A confiança vem de muitos olhos voltados para um único elemento, o inverso de como o código de compliance costuma funcionar. A contrapartida é que uma falha em uma política compartilhada afetaria todos que dependem dela, e é por isso que a auditoria e a revisão aberta importam ainda mais aqui.

Fácil de adotar, fácil de explicar

Uma verificação compartilhada só é útil se a instituição financeira que a utiliza consegue entender o conceito bem o suficiente para explicá-lo a um regulador ou a outra parte interessada. Uma política é construída exatamente para isso. Se uma política amplamente usada já cobre um requisito, a instituição pode utilizá-la em vez de escrever a sua própria. O onboarding passa a ser uma questão de escolher a política certa para o produto e o mercado, assim como um desenvolvedor hoje recorre a uma biblioteca bem testada em vez de escrever criptografia do zero.

E como a verificação já está construída, a equipe que a adota precisa entender o que ela prova, e não como a criptografia chega a isso. A matemática por trás dessas provas é realmente difícil de acertar, o que normalmente a deixaria fora do alcance da maioria das equipes de engenharia. Uma política coloca essa dificuldade abaixo da superfície, já construída e já auditada. A instituição escolhe a política adequada e a integra.

Reutilização que se multiplica

Uma verificação compartilhada é mais segura e mais fácil de adotar mesmo que apenas uma instituição a utilize. A reutilização é o terceiro benefício, e é nela que as vantagens começam a se multiplicar.

As políticas são compartilhadas, mas também podem ser combinadas. Um serviço monta seus requisitos exatos a partir de verificações que já existem. À medida que mais instituições se apoiam nas mesmas verificações, as mais úteis atraem adoção, e a adoção atrai escrutínio. As políticas mais usadas se tornam o padrão, pelo mesmo motivo pelo qual padrões antigos conquistaram confiança: resistiram ao escrutínio ao longo do tempo.

Esse efeito multiplicador também chega ao cliente. Onde as regras permitem que uma instituição confie na verificação de outra, alguém verificado uma vez pode atender ao mesmo requisito no serviço seguinte sem entregar suas informações novamente. Seu status de verificado pode acompanhá-lo entre os serviços da rede. O cliente enfrenta menos atrito repetido, e a empresa herda uma base maior de clientes já verificáveis e uma pilha menor de dados para proteger.

Um olhar mais atento sobre uma política

Uma política é uma verificação de compliance auditada, publicada em um endereço fixo na rede, que qualquer instituição pode encontrar e na qual pode confiar. Ela verifica provas de conhecimento zero e funciona porque ser verificado e provar isso são duas etapas separadas.

‍

Primeiro, o cliente é verificado uma única vez, por meio do mesmo tipo de verificação de identidade que conhecemos hoje. O provedor que verifica o cliente emite uma credencial, um registro assinado das informações confirmadas, que fica com o cliente. A credencial contém os dados pessoais reais, por isso permanece com o cliente e nunca toca a rede.

A partir daí, provar a verificação é uma questão de usar essa credencial. Quando um serviço precisa confirmar que um cliente se qualifica, uma prova é gerada a partir da credencial, seja no próprio dispositivo do cliente, seja pelo provedor em nome dele, mostrando que ele atende à política sem expor nada do que há nela. O serviço recebe de volta um simples “sim” ou “não”. O cliente controla quando sua credencial é usada, e o serviço nunca constrói nem mantém a verificação. Publicada uma única vez, uma política pode ser reutilizada por qualquer instituição da rede.

O onboarding deixa de ser um desenvolvimento e vira uma integração

Imagine uma fintech fazendo o onboarding de um novo cliente. Antes de permitir que esse cliente mantenha ou movimente fundos, a fintech precisa confirmar que ele foi verificado, vive em um mercado elegível e passa nas verificações de sanções.

A versão “tradicional” é pesada. A empresa coleta os documentos de identidade do cliente, armazena-os e desenvolve seu próprio processo de triagem contra listas de sanções e regras de elegibilidade. O mesmo cliente precisa repetir o processo para cada conta que abre.  Cada empresa em que o cliente abre uma conta guarda dados pessoais que passam a ser responsabilidade dela. A verificação não é um diferencial, e o ônus recai inteiramente sobre cada empresa.

Uma política muda isso: uma política auditada que cobre os três requisitos já está publicada na rede. O cliente é verificado uma única vez e passa a ter uma credencial. Quando a fintech solicita, uma prova é gerada a partir dessa credencial, no dispositivo do cliente ou pelo provedor dele. Em uma política bem projetada, a triagem de sanções é executada continuamente, e a política é atualizada quando uma lista muda, de modo que a verificação reflete as listas atuais.

A fintech recebe a confirmação de que precisa. O provedor que fez a verificação mantém os registros subjacentes, e a fintech pode obtê-los para um examinador ou auditoria quando necessário. Os documentos não precisam circular entre instituições no dia a dia, nada sensível é gravado na rede, e a fintech confia na mesma verificação que outras instituições da rede usam e inspecionam. O onboarding deixa de ser um desenvolvimento e vira uma integração.

O compliance se torna infraestrutura

O compliance é uma das funções mais importantes dos serviços financeiros, e uma das mais duplicadas. Cada equipe reconstrói as mesmas verificações, o que consome tempo de engenharia, concentra riscos e espalha dados sensíveis por mais sistemas do que qualquer um escolheria. Tratar a verificação como um bloco de construção compartilhado e auditado muda a natureza do problema. Uma política é escrita e revisada uma vez, reutilizada amplamente e executada sem nunca colocar os dados do cliente na rede. Cada instituição continua sendo dona de seu programa de compliance e responde aos seus reguladores. Uma política compartilhada muda a forma como a verificação é construída e revisada, enquanto a responsabilidade continua com as instituições.

Essa é uma base que uma rede voltada primeiro para pagamentos pode estabelecer desde o início. E ela melhora com o uso. Cada instituição que confia em uma política compartilhada aumenta o escrutínio por trás dela, o que torna a próxima mais segura para construir em cima. O compliance deixa de ser algo que cada empresa constrói sozinha e se torna uma infraestrutura compartilhada que fica mais forte a cada instituição que confia nela.