[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

[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.

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

Uma cobrança tem valor específico, e nesse caso não se sabe o valor a priori. O quanto o usuário quiser carregar no pré-pago, ele pode. O mesmo vale para corretoras (que poderiam estar no Pix como correntista, como participante se houver um banco no grupo).

[dmkamers]

@rubenskuhl a conciliação feita com base no nome e CPF significa que o recebedor já tem a priori essa informação. Ele pode fazer, sem problema, seja consultando com base no CPF, seja usando a forma que já existe (onde consulta se ocorreu um pagamento via TED por exemplo - e que certamente envolve um acordo com o banco que fornece a informação).

@rturk o recebedor (titular da conta que recebeu o deposito) sabe quem depositou. Não se trata de excluir a informação do fluxo. Ao contrário, o fluxo permanece absolutamente inalterado. Não abre nenhuma possibilidade de 'lavagem' por exemplo.

Nos atendo especificamente à duvida do @feinstein, que é muito pertinente, o 'cliente' da API Pix estaria recebendo uma informação que não pediu, e teria a responsabilidade de garantir que ela será devidamente descartada, ou arcar com as consequências de ocorrer vazamento ou uso indevido, por exemplo.

[dmkamers]

@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.

@rturk quais informações as empresas são obrigadas a guardar? Quais desses dados os clientes são obrigados a fornecer? E, se são obrigados a fornecer, fazem isso sem consentimento (de forma 'automática')?

[feinstein]

@dmkamers mas nem sempre o recebedor sabe quem depositou, pense numa caixa de supermercado por exemplo, ou o garçom de um bar.

[dmkamers]

@dmkamers mas nem sempre o recebedor sabe quem depositou, pense numa caixa de supermercado por exemplo, ou o garçom de um bar.

Exato, nem nunca, eu diria. Ele não sabe, e nem deve saber. Podes desenvolver melhor? Note, ele vai conciliar, sem problemas. Nada muda. Inclusive o lojista pode pesquisar pelo pagamento específico, SE o cliente fornecer o CPF e pedir por isso (o que por si só não autoriza o lojista a 'guardar' essa informação - mas, se o fizer, será por decisão própria).

[dmkamers]

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.

@rubenskuhl nos casos em que o pagador precisa informar algo (ou isso convém ao recebedor), já existe provisão na API. Neste caso, supostamente o recebedor informa o pagador a priori da necessidade, propósito, e escopo dessa informação. Ele pode gerar a cobrança usando o campo 'solicitacaoPagador', e receber a informação no campo 'infoPagador'.

[rubenskuhl]

@rubenskuhl a conciliação feita com base no nome e CPF significa que o recebedor já tem a priori essa informação. Ele pode fazer, sem problema, seja consultando com base no CPF, seja usando a forma que já existe (onde consulta se ocorreu um pagamento via TED por exemplo - e que certamente envolve um acordo com o banco que fornece a informação).

Se isso estiver especificado na API Pix para que, se fornecida, seja dessa forma, parece razoável. Quem tem uso para essa informação pode pedir para o PSP que envie tal informação, e assume a gestão do ciclo de vida da informação fornecida. O que não acho bom seria ter essa informação apenas através de outra API proprietária.

[rubenskuhl]

@rubenskuhl nos casos em que o pagador precisa informar algo (ou isso convém ao recebedor), já existe provisão na API. Neste caso, supostamente o recebedor informa o pagador a priori da necessidade, propósito, e escopo dessa informação. Ele pode gerar a cobrança usando o campo 'solicitacaoPagador', e receber a informação no campo 'infoPagador'.

Uma informação preenchida pelo pagador não atende a muitos desses casos de uso. Só o que efetivamente atende é que seja a informação validada pela IF/IP como parte do KYC.

[dmkamers]

@rubenskuhl a conciliação feita com base no nome e CPF significa que o recebedor já tem a priori essa informação. Ele pode fazer, sem problema, seja consultando com base no CPF, seja usando a forma que já existe (onde consulta se ocorreu um pagamento via TED por exemplo - e que certamente envolve um acordo com o banco que fornece a informação).

Se isso estiver especificado na API Pix para que, se fornecida, seja dessa forma, parece razoável. Quem tem uso para essa informação pode pedir para o PSP que envie tal informação, e assume a gestão do ciclo de vida da informação fornecida. O que não acho bom seria ter essa informação apenas através de outra API proprietária.

Está sim. A solicitacaoPagador é indicada na cobrança. A infoPagador deve ser colhida pelo PSP pagador e transita na mensagem de pagamento, até o PSP recebedor. Esta informação está disponível no Pix recebido.

[rubenskuhl]

@rubenskuhl a conciliação feita com base no nome e CPF significa que o recebedor já tem a priori essa informação. Ele pode fazer, sem problema, seja consultando com base no CPF, seja usando a forma que já existe (onde consulta se ocorreu um pagamento via TED por exemplo - e que certamente envolve um acordo com o banco que fornece a informação).

Se isso estiver especificado na API Pix para que, se fornecida, seja dessa forma, parece razoável. Quem tem uso para essa informação pode pedir para o PSP que envie tal informação, e assume a gestão do ciclo de vida da informação fornecida. O que não acho bom seria ter essa informação apenas através de outra API proprietária.

Está sim. A solicitacaoPagador é indicada na cobrança. A infoPagador deve ser colhida pelo PSP pagador e transita na mensagem de pagamento, até o PSP recebedor. Esta informação está disponível no Pix recebido.

Como eu disse acima, isso não atende. Não pode ser informação que o pagador tem arbitrariedade de preenchimento.

[feinstein]

@dmkamers bom, eu não sou especialista em combate a lavagem de dinheiro, mas o argumento do @rturk me pareceu bem pertinente.

[dmkamers]

@dmkamers bom, eu não sou especialista em combate a lavagem de dinheiro, mas o argumento do @rturk me pareceu bem pertinente.

O pagador está identificado, não há problema algum.

[feinstein]

Não em um QR Code estático.

[dmkamers]

@rubenskuhl a conciliação feita com base no nome e CPF significa que o recebedor já tem a priori essa informação. Ele pode fazer, sem problema, seja consultando com base no CPF, seja usando a forma que já existe (onde consulta se ocorreu um pagamento via TED por exemplo - e que certamente envolve um acordo com o banco que fornece a informação).

Se isso estiver especificado na API Pix para que, se fornecida, seja dessa forma, parece razoável. Quem tem uso para essa informação pode pedir para o PSP que envie tal informação, e assume a gestão do ciclo de vida da informação fornecida. O que não acho bom seria ter essa informação apenas através de outra API proprietária.

Está sim. A solicitacaoPagador é indicada na cobrança. A infoPagador deve ser colhida pelo PSP pagador e transita na mensagem de pagamento, até o PSP recebedor. Esta informação está disponível no Pix recebido.

Como eu disse acima, isso não atende. Não pode ser informação que o pagador tem arbitrariedade de preenchimento.

@rubenskuhl a unica informação nesta linha é o 'endToEndId', de conhecimento do PSP recebedor. Se há necessidade de correlacionar esta informação com um pagador em particular, certamente isso só se faz com um propósito e escopo previamente estabelecido entre quem acessa e o PSP recebedor. Note: o dono da conta pode ter acesso ao nome e CPF de quem depositou, não há problema algum aí. O que não existe é uma forma automatizada e irrestrita de obter essa informação. Se quiser detalhar algum caso de uso específico, se avalia. Se for o caso, se trataria de uma autorização específica na API, com este escopo. Algo entre a corretora e o PSP (pegando o seu exemplo), em que foi previamente estabelecido que pagamentos recebidos neste contexto pressupõe o fornecimento (e concordância) de determinadas informações pelos pagadores.

[dmkamers]

Não em um QR Code estático.

Sim, continua identificado. Quem recebe, sabe, sempre, quem pagou. Não entendi bem sua dúvida.

[dmkamers]

Dados pessoais do pagador não são requisito para conciliação. Esse caso de uso é específico (e provavelmente essas APIs de extrato não estão fazendo a coisa certa). Se um PSP te fornecer isso no seu extrato, o problema é do banco. Se isso for fornecido via API Pix, certamente será num contexto de 'extrato' (com condições e autorização específica), não de conciliação/confirmação de pagamento.

[rubenskuhl]

As corretoras estão no SPB, apesar de não estarem no SPI. Tanto que elas tem ISPB.

a informação que tenho é que elas não podem ser PSPs por questão jurídica mesmo. Tem que existir um banco fazendo esse serviço pra elas.

Sim, por isso o caso de uso das corretoras como ECs. Se elas fossem PSPs, elas já receberiam a informação na interface ICOM.

Imagino que vc tenha antes falado do QR-Code estático por causa do TxID... a transferência sem TxID não é informada no webhook, então a corretora precisaria ficar fazendo um loop infinito de GETs com todos os CPFs de clientes para saber que uma quantia foi depositada e por quem.

Não, não @rubenskuhl . Sem txid. Não tem txid.

Sem TxID, sem notificação no Webhook.

O fluxo é:

1. Você loga no seu banco e usa a chave da corretora para transferir uma quantia arbitrária de dinheiro.
2. fim.

Funciona porque quando você logar, quando vc apertar o refresh, ou de 1 em uma hora, ou de acordo com qualquer evento que você imaginar, a corretora envia GET /pix?cpf={cpf} e aí se houver um e2eid novo que não consta nos controles, incorpora-se esse novo pix ao seu saldo na corretora.

Enquanto isso, na TED há todo um sistema orientado a eventos que já coloca o saldo lá. Sem ter que fazer refresh, sem ter que logar no app, sem ter que checar todos os clientes por GET. Só a XP tem 3 milhões de correntistas, o ciclo de GET deles vai ser... sub-ótimo.

[dmkamers]

As corretoras estão no SPB, apesar de não estarem no SPI. Tanto que elas tem ISPB.

a informação que tenho é que elas não podem ser PSPs por questão jurídica mesmo. Tem que existir um banco fazendo esse serviço pra elas.

Sim, por isso o caso de uso das corretoras como ECs. Se elas fossem PSPs, elas já receberiam a informação na interface ICOM.

Imagino que vc tenha antes falado do QR-Code estático por causa do TxID... a transferência sem TxID não é informada no webhook, então a corretora precisaria ficar fazendo um loop infinito de GETs com todos os CPFs de clientes para saber que uma quantia foi depositada e por quem.

Não, não @rubenskuhl . Sem txid. Não tem txid.

Sem TxID, sem notificação no Webhook.

O fluxo é:

1. Você loga no seu banco e usa a chave da corretora para transferir uma quantia arbitrária de dinheiro.
2. fim.

Funciona porque quando você logar, quando vc apertar o refresh, ou de 1 em uma hora, ou de acordo com qualquer evento que você imaginar, a corretora envia GET /pix?cpf={cpf} e aí se houver um e2eid novo que não consta nos controles, incorpora-se esse novo pix ao seu saldo na corretora.

Enquanto isso, na TED há todo um sistema orientado a eventos que já coloca o saldo lá. Sem ter que fazer refresh, sem ter que logar no app, sem ter que checar todos os clientes por GET. Só a XP tem 3 milhões de correntistas, o ciclo de GET deles vai ser... sub-ótimo.

A XP só precisa, uma vez, apresentar um QR pro cliente (que tem um txid que representa esse cliente).
É muita restrição de recursos (não quero gerar um txid) pra um provedor que tem 3 milhões de clientes.

[feinstein]

Existem correntistas que não entram no site da corretora, eles usam apps externos para fazer a análise das ações e emitir as ordens de compra, como o Metatrader e o NinjaTrader, que possuem integrações com corretoras.

[rubenskuhl]

A XP só precisa, uma vez, apresentar um QR pro cliente (que tem um txid que representa esse cliente).
É muita restrição de recursos (não quero gerar um txid) pra um provedor que tem 3 milhões de clientes.

Aí a jornada do usuário fica tão longa como a que descrevi acima. Então ou é sub-ótimo do lado do EC, ou do lado do pagador... enquanto a TED funciona totalmente para ambos.

[dmkamers]

A XP só precisa, uma vez, apresentar um QR pro cliente (que tem um txid que representa esse cliente).
É muita restrição de recursos (não quero gerar um txid) pra um provedor que tem 3 milhões de clientes.

Aí a jornada do usuário fica tão longa como a que descrevi acima. Então ou é sub-ótimo do lado do EC, ou do lado do pagador... enquanto a TED funciona totalmente para ambos.

O usuario paga sem se cadastrar antes? "Investe aí pra mim, 10 mil, CPF tal, esse pagamento significa que voce pode criar a conta, investir, e está autorizado". É isso?

[rubenskuhl]

A XP só precisa, uma vez, apresentar um QR pro cliente (que tem um txid que representa esse cliente).
É muita restrição de recursos (não quero gerar um txid) pra um provedor que tem 3 milhões de clientes.

Aí a jornada do usuário fica tão longa como a que descrevi acima. Então ou é sub-ótimo do lado do EC, ou do lado do pagador... enquanto a TED funciona totalmente para ambos.

O usuario paga sem se cadastrar antes? "Investe aí pra mim, 10 mil, CPF tal, esse pagamento significa que voce pode criar a conta, investir, e está autorizado". É isso?

Não, os procedimentos de KYC das corretoras são tão rígidos quanto de bancos. Mas veja a jornada do usuário que descrevi acima mesmo já cadastrado quando se usa um QR-Code, ela é para titulares já cadastrados.

[dmkamers]

A XP só precisa, uma vez, apresentar um QR pro cliente (que tem um txid que representa esse cliente).
É muita restrição de recursos (não quero gerar um txid) pra um provedor que tem 3 milhões de clientes.

Aí a jornada do usuário fica tão longa como a que descrevi acima. Então ou é sub-ótimo do lado do EC, ou do lado do pagador... enquanto a TED funciona totalmente para ambos.

O usuario paga sem se cadastrar antes? "Investe aí pra mim, 10 mil, CPF tal, esse pagamento significa que voce pode criar a conta, investir, e está autorizado". É isso?

Não, os procedimentos de KYC das corretoras são tão rígidos quanto de bancos. Mas veja a jornada do usuário que descrevi acima mesmo já cadastrado quando se usa um QR-Code, ela é para titulares já cadastrados.

Pronto, no cadastro o usuário recebe um QR. Copia e cola, e nunca mais precisa repetir isso.

[rubenskuhl]

Pronto, no cadastro o usuário recebe um QR. Copia e cola, e nunca mais precisa repetir isso.

O que pressupõe um recurso hoje não especificado no manual de experiência, que é o de "lembrar" um QR.

[ninrod]

@rubenskuhl ,

voltando ao fluxo utilizando txid via QR estático sem valor, mas com txid.

Se tivesse a funcionalidade do PSP pagador: "pagar novamente QR Estático XYZ'. Resolveria, certo?

O que pressupõe um recurso hoje não especificado no manual de experiência, que é o de "lembrar" um QR.

Ok, o manual de experiência eu posso alterar. O que eu preciso saber é se resolve o caso de uso colocado.

[rubenskuhl]

@rubenskuhl ,

voltando ao fluxo utilizando txid via QR estático sem valor, mas com txid.

Se tivesse a funcionalidade do PSP pagador: "pagar novamente QR Estático XYZ'. Resolveria, certo?

O que pressupõe um recurso hoje não especificado no manual de experiência, que é o de "lembrar" um QR.

Ok, o manual de experiência eu posso alterar. O que eu preciso saber é se resolve o caso de uso colocado.

Resolveria. O que eu não sei se poderia ser usado também é o QR-Code dinâmico com reuso de location, mas ele é muito abstrato para mim no momento para que eu possa ser taxativo.

O método de guardar pode ser uma opção depois de realizado o pagamento para guardar aquele QR para reuso. Se estático ou estático + dinâmico, depende do ponto acima sobre reuso de location.

[renatofrota]

Não ficou claro pra mim se chegaram a um consenso.

No meu ponto de vista, é possível replicar a mesma segurança do TED em relação a garantia da identidade do efetivo pagador com o Pix, sem a quebra de privacidade do pagador 'por default' quando este não quer se identificar pelo próprio envio do Pix, mesmo com a remoção do pix.pagador:

• Corretora gera um QR Code estático com um txid específico para o cliente (que pode até ser igual ao CPF/CNPJ);
• Cliente envia o Pix para a corretora pelo QR Code (ou envia o Pix informando a chave Pix + o txid manualmente)
• PSP notifica a corretora via webhook que aquela chave recebeu um novo Pix (nesta notificação consta o txid e o e2eid)
• Corretora consulta os Pix recebidos filtrando pelo CPF/CNPJ relativo àquele txid - se este Pix (de acordo com o e2eid) for retornado, significa que o mesmo foi enviado pelo próprio cliente (o que o "autentica"). Se não for retornado este Pix, significa que ele foi enviado por um terceiro.

Não há a necessidade de polling nem de um aviso por parte do cliente do tipo "enviei o Pix, me autentique / carregue minha conta".

Se vocês já tinham chegado a esse fluxo, me desculpem por fazê-los perder tempo. 😛

[ninrod]

@renatofrota , é por aí mesmo.

Você adicional um último passo que não constava aqui na discussão, que realmente fica útil para validar a identidade do efetivo pagador. Melhor ainda.

[rubenskuhl]

Se vocês já tinham chegado a esse fluxo, me desculpem por fazê-los perder tempo. 😛

Só faltou ao final a opção de guardar o QR-Code para pagamentos futuros, quer seja um estático com TxID (que é necessário para ativar o webhook, tanto que você mencionou no exemplo) quer seja um dinâmico com reuso de location. Isso ainda não consta do manual de experiência mas possivelmente seja adicionado.

[renatofrota]

"Desenterrando" o issue para perguntar:

Os termos de uso do Pix evidenciam, no momento do cadastramento de uma chave - de forma bastante explícita (conforme manual de UX do Pix) - quais dados serão expostos ao pagador na ocasião do uso daquela Chave Pix para identificar o recebedor:

• Nome completo
• CPF parcial
• Instituição de pagamento onde a chave está vinculada

A mesma informação é constante dos Termos de Uso que o usuário concorda ao cadastrar a chave.

Porém, o que tenho visto são instituições abrindo outras informações a respeito do recebedor, não somente em comprovantes mas, até mesmo, quando da inserção da chave (antes mesmo de realizar o pagamento).

Em detalhes

aqui.

As instituições de pagamento estão erradas? Se sim, o BACEN deveria comunicá-las. Se elas estão corretas em expôr esses dados não previstos, então são os termos de uso do Pix que deveriam ser revistos (assim como o manual de UX) e - num mundo perfeito - os usuários deveriam concordar com a atualização desses termos antes que suas chaves possam ser consultadas de novo.

[feinstein]

Outra coisa com relação a privacidade que eu estou vendo bastante é as pessoas falarem que não querem fazer Pix porque "o governo está rastreando todas as minhas operações".

Até onde eu sei o Bacen não pode rastrear nada e enviar a Receita Federal, seria quebra de sigilo bancário, então isso deveria ser melhor comunicado ao público em geral.

[dmkamers]

"Desenterrando" o issue para perguntar:

Os termos de uso do Pix evidenciam, no momento do cadastramento de uma chave - de forma bastante explícita (conforme manual de UX do Pix) - quais dados serão expostos ao pagador na ocasião do uso daquela Chave Pix para identificar o recebedor:

• Nome completo
• CPF parcial
• Instituição de pagamento onde a chave está vinculada

A mesma informação é constante dos Termos de Uso que o usuário concorda ao cadastrar a chave.

Porém, o que tenho visto são instituições abrindo outras informações a respeito do recebedor, não somente em comprovantes mas, até mesmo, quando da inserção da chave (antes mesmo de realizar o pagamento).

Em detalhes

aqui.

As instituições de pagamento estão erradas? Se sim, o BACEN deveria comunicá-las. Se elas estão corretas em expôr esses dados não previstos, então são os termos de uso do Pix que deveriam ser revistos (assim como o manual de UX) e - num mundo perfeito - os usuários deveriam concordar com a atualização desses termos antes que suas chaves possam ser consultadas de novo.

@renatofrota as contribuições sao importantes, mas é melhor avisar as instituições e encaminhar os relatos para pix-operacional@bcb.gov.br com evidencias dos problemas encontrados

[renatofrota]

"Desenterrando" o issue para perguntar:
Os termos de uso do Pix evidenciam, no momento do cadastramento de uma chave - de forma bastante explícita (conforme manual de UX do Pix) - quais dados serão expostos ao pagador na ocasião do uso daquela Chave Pix para identificar o recebedor:

• Nome completo
• CPF parcial
• Instituição de pagamento onde a chave está vinculada

A mesma informação é constante dos Termos de Uso que o usuário concorda ao cadastrar a chave.
Porém, o que tenho visto são instituições abrindo outras informações a respeito do recebedor, não somente em comprovantes mas, até mesmo, quando da inserção da chave (antes mesmo de realizar o pagamento).
Em detalhes

aqui.

As instituições de pagamento estão erradas? Se sim, o BACEN deveria comunicá-las. Se elas estão corretas em expôr esses dados não previstos, então são os termos de uso do Pix que deveriam ser revistos (assim como o manual de UX) e - num mundo perfeito - os usuários deveriam concordar com a atualização desses termos antes que suas chaves possam ser consultadas de novo.

@renatofrota as contribuições sao importantes, mas é melhor avisar as instituições e encaminhar os relatos para pix-operacional@bcb.gov.br com evidencias dos problemas encontrados

Obrigado. Eu enviei por este e-mail e me falaram pra abrir RDR - o que eu devo fazer para cada instituição, individualmente.

Eu até escrevi um "rant" aqui, mas já apaguei. Vida que segue.

[rubenskuhl]

Quando se é correntista da instituição é factível abrir RDR, mas e quando não ?

[renatofrota]

Quando se é correntista da instituição é factível abrir RDR, mas e quando não ?

Exato. Não se pode mais fazer denúncias nesse país. Só delação premiada.

Talvez eu devesse processar logo o banco por expor meus dados? 🤔

Estou aceitando contatos de advogados especializados na área.

[rubenskuhl]

As questões de privacidade especificamente poderão ser denunciadas à ANPD quando ela existir. Enquanto isso, o MPDFT já tomou outras ações contra instituições financeiras e de crédito em casos de quebra de privacidade/sigilo/segurança, e pode se interessar (ou não) pela questão:
https://www.mpdft.mp.br/portal/
https://www.mpdft.mp.br/portal/index.php/conhecampdft-menu/nucleos-e-grupos/espec/contato

Ministério Público do Distrito Federal e Territórios
A Unidade Especial de Proteção de Dados e Inteligência Artificial (Espec)

Eixo Monumental, Praça do Buriti, Lote 2, Sala 922 D, Sede do MPDFT, Brasília-DF
CEP 70.091-900
dados@mpdft.mp.br

[dmkamers]

Caros, uma vez que as orientações que tentei repassar nao agregaram na discussão do tópico, tomei a liberdade de remove-las.

[dmkamers]

Quando se é correntista da instituição é factível abrir RDR, mas e quando não ?

enquanto PSP, ... protocolo digital ou pix-operacional@bcb.gov.br, dependendo do propósito. Enquanto pessoa física RDR.

[rubenskuhl]

E o site da ANPD está no ar, e há canais de comunicação. Se já estão operacionais de fato, não sei.
https://www.gov.br/anpd/pt-br