Manual audit trails creating compliance gaps?
Access verified bank transaction data for audit-ready regulatory reporting.
Client due diligence solutions are used to verify customer identity, financial activity, and risk as part of compliance processes required under the Money Laundering Regulations 2017.
Most regulated firms have a CDD process in place. The gap in most client due diligence solutions is not the process itself – it is the quality of data the process relies on.
Documents tell you what a client wants you to see. Bank data tells you what actually happened.
As of January 2025, over 13 million people in the UK are active open banking users (Open Banking Limited, 2025) – yet many Lawtech, conveyancing, and compliance platforms still rely on PDF bank statements and manual document review as the foundation of their CDD process. That approach carries risks that verified financial data can directly address.
TL;DR
Client due diligence solutions must verify identity, source of funds, and financial activity under MLR 2017. Document-based client due diligence solutions create three risks: PDFs can be manipulated, source of funds cannot be independently verified from a statement, and audit trails depend on what the client chooses to provide. Modern client due diligence solutions that incorporate bank transaction data via Open Banking AIS deliver verified, direct-from-bank financial records with consent logs and access timestamps – improving both accuracy and audit readiness.
Key Takeaways
What is client due diligence?
Client due diligence (CDD) is the process of verifying a client’s identity, understanding the nature of their business relationship, and assessing their risk profile. Under the Money Laundering Regulations 2017, regulated firms including solicitors, conveyancers, and accountants must complete CDD before establishing a business relationship and maintain records demonstrating that verification was performed.
Why do document-based client due diligence solutions create compliance risk?
Three specific weaknesses:
- PDF bank statements can be altered – transaction amounts, dates, and descriptions are editable using widely available tools; the SRA cannot verify authenticity from a document alone
- Source of funds cannot be confirmed from documents – a statement shows funds exist but does not independently verify their origin or legitimacy
- Audit trails rely on client-provided evidence – if a document is later found to be manipulated, the firm may be unable to demonstrate adequate due diligence under MLR 2017 Regulation 28
What do effective client due diligence solutions require?
- Direct-from-bank transaction data via Open Banking AIS – not client-prepared documents
- Consent log per retrieval recording when data was accessed, by whom, and what scope was granted
- Transaction history depth covering the full period required for source of funds assessment
- Structured data format that supports review and audit without manual interpretation
Why Do Document Checks Fail in CDD Workflows?
What Makes Document-Based Due Diligence Unreliable?
The fundamental problem with document-based client due diligence solutions is that documents are client-intermediated. Every piece of evidence goes through the client’s hands before it reaches the compliance team.
PDF bank statements downloaded from a banking app can be edited before sending. Client-prepared summaries of financial activity are self-selected. Even certified copies verify that a signature is genuine – not that the underlying data is accurate.
For high-value property transactions, this matters significantly. The SRA’s source of funds guidance requires solicitors to understand not just where funds are coming from, but whether the explanation is consistent with the client’s risk profile and the nature of the transaction. A PDF cannot satisfy that requirement independently.
| CDD Method | Data Source | Manipulation Risk | Audit Trail |
|---|---|---|---|
| PDF bank statement | Client-prepared document | High – editable before sending | Firm’s own records only |
| Certified copy | Client-prepared, certified by third party | Medium – signature verified, data not | Firm’s own records only |
| Open Banking AIS | Direct from bank via API | None – unalterable at source | Consent log + access timestamp per retrieval |
“The compliance risk in document-based CDD is not always visible at the time of collection. It surfaces when a statement is later found to have been altered, or when a firm cannot demonstrate to the SRA that the data was genuine and obtained with proper consent documentation.” – Clare, Finexer
Financial due diligence and transaction services covers how bank transaction data supports financial due diligence workflows across regulated platforms.
What Is the Business Impact of Weak Client Due Diligence?
How Does Document Reliance Affect Compliance and Onboarding?
Weak client due diligence solutions create two categories of business impact. When evaluating due diligence providers, these are the risks that separate document-based approaches from verified data approaches.
Regulatory risk:
Under Section 327 of the Proceeds of Crime Act 2002 and MLR 2017, firms that cannot demonstrate adequate CDD face regulatory sanction. The SRA took enforcement action against multiple law firms in 2024-2025 for inadequate source of funds documentation. A firm that accepted manipulated bank statements without independent verification may be unable to show it applied the standard required under Regulation 28.
Operational cost:
Manual document collection is slow. Chasing clients for statements, reviewing PDFs line by line, and filing paper records creates overhead per matter. For high-volume conveyancing or compliance platforms, this cost compounds. According to the Law Society’s customer due diligence guidance, AML costs should be identified separately and be transparent to clients – suggesting the compliance overhead is material and recognised.
What Do Modern Client Due Diligence Solutions Require?
What Should Platforms Evaluate in a CDD Data Solution?
The shift from document-based to data-based client due diligence solutions requires three capabilities. Most due diligence providers operating in the UK market offer some combination of these – the difference is whether data comes from the client or directly from the bank.
Verified financial data access:
- Direct bank connection via FCA-authorised AIS – data from the bank, not from the client
- SCA (Strong Customer Authentication) at bank level – the bank verifies the client’s identity at consent
- Transaction history covering the required assessment period (typically 6-12 months, up to 7 years for deeper source of wealth checks)
Consent and audit infrastructure:
- Consent log per retrieval – timestamp, client identity, data scope, and access event recorded
- Per-retrieval records that demonstrate to the SRA or FCA when data was obtained and what scope was granted
- Data provenance traceable to the bank – not to a client-prepared document
Structured data output:
- Consistent transaction format supporting review without manual interpretation
- Merchant IDs and category codes that support income, expense, and funding source analysis
- Compatible with existing CDD review workflows without replacing them
Reducing client due diligence costs with Open Banking covers how bank data access reduces the operational overhead of document-based CDD workflows for regulated platforms.
How Does Finexer Support Client Due Diligence Solutions?
What Does Finexer’s AIS Provide for CDD Workflows?
Finexer’s FCA-authorised AIS provides the verified bank transaction data layer that supports source of funds checks, financial verification, and audit-ready records within a platform’s existing CDD workflow.
- Direct-from-bank transaction data – retrieved via Open Banking API, not from client-prepared documents
- SCA at bank level – client authenticates in their own banking app; the bank verifies their identity
- Up to 7 years of transaction history – configurable depth for source of funds and source of wealth assessments
- Consent logs per retrieval – timestamp, scope, and access event recorded per data pull
- Structured JSON – consistent format across almost all major UK banks, supporting review without manual interpretation
- 99% UK bank coverage – high street, challenger, and business accounts
- Usage-based pricing, 3-5 weeks to production with active onboarding support
“For compliance teams handling source of funds checks, the critical question is not whether the data shows what the client claims. It is whether the data came directly from the bank or passed through the client’s hands first. Finexer’s AIS answers that question.” – Clare, Finexer
Finexer verification infrastructure covers how Finexer’s bank data access supports identity and financial verification workflows for regulated platforms.
What I Feel
Document-based CDD is the path of least resistance for a lot of firms.
It is familiar. It is cheap upfront. Clients know how to provide it.
The problem surfaces later – in an SRA review, a compliance audit, or a transaction that turns out to have been built on manipulated statements.
Verified bank data via Open Banking does not make CDD more complicated. It makes the evidence undeniable. That is worth more than convenience.
Common Use Cases
Lawtech Platforms
Source of funds checks under MLR 2017 and POCA 2002 require verified transaction history. Finexer’s AIS delivers direct-from-bank data with consent logs per retrieval – providing the audit trail that document-based collection cannot guarantee.
Conveyancing Platforms
Property transaction CDD requires 6-12 months of unredacted bank statements. Finexer’s AIS retrieves directly from the bank with SCA at authentication – data that cannot be altered between the bank and the platform.
Compliance SaaS Platforms
Ongoing monitoring workflows require continuous access to transaction data over 90-day consent windows (UK). Finexer’s AIS supports consent refresh and continuous data access – structured, timestamped, and audit-ready per access event.
Accounting Platforms
Financial verification for compliance engagements requires structured transaction data covering income, expenditure, and funding sources. Finexer’s AIS delivers enriched transaction data with category codes at source, reducing the manual review step in financial verification workflows.
How do due diligence providers use Open Banking for CDD?
Due diligence providers that integrate Open Banking AIS retrieve bank transaction data directly from the client’s bank with consent, rather than relying on client-submitted documents. This provides verified, unalterable transaction history with a consent log per retrieval – improving source of funds evidence quality and audit readiness under MLR 2017 Regulation 28.
What is CDD and EDD in banking?
CDD (Customer Due Diligence) is the standard verification process covering identity and source of funds. EDD (Enhanced Due Diligence) applies to higher-risk clients or transactions and requires deeper financial verification – including more extensive transaction history, beneficial ownership analysis, and closer scrutiny of source of wealth. Both can incorporate Open Banking bank data to improve evidence quality.
How does Open Banking improve client due diligence solutions?
Open Banking AIS provides direct access to bank transaction data with the client’s consent via SCA. The data arrives from the bank – not from a client-prepared document – and is accompanied by a consent log and access timestamp. This improves source of funds verification accuracy and creates an auditable access record that supports MLR 2017 Regulation 28 compliance.
Strengthen your CDD workflows with verified bank transaction data.
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