Data Erasure Procedure
Introduction: This policy outlines the step-by-step process followed by Rintral for handling data erasure requests from our users, ensuring compliance with GDPR, and protecting individuals' rights. It provides clear guidance on the procedures for verifying, processing, and documenting each request, while adhering to legal obligations and data protection best practices.
Legal Grounds for Retaining KYC Data: Under Article 17(3)(b), we can refuse a data subject’s request for erasure when the processing is necessary to comply with a legal obligation that requires retaining data. KYC records typically fall under anti-money laundering (AML) laws, financial regulations, or other statutory obligations that require companies to retain records for a specified period.
Pseudonymization as a Solution: One option to reconcile the need to retain KYC data with GDPR’s right to erasure is to pseudonymize the data. Article 4(5) of GDPR defines pseudonymization as processing personal data in such a way that it can no longer be attributed to a specific data subject without additional information, which must be stored separately and subject to technical and organizational measures to ensure non-attribution.
1. Receive and Authenticate the Request (For Customer Support Team)
• Ensure the request is from the actual customer or a legally authorized individual.
• Require identity verification (e.g., a copy of ID) before proceeding to avoid fraudulent requests.
• Communicate the request to the DPO, log the request date on the Excel file, and verify it falls under the legal guidelines of data erasure rights.
2. Review Legal Obligations and Data Retention Requirements
• Retain legally required KYC data such as transaction histories, but pseudonymize sensitive personal data where possible using encryption and hashing techniques.
• If certain data must be retained for legal purposes, inform the customer and explain why the data must be pseudonymized rather than erased.
3. Identify Data Categories Eligible for Erasure or Pseudonymization
• Personal Identification Information (PII): Full name, date of birth, national ID numbers, etc., as part of the KYC data will be pseudonymized.
• Contact Information: Emails, phone numbers, and physical addresses as part of the KYC data will be pseudonymized as required for legal reasons.
• Account Information: Username, account ID, and password. Remove it. If it needs to remain for future audit purposes, it will be pseudonymized.
• Wallet Addresses (Cryptocurrency Data): Remove any user-linked wallet addresses. However, the blockchain ledger itself cannot be altered or erased. Any private keys, if stored, should be deleted securely. Blockchain transactions are immutable and cannot be altered or deleted. However, any personal data tied to blockchain transactions (such as identifiable metadata) can and must be anonymized or pseudonymized where possible. This ensures that while the transaction itself remains permanent on the blockchain, the associated personal information does not violate privacy laws.
• Financial Information: The data cannot be erased due to regulatory requirements and will be pseudonymized using encryption and hashing techniques (explained below). For financial transactions (both direct and indirect) that must be retained (pseudonymized) for compliance purposes (auditing, AML). That means completely removing or obscuring any identifiable personal information related to the customer, ensuring that the transactions cannot be traced back to the individual.
Direct Financial Information: | Indirect Financial Information: |
Credit/Debit Card Numbers | Transaction histories |
Bank Account
Numbers | Payment dates, amounts, and vendors |
IBAN, SWIFT codes | |
Linked Payment Methods (e.g., PayPal, Crypto Wallets) |
• Remove Unnecessary Financial Data:
Stored Payment Details: | Direct Bank Account
Information: |
Credit card numbers, CVV/CVC codes | Bank account numbers (e.g., local account numbers or international IBANs). |
Card expiration dates | Bank routing numbers (e.g., SWIFT/BIC codes) |
Cardholder's name | Account holder’s name linked to the bank account. |
Stored tokens or references to the credit card (if tokenization is used and the token is no longer needed) | Linked payment
methods (e.g., PayPal
or cryptocurrency wallet addresses) |
Billing address associated with the credit or debit card | Bank account details used for recurring payments (e.g., Direct Debit mandates |
4. Pseudonymization Process
• Pseudonymization Method: For data that cannot be deleted due to legal obligations or compliance requirements, where the data controller may need to re-identify the individual (e.g., KYC records), we will implement Reversible Pseudonymization (Encryption). This method enables the data to be restored to its original form, which is essential when access to the data is still required for regulatory audits, legal inquiries, or operational needs.
5. AES-256 Encryption (for reversible data pseudonymization):
• Encrypt sensitive data using the AES-256 encryption algorithm, ensuring that data can only be decrypted with a unique encryption key.
• Example (Python using PyCryptodome):
6. Store Pseudonymized Data Securely
• Using reversible encryption, we have to store the mapping between pseudonyms and original data in a separate encrypted database.
• Only authorized personnel with legal clearance can access the mapping table, ensuring high- level security for re-identification. The following bullet list focuses on who should have access to the mapping table and sensitive data:
a) Data Protection Officer (DPO): Oversees and manages access to pseudonymized data for GDPR compliance purposes.
b) Compliance Officers: Responsible for ensuring that the company meets legal and regulatory obligations (e.g., KYC/AML requirements), with access granted only for audit or reporting purposes.
c) Legal Team: Access may be required for handling legal claims, disputes, or regulatory inquiries where re-identification of individuals is necessary.
d) IT Security Team: Responsible for maintaining encryption keys, pseudonymization infrastructure, and security controls, but access to personal data should be limited.
e) Auditors (Internal or External): Granted access in the event of financial or regulatory audits, strictly for reviewing compliance with legal retention requirements.
7. Notify Third-Party Processors
• As per our data protection policy, we are already aware that customer data are shared with third-party processors (e.g., marketing platforms or payment processors), We shall notify them to either erase the data or apply the same pseudonymization techniques.
• Require confirmation from third parties that the pseudonymization or data deletion has been completed.
8. Record the Erasure and Pseudonymization Process
• Keep a detailed log of both the data that was erased and the data that was pseudonymized, along with the method used, and the date of completion.
• Document reasons for pseudonymization when erasure is not possible (e.g., legal retention requirements) and maintain a record of pseudonymization activities as expressed in Art. 6 of Rintral RAT (Record of Processing Activities).
9. Confirm Erasure and Pseudonymization with the Customer
• Once the erasure or pseudonymization process has been completed, confirm the actions taken with the customer.
• If certain data could not be erased due to legal obligations, provide clear explanations, and describe how the data has been pseudonymized.
10. Specific Pseudonymization Checklist:
Data Type | Action | Notes | |
Personal Information (Name, ID) | Encrypt |
| |
Contact Information (Email, Phone) | Erase | Pseudonymize or Delete or pseudonymize if required for legal
reasons. | |
Financial Data (Bank Info) | Encrypt | Apply AES-256 encryption to sensitive financial data if retention is necessary. | |
Verification Documents (KYC) | Encrypt | Encrypt sensitive KYC data, ensuring no direct re- identification. | |
Communication History | Erase | Delete customer interaction logs unless retention is required for auditing. |
Related Articles
Data Privacy Policy
1. Introduction This Data Privacy Policy outlines how Rintral Trading S.L.U., trading as Nebeus, collects, uses, discloses, and safeguards your personal data across all our websites, mobile applications, service platforms, and related operational ...Fiat Republic Linked Business- Terms & Conditions
This document (“T&Cs”) sets out the terms and conditions on which one or more entities within the Fiat Republic group (“Fiat Republic”, “we”, “us” or “our”) provide access to one or more e-money accounts and related payment services (the “Services”) ...Nebeus Linked Business Accounts – Terms of Use
1. Introduction and Scope These Linked Business Accounts Terms and Conditions (“Terms”) govern the use of the Linked Business service (“Linked Business Accounts”) made available via the Nebeus Platform (https://nebeus.com) to eligible business ...Closure Policy
1. Introduction This Closing Account Policy outlines the procedures and conditions under which customers can close their accounts with Nebeus. This policy is compliant with Spanish law and aims to ensure a transparent and seamless account closure ...Terms of Use
1. Introduction and Scope In compliance with Article 10 of Spanish Law 34/2002, of 11 July, on Information Society Services and Electronic Commerce (LSSI), the following information is provided: The Platform is operated by Rintral Trading, S.L.U., ...