[Segurança] Payload apresenta CPF sem máscara

[joelemanoel]

Caros,

Recebi um EMV de QR Code Dinâmico e estive avaliando que o Requisitos Mínimos para a Experiência do Usuário informa que os PSPs devem mostrar o CPF/CNPJ mascarado como: ***.777.888-**

Porém este dado é transitado sem máscara no Payload, sendo assim, quando um EMV de QR Code Dinâmico vaza, é possível ter acesso ao CPF do pagador, neste caso não seria interessante que no Payload a informação esteja disponível já mascarada?

Saindo de:

Para:

[rubenskuhl]

O principal intuito do campo (opcional) devedor é o devedor entender se a cobrança é para ele, então não apenas a informação não deveria ser mascarada, mas também não mascarada na UX do app, caso ela esteja presente.

Mas sim, o tratamento nos dois ambientes deveria ser homogêneo.

[rturk]

CPF tem que ser mostrado sem máscara, é de extrema importância reverter esta prática de mascarar dados. Se eu recebi fundos de outra parte eu tenho que saber a origem destes recursos.

Mascarar o CPF é uma prática ruim desacredita o sistema e acaba por colocar Pix em inferioridade quando comparado com sistemas legados como TED, DOC inclusive CHEQUES! onde a parte recebedora consegue rastrear a origem dos fundos.

Lembrando que é obrigação de empresas perante legislação fiscal saber a origem dos recursos (SPED Fiscal e SPED Contábil)

Manter este requisito de CPF mascarado ainda é uma falha que permite lavagem de dinheiro já que uma empresa imagina que cobra um Pix cobrança para pessoa A, e na realidade quem pagou foi a pessoa B. Sem estes dados é impossível conciliar fundos e novamente, inferior ao que o sistema bancário nacional já garante com Outros meios de pagamento.

[joelemanoel]

O principal intuito do campo (opcional) devedor é o devedor entender se a cobrança é para ele, então não apenas a informação não deveria ser mascarada, mas também não mascarada na UX do app, caso ela esteja presente.

Mas sim, o tratamento nos dois ambientes deveria ser homogêneo.

O meu intuito é: Se o BACEN opta em seguir com a informação mascarada, isso deve ser constante em todas as partes, por isso não entrei no mérito de se deve ou não ser mascarada em todos os locais.

[rubenskuhl]

O principal intuito do campo (opcional) devedor é o devedor entender se a cobrança é para ele, então não apenas a informação não deveria ser mascarada, mas também não mascarada na UX do app, caso ela esteja presente. Mas sim, o tratamento nos dois ambientes deveria ser homogêneo.

O meu intuito é: Se o BACEN opta em seguir com a informação mascarada, isso deve ser constante em todas as partes, por isso não entrei no mérito de se deve ou não ser mascarada em todos os locais.

Pelo menos num mesmo caso de uso. Cobrança e transferência podem ser potencialmente diferentes.

[ninrod]

Porém este dado é transitado sem máscara no Payload, sendo assim, quando um EMV de QR Code Dinâmico vaza, é possível ter acesso ao CPF do pagador, neste caso não seria interessante que no Payload a informação esteja disponível já mascarada?

@joelemanoel ,

o campo opcional devedor.cpf não é igual ao cpf retornado pelo DICT, esse sim, mostrado mascarado. Um é o cpf do recebedor e o outro é o cpf do devedor. Contextos diferentes. Ninguém, de maneira geral, deveria acessar o QR dinâmico endereçado ao devedor, a não ser, por exemplo, uma alguém próximo ao devedor que honrará o pagamento em seu nome.

Ademais, apresentar o CPF do recebedor com máscara sempre foi um princípio seguido pelo PIX na apresentação de informações pessoais via DICT (inclusive por questões de LGPD - informações pessoais).

[sibelius]

Todos os meios de pagamentos que utilizamos sempre nos dizem quem foi o pagador, nome cpf/cnpj pelo menos

[rturk]

@ninrod gostaria de novamente discordar sobre a interpretação da LGPD e seus impactos sobre o Pix.

A LGPD versa sobre correto uso e salvaguarda dos dados. Isto quer dizer que: se uma empresa recebe os dados tem que ser capaz cuidar destes dados de forma segura.

É incorreto traduzir que a LGPD impede o Pix de informar quem pagou a transação.

O desenho atual é uma interpretação bem superficial da LPGD. Isto tanto é verdade que atualmente quando a minha empresa recebe pagamento via TED, DOC e até mesmo cheque! É possível saber claramente a origem dos recursos e isto não viola de forma alguma a LGDP. Claro que ao receber este dado eu sou obrigado ao uso correto e devida salvaguarda dos mesmos.

Novamente quero enfatizar que que esta forma mascarada cria uma situação onde eu na condição de empresa recebedor não tenho certeza da origem dos recursos recebidos. Isto permite por exemplo lavagem de dinheiro. Da forma como o Pix esta estruturada as empresas não tem como garantir a origem dos recursos.

Empresas são obrigadas devido a outros dispositivos como SPED fiscal e SPED contábil ou até mesmo contabilidade básica à poder rastrear e declarar a origem dos recursos recebidos, seja um CPF ou CNPJ.

Ao se mascararem os dados falou considerar (PLD prevenção lavagem dinheiro), SPED Fiscal, SPED contábil entre outras obrigações que empresas e até mesmo pessoas são obrigadas a atender.

Sei que o tema é complexo, e peço que o BACEN reconsidere a recomendação de mascarar CPF para APIs incluindo todos as obrigações fiscais, contábeis, regulatórias, e boas práticas de contabilidade.

[ninrod]

@rturk, boa tarde.

Sei que o tema é complexo, e peço que o BACEN reconsidere a recomendação de mascarar CPF para APIs incluindo todos as obrigações fiscais, contábeis, regulatórias, e boas práticas de contabilidade.

Desconheço onde estaria recomendado pelo BCB que as APIs devem mascarar CPFs.