Open Finance: o que 220 milhões de consentimentos não dizem

O Brasil chegou a mais de 220 milhões de consentimentos ativos no Open Finance. É um número impressionante. Também é um número que, sozinho, diz muito pouco sobre a experiência que acontece depois.

Consentimento registra que alguém chegou até um ponto da jornada e autorizou o compartilhamento. Não diz se o dado chegou, se chegou completo, se estava atualizado, se todas as instituições responderam ou se o produto que dependia daquilo conseguiu entregar o que prometeu. Consentimento é uma métrica de adesão. Usá-lo como prova de que a experiência inteira funciona mistura duas coisas diferentes. E essa diferença importa muito para quem constrói produto financeiro em cima do Open Finance.

O Brasil resolveu muito bem o problema do “sim”

A escala brasileira é real. Em 2023, o Banco Central reportava cerca de 15 milhões de clientes e 22 milhões de consentimentos ativos. No início de 2025, a Associação Open Finance Brasil já falava em mais de 40 milhões de clientes e 60 milhões de consentimentos ativos. Em agosto de 2026, uma reportagem da Finsiders situava o ecossistema em mais de 220 milhões de consentimentos ativos e mais de 130 milhões de contas conectadas. A evolução é enorme.

Mas existe uma diferença entre medir:

quantas autorizações existem?

e medir:

o produto conseguiu utilizar aquele compartilhamento para entregar valor?

Uma pessoa pode autorizar perfeitamente e, ainda assim, receber uma experiência ruim depois. É aí que começa a parte menos visível do Open Finance.

A discussão sobre a “engrenagem”

Em agosto de 2026, durante a Rio Innovation Week, Rafaela Nogueira, responsável por Inteligência Regulatória no Nubank, levantou publicamente problemas que, na visão da instituição, ainda existiam na operação do Open Finance. Entre eles:

• diferenças de desempenho entre instituições;

• dificuldades na priorização de problemas;

• questões relacionadas ao monitoramento;

• qualidade e atualidade dos dados.

A declaração que mais chamou atenção foi que, em mais de 60% das solicitações, a informação não chegaria atualizada.

No dia seguinte, a Associação Open Finance Brasil publicou um contraponto. Sobre os 60%, foi direta: o percentual apresentado na reportagem não vinha acompanhado de fonte, período ou metodologia que permitissem verificá-lo. A Associação também contestou a descrição do monitoramento como manual e afirmou possuir mecanismos automatizados, processos de criticidade e acompanhamento de desconformidades.

Do outro lado, apresentou seus próprios sinais de evolução. Segundo a nota reproduzida pela reportagem, o ecossistema processava cerca de 47 bilhões de chamadas de API por mês, para 223,5 milhões de consentimentos ativos, e a nota agregada de desempenho das APIs teria passado de 5,7 em novembro de 2025 para 7,3 em agosto de 2026.

O problema é que esses números não respondem exatamente à mesma pergunta. E a reportagem não traz detalhe metodológico suficiente para transformar 60% e 7,3 em duas medidas diretamente comparáveis. Então não faz sentido escolher um vencedor daqui. Para produto, existe uma conclusão mais útil.

Seu produto não pode depender de essa discussão estar resolvida

Imagine que a taxa real de problema seja muito menor que 60%. Ainda assim, algumas requisições podem falhar, alguns dados podem chegar desatualizados, uma instituição pode responder enquanto outra não, um consentimento pode deixar de estar válido, uma integração pode passar por indisponibilidade. Tudo isso já é suficiente para criar estados que a interface precisa representar.

O caminho feliz costuma ser desenhado assim:

usuário autoriza → dados chegam → produto mostra resultado.

Mas um produto real precisa considerar pelo menos:

1. o dado chegou como esperado;

2. o dado chegou, mas está desatualizado;

3. parte dos dados chegou;

4. o dado não chegou.

A estatística muda a frequência de cada estado. Não elimina a necessidade de desenhá-los. É por isso que a discussão pública sobre qualidade é interessante, mas não deveria determinar sozinha o escopo da experiência.

A regulação também olha para o que acontece depois do consentimento

O monitoramento atual do Open Finance não se limita a contar autorizações. A Instrução Normativa BCB nº 706, de janeiro de 2026, estabeleceu a versão 3.0 do Manual de Monitoramento do Open Finance e revogou a versão anterior publicada pela IN 575. O manual inclui monitoramento de aspectos como:

• performance e disponibilidade das APIs;

• qualidade dos dados;

• experiência do cliente;

• taxa de conversão das jornadas;

• situações de desconformidade.

Na qualidade de dados, o próprio Banco Central diferencia dimensões como completude, consistência, conformidade, validade, atualidade e unicidade. Essa distinção é importante. “Recebi um dado” e “recebi um dado utilizável” também não são a mesma coisa do ponto de vista regulatório. O produto deveria refletir essa realidade.

Um saldo sem data é uma promessa

