Financial Crime Knowledge Hub

    Building a Regulator-Defensible CDD Audit Trail

    Agora Consulting Solutions•Written by •

    An audit trail is defensible when an independent reviewer can reconstruct a past decision without asking anyone what happened. That requires five linked layers: where the data came from, what checks ran, which configuration was in force, what was concluded and by whom, and what was done next.

    Why it matters

    Most supervisory criticism of customer due diligence is not that the firm reached the wrong conclusion. It is that the firm cannot demonstrate how it reached any conclusion. The test a firm should set itself is simple: pick a file closed two years ago and try to reproduce the decision from the record alone. Whatever a reviewer has to ask a person about is a gap in the trail.

    Regulatory basis, stated carefully

    The Money Laundering Regulations 2017 include record-keeping obligations, and HMRC guidance describes records and updating on change as part of customer due diligence. The FCA Financial Crime Guide sets out expectations for firms it supervises.

    The FCA's April 2026 findings on customer due diligence processes and controls observed weaknesses including insufficient evidence of enhanced due diligence measures, insufficient detail in procedures on periodic and event-driven reviews, failure to record purpose and intended nature, and weak independent assurance and version control. Stronger practice it described included documented EDD steps, risk-tailored due diligence and regular independent testing. Those are observations about the firms reviewed rather than a uniform rule for all businesses. This page is general information, not legal or compliance advice.

    The five layers of a defensible trail

    01

    Data provenance

    Every attribute with its source, retrieval method, timestamp and the identity of whoever supplied or amended it.

    02

    Check execution

    Each verification, registry retrieval and screening run: what ran, against which source and list version, when, and what it returned.

    03

    Configuration state

    The policy version, risk methodology version, rule set, thresholds and list scope in force at the moment of the decision.

    04

    Decision record

    The conclusion reached, the reasoning, the evidence relied on, the accountable person, the approver where required and the date.

    05

    Subsequent action

    Monitoring settings applied, review dates set, outreach issued, escalations raised and their outcomes.

    Recording decisions properly

    A decision record should be short but complete. Four elements make the difference between a note and evidence.

    • The question decided. Stated explicitly, for example whether the ownership chain is understood to the firm's standard.
    • The evidence relied on. Referenced items on the file, not a general assertion that evidence was reviewed.
    • The reasoning. Why the evidence supports the conclusion, including how contrary indications were treated.
    • Accountability. Who concluded, who approved where required, and when.

    Overrides deserve particular care: record the original outcome, the new outcome, the reason, the approver and any review date. Overrides are the first thing an experienced reviewer samples.

    Agora practitioner interpretation

    We would treat negative outcomes as first-class records. Firms routinely evidence the alerts they worked and the reviews they performed, then cannot show why a signal was evaluated and dismissed, or why a file went untouched during a period of change. In an event-driven operating model that absence becomes the central audit question.

    Configuration and versioning

    • Version the policy, the risk methodology, screening configuration, trigger logic and any models, each with an effective date.
    • Stamp each case with the versions in force when it was decided.
    • Keep change records: what changed, why, who approved it, what testing preceded it.
    • Retain superseded versions for as long as decisions made under them remain in scope.
    • Record list versions and refresh times for screening, so a past match or non-match can be explained.

    Testing the trail

    Reconstruction should be exercised, not assumed. Practical tests include sampling closed cases and attempting full reconstruction from the record; asking an independent reviewer with no prior knowledge to reach a view; timing how long retrieval takes; and reviewing whether the case report contains the reasoning or only the artefacts. This overlaps directly with the assurance design described in KYC quality assurance.

    Common pitfalls

    • Evidence spread across email, shared drives and case systems with no single retrievable record.
    • Screenshots without source, timestamp or the query that produced them.
    • Configuration edited in place with no history, so past outcomes cannot be explained.
    • Decisions recorded as status changes rather than reasoning.
    • Automated steps that log an outcome but not the inputs or rule version that produced it.
    • Retention that preserves documents while losing the system context needed to interpret them.

    Where technology helps

    Provenance capture, version stamping, immutable event logging and case report assembly are exactly what systems do well, and doing them manually at scale is not realistic. As CDD automation sets out, automation raises the importance of the trail rather than reducing it. The Agora Due Diligence Platform records each step against the case and produces a case report that assembles the evidence and the decisions in one place.

    Primary sources

    Frequently asked questions

    What makes a CDD audit trail defensible?

    That an independent reviewer can reconstruct a past decision without speaking to the people who made it: what information was held, where it came from and when, which policy and configuration version applied, what checks ran and with what outcome, who decided what, and what was done afterwards.

    Is storing the documents enough?

    No. Documents show what was collected but not what was concluded or why. A defensible trail links evidence to the assessment it supported, records the reasoning and identifies the accountable person and the date.

    Why does version control matter for CDD records?

    Because a decision can only be judged against the standard in force when it was made. If policy, risk methodology or system configuration changed without version history, a reviewer cannot tell whether a past outcome was correct at the time. The FCA's April 2026 findings identified weak version control among the weaknesses it observed.

    What should be recorded when a control produces no action?

    The signal or check performed, the configuration that evaluated it, the outcome, and the conclusion that no further action was needed. Negative outcomes are frequently the hardest part of a review to evidence and the most valuable to retain.

    How long should CDD records be kept?

    Retention is set by the applicable record-keeping requirements for the firm's sector and by its own data protection obligations, so firms should apply their documented retention policy rather than an informal practice. The important operational point is that retention must preserve the evidence in a retrievable, reconstructable form, not just in storage.

    Where the technology fits

    Agora is a technology provider: the platform supports the control described above, and your own teams operate it and hold the accountable decisions.

    Next step

    Can you reconstruct a decision from two years ago?

    See provenance, configuration versioning and case reporting working together in the Agora platform.