Divulga a versão 8.2 do Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT), que compõe o Regulamento do Pix.
A IN BCB 722/2026 divulga a versão 8.2 do Manual Operacional do DICT e altera fluxos relevantes do MED.
📌 Centraliza notificações de infração de devolução na Recuperação de Valores.
⚠️ Exige ajuste de endpoints, domínios, eventos e testes da API do DICT.
🧾 Revoga a IN BCB 702/2026 e demanda evidências de implantação da versão 8.2.
A Instrução Normativa BCB 722/2026 divulga a versão 8.2 do Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT), componente do Regulamento do Pix. O ato também revoga a Instrução Normativa BCB 702/2026 e estabelece vigência em 11 de maio de 2026. Em termos de produto e compliance, o documento deve ser lido como norma alteradora e divulgadora de manual operacional: ele não recria todo o regime do DICT, mas substitui a versão operacional anterior do manual e introduz mudanças relevantes em fluxos do MED, principalmente notificação de infração, solicitação de devolução e Recuperação de Valores.
Esta curadoria foi construída em modo de retrato-fonte. Por isso, não transforma todo o Manual Operacional do DICT em requisitos novos. O pacote concentra os requisitos que nascem materialmente da versão 8.2 divulgada pela Instrução Normativa BCB 722/2026, registra a revogação da IN BCB 702/2026 em alterações de requisitos e preserva o Manual Operacional do DICT v8.2 como referência operacional central.
Os comandos operacionais extraídos interessam a instituições que sejam participantes do Pix, PSPs e áreas internas que executem ou suportem DICT, MED, Recuperação de Valores, solicitação de devolução e tratamento de fraude. A aplicabilidade prática não decorre de toda atividade financeira em sentido amplo. Ela depende de participação no Pix e de operação dos fluxos técnicos e operacionais regulados pelo Manual do DICT.
Como o dicionário de segmentação disponível não possui tag específica para participante do Pix, PSP participante direto, PSP participante indireto ou usuário operacional do DICT, a segmentação usou uma aproximação por instituições financeiras e instituições de pagamento. Essa é uma limitação importante: empresas financeiras que não participem do Pix ou que não operem DICT/MED não deveriam receber esses requisitos como diretamente aplicáveis apenas por pertencerem ao setor financeiro.
A mudança mais importante da versão 8.2 é a centralização do tratamento de notificação de infração para solicitação de devolução por fraude dentro da Recuperação de Valores. A abertura de notificação de infração por endpoint antigo deixa de ser o caminho para esse contexto, e o DICT passa a abrir a notificação vinculada a partir da Recuperação de Valores. Isso altera fluxos de atendimento, investigação de fraude, sistemas de integração, filas operacionais e controles de qualidade de dados.
Outro bloco relevante é a remoção do domínio refundCancelled do campo RefundReason nas solicitações de devolução. Essa alteração exige revisão de catálogos técnicos, parametrizações internas, mapeamento de motivos, validações de payload e testes de integração. É um ponto de atenção tecnológico porque valores de domínio desatualizados podem gerar rejeição, erro de roteamento ou classificação indevida do caso.
A versão 8.2 também ajusta a solicitação de devolução por fundada suspeita de fraude para tratá-la como etapa da Recuperação de Valores. A abertura deve observar a transação correta, os prazos aplicáveis e a lógica de unicidade. Para transações originais, o fluxo considera a pacs.008 e o limite de 80 dias; para contestação de transação de devolução, considera a pacs.004 e o limite de 30 dias.
O capítulo de Recuperação de Valores recebeu ajustes operacionais relevantes. O participante recuperador deve instituir o processo imediatamente após identificar suspeita de fraude ou receber reclamação do usuário, acompanhar a análise por notificações de eventos, iniciar a devolução em até 72 horas após a etapa de análise quando aplicável e observar regras de cancelamento, recomposição de recursos e encerramento definitivo.
Para compliance, o principal impacto está na governança de implantação da versão 8.2. A empresa precisa demonstrar que identificou a mudança normativa, avaliou os processos afetados, atualizou sistemas e procedimentos, comunicou áreas internas e manteve evidência de testes. O risco não está apenas na leitura da norma, mas na execução técnica correta do DICT e do MED.
Os requisitos extraídos são especialmente sensíveis porque afetam usuários vítimas de fraude, valores bloqueados ou devolvidos, comunicação entre participantes e rastreabilidade de decisões. Falhas nesses fluxos podem gerar reclamações, perda de prazo, tratamento desigual de usuários, divergência de estados entre sistema interno e DICT, uso de endpoint descontinuado ou recomposição financeira inadequada.
Compliance deve atuar como coordenador de evidências e validação de aderência, sem substituir os donos operacionais. A operação Pix e os times de prevenção a fraude devem cuidar da triagem, classificação, abertura e acompanhamento dos casos. Tecnologia deve garantir endpoints, domínios, integração, logs, tratamento de eventos e testes de regressão. Atendimento deve capturar corretamente a reclamação do usuário e encaminhar o caso pelo fluxo correto. Riscos e controles podem apoiar testes, amostragem e acompanhamento de achados.
As principais evidências esperadas incluem plano de implantação da versão 8.2, matriz de impacto de integração DICT, procedimento interno de MED atualizado, logs de API, payloads de criação de Recuperação de Valores, retorno de consultas de eventos, dossiês de casos de fraude, cálculo de prazos e comprovantes de devolução ou cancelamento. Para requisitos com prazo, como a devolução em até 72 horas após a etapa de análise, a evidência deve permitir reconstruir data de início, data limite, data de execução e resultado.
Os controles mais úteis são de três tipos. O primeiro grupo é preventivo e sistêmico: bloquear domínio removido, impedir endpoint descontinuado, validar prazo e tipo de transação, exigir campos obrigatórios e controlar unicidade por transação. O segundo grupo é detectivo: monitorar logs, conciliar eventos do DICT com estados internos, revisar rejeições de API e amostrar casos pós-implantação. O terceiro grupo é de governança: aprovar plano de implantação, manter comunicação interna, registrar alçadas de cancelamento e documentar decisões de mérito.
As áreas internas mais impactadas são pagamentos Pix e Open Finance, tecnologia e dados, prevenção a fraude ou cadastro, operações/backoffice, atendimento e ouvidoria, riscos e controles e compliance. Jurídico-regulatório pode participar em interpretações materiais, disputas ou dúvidas sobre enquadramento, mas não foi incluído em todos os requisitos para evitar audiência interna genérica.
O primeiro ponto de atenção é evitar falsa consolidação. A IN BCB 722/2026 revoga a IN BCB 702/2026 e divulga a versão 8.2 do Manual Operacional do DICT, mas este pacote não atualiza automaticamente requisitos de outros documentos fora do retrato-fonte. O efeito de revogação e substituição foi registrado em alterações de requisitos para que a plataforma possa inativar ou revisar itens antigos relacionados à versão 8.1.
O segundo ponto é a dependência técnica. A mudança envolve endpoints, domínios, eventos e estados de processo. Aderência não se prova apenas com política ou procedimento; é necessário ter evidências de implementação em sistemas, logs, testes, parametrizações e integração com o DICT.
O terceiro ponto é a qualidade de dados. Como a notificação de infração vinculada passa a receber campos automaticamente a partir da Recuperação de Valores, qualquer erro no registro inicial pode gerar efeitos em cadeia. A empresa deve conferir dados da transação, motivo, detalhes, prazo, identificação do participante e evidências do caso.
O quarto ponto é a gestão de prazos e estados. A abertura imediata da Recuperação de Valores, os limites de 80 e 30 dias, o prazo de até 72 horas para iniciar devolução após análise e o acompanhamento dos eventos do DICT precisam estar refletidos em filas, alertas e conciliações.
Foram convertidos em requisitos apenas os comandos operacionais materiais da versão 8.2: centralização da notificação na Recuperação de Valores, descontinuação do endpoint antigo para esse contexto, qualidade de dados da abertura, remoção do domínio refundCancelled, tratamento de devolução por fraude como etapa da Recuperação de Valores, abertura correta do processo, acompanhamento de estados, devolução em até 72 horas, contestação de transação de devolução por fraude, cancelamento e recomposição de recursos, monitoramento de eventos e governança de implantação.
Não foram convertidas as versões anteriores do histórico do manual, porque não nascem da IN BCB 722/2026. Também não foram convertidas todas as seções do Manual Operacional do DICT v8.2, pois isso transformaria o pacote em uma consolidação completa do manual, contrariando o modo de retrato-fonte puro. Dispositivos formais, como preâmbulo e disponibilidade do manual no site do Banco Central, foram tratados como identificação, referência ou ponto de apoio, sem requisito empresarial autônomo.
O pacote deve ser usado como acelerador para atualizar clientes que operam Pix, DICT e MED. Antes de promover requisitos para um workspace específico, recomenda-se confirmar se a instituição é participante do Pix, se atua como participante recuperador, se processa MED internamente ou por fornecedor, quais sistemas consomem a API do DICT e como a empresa trata atendimento de fraude. Em instituições com operação terceirizada ou compartilhada, os requisitos podem exigir adaptação para refletir contratos, responsabilidades de fornecedor, trilhas de auditoria e evidências recebidas de terceiros.
Este artefato ainda não tem tags.
