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

[dmkamers]

Segundo a LGPD não podemos armazenar os dados dos clientes sem o consentimento deles. 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?

@feinstein , não. Está dito em algum lugar que um Pix é uma autorização automática para armazenamento de informações pessoais? Se sim, por gentileza nos aponte. Mesmo que mantivéssemos pix.pagador (efetivo) na API, a autorização não se subentende. Retirar é apenas questão de não expor os clientes da API a um risco desnecessário (até desconhecido em alguns casos), caso o PSP recebedor não tome as devidas providências para evitar isso.

[dmkamers]

Como seria essa "de alguma forma"?

GET /pix (passa o CPF como parametro)

Futuramente (e não 'por default'), quando o pagador consentir, isso poderá transitar 'automaticamente' (entregando a identificação 'limpa e validada pelo banco pagador') de bandeja para o recebedor. Note, o recebedor já tem a informação. Trata-se apenas de recuperar via API sob condições razoáveis.

[feinstein]

@feinstein , não. Está dito em algum lugar que um Pix é uma autorização automática para armazenamento de informações pessoais? Se sim, por gentileza nos aponte. Mesmo que mantivéssemos pix.pagador (efetivo) na API, a autorização não se subentende. Retirar é apenas questão de não expor os clientes da API a um risco desnecessário (até desconhecido em alguns casos), caso o PSP recebedor não tome as devidas providências para evitar isso.

Estou ciente que a documentação não diz que há o aceite imediato, mas conjecturei que talvez por fazer parte da API, conforme descrito nas documentações da versão 2.0, haveria portanto algum documento a ser liberado ao público no futuro avisando que esses dados seriam compartilhados, talvez alguma obrigação dos bancos de avisarem, ou um aceite geral ao habilitar o Pix para uma conta transacional: "ao se cadastrar no Pix voce concorda que...".

Daí minha pergunta original, eu queria saber quais os limites do Pix perante a LGPD, se vocês tinham salvaguardas disso e etc.

[dmkamers]

Se eu entendi direito, isso significa que um GET na API com filtro de CPF só pode retornar um Pix se o efetivo pagador for mesmo o CPF em questão, e tem que retornar inexistente se o efetivo pagador não for o CPF em questão ? Se sim, isso permite validar se quem pagou era quem era esperado que pagasse, e isso permite fazer a checagem apesar da ausência do parâmetro na informação do Pix recebido. (Notar que não estamos falando do CPF na cobrança)

Esclarecendo: um GET em /pix. GET em 'cobranças' é baseado em CPF do 'devedor'. Aí voltam todos os Pix associados a cada cobrança desse 'devedor' (se existirem), não importa quem efetivou pagamento (e esse é exatamente o problema). Continuará voltando, mas seja 'sob' uma cobrança, seja consultando diretamente 'tudo o que recebi', a informação do pagador não precisa voltar 'por default'. Se voltar, será em contexto específico da API (com autorização própria, que pressuponha que os pagadores 'autorizaram' isso).

[rubenskuhl]

@rubenskuhl nao entendi a relação com oauth. Sim, ele recebe autorização do EC pra operar na API Pix, isso não significa autorização dos pagadores para receber e armazenar qualquer dado pessoal. Eu devo ter me expressado mal antes, vamos deixar esse ponto pra lá, acredito que não é relevante. Sim, quando for possível via API (o 'pagamento autenticador'), está tudo certo, seja o EC diretamente, ou um terceiro autorizado (e aí o problema é entre eles).

Falando de TED: via 'extrato', ok, é sua conta (mesmo cenário aqui). Via API: o banco te dá a possibilidade de elencar todos os nomes e CPFs que já te pagaram alguma coisa em algum momento, mesmo aqueles que você sequer conhecia previamente? Ele faz isso por default, sem nenhuma contrapartida, limite, ou condição? Os pagadores estão cientes disso? Se alguma dessas respostas for sim, e quiseres compartilhar a fundamentação jurídica e porque isso não fere a LGDP (que é um cenário novo) podemos avaliar se é aplicável a pagamentos de varejo.

Não há diferença de regras de tratamentos de dados entre meios; o acesso via extrato e via API é equivalente do ponto de vista de LGPD.

Via API o banco fornece o CPF/CNPJ junto da informação de pagamento, e ele fornece mesmo que não seja conhecido previamente (não há uma lista de conhecidos que é fornecida para o banco). Ele faz isso por default, e as condições são as usuais sobre uso dos dados (finalidade). Os pagadores não estão cientes disso.

