A data retention schedule is a document, usually set out as a table, that lists the categories of records and data an organisation holds and states for each one how long it must be kept, the reason for that period, who owns it and how it is disposed of at the end. Banks, payment firms, insurers, crypto businesses and most regulated companies maintain one, because different laws require some records to be kept for years while others require personal data to be deleted as soon as it is no longer needed.
The schedule sits at the meeting point of two pressures. Recordkeeping requirements in anti-money laundering, tax and securities law set minimum periods, while data protection law sets maximums by forbidding firms to keep personal information longer than necessary. A schedule turns both into one set of instructions that staff and systems can follow. It is often called a records retention schedule, and it forms part of a wider records management or information governance policy.
Data retention schedule in plain terms
Think of a household filing cabinet. Some papers, such as the deeds to a house, are kept for as long as the house is owned. Tax papers are kept for a set number of years in case questions are asked. Old supermarket receipts are thrown away after a few weeks. A sensible family agrees which drawer each paper goes in and when it can be shredded.
A data retention schedule is that agreement for a company, written down so everyone follows the same rules. The difference is scale and consequence. A bank holds millions of records across many computer systems, and both mistakes are costly: shredding too early can mean failing a regulator's request, and keeping too long can mean breaking privacy law or exposing old data to theft.
What a schedule contains
Each line of a schedule normally covers one record class, such as account-opening files, payment instructions, call recordings or marketing consent records. Typical columns include:
- Record class and description. What the records are and which systems or teams hold them.
- Retention period. How long the records are kept, for example "five years after the account is closed".
- Trigger event. The date from which the period runs, such as transaction date, end of the customer relationship or contract expiry.
- Legal or business basis. The law, regulation or business need that justifies the period.
- Owner. The department accountable for the records and for approving their deletion.
- Disposal method. Secure deletion, anonymisation, archiving or physical destruction, and how that is recorded.
The trigger event matters as much as the period. "Five years" means very different things if it runs from each transaction rather than from the day a long-standing customer leaves.
Rules that drive retention periods in finance
Financial firms take most of their minimum periods from anti-money laundering law. FATF Recommendation 11 asks countries to require that transaction records and the results of customer due diligence be kept for at least five years. In the United States the Bank Secrecy Act rules generally require five years, which covers records gathered under a customer identification program (kept for five years after the account is closed) and copies of filed suspicious activity reports and currency transaction reports. The UK Money Laundering Regulations 2017 and the EU anti-money laundering directives use a similar five-year baseline, with some room to extend it.
Other rules point the other way. The EU General Data Protection Regulation (GDPR) includes a storage limitation principle in Article 5, and Article 17 gives people a right to have data erased once there is no longer a lawful reason to keep it. The PCI DSS requires firms to keep stored cardholder data to a minimum and forbids storing sensitive authentication data, such as the full magnetic-stripe contents or the card verification value, after a payment is authorised. Tax law, securities rules (such as SEC Rule 17a-4 for US broker-dealers) and limitation periods for legal claims add further minimums.
Putting a schedule into practice
Writing the schedule is the easy part. Applying it means mapping each record class to the systems that hold it, including backups, email, chat tools and data held by outsourced providers, which is why retention terms appear in vendor risk management reviews. Mature firms automate deletion or anonymisation when the period ends and keep a log showing what was destroyed and when.
A legal hold overrides the schedule. When litigation, a regulatory investigation or a law enforcement request is expected, the affected records must be preserved even if their period has run out, and deleting them can be treated as destruction of evidence. Payment firms also keep transaction evidence long enough to answer a chargeback or a customer complaint, which can arrive months after the payment.
Encrypted archives raise a related issue. If the keys protecting an archive are rotated or destroyed, the old data must be re-encrypted or it becomes unreadable, which links retention planning to cryptographic key rotation and to the hardware security modules that often hold those keys. Some firms deliberately destroy a key to make expired data unrecoverable, a technique known as crypto-shredding.
Weaknesses and common failures
The most frequent problem is a schedule that exists on paper but is not applied, so data piles up indefinitely in old systems. Over-retention increases the damage of any data breach, because records that should have been deleted are stolen along with current ones. Under-retention is rarer but serious: regulators have fined firms that could not produce records, including business messages sent on unapproved apps. Conflicting rules across countries also make a single global schedule hard to write, so multinational banks often keep the longest required period and document local exceptions. Finally, a schedule ages quickly; it needs regular review as laws, products and systems change, and as data privacy expectations tighten.