Segurança no Open Finance: quem vê o quê, o que fica guardado e o que é responsabilidade sua

"É seguro?" é a pergunta que muita gente faz quando conhece o consentimento via Open Finance da Pluggy.

Primeiro, com o que a gente está comparando

Vale lembrar o que existia antes, porque é isso que o Open Finance substituiu.

Antes, uma empresa que precisava do extrato do cliente tinha três opções: pedir o arquivo por e-mail ou WhatsApp, pedir a senha do banco, ou usar um robô que logava como se fosse o cliente.

As três ainda acontecem. A primeira espalha extrato em caixa de entrada que ninguém audita. A segunda é a pior coisa que um produto pode pedir. A terceira concentra credencial de banco em alguém que não é banco.

O Open Finance não é seguro porque é novo. É seguro porque tira a credencial do caminho e coloca uma autorização rastreável no lugar dela.

Onde o seu usuário digita a senha

Essa é a pergunta mais importante do texto, e ela tem duas respostas dependendo do tipo de conexão. Vale dizer as duas, porque fornecedor que dá só a primeira está escondendo metade.

Nos conectores de Open Finance, o usuário é levado para o ambiente da própria instituição. Ele se autentica lá, com os mecanismos do banco dele, e volta com uma autorização. A senha não passa pelo seu produto e não passa pela Pluggy. Não existe credencial para ser vazada porque não existe credencial armazenada.

Nos conectores de acesso direto, que existem para instituições que não estão no Open Finance regulado, o usuário fornece credencial. Ela fica criptografada e nunca pode ser recuperada pela API, nem por você, nem por nós por essa via. Mas ela existe, e isso é uma diferença real de modelo de risco.

Se segurança é critério duro no seu produto, essa distinção deveria estar na sua decisão de quais instituições você oferece e em que ordem. Escrevemos sobre os dois tipos em as diferenças entre conector direto e regulado.

O que o consentimento realmente é

Consentimento, no Open Finance, não é um aceite de termos. É um objeto com estado, que dá para consultar.

Ele carrega quais produtos financeiros foram autorizados, quais permissões o usuário concedeu, quando foi criado, quando expira e quando foi revogado. Você lê isso pela API a qualquer momento, por item.

Duas coisas que valem saber antes de desenhar o seu produto em cima disso:

O padrão é consentimento sem prazo de validade. O usuário é quem decide, e alguns conectores trabalham com prazo definido. Então não assuma nenhum dos dois: leia o campo.

A revogação não passa por você. O usuário entra no app do banco dele e tira a autorização. Você não é consultado e não tem como impedir. Do seu lado, os endpoints de dado passam a devolver vazio.

Esse segundo ponto é o que mais pega produto desprevenido. Vazio não é erro. Se o seu código trata lista vazia como "o cliente não teve movimentação", você vai mostrar um fechamento errado em vez de um aviso. Trate revogação como estado, não como falha.

O que acontece quando você apaga

Muita conversa de segurança para na entrada do dado. A parte que quase ninguém pergunta, e que é justamente a que o jurídico do seu cliente vai perguntar, é o que acontece na saída.

Quando uma conexão é excluída, quatro coisas acontecem de uma vez: as credenciais armazenadas são apagadas, o consentimento de Open Finance é revogado quando se aplica, as autorizações OAuth são expiradas e os dados daquela conexão são excluídos em definitivo. Um evento de webhook avisa o seu sistema que isso aconteceu.

E existem exclusões que acontecem sozinhas:

• Conexão de teste parada há mais de 30 dias é removida com todos os dados dela. Ambiente de sandbox não acumula coisa esquecida.
• Conector descontinuado leva junto as conexões ligadas a ele, 30 dias depois do anúncio. É por isso que vale assinar o evento de exclusão: é o seu aviso para pedir ao usuário que reconecte por outro caminho antes do prazo.

A regra por trás das três políticas é a mesma: credencial e dado não ficam guardados além do necessário, e a credencial é a primeira coisa a cair.

Os cinco erros que a gente mais vê

Aqui vem a parte desconfortável. Na maior parte dos incidentes, a infraestrutura não foi o elo fraco. A integração foi.

Esses são os cinco que mais aparecem, em ordem de gravidade.

1. Chave secreta no frontend. O clientSecret no código da página ou no bundle do app. Quem achar aquilo acessa os dados bancários de todos os seus usuários, não só os de um. É o erro mais grave e, infelizmente, não é raro. A chave vive no backend, sempre.

2. Token de conexão reaproveitado. O token que vai para o frontend existe justamente para ser limitado: ele dura 30 minutos e só enxerga as conexões criadas com ele. Um token novo não acessa o que outro criou. Gere um por usuário e por sessão, em vez de criar um e deixar circulando.

