Norma
31/01/2025

Instrução Normativa BCB N° 587

Divulga a versão 6.0 do Manual de Escopo de Dados e Serviços do Open Finance com atualizações em campos e requisitos técnicos.

Resumo

A IN BCB 587/2025 divulga a versão 6.0 do Manual de Escopo de Dados e Serviços do Open Finance.

📌 Exige atenção a campos obrigatórios, APIs, consentimento e qualidade de dados.

⚠️ Inclui novidades sobre portabilidade salarial, investimentos, câmbio, pagamentos sucessivos e pagamento sem redirecionamento.

🧾 O pacote é retrato-fonte: não consolida normas posteriores e registra a revogação da IN BCB 371/2023 separadamente.

Resumo executivo

A Instrução Normativa BCB nº 587/2025 divulga a versão 6.0 do Manual de Escopo de Dados e Serviços do Open Finance. Embora o ato formal seja uma Instrução Normativa, o conteúdo operacional relevante está no anexo: um manual técnico que define conjuntos mínimos de dados e serviços a serem implementados pelas instituições participantes. O documento tem efeito prático forte porque transforma o escopo regulatório do Open Finance em campos, domínios, classificações e procedimentos de compartilhamento que precisam ser refletidos em APIs, bases de dados, jornadas de consentimento e controles de qualidade.

O núcleo do pacote foi construído como retrato-fonte da própria Instrução Normativa e de seu anexo. Isso significa que os requisitos aqui sugeridos não incorporam consolidação posterior, não atualizam o status da norma com atos posteriores e não recriam obrigações da Instrução Normativa BCB nº 371/2023, que é revogada pelo art. 2º. O efeito da revogação foi registrado em alteracoesRequisitos, como esperado para uma norma que substitui manual anterior, mas os requisitos materiais extraídos nascem da versão 6.0 divulgada pela própria IN BCB nº 587/2025.

Escopo e sujeitos regulados

O documento dirige-se às instituições participantes do Open Finance. O manual detalha dados de canais de atendimento, produtos e serviços disponíveis à contratação, cadastro de clientes e representantes, dados transacionais, iniciação de transação de pagamento e modalidade Pix. A segmentação técnica do pacote usa roteamento setorial financeiro amplo porque o dicionário disponível não contém marcador específico para “participante do Open Finance” ou “instituição autorizada pelo Banco Central participante do Open Finance”. Assim, a aplicabilidade real deve ser filtrada pelo enquadramento da empresa como participante do Open Finance e, em vários requisitos, pelo produto, serviço ou operação efetivamente ofertado.

Essa distinção é importante para evitar falso positivo operacional. Uma empresa do setor financeiro que não seja participante do Open Finance, ou que não ofereça determinado produto, não deve receber todos os requisitos como se fossem diretamente aplicáveis. Por outro lado, quando a instituição participa do ecossistema e oferece contas, cartões, crédito, câmbio, investimentos, credenciamento, iniciação de pagamento ou Pix, os blocos correspondentes do manual tornam-se pontos de atenção para tecnologia, dados, produtos, operações, privacidade, pagamentos e controles.

Principais comandos operacionais

O primeiro comando estruturante é implementar a versão 6.0 do manual como referência obrigatória. Esse requisito não é uma obrigação genérica de “cumprir a norma”; ele exige governança concreta: inventário de APIs e domínios de dados impactados, plano de adequação, registro de mudanças, testes e evidências de implantação. A versão 6.0 traz alterações relevantes, como campos de portabilidade salarial, identificação de transação conforme visualizada pelo cliente, tipo de pagador ou recebedor, data de atualização de saldo, justificativa de limite zerado, seguro contratado em operações de crédito, investimentos, câmbio, pagamentos sucessivos e pagamentos sem redirecionamento.

O segundo comando central é a obrigatoriedade de implementação dos campos listados. O manual deixa claro que os dados são de implementação obrigatória e que a omissão de dados considerados opcionais nas especificações técnicas só é admitida quando houver impossibilidade por inexistência do dado. Isso exige uma governança robusta de qualidade de dados: dicionário interno, mapeamento campo-fonte, regras de transformação, trilhas de exceção e validações de completude.

O terceiro eixo é consentimento. O manual ressalta que dados cadastrais e transacionais de clientes, bem como dados adicionais, dependem de consentimento prévio para finalidades e prazos determinados. Esse ponto conecta Open Finance, privacidade, segurança e arquitetura de dados. A instituição precisa validar consentimento antes de retornar dados, controlar revogação, prazo e escopo, e impedir que a API compartilhe dados fora do consentimento autorizado.

Blocos de dados e serviços

Nos canais de atendimento, o manual cobre dependências próprias, correspondentes no País, canais eletrônicos, canais telefônicos e outros canais. Os requisitos foram separados entre canais presenciais ou correspondentes, canais eletrônicos ou telefônicos e padronização de tipos de dependências e serviços. O endpoint de terminais de autoatendimento de terceiros compartilhados foi tratado apenas como ponto de escopo/exceção, porque o próprio manual afirma que sua implementação é facultativa.

Nos produtos e serviços disponíveis à contratação, o manual cobre contas de depósito, poupança e pagamento pré-pagas, contas pós-pagas, operações de crédito, operações de câmbio, credenciamento em arranjo de pagamento, investimentos e uma remissão ao Open Insurance para seguros, previdência complementar aberta e capitalização. Esses blocos foram transformados em requisitos por domínio, porque cada um envolve fontes, áreas e controles diferentes: produtos de conta, cartões, crédito, câmbio, credenciamento, investimentos e seguros.