Imagine um agregador financeiro mostrando:

Banco A
R$ 18.430

O usuário naturalmente interpreta aquilo como saldo atual. Só que talvez a última atualização tenha acontecido ontem às 14h. Agora imagine que no aplicativo do próprio banco apareçam R$ 13.800. Para a infraestrutura, existe uma explicação técnica. Para o usuário, existe uma discrepância. E quem recebe a culpa normalmente é a interface que ele está olhando.

Uma linha pequena muda a interpretação:

Atualizado ontem às 14h02.

Agora o produto não promete uma atualidade que não consegue garantir naquele momento. Essa decisão parece simples. Mas muda bastante a confiança na informação.

“Zero” e “não recebemos” são estados completamente diferentes

Outro erro comum é usar ausência de informação como se fosse valor. Se a API não retornou saldo e a interface exibe:

R$ 0,00

o produto acabou de inventar uma informação financeira. O usuário não sabe que houve ausência de dado. Ele vê zero. Isso pode acontecer também com limites, parcelas, investimentos, cartões, transações e contratos.

Em produto financeiro, essa distinção precisa ser explícita. R$ 0,00 significa que conhecemos o valor e ele é zero. Saldo indisponível significa que não conseguimos determinar o valor naquele momento. São estados visualmente parecidos e semanticamente muito diferentes.

Dados parciais precisam continuar parecendo parciais

O Open Finance cria outro problema interessante porque o produto pode depender de várias instituições ao mesmo tempo. Imagine uma tela com cinco bancos. Quatro responderam. Um não. O pior desenho possível é esconder silenciosamente o quinto e continuar dizendo:

Veja toda a sua vida financeira em um só lugar.

A promessa agora é maior que o dado disponível. Uma interface mais honesta pode mostrar:

4 de 5 instituições atualizadas.

ou destacar:

Banco X não pôde ser atualizado.

Agora a incompletude faz parte da experiência. Isso é importante porque um dado parcial pode parecer completo quando não existe sinal visual de que alguma coisa está faltando.

A conexão também é um estado de produto

Consentimento não deveria desaparecer da experiência depois que a pessoa toca em “autorizar”. Existe uma relação acontecendo ali. Ela pode estar ativa, expirada, revogada, com erro, precisando de nova autenticação ou temporariamente indisponível. Se o único sinal de que alguma coisa mudou é um banco sumir da lista, o produto transferiu para o usuário o trabalho de monitorar a integração.

Uma área de conexões pode responder coisas simples: quais instituições estão conectadas, quando cada uma atualizou pela última vez, se existe algum problema, se é preciso fazer alguma coisa, se o compartilhamento continua válido. A tela de consentimento é o início. A gestão da conexão é o produto depois dela.

O lado PJ mostra como números agregados podem esconder mercados diferentes

Existe outro dado que merece atenção para quem constrói fintech B2B. Em números referentes a 2024 divulgados pela Associação Open Finance Brasil, foram registrados cerca de 40,8 milhões de consentimentos de pessoas físicas como receptoras de dados. Entre pessoas jurídicas, foram aproximadamente 403,2 mil.

Essa comparação exige cuidado. São consentimentos, não necessariamente usuários únicos, e representa um recorte daquele período. Ainda assim, a diferença de ordem de grandeza é relevante. O Open Finance pode apresentar enorme escala agregada e, ao mesmo tempo, ter maturidade muito diferente em determinados segmentos.

Para produto B2B, isso importa. Empresa tem outras complicações:

• múltiplas contas;

• mais de um representante;

• alçadas;

• governança interna;

• integração contábil;

• múltiplas pessoas envolvidas numa autorização;

• operação distribuída entre bancos diferentes.

O mesmo fluxo que funciona para uma pessoa física não pode simplesmente ser ampliado e chamado de Open Finance PJ.

PJ também muda quem precisa entender o consentimento

Em uma conta pessoal, quem autoriza e quem usa o dado tende a estar mais próximo. Numa empresa, isso pode se separar. O financeiro quer conectar as contas, um administrador tem acesso ao sistema, o diretor possui determinada alçada, outro sócio precisa aprovar, o contador depois consome a informação. Isso transforma consentimento em fluxo organizacional.

O problema deixa de ser apenas:

a pessoa entendeu o que está compartilhando?

E passa a incluir: a pessoa certa consegue autorizar isso? Quem ainda precisa agir? Por que o processo está parado? O que acontece se alguém sair da empresa? Quem consegue renovar a conexão? O desafio de Open Finance B2B não está apenas na API. Também está na representação de permissão e responsabilidade.

A métrica do produto começa depois do consentimento

Se você constrói uma funcionalidade usando Open Finance, contar consentimentos pode fazer sentido. Mas eu não pararia ali. Dependendo do caso, gostaria de acompanhar também:

• Conexão concluída: quantas pessoas que iniciaram realmente chegaram a uma integração utilizável?