3. Webhook aceito sem verificar quem mandou. Se o seu endpoint aceita qualquer POST que chegue, qualquer um pode inventar um evento no seu sistema. Dá para proteger a URL com cabeçalho próprio, e vale a regra geral: não confie no conteúdo do webhook, confie nele como gatilho. Recebeu o aviso, consulte a API para saber o estado de verdade.

4. Guardar mais do que o produto precisa. A tentação de salvar todo o extrato bruto "porque pode ser útil depois" é como você transforma um dado que estava sob cuidado de uma instituição num dado que está sob o seu. Cada campo que você persiste é um campo que você passa a ter que proteger, justificar e saber apagar. Tratamos disso em o que um software pode guardar de dado bancário.

5. Log com dado bancário dentro. O jeito mais comum de vazar extrato não é invasão: é o payload inteiro logado em texto puro numa ferramenta de observabilidade que metade da empresa acessa. Vale revisar o que o seu logger captura antes de ir para produção.

Nenhum desses cinco é resolvido por quem te fornece a API. São seus.

O que ser autorizada pelo Banco Central realmente obriga

"Somos autorizados pelo Banco Central" vira frase de marketing se ninguém disser o que ela implica. Implica cinco coisas concretas, e todas dá para conferir.

1. A autorização é um processo, não um cadastro. Pelo regime da Resolução BCB nº 80, de 25 de março de 2021, o Banco Central analisa capital, governança, estrutura societária e idoneidade dos controladores antes de autorizar uma instituição de pagamento a funcionar. Não se preenche formulário e começa a operar: o BCB autoriza nominalmente, e pode não autorizar.

2. A supervisão é contínua, não é um selo de uma vez. Depois de autorizada, a instituição reporta periodicamente e fica sujeita a fiscalização, a determinação de ajuste e a sanção. A régua não é a boa intenção de quem opera, é o que o regulador cobra e pode punir.

3. Segurança cibernética é obrigação normativa. A Resolução BCB nº 85, de 8 de abril de 2021, alterada pela Resolução BCB nº 538, de 18 de dezembro de 2025, obriga instituições de pagamento a manter política formal de segurança cibernética, com plano de ação e de resposta a incidentes, e a cumprir requisitos específicos para contratar processamento de dados, armazenamento e computação em nuvem.

Na prática, isso vira uma coisa útil para você: boa parte do que está no seu questionário de fornecedor já é exigência de norma aqui, não cortesia comercial.

4. Entrar no Open Finance exige certificação, não só implementar a API. O participante precisa estar registrado no Diretório de Participantes e passar pela certificação de conformidade do ecossistema, que inclui a certificação de segurança do perfil FAPI, conduzida pela OpenID Foundation. A comunicação entre participantes usa autenticação mútua por certificado (mTLS) e assinatura de mensagem, com certificados emitidos dentro do padrão do próprio Open Finance Brasil. Quem não tem certificado válido não conversa com os outros participantes: não é uma política interna que alguém pode relaxar, é o que faz a conexão existir.

5. Dá para conferir sem perguntar para a gente. O Diretório de Participantes do Open Finance Brasil é público e lista CNPJ, razão social, papel e status de cada participante. O Banco Central também publica a relação de instituições autorizadas a funcionar. Se um fornecedor diz que é autorizado e participante, isso se checa em dois minutos, e é exatamente o que a gente sugere que você faça.

Uma ressalva honesta para fechar: licença é piso, não teto. Estar autorizado prova que a instituição passou por um crivo e está sob supervisão. Não prova que ela é boa em segurança, do mesmo jeito que ter carteira não prova que alguém dirige bem. É por isso que as seções anteriores deste texto falam de mecanismo, e não de credencial.

Na iniciação de pagamento, o desenho também protege por construção: a ITP manda a ordem, o dinheiro sai da conta do pagador e cai na do recebedor, e não passa pela conta de ninguém no meio. Não existe saldo de terceiro parado em lugar nenhum, porque não existe o lugar.

E vale separar duas coisas que costumam ser confundidas: autorização do Banco Central e LGPD são assuntos diferentes. A primeira define quem pode operar. A segunda define o que você pode fazer com o dado dentro do seu produto, e essa parte continua sendo sua mesmo usando a licença de outro. Quem quiser a linha divisória completa, está em meu produto precisa de licença do Banco Central?.

E a Pluggy nisso tudo?

Juntando o que foi dito, sem adjetivo:

• Nos conectores de Open Finance, a autenticação acontece no ambiente da instituição, e não há credencial do usuário armazenada.
• Nos conectores de acesso direto, a credencial é criptografada e não pode ser recuperada pela API.
• O token que vai para o seu frontend dura 30 minutos e só enxerga o que foi criado com ele.
• O consentimento é consultável por item, com os produtos autorizados, as permissões concedidas e as datas de criação, expiração e revogação.
• Excluir uma conexão apaga credencial, revoga consentimento, expira OAuth e remove o dado, com webhook avisando.
• Pagamento acontece conta a conta, sem passar por nós.
• A Pluggy é autorizada pelo Banco Central como Iniciadora de Transação de Pagamento, sujeita à supervisão contínua e às obrigações de segurança cibernética da Resolução BCB nº 85/2021.
• Como participante do Open Finance, está no Diretório de Participantes e passou pela certificação de conformidade do ecossistema, incluindo a de segurança.

A página de conectores tem o lado de produto, as políticas estão em legal e compliance, e cada um dos mecanismos acima está descrito na documentação pública, com nome de campo e comportamento. Se algum fornecedor seu, inclusive nós, afirmar algo de segurança que não dê para conferir na documentação dele, essa é a hora de perguntar por quê.

Perguntas frequentes

A Pluggy tem a senha do banco do meu usuário?

Nos conectores de Open Finance, não existe senha armazenada: a autenticação acontece no ambiente da instituição. Nos conectores de acesso direto, a credencial existe, fica criptografada e não pode ser recuperada pela API.

Meu produto chega a ver a senha?

Não, em nenhum dos dois casos. Se algum fornecedor pede para você coletar a senha do banco na sua própria tela, esse é o sinal de alerta.

O usuário consegue cancelar o acesso?

Consegue, pelo app do banco dele, a qualquer momento, sem passar por você. Do seu lado, os endpoints de dado passam a devolver vazio.

O que acontece com os dados se eu encerrar o contrato ou apagar uma conexão?

Credenciais apagadas, consentimento revogado quando se aplica, autorizações OAuth expiradas e dados da conexão excluídos, com evento de webhook avisando o seu sistema.

Preciso de licença do Banco Central para usar isso com segurança?

Não. Você acessa por meio de uma instituição autorizada. O que continua sendo seu é a base legal do tratamento do dado dentro do seu produto.

Como eu confiro se um webhook veio mesmo de vocês?

Dá para configurar cabeçalhos próprios na URL do webhook. A prática que recomendamos de qualquer jeito é tratar o webhook como gatilho e buscar o estado real na API antes de agir.

Como eu confiro que vocês são mesmo autorizados?

Sem perguntar para a gente: a relação de instituições autorizadas a funcionar é publicada pelo Banco Central, e o Diretório de Participantes do Open Finance Brasil é público e traz CNPJ, papel e status de cada participante.

Ser autorizado pelo Banco Central garante que o fornecedor é seguro?

Não. Garante que ele passou por um crivo de autorização, está sob supervisão contínua e tem obrigação normativa de manter política de segurança cibernética e plano de resposta a incidentes. É piso, não teto, e por isso vale olhar os mecanismos também.

Qual é o ponto mais frágil de uma integração dessas?

Quase sempre a chave secreta exposta no frontend. É o erro mais comum e o de maior impacto, e ele está do lado de quem integra.

Fontes

• Resolução BCB nº 80, de 25 de março de 2021, sobre autorização para funcionamento das instituições de pagamento
• Resolução BCB nº 85, de 8 de abril de 2021, sobre política de segurança cibernética e requisitos para contratação de processamento e armazenamento de dados e de computação em nuvem, alterada pela Resolução BCB nº 538, de 18 de dezembro de 2025
• Resolução Conjunta nº 1, de 4 de maio de 2020 (CMN e Banco Central), que institui o compartilhamento de dados e serviços do Open Finance
• Open Finance Brasil, Guia de Certificação de Conformidade e Padrão de Certificados, na área do desenvolvedor
• Documentação da Pluggy: ciclo de vida do item, consentimentos, autenticação do Connect e referência de webhooks

Conclusão

Segurança em dado bancário não é um selo que alguém te entrega na assinatura do contrato. É uma lista de mecanismos que dá para conferir um por um, somada a uma lista de coisas que continuam sendo suas.

Se você está avaliando fornecedor agora, leve as quatro perguntas do começo do texto: quem vê o quê, o que fica guardado, o que acontece quando alguém desiste, e o que sobra para você. Quem souber responder as quatro com nome de campo e comportamento fez o trabalho. Quem responder "temos os mais altos padrões de segurança" não respondeu nada.