Contribuições Fórum Pix Gestor de Pagamentos

O presente documento está dividido em três partes. A <strong>primeira</strong> é destinada à exposição de uma proposta alternativa à regulamentação da figura de um gestor de pagamento. Vamos expor algumas preocupações com a criação de um novo intermediário no arranjo do Pix e uma proposta alternativa focada em um mecanismo de pagamentos com múltiplos recebedores (<em>split pay</em>). A <strong>segunda</strong> parte é destinada à discussão de um outro tema objeto da 19a Plenária do Fórum Pix: a especificação do Pix automático. Neste ponto, vamos defender uma abordagem que unifica as jornadas de pagamento automático e amplifica o escopo e impacto desse mecanismo. Por fim, a <strong>terceira</strong> parte amarra as propostas das duas primeiras partes e descreve como ambas poderiam ser incorporadas na API Pix para máximo impacto no sistema de pagamentos.
Nossa contribuição adota a posição de que a solução de formalizar a figura do gestor de pagamentos não é o melhor caminho para alcançar os objetivos do Banco Central de fomentar a inovação no mercado de pagamentos sem comprometer princípios importantes, como o combate à lavagem de dinheiro. Defendemos que a necessidade que o mercado está mostrando é resultado de três questões subjacentes e que uma solução efetiva deve atacar essas questões em suas raízes.</p>
<p>A primeira questão subjacente pode ser uma frustração com o funcionamento da API Pix oferecidas pelos bancos para acessar as funcionalidades do Pix. Aqui, nossa proposta é corrigir esse problema específico implementando requisitos mínimos de experiência do usuário para as APIs da mesma maneira que o BCB fez com os aplicativos bancários desde o primeiro dia. Se as APIs funcionassem e dessem acesso a todas as funcionalidades do Pix, os intermediários poderiam gerenciar os pagamentos sem participar do fluxo de dinheiro.</p>
<p>A segunda questão subjacente é que terceirizar os pagamentos também é muito difícil. Até mesmo a atividade de simplesmente registrar ordens de pagamento para aprovação futura pode ser difícil. Novamente, as APIs do Pix poderiam resolver esse problema permitindo a geração de credenciais para os operadores, mesmo que a aprovação final exija um nível mais alto de credencial.</p>
<p>Por fim, a terceira questão é que participar do fluxo de dinheiro pode reduzir muito o risco de inadimplência, já que o intermediário pode deduzir sua taxa do que é finalmente encaminhado para o beneficiário final. Para resolver esse caso de uso específico, propusemos a implementação de um fluxo para acomodar o <em>split pay</em>. Ou seja, pagamentos com vários destinatários. O recurso de split pay estaria disponível para todos os beneficiários em seus aplicativos bancários ou APIs, para que os gerentes de conta pudessem configurar os QR Codes já com o split pay configurado.</p>
<p>Também fizemos uma proposta adicional em relação à segunda questão mencionada acima. Sugerimos que o BCB considere o Pix automático como apenas uma nova forma de enviar descrições de pagamento para o banco do pagador para confirmação do pagador e início do fluxo de dinheiro. Isso significa que a mensagem que os bancos pagadores recebem dos bancos recebedores em um débito automático deve ser exatamente o conteúdo de um QR Code que um pagador pode digitalizar. Também sugerimos que tanto o Pix automático quanto os QR Codes possam ser únicos, recorrentes ou únicos e recorrentes. Se o BCB aceitar essa sugestão, poderíamos ter pagamentos por push em larga escala no Brasil.