• Primeira sincronização: quantas conseguiram receber dados depois da autorização?

• Completude: quantas tiveram todas as fontes esperadas disponíveis?

• Atualidade: os dados estavam recentes o suficiente para a tarefa?

• Recuperação: quando uma conexão falhou, quantas pessoas conseguiram restabelecê-la?

• Valor entregue: a informação compartilhada realmente permitiu concluir a tarefa que justificou o consentimento?

Esse último é o que coloca tudo no lugar. Porque Open Finance não existe para gerar consentimentos. Consentimento é a permissão necessária para alguma coisa acontecer depois.

A interface precisa conhecer o limite da infraestrutura

Existe uma frase perigosa em produto financeiro:

Todas as suas contas em tempo real.

Talvez a infraestrutura realmente sustente isso no contexto em que a promessa está sendo feita. Talvez não. A questão é que copy também deveria conhecer os estados técnicos. Se atualização pode atrasar, a interface precisa representar tempo. Se fonte pode falhar, precisa representar indisponibilidade. Se compartilhamento pode ser parcial, precisa representar incompletude. Se a conexão pode expirar, precisa representar renovação.

Product Design não precisa expor cada detalhe técnico do Open Finance. Precisa impedir que a interface comunique uma certeza maior do que a infraestrutura consegue entregar.

A disputa entre Nubank e Associação deixa uma lição útil

Dois participantes relevantes do mesmo ecossistema apresentaram leituras bastante diferentes sobre a saúde da infraestrutura. Uma declaração colocou em discussão desatualização, monitoramento e criticidade. A Associação contestou esses pontos e apresentou indicadores de evolução. Isso é uma discussão importante para o mercado.

Mas existe outra lição para quem faz produto: um número sem definição clara daquilo que mede é muito fácil de transformar em conclusão maior do que ele suporta. 220 milhões de consentimentos não significam 220 milhões de experiências excelentes. Uma nota agregada de desempenho não significa que toda chamada de API funcionou. Uma reclamação sobre desatualização também não significa que 60% de toda experiência de Open Finance está quebrada. Métrica precisa de contexto. Isso vale para regulador, para associação, para fintech e para o dashboard interno do seu produto.

Antes de construir com Open Finance, desenhe o dado que não chegou

O caminho feliz vai para o Figma de qualquer maneira. Vale começar pelo resto. O que aparece se uma instituição não responder? Como sabemos quando o dado foi atualizado? Como representamos uma resposta parcial? O que acontece quando o consentimento expira? Como alguém reconecta? O produto consegue diferenciar zero de ausência? Qual promessa continua verdadeira quando uma das fontes falha?

Essas perguntas não deixam a experiência mais pessimista. Deixam o produto preparado para depender de uma infraestrutura distribuída.

O Brasil conseguiu construir escala suficiente para que centenas de milhões de consentimentos existam ao mesmo tempo. Isso é um feito. A próxima pergunta para Product Design é menos impressionante em apresentação e muito mais importante no uso: o que acontece depois que a pessoa diz sim? É ali que consentimento começa a virar produto.

Sobre outra experiência em que regulação, risco e interface precisam funcionar ao mesmo tempo, vale continuar por KYC sem fricção.

Fontes

Banco Central do Brasil. Instrução Normativa BCB nº 706, de 29 de janeiro de 2026. Divulga a versão 3.0 do Manual de Monitoramento do Open Finance e revoga a Instrução Normativa BCB nº 575/2024. O manual contempla monitoramento de performance de APIs, qualidade dos dados, experiência do cliente, conversão e tratamento de situações de desconformidade.

Finsiders Brasil. “Open Finance trava na ‘engrenagem’, aponta executiva do Nubank; associação rebate”, Danylo Martins. Publicado em 10 de agosto de 2026 e atualizado em 11 de agosto de 2026. A reportagem registra mais de 220 milhões de consentimentos ativos e mais de 130 milhões de contas conectadas e reúne as declarações de Rafaela Nogueira, do Nubank, além do contraponto posterior da Associação Open Finance Brasil.

Associação Open Finance Brasil. Contraponto reproduzido na reportagem da Finsiders. A entidade contesta o percentual de mais de 60% por ausência de fonte, período e metodologia verificáveis na declaração reportada e informa, entre outros indicadores, 223,5 milhões de consentimentos ativos, cerca de 47 bilhões de chamadas mensais de APIs e evolução da nota agregada de desempenho de 5,7 em novembro de 2025 para 7,3 em agosto de 2026.

Banco Central do Brasil. Balanço dos primeiros anos do Open Finance, utilizado como referência histórica para a evolução de clientes e consentimentos.

Associação Open Finance Brasil. Dados referentes a 2024, divulgados posteriormente pela imprensa, com 40,8 milhões de consentimentos de pessoas físicas como receptoras de dados e 403,2 mil consentimentos de pessoas jurídicas no mesmo papel. Os valores representam consentimentos, não necessariamente clientes únicos.