Financial Records Retention UK: Structured Data Over Storage

Financial records retention UK compliance breaks down not at the point of storage, but at the point of retrieval.

An insolvency firm received a client due diligence request from a regulator. They had the documents. The problem was where those documents lived – across three email threads, two exported spreadsheets, a PDF the client had submitted six months earlier, and a bank statement downloaded manually and saved to a shared drive folder nobody had organised.

The documents existed. The standard was technically met. Producing them took two days. The regulator noted the delay.

This is the core financial records retention UK challenge for regulated platforms in 2026. It is not about whether records are kept. Most firms and platforms meet the basic record-keeping obligation. The question regulators are increasingly asking is whether that evidence is structured, accessible, and verifiable – or just stored.

“Retention gets treated as an archiving problem. It is an operational problem. The financial records retention UK obligation depends not only on storage, but also on the ability to retrieve and produce evidence when required. A folder full of PDFs and email exports may not provide the operational clarity regulators or auditors expect during reviews.” – Clare, Finexer

TL;DR

Companies Act 2006: 6 years for private company accounting records. MLR 2017 (Reg. 40): 5 years for AML and CDD records. HMRC self-assessment: 5 years. UK Sanctions List replaced the OFSI Consolidated List from 28 January 2026. Retention periods are the easy part. Structured, accessible, verifiable data is the operational challenge.

What Does UK Law Actually Require for Financial Records Retention?

The statutory obligations differ by record type, legal basis, and whether the business is subject to additional regulatory requirements. The table below covers the primary retention obligations for regulated UK platforms.

This table covers primary statutory obligations. Regulated firms should confirm specific requirements with their sector regulator and seek independent legal advice for their circumstances. Periods may extend beyond statutory minimums for operational, legal, or regulatory reasons.

Two points deserve attention.

First, AML-regulated firms – which include credit institutions, regulated institutions, independent legal professionals, accountants, and tax advisers – face a separate 5-year clock under the Money Laundering Regulations 2017 (Regulation 40), running from the end of the business relationship. This applies to customer due diligence records and supporting transaction documentation across all monitored transactions subject to ongoing monitoring, not just flagged or suspicious ones.

Second, the Companies Act 2006 (s.386) requires that company accounting documentation be sufficient to show and explain the company’s transactions, disclose with reasonable accuracy the company’s position, and enable directors to ensure accounts comply with the Act. Storage alone may not always be sufficient for compliance workflows under these standards – the documents must be capable of demonstrating compliance when reviewed.

What Did the ECCTA 2025 Change for Statutory Record Keeping?

From 18 November 2025, the Economic Crime and Corporate Transparency Act 2025 changed how companies maintain statutory registers. Several internal registers no longer need to be held by the company – the information is now held centrally at Companies House (gov.uk).

This simplification does not affect core accounting record obligations under the Companies Act 2006 or the MLR 2017. Transaction histories, accounting documents, and AML documentation remain the responsibility of the company – they are not migrated to Companies House.

The distinction matters for compliance platforms advising clients on record simplification following ECCTA: statutory register consolidation does not reduce the underlying data obligations.

Where Are Records for Financial Sanctions Kept – and Why Does It Matter?

From 28 January 2026, the UK moved to a single UK Sanctions List as the sole official record of designations (UK Government, gov.uk). The OFSI Consolidated List stopped updating on that date. Any platform or firm that previously screened against the OFSI Consolidated List needs to be using the UK Sanctions List from that point.

For regulated platforms, this change has implications for how records for financial sanctions are kept.

The compliance evidence is not just the screening result. It is the evidence trail showing when the screening occurred, against which list version, what the result was, and how any flagged results were handled. Sanctions compliance evidence that cannot be produced – or that relies on a superseded list version – creates a gap that regulators take seriously.

MLR 2017 (Regulation 40) requires that documentation sufficient to reconstruct each transaction is kept for 5 years. For transactions involving sanctions-adjacent parties or any transaction that triggered a monitoring flag, the supporting documentation needs to demonstrate that appropriate checks were applied at the time – not reconstructed after the fact.

OFSI handles enforcement of financial sanctions in the UK. Firms reporting a suspected breach or holding frozen assets should report to OFSI and, where relevant, the FCA.

For compliance platforms building sanctions screening workflows, sanctions compliance evidence is held most reliably when the underlying transaction data is structured, timestamped, and bank-verified – rather than depending on manually assembled documentation collected after a screening event.

Where Does Compliance Record Keeping Break Down for Regulated Platforms?

The problem is not willingness to keep documents. Most regulated firms understand the obligation: documents must be kept. The breakdown happens in three places.

Documents exist but are not structured. PDF bank statements, email-attached documents, CSV exports from banking portals, and screenshots saved to shared folders all qualify as documentation in the loosest sense. They do not qualify as structured data that can be produced, searched, and verified efficiently. When an auditor asks for all transaction evidence involving a specific counterparty over a 24-month period, a folder of PDFs is not a useful answer.

Coverage is complete for the standard case but not the edge case. The Companies Act 2006 requires documentation sufficient to show and explain transactions. A transaction manually entered, partially exported, or captured from a secondary source may be in the system but may not be verifiable against the bank account it purportedly reflects. This is where the gap between stored documentation and structured, verifiable evidence becomes visible.

The access workflow is slower than regulatory expectations. Regulators, auditors, and investigators expect documents to be produced promptly. A two-day assembly exercise is not a statutory failing in isolation – but it signals to a regulator that the infrastructure is not designed for retrieval. Under an active HMRC compliance check or OFSI enquiry, that signal carries weight.

For accounting SaaS and LawTech tools, the practical implication is that financial records retention UK compliance depends not only on whether documents are kept but on whether the platform’s data layer makes them producible and verifiable on demand.

What verified compliance data looks like in practice – and why bank-verified transaction data produces a structurally different evidence trail from manually assembled documents – is covered in the compliance data for regulated financial platforms guide.

How Are Regulated Platforms Improving Compliance Data Infrastructure?

The shift in UK compliance infrastructure is from passive storage to active retrievability. Platforms that have addressed this problem are not keeping more documents – they are keeping data that is structured, verifiable, and retrievable without manual assembly.

Three elements distinguish structured data infrastructure from document storage:

Bank verification at source. Transaction data retrieved directly from the bank account – with a timestamped consent log – is structurally different from a manually submitted bank statement. The bank-verified entry is tamper-resistant and carries an access trail showing not just what the document contains but how it was retrieved.

Consistent data structure. Transaction entries in a consistent format – amount, date, counterparty, category, reference – can be searched, filtered, and produced against specific criteria. The same query that identifies all transactions involving a specific counterparty in a PDF archive requires manual review. In structured transaction data, it is a filter.

Consent-based access logs. For AML-regulated firms accessing client bank data through Open Banking, the consent flow itself creates a documented, timestamped access entry. When consent was granted, what data was accessed, and by which platform becomes part of the compliance evidence trail – supporting the requirements under MLR 2017 Regulation 40.

UK GDPR, the Data Protection Act 2018, and FCA data standards interact directly with these obligations – this layered interaction is addressed in financial data protection for UK regulated platforms.

How Does Structured Bank Data Reduce Reliance on Fragmented Documentation?

Operational finance and compliance teams at regulated platforms increasingly face the same friction: when a regulator, auditor, or AML investigator requests transaction evidence, the speed and quality of what can be produced depends almost entirely on how that evidence was collected and stored in the first place.

Structured bank data from Open Banking AIS replaces four common sources of operational friction:

Retrieval speed during AML and compliance reviews. Bank-verified transaction data is searchable by counterparty, date range, amount, and reference – without manual file-opening. What takes two days through document folders takes minutes through a structured data layer.

Structured transaction evidence. Each bank-verified entry carries consistent fields – merchant name, category, amount, timestamp, reference – making counterparty tracing and transaction reconstruction straightforward without format conversion.

Reduced dependency on fragmented documentation. Manually collected PDFs, email-attached statements, and portal CSV exports each require format handling, version management, and manual verification. A single structured data feed from the bank account eliminates that surface area.

