Norma
31/01/2025

Instrução Normativa BCB N° 588

Divulga a versão 4.0 do Manual de Serviços da Estrutura de Governança do Open Finance, detalhando requisitos técnicos e operacionais para instituições participantes.

Resumo

A IN BCB 588/2025 torna obrigatória a versão 4.0 do Manual de Serviços do Open Finance para instituições participantes.

📌 Pontos centrais: Diretório, Service Desk, tickets, notificações, Sandbox, validação em produção e monitoramento.

⚠️ Atenção a incidentes, prazos por evento, relatórios de desconformidade e planos de adequação.

🧾 A segmentação deve ser revisada conforme a empresa seja participante do Open Finance e sua modalidade de participação.

Resumo executivo

A Instrução Normativa BCB nº 588, de 31 de janeiro de 2025, divulga a versão 4.0 do Manual de Serviços Prestados pela Estrutura de Governança do Open Finance. O documento é relevante porque transforma serviços centrais da infraestrutura compartilhada do Open Finance em um conjunto de requisitos técnicos e operacionais que devem ser observados pelas instituições participantes. O pacote foi montado como retrato-fonte: ele extrai comandos que nascem da própria Instrução Normativa e do manual anexo, sem consolidar alterações posteriores.

O eixo da curadoria é a operacionalização da participação no Open Finance. O manual cobre Diretório de Participantes, testes de conformidade, Service Desk, gestão de tickets, notificações, Portal do Open Finance, Sandbox, validação em produção e monitoramento do ecossistema. Muitos comandos são dirigidos à Estrutura de Governança, que deve prover serviços, SLAs e funcionalidades. Esses itens foram preservados como documentoPontos para rastreabilidade, mas não foram convertidos automaticamente em requisitos empresariais quando não havia conduta verificável para a instituição participante.

Escopo e sujeitos regulados

O sujeito empresarial mais importante é a instituição participante do Open Finance. A Instrução Normativa afirma a observância obrigatória do manual por essas instituições. Como o dicionário de segmentação disponível não possui uma tag própria para “instituição participante do Open Finance” nem para “modalidade de participação”, a segmentação dos requisitos usa categorias financeiras próximas e mantém aviso de revisão. Isso reduz perda de cobertura, mas pode gerar falso positivo para entidades financeiras que não sejam participantes do Open Finance. Por isso, cada requisito traz aplicabilidade condicionada ao enquadramento como instituição participante.

Também há comandos voltados à Estrutura de Governança do Open Finance. A Estrutura deve prover Diretório, Service Desk, Portal, Sandbox, validação em produção, mecanismos de notificação, monitoramento e outros serviços essenciais. Esses comandos importam para a empresa porque definem canais, sistemas, prazos e evidências que ela usará, mas nem todos impõem uma ação direta à instituição. A curadoria separou o que é obrigação de prover serviço, normalmente interna à Estrutura de Governança, do que é obrigação de usar, responder, reportar, corrigir, manter evidência ou acompanhar pela instituição participante.

Principais comandos operacionais

O primeiro bloco prático está no Diretório de Participantes. A instituição deve manter dados cadastrais, representantes, contatos, informações de participação e dados relacionados a APIs. O Diretório é também o ambiente que formaliza a participação no Open Finance e sustenta identidade, autorização de aplicações e consulta a informações. A curadoria gerou requisitos para manutenção cadastral, certificação de APIs e recertificações, porque esses pontos têm impacto direto na capacidade de operar no ambiente produtivo.

O segundo bloco é o Service Desk. O manual detalha abertura, tipos, gestão, estados, prazos, trilha de auditoria, encerramento e reabertura de tickets. A instituição participante deve tratar requisições, incidentes, demandas de monitoramento, notificações e suporte por esse canal. A extração separou tickets de requisição, incidentes sem indisponibilidade, incidentes com indisponibilidade, análise pós-incidente, indícios de desconformidade, entregas de relatório, planos de adequação e avaliações de taxa de conversão. Essa granularidade foi adotada porque os prazos, evidências, riscos e donos operacionais são diferentes.

O terceiro bloco envolve notificações. Instituições participantes e Estrutura de Governança devem reportar indisponibilidades de APIs, degradação de qualidade, indisponibilidades programadas e restabelecimento de serviços. Embora o detalhamento de forma e prazo fique no Portal do Open Finance, o manual cria a obrigação-fonte de reportar esses eventos. Por isso, o requisito foi tratado como entrega por evento, sem recorrência normativa fixa.

O quarto bloco trata de mecanismos de apoio técnico: Área do Participante, Sandbox e validação em ambiente produtivo. A Área do Participante concentra orientações sobre participação, parcerias, implementação, registro, Service Desk, disputas, custeio, regulamentação e escopo de dados e serviços. O Sandbox apoia testes automatizados e implementações de exemplo. A validação em produção verifica conformidade e registro de APIs e deve ter política seguida pelas instituições participantes. Esses itens foram convertidos em requisitos quando há uso direto ou observância pela instituição.

Impactos para compliance

A norma exige integração forte entre tecnologia, operações de Open Finance, gestão de riscos, compliance e áreas responsáveis por APIs e canais digitais. O cumprimento não se resume a conhecer o manual: a empresa precisa demonstrar uso correto de sistemas, atendimento tempestivo de tickets, controle de certificação de APIs, acompanhamento de desconformidades e retenção de evidências. Para compliance, o ponto crítico é manter uma matriz que conecte cada fluxo do manual ao processo interno correspondente.

