A PSD2 exigiu uma API. O FiDA exige entrar num mercado.

Sob a PSD2, um banco podia cumprir a norma sozinho. Construir o endpoint, publicar a especificação, atingir a meta de disponibilidade, pronto. A proposta de Acesso a Dados Financeiros da Comissão Europeia elimina essa opção. A conformidade passa por um Esquema de Compartilhamento de Dados Financeiros — um acordo-quadro negociado entre detentores dos dados, usuários de dados e representantes dos clientes — e nenhuma instituição consegue constituir um esquema sozinha. O trabalho técnico é a metade menor. A metade maior é uma negociação comercial sobre escopo, padrões, responsabilidade e preço, e ela está acontecendo agora, enquanto a maioria dos bancos espera o texto final.

Resumo executivo

O status importa antes da estratégia. O FiDA foi proposto em junho de 2023 como parte do pacote de acesso a dados financeiros e pagamentos. Apareceu numa lista vazada de retiradas em 2025, sobreviveu até o programa de trabalho final e segue em trílogo. Nada do que vem abaixo é lei consolidada.

O esquema é o objeto regulatório. Os Esquemas de Compartilhamento de Dados Financeiros definem os padrões comuns, os requisitos de interface, os termos de responsabilidade e os mecanismos de disputa. A exposição de um banco é determinada por regras que ele ajuda a escrever ou simplesmente herda.

A remuneração reformula todo o exercício. Quando o acesso carrega um preço ligado ao custo de provisão, o banco precisa de um modelo de custos defensável, não apenas de um gateway de API. Pouquíssimos têm um.

A construção não é a API. A maioria das instituições consegue expor um endpoint. Bem menos conseguem localizar, normalizar e garantir a qualidade de dados de crédito imobiliário, previdência e seguros que nunca saíram do seu silo de produto.

O regulamento que quase não aconteceu

Qualquer estratégia construída sobre o FiDA precisa começar com uma declaração honesta sobre onde o processo de fato está.

A Comissão o propôs em junho de 2023, ao lado do pacote de pagamentos que traz a PSD3 e o Regulamento de Serviços de Pagamento. No início de 2025, um rascunho vazado do programa de trabalho da Comissão sugeriu que o FiDA poderia ser retirado — reportado na época como resposta a preocupações com a carga imposta às instituições financeiras da UE. O programa de trabalho final o manteve entre as propostas pendentes, e a negociação continuou. Passou pelo trílogo e as instituições trabalham rumo a um acordo político, com obrigações que devem entrar em vigor de forma faseada após a adoção, à medida que os esquemas forem constituídos.

Duas coisas decorrem dessa história, e elas puxam em direções opostas.

A proposta é politicamente sobrevivente, mas não politicamente segura, então um programa que assume que o texto atual sairá inalterado está exposto. Escopo, prazos e o mecanismo de remuneração são precisamente as disposições que se mexem em trílogo.

Ao mesmo tempo, as partes com maior probabilidade de sobreviver são as estruturais — governança baseada em esquemas, painéis de permissões, remuneração em princípio — porque são a arquitetura da proposta, e não seus parâmetros. Essas também são as partes com o maior prazo de construção.

A postura correta, portanto, não é nem "esperar o texto final" nem "construir para o rascunho atual". É construir as capacidades que toda versão plausível exige e estar presente onde os parâmetros são decididos.

Três rupturas estruturais em relação à PSD2

Tratar o FiDA como a PSD2 com uma lista maior de endpoints é o erro que custará mais caro.

Tabela 1: o que realmente muda

Dimensão	PSD2	FiDA como proposto
Como você cumpre a norma	Construir e publicar uma interface; um ato unilateral	Aderir a um Esquema de Compartilhamento de Dados Financeiros; um acordo multilateral
Dados no escopo	Contas de pagamento	Crédito imobiliário, empréstimos, poupança, investimentos, criptoativos, previdência, seguros não vida
Custo do acesso	Gratuito para o terceiro	Detentores dos dados podem pleitear remuneração razoável ligada ao custo de provisão
Quem define o padrão	O regulador define resultados; cada banco escolhe uma implementação	O esquema define padrões comuns e requisitos de interface
Controle do cliente	Consentimento por conexão	Um painel de permissões que o detentor dos dados deve oferecer
Onde o risco fica	Disponibilidade e segurança da sua interface	Também: termos do esquema, alocação contratual de responsabilidade e resultados de disputas

A primeira e a terceira linhas são as que mudam o formato do programa.

O esquema é o objeto regulatório

Sob a PSD2, a superfície de conformidade de um banco era a própria API. Sob o FiDA como redigido, a superfície de conformidade é um regulamento negociado com contrapartes, incluindo as empresas que querem os seus dados.

