[Dúvida] no [LGPD] - Como fica o Pix com a LGPD?

[feinstein]

Segundo a LGPD não podemos armazenar os dados dos clientes sem o consentimento deles.

Pela API Pix, ao receber os dados de um Pix, recebemos o nome completo e o CPF de um cliente.

A transação Pix com a loja já seria considerada como um "aceite", onde o usuário entende que está entregando esses dados pessoais a serem armazenados em algum sistema de rastreamento de transações financeiras da loja?

Me refiro mais a lojas físicas, restaurantes e etc. Onde não há um fluxo de cadastro para se pagar o produto.

[ninrod]

@feinstein , já era uma questão mapeada, estamos ajustando para a próxima release.

[feinstein]

Você pode me dar um preview do que vai ser? Apenas para eu poder modelar meu banco de dados de acordo.

[ninrod]

o pix.pagador seria removido.

[rubenskuhl]

o pix.pagador seria removido.

Sempre ou só no caso de pagamentos não ligados a cobranças ?

[rturk]

@ninrod em uma primeira análise discordo com remoção do Pix.Pagador. Me parece que isto tornaria o Pix inferior ao padrão que já existe com TED, DOC.

Importante considerar que a LGPD tem dispositivos bem claros sobre para transações financeiras e para pagamentos. Nestas é permitido conhecer os dados da outra parte, até porque estes dados são importantes para atender outras obrigações como exemplo obrigações fiscais.

Em suma recomendo que temas envolvendo LGPD devem ter um embasamento jurídico, considerando que o padrão Pix não deveria ser inferior ao que já existe com por exemplo TED, DOC.

[rturk]

@feinstein

Segundo a LGPD não podemos armazenar os dados dos clientes sem o consentimento deles.

Correto porém incompleto, você é obrigado a armazenar os dados de clientes ao emitir Nfes e pagamentos, inclusive empresas são obrigadas a armazenar estes dados. Por exemplo para atender SPED fiscal. Neste contexto à luz da LGPD estes dados possivelmente são esperados.

Recomendo que este tema seja analisado com o devido embasamento jurídico.

[feinstein]

@rturk excelente. Realmente eu desconheço a LGPD em profundidade. Se realmente possui embasamento jurídico então não vejo porque remover. No máximo poderia se manter com uma máscaras ***.123.456-**, assim como no manual do DICT, mas sendo previsto na LGPD então não vejo razão para a remoção e deve ser transmitido em sua integralidade, sem máscara.

[ninrod]

Ok Pessoal. Vamos levar em consideração as informações colocadas aqui.

[ninrod]

Sempre ou só no caso de pagamentos não ligados a cobranças ?

Sempre.

Qual seria o problema de negócio? @rubenskuhl

[rubenskuhl]

Sempre ou só no caso de pagamentos não ligados a cobranças ?

Sempre.

Qual seria o problema de negócio? @rubenskuhl

Impedir reconhecimento do pagador para transferências iniciadas pelo pagador com valor escolhido por ele, por exemplo em recarga de sistemas pré-pagos. Há sistemas que hoje sem que o pagador precise acessar qualquer site ou aplicativo, ele faz uma transferência e isso já lhe dá créditos (de valor não pré-determinado, à escolha do pagador) num determinado sistema associado a essa conta destino. Como já comentado, a TED tem hoje esse recurso, e ele é usado por exemplo nas corretoras para só permitir depósitos a partir de contas do titular da carteira de investimento.

Fora o fato de que a LGPD não impede o envio da informação, o que mais preocupa é remover a possibilidade de envio da informação. Há pessoas que prefeririam não enviar, há aquelas que não veem problema desde que isso tenha uma finalidade.

[ninrod]

Impedir reconhecimento do pagador para transferências iniciadas pelo pagador com valor escolhido por ele, por exemplo em recarga de sistemas pré-pagos. Há sistemas que hoje sem que o pagador precise acessar qualquer site ou aplicativo, ele faz uma transferência e isso já lhe dá créditos (de valor não pré-determinado, à escolha do pagador) num determinado sistema associado a essa conta destino. Como já comentado, a TED tem hoje esse recurso, e ele é usado por exemplo nas corretoras para só permitir depósitos a partir de contas do titular da carteira de investimento.

Você não consegue emitir uma cobrança atrelada a um txid e associar o pagamento eventual à conta pré-paga específica?

[rturk]

Você não consegue emitir uma cobrança atrelada a um txid e associar o pagamento eventual à conta pré-paga específica?

@ninrod Não recomendo, pode ser uma porta para lavagem de dinheiro exemplo:

Gero um QRCode com uma transação que eu espero que será cobrado da pessoa A, mas quem paga é B.
Eu como recebedor vou assumir que quem pagou foi A quando na verdade foi B.

Lembrando que empresas são obrigadas (através de outros dispositivos legais) a saber as origem dos recursos e poder rastrear estes recursos. Isto vale em várias regulamentações, como na esfera fiscal ou até mesmo KYC.

Vou recomendar adicionar outro stakeholder nesta discussão, além do jurídico, já citado acima. Acredito ser importante time de prevenção à fraudes também ser consultado. Menos dados, tradicionalmente implica em mais ambiguidade e maior margem para erros ou fraudes.

Conforme já mencionei antes, parece prematuro reduzir dados de transações, quando estes são fundamentais para outras esferas fiscais, contábeis, segurança do sistema financeiro, prevenção à fraude, etc