Dispõe sobre regras gerais relativas a testes em produção no Open Finance.
A Resolução BCB nº 463/2025 organiza testes em produção no Open Finance.
📌 Exige testes antes de lançamentos, versionamentos relevantes, entrada de novas participantes e correção de ciclos sem sucesso.
⚠️ Dá peso à base restrita de clientes, à ferramenta de validação, à jornada do cliente e à continuidade dos serviços existentes.
🧾 Também cria comandos para a Estrutura de Governança detalhar regras, monitoramento, métricas, performance e instruções de acesso.
A Resolução BCB nº 463/2025 cria um regime geral para testes em produção no Open Finance. O foco do documento é transformar a realização desses testes em etapa operacional estruturada para lançamentos, versionamentos relevantes de APIs, entrada de novas participantes e regularização de instituições que não participaram ou não tiveram sucesso em testes prévios. A norma não é uma simples diretriz técnica: ela cria comandos rastreáveis para instituições participantes, para a Estrutura de Governança do Open Finance e, em alguns pontos, reserva ao Banco Central a definição de parâmetros complementares.
O pacote foi tratado como retrato-fonte puro. Assim, os requisitos propostos nascem apenas da Resolução BCB nº 463/2025, sem consolidar normas posteriores nem atualizar o estado da norma por atos complementares futuros. Referências operacionais do ecossistema Open Finance foram catalogadas apenas como apoio de execução, especialmente para ferramentas, documentação técnica, agenda evolutiva e informes operacionais. O texto oficial foi identificado no site do Banco Central, mas a página consultada depende de JavaScript; por isso, a leitura artigo a artigo foi apoiada em reprodução pública do texto normativo com indicação de publicação no DOU. Essa limitação justifica o status de extração como “revisar”.
A norma se aplica a testes em produção no âmbito do Open Finance. O sujeito central dos comandos empresariais é a instituição participante do Open Finance, tanto quando a participação for obrigatória quanto quando for facultativa, conforme cada modalidade de participação. A Resolução também impõe comandos diretos à Estrutura de Governança do Open Finance, especialmente para detalhamento de regras, definição de monitoramento, cronogramas, compilação e divulgação de instruções.
A segmentação exigiu cautela. O dicionário de tags disponível não possui uma tag granular para “instituição participante do Open Finance” nem para “Estrutura de Governança do Open Finance”. Por isso, os requisitos foram roteados pelo recorte financeiro amplo, com aviso explícito de que a aplicabilidade real depende de ser participante do Open Finance ou de ser a própria Estrutura de Governança. Atuar genericamente no setor financeiro não basta, por si só, para receber esses requisitos como aplicáveis.
A norma também contém dispositivos dirigidos ao Banco Central, como a divulgação de versionamentos relevantes e principais produtos, serviços e APIs já implementados, a possibilidade de definir métodos alternativos quando não houver contratação em ambiente de produção e a faculdade de determinar pares de instituições ou limitações de base de clientes. Quando esses dispositivos geram ação empresarial condicionada, foram convertidos em requisitos condicionais; quando são apenas competência ou faculdade do regulador, foram mantidos como pontos de escopo ou exceção.
O primeiro bloco operacional está no art. 2º. Ele exige testes em produção antes do lançamento de novos produtos ou serviços e de versionamentos relevantes de APIs ligadas a produtos ou serviços existentes. Esse comando foi separado como requisito próprio porque atua como controle prévio de go-live. A instituição precisa integrar planejamento de produto, esteira de desenvolvimento, governança de mudanças, segurança, canais digitais, compliance e gestão do Open Finance para impedir lançamento sem evidência de teste aplicável.
O mesmo artigo cria gatilhos adicionais: instituições que não participaram ou não obtiveram sucesso nos testes prévios devem realizar testes em produção; novas instituições participantes também devem testar, em uma ou mais modalidades de participação, os principais produtos, serviços e APIs já implementados. Esses gatilhos foram mantidos em requisitos separados porque possuem fluxos, evidências e riscos próprios: remediação de falhas, reexecução de testes, onboarding e definição de escopo de entrada.
A norma também exige que testes posteriores por ausência, insucesso ou entrada de nova participante tenham características semelhantes aos testes prévios, quando estes tiverem ocorrido. O requisito correspondente busca evitar que um novo ciclo seja materialmente inferior ao teste de referência. A evidência recomendada é uma matriz de equivalência que compare escopo, método, pares, base de clientes, métricas, funcionalidades e jornadas.
Outro ponto central é a cobertura do escopo. Funcionalidades relacionadas a APIs do Open Finance implementadas em determinada marca, aplicação ou ambiente da instituição devem estar contempladas nos testes em produção. Essa regra impede que a instituição teste apenas a API principal e deixe fora uma marca, aplicação mobile, ambiente específico ou canal que também disponibilize a funcionalidade.
O art. 3º detalha como os testes devem ser executados. Eles devem utilizar a ferramenta de validação em produção desenvolvida pela Estrutura de Governança e ocorrer entre instituições participantes que oferecem ou oferecerão os produtos ou serviços testados. Isso exige evidência técnica de uso da ferramenta, além de registro dos papéis das instituições envolvidas no teste.
A base de clientes é outro elemento sensível. Os testes devem ser restritos a uma base definida pelas instituições participantes, acrescida de relação de clientes informada pela Estrutura de Governança e pelo Banco Central. Como o teste ocorre em produção, esse ponto foi classificado como alta criticidade. A instituição deve manter lista aprovada e versionada, parametrização sistêmica, logs de execução e conciliação entre clientes testados e clientes autorizados. A exposição de cliente fora da base autorizada pode gerar risco operacional, de privacidade, de consumidor e regulatório.
A Resolução determina ainda que os testes cubram funcionalidades dos produtos ou serviços, jornadas de experiência do cliente e integração com ferramentas da Estrutura de Governança, conforme regulamentação vigente e documentação aplicável. Esse comando é mais amplo que uma simples validação de endpoint. O teste deve demonstrar que a jornada do cliente funciona, que as ferramentas do ecossistema se integram corretamente e que o produto ou serviço está aderente aos critérios documentais e regulatórios.
O art. 2º, § 7º, estabelece uma proteção importante: testes em produção não devem afetar o regular fornecimento de produtos e serviços já implementados. Esse dispositivo foi tratado como requisito de proibição/continuidade operacional. O teste deve ter monitoramento, limites, plano de rollback, gestão de incidentes e acompanhamento de performance para evitar degradação ou indisponibilidade de serviços existentes.
O art. 4º cria uma obrigação de demonstração ao Banco Central: as instituições participantes devem demonstrar a aderência das jornadas de experiência do cliente à regulamentação vigente e aos documentos da Estrutura de Governança. A norma permite que essa demonstração seja realizada por verificação de atendimento de requisitos operacionalizada pela Estrutura de Governança. Em termos de compliance, isso exige matriz de aderência, evidência de execução, resultado de verificação e trilha de envio ou disponibilização ao regulador.
O art. 5º exige que as instituições forneçam à Estrutura de Governança instruções e forma de acesso ao seu ambiente de testes em produção. Esse requisito tem natureza de entrega operacional. A instituição deve produzir instruções tecnicamente suficientes e seguras, com controle de versão, revisão de tecnologia e segurança, registro de disponibilização e evidência de recebimento ou envio.
O art. 6º prevê que o prazo máximo para atendimento de requisições de resolução de problemas, ou tickets, referentes aos testes em produção pode ser reduzido conforme definição do Banco Central. A Resolução não traz um prazo numérico, por isso o requisito foi estruturado como condicional: quando o Banco Central definir ou reduzir o prazo, a instituição deve parametrizar sua fila de tickets, monitorar SLA, priorizar tratamento e manter relatório de atendimento.
A Resolução atribui papel relevante à Estrutura de Governança. Para versionamentos de APIs que não forem considerados relevantes, ela deve estabelecer cronograma de acionamento escalonado durante o período de convivência entre a versão anterior e a nova versão, além de definir itens mínimos de monitoramento. Para ajustes em implementações que não envolvam versionamentos de APIs, a Estrutura também deve estabelecer itens mínimos de monitoramento.
O comando mais estruturante está no art. 3º, § 2º: a Estrutura de Governança deve detalhar o escopo e as regras de funcionamento dos testes em produção, contemplando no mínimo cronograma de atividades, quantidade mínima de testes, critérios de seleção e habilitação de usuários participantes, métricas a serem enviadas pelas instituições, ferramentas de integração, indicadores, itens de experiência do cliente, requisitos de performance e condições para canal permanente com instituições de desempenho insuficiente.
Esses itens foram tratados como requisito de governança central porque servem de base para que as instituições executem seus próprios testes. A ausência ou incompletude desse detalhamento comprometeria o funcionamento coordenado do regime. O pacote também manteve requisito específico para a compilação e divulgação, pela Estrutura, das instruções e formas de acesso recebidas das instituições participantes.
As evidências recomendadas giram em torno de plano de teste em produção, matriz de escopo, relatório da ferramenta de validação, lista de clientes autorizados, logs por cliente, matriz de cobertura de funcionalidades e jornadas, evidência de uso da ferramenta, resultados de verificação de aderência e registros de envio ao Banco Central ou à Estrutura de Governança. Para requisitos condicionais, como determinações do Banco Central e redução de prazo de tickets, a evidência-chave é o registro da determinação recebida e a prova de sua implementação.
As áreas internas mais envolvidas tendem a ser Open Finance/pagamentos, tecnologia, segurança, produto/canais, operações, compliance e riscos/controles. Jurídico-regulatório aparece apenas onde há interpretação ou atendimento a determinação do Banco Central. Auditoria interna não foi incluída como público padrão porque a norma não a coloca como destinatária nem executora direta.
Os controles sugeridos priorizam bloqueio de go-live sem teste, matriz de cobertura, parametrização de base de clientes, monitoramento de impacto em serviços existentes, gestão de SLA de tickets, controle de versão de instruções e governança de documentos mínimos da Estrutura de Governança. A frequência normativa não é recorrente por calendário; a maioria dos requisitos é por evento, acionada por lançamento, versionamento, entrada de participante, teste em produção, definição do Banco Central ou organização de ciclo pela Estrutura.
O primeiro ponto de atenção é a completude do texto-fonte. A identificação da norma é segura no site do Banco Central, mas a extração artigo a artigo foi feita com apoio em reprodução textual por limitação de JavaScript na página oficial acessada. Antes de uso como curadoria certificada, recomenda-se conferir o pacote contra o DOU ou contra a página oficial renderizada do BCB.
O segundo ponto é a segmentação. Como não há tag específica para participante do Open Finance, a segmentação pode gerar falso positivo se usada sem o filtro material de aplicabilidade descrito em cada requisito. O cliente deve aplicar o requisito apenas quando for instituição participante do Open Finance ou, nos requisitos próprios, quando for a Estrutura de Governança.
O terceiro ponto é a coexistência de obrigações das instituições e da Estrutura de Governança no mesmo documento-fonte. O pacote preserva ambos os blocos porque a Resolução cria comandos operacionais para ambos. Contudo, em um workspace voltado apenas a instituições participantes, os requisitos dirigidos à Estrutura de Governança podem ser ocultados, inativados ou mantidos apenas como referência de dependência externa.
Por fim, a norma depende de parâmetros operacionais a serem divulgados ou definidos pelo Banco Central e pela Estrutura de Governança, como versionamentos relevantes, produtos principais, regras de funcionamento, métricas, indicadores, requisitos de performance e eventuais prazos reduzidos para tickets. Esses elementos não foram inventados no pacote. Onde a Resolução não especifica prazo, canal, formulário ou número, o requisito foi estruturado com gatilho e evidências de acompanhamento, sem criar detalhe inexistente no documento-fonte.
Temas