Um Esquema de Compartilhamento de Dados Financeiros é um acordo-quadro entre detentores dos dados, usuários de dados e representantes de consumidores ou clientes. Espera-se que desenvolva os padrões comuns de compartilhamento de dados e de solicitações via interface, fixe a responsabilidade contratual de seus membros e ofereça um mecanismo de resolução de disputas que funcione.

Leia essa lista como um registro de riscos e a implicação incomoda. Alguém vai decidir como a responsabilidade é alocada quando um usuário de dados lida mal com dados de clientes obtidos pela sua interface. Alguém vai decidir a que padrão de qualidade de dados você fica sujeito e o que constitui uma solicitação válida. Se o banco não estiver na sala, essas decisões serão tomadas por partes cujo interesse comercial é ter acesso amplo, preços baixos e responsabilidade concentrada no detentor.

Essa é a parte mais mal dimensionada do programa FiDA médio. As instituições designaram arquitetos e nenhum negociador.

A remuneração transforma um dever em produto

A PSD2 obrigou os bancos a dar de graça o acesso a contas de pagamento. A proposta do FiDA assume outra posição: os detentores dos dados podem pleitear remuneração razoável dos usuários de dados, atrelada ao custo de disponibilizar os dados, segundo uma metodologia objetiva, transparente e não discriminatória.

Essa única mudança converte uma obrigação em algo mais próximo de uma linha de produto regulada — e exige uma capacidade de que a maioria dos bancos nunca precisou.

Tabela 2: o que uma posição defensável de remuneração precisa responder

Pergunta	Por que é difícil	O que você precisa antes de precificar
Quanto custa de fato a provisão?	Os custos estão espalhados por infraestrutura, segurança, suporte e conformidade, e nenhum deles é hoje alocado a um produto de dados	Um modelo de custos que atribua o custo de plataforma compartilhada à provisão de dados
A metodologia é não discriminatória?	Diferentes usuários de dados terão volumes e margens muito distintos	Uma tabela publicada que resista ao escrutínio de um membro do esquema que não goste dela
Ela escala para baixo?	A remuneração deve se orientar pelos níveis mais baixos do mercado, e não excluir o acesso pelo preço	Uma estrutura que funcione para um usuário de dados pequeno, não só para um grande
Você consegue comprovar?	Um preço vira um artefato supervisório e competitivo assim que é publicado	Derivação auditável, não um número negociado

As instituições que se sairão bem nisso são as que começam a custear a provisão de dados agora, enquanto ainda é um exercício interno, e não numa negociação de esquema em que o número vira uma posição a defender.

A construção não é a API

O trabalho técnico que importa não é a interface. É tudo o que fica atrás dela.

Os dados de contas de pagamento já eram estruturados, já eram em tempo real, já pertenciam a um único sistema com um único dono. Dados de crédito imobiliário, previdência, investimentos e seguros não são nada disso. Ficam em silos de produto de idades diferentes, com identificadores de cliente diferentes, dados de referência diferentes e definições diferentes para o mesmo campo. Parte deles existe apenas em documentos.

Três capacidades carregam o prazo de construção, e nenhuma delas depende do texto final.

Uma camada de resolução de identidade do cliente. Atender a uma solicitação de dados significa saber que o cliente do crédito imobiliário, o titular da previdência e o correntista são a mesma pessoa, com confiança alta o bastante para liberar dados com base nisso. A maioria das instituições descobre que sua resolução de identidade é mais fraca do que se supunha exatamente no momento em que tenta usá-la.

Normalização dos dados de produto. Um esquema definirá formatos comuns. Quaisquer que sejam, o trabalho de mapear dados legados de produto para qualquer padrão externo é o mesmo trabalho, e é o maior item do plano.

Estado de permissão como infraestrutura. Um painel é uma visão. Abaixo dele precisa existir um registro durável e auditável de qual permissão foi concedida, por quem, sobre quais dados, por quanto tempo e quando foi revogada — consultável em tempo real por todo sistema que atende uma solicitação. Instituições que constroem o painel antes do livro-razão de permissões constroem aquilo que terão de reconstruir.

O manual de execução

Coloque alguém na conversa do esquema. Não um arquiteto — um negociador comercial com mandato sobre responsabilidade e preço. Essa é a ação de maior alavancagem disponível e a mais frequentemente adiada.
Custeie a provisão de dados agora. Construa o modelo de atribuição enquanto a questão é interna. Uma metodologia de remuneração inventada sob pressão de negociação não resistirá ao escrutínio.
Comece a resolução de identidade antes de o escopo ser definido. Toda versão do FiDA exige saber que o seu cliente é um cliente só. Nada disso muda no trílogo.
Construa o livro-razão de permissões, não o painel. O artefato visível é uma semana de front-end. O registro por baixo dele é a parte com cauda de dois anos.
Faça o inventário honesto dos silos. Identifique quais produtos no escopo hoje não conseguem produzir dados estruturados e atuais. Essa lista é o verdadeiro plano do programa.
Acompanhe o escopo, não as manchetes. Os parâmetros com maior chance de se mover no trílogo — quais produtos, quais dados, que prazos — são exatamente os que o seu plano deve absorver sem redesenho.

