Open Finance versiona seus manuais de escopo de dados e de experiência do cliente: por que uma nova versão é, na prática, um teste de controles

Um ecossistema de compartilhamento de dados que passou de 46 milhões de consentimentos ativos, mais de 800 instituições participantes e dezenas de bilhões de chamadas de API por mês não muda de manual sem consequência operacional. Em julho de 2026, o regulador divulgou novas versões dos dois manuais que definem o que se compartilha e como o cliente autoriza esse compartilhamento no Open Finance: a versão 8.0 do Manual de Escopo de Dados e Serviços e a versão 9.0 do Manual de Experiência do Cliente. Para quem lê a notícia de fora, é atualização técnica de rotina. Para quem opera dentro do arranjo, cada nova versão é um evento de gestão de mudança com prazo, escopo e efeito sobre controles, contratos e evidência. Este artigo não trata de nenhuma instituição específica. Trata do tema técnico: por que o versionamento de padrões regulatórios em ecossistemas de dados compartilhados é, antes de um assunto de TI, um assunto de governança, controle interno e auditabilidade.

Resumo

Os dois manuais que estruturam o Open Finance foram atualizados: o Manual de Escopo de Dados e Serviços define quais dados e serviços trafegam entre instituições, e o Manual de Experiência do Cliente define como a jornada de consentimento, autenticação e revogação deve funcionar. Nova versão significa novo padrão obrigatório, com prazo de adequação.

Uma mudança de escopo altera o mapa de dados pessoais que cada instituição transmite ou recebe, com efeito direto sobre bases legais, contratos entre participantes e a superfície de exposição sob a LGPD. Uma mudança de experiência altera a jornada de consentimento e de revogação, que é onde mora o risco de conduta e a evidência de que o cliente autorizou o que autorizou.

O consentimento tem validade máxima de doze meses e o fluxo de revogação precisa ser tão simples quanto o de concessão. Autenticação multifator, criptografia ponta a ponta e comunicação obrigatória de incidentes são exigências permanentes: cada nova versão precisa preservá-las, não enfraquecê-las.

Para efeito de controle e auditoria, o ponto não é a versão em si, e sim a capacidade de demonstrar que a instituição migrou no prazo, mapeou o impacto, testou a jornada, manteve trilha de consentimentos e registrou logs de API reconstituíveis. Versão adotada sem evidência de migração controlada é deficiência esperando para ser apontada.

Por que versionamento é assunto de controle, não só de sistema

Em arranjos de compartilhamento de dados, o padrão é o contrato de fato entre as partes. Quando o manual de escopo muda, muda o que uma instituição está autorizada a pedir e obrigada a entregar. Um campo novo no escopo é um dado pessoal a mais circulando, e cada dado a mais tem que ter base legal, finalidade definida e caminho de segurança do início ao fim. Tratar isso como simples atualização de biblioteca de software ignora que a mudança atravessa três domínios ao mesmo tempo: tecnologia, jurídico e controle interno.

A camada de experiência é ainda mais sensível, porque é ali que o cliente exerce o consentimento. A jornada define como a pessoa entende o que está autorizando, como autentica esse aceite e como revoga depois. Uma mudança de texto ou de fluxo que pareça cosmética pode alterar a qualidade do consentimento obtido, e consentimento é o alicerce jurídico de todo o compartilhamento. Se a jornada não deixa claro o escopo, ou se a revogação é mais difícil que a concessão, o problema deixa de ser de usabilidade e passa a ser de conformidade e de conduta.

Por isso a adoção de uma nova versão não se resolve no dia do deploy. Ela exige análise de impacto anterior à migração, teste da jornada e dos endpoints, atualização de contratos e de avisos, e, sobretudo, registro de que tudo isso foi feito. A pergunta que separa a instituição madura da frágil não é se ela está na versão nova. É se ela consegue mostrar como chegou lá.

As três frentes que uma nova versão sempre reabre

A primeira frente é o mapeamento de dados e bases legais. Toda mudança de escopo obriga a reconciliar o que passou a ser compartilhado com o inventário de dados pessoais, a finalidade declarada e a base legal aplicável. É o momento de confirmar que nenhum campo novo trafega sem amparo e que nenhum dado saiu do escopo autorizado. Sem esse mapeamento, a instituição perde a visão de sua própria superfície de exposição.

A segunda frente é a jornada de consentimento e revogação. A experiência precisa ser testada de ponta a ponta na nova versão: concessão, renovação dentro do limite de validade, e revogação com a mesma facilidade da concessão. Cada etapa gera evidência, e é essa evidência que sustenta, mais tarde, a afirmação de que o cliente autorizou exatamente aquilo. Jornada que funciona mas não deixa rastro é jornada que não se prova.

A terceira frente é a integridade técnica e de segurança. Autenticação multifator, criptografia ponta a ponta e monitoramento de incidentes não são requisitos que uma nova versão possa relaxar. A migração precisa preservar os controles de segurança e manter os logs de API íntegros e reconstituíveis, porque são esses registros que permitem reconstruir quem acessou o quê, quando e sob qual consentimento. Comunicação tempestiva de incidentes fecha o ciclo: a obrigação de reportar falhas é parte do controle, não um anexo dele.

Onde isso encosta na contabilidade, na asseguração e na auditoria

Compartilhamento de dados parece assunto distante das demonstrações financeiras, mas a distância é menor do que aparenta. Instituições que operam nesse arranjo dependem de controles de tecnologia da informação para produzir informação financeira confiável, e a integridade desses controles gerais de TI é parte do ambiente que o auditor avalia sob a NBC TA 315 (R2). Falha de gestão de mudança, acesso indevido a dados ou log inconsistente não são apenas riscos operacionais: são pontos que podem afetar a confiança do auditor nos controles que sustentam os números.

