Contestação de Pix devolvido passa de 30 para 80 dias

Em 1º de setembro de 2026, muda um prazo do Pix que parece pequeno até você olhar para o produto que precisa suportá-lo. A contestação de uma transação de devolução por fraude passa de 30 para 80 dias. São cinquenta dias a mais.

Para jurídico e compliance, isso é uma alteração de regra. Para produto, significa outra coisa: uma transação que a operação já considerava encerrada pode voltar a exigir contexto, evidência, comunicação e decisão quase três meses depois. É aí que a mudança deixa de ser assunto de norma e começa a mexer em painel, retenção de dados, atendimento e gestão de risco.

O que realmente muda em 1º de setembro

A Instrução Normativa BCB nº 766, de 27 de julho de 2026, divulgou a versão 8.5 do Manual Operacional do DICT, que integra o Regulamento do Pix. Entre as alterações está a ampliação do prazo para contestação de transação de devolução por fraude: de 30 dias para 80 dias. A vigência dessa mudança começa em 1º de setembro de 2026, conforme as alterações das seções 20.1.1, 20.1.9 e 20.2 do Manual Operacional do DICT.

Isso parece simples. Mas existe uma confusão importante para evitar.

A vítima do golpe não ganhou mais 50 dias

Boa parte da confusão vem de misturar dois momentos diferentes do MED. Quem fez um Pix e alega ter sido vítima de fraude já podia iniciar o processo relacionado ao MED para uma transação original ocorrida há até 80 dias. Esse não é o prazo que está mudando. A mudança acontece depois, do outro lado da operação. Imagine:

1. uma pessoa envia um Pix;

2. posteriormente alega fraude;

3. ocorre uma devolução dentro do mecanismo aplicável;

4. quem recebeu o pagamento entende que essa devolução foi indevida e quer contestá-la.

É essa contestação da transação de devolução que antes tinha janela de 30 dias e passa a ter 80.

A diferença é importante porque muda completamente quem está no centro da experiência. Não é a vítima iniciando uma contestação. É o usuário recebedor tentando demonstrar que uma devolução que o atingiu não deveria ter acontecido. Em muitos produtos, esse usuário é um lojista, vendedor, prestador de serviço ou empresa que recebeu um Pix legítimo e depois viu o valor sair.

Cinquenta dias mudam a memória operacional da transação

Com uma janela curta, existe uma chance maior de a operação ainda estar “quente”. O pedido aparece facilmente no atendimento, a conversa ainda está disponível, o comprovante de entrega continua acessível, a equipe lembra do contexto, o sistema mantém logs de alta granularidade.

Com 80 dias, uma contestação pode chegar quando aquela venda já desapareceu da rotina. O pedido foi arquivado, algum dado operacional expirou, o parceiro logístico já não oferece o mesmo detalhe, a pessoa que tratou o caso não lembra dele — talvez nem trabalhe mais na empresa. A interface precisa ajudar alguém a reconstruir uma história que aconteceu meses antes.

Essa é a consequência de produto mais interessante da mudança: o prazo regulatório começa a competir com o prazo de memória do seu próprio sistema.

A primeira pergunta deveria ir para engenharia

Antes de redesenhar qualquer tela, pergunte: se uma contestação relacionada a uma transação antiga chegar dentro da nova janela, que contexto conseguimos recuperar hoje? Não apenas valor, data e identificador Pix, mas tudo que a operação utiliza legitimamente para entender o que aconteceu naquela venda. Dependendo do negócio, isso pode incluir informações como:

• pedido associado;

• histórico de atendimento;

• aceite ou confirmação relevante;

• informações sobre entrega;

• registros operacionais disponíveis;

• eventos do fluxo;

• documentos relacionados ao atendimento da venda.

Isso não significa que todos esses dados devam ser coletados nem armazenados indiscriminadamente por 80 dias. Política de retenção também precisa considerar LGPD, necessidade, segurança, obrigações aplicáveis e o contexto específico da operação. O ponto é outro: a política de descarte não deveria apagar automaticamente informações necessárias para tratar uma disputa que ainda pode surgir. Essa conversa precisa acontecer entre produto, engenharia, risco, jurídico e compliance.

A norma não obriga você a segurar recebível por 80 dias

Outro cuidado importante. Ampliar o prazo de contestação não significa automaticamente que todo lojista precisa ficar 80 dias esperando para receber. A política de liquidação e de retenção de valores depende da operação, das responsabilidades assumidas, do modelo de risco e das regras aplicáveis ao negócio. O que muda é a janela durante a qual uma contestação pode aparecer.

