[SEGURANÇA] Mitigação contra transações de baixo valor

[rubenskuhl]

Uma possível vulnerabilidade no Pix é que enquanto o pagador pessoa física não paga nada, o recebedor pessoa jurídica paga. Se o recebimento custar 50 centavos para a PJ, 1 pessoa pode gastar R$ 1 mil para enviar 100 mil Pix de um centavo cada, e causar um prejuízo de R$49 mil.

Assim, gostaria de saber se as seguintes mitigações seriam permissíveis pelo BACEN:

• Se um EC pode instruir seu PSP a não aceitar Pix que não seja de um QR-Code dinâmico que ele tenha emitido
• Se um EC pode instruir seu PSP a aceitar Pix apenas acima de determinado valor
• Se um PSP pode limitar o valor mínimo de Pix recebido ao da tarifa independente de solicitação do EC
• Se um PSP pode rejeitar um Pix que venha em valor diferente dos permitidos na geração do QR-Code dinâmico
• Se em qualquer dos métodos acima, se o PSP ao recusar o recebimento não pagará a tarifa de recebimentos cobrada pelo BACEN

[ninrod]

@rubenskuhl , boa noite.

É uma situação interessante. Nesse cenário, gostaria de pontuar alguns elementos:

• esse cenário que você colocou tem que acontecer em um fluxo fora do QR Code dinâmico. Porque dentro do cenário de iniciação de pagamentos, por exemplo, via QR Dinâmico, o problema descrito não existe. Teria que acontecer via transferência manual ou via QR Estático sem o valor opcional.

• Seria um comportamento bastante suspeito o envio de 100.000 pix de 1 centavo cada partindo de uma PF só. Imagino que seria bloqueado rapidamente, tanto na origem quanto no destino.

• Se não estamos falando de QR Dinâmico, que seria a forma de iniciação mais cara, temos que considerar que 50 centavos para receber um pix via transferência manual, sem iniciação, foge muito do razoável para um arranjo que propõe um custo base de 1 centavo a cada 10 transações (500x mais caro que o custo base).

• Tenho dúvidas a respeito da aplicabilidade de uma cobrança de 50 centavos na ponta recebedora de um pix realizado via transf. manual. Não me recordo agora da regra de tarifas do PIX, vou buscar essa informação.

• Acredito que os controles anti-fraude do PSP recebedor seriam, se todos esses elementos colocados acima falharem, uma proteção adicional ao usuário recebedor. Porque entendo que o cenário relatado trata-se de uma fraude com o intuito de lesar o usúario recebedor, e acredito que possa ser enquadrado como crime e possivelmente mais do que um crime.

• Uma investigação seria realizada e, reunidas as transações que em conjunto foram utilizadas para lesar o recebedor, seria razoável imaginar que o PSP recebeor trataria de efetuar uma devolução dos valores cobrados.

[rubenskuhl]

Sobre o recebimento de QR-Code Estático, eu tenho várias propostas em mãos com valores da ordem que citei... tem mais altos inclusive. E o que o BACEN tem dito até o momento diferencia tarifas mandatórias apenas por PF/PJ, não por tipo de transação.

Notar também que isso não precisa ser feito necessariamente por um único pagador; pode-se orquestrar uma multiplicidade de transferências de 1 centavo cada um por uma pessoa. Isso já é feito em ataques DDoS na Internet orquestrados pelo grupo Anonymous, e basta uma pessoa de grande popularidade/influência pedir que seus seguidores façam isso contra alguma empresa, e está lá o prejuízo.

[ninrod]

@rubenskuhl , foram relevantes essas informações, agradeço. Vou colocar para o time suas ponderações e o cenário relatado.

[rubenskuhl]

Uma variação de permitir ao EC configurar um valor mínimo seria uma regra genérica de que o PSP recebedor fosse obrigado a recusar Pix que fosse custar mais do que o valor sendo transacionado. Aí tanto faz se custa 5 ou se custa 89 centavos, vai estar coberto, inclusive com eventuais diferenças de preço entre clientes dentro de um mesmo PSP.

[rubenskuhl]

Um detalhe é que qualquer mitigação se aplicaria ao recebimento não solicitado; se um pagamento de 1 centavo foi feito de propósito, por exemplo para confirmar um dado bancário, o refund desse 1 centavo seria permitido. Mas aí as duas transações foram feitas de forma consciente por seus operadores.

[rturk]

