Asseguração no Open Finance: consentimento, segurança de APIs e controles no compartilhamento de dados entre participantes

Com o Open Finance consolidado, a asseguração de consentimento, segurança de APIs e controles no compartilhamento de dados vira exigência de confiança.

Resumo

• O Open Finance amadureceu em escala e escopo, e com isso orisco associado ao compartilhamento de dadosdeixou de ser teórico: mais dados, mais participantes e mais integrações significam mais superfície a controlar.

• A segurança não se resume àcriptografia em trânsito: o que sustenta a confiança é o conjunto de controles sobre consentimento, autenticação, autorização, segregação de acessos e rastreabilidade de quem acessou o quê, quando e com que base.

• Oconsentimento é o núcleo jurídico e técnicodo modelo: escopo definido, prazo definido, registro explícito e revogação efetiva — um consentimento mal implementado é uma falha de controle com consequências de proteção de dados.

• Aasseguração de controles— no espírito dos relatórios de controles em organizações prestadoras de serviço — é o instrumento que permite a um participante confiar nos controles de outro sem auditar cada um individualmente, sustentando a cadeia de responsabilidade do ecossistema.

Criptografia é o piso, não o teto

Quando se fala em segurança de dados no Open Finance, a resposta reflexa costuma ser a criptografia: os dados trafegam cifrados, acessados apenas por processo tecnológico construído para esse fim. Isso é verdadeiro e necessário — mas é o piso. A criptografia protege o dado em trânsito; ela não decide se aquele acesso deveria acontecer. Quem decide isso é a camada de controle: o consentimento que autorizou, a autenticação que confirmou a identidade, a autorização que limitou o escopo, e a rastreabilidade que registra o que aconteceu. Um dado perfeitamente cifrado, entregue a quem não deveria tê-lo porque o controle de consentimento falhou, é uma violação — cifrada, mas violação.

Por isso a segurança do ecossistema é uma questão de arquitetura de controles, não de tecnologia isolada. O compartilhamento só deve ocorrer com consentimento explícito e registrado, com escopo e prazo definidos, e essa frase — simples de escrever — esconde uma cadeia de exigências técnicas: o consentimento precisa ser granular o suficiente para não conceder mais do que o cliente autorizou; precisa ter prazo que efetivamente expire; precisa poder ser revogado de modo que a revogação encerre o acesso de fato, e não apenas na tela. Cada um desses pontos é um controle que pode falhar, e é sobre a eficácia desses controles — não sobre a existência da criptografia — que a asseguração se debruça.

O consentimento como controle, não como formalidade

O consentimento é o coração do modelo. Juridicamente, é o que legitima o tratamento do dado; tecnicamente, é o que parametriza o acesso. Um consentimento bem desenhado define escopo (quais dados), finalidade (para quê), prazo (até quando) e registro (prova de que foi dado). Um consentimento mal desenhado abre brechas: escopo amplo demais entrega mais do que o cliente quis compartilhar; prazo indefinido mantém o acesso vivo depois que a finalidade se encerrou; revogação que não propaga deixa o dado fluindo depois que o cliente pediu para parar.

O ponto que separa a boa da má implementação é o ciclo de vida do consentimento. Concedê-lo é fácil; o difícil é gerenciá-lo ao longo do tempo — expirá-lo no prazo, revogá-lo quando pedido, e garantir que a revogação encerre o acesso em todos os pontos da cadeia. Um participante que recebe dados com base em um consentimento precisa ter certeza de que aquele consentimento continua válido, e essa certeza depende de controles que muitas vezes cruzam a fronteira entre organizações. É aqui que o exame independente ganha valor: verificar se o consentimento é respeitado de ponta a ponta é diferente de verificar se ele foi coletado — e é o respeito de ponta a ponta que a proteção de dados exige.

A cadeia de responsabilidade entre participantes

O Open Finance é, por natureza, um ecossistema de muitos participantes que dependem uns dos outros. Um participante que transmite dados confia que o receptor os tratará conforme o consentimento; o receptor confia que o transmissor validou a identidade do cliente. Essa confiança mútua não pode se apoiar em cada participante auditar todos os outros — seria inviável. O mecanismo que resolve o problema é a asseguração de controles no espírito dos relatórios de controles em organizações prestadoras de serviço: uma organização submete seus controles a exame independente, e o relatório resultante permite que os demais confiem naqueles controles sem precisar testá-los individualmente.

Esse modelo tem uma consequência prática relevante. Quando um participante presta serviço de tecnologia a outros — hospedando, processando ou intermediando dados — os controles dele passam a fazer parte do ambiente de controle dos que o contratam. Uma falha na sua camada não fica contida: propaga-se para todos os que dependem dele. Por isso a asseguração de prestadores de serviço no ecossistema não é um luxo de conformidade; é a costura que mantém a cadeia de responsabilidade íntegra. Um relatório de asseguração crível responde a uma pergunta que todo participante da cadeia precisa fazer sobre seus fornecedores de dados e tecnologia: os controles descritos existem, e operaram de forma eficaz ao longo do período? Sem essa resposta, a confiança é fé — e fé não é controle.

