GDPR and IBAN Data: How to Handle Bank Account Numbers Compliantly

IBAN numbers are personal data under the GDPR. For individuals, an IBAN directly identifies a financial account and, by extension, the account holder — making it personal data under Article 4(1) of the General Data Protection Regulation. For businesses, IBANs associated with sole traders or named individuals also qualify. This means that any organization that collects, stores, processes, or transmits IBANs for EU or UK-based individuals must comply with GDPR obligations: lawful basis, data minimisation, storage limitation, security, and the rights of data subjects. This guide explains what those obligations mean in practice for payment operations, finance teams, and developers building IBAN-processing applications.

Is an IBAN Always Personal Data Under the GDPR?

The GDPR defines personal data as any information relating to an identified or identifiable natural person. An IBAN held for an individual's personal account directly identifies that person's bank account and, combined with other information in a payment record (name, payment reference, amount), is clearly personal data.

For corporate bank accounts — where the account holder is a limited company, not an individual — the IBAN does not relate to a natural person and falls outside the GDPR's scope in principle. However, in practice many corporate accounts are associated with sole traders, partnerships, or small businesses where the IBAN is functionally an individual's account. Similarly, the named account signatories on a corporate account are natural persons, and their associated data may be implicated. When in doubt, treat the IBAN as personal data.

The UK GDPR (retained post-Brexit) applies the same test and reaches the same conclusion. The ICO's guidance explicitly identifies bank account numbers and payment card details as categories of data that require careful handling, though they do not rise to the level of "special category" data (which covers health, biometric, and racial data, among others).

What Lawful Basis Applies to Processing IBANs in Payment Operations?

For most payment processing scenarios, the lawful basis for processing an IBAN is one of three options under Article 6 GDPR:

Contract (Article 6(1)(b)): Processing the IBAN is necessary to perform a contract with the data subject — for example, to pay a supplier, to transfer wages to an employee, or to process a customer refund. This is the most commonly applicable basis for B2B payment operations.

Legal obligation (Article 6(1)(c)): Processing is necessary to comply with a legal obligation — for example, AML record-keeping requirements, payroll tax reporting, or sanctions screening obligations. Where you are required by law to record and retain payment details, this basis covers the retention period mandated by law.

Legitimate interests (Article 6(1)(f)): Processing is necessary for the legitimate interests of the controller, provided those interests are not overridden by the rights and interests of the data subject. Fraud prevention, payment audit trails, and operational security are typically accepted as legitimate interests — but a legitimate interests assessment (LIA) should be documented for each processing activity.

Consent is generally not the appropriate basis for processing IBANs in a payment context. Consent must be freely given and withdrawable at any time — which is incompatible with payment operations where the IBAN must be processed to complete the transaction regardless of whether the data subject later withdraws consent.

How Long Can You Retain IBAN Data?

The storage limitation principle (Article 5(1)(e)) requires that personal data be kept no longer than necessary for the purpose for which it was collected. For IBAN data in payment contexts, retention is governed by the interplay of GDPR minimisation principles and mandatory legal retention periods:

• AML / financial records: EU AMLD5 and UK MLR 2017 require retention of customer due diligence records and transaction records for five years from the end of the business relationship. This creates a floor — IBAN data associated with those records must be retained for at least five years, regardless of GDPR minimisation preferences.
• Tax records: Most EU member states require retention of accounting records, including payment records, for seven to ten years (Germany: 10 years; UK: 6 years for companies, 5 for self-employed). Payment records containing IBANs fall within scope.
• Employment payroll: Payroll records containing employee IBANs are typically retained for the duration mandated by employment and tax law — commonly 6–7 years — rather than indefinitely.

Once the applicable retention period expires, IBAN data should be securely deleted or anonymised. Anonymisation — removing or irreversibly altering data so that the individual can no longer be identified — takes data outside the scope of GDPR. Pseudonymisation (for example, storing a hash of the IBAN rather than the IBAN itself) reduces risk but does not remove GDPR obligations entirely, because pseudonymised data can potentially be re-identified.