E a fundamentação na LGPD para o que estamos falando é o Art. 11, alínea g:

"g) garantia da prevenção à fraude e à segurança do titular, nos processos de identificação e autenticação de cadastro em sistemas eletrônicos, resguardados os direitos mencionados no art. 9º desta Lei e exceto no caso de prevalecerem direitos e liberdades fundamentais do titular que exijam a proteção dos dados pessoais."

Por isso já havia mencionado que não há óbice na LGPD; isso não significa que o BACEN precise fazer tudo que a lei permite, pois o BACEN como instituidor do arranjo pode escolher não ter isso no Pix. Mas ao fazê-lo, está fazendo uma escolha diminuindo o Pix frente à TED, e essa escolha não tem requisito jurídico que a compelisse.

Por hora, me parece que há um 'caso de uso' claro que, sim, pode ser contemplado (não 'por default') na API Pix, que é o 'autenticação por pagamento' (sem 'identificação' prévia). Neste caso, certamente os pagadores deverão estar cientes das condições em que vão efetuar a operação (como ocorre em compras online, por exemplo). Infelizmente, parece ser um caso de uso 'contemplado' por acaso, até o momento (note que o pix.pagador é opcional). Como comentei, não ser o 'default' não significa que não pode ser facilmente implementado, após as análises devidas. Acho que a comunidade pode fundamentar e encaminhar às áreas de negócio a necessidade. Não é uma decisão a ser tomada no commit.

A mudança na informação que flui pelo PSP pagador não requer mudança apenas na API Pix, pois hoje o PSP recebedor não tem uma sinalização de consentimento (lembrando que consentimento é apenas um dos vários autorizadores da LGPD para tratamento de dados pessoais).

[dmkamers]

@rubenskuhl confesso que não entendi, e discordo, da sua argumentação jurídica. Se as APIs bancárias de TED não ferem a LGPD, de qualquer forma, não nos ajuda em nada aqui.

Sim, prevenção à fraude foi citado, não é motivo para você ser obrigado a fornecer o CPF na padaria. Acesso à extrato bancário via API não tem relação com conciliação de pagamento no varejo do ponto de vista de finalidade, consentimento (e todos os outros requisitos legais) quanto a acesso a dados pessoais. Você não pode exigir nome e CPF de ninguém na padaria, e o padeiro não precisa das informações (é risco para ele). É diferente de você voluntariamente efetivar um depósito na conta de alguém 'querendo' ser identificado (diria que com o propósito específico de ser identificado, praticamente).

Enfim, como comentei reiteradamente, trata-se apenas de mudar o comportamento 'default'. Está em avaliação, e o caso de uso 'pagamento autenticador' certamente vai ser considerado (talvez diferenciar o escopo de acesso apenas). Deve ser caso marginal - não tenho dados no momento - comparado ao propósito maior de atender ao varejo, e este 'condicionante' de uso do Pix poderia ser um supressor maior do que o estímulo do primeiro caso.

[rubenskuhl]

Sim, prevenção à fraude foi citado, não é motivo para você ser obrigado a fornecer o CPF na padaria.

Não é só prevenção à fraude, é também "nos processos de identificação e autenticação de cadastro em sistemas eletrônicos" (reprodução exata do texto da LGPD).

Você não pode exigir nome e CPF de ninguém na padaria, e o padeiro não precisa das informações (é risco para ele).

Sim, e isso pode ser uma opção no dashboard do EC: quero receber/não quero receber. E pode ser default "não quero receber", basta que o EC possa ativar.

Enfim, como comentei reiteradamente, trata-se apenas de mudar o comportamento 'default'. Está em avaliação, e o caso de uso 'pagamento autenticador' certamente vai ser considerado (talvez diferenciar o escopo de acesso apenas).

Diferenciação de escopo é uma opção interessante também.

Deve ser caso marginal - não tenho dados no momento - comparado ao propósito maior de atender ao varejo, e este 'condicionante' de uso do Pix poderia ser um supressor maior do que o estímulo do primeiro caso.

São mais de 3 milhões de CPFs hoje na B3, e todos tem que investir através de corretoras. Se somar os que só investem em renda fixa, dá mais. São mais de 100 milhões de celulares pré-pagos. Esses casos de uso são bem numerosos, não são marginais.

