Resposta curta: a conformidade com o RGPD depende da sua função no tratamento dos dados, não do modelo de custódia
Uma configuração sem custódia não está dispensada de cumprir as regras. O RGPD considera os dados pessoais, a finalidade do tratamento e a função de cada parte. Se um gateway ou comerciante tratar nomes, emails, rastos de carteiras, mensagens de apoio ou até a impressão digital de um dispositivo, o RGPD pode aplicar-se.
A pergunta «um gateway de pagamento de criptomoedas sem custódia está em conformidade com o RGPD?» parece exigir uma resposta de sim ou não, mas a lei é mais complexa. Um gateway pode não guardar fundos dos clientes e, ainda assim, tratar dados pessoais a cada instante em que gere o checkout, os registos, as verificações antifraude ou o apoio ao cliente. O modelo de custódia é importante para a segurança, mas não determina, por si só, a conformidade com o RGPD.
Imagine um checkout simples. Um cliente paga em USDC e o sistema regista o número da encomenda, o endereço da carteira, a data e hora e um endereço IP. Isto já basta para justificar uma análise ao abrigo do RGPD se for possível associar o pagamento a uma pessoa identificável — o que muitas vezes acontece através de faturas, dados da conta ou registos de apoio ao cliente.
Para os comerciantes, a questão prática é mais específica: quem decide por que motivo os dados são recolhidos e quem controla os meios utilizados? A resposta determina se o comerciante é responsável pelo tratamento, se o gateway é subcontratante ou se ambas as partes partilham responsabilidades. Identificar o responsável pelo tratamento de dados em gateways de pagamento exige analisar cada fluxo de trabalho, pois raramente uma única designação se aplica a todos.
Que partes são normalmente responsáveis pelo tratamento, subcontratantes ou corresponsáveis
Num checkout de criptomoedas típico, o comerciante é geralmente o responsável pelo tratamento dos dados dos clientes associados à venda. É o comerciante que decide o que vende, o que guarda e durante quanto tempo mantém o registo da compra no sistema de encomendas. Só isso já deixa uma pegada clara no âmbito do RGPD.
Um fornecedor de gateways pode atuar como subcontratante se tratar os dados apenas segundo as instruções do comerciante. É comum quando o gateway apresenta o checkout, cria instruções de pagamento e envia atualizações sobre o estado do pagamento. Se o fornecedor também decidir reutilizar os dados para analisar o produto, calcular riscos ou criar a sua própria base de dados de clientes, a sua função pode mudar. Nesse caso, o gateway pode passar a ser responsável pelo tratamento para essas finalidades distintas.
As infraestruturas de carteiras, as ferramentas de indexação da blockchain, os fornecedores de análise e os serviços de alojamento costumam operar em segundo plano como subcontratantes ou subcontratantes ulteriores, mas tudo depende dos factos. Um operador de nós que disponibilize apenas infraestrutura técnica pode ter uma exposição limitada. Já um serviço que correlacione transações de vários comerciantes pode passar a ser responsável pelo tratamento ou corresponsável.
A corresponsabilidade pelo tratamento não é rara. Surge quando o comerciante e o gateway decidem ambos sobre partes da mesma operação de tratamento, como regras partilhadas de análise antifraude ou um checkout com marca conjunta. Nesse caso, ambas as partes precisam de um acordo escrito que explique quem trata dos avisos, dos pedidos de acesso e dos incidentes de segurança. Há três palavras que importam: quem faz o quê.
As equipas dos comerciantes muitas vezes não se apercebem da função das ferramentas de apoio ao cliente. Um sistema de assistência que guarda capturas de ecrã dos clientes, emails sobre reembolsos e imagens de carteiras não serve «apenas para apoio». Trata dados pessoais, e o contrato com o fornecedor deve dizê-lo. O mesmo se aplica aos sistemas de gestão de pedidos de assistência e às ferramentas de CRM.
Que dados pessoais um gateway sem custódia ainda pode tratar
Sem custódia não significa sem dados. Um gateway pode tratar endereços IP e de email, endereços de carteiras, dados de dispositivos, IDs de transação, o idioma do navegador, referências de faturas e notas sobre reembolsos. Cada elemento pode tornar-se um dado pessoal quando permite identificar alguém, direta ou indiretamente.
Os endereços de carteiras exigem especial atenção. Isoladamente, podem parecer sequências aleatórias. Na prática, é possível associar um endereço a um cliente através de uma conta, uma fatura, uma conversa com o apoio ao cliente, uma etiqueta de envio ou um ficheiro de KYC. Um identificador pode revelar muito mais do que parece.
Os registos são outra armadilha. Um registo de servidor com 90 dias pode incluir endereços IP, cabeçalhos de pedidos, padrões temporais e mensagens de erro. Se for possível pesquisar esses registos por email ou ID de encomenda, o sistema torna-se um mapa da atividade dos clientes. Isso basta para levantar questões ao abrigo do RGPD, mesmo que os fundos nunca passem pelo balanço do gateway.
Os pedidos de apoio ao cliente podem conter dados mais sensíveis do que os do checkout. Um cliente pode enviar uma captura de ecrã da carteira, o hash de uma transação falhada ou uma morada associada a um problema de entrega. Esse pequeno conjunto de informações pode revelar hábitos de compra, localização e titularidade da conta. Para o RGPD, é irrelevante que os dados tenham chegado através de uma «pergunta simples».
As faturas e os recibos também são importantes. Podem incluir nomes, moradas de faturação, números de IVA, números de identificação fiscal ou detalhes da encomenda. Se o comerciante usar a mesma referência de fatura na blockchain e nos sistemas internos, a ligação fica mais forte. Uma transação na blockchain pode ser pseudónima e, ainda assim, estar associada a um cliente identificável.
As bases jurídicas do RGPD mais relevantes para os pagamentos em criptomoedas
Para a maioria dos comerciantes, a execução do contrato é a primeira base jurídica a considerar. Se o cliente estiver a pagar por bens ou serviços, o gateway precisa de alguns dados para processar a encomenda e confirmar o estado do pagamento. Muitas vezes, esse tratamento é necessário para executar o contrato.
A obrigação legal vem a seguir. As regras fiscais e contabilísticas, as verificações antifraude e os deveres de conservação podem exigir que certos dados sejam guardados durante um período determinado. O prazo de conservação exato depende do país e do tipo de registo, pelo que um advogado ou encarregado da proteção de dados poderá ter de confirmar a regra aplicável.
O interesse legítimo também pode ser uma base adequada para alguns tratamentos, sobretudo a prevenção de fraude, a integridade do serviço, a monitorização de abusos e a análise limitada. Esta base não se aplica automaticamente. O teste de ponderação deve avaliar se o cliente poderia razoavelmente esperar esse tratamento, se os dados são limitados e se o comerciante consegue alcançar o mesmo objetivo de forma menos intrusiva.
O consentimento raramente é a opção certa para o processamento essencial dos pagamentos. Se o pagamento não puder ser processado sem determinados dados, pedir consentimento pode criar uma falsa escolha. Ainda assim, o consentimento pode ser adequado para marketing opcional, análises adicionais ou monitorização através de cookies, mas não para o simples ato de receber um pagamento. Esta distinção é importante.
Uma regra prática pode ajudar: sempre que possível, baseie os dados de pagamento na execução do contrato ou numa obrigação legal e reserve o consentimento para funcionalidades verdadeiramente opcionais. Esta abordagem reduz os obstáculos e torna o checkout mais transparente. Evita também um aviso de consentimento confuso que tenta abranger demasiadas coisas.
Uma análise de RGPD para pagamentos com criptomoedas deve começar por mapear os dados, as finalidades e as funções de cada parte, antes de escolher a base jurídica aplicável a cada atividade.
Se estiver a mapear o fluxo do lado do comerciante, o guia sobre gateways de pagamento de criptomoedas para comércio eletrónico pode ajudar com detalhes de implementação que afetam o tratamento dos dados, como as atualizações do estado da encomenda e a integração do checkout.
Minimização dos dados e proteção da privacidade desde a conceção nos fluxos de pagamento
A minimização dos dados é o ponto de partida mais simples. Recolha apenas o que o fluxo de pagamento realmente exige. Se for possível concluir a encomenda sem a data de nascimento, não a peça. Se bastar um email de faturação, não acrescente outro identificador. Pequenas decisões reduzem rapidamente os riscos.
Os registos devem ser reduzidos de forma deliberada. Guarde apenas os campos necessários para resolver problemas, garantir a segurança e tratar litígios. É difícil justificar um registo que conserve o histórico completo das carteiras, todos os endereços IP e todos os cabeçalhos de pedidos durante 12 meses, salvo se houver um motivo claro. Muitas vezes, um prazo de conservação mais curto é suficiente.
Sempre que possível, mantenha os dados de faturação separados dos dados da blockchain. O comerciante pode guardar o perfil do cliente num sistema e a referência da transação na blockchain noutro, ligando-os através de um token interno ou do ID da encomenda. Esta separação não elimina as obrigações ao abrigo do RGPD, mas reduz o impacto caso um sistema seja comprometido.
A proteção da privacidade desde a conceção não é apenas um slogan. Significa que o checkout predefinido deve evitar campos adicionais, notas públicas sobre transações e a apresentação desnecessária de metadados sensíveis. O cliente não deve ter de procurar uma opção escondida só para obter uma fatura simples. A privacidade deve estar assegurada desde o início.
Os limites de conservação devem ser definidos antes do lançamento, e não depois da primeira reclamação. Um email de apoio ao cliente enviado há seis meses pode continuar na caixa de entrada se ninguém tiver definido uma regra. O mesmo se aplica a exportações de análises, relatórios de pagamentos falhados e arquivos de webhooks. Apagar dados antigos dá trabalho, mas é mais simples do que explicar por que motivo continuaram guardados para sempre.
Se procura uma lista prática para testar estas decisões antes de começar a receber tráfego real, consulte como testar um pagamento em criptomoedas. É no ambiente de testes que se detetam mais facilmente as predefinições inadequadas.
Transferências internacionais de dados e considerações sobre alojamento
Uma infraestrutura transfronteiriça pode complicar rapidamente o cumprimento do RGPD. Se os nós, servidores, equipas de apoio ou sistemas de análise estiverem fora do EEE, o comerciante precisa de analisar as regras de transferência. Um fluxo de pagamento pode ser sem custódia e, ainda assim, transferir dados pessoais para os Estados Unidos, o Reino Unido ou outra região.
As transferências não são proibidas, mas exigem um mecanismo jurídico e uma avaliação do fornecedor. Podem ser aplicáveis cláusulas contratuais-tipo ou uma decisão de adequação, quando exista. Mas isso é apenas o começo. O comerciante também precisa de verificar o que o fornecedor realmente faz com os dados, e não apenas onde está localizado o servidor.
Os detalhes do alojamento são importantes, porque os sistemas de cópias de segurança podem estar num país diferente do da aplicação principal. O mesmo se aplica às ferramentas de monitorização, aos sistemas de registo de erros e às plataformas de apoio ao cliente. Alojar a página de checkout no EEE não resolve o problema se os registos forem copiados de hora a hora para um serviço externo de análise.
A diligência devida em relação aos fornecedores deve responder a três perguntas: onde são armazenados os dados, quem lhes pode aceder e que subcontratantes ulteriores estão envolvidos? As respostas devem ser fornecidas por escrito. A promessa de um comercial não chega.
O comerciante também deve verificar se a infraestrutura da blockchain é consultada através de um indexador externo, uma vez que estes podem recolher metadados de transações e registos de endereços IP. Este aspeto passa muitas vezes despercebido porque a própria blockchain parece descentralizada. Na maioria dos casos, o verdadeiro problema de transferência está no serviço que a liga à blockchain.
Política de privacidade, registos e acordos com subcontratantes que um comerciante deve ter
O aviso de privacidade é a porta de entrada. Deve explicar que dados são recolhidos e porquê, quem os recebe, durante quanto tempo são conservados e que direitos tem o cliente. Se o checkout incluir endereços de carteiras, identificadores de faturas e dados de contacto do apoio ao cliente, esses elementos devem ser identificados claramente.
Os registos das atividades de tratamento, ou RAT, são importantes até para equipas pequenas quando o tratamento já tem alguma complexidade. O registo deve indicar as categorias de dados, as finalidades, os destinatários, os prazos de conservação e os destinos das transferências. Sim, é burocracia. Mas também prova que alguém analisou o fluxo de ponta a ponta.
Os acordos com subcontratantes são indispensáveis quando um fornecedor atua segundo as instruções do comerciante. Um acordo de tratamento de dados deve abranger as medidas de segurança, os prazos para notificação de violações, a subcontratação ulterior, a eliminação dos dados após o fim do contrato e o apoio a auditorias. Se o gateway utilizar fornecedores externos de alojamento, análise ou envio de emails, esses subcontratantes ulteriores também devem ser identificados.
As regras de conservação devem ser explícitas. O comerciante deve saber durante quanto tempo são conservados os dados das faturas e os registos, bem como quando são eliminados os pagamentos falhados. Uma regra sem prazo é apenas uma intenção. E isso não chega para cumprir o RGPD.
Os procedimentos em caso de violação de dados devem estar na mesma pasta. Se forem expostos um endereço de carteira, um email ou uma base de dados de faturas, o comerciante precisa de um processo de triagem, de um responsável interno e de um calendário para comunicar o incidente. Os atrasos podem sair caros rapidamente quando há vários fornecedores envolvidos.
Lista prática para os comerciantes avaliarem um gateway
Comece por mapear as funções. Anote quem é responsável pelo tratamento, quem é subcontratante e em que situações pode haver corresponsabilidade. Se a resposta variar consoante a funcionalidade, registe-o também. Um único checkout pode envolver três funções jurídicas distintas, dependendo dos dados tratados.
Depois, peça um mapa dos dados. Que campos são armazenados? Quais ficam registados? Quais são enviados para sistemas de análise, apoio ao cliente ou alojamento? Se o fornecedor não conseguir responder numa reunião, isso é um sinal de alerta. Sistemas bem definidos deixam um rasto claro.
Em seguida, verifique os prazos de conservação e os processos de eliminação. Pergunte qual é o prazo predefinido para os registos, durante quanto tempo são conservados os dados das faturas e como são eliminados os dados de encomendas canceladas e pedidos de apoio ao cliente. Se o fornecedor disser «guardamos os dados enquanto forem necessários», peça prazos concretos. Sem prazos, não há controlo.
Analise a base jurídica de cada finalidade de tratamento. A confirmação do pagamento pode basear-se na execução do contrato, os registos fiscais numa obrigação legal e algumas atividades de monitorização no interesse legítimo. O marketing deve estar separado do checkout essencial. É melhor indicar uma finalidade por linha do que usar um parágrafo vago.
Confirme as garantias aplicáveis às transferências. Se os dados de apoio ao cliente, telemetria ou análise saírem do EEE, pergunte qual é o mecanismo de transferência e que países estão envolvidos. Não parta do princípio de que a resposta é igual para todos os serviços. Um comerciante que guarda registos na Alemanha pode ainda enviar dados de pedidos de apoio para outra região.
Antes do lançamento, peça o acordo de tratamento de dados, a lista de subcontratantes ulteriores, o procedimento em caso de violação e um projeto de aviso de privacidade. Se esses documentos não existirem, o comerciante não está preparado. Se o gateway tratar pedidos de apoio relacionados com transações sensíveis ou grandes volumes de dados de clientes, consulte um advogado ou encarregado da proteção de dados antes de assinar.
Para os comerciantes que planeiam faturação recorrente ou faturação a clientes, o artigo sobre gateways de pagamento de criptomoedas para freelancers é útil, porque os dados das faturas, a identidade dos clientes e os registos de pagamento muitas vezes se cruzam de formas que afetam as decisões relativas ao RGPD. A sobreposição parece pequena, até deixar de o ser.
Se o gateway for ligado a ferramentas de automatização, analise todas as aplicações a jusante. Um webhook que envie os detalhes da encomenda para um CRM pode disseminar rapidamente dados pessoais. Para ver um exemplo prático de integração, consulte como ligar o Payora ao Zapier. Um passo adicional pode envolver três novos subcontratantes.
Uma última verificação: pergunte ao fornecedor se consegue explicar, em termos simples, por que existe cada campo. Se a resposta for «porque sempre o recolhemos», pare por aí. Um gateway de pagamento de criptomoedas sem custódia pode cumprir bem o RGPD, mas só se o comerciante gerir as práticas de tratamento de dados com o mesmo cuidado que dedica ao próprio fluxo de pagamento. Ao escolher um gateway de criptomoedas sem custódia e RGPD em mente, confirme que a privacidade, a minimização e a transparência estão incorporadas no serviço desde o início.
Comments