Há também a via da asseguração específica. Serviços prestados a terceiros nesse ecossistema, incluindo processamento e transmissão de dados, com frequência são objeto de relatórios de asseguração sobre controles em organizações prestadoras de serviço, no modelo da NBC TO 3402(equivalente ao ISAE 3402). Uma nova versão de manual entra diretamente no escopo desses relatórios, porque muda os controles que precisam operar de forma efetiva no período examinado. Migração malfeita vira exceção no relatório, e exceção em relatório de controles é sinal que os usuários desses serviços leem com atenção.

Para o auditor e para o assegurador, o ângulo prático é o mesmo: uma mudança de padrão regulatório é um risco de que controles antes efetivos deixem de operar durante a transição. É por isso que o teste não pergunta só se a instituição está na versão vigente, mas se manteve a jornada de consentimento íntegra, os logs reconstituíveis e a trilha de mudança documentada ao longo de toda a janela de migração. Ambiente de dados compartilhado sem trilha é ambiente que se afirma seguro sem poder prová-lo.

Um caso ilustrativo (anonimizado)

Considere uma instituição que participa do ecossistema tanto recebendo quanto transmitindo dados. Ao adotar a nova versão dos manuais, faz o deploy técnico no prazo e considera a tarefa encerrada. Meses depois, numa revisão de controles, três lacunas aparecem. O escopo novo passou a incluir campos que não foram reconciliados com o inventário de dados pessoais, de modo que ninguém conseguia afirmar com segurança sob qual base legal aqueles campos trafegavam. A jornada de revogação, embora funcional, não guardava registro estruturado dos aceites, o que fragilizava a prova do consentimento. E os logs de API, embora existissem, não permitiam reconstruir com clareza a associação entre acesso e consentimento vigente no momento do acesso.

Nenhuma das falhas decorreu de má intenção. Todas decorreram de tratar a atualização como evento de sistema, e não como evento de controle. Refeitos o mapeamento de dados, o desenho da trilha de consentimentos e a política de retenção de logs, a instituição passou a conseguir demonstrar, e não apenas afirmar, que operava em conformidade. O caso é ilustrativo e não se refere a nenhuma instituição específica. O padrão, contudo, é recorrente: a falha quase nunca está na tecnologia que funciona, e sim na evidência que não foi produzida.

Como a MERC pode ajudar

A MERC é a primeira e única auditoria especializada no mercado financeiro brasileiro, e ecossistemas de dados compartilhados são exatamente o ponto em que tecnologia, regulação e controle interno se encontram. Apoiamos a leitura de impacto de cada nova versão de manual sobre escopo de dados, contratos entre participantes e bases legais sob a LGPD. Estruturamos a governança de mudança que transforma o deploy em migração controlada e documentada, com registro de aprovação, teste de jornada e data de corte. Desenhamos a trilha de consentimentos e a política de logs que permitem reconstruir quem acessou o quê e sob qual autorização. E, em auditoria das demonstrações e em trabalhos de asseguração de controles no modelo da NBC TO 3402, tratamos os controles gerais de tecnologia e a jornada de consentimento como o que eles são: parte do ambiente que sustenta a confiabilidade da informação. O objetivo é direto: que a conformidade da instituição seja sustentável quando alguém pedir a evidência.

Perguntas frequentes

Uma nova versão de manual é obrigatória ou opcional?

É obrigatória, com prazo de adequação. O manual define o padrão vigente do arranjo, e operar em versão vencida significa estar fora do padrão comum que sustenta a interoperabilidade e a segurança do ecossistema. O ponto de atenção não é a decisão de migrar, que não é opcional, mas a forma de migrar: com análise de impacto, teste e trilha, ou apenas com um deploy sem evidência.

Por que o Manual de Experiência do Cliente é tão sensível?

Porque é ali que o consentimento é exercido. A jornada define como o cliente entende, autoriza e revoga o compartilhamento. Uma mudança de fluxo ou de texto pode alterar a qualidade do consentimento obtido, e o consentimento é a base jurídica de todo o compartilhamento. Revogação que seja mais difícil que a concessão é um problema de conformidade, não de design.

O que muda no escopo de dados afeta a LGPD?

Afeta diretamente. Cada campo novo no escopo é um dado pessoal a mais em circulação, que precisa de finalidade definida, base legal e caminho de segurança do início ao fim. Uma mudança de escopo obriga a reconciliar o que passou a ser compartilhado com o inventário de dados e as bases legais aplicáveis, sob pena de transmitir dado sem amparo.

Como isso aparece numa auditoria?

Aparece pelos controles gerais de tecnologia da informação, que o auditor avalia sob a NBC TA 315 (R2), e por relatórios de asseguração de controles em prestadores de serviço, no modelo da NBC TO 3402. Gestão de mudança, integridade de logs e jornada de consentimento entram no escopo. Uma migração malfeita pode virar exceção no relatório de controles e afetar a confiança do auditor no ambiente.

Qual é o erro mais comum na adoção de uma nova versão?

Tratar a atualização como evento de sistema, encerrado no deploy, e não como evento de controle. O erro típico é migrar no prazo sem reconciliar o escopo com as bases legais, sem estruturar a trilha de consentimentos e sem garantir que os logs permitam reconstruir acesso e autorização. A tecnologia funciona, mas a evidência não existe, e é a evidência que a conformidade cobra.

Este artigo tem caráter informativo e técnico e não constitui aconselhamento regulatório, contábil, de segurança da informação ou de investimento. A aplicação das normas e dos manuais depende dos fatos específicos de cada instituição e do texto integral da regulamentação e dos padrões vigentes.

Baixar PDF gratuito →