Uma possível solução, ao menos para QRCodes, seria extender o arranjo de pagamentos do BR QR Code Pix para incluir dois novos valores na estrutura do QRCode EMV para valorMinimo e valorMáximo, estes campos seriam opcionais, porém tem que ser honrados pelo client que efetua transação

[ninrod]

@rturk é interessante, mas no PIX sempre buscamos uma segunda tentativa de validação no backend. O client pode eventuamente deixar passar essa validação.

@rubenskuhl , obrigado. Estamos verificando.

[rturk]

@ninrod correto. Estou apenas ampliando o conceito, claro que o backend tem que validar e será sempre a origem verdade, mas o front pode ajudar também e informar, na hora, para o usuário que o valor está incorreto.

[ninrod]

@rturk é bastante interessante essa validação no front, se fosse eventualmente implementada. O ponto que eu coloco é que esse valorMin e o valorMax deveriam ser informados ao backend server, também, via PIX API, e não apenas constarem no QR ou no payload JSON.

[guilhermedecampo]

Muito pertinente essa pergunta, o anti-fraude precisa pegar esse tipo de ataque.

[rubenskuhl]

Esse tipo de problema pode acontecer mesmo fora do uso da API Pix, requerendo apenas que o modelo de cobrança das transações habilite o problema descrito.

[ninrod]

Apenas uma provocação para explorar mais a questão:

Não seria um problema de mercado? Em outras palavras, o PSP não poderia cobrar 50 centavos, mas, para recebimentos abaixo de 50 centavos, cobrar menos?

Não seria esse um problema que deveria ser resolvido mais por via contratual do que por via tecnológica?

[rubenskuhl]

A mudança na tarifa mitiga o impacto sobre o EC mas não sobre o PSP, já que o recebimento é do EC e não do PSP. Mas o principal ponto aqui é a certeza regulatória de que os mecanismos de mitigação podem ser usados, ou quais podem ser usados... por que em podendo ser usados, o mercado tenderá a apreciar os PSPs que melhor resolvam essa questão quer seja por meio de tarifa quer seja por controles.

[dncosta]

@ninrod , toda transação do PIX passa sempre por duas etapas no PSP Recebedor, correto? Primeiro esse PSP recebe uma notificação do SPI, quando deve validar e retornar uma confirmação (ou não) de que aceita aquele pagamento. Esse momento não deveria ser utilizado exatamente pra mitigar esses "ataques"? Em outras palavras, quando o PSP do Recebedor recebe um valor X, uma das validações que ele poderia fazer seria de que o valor é superior a tarifa que será aplicada. Se não for, ele nega pro SPI.

Faz sentido?

[rubenskuhl]

@dncosta faz sentido e é uma das mitigações que propus. Mas talvez não possa ser feito para todos, pois como o Pix é muito mais um sistema de informações do que um sistema financeiro, a informação de um pagamento de um centavo pode ser bem-vinda para alguns estabelecimentos. Por exemplo se o Pix está sendo usado para liberar a cancela de um condomínio usando a informação do CPF do efetivo pagador...

... então um default de recusar transações menores que a tarifa mas com possibilidade do EC dizer (a priori, não no momento da transação) que quer receber assim mesmo pode fazer sentido.

[dncosta]

Concordo @rubenskuhl . Vlw.

[ninrod]

Em outras palavras, quando o PSP do Recebedor recebe um valor X, uma das validações que ele poderia fazer seria de que o valor é superior a tarifa que será aplicada. Se não for, ele nega pro SPI.

Faz sentido, não vejo problemas em o PSP recebedor implementar uma regra assim, mas a questão colocada aqui seria mais no sentido de se realmente esse deveria ser um comportamento padrão regulamentado pelo Bacen, ou se haveria outra solução regulamentada pelo Bacen que ajudaria a mitigar o cenário.

[rubenskuhl]

@ninrod acho que o mais importante é o Banco Central autorizar uma, algumas ou todas as mitigações sugeridas, mesmo que não obrigue a adoção de alguma específica. Há bancos que se mostraram receosos em fazer esse tipo de bloqueio, mesmo quando a pedido do EC.

[ninrod]

@ninrod acho que o mais importante é o Banco Central autorizar uma, algumas ou todas as mitigações sugeridas, mesmo que não obrigue a adoção de alguma específica. Há bancos que se mostraram receosos em fazer esse tipo de bloqueio, mesmo quando a pedido do EC.

@rubenskuhl , perfeito. Levarei as considerações ao time.