Isso força uma decisão. Quem carrega esse risco depois que o recebível já foi liberado? O lojista? A instituição? Um parceiro? Existe reserva? Existe retenção para determinados perfis? O risco é precificado? A resposta pode variar. O que não funciona bem é deixar a política aparecer pela primeira vez quando chega uma contestação antiga.

Se existe retenção, o lojista precisa entender quanto fica retido, por quanto tempo, por qual motivo, o que libera o valor e o que acontece quando surge uma contestação. Prazo variável sem explicação parece dinheiro preso arbitrariamente.

A contestação precisa existir como estado do produto

Em algumas operações, notificações relacionadas a fraude continuam chegando principalmente para equipes internas: e-mail, fila operacional, sistema administrativo, integração. O lojista percebe a consequência só quando o saldo muda. Esse desenho cria uma assimetria ruim. A empresa sabe que existe uma disputa. Quem perdeu o dinheiro sabe apenas que o dinheiro sumiu.

O produto precisa responder perguntas muito básicas: qual transação está sendo contestada, quando isso aconteceu, qual valor está envolvido, qual é o prazo disponível, existe alguma ação possível, que informações precisam ser apresentadas, qual é o estado atual da análise. Mesmo quando parte do processo precisa acontecer fora do painel, a interface pode transformar uma mudança de saldo numa ocorrência compreensível.

Esse é um bom princípio para produtos financeiros: dinheiro não deveria mudar de estado sem que o usuário consiga encontrar uma explicação para aquele estado.

O desenho do MED para pessoa física dá uma pista interessante

O próprio desenho regulatório do autoatendimento do MED já mostra como prazo e estado podem virar produto. Para os fluxos aplicáveis ao usuário pagador pessoa física, o Banco Central estabelece requisitos para que determinadas ações e informações estejam disponíveis dentro do ambiente Pix. Isso inclui acesso pelo contexto da transação, informação quando o prazo não permite mais prosseguir e acompanhamento do andamento das solicitações.

O ponto não é copiar literalmente esse fluxo para um painel de lojista. As obrigações e os usuários são diferentes. Mas existe um princípio útil: um direito operacional que só existe num documento ou num e-mail é muito mais difícil de exercer do que um direito representado como estado e ação dentro do produto. Com a janela de contestação chegando a 80 dias, essa diferença fica ainda mais evidente.

Evidência deveria nascer junto com a transação

Quando uma contestação aparece meses depois, não é uma boa hora para descobrir que o sistema nunca guardou contexto suficiente sobre a venda. Por isso o problema começa antes da disputa. Pode começar no checkout, no pedido, na confirmação, na integração com o lojista, na logística.

A pergunta para Product Design não é:

que formulário precisamos criar para contestação?

É: o produto está produzindo, ao longo da operação normal, contexto suficiente para reconstruir uma transação legítima depois?

Isso muda a arquitetura. Informação usada apenas como log técnico pode precisar ter outra função. Um identificador de pedido pode precisar estar conectado ao Pix. Um comprovante pode precisar continuar acessível. O histórico pode precisar ser recuperável a partir da própria transação. O produto deixa de pensar apenas no caminho:

receber → liquidar → encerrar.

E passa a considerar:

receber → liquidar → eventualmente investigar muito tempo depois.

O TransactionDepth adiciona outra camada de contexto

A versão 8.5 do Manual Operacional do DICT também introduz o atributo TransactionDepth em notificações de infração relacionadas aos fluxos previstos. Esse campo representa a profundidade da transação no grafo de rastreamento. Em termos de produto, ele ajuda a responder: a que distância daquela cadeia está a transação que estamos analisando?

Só que essa alteração não entra em vigor junto com a ampliação do prazo. Aqui existe uma pegadinha importante. A redação original da Instrução Normativa BCB nº 766 previa 10 de agosto de 2026 para o bloco que inclui as alterações das seções 10.1 e 20.1.5. No dia seguinte à publicação da norma no Diário Oficial, o Banco Central editou a Instrução Normativa BCB nº 767. A redação vigente passou a estabelecer:

• 1º de setembro de 2026 para as alterações das seções 20.1.1, 20.1.9 e 20.2, incluindo a ampliação do prazo de contestação;

• 26 de outubro de 2026 para as alterações das seções 10.1 e 20.1.5, onde entra o TransactionDepth, além da revogação prevista.

Quem consultar apenas a publicação original pode encontrar a data antiga. Para produto e engenharia, a versão consolidada é a referência importante para planejamento.

TransactionDepth não deveria virar apenas um badge de risco

Um campo técnico novo costuma virar uma solução visual rápida:

Profundidade: 3

Isso praticamente não comunica nada para um lojista. Pior seria converter diretamente para:

Transação suspeita.