What Security Measures Are Required for IBAN Data?

Article 32 GDPR requires "appropriate technical and organisational measures" to protect personal data against unauthorized access, loss, or disclosure. For IBAN data, appropriate measures typically include:

• Encryption at rest and in transit. IBAN data stored in databases should be encrypted using AES-256 or equivalent. All transmission of IBAN data over networks should use TLS 1.2 or higher with current cipher suites.
• Access controls. Only personnel with a demonstrable need should have access to systems containing IBAN data. Role-based access control (RBAC), with audit logging of every access event, is standard practice.
• Data minimisation in processing systems. Where possible, store the output of IBAN validation (bank name, BIC, country) rather than the full IBAN string. This approach is supported by services like the ibanchecker.cash API, which performs all validation in memory and returns structured results without retaining the IBAN — allowing you to record only the information you need for your legitimate purpose.
• Tokenisation for payment platforms. Payment platforms that need to reference an IBAN across multiple transactions can tokenise the IBAN — replacing it with a non-sensitive token that maps to the real IBAN in a secure, access-controlled vault. The token can be used in payment instructions and audit records without exposing the IBAN itself.
• Breach detection and notification. Article 33 requires notification of a personal data breach to the supervisory authority within 72 hours of becoming aware of it. A breach involving IBAN data — even if the IBANs are not combined with other identifiers — is a reportable breach if it risks individuals' rights and freedoms. Maintain an incident response plan that covers IBAN data breaches specifically.

What Are the Rights of Data Subjects Regarding Their IBAN Data?

Individuals whose IBANs you process have GDPR rights that apply to that data:

Right of access (Article 15): An individual can request confirmation of whether you process their IBAN, a copy of that data, and information about how it is used, retained, and shared. You must respond within one month.

Right to rectification (Article 16): An individual can request correction of an inaccurate IBAN. This is particularly relevant for employees whose payroll IBAN changes.

Right to erasure (Article 17): An individual can request deletion of their IBAN data where it is no longer necessary for the purpose for which it was collected, or where the lawful basis (e.g. consent) has been withdrawn. However, this right does not override legal retention obligations — if you are required by law to retain a payment record for seven years, you cannot delete it early at the individual's request. You should inform the individual of this conflict and the applicable legal basis for continued retention.

Right to data portability (Article 20): Where the lawful basis is consent or contract, individuals have the right to receive their personal data in a structured, commonly used, machine-readable format. For IBAN data in employment or supplier contexts, this typically means providing the individual's bank details in a structured format on request.

How Should Developers Build GDPR-Compliant IBAN Processing?

Developers building applications that process IBANs should apply privacy by design principles from the outset, rather than retrofitting compliance after the fact:

• Validate without storing. Where you only need to confirm that an IBAN is valid, use the ibanchecker.cash API to validate in real time and store only the result (valid/invalid, bank name, BIC). Do not store the raw IBAN if you do not need it for downstream processing.
• Log validation events without IBAN strings. If you log IBAN validation events for audit or debugging purposes, log a hash of the IBAN rather than the IBAN itself. A SHA-256 hash with a per-tenant salt provides a unique identifier for the IBAN without exposing it in log files.
• Implement retention policies in the database layer. Set automated deletion or anonymisation jobs for IBAN records that have passed their retention period. Hard-code the retention periods in configuration, not in application code, so they can be updated without a deployment.
• Document the data flow. Maintain a Record of Processing Activities (RoPA) as required by Article 30 GDPR that includes IBAN processing activities — what data is collected, from whom, on what lawful basis, where it is stored, how long it is retained, and who it is shared with (including any third-party payment processors or validation APIs).

The ibanchecker.cash platform is designed with data minimisation as a core principle: all IBAN validation is performed in memory, no IBAN data is logged or retained on ibanchecker.cash infrastructure, and the API returns only the structured result needed for compliance and fraud prevention purposes.

Last updated: June 2026