Coordination between compliance and finance teams. When both teams access the same structured, bank-verified data layer, the version inconsistencies between manually assembled documents are removed. Compliance reviewers work from the same source as the finance team – not from a separately assembled evidence pack.

This is an operational infrastructure question, not a compliance determination. Platforms still apply their own retention policies, compliance logic, and regulatory judgements on top.

How Does Finexer Support These Workflows?

Finexer does not provide legal compliance, legal advice on these requirements, or determine how long documents must be held. It does not fulfil regulatory obligations on behalf of platforms.

Finexer provides FCA-authorised Open Banking AIS – the bank transaction data infrastructure that accounting platforms, LawTech tools, and compliance SaaS products use to access verified, structured transaction data from client bank accounts.

The data layer problem Finexer addresses is not how long documents must be kept, but what those documents look like and whether they are structured for retrieval and verification.

What does Finexer’s AIS provide for compliance data infrastructure?

• Verified transaction data from source. Bank data retrieved via Open Banking AIS comes directly from the account with a timestamped consent record. The entry is bank-verified, not manually submitted.
• Consistent, structured format. Transaction data delivered in normalised JSON format across 99% of UK banks – date, amount, counterparty, category, reference – produces entries searchable and filterable without manual processing.
• Up to 7 years of transaction history. AIS provides access to up to 7 years of history through a single integration – covering the 6-year Companies Act requirement and the 5-year MLR 2017 obligation within one data access workflow.
• Timestamped consent and access logs. Each Open Banking consent flow creates a logged access entry: when consent was granted, what data was requested, and confirmation of retrieval. This supports the evidence trail MLR-regulated firms need to demonstrate compliant data access.
• Webhook delivery for ongoing transaction visibility. Platforms maintaining an ongoing record of client account activity for AML monitoring, sanctions screening, or compliance workflows receive transaction updates near-immediately as they occur.

What Finexer does not replace: the platform’s own storage policies and schedules; legal advice on obligations for specific regulated activities; compliance decisions, sanctions screening determinations, or AML assessments; HMRC-facing obligations or filing requirements.

The bank data arrives structured and verifiable. The platform applies its own compliance logic and data workflows on top.

“The platforms that handle these requirements most reliably are the ones that stopped treating it as a storage question and started treating it as a data infrastructure question. The period is the easy part. How records are structured, and how quickly they can be produced – that is where the operational risk in financial records retention UK actually sits.” – Clare, Finexer

For platforms handling client bank statement retrieval for compliance workflows, see automated bank statement analysis UK platforms for how Open Banking AIS replaces manually submitted documents with verified, structured transaction data.

FCA-authorised (FRN 925695). PSD2-compliant. Usage-based pricing. 3 to 5 weeks of onboarding support.

What Are the Typical Use Cases for Structured Bank Data in Compliance Workflows?

Accounting SaaS platforms. Accounting platforms using Open Banking AIS maintain client transaction workflows – bank-verified, structured, and retrievable – replacing manually exported statements and CSV imports with a consistent data layer. The underlying infrastructure determines whether documentation meets the Companies Act 2006 standard of being capable of showing and explaining transactions.

LawTech and compliance platforms. LawTech tools supporting AML obligations under the Money Laundering Regulations 2017 need documentation retrievable within the 5-year window specified in Regulation 40. Bank-verified transaction data provides the structured evidence layer for source-of-funds workflows, client due diligence, and transaction reconstruction.

For platforms needing a KYC verification guide, and those running income evidence checks alongside bank account verification, see also income verification API UK platforms.

Fintech compliance and AML operations. Payment institutions, e-money institutions, and credit providers with obligations under MLR 2017 need transaction data that is both complete and structured for regulatory production. Open Banking AIS delivers data from source with consistent formatting, reducing the gap between what documentation contains and what regulators expect to see.

About the Author

Clare Pearson

Clare Pearson is a senior payments professional with extensive experience across the global financial services and payments industry. She specialises in Open Banking, payment infrastructure, and financial technology transformation, with expertise spanning product delivery, operational strategy, regulatory compliance, and large-scale payments programmes. Clare currently serves as a Non-Executive Director at Finexer and a panel member for the Payment Systems Regulator (PSR), advising on the development of payment systems policy and innovation