Estabelece diretrizes para a interoperabilidade no Open Finance entre participantes dos sistemas regulados.
A Resolução Conjunta nº 5/2022 conecta Open Finance e Open Insurance pela interoperabilidade.
📌 Exige padrões técnicos e procedimentos operacionais para compartilhamento padronizado de dados.
🤝 Requer foro conjunto para infraestrutura de suporte, como diretório, service desk, disputas e testes de APIs.
🧾 O envio de propostas ao Banco Central e à Susep tinha prazo único até 30/11/2023 e foi tratado como requisito histórico encerrado.
A Resolução Conjunta nº 5, de 20 de maio de 2022, é uma norma autônoma e enxuta voltada à interoperabilidade no Open Finance. Ela não reescreve os requisitos completos do Open Finance nem do Open Insurance; em vez disso, cria um ponto de conexão entre os sistemas regulados pela Resolução Conjunta nº 1/2020 e pela Resolução CNSP nº 415/2021. O núcleo operacional do documento está no art. 3º: os participantes desses sistemas, por meio de suas estruturas de governança, devem propor e implementar padrões técnicos e procedimentos operacionais que assegurem a interoperabilidade e devem estabelecer foro conjunto para discussão e deliberação sobre a infraestrutura de suporte necessária.
A norma também trouxe uma entrega de prazo único: as propostas de padrões técnicos e procedimentos operacionais deveriam ser encaminhadas até 30 de novembro de 2023 ao Banco Central do Brasil e à Superintendência de Seguros Privados. Como esse prazo está encerrado por data expressa do próprio documento-fonte, o pacote mantém esse item como requisito histórico, útil para auditoria, retenção de evidências e rastreabilidade de submissões regulatórias, mas não como obrigação recorrente viva.
O documento alcança os participantes dos sistemas de Open Finance e Open Insurance indicados no art. 2º. O primeiro bloco está vinculado à Resolução Conjunta nº 1/2020, que disciplina a implementação do Open Finance no âmbito de instituições financeiras, instituições de pagamento e demais instituições autorizadas a funcionar pelo Banco Central do Brasil. O segundo bloco está vinculado à Resolução CNSP nº 415/2021, que disciplina o Sistema de Seguros Aberto, originalmente voltado a sociedades seguradoras, entidades abertas de previdência complementar e sociedades de capitalização.
A segmentação do pacote usa lista positiva das categorias disponíveis no dicionário Okai que mais se aproximam desses sujeitos regulados. Como não há uma tag única para “participante do Open Finance” ou “participante do Open Insurance”, o roteamento deve ser lido com a condição material descrita nos requisitos: a aplicabilidade depende do enquadramento efetivo como participante dos sistemas citados e da atuação por meio das estruturas de governança responsáveis pela implementação. A mera atuação ampla em tecnologia financeira, seguros, distribuição, consultoria ou prestação de serviços auxiliares não basta, isoladamente, para tornar a empresa sujeita a estes requisitos.
O primeiro comando operacional é a obrigação de propor e implementar padrões técnicos e procedimentos operacionais de interoperabilidade. Esse comando exige controle de versões, participação coordenada em governança técnica, validação de aderência à regulamentação aplicável e evidências de implementação. A norma não define todos os detalhes técnicos das APIs, dos padrões ou dos fluxos; ela determina que esses padrões e procedimentos sejam construídos e aplicados no âmbito das estruturas responsáveis pelos sistemas.
O segundo comando é a criação ou manutenção de foro de discussão e deliberação conjunta para a infraestrutura de suporte. A própria Resolução dá exemplos relevantes dessa infraestrutura: diretório de participantes, service desk, plataforma de resolução de disputas, ambiente de testes de APIs e outros serviços previstos em regulamentação específica. Esse requisito tem natureza de governança e exige registros de deliberação, acompanhamento de pendências, responsabilidades claras e capacidade interna de transformar decisões do foro em ações técnicas e operacionais.
O terceiro comando foi a submissão das propostas ao Banco Central e à Susep até 30 de novembro de 2023. Esse requisito deve ser visto como marco histórico de entrega regulatória. Para empresas e estruturas de governança, o valor atual do requisito está em preservar o dossiê do envio, comprovar a versão submetida, relacionar eventuais manifestações das autarquias e demonstrar rastreabilidade entre o que foi proposto, aprovado, ajustado e implementado.
A norma exige uma leitura integrada entre compliance regulatório, tecnologia, governança de produto, segurança e áreas de negócio impactadas pelo Open Finance ou Open Insurance. O compliance não deve tratar a resolução apenas como uma norma conceitual. Embora ela seja curta, os comandos do art. 3º dependem de evidências robustas: inventários de padrões, matrizes de aderência normativa, registros de homologação, atas do foro conjunto, plano de ação para infraestrutura de suporte e dossiê da entrega regulatória de 2023.
Para fins de GRC, o pacote separa os requisitos por processo controlável. A proposição e implementação de padrões técnicos ficou em requisito próprio, porque exige controles técnicos, homologação e aderência regulatória. O foro conjunto ficou em requisito separado, porque sua evidência típica é de governança: regimento, atas, pautas, deliberações e acompanhamento de pendências. A entrega ao Banco Central e à Susep ficou em requisito histórico separado, porque tem destinatário, prazo e evidências próprias.
As evidências mais importantes para o requisito de padrões técnicos são inventário de padrões e versões, matriz de aderência regulatória, relatórios de teste, homologações, registros de implementação e rastreabilidade entre decisões do ecossistema e alterações internas. Para o requisito de foro conjunto, as evidências principais são documentos de governança do foro, atas, listas de presença, pautas, registros de deliberação, plano de ação e acompanhamento de pendências sobre diretório, service desk, plataforma de disputas e ambiente de testes de APIs.
Na entrega histórica de 2023, a organização deve preservar comprovante de encaminhamento, versão final das propostas, anexos técnicos, aprovações internas, comunicações com Banco Central e Susep e eventual documentação que relacione as propostas aos padrões efetivamente implementados ou posteriormente incorporados à regulamentação.
As áreas internas mais prováveis são tecnologia, segurança e dados, compliance regulatório, jurídico regulatório, áreas de produto e canais, governança executiva e áreas especializadas em Open Finance ou Open Insurance. A participação de cada área deve ser calibrada conforme o tipo de instituição e o papel exercido no ecossistema. Em instituições financeiras e de pagamento, a área de Open Finance ou pagamentos digitais tende a ser especialmente relevante. Em seguradoras, entidades abertas de previdência complementar e sociedades de capitalização, as áreas ligadas a Open Insurance e produtos de seguros tendem a assumir papel central.
O principal ponto de atenção é não transformar a Resolução Conjunta nº 5/2022 em consolidação do regime completo de Open Finance ou Open Insurance. Ela cita a Resolução Conjunta nº 1/2020 e a Resolução CNSP nº 415/2021, mas não reproduz seus requisitos nem substitui a análise desses documentos em pacotes próprios. Este pacote é o retrato-fonte da Resolução Conjunta nº 5/2022: ele captura somente os comandos que nasceram nela.
Outro ponto relevante é o tratamento do prazo de 30 de novembro de 2023. Como a data está expressa no documento-fonte e já se encerrou, o requisito correspondente foi marcado como encerrado e inativo para operação corrente. Ainda assim, ele permanece útil como requisito histórico porque pode sustentar auditorias de implementação, revisões de evidência e análise de aderência entre propostas submetidas e padrões implementados.
Também é importante distinguir comandos empresariais de comandos dirigidos ao regulador. O art. 4º determina que Banco Central e Susep adotem medidas necessárias, incluindo atos conjuntos e cronograma de implementação. Esse dispositivo foi mantido como ponto do documento, mas não virou requisito empresarial, porque é uma atribuição das autarquias. Empresas podem ser afetadas por atos posteriores, mas esses efeitos devem ser processados em pacotes próprios dos atos que os criarem.
O art. 1º foi tratado como ponto de escopo. O art. 2º, inciso I, foi tratado como definição de interoperabilidade. O art. 2º, inciso II, foi tratado como definição e absorvido no requisito de foro conjunto, pois a lista de infraestruturas de suporte é justamente o objeto prático da governança exigida. O art. 3º, inciso I, gerou requisito autônomo de padrões técnicos e procedimentos operacionais. O art. 3º, § 1º, foi absorvido nesse requisito por ser condição de aderência regulatória das mesmas propostas e implementações. O art. 3º, inciso II, gerou requisito próprio de governança. O art. 3º, § 2º, gerou requisito histórico de entrega regulatória. O art. 4º foi classificado como comando interno do regulador. O art. 5º foi usado como vigência geral.
A página oficial do Banco Central identifica o normativo, mas no ambiente de consulta a visualização integral dependeu de JavaScript. A leitura do texto integral foi conferida contra publicação do DOU reproduzida em espelho não oficial e contra a minuta oficial anexa ao Voto 43/2022-CMN, cujo conteúdo material coincide com os comandos operacionais analisados. Por prudência, o manifest marca a extração como “revisar”, recomendando conferência contra versão certificada do DOU se o processo de importação exigir comprovação documental formal.
O pacote não incorpora alterações posteriores, atos complementares posteriores nem consolida o estado atual do Open Finance ou do Open Insurance. Caso o objetivo seja gerar uma visão consolidada vigente, devem ser processados os atos posteriores em pacotes próprios ou solicitado expressamente um trabalho consolidado.
Nenhum item vinculado a este artefato.