[dmkamers]

Sim, prevenção à fraude foi citado, não é motivo para você ser obrigado a fornecer o CPF na padaria.

Não é só prevenção à fraude, é também "nos processos de identificação e autenticação de cadastro em sistemas eletrônicos" (reprodução exata do texto da LGPD).

"...resguardados os direitos mencionados no art. 9º desta Lei e exceto no caso de prevalecerem direitos e liberdades fundamentais do titular que exijam a proteção dos dados pessoais."

Note que um pagamento de varejo não é um processo de "identificação e autenticação de cadastro..." (já ficou bem claro que esta é a necessidade).

[rubenskuhl]

"...resguardados os direitos mencionados no art. 9º desta Lei e exceto no caso de prevalecerem direitos e liberdades fundamentais do titular que exijam a proteção dos dados pessoais."

Os direitos do art 9 são os de informação sobre o processo de tratamento de dados, e se aplicariam mesmo sem a ressalva. Especificamente sobre o CPF, ela é informação que aparece em diversos outros processos na sociedade e não identifica dados sensíveis.

Note que um pagamento de varejo não é um processo de "identificação e autenticação de cadastro..." (já ficou bem claro que esta é a necessidade).

Uma das necessidades, eu já mencionei algumas outras.

[feinstein]

IMHO se a LGPD não vê problemas em compartilhar nome e CPF durante um pagamento, então não vejo porque o Pix veria.

Dito isso, eu realmente acho que precisamos adicionar alguns especialistas nessa conversa, conforme já sugerido anteriormente pelo @rturk.

No final das contas somos todos programadores e não seria prudente tomar uma decisão tão grande, quanto a modelagem de um novo sistema de pagamento do país, sem participação de advogados especialistas em LGPD e profissionais especializados no combate à corrupção.

Podem haver diversos casos que talvez estamos deixando de contemplar e um especialista pode identificar de imediato.

Acredito que o BC tem acesso a esses profissionais e eles deviam ser incluídos nessa discussão o quanto antes.

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

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

@rubenskuhl, não querendo entrar no mérito jurídico da questão e tentando encontrar maneiras técnicas de se resolver os casos de uso das "corretoras" e dos "pré-pagos" sem o pix.pagador, um QR Estático com txid, mas sem valor, não resolveria?

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

@rubenskuhl, não querendo entrar no mérito jurídico da questão e tentando encontrar maneiras técnicas de se resolver os casos de uso das "corretoras" e dos "pré-pagos" sem o pix.pagador, um QR Estático com txid, mas sem valor, não resolveria?

Corretoras: não resolve. Elas tem que confirmar que os recursos vieram de uma conta do titular. E vale o comentário de UX abaixo. Pré-pagos: introduz uma significativa sequência de passos adicionais.

Exemplo de jornada do usuário fazendo transferência para corretora hoje via TED:

• Transfere para conta informado ISPB, agência e conta. Fim.

Exemplo de jornada do usuário fazendo transferência para corretora hoje via Pix:

• Loga na corretora
• Mostra QR-Code
• Copia e cola
• Abre aplicativo do banco
• Pagar Pix
• Cola
• Volta na corretora
• Avisa que Pix foi feito
• Corretora confirma que foi feito Pix a partir do CPF e faz o crédito.

A diferença de número de linhas para descrever as duas jornadas fala por si só.

[ninrod]

Corretoras: não resolve. Elas tem que confirmar que os recursos vieram de uma conta do titular. E vale o comentário de UX abaixo. Pré-pagos: introduz uma significativa sequência de passos adicionais.

Exemplo de jornada do usuário fazendo transferência para corretora hoje via TED:

Transfere para conta informado ISPB, agência e conta. Fim. Exemplo de jornada do usuário fazendo transferência para corretora hoje via Pix:

Loga na corretora Mostra QR-Code Copia e cola Abre aplicativo do banco Pagar Pix Cola Volta na corretora Avisa que Pix foi feito Corretora confirma que foi feito Pix a partir do CPF e faz o crédito. A diferença de número de linhas para descrever as duas jornadas fala por si só.

@rubenskuhl, point taken.

via TED (como exatamente a corretora sabe que houve um pagamento cujo CPF é tal? Nenhuma corretora é um PSP).

1. Transfere para conta informado ISPB, agência e conta. Fim.

via Pix Usando o GET /pix?cpf={cpf} (quando loga, quando ticka o clock de refresh, quando aperta no botão de refresh, etc...)