Caso anonimizado: a revogação que não revogava

Uma instituição participante do ecossistema oferecia aos clientes o compartilhamento de dados com escopo granular e um botão de revogação bem visível. No papel, tudo estava correto: consentimento explícito, escopo definido, revogação disponível. Um exame de controles, porém, revelou uma fratura na cadeia. Quando o cliente revogava o consentimento, o pedido encerrava o acesso na interface principal, mas um fluxo de integração secundário — usado para alimentar um serviço analítico — continuava recebendo dados por um intervalo, porque a revogação não propagava para aquele ponto em tempo hábil. Nenhum dado vazou para fora; a criptografia funcionou o tempo todo. Mas o dado seguiu sendo tratado depois que o cliente pediu para parar, o que é, em si, uma falha de controle de consentimento com implicação direta de proteção de dados.

A correção foi técnica e organizacional: mapear todos os pontos da cadeia que consumiam o dado consentido, garantir que a revogação propagasse para todos eles, e instituir uma verificação periódica de que consentimentos expirados ou revogados efetivamente encerravam o acesso em cada ponto. O que o caso ensina é que a segurança do Open Finance não se prova na tela bonita do consentimento, mas na conduta invisível da revogação — e que só um exame que segue o dado por toda a cadeia encontra a fratura que a interface esconde.

Como a MERC pode ajudar

A MERC atua na asseguração dos controles que sustentam o compartilhamento de dados. Avaliamos o ciclo de vida do consentimento — concessão, escopo, prazo, expiração e revogação — verificando não se ele foi coletado, mas se é respeitado de ponta a ponta. Examinamos os controles de autenticação, autorização e segregação de acessos, a segurança e o monitoramento das interfaces, e a integridade da trilha que registra quem acessou o quê. E, para participantes que prestam serviço de tecnologia a outros, estruturamos relatórios de asseguração de controles que permitem aos contratantes confiar sem precisar auditar individualmente.

Como primeira e única auditoria especializada no mercado financeiro brasileiro, a MERC combina o entendimento da regulação do ecossistema com a prática de asseguração de controles em ambiente tecnológico — uma interseção rara e cada vez mais necessária à medida que o escopo do compartilhamento avança sobre crédito, investimentos e novas funcionalidades. A confiança é o ativo mais valioso do Open Finance, e confiança que não se demonstra por controle é confiança que ainda não foi testada.

Perguntas frequentes

Se os dados trafegam criptografados, a segurança já não está resolvida?

Não. A criptografia protege o dado em trânsito, mas não decide se aquele acesso deveria ocorrer. Quem decide isso são os controles de consentimento, autenticação e autorização. Um dado cifrado entregue a quem não deveria tê-lo, por falha de consentimento, continua sendo uma violação.

O que significa "respeitar o consentimento de ponta a ponta"?

Significa garantir que o escopo, o prazo e, sobretudo, a revogação sejam efetivos em todos os pontos da cadeia que tratam o dado — não apenas na interface principal. Um consentimento revogado precisa encerrar o acesso em todos os fluxos que o consumiam, e não só na tela onde o cliente clicou.

Por que a asseguração de controles é importante em um ecossistema de muitos participantes?

Porque é inviável cada participante auditar todos os outros. O relatório de asseguração de controles permite que uma organização submeta seus controles a exame independente e que os demais confiem neles sem precisar testá-los individualmente, sustentando a cadeia de responsabilidade.

O que a asseguração examina além da tecnologia?

Examina o desenho e a eficácia operacional dos controles ao longo de um período: o ciclo de vida do consentimento, a concessão e revogação de acessos, o monitoramento das interfaces, a resposta a incidentes e a integridade da trilha de auditoria. É a operação real dos controles, não apenas sua existência no papel.

Como um prestador de serviço de tecnologia afeta o ambiente de controle de quem o contrata?

Quando ele hospeda, processa ou intermedia dados, seus controles passam a integrar o ambiente de controle dos contratantes. Uma falha na camada dele se propaga a todos que dependem dele, o que torna a asseguração desses prestadores parte essencial da integridade da cadeia.

A ampliação do escopo do compartilhamento aumenta o risco?

Sim, na medida em que mais categorias de dados e mais funcionalidades significam mais superfície a controlar. Isso não é motivo para frear o ecossistema, mas para amadurecer os controles no mesmo ritmo do escopo — de modo que a confiança acompanhe a expansão.

Este material tem caráter informativo e técnico e não constitui aconselhamento jurídico, de proteção de dados ou de auditoria para caso específico. A avaliação de controles de compartilhamento de dados depende das circunstâncias de cada participante e das normas aplicáveis vigentes.