Anonymising instead of erasing is an option the 2024 PDPC erasure notification gives banks and every other data controller when a customer asks for erasure. The bank must tell the customer, and the option is closed for data collected unlawfully. This article explains the PDPC Office's answer to the Thai Bankers' Association on backups, mapping tables and data other laws require banks to keep.
- When a customer asks for erasure, a bank may anonymise instead under Clause 3 paragraph 3 of the 2024 notification, but must tell the customer.
- Data collected unlawfully (Section 33(4)) must be erased or destroyed only. Clause 7 rules out anonymisation as a substitute.
- Replacing customer IDs while keeping a usable mapping table is only pseudonymisation. The data is still personal data.
- Backups that cannot be erased within 90 days must be put beyond use under the five criteria in Clause 4, then erased as soon as possible.
- A bank may rely on significant necessity under Clause 5, but it bears the burden of proof and must explain it to the requester.
Banks receive erasure requests all the time: from customers who closed their accounts, from people who applied for a loan but never signed, and from people who simply want the marketing to stop. The hard part is that one customer's data sits in the core system, the data warehouse, backup files and paper folders, and much of it must still be kept under other laws.
The Thai Bankers' Association therefore drafted a manual on erasure, destruction and anonymisation for its member institutions to adapt. Representatives of the relevant agencies met on 8 August 2025 and found the principles of the draft consistent with the law. The details, such as worked examples and how to classify data, were to be raised with the Office of the Personal Data Protection Committee (PDPC Office).
The Association sent four questions. The PDPC's advisory subcommittee on consultations replied, adding observations on the draft manual. We summarise that opinion in our own words. The text inside the law boxes is quoted word for word from the Personal Data Protection Act B.E. 2562 (2019) (PDPA) and the 2024 notification.
- What counts as a significant necessity under Clause 5 of the notification, so that the bank need not erase?
- What does the principle of putting data beyond use mean?
- How should erasure or anonymisation methods differ by the way data is stored?
- If erasing one person's data would affect other people's data in the same database, for example a row-based or column-based file, can the bank put the data beyond use instead?
Can a bank anonymise data instead of erasing it when a customer asks?
Yes, in the ordinary case. Clause 3, paragraph 3 of the PDPC Notification on Criteria for the Deletion or Destruction of Personal Data, or for Rendering Personal Data into Data by which the Data Subject Cannot Be Identified (2024) lets the data controller use another method under the notification even if the customer asked for only one. The controller must tell the customer.
In the case where the data subject exercises the right requiring the data controller to carry out only one of the following, namely deletion or destruction, or rendering the personal data into data by which the data subject cannot be identified, the data controller may carry out deletion or destruction, or the rendering of the personal data into data by which the data subject cannot be identified, by another method under this Notification, which may differ from what the data subject requested; in doing so, the data controller has a duty to notify the data subject who exercised the right thereof, except where the case falls under Clause 7.
The Association did not ask this directly, yet every erasure request forces the choice. Our reading: once data is anonymised to the standard in Clause 6, it falls outside the definition of personal data in Section 6 of the PDPA. The bank can then keep it for statistics or model testing, as long as it truly reaches that standard.
If the bank takes this route, Clause 8, paragraph 2 requires it to give the customer reasonable details of how the data was anonymised, unless the customer already knows. If the bank cannot act on the request at all, Clause 8, paragraph 3 requires it to tell the customer why.
Unlawfully collected data must be erased or destroyed
The anonymisation route closes when the customer asks for erasure because the data was collected, used or disclosed unlawfully under Section 33(4) of the PDPA. Clause 7 of the notification does not allow anonymisation as a substitute in that case.
the data controller must delete or destroy the personal data only, and may not instead render the personal data into data by which the data subject cannot be identified under Clause 6.
Our advice: if a bank is unsure whether a dataset was obtained lawfully, for instance a list from a partner with no record of a lawful basis, it should not anonymise the data to keep using it. If the case later turns out to fall under Section 33(4), the chosen method will not satisfy Clause 7.
What is the difference between erasure, destruction, anonymisation and putting data beyond use?
The difference is the legal result. Erasure or destruction leaves no data behind. Anonymisation leaves data that is no longer personal data. Pseudonymised data and data put beyond use are still personal data, with every duty that comes with it.
| Method | Is what remains still personal data? | When to use it | Source |
|---|---|---|---|
| Erasure or destruction | Nothing remains. Copies and backups must be covered, and recovery by any reasonably foreseeable means must be impossible | Any Section 33 request that is not exempt; the only option for unlawfully obtained data | Clause 3 paras 1–2 · Clause 7 |
| Anonymisation | No, if all direct identifiers are removed and the chance of indirect identification is sufficiently low | May replace erasure, with notice to the customer, except under Clause 7 | Clause 3 para 3 · Clause 6 · Clause 8 para 2 |
| Pseudonymisation | Yes, while a mapping table is kept in a form that can be accessed and used | A step in reducing indirect identifiers; cannot replace erasure | Section 6 · Clause 6(2) · subcommittee opinion |
| Putting data beyond use | Yes | A holding measure when erasure cannot be completed in time, such as data awaiting overwrite or held in backups | Clause 4 · subcommittee opinion |
Removing names but keeping a mapping table leaves personal data
The subcommittee added this point at the end of its opinion. Suppose a bank replaces customer numbers or codes in a dataset but keeps a mapping table, or similar data, in a form that can be accessed and used. The dataset can still be linked back to each customer, so the exercise is only pseudonymisation.
The data therefore remains personal data under the Section 6 definition read with Clause 6 of the notification. A bank that tells a customer the data has been anonymised while the mapping table is still usable has not complied with the request.
“Personal Data” means any information relating to a Person, which enables the identification of such Person, whether directly or indirectly, but not including the information of the deceased Persons in particular;
Direct identifiers go well beyond names and ID card numbers. Clause 6(1) of the notification lists ten of them, items (a) to (j). The one closest to banking is item (c).
(c) The number, figure, or code of a membership, customer, service recipient, or personnel record, as well as the number, figure, or code of any account, contract, or any other thing that is unique to a person.
Account numbers, loan contract numbers and customer codes must all go. Clause 6(2) then asks the bank to look at indirect identifiers, such as date of birth, age, job title, address or IP address, until the chance of identification is sufficiently low. That judgement must weigh the risk, motivation and capability of anyone who might try to re-identify the data.
This is the mapping-table situation the subcommittee described. It is only pseudonymisation, so the request has not been met.
Clause 6(1) is done, but Clause 6(2) is not. Several indirect identifiers together may point back to an individual.
Our reading: with no route back and the data aggregated, the chance of identification drops sharply. The bank should still record why it judged the risk sufficiently low.
This is a Section 33(4) case. Clause 7 of the notification does not allow anonymisation instead.
What if data sits in backups or linked records and cannot be erased in time?
The bank must lock it away from any use until it can be erased. Clause 3, paragraph 2 of the notification extends erasure to copies and backups. A bank cannot tell a customer the job is done while the data still sits on backup tapes or replica databases.
The action under paragraph one must be carried out so as to cover personal data that has been copied or backed up as well (if any), and it must be ensured that no person is able, by any means that may reasonably be anticipated, to recover the personal data or to cause such data to become capable once again of identifying the data subject, whether directly or indirectly.
The Association's fourth question went straight to this. If erasing one person's records would affect others in the same database, such as a row-based or column-based file, may the bank put the data beyond use instead? The subcommittee said yes, where there is a genuine technical or practical constraint, but only for as long as erasure is not yet possible.
The opinion places this principle in Clause 4 of the notification and gives two examples. One is electronic data left on storage devices while it waits to be overwritten. The other is backed-up data, on paper or in electronic files, that cannot be erased straight away for technical reasons.
the data controller must place such personal data in a form in which the collection, use, or disclosure of such personal data is difficult, until the action under Clause 3 has been completed
While it waits, the bank needs organisational and technical measures, plus physical measures where necessary, that achieve all five results in Clause 4(1) to (5). In working terms:
- Neither the bank nor any processor involved intends to access, use or disclose the data again, even though it still exists.
- The data cannot be used to serve the customer or to make any decision about them. Our example: it must not feed a credit scoring model or a sales list.
- No one can access, use or disclose the data.
- Security measures match the level of risk.
- The data is erased, destroyed or anonymised without delay as soon as that becomes possible.
How far can a bank refuse erasure because other laws require it to keep data?
Only for the part covered by an exemption in Section 33, paragraph 2, or by a significant necessity under Clause 5 of the notification, and the bank must prove it. For a bank, the closest exemptions are retention to comply with the law and use to establish, exercise or defend legal claims.
Paragraph one shall not apply to the extent that such Personal Data retention is necessary for the purpose of freedom of expression, the purpose under section 24 (1) or (4) or section 26(5) (a) or (b), the purpose of establishment, compliance or exercise of legal claims, or defense of legal claims, or the purpose for compliance with the law.
The subcommittee gave examples of data kept to comply with other laws: accounting duties for audit, the Revenue Code or tax laws, the anti-money laundering law, the Bank of Thailand law and the law on financial institution businesses. Erasing such data could leave records incomplete, expose the bank to liability or leave it without evidence for a legal claim.
The opinion does not say how many years each law requires. Those periods must come from the laws themselves and the regulators' rules, and belong in the bank's retention schedule. Anything beyond that period or beyond what is needed must still be erased. For building a schedule that survives an audit, see our article on defensible retention schedules.
A Clause 5 significant necessity must pass a proportionality test
The provisions of Clause 3 shall not apply to personal data that cannot be deleted or destroyed, or rendered into data by which the data subject cannot be identified, by reason of significant necessity — for example, where such deletion or destruction, or the rendering of the personal data into data by which the data subject cannot be identified, may adversely affect the personal data rights or the interests of other persons. In such case, the data controller has a duty to notify the data subject who exercised the right, together with an explanation of, or a demonstration of, such significant necessity to the data subject.
The subcommittee explained that the necessity may be legal, social or technical. Technical examples include linked financial records, or backups where erasure would damage other data or the working of the system. The reason must still be weighed for proportionality, balancing the customer's privacy against the rights of others and the public interest.
The burden of proof is on the bank. It must show how erasure would affect the rights or interests of others, with due regard to the accuracy and integrity of the data. Saying that the legacy system cannot delete rows is not enough on its own.
The opinion gives one more example: data kept for historical documents or archives in the public interest under Section 24(1). Erasing it could make the record of important events inaccurate or break its continuity.
In what order should a bank decide on an erasure request?
The opinion sets the order. First, decide which ground in Section 33, paragraph 1, items (1) to (4), the request falls under, and whether an exemption in paragraph 2 applies. Only then apply the relevant parts of the 2024 notification. The table below is our reading of the law and the opinion.
| Situation | What the bank does | Reference |
|---|---|---|
| The data is no longer needed, consent is withdrawn, or an objection succeeds, and no exemption applies | Erase, destroy or anonymise within 90 days of receipt, covering copies and backups | Section 33(1)(2)(3) · Clause 3 |
| The customer asks for erasure, but the bank wants anonymised data for statistics | Anonymise fully, both direct and indirect identifiers, and give the customer reasonable details | Clause 3 para 3 · Clause 6 · Clause 8 para 2 |
| The data was collected, used or disclosed unlawfully | Erase or destroy only | Section 33(4) · Clause 7 |
| Accounting, tax, anti-money laundering or financial institution law requires retention | Keep only what that law requires, erase the rest, and give reasons for what cannot be erased | Section 33 para 2 · Clause 8 para 3 |
| The data is evidence in an existing or foreseeable dispute | Keep only what the legal claim needs and record the reason | Section 33 para 2 |
| Erasure would damage financial records linked to other customers | Rely on significant necessity if it can be proved, and explain it to the customer | Clause 5 |
| Data is in backups or awaiting overwrite and cannot be erased within 90 days | Put it beyond use under the five criteria, then erase as soon as possible | Clause 4 |
| The bank purges data at the end of its retention period with no request | Erase through the Section 37(3) review system; no notice to the customer | Section 37(3) · Clause 9 |
- Day the request arrivesRecord the date of receipt; the 90-day limit runs from hereClause 3 para 1
- First stepIdentify the ground under Section 33(1) to (4) and check for a paragraph 2 exemption or a significant necessitySection 33 · Clause 5
- Choose the methodErase, destroy or anonymise; if the data was obtained unlawfully, erase or destroy onlyClause 3 para 3 · Clause 7
- By day 90Finish across the core system, copies and backups; put anything still pending beyond useClause 3 para 2 · Clause 4
- When done, or if it cannot be doneTell the customer: reasonable details if anonymised, reasons if the request cannot be metClause 8
What did the PDPC Office suggest adding to a bank's erasure manual?
The subcommittee noted that the Association's draft only described the types of data that might qualify for an exemption. It suggested considering six further elements, so that erasure meets the legal conditions and can be checked afterwards.
- An appropriate data retention schedule.
- Operational controls, such as approval before erasure and checklists showing how long each part of the data must be kept and when it was last reviewed.
- Handling of physical media and storage devices awaiting erasure: where they are held, security while they wait, a register of devices and a clearly identified storage location.
- Clearer technical methods for hardware, such as device wiping, degaussing or hardware shredding.
- Requirements for outside contractors that erase or destroy data or devices, possibly including a certificate of destruction for each job.
- A standard for paper shredders, such as cross-cut or micro-cut, so strips cannot be pieced back together.
Technical methods should be chosen on a risk basis, considering the type of data, the kind of storage medium and the way records are kept. Whatever the method, it must reach copies and backups and stop anyone from recovering the data or re-identifying people, directly or indirectly.
How binding is this opinion, and can other businesses use it?
The subcommittee itself states that its opinion and observations do not certify that every practice is lawful in every case. They are suggestions on certain points, which the Association and its member banks may use when preparing manuals, guidelines or standards.
What binds is the PDPA and the 2024 notification the opinion relies on. A customer who believes the bank or its processor has broken the law keeps the right to complain through the procedures the law provides. The opinion helps to read the notification; it does not close the customer's options.
In our reading, fintech firms, insurers and any business with a large customer database can apply the points on backups, mapping tables and holding measures in the same way, since the notification applies to every data controller. The examples of financial sector laws apply only to those subject to them. If you must keep system logs, see our article on 90-day logs and erasure requests.
Frequently asked questions
How long does a bank have to act on an erasure request?
Without delay, and no later than 90 days from receipt, under Clause 3 of the 2024 notification, provided no Section 33 paragraph 2 exemption applies. Anything that cannot be erased in time for technical reasons must be put beyond use under Clause 4.
I have closed my account. Can I ask the bank to erase everything?
You can ask, but the bank may keep some data to comply with other laws, such as accounting, tax or anti-money laundering law, or as evidence in a dispute. Anything beyond that must be erased, and the bank must give reasons for what it cannot erase.
Must a bank tell the customer if it anonymises instead of erasing?
Yes. Clause 3 paragraph 3 requires notice when the method differs from the request, and Clause 8 paragraph 2 requires reasonable details of the anonymisation, unless the customer already knows them.
Does encrypting data and keeping it count as erasure?
The opinion does not address encryption directly. In our reading, if the bank still holds the decryption key, the data can be linked back to the customer, much like the mapping table the subcommittee described. It is therefore neither erasure nor anonymisation.
Must a bank notify customers when it purges expired data on its own?
No. The subcommittee's view is that erasure under Section 37(3) that does not stem from a customer's request carries no duty to notify. The erasure must still reach copies and backups, because Clause 9 of the notification applies Clause 3 paragraphs 2 and 3 to it.
What kind of paper shredder is required?
The subcommittee suggested that the Association's manual set a shredder standard, such as cross-cut or micro-cut, so strips cannot be reassembled. That is a suggestion on the draft manual; the notification itself does not specify a shredder type.
You have read it. Now get it done
Open the demo account to see the real AIPDPA system with a sample company: RoPA, the 72-hour breach clock, data subject requests, cookie consent and ready-to-use documents, all in one place.
From 2,900 THB/year (11 modules) · all 24 modules from ENTERPRISE at 19,900 THB/year · demo account, no sign-up
No time? Have our lawyers handle it →Kooru's lawyers set it up and act as your DPO
Law and sources
- Notification of the Personal Data Protection Committee on Criteria for the Deletion or Destruction of Personal Data, or for Rendering Personal Data into Data by which the Data Subject Cannot Be Identified, B.E. 2567 (2024) — Clause 3 · 4 · 5 · 6 · 7 · 8 · 9
- Personal Data Protection Act B.E. 2562 (2019) — Section 6 · 24 (1) (4) · 33 · 37 (3)
Text in the "The text" boxes is copied word for word from AIPDPA's legal knowledge base, transcribed from the Royal Gazette and official documents; every edit is checked by the system against that base, character by character. English wording is an unofficial translation; the Thai text prevails. This article is general information, not legal advice for a particular case.
Do it in the system
Who stands behind this guide?
Written by the AIPDPA legal team · Content owner: Phuwara Krobtaku, Attorney-at-law · Thai Barrister-at-Law · technology & intellectual property counsel
Lawyer's licence no. 477/2558 · Thai Barrister-at-Law · LL.M. in Intellectual Property & IT Law (Gold Medal)