Publica atualização do Catálogo de Serviços do SFN e detalha cronograma para implantação do evento SRC0001.
O Comunicado BCB nº 43.612 é um ato técnico sobre o Catálogo de Serviços do SFN e o evento SRC0001.
📌 Inclui o evento de consulta de permissão de produto.
⚙️ Organiza preparação do domínio MES02 em homologação e produção.
🧾 Exige rastreabilidade de versões, testes, fontes oficiais e alternativa STA/AMES quando aplicável.
O Comunicado BCB nº 43.612, de 5 de agosto de 2025, é um ato operacional do Banco Central voltado à comunicação eletrônica de dados no Sistema Financeiro Nacional. Ele não cria, por si só, todo o regime material do BC PROTEGE+ nem consolida as normas que disciplinam a obrigação de consulta antes de determinadas contratações. O núcleo do documento é técnico: comunicar atualização na versão 5.10 do Catálogo de Serviços do SFN, alterações no Dicionário de Domínios e na Relação de Códigos de Erro, além de organizar a preparação para o novo domínio de sistema MES02 e para o evento SRC0001.
A extração foi tratada como retrato-fonte do comunicado. Isso significa que o pacote preserva somente os comandos que nascem do próprio ato: atualização de documentos técnicos, inclusão do evento “SRC0001 – IF consulta permissão de produto”, disponibilização do domínio MES02, marcos de acesso ao MQConfig em homologação e produção, necessidade de acompanhar o cronograma de implantação efetiva do evento, alternativa por arquivos AMES no STA para instituições sem conexão à RSFN e uso de documentos técnicos/canal de dúvidas do Banco Central.
O documento é dirigido principalmente a instituições que participam da comunicação eletrônica de dados com o Banco Central e que possam precisar trafegar o evento SRC0001. Na segmentação do pacote, o escopo foi representado por instituições financeiras e instituições de pagamento, pois o evento trata de consulta de permissão de produto no contexto do Sistema Financeiro Nacional e do BC PROTEGE+. A aplicabilidade real, porém, depende do enquadramento operacional da instituição: participação na RSFN, necessidade de usar o domínio MES02, existência de processos afetados pelo SRC0001 ou, no caso alternativo, ausência de conexão à RSFN e uso do Sistema de Transferência de Arquivos.
A segmentação não usa “todas as empresas” porque o comunicado não é transversal a qualquer pessoa jurídica. Também não foi usada a tag ampla de setor financeiro isoladamente, porque o texto está associado a instituições que usam infraestrutura técnica do SFN e a eventos de mensageria. O pacote preserva essa condição em cada requisito por meio da explicação de aplicabilidade.
O primeiro bloco operacional é a atualização do Catálogo de Serviços do SFN, do Dicionário de Domínios e da Relação de Códigos de Erro. Esse ponto foi convertido em requisito porque a atualização técnica exige ação verificável: revisar tabelas internas, validar domínios, ajustar tratamento de códigos de erro, manter registro de versão adotada e comprovar testes. Em instituições com arquitetura de mensageria regulatória mais complexa, esse requisito tende a envolver tecnologia, operações e controles.
O segundo bloco é a inclusão do evento SRC0001, descrito como “IF consulta permissão de produto”. Esse é o requisito mais sensível do pacote, porque conecta a atualização técnica à jornada de consulta de permissão de produto. O comunicado não detalha todos os campos da mensagem nem o cronograma definitivo de uso efetivo, mas a inclusão do evento no catálogo já justifica preparação de sistemas, mapeamento de jornadas afetadas, integração com processos de contratação ou abertura aplicáveis e teste do tratamento de retorno.
O terceiro bloco é a criação e disponibilização do domínio MES02. O pacote separa a preparação em homologação e produção porque os marcos, evidências e riscos são diferentes. A partir de 1º de setembro de 2025, o comunicado indicou acesso ao MQConfig em homologação para configuração do MQ e testes de conectividade. A partir de 15 de setembro de 2025, indicou acesso ao MQConfig em produção para configuração produtiva e testes de conectividade. Essas datas foram tratadas como marcos iniciais de disponibilidade, não como prazos finais inventados.
O quarto bloco é a governança do cronograma de implantação efetiva do SRC0001. O comunicado informa que esse cronograma seria divulgado pelo Departamento de Atendimento ao Cidadão do Banco Central. Por isso, o pacote criou requisito de monitoramento, em vez de inventar data de início obrigatório do uso do evento. Esse ponto é importante para produto: a instituição precisa acompanhar a fonte oficial, atualizar seu plano interno e evitar tanto atraso de prontidão quanto ativação operacional prematura sem base em cronograma oficial.
O quinto bloco é a alternativa para instituições sem conexão à RSFN. O comunicado indica que essas instituições poderiam usar arquivos AMES no Sistema de Transferência de Arquivos para envio e recebimento do evento. Esse requisito é condicional e não deve ser roteado como obrigação igual para todas as instituições conectadas à RSFN. A operacionalização por arquivo exige evidências próprias: protocolos, arquivos enviados, retornos recebidos, conciliação e trilhas de processamento.
O impacto principal está na coordenação entre monitoramento regulatório e implementação técnica. A área de tecnologia tende a ser dona da configuração do MQ, do domínio MES02, dos testes de conectividade, da parametrização de mensagens e da atualização de domínios e códigos de erro. Operações e cadastro tendem a participar do desenho das jornadas que dependem da consulta de permissão de produto. Produtos e canais podem ser envolvidos quando a consulta interferir em fluxos de contratação, abertura ou inclusão de titular/representante. Compliance aparece como público material no monitoramento regulatório, na rastreabilidade de fontes oficiais e na coordenação de evidências, mas não como executor de todas as mudanças técnicas.
A implementação deve ser tratada como mudança controlada. Para os requisitos de homologação e produção, evidências fortes incluem tickets de mudança, registros do MQConfig, logs de conectividade, relatórios de testes, aceite técnico, aceite operacional e plano de contingência. Para o evento SRC0001, a evidência mais relevante é a rastreabilidade da integração: especificação funcional, regra de negócio, tratamento da resposta, logs de consulta, amostras de processamento e comprovação de que a jornada aplicável aciona a consulta quando necessário.
Os controles sugeridos concentram-se em cinco eixos. O primeiro é controle de versão: manter evidência de qual versão do Catálogo de Serviços, quais domínios e quais códigos de erro foram internalizados. O segundo é teste técnico: homologação do domínio MES02, teste de conectividade e validação de retorno. O terceiro é gestão de mudança produtiva: aprovação, janela, plano de rollback e aceite antes de operar em produção. O quarto é governança de cronograma: acompanhamento de comunicações oficiais do Banco Central e atualização do plano interno. O quinto é rastreabilidade de canais e documentos: repositório de fontes oficiais, dúvidas encaminhadas e respostas recebidas.
Para instituições sem RSFN, o controle por STA/AMES tem natureza diferente. Ele deve cobrir geração, transmissão, recebimento, leitura, tratamento de erros e conciliação de arquivos. A evidência não é apenas técnica; também deve demonstrar que o resultado do arquivo foi incorporado à decisão operacional vinculada ao evento SRC0001.
O comunicado é sintético e remete a documentos técnicos. Por isso, este pacote não detalha todos os campos da mensagem SRC0001, nem todos os domínios e códigos de erro alterados. Esses elementos devem ser obtidos no Catálogo de Serviços, no Dicionário de Domínios, na Relação de Códigos de Erro e nos documentos técnicos oficiais do Banco Central. Para evitar extrapolação, o pacote criou referências operacionais, mas não transformou material posterior em consolidação do documento-fonte.
Outro ponto importante é a diferença entre disponibilidade técnica e início de uso efetivo. O comunicado informa marcos de acesso ao MQConfig para homologação e produção, mas também indica que o cronograma de implantação do evento SRC0001 seria divulgado pelo Deati. Assim, a instituição deve separar evidências de prontidão técnica das evidências de obrigatoriedade ou início operacional efetivo.
Também há limitação de fonte: a página oficial do BCB foi localizada e confirmada por número, espécie e data, mas depende de JavaScript para exibição completa. A extração textual foi apoiada em trechos indexados da própria fonte oficial e em referências oficiais associadas. Por esse motivo, o manifest foi marcado como “revisar”. O pacote é importável como acelerador, mas recomenda conferência humana do texto integral, especialmente se o workspace exigir granularidade de campo técnico ou validação de versões arquivadas do catálogo.
O mapa de cobertura converteu em requisitos apenas os pontos com ação operacional verificável. A ementa foi preservada como ponto de documento e vinculada ao requisito de atualização técnica. A inclusão do SRC0001 virou requisito próprio porque gera preparação de sistemas e integração de processo. A disponibilidade do MES02 foi absorvida em requisitos específicos de homologação e produção. O cronograma pendente virou governança de monitoramento, sem criação de prazo artificial. A alternativa STA/AMES virou requisito condicional. A indicação de documentos técnicos e canal de dúvidas virou requisito de suporte e rastreabilidade, de criticidade baixa.
Não foram criados requisitos genéricos como “cumprir o comunicado” ou “observar o Catálogo de Serviços”. Também não foram criadas obrigações materiais amplas de BC PROTEGE+ que nascem de normas próprias, como resoluções ou instruções normativas posteriores. Quando essas normas forem processadas em pacotes próprios, poderão criar requisitos autônomos sobre consulta obrigatória, contas, restrições, resposta ao cliente e governança antifraude. Neste pacote, o foco permanece no comunicado técnico de 5 de agosto de 2025.
Este artefato ainda não tem tags.