A PSD2 ensinou os bancos a tratar dados abertos como um custo de conformidade a minimizar. Esse instinto é o ponto de partida errado aqui. Quando o acesso é precificado, delimitado por negociação e cobre os produtos com os quais o banco de fato ganha dinheiro, as instituições que o tratarem como mercado ditarão os termos para as que o tratarem como fardo.

Perguntas frequentes

O FiDA já é lei?
Não. Foi proposto em junho de 2023 como parte do pacote de acesso a dados financeiros e pagamentos e continua no processo legislativo da UE, tendo passado pelo trílogo. Foi incluído numa lista vazada de retiradas no início de 2025 e depois mantido no programa de trabalho final da Comissão. Escopo, prazos e o mecanismo de remuneração são disposições que ainda podem mudar.

Qual é a diferença prática em relação à PSD2?
Três diferenças que importam. A conformidade passa por um Esquema de Compartilhamento de Dados Financeiros em vez de uma interface construída sozinho; os detentores dos dados podem pleitear remuneração razoável em vez de fornecer acesso gratuito; e os dados no escopo vão muito além das contas de pagamento, alcançando crédito imobiliário, empréstimos, poupança, investimentos, criptoativos, previdência e seguros não vida.

O que é um Esquema de Compartilhamento de Dados Financeiros?
Um acordo-quadro entre detentores dos dados, usuários de dados e representantes de clientes ou consumidores. Espera-se que defina os padrões comuns de dados e de interface, aloque a responsabilidade contratual entre os membros e ofereça resolução de disputas. Como define os termos aos quais você ficará sujeito, adesão e influência são questões estratégicas, não administrativas.

Se o texto não é final, o que dá para construir com proveito agora?
As partes de que toda versão precisa: resolução de identidade do cliente entre silos de produto, normalização de dados legados de produto rumo a um padrão externo e um livro-razão durável de permissões por baixo do painel. Nenhuma delas depende de como escopo ou prazos se acomodarem, e todas as três têm prazos longos.

Devemos resistir ao FiDA ou abraçá-lo?
Resistir a uma proposta que já sobreviveu a uma tentativa de retirada é mau uso da janela restante. A pergunta mais produtiva é se a sua instituição é detentora líquida ou usuária líquida de dados nos segmentos que lhe interessam — porque isso determina se você quer a metodologia de remuneração alta ou baixa, e essa discussão se resolve no esquema, não em Bruxelas.

Referências

Comissão Europeia, 2023. Pacote de acesso a dados financeiros e pagamentos. Bruxelas: Direção-Geral da Estabilidade Financeira, dos Serviços Financeiros e da União dos Mercados de Capitais. Disponível em: Comissão Europeia, 2023..
Comissão Europeia, 2023. Proposta de Regulamento relativo a um quadro para o Acesso a Dados Financeiros, COM(2023) 360. Bruxelas: Comissão Europeia. Disponível em: Comissão Europeia, 2023..
Parlamento Europeu, 2026. Legislative Train Schedule: um novo quadro de open finance. Bruxelas: Parlamento Europeu. Disponível em: Parlamento Europeu, 2026..
Parlamento Europeu e Conselho da União Europeia, 2015. Directive (EU) 2015/2366 relativa aos serviços de pagamento no mercado interno (PSD2). Bruxelas: Jornal Oficial da União Europeia. Disponível em: Parlamento Europeu e Conselho da União Europeia, 2015..

Última revisão 2026-08-08.

Republicar este artigo

A PSD2 exigiu uma API. O FiDA exige entrar num mercado. — Sebastien Rousseau

O FiDA não é a PSD2 com mais endpoints. Adesão a um esquema, acesso a dados com preço e escopo muito maior tornam o open finance um mercado obrigatório.

Este artigo está licenciado sob Creative Commons Attribution 4.0 International. A republicação exige atribuição à URL canônica.

A PSD2 exigiu uma API. O FiDA exige entrar num mercado. — Sebastien Rousseau

O FiDA não é a PSD2 com mais endpoints. Adesão a um esquema, acesso a dados com preço e escopo muito maior tornam o open finance um mercado obrigatório.

Originally published at https://sebastienrousseau.com/pt-br/2026-07-31-fida-open-finance-data-sharing-schemes-banks-2026/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER