PixVerifica — Protótipo Independente

PixVerifica é um protótipo independente que demonstra como uma camada de visibilidade técnica mínima poderia existir para o usuário final, utilizando apenas informações que já circulam internamente entre as instituições participantes e o SPI.

Hoje, todo o fluxo operacional do Pix - rota, status, SLA e confirmação - é monitorado pelas instituições ao longo da jornada da transferência. O usuário, porém, permanece completamente isolado desse ciclo. Entre “enviado” e “recebido”, não existe qualquer indicação intermediária, mesmo quando a transação passa por etapas distintas dentro da infraestrutura.

Essa assimetria gera incerteza, suporte desnecessário e aumenta a superfície de golpes baseados em ausência de evidência técnica.

O protótipo abaixo simula, em camada privada, como o usuário poderia visualizar o estado técnico da operação de forma segura, sem acessar dados sensíveis, sem expor valores e sem revelar histórico transacional.

Ele não representa interface final nem arquitetura definitiva - apenas demonstra o conceito central: Transparência técnica mínima reduz ruído, fortalece segurança e aproxima o usuário do processo real que já ocorre dentro da infraestrutura do Pix.

O objetivo é ilustrar o potencial de uma camada adicional de clareza, mantendo o modelo operacional atual e respeitando os limites de privacidade, compliance e segurança que já regem o ecossistema.

Saldo disponível (fictício): R$ 1.000,00

Escolha um valor e realize a transação para iniciar o procedimento

O que a demonstração acima expõe não é “mais um comprovante”. É a base de um comprovante vivo - um comprovante que deixa de ser um print estático e passa a refletir, de forma técnica, o estado real da transferência ao longo de toda a sua vida.

No centro de tudo está um elemento que já existe hoje: o ID da transação - único, imutável e rastreável pelo sistema. É esse ID que acompanha a operação dentro das instituições. É em torno dele que a transparência pode ser construída, sem romper sigilo bancário, sem alterar o fluxo atual do Pix e sem criar dependência de dados sensíveis.

O comprovante vivo nasce exatamente para resolver essa assimetria: O ID deixa de ser apenas um número no rodapé e passa a ser a chave viva da operação, sempre que consultado, ele devolve o estado atual, e não apenas o passado.

É isso que reduz ruído, reduz suporte, reduz golpes baseados em prints manipulados e aumenta previsibilidade para usuários, empresas e operações críticas.

Entre camadas

A primeira camada é a Camada Pública de Visibilidade - pensada para ser mínima, universal e compatível com o sigilo bancário.

Ela responde a três perguntas simples:

Esse ID é válido? Essa transação existe de fato no sistema? Em que estado técnico ela está agora?

Sem expor:

  • - nome,
  • - valor,
  • - CPF/CNPJ,
  • - saldo,
  • - histórico de conta.

Na prática, essa camada pública precisa mostrar apenas: ID válido ou inválido e status técnico atual: pendente, concluído ou devolvido (eventualmente outros estados operacionais, se o ecossistema desejar).

Nada além disso. É a camada que pode ser acessada por:

  • - usuários finais,
  • - pequenos comércios,
  • - plataformas de pagamento,
  • - empresas que só precisam validar “se a operação existe e em que pé está”.

Ela elimina o “vazio” entre o enviei e o recebido, sem abrir nenhuma porta de dado sensível.

A segunda camada é a Camada Privada de Verificação Detalhada - e é exatamente essa que o protótipo demonstra.

Ela existe dentro do próprio banco do recebedor ou do emissor, em ambiente autenticado, onde o usuário já teria acesso a seus próprios dados de qualquer forma.

Ao consultar o ID nessa camada, o que aparece não é só o status, mas o equivalente a um comprovante legítimo e íntegro, associado ao estado atual da transação:

  • - nome de quem enviou / recebeu,
  • - banco de origem e banco de destino,
  • - data e horário,
  • - valor,
  • - identificadores internos relevantes,
  • - e o status técnico (pendente / concluído / devolvido).

Ou seja:

  • - se o ID for real e a operação existir, essa camada devolve o comprovante atualizado, alinhado ao que o sistema de fato reconhece naquele momento;
  • - se o ID não existir, ou não tiver mais vínculo com uma operação válida, fica claro que aquele “comprovante” não é confiável.

Aqui, não há qualquer ampliação de exposição: o usuário só vê, em formato estruturado, o que já teria acesso de outras maneiras dentro do próprio banco. A diferença é que tudo passa a ser organizado a partir do ID, o que cria rastreabilidade técnica e elimina brechas para fraude via edição de comprovante.

Pix Agendado

Se existe um caso em que essas camadas deixam de ser apenas desejáveis e passam a ser indispensáveis, é o Pix Agendado.

Hoje, para o usuário comum, o Pix agendado é:

  • - um print de algo que “deveria acontecer no futuro”;
  • - sem garantia clara de que ainda está ativo;
  • - sem visibilidade se foi cancelado, barrado ou alterado antes da execução.

Ele só descobre o problema depois que precisa do dinheiro - ou depois que o compromisso falhou.

Com o ID como âncora e as duas camadas em operação, o cenário muda por completo:

Na Camada Pública

  • Qualquer parte pode consultar o ID de um Pix agendado e saber se a operação ainda está agendada, se já foi executada, se não existe mais ou foi devolvida/cancelada;
  • tudo isso sem expor valor, nomes ou dados sensíveis - apenas o estado técnico.

Na Camada Privada

Dentro do banco do recebedor ou do emissor, a consulta pelo ID:

  • - confirma com exatidão a programação da operação;
  • - permite que o usuário veja, com data e hora, o que está previsto para acontecer;
  • - registra se houve cancelamento, reagendamento ou qualquer exceção;
  • - pode disparar alertas claros para o cliente quando um Pix agendado for revogado.

Nesse contexto, o Pix agendado deixa de ser “só uma função a mais” e passa a ser uma ferramenta confiável de pagamento futuro.

Comprovantes de Pix agendado deixam de ser promessas frágeis e passam a ser comprovantes vivos de intenção auditáveis, verificáveis e difíceis de usar em golpes.

ID como eixo de transparência funcional

Tudo isso pode ser resumido em um ponto: Se toda transferência Pix já nasce com um ID único e imutável, ela já nasce com tudo o que precisa para ser rastreável e auditável.

O sistema já enxerga a vida inteira da operação. A única peça que falta é organizar isso em camadas de visibilidade:

  • - uma camada pública, mínima, baseada apenas em ID + status;
  • - uma camada privada, interna, que entrega um comprovante atualizado, vinculado ao estado real da transação;
  • - e, em especial, a aplicação disso ao Pix Agendado, onde a previsibilidade técnica é crítica.

Nenhuma dessas peças exige ruptura de arquitetura. Nenhuma exige exposição de dados sensíveis. Nenhuma conflita com sigilo bancário.

O que elas fazem é alinhar o que o sistema já sabe com o que o usuário precisa saber, na dose certa.

Com poucos ajustes de interface e rotas internas, o resultado prático é:

  • - menos ruído entre clientes, bancos e empresas;
  • - menos suporte para dúvidas básicas sobre “caiu ou não caiu?”;
  • - menos espaço para golpes baseados em prints falsos ou informações assimétricas;
  • - mais confiança em operações críticas;
  • - um ambiente onde transparência funcional vira parte da infraestrutura, tão natural quanto emitir um comprovante.

O Pix já trouxe velocidade.

Soluções como o Protege+ reforçam segurança.

O próximo passo natural é a clareza técnica mínima para o usuário final.

Essa é a função do comprovante vivo. Essas são as camadas que o ID permite construir. E este é o tipo de evolução que pode ser implementada de forma gradual, segura e compatível com o que o sistema já é hoje - mas com um ganho de confiança difícil de ignorar.