O que é o RGPD e por que é importante para os pagamentos em criptomoedas
O RGPD e os pagamentos em criptomoedas cruzam-se porque o RGPD é a lei de proteção de dados da União Europeia e aplica-se a muitas empresas que tratam dados pessoais de residentes na UE, mesmo quando o pagamento é feito em Bitcoin, USDT ou outro token. Um comerciante em Londres, uma empresa SaaS em Lisboa ou um gateway que processa faturas de clientes na Alemanha podem estar abrangidos. A regra é simples: se trata dados pessoais, o RGPD pode aplicar-se a si. Compreender a relação entre RGPD e pagamentos em criptomoedas é, por isso, essencial desde o início da atividade.
Os pagamentos em criptomoedas continuam a envolver nomes, endereços de e-mail, endereços de carteiras, dados dos dispositivos e pedidos de assistência. Isso basta. Um endereço de carteira pode parecer uma sequência aleatória de caracteres, mas ainda pode ser associado a uma pessoa através de registos de faturação, documentos KYC ou padrões de transação. Uma única fatura pode ligar vários pontos de dados.
As empresas muitas vezes presumem que as criptomoedas implicam menos riscos para a privacidade porque não é guardado nenhum número de cartão. Essa ideia desfaz-se rapidamente. Um pedido de pagamento pode incluir um ID de encomenda, uma morada de entrega, uma nota de reembolso e um endereço IP, tudo no mesmo processo. O meio de pagamento muda, mas a questão de conformidade mantém-se.
Para os comerciantes, não se trata de uma questão teórica. Um processo de pagamento simples, uma contestação de cobrança ou um reembolso pode criar um registo que inclua dados pessoais e decisões comerciais sobre os motivos da recolha desses dados. Se também consultar um guia sobre gateways de pagamento em criptomoedas para comércio eletrónico, verá que as mesmas questões de privacidade tendem a surgir durante a configuração, não depois do lançamento. É nessa altura que deve perguntar quem vê o quê.
Como surgem os dados pessoais nas transações em criptomoedas
Os dados pessoais surgem nas transações em criptomoedas em mais locais do que muitas equipas esperam. Os endereços de carteiras são o exemplo mais óbvio, mas são apenas o começo. Endereços IP, impressões digitais do navegador, números de fatura, dados de entrega e registos de apoio ao cliente podem fazer parte de um registo de pagamento. Até um carimbo temporal pode ser relevante quando combinado com outro identificador.
As verificações KYC são outra fonte comum. Um prestador pode recolher uma cópia do passaporte, uma selfie, um comprovativo de morada ou um documento de registo da empresa antes de permitir transações de valor mais elevado. Estes dados estão claramente abrangidos pelas regras de proteção de dados. O mesmo se aplica às pontuações de risco, às listas de utilizadores bloqueados e às notas de revisão manual redigidas por uma equipa de conformidade.
Os metadados na blockchain também são importantes. Um campo de mensagem, uma referência de pagamento ou um código de encomenda incorporado podem revelar mais do que se pretendia. Algumas empresas acrescentam nomes de clientes ou partes dos respetivos endereços de e-mail às etiquetas das transações para facilitar a reconciliação. Isso também torna o registo mais pessoal. Uma blockchain pública não se esquece desses detalhes.
Há aqui uma questão prática. Mesmo que o processo de pagamento tenha sido concebido para ser rápido, pode ser necessário perguntar quais os campos opcionais e quais os obrigatórios. Um campo adicional pode alterar o enquadramento jurídico. O mesmo se aplica aos reembolsos, quando um agente de apoio ao cliente pode pedir um endereço de carteira, o hash da transação e um comprovativo de compra no mesmo pedido.
Para as equipas que querem começar com uma análise mais tranquila, vale a pena ler como testar um pagamento em criptomoedas antes de qualquer lançamento em produção. Os testes mostram quais os dados recolhidos por predefinição, quais podem ser removidos e quais estão incluídos simplesmente porque ninguém os questionou durante a implementação. Este pequeno exercício pode evitar uma limpeza posterior.
Funções previstas no RGPD numa configuração de pagamentos em criptomoedas
O RGPD define duas funções principais: responsável pelo tratamento e subcontratante. O responsável pelo tratamento decide por que motivos e de que forma os dados pessoais são tratados. O subcontratante trata os dados por conta do responsável. Muitas vezes, o comerciante é o responsável pelo tratamento dos dados dos clientes recolhidos no processo de pagamento, mas nem sempre é assim tão simples.
Um gateway de pagamento pode ser subcontratante no que diz respeito às instruções de pagamento, mas passar a ser responsável pelo tratamento dos seus próprios processos de prevenção ou avaliação de fraude. Uma plataforma de câmbio pode ser responsável pelo tratamento na abertura de contas e subcontratante em determinados serviços relacionados com comerciantes. Um prestador de carteiras pode ter ainda outro papel, consoante os termos do serviço e o fluxo efetivo dos dados. Os contratos são importantes, mas os factos são ainda mais importantes.
As funções devem ser mapeadas por escrito. Não num diapositivo, mas num registo interno propriamente dito. Esse registo deve indicar quem trata os dados das faturas, quem recebe os registos de IP, quem guarda os documentos KYC e quem responde aos pedidos de eliminação dos utilizadores. Se três fornecedores tiverem acesso ao mesmo registo, não se deve adivinhar qual é a função de cada um.
É aqui que um pequeno detalhe pode criar problemas a um comerciante. Um prestador de pagamentos em criptomoedas que apenas transmite confirmações de pagamento pode, ainda assim, utilizar metadados dos clientes para verificar riscos. Nesse caso, o prestador pode não estar a atuar exclusivamente como subcontratante em todas as atividades. Um contrato bem redigido ajuda, mas é o fluxo dos dados que determina o resultado.
Bases legais para o tratamento de dados de pagamento
As empresas precisam de uma base legal antes de tratarem dados pessoais. No contexto do RGPD e dos pagamentos em criptomoedas, três bases são geralmente as primeiras a considerar: a necessidade contratual, o cumprimento de uma obrigação legal e os interesses legítimos. A necessidade contratual abrange os dados necessários para concluir o pagamento ou prestar o serviço. Se um cliente comprar um produto digital e pagar em criptomoedas, poderá precisar do endereço de e-mail, do endereço da carteira e da referência da encomenda para concluir a transação.
O cumprimento de uma obrigação legal aplica-se quando a lei exige a conservação de dados ou a comunicação de informações. Os registos fiscais, os registos contabilísticos e as verificações de combate ao branqueamento de capitais podem enquadrar-se nesta categoria. O essencial é limitar a conservação ao necessário. Se uma regra exigir que um registo seja conservado durante sete anos, isso não significa que todos os registos tenham de ser guardados durante esse período.
Os interesses legítimos justificam muitas vezes a prevenção de fraude, a monitorização da segurança e a deteção de abusos. Esta base não é um salvo-conduto. A empresa continua a ter de ponderar os seus interesses face aos direitos da pessoa em causa. É preferível fazer uma breve avaliação de ponderação a invocar vagamente que «é necessário por motivos de segurança».
O consentimento é utilizado em alguns processos relacionados com criptomoedas, mas não deve servir de atalho para tudo. Se o serviço não puder funcionar sem determinados dados, a necessidade contratual poderá ser a base mais adequada. Se a equipa de marketing quiser reutilizar dados de pagamento em campanhas de e-mail, trata-se de outra questão. Um conjunto de dados, duas finalidades, duas questões jurídicas.
Para os comerciantes que trabalham com faturação recorrente, a faturação automatizada da Payora com o WHMCS pode ser um exemplo operacional útil, já que é fácil perder de vista os limites de conservação e de finalidade quando há faturação recorrente. Os pagamentos mensais geram um fluxo constante de registos, e é nesses fluxos constantes que começam a esconder-se práticas descuidadas.
Principais riscos do RGPD nos pagamentos em criptomoedas
A recolha excessiva de dados é um risco comum. Um formulário de pagamento pede nome, endereço de e-mail, número de telefone, nome da empresa, morada de faturação, morada de entrega e nome de utilizador do Telegram. Para um serviço digital, pode ser informação a mais. Recolher mais dados do que o necessário aumenta os encargos de conformidade e os danos potenciais caso algo corra mal.
A conservação é outro ponto fraco. Por vezes, as equipas guardam registos de pagamento durante anos «por precaução», mesmo depois de já não serem necessários para a atividade. O RGPD exige uma regra de conservação concreta, não uma resposta vaga. Se o prazo para pedir um reembolso termina ao fim de 30 dias, isso pode servir de referência para definir a conservação. Se um arquivo de faturas tiver de ser mantido por razões contabilísticas, indique-o e mantenha-o separado dos restantes dados.
As transferências internacionais exigem uma análise cuidadosa. Um cliente em França, um servidor de gateway em Singapura e uma equipa de apoio nos Estados Unidos podem criar uma cadeia de transferências que exige garantias. Podem ser necessárias cláusulas contratuais-tipo, avaliações das transferências e uma análise prévia dos fornecedores. É indispensável mapear os percursos dos dados.
A imutabilidade dos registos na blockchain cria um problema diferente. Depois de os dados serem registados na cadeia, muitas vezes é impossível apagá-los pelos meios habituais. Isto não é um pormenor técnico. É a tensão central entre a legislação de privacidade e a conceção do sistema. As empresas que registam nomes ou endereços de e-mail na blockchain assumem um risco deliberado.
Há também a questão dos metadados excessivamente expostos. Um histórico público de transações pode permitir que terceiros deduzam os hábitos dos clientes, o valor das encomendas e os respetivos horários. Um concorrente não precisa de ter acesso a um perfil completo do cliente para aprender muito com transferências repetidas. Uma blockchain sem nomes ainda pode revelar padrões.
Outro risco é a alteração gradual das práticas dos fornecedores. Um prestador pode mudar as práticas de registo, adicionar uma nova ferramenta de análise ou alargar as regras antifraude sem avisar todos os comerciantes de imediato. Por isso, uma análise de privacidade não deve ser feita uma única vez. Se mais tarde precisar de corrigir um problema de integração de pagamentos em criptomoedas, a revisão do fornecedor deve continuar a fazer parte das notas de resposta ao incidente.
Medidas de conformidade para comerciantes e prestadores de pagamentos
Comece pela minimização dos dados. Recolha apenas o que for necessário para a transação, o reembolso ou o registo legal. Se um campo for opcional, assinale-o como opcional. Se não precisar do endereço da carteira até à confirmação do pagamento, não o peça no momento da criação da conta. Parece óbvio e, ainda assim, continua a acontecer todas as semanas.
Os avisos de privacidade devem ser específicos. Devem identificar as categorias de dados, as finalidades do tratamento, os períodos de conservação, os destinatários e os países para onde os dados são transferidos. Uma frase genérica como «respeitamos a sua privacidade» não basta. Se os clientes puderem pagar em criptomoedas, o aviso deve dizê-lo claramente e explicar que dados da transação são guardados. Esta transparência é uma parte essencial da proteção de dados em pagamentos com criptomoedas.
Os controlos de acesso são importantes porque os registos de pagamento muitas vezes combinam dados comerciais e pessoais. Só os funcionários que precisem de aceder a dados de faturas, pedidos de apoio ou documentos KYC devem poder consultá-los. Utilize acessos baseados em funções, contas de administrador separadas e registos que indiquem quem acedeu a quê e quando. Se um único agente de apoio puder ver tudo, o sistema é demasiado aberto.
As políticas de conservação devem indicar prazos em dias ou meses, não basear-se em palpites. Crie uma categoria para registos contabilísticos, outra para registos antifraude e outra para pedidos de apoio. Depois, defina os passos de eliminação ou anonimização para cada uma. Se houver uma obrigação legal de conservação, registe essa exceção. Caso contrário, elimine os dados de acordo com o prazo previsto.
A gestão de fornecedores deve incluir contratos, verificações de segurança e análises dos fluxos de dados. Pergunte a cada prestador onde os dados são armazenados, que subcontratantes utiliza e como comunica as violações de dados. A encriptação deve proteger os dados em trânsito e em repouso, e a gestão de chaves não deve ser tratada como algo secundário. Guardar uma cópia de um ficheiro de chaves numa pasta partilhada não é uma estratégia.
Blockchain, transparência na cadeia e direito ao apagamento
A blockchain dificulta os pedidos relacionados com a privacidade porque os registos podem ser permanentes. Em determinadas situações, o RGPD confere às pessoas o direito de acesso, retificação e apagamento, mas uma blockchain pública não tem um botão para eliminar dados. Essa tensão não desaparece só porque uma empresa chama ao pagamento «descentralizado».
Em geral, o que pode ser removido são os dados fora da cadeia. Um comerciante pode eliminar um perfil de cliente, um pedido de apoio ou um registo de fatura guardado na sua própria base de dados, sem prejuízo das regras de conservação. Nem sempre é possível apagar uma entrada da cadeia, mas muitas vezes é possível eliminar o registo associado na base de dados. Na prática, essa diferença é importante.
As decisões de conceção ajudam. Sempre que possível, mantenha os dados pessoais fora da cadeia. Guarde apenas uma referência tokenizada ou um apontador para a transação na blockchain e mantenha os dados de identificação numa base de dados controlada. Se tiver de usar um registo público, evite incluir nomes, endereços de e-mail ou moradas nas notas das transações. Um código de referência é mais seguro do que uma etiqueta legível por qualquer pessoa.
Algumas equipas perguntam se o hashing resolve o problema. Não por si só. Um hash ainda pode ser considerado dado pessoal se puder ser associado a uma pessoa ou se os dados originais estiverem disponíveis noutro local. A pseudonimização é útil, mas não é uma solução mágica. A lei tem em conta a possibilidade de reidentificação.
Há aqui uma solução de compromisso prática. Utilize armazenamento fora da cadeia para a identidade dos clientes e a gestão de pagamentos, e reserve a blockchain para a liquidação. Assim, o registo público mantém-se enxuto. Também é mais fácil satisfazer os pedidos de apagamento relativos aos dados que controla — normalmente, é aí que se concentra o trabalho operacional.
Lista prática para gerir pagamentos em criptomoedas em conformidade com o RGPD
Comece por rever a política de privacidade. Verifique se menciona dados de pagamentos em criptomoedas, endereços de carteiras, verificações antifraude, KYC, transferências internacionais e prazos de conservação. Se esses elementos estiverem em falta, a política está incompleta. Uma página de texto cuidado vale mais do que três páginas de garantias vagas.
Mapeie todos os campos das transações. Para cada campo, indique a origem, a finalidade, o destinatário e o local de armazenamento. Faça-o para os processos de pagamento, reembolsos, pedidos de apoio, exportações contabilísticas e avaliação de riscos. Se o mesmo campo aparecer em 4 sistemas, todos os 4 têm de ser revistos.
Confirme por escrito as funções de responsável pelo tratamento e de subcontratante. Certifique-se de que o contrato com o comerciante, o contrato com o gateway e a lista de eventuais subcontratantes correspondem ao fluxo real dos dados. Se um fornecedor alterar o serviço, atualize o registo. Uma cláusula desatualizada pode induzir uma auditoria em erro.
Analise em conjunto as transferências internacionais e as bases legais. Um fluxo de pagamentos pode ser lícito com base na necessidade contratual e, ainda assim, precisar de um mecanismo de transferência para alojamento ou acesso ao apoio no estrangeiro. São questões distintas. Trate-as como tal.
Forme as equipas de apoio e de finanças para saberem como agir perante incidentes. Uma fatura divulgada, um reembolso enviado por engano para a carteira errada ou uma captura de ecrã enviada por e-mail podem constituir um incidente de privacidade. Os funcionários devem saber quem avisar na primeira hora, que provas preservar e quando deixar de enviar ficheiros por e-mail. Um processo claro de escalonamento faz diferença numa tarde de sexta-feira.
Defina uma data para a revisão. Os controlos de privacidade ficam rapidamente desatualizados, sobretudo quando um gateway acrescenta novos registos, novas verificações antifraude ou uma nova região de armazenamento. As revisões trimestrais são preferíveis a uma correria anual. Os riscos não esperam pelo calendário.
Para saber como cumprir o RGPD ao aceitar Bitcoin, comece por conseguir explicar cada etapa do pagamento, em linguagem simples, a um cliente, a um advogado e a um auditor sem alterar a história. Se não for possível, o fluxo de pagamentos em criptomoedas ainda não está pronto.
Comments