A profundidade descreve uma posição na cadeia de rastreamento. Sozinha, ela não conta toda a história sobre legitimidade da venda ou responsabilidade do recebedor. Uma interface útil precisará traduzir pelo menos três coisas: onde esta transação aparece na cadeia, o que essa informação significa neste contexto e o que o usuário pode ou precisa fazer agora.

Isso talvez exija visualização. Talvez texto. Talvez nenhuma exposição direta do número bruto ao usuário final. A decisão depende do papel daquele usuário e de quanto essa informação realmente ajuda na ação. O princípio é não transformar dado de infraestrutura em label de interface sem antes decidir qual compreensão ele deveria produzir.

Três decisões de produto que a mudança coloca na mesa

Não existe uma implementação única para toda empresa. Mas a nova janela torna algumas discussões difíceis de adiar.

1. Retenção orientada ao risco e à necessidade operacional

Revise por quanto tempo o contexto necessário para tratar essas ocorrências continua disponível. Não apenas no banco principal. Também em logs, atendimento, parceiros e documentos.

2. Evidência conectada à transação

Se uma venda precisa ser reconstruída no futuro, o caminho até pedido, atendimento e demais evidências aplicáveis não deveria depender de investigação manual em cinco sistemas. A transação pode funcionar como ponto de entrada para esse contexto.

3. Contestação como estado visível

Quando o usuário é afetado, mostre: prazo, valor, transação, estado, próxima ação. O objetivo é evitar que uma disputa de Pix seja descoberta como “saldo faltando”.

O que dá para fazer antes de 1º de setembro

A menos de uma semana da entrada em vigor, provavelmente não faz sentido tentar reinventar todo o painel. Mas existem perguntas que podem ser respondidas imediatamente.

Pergunte qual é a retenção atual dos dados relevantes

Se informações importantes desaparecem antes da janela em que uma contestação ainda pode chegar, existe um problema para investigar agora.

Descubra onde a ocorrência aparece hoje

Ela entra no produto? Vai para operações? Chega por integração? Vira apenas e-mail? Em que momento o lojista fica sabendo? Mapear o fluxo atual já revela boa parte do trabalho.

Escreva a política operacional em linguagem simples

Quem carrega o risco? Existe retenção? O que acontece com o saldo? Quem pode contestar? Qual é o prazo? Qual é o estado enquanto existe análise? Se o próprio time não consegue explicar isso em poucas frases, dificilmente a interface vai conseguir.

A mudança de 30 para 80 dias é pequena só no documento

O prazo é uma linha da norma. No produto, ele atravessa sistemas. A política de retenção precisa conversar com a nova janela. A operação precisa conseguir recuperar contexto antigo. O painel precisa representar uma disputa que pode surgir meses depois da venda. E, a partir de outubro, uma nova informação sobre a posição da transação na cadeia também entra na infraestrutura.

Esse é o tipo de mudança regulatória que parece “backoffice” até atingir saldo, suporte e confiança do cliente. A melhor pergunta para fazer agora é simples: se uma contestação chegar no último dia possível, o nosso produto ainda consegue explicar aquela transação? Se a resposta não estiver clara, o trabalho não começa na tela de contestação. Começa muito antes dela.

Sobre a diferença entre a infraestrutura que processa o pagamento e a experiência em que o usuário paga, vale continuar por Gateway não é checkout.

Fontes

Banco Central do Brasil. Instrução Normativa BCB nº 766, de 27 de julho de 2026. Divulga a versão 8.5 do Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT), que compõe o Regulamento do Pix. Entre as alterações estão a ampliação do prazo para contestação de transação de devolução por fraude e a inclusão do atributo TransactionDepth.

Banco Central do Brasil. Instrução Normativa BCB nº 767, de 30 de julho de 2026. Altera o art. 3º da IN BCB nº 766. A redação vigente estabelece 1º de setembro de 2026 para as alterações das seções 20.1.1, 20.1.9 e 20.2 e 26 de outubro de 2026 para as alterações das seções 10.1 e 20.1.5 e para a revogação prevista no art. 2º.

Banco Central do Brasil. Manual Operacional do DICT, versão 8.5. Referência operacional para as alterações tratadas neste artigo, incluindo a ampliação da janela de contestação de transação de devolução para 80 dias e a introdução da informação de profundidade no grafo de rastreamento.

Banco Central do Brasil. Guia de implementação dos procedimentos de devolução no Pix, com ênfase no Mecanismo Especial de Devolução. Referência para os fluxos e prazos do MED, incluindo a janela já existente de até 80 dias para a transação original e os requisitos de autoatendimento aplicáveis aos fluxos descritos pelo Banco Central.

Este artigo discute implicações de produto e não constitui orientação jurídica ou regulatória.