1. Faz a tranferência informando a chave. fim.

não seria isso?

[dmkamers]

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

@rubenskuhl, não querendo entrar no mérito jurídico da questão e tentando encontrar maneiras técnicas de se resolver os casos de uso das "corretoras" e dos "pré-pagos" sem o pix.pagador, um QR Estático com txid, mas sem valor, não resolveria?

Corretoras: não resolve. Elas tem que confirmar que os recursos vieram de uma conta do titular. E vale o comentário de UX abaixo. Pré-pagos: introduz uma significativa sequência de passos adicionais.

Exemplo de jornada do usuário fazendo transferência para corretora hoje via TED:

• Transfere para conta informado ISPB, agência e conta. Fim.

Exemplo de jornada do usuário fazendo transferência para corretora hoje via Pix:

• Loga na corretora
• Mostra QR-Code
• Copia e cola
• Abre aplicativo do banco
• Pagar Pix
• Cola
• Volta na corretora
• Avisa que Pix foi feito
• Corretora confirma que foi feito Pix a partir do CPF e faz o crédito.

A diferença de número de linhas para descrever as duas jornadas fala por si só.

Nao foi comparação justa: para informar ispb, conta... tens que saber isso previamente. Provavelmente vai ter um copia e cola em cada campo destes (ispb, agencia, conta...). Ou pode entrar direto (modelo TED) os dados para fazer o Pix (com a vantagem que só precisa da chave, e não ispb, agencia, conta). E, se a corretora gera um txId, você nao precisa avisar que pagou. Ela sabe que gerou pra você. "Avisar que pagou" é quando o pagador faz isso "às cegas" (sem um txid). Aí a corretora tem que consultar pelo seu CPF. Enfim, é mais provável que o TED venha a ter tantos bullets quando o segundo caso do que o contrário.

[ninrod]

Nao foi comparação justa: para informar ispb, conta... tens que saber isso previamente. Provavelmente vai ter um copia e cola em cada campo destes (ispb, agencia, conta...). Ou pode entrar direto (modelo TED) os dados para fazer o Pix (com a vantagem que só precisa da chave, e não ispb, agencia, conta). E, se a corretora gera um txId, você nao precisa avisar que pagou. Ela sabe que gerou pra você. "Avisar que pagou" é quando o pagador faz isso "às cegas" (sem um txid). Aí a corretora tem que consultar pelo seu CPF. Enfim, é mais provável que o TED venha a ter tantos bullets quando o segundo caso do que o contrário.

@dmkamers , você tem razão, mas há bancos que "guardam" a informação de ISPB, ag, conta, etc... para transferências futuras.

Ainda assim, nada impediria de existir uma feature no PSP pagador "pagar novamente o QR Estático".

Certo?

[rubenskuhl]

via TED (como exatamente a corretora sabe que houve um pagamento cujo CPF é tal? Nenhuma corretora é um PSP).

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

1. Transfere para conta informado ISPB, agência e conta. Fim.

via Pix Usando o GET /pix?cpf={cpf} (quando loga, quando ticka o clock de refresh, quando aperta no botão de refresh, etc...)

1. Faz a tranferência informando a chave. fim.

não seria isso?

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.

[rubenskuhl]

Nao foi comparação justa: para informar ispb, conta... tens que saber isso previamente. Provavelmente vai ter um copia e cola em cada campo destes (ispb, agencia, conta...).

Só no primeiro aporte. Depois já fica tudo na agenda de destinatários frequentes do banco. Notar que é TED mesmo titular, então não pergunta CPF/CNPJ.

Ou pode entrar direto (modelo TED) os dados para fazer o Pix (com a vantagem que só precisa da chave, e não ispb, agencia, conta). E, se a corretora gera um txId, você nao precisa avisar que pagou. Ela sabe que gerou pra você. "Avisar que pagou" é quando o pagador faz isso "às cegas" (sem um txid). Aí a corretora tem que consultar pelo seu CPF. Enfim, é mais provável que o TED venha a ter tantos bullets quando o segundo caso do que o contrário.

Faça você mesmo o teste com qualquer corretora, muitas tem abertura de conta gratuita. É tão simples e rápido como descrevi, com TED.

[ninrod]

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.

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. 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 na corretora, quando vc apertar o refresh, ou de uma 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.

Funciona, certo?

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

[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? :thinking:

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