Customer data safeguards you can show a regulator, a bank and an auditor

The article sets no product list or configuration. The level of security follows the state of the art, implementation costs, the nature of the processing and the risk to people, above all from accidental or unlawful destruction, loss, alteration or unauthorised disclosure (Art. 32(2)).

What that means in a fintech

• Encryption of the KYC archive, customer databases and backups, with keys managed apart from the data.
• Access: least privilege, MFA, a log of access to customer files, and revocation on departure.
• Restore: backups separated from the main network and accounts, and a restore test with a recorded result.
• Testing: regular testing and review of the measures, with dates and conclusions.

Adherence to an approved code of conduct or certification under Articles 40 and 42 can be one element of demonstrating compliance (Art. 32(3)). It sits alongside the measures themselves, which are still examined.

For a group with entities in several jurisdictions we build one map of measures and mark which measure meets which requirement. The differences usually lie in documents and notice deadlines, while the measures stay the same.

KYC data retention under GDPR and PDPA

GDPR allows identifiable data to be kept no longer than the purpose requires (Art. 5(1)(e)). The retention period for KYC records comes from the anti-money laundering law of the country that licensed you. PDPA expressly requires an organisation to stop retaining personal data, or anonymise it, once the purpose is no longer served and retention is not needed for legal or business reasons (s. 25).

We handle the technical side: where the archive lives, who can open it, how records are deleted when the period ends and how the log shows it. Your compliance team sets the period per document category; the AML link is handled by our compliance practice.

A fintech has many processors: KYC vendor, cloud hosting, CRM, payment processing, outsourced support. We check that every contract carries the security obligation, that the vendor can evidence it and that your documents describe the measures consistently.

One TOMs document, several uses

A single description of technical and organisational measures, tied to real settings, serves as the annex to processing agreements, the records of processing section, the basis for bank questionnaire answers and material for a licence application. We write it from actual configurations and update it after each fix.

The controller carries out the DPIA, seeking the DPO's advice where one is designated. We prepare its technical part: system and data flow descriptions, security risks and the measures that reduce them. The DPO and your lawyer assess the legal side, including the lawful basis and whether a DPIA is required in your case.

Before a new product goes live, for example online onboarding with face matching, we review the architecture: which data is collected, where it is stored, who sees it and how it is deleted. If a breach does happen, see our incident response page.