Accounting, Tax & Bookkeeping// definition

What a client due-diligence record has to contain before work starts

In short

A client due-diligence record is the stored evidence that a practice knows who its client is: verified identity per individual, the beneficial ownership chain with percentages, screening results with their date, a risk rating with its factors, source-of-funds notes, a refresh due date and a named approver. Each field needs evidence attached, not an assertion.

Key takeaways

  • The deliverable is a record with evidence links, not a folder of scans and a memory of the conversation.
  • Beneficial ownership is a chain, not a field: model owners as rows with a percentage and a control mechanism.
  • Every screening result needs its date and list version, or it is unverifiable a year later.
  • A risk rating with no stored factors cannot be defended, reviewed or recalculated.
  • The refresh due date turns onboarding evidence into ongoing monitoring, and is the field most often absent.

A client due-diligence record is the evidence a practice stores showing it knows who it acts for, who ultimately owns and controls them, and why the engagement makes sense. Firms hold it as a folder of scans plus a partner's recollection. That is not a record: it cannot be searched, refreshed, reviewed or handed over, and the fields that fix it are known.

The obligation is dated context and changes by jurisdiction. The record shape is the engineering deliverable, and it is stable.

Where the obligation comes from

Accountants sit inside anti-money-laundering regimes as designated non-financial businesses and professions. FATF Recommendation 22 brings them into scope; Recommendation 10 sets the measures — identify and verify the customer, identify the beneficial owner, understand the purpose of the relationship, monitor it thereafter. National law differs: in the UK, regulation 28 of the Money Laundering, Terrorist Financing and Transfer of Funds Regulations 2017 sets the measures and regulation 40 requires 5 years of retention after the relationship ends. In the EU, Regulation (EU) 2024/1624 moves the rules into one directly applicable rulebook from 2027.

The record, field by field

FieldWhat it holdsThe constraint that makes it usable
legal_identityRegistered name, number, jurisdiction, registered and trading addressStore which register the number came from; a company number alone is ambiguous
entity_typeCompany, partnership, LLP, trust, sole trader, charityDecides which ownership model applies — a trust has no shareholders to enumerate
individualsEach person verified: name, date of birth, role, addressOne row per person, not a "directors" text field
identity_evidenceDocument type, issuer, expiry, method, verified_by, verified_atMethod matters as much as document: in person, certified copy, electronic check
ownership_chainEach owner with percentage, control mechanism and layerA chain, not a field. Layered holdings need parent references or the 25% test fails
screeningPEP and sanctions results, date, list version, dispositionA result with no date and no list version is unverifiable a year later
risk_ratingThe rating, the factors behind it, who approved itStore the factors. A rating with no inputs cannot be reviewed or recalculated
source_of_fundsNature of business, expected pattern, funding narrativeFree text is fine, but must be dated and attributed
refresh_dueWhen this record must be looked at againDerived from risk_rating, or it is set once and never moves
approvalWho accepted the client, when, against which record versionVersion the record. Approval of an unversioned record proves nothing
The stored shape of a client due-diligence record

Ownership chains, and the structures that break the model

An owners table with a percentage column handles a straightforward company and nothing else. Holding structures need a parent reference per row so ownership multiplies through layers. Trusts need settlor, trustees, beneficiaries and any protector, none of which is a shareholding. Partnerships split economics by agreement rather than by shares — the wrinkle that reappears in the partnership income statement as an extraction problem.

Where the record fails in practice

  • Evidence attached to an email thread. It links to no field, so nobody can say which document proves this director's address.
  • Screening captured as a screenshot. No list version, no structured disposition, no way to re-run the same parameters when a name later matches.
  • One refresh date for the whole firm. Annual review for everyone under-reviews high-risk clients and makes noise for the rest. Derive it from the rating.
  • Collection treated as the client's problem. Identity documents decay like any other chase — reminders stop working after the second one applies unmodified.
  • An upload flow built for finance staff. Owners photograph a passport on a phone at 8pm, and format rejections or a forced order produce the drop-offs in clients abandoning the records upload halfway.

The related failure is attribution. A document arriving with no verified link to a person and an entity is evidence of nothing — the binding problem in receipts sent over chat with no client or period. Bind identity at first contact rather than inferring it later from a filename.

A due-diligence file you cannot query is a shelf. The question is never "do you have it" but "show me, for this client, on that date".

Built properly this is a small internal system: a record per client, evidence objects linked to fields, a derived refresh queue, an audit log of who approved what. We build that under internal tools and operations software for accounting and tax practices, beside the rest of the client intake, chasing and portals topic.

Frequently asked questions

Short answers to the follow-ups this page tends to raise.

What is the difference between KYC and CDD for an accounting practice?

They name the same activity, CDD being the regulatory term and KYC the shorthand borrowed from banking. Where a distinction is drawn, KYC is identifying and verifying the client, and CDD is the wider set: identification, beneficial ownership, the purpose of the relationship, and ongoing monitoring.

Do we need beneficial ownership for every client?

You need to identify who ultimately owns or controls the client, which is not the same as enumerating every shareholder. Thresholds such as 25% appear in many regimes as the trigger for identifying an individual, but control can exist with no shareholding at all — voting agreements, a golden share, a power to appoint directors. Model control mechanisms, not only percentages.

How long should due-diligence records be kept?

Retention is set by your jurisdiction; the UK regulations require 5 years from the end of the relationship, and other regimes differ. The engineering consequence is that the record must survive the client leaving, so a design that deletes a client on offboarding is wrong. Archive it with evidence and approval history intact.

Can identity verification be automated?

The check can be, the acceptance decision should not be. Electronic verification returns a structured result you can store with a date and provider reference, better evidence than a scan in a folder. What stays human is the disposition of anything ambiguous — a partial match, an expired document, an unexplained ownership layer — and the record must show who made that call.

  • client due diligence
  • onboarding
  • AML
  • data modelling
// shipped work

The work behind this page

Builds from our portfolio that this page draws on.

Working on something in this space?

Tell us where you are in a sentence or two. We'll tell you honestly whether we're the right team, and what a sensible first slice of the work looks like.

Start the conversation