O tratamento de incidentes merece atenção especial. Em incidentes com indisponibilidade, há meta de restabelecimento em horas e fechamento do ticket após restabelecimento. Em incidentes sem indisponibilidade, os prazos variam conforme degradação de qualidade, erro de desconformidade ou demais erros. Além disso, após o fechamento de ticket de incidente, a instituição deve avaliar necessidade de ajustes de causa raiz e controles internos, documentar a análise em relatório e mantê-lo à disposição do Banco Central. Esse fluxo exige evidências técnicas, logs, análise de causa raiz, plano de correção e governança de encerramento.

O monitoramento também é central. O manual remete ao Manual de Monitoramento do Open Finance para itens monitorados, evidências e fluxo de medidas. Quando houver indício de desconformidade, a instituição deve avaliar a situação e, se discordar, apresentar argumentação fundamentada. Em fases posteriores, pode ser demandada a entregar relatório de situações de desconformidade, plano de adequação e avaliação específica de taxa de conversão. Esses requisitos foram classificados com criticidade alta quando envolvem entrega formal, prazo ou potencial escalonamento no fluxo de monitoramento.

Evidências, controles e áreas envolvidas

As principais evidências esperadas incluem protocolos de tickets, registros de abertura, histórico de estados, logs, telas, relatórios de análise pós-incidente, documentos de causa raiz, planos de adequação, avaliações de taxa de conversão, argumentos fundamentados, comprovantes de atualização cadastral, certificados de APIs, registros de recertificação e trilhas de validação em produção. A empresa deve preservar não apenas o documento final, mas a linha do tempo que demonstra quando recebeu a demanda, quem analisou, qual prazo era aplicável, o que foi enviado e como a demanda foi encerrada.

As áreas internas mais envolvidas tendem a ser Open Finance, tecnologia, operações, controles, compliance e, em alguns casos, jurídico-regulatório. Tecnologia e Open Finance são centrais nos requisitos de APIs, Sandbox, certificação, validação, incidentes e indisponibilidade. Compliance e riscos aparecem principalmente nos itens de monitoramento, desconformidade, plano de adequação e retenção de evidências. Jurídico-regulatório deve ser chamado quando houver argumentação formal, dúvida de enquadramento, medidas regulatórias, disputa ou necessidade de interpretação normativa.

Pontos de atenção

A curadoria não criou série de recorrência porque o manual trabalha, em regra, com gatilhos por evento: abertura de ticket, incidente, demanda da Estrutura de Governança, indisponibilidade, restabelecimento, encerramento ou indício de desconformidade. Mesmo quando o texto fala em disponibilidade diária ou trimestral, os SLAs são em grande parte obrigações da Estrutura de Governança sobre os serviços prestados; não foram tratados como calendário recorrente para a instituição participante.

A revogação da Instrução Normativa BCB nº 359/2023 foi registrada em alteracoesRequisitos. O pacote não duplicou os requisitos da versão anterior. A versão 4.0 também informa, no sumário, atualizações nas seções 2, 3 e 5 e simplificação da seção 8, considerando o Manual de Monitoramento do Open Finance. Esse efeito foi registrado como alteração de redação e atualização operacional, sem consolidar histórico externo.

As regras transitórias da seção 9 foram tratadas como comandos nascidos do documento-fonte. A obrigação de apresentação de evidências para certos itens monitorados e as alterações relacionadas à avaliação de encerramento de tickets têm marco de 1º de julho de 2025. Como o pacote foi gerado em 2026, esses requisitos foram marcados como vigentes, mas com início específico indicado para rastreabilidade.

Decisões de cobertura

Foram criados requisitos quando havia ação verificável pela instituição participante: observar manual, manter cadastro, certificar APIs, responder tickets, corrigir incidentes, documentar causa raiz, avaliar desconformidade, entregar relatório, apresentar plano, reportar notificações, usar orientações de Portal, testar no Sandbox, seguir validação em produção e gerir informações de monitoramento. Foram preservados apenas como pontos os comandos de desenho de serviço, SLAs e conteúdo obrigatório do Portal que se dirigem principalmente à Estrutura de Governança.

O mapa de cobertura foi usado para explicitar essas escolhas. Itens conceituais, fundamentos, referências e finalidade do manual foram mantidos como documentoPontos de definição ou escopo. Itens internos da Estrutura de Governança foram marcados como interno do regulador ou da estrutura operacional do ecossistema, sem gerar requisito empresarial direto. Essa decisão evita que a plataforma envie à instituição participante obrigações que, no texto, pertencem à entidade responsável pela infraestrutura comum.

Limitações e revisão recomendada

O principal ponto de revisão é a segmentação. A expressão usa o recorte mais próximo disponível no dicionário, mas a aplicabilidade real depende de a empresa ser instituição participante do Open Finance e de sua modalidade de participação. Recomenda-se que o workspace do cliente aplique filtros adicionais próprios, como modalidade, APIs implementadas, escopo de dados ou serviços, e status de participação obrigatório ou voluntário.

Outra limitação decorre da natureza do manual. Alguns detalhes operacionais são remetidos ao Portal do Open Finance, à Área do Desenvolvedor, ao Manual de Monitoramento e a políticas definidas pela Estrutura de Governança. Esses materiais foram cadastrados como referências operacionais quando úteis, mas não foram usados para inventar prazos ou obrigações que não apareçam no documento-fonte. Para execução prática, o cliente deve vincular os requisitos aos manuais, guias, sistemas e políticas aplicáveis no momento de sua operação.