No cadastro de clientes, há requisitos separados para pessoa natural e pessoa jurídica. Pessoa natural inclui dados de identificação, documentos, endereço, qualificação, renda, patrimônio, ocupação, relacionamento, produtos vigentes, representantes e campos de portabilidade salarial e conta salário. Pessoa jurídica inclui identificação, constituição, endereço, sócios ou administradores, participação societária, ramo de atuação, faturamento, patrimônio, produtos vigentes e representantes. Esses requisitos têm criticidade alta porque envolvem dados pessoais, relacionamento financeiro, representação e consentimento.

Nos dados transacionais, o pacote separa contas, literal da transação, contas pós-pagas/cartões, crédito, investimentos e câmbio. A regra da literal da transação foi destacada como requisito próprio porque o manual exige que a identificação da transação reflita a visualização do cliente nos canais eletrônicos, com precisão temporal mínima. Esse detalhe tende a exigir conciliação entre extrato, core transacional, aplicativo, navegador e payload da API.

Iniciação de pagamento e Pix

O manual dedica bloco específico ao serviço de iniciação de transação de pagamento. Para pagamentos únicos, os dados mínimos incluem cliente pagador, conta a debitar, recebedor, forma de pagamento, valor, moeda e data do pagamento. Para pagamentos sucessivos, o manual abrange agendamentos recorrentes, transferências inteligentes e Pix Automático, incluindo dados mínimos e parâmetros como periodicidade, prazo, número de recorrências, valor variável e limite. Para pagamento sem redirecionamento, o manual define etapa de vinculação de conta e etapa de transação, com dados mínimos de pagador, instituição iniciadora, conta, forma de pagamento, limites e prazo de consentimento.

A modalidade Pix foi tratada em requisito próprio porque o manual remete aos regulamentos, documentos, manuais técnicos e instruções do arranjo Pix, além de informações técnicas do Portal Open Finance. Na prática, isso exige matriz técnica de Pix no Open Finance, testes de jornada, controles de limites e rastreabilidade entre especificações e APIs publicadas.

Evidências, controles e áreas envolvidas

As principais evidências esperadas são matriz de impacto da versão 6.0, dicionário interno de campos, matriz campo-fonte, registros de exceção por inexistência de dado, logs de consentimento, logs de compartilhamento, relatórios de testes de contrato, evidências de deploy, relatórios de validação de APIs e conciliações com bases internas. Para dados transacionais, evidências de conciliação entre payloads e sistemas de origem são especialmente importantes. Para literal de transação, a evidência mais forte é a comparação entre o extrato ou visualização do cliente e a resposta da API.

As áreas internas mais envolvidas são Open Finance, tecnologia, dados, produtos e canais, pagamentos, cadastro, crédito, câmbio, investimentos, operações, privacidade e compliance. Jurídico-regulatório aparece de forma mais pontual, sobretudo para interpretação de referência normativa, Open Insurance, consentimento e governança de escopo. Auditoria interna não foi incluída como público padrão porque o documento não a torna destinatária direta; ela pode usar as evidências em trabalhos de asseguração, mas não é necessariamente executora.

Pontos de atenção

O primeiro ponto de atenção é a granularidade. O manual contém muitas tabelas técnicas e campos. O pacote não cria um requisito por campo, porque isso produziria ruído operacional e dificultaria governança. A curadoria consolida campos por domínio operacional, preservando pontos de documento e mapa de cobertura para rastrear os blocos principais. Campos que merecem controle próprio, como consentimento, obrigatoriedade de campos, literal da transação, pagamento sem redirecionamento e Pix, foram destacados em requisitos específicos.

O segundo ponto de atenção é o uso de referências complementares. O manual depende do Portal Open Finance e da Área do Desenvolvedor para especificações de APIs, dicionário de dados, agrupamentos e requisitos técnicos. A execução dos requisitos geralmente exige consulta a essas referências, mas o pacote não incorporou documentos posteriores para atualizar o status da norma-fonte.

O terceiro ponto de atenção é a vigência e revogação. O art. 3º determina entrada em vigor na data de publicação. O art. 2º revoga expressamente a Instrução Normativa BCB nº 371/2023. Este pacote registra esse efeito sem duplicar requisitos da norma revogada. Eventual revogação posterior da IN BCB nº 587/2025 deve ser processada em pacote próprio da norma posterior ou em extração consolidada expressamente solicitada.

Decisões de cobertura

Dispositivos conceituais, referências e sumário de alterações foram mantidos como documentoPontos e usados para orientar requisitos, mas nem todos viraram obrigações autônomas. O endpoint de terminais de autoatendimento compartilhados foi tratado como escopo facultativo, não como obrigação. As referências normativas foram catalogadas em 04-textos-citados-alterados.json. O requisito de Open Insurance foi mantido como procedimento de roteamento, pois o manual não detalha campos de seguros, previdência aberta e capitalização.

O resultado é um pacote de aceleração regulatória focado em implementação, qualidade de dados, consentimento, APIs, controles e evidências, mantendo fidelidade ao documento-fonte e evitando consolidação indevida com normas posteriores.