Web Project Studios

Field notes

The AML audit trail that looks complete until a solicitor actually requests it

15 June 2026

estate-agencyaml-complianceworkflow-design

A solicitor requests the AML file on a transaction that completed eight months ago. The agent pulls up the SmartSearch record. Green result, timestamp, name matched. It looks fine.

Then the solicitor asks for the decision log. When was the check run relative to instruction? Was there a PEPs or sanctions flag? If so, who reviewed it, and what did they conclude? What enhanced due diligence was applied, and why?

The agent has none of that. What they have is a green badge and a PDF they cannot interrogate.

This is where most AML workflows in estate agency actually live: compliant on the surface, hollow underneath. The check happened. The compliance did not.


This post discusses workflow design for AML processes. It does not constitute legal advice. If you are unsure whether your current procedures meet the requirements of the Money Laundering Regulations 2017, speak to a qualified compliance professional or your supervisory authority.


The Money Laundering, Terrorist Financing and Transfer of Funds (Information on the Payer) Regulations 2017 do not say "run a check." They require estate agents to apply customer due diligence measures, keep records of those measures, and be able to demonstrate ongoing monitoring of business relationships.

Regulation 40 is the one that bites in practice. It requires you to keep copies of the documents and information obtained during due diligence, and records of the steps taken to verify identity, for five years from the end of the business relationship. The word "steps" is doing a lot of work there. A pass result from a verification platform is evidence that a check ran. It is not evidence of the steps you took to reach a compliance decision.

The distinction matters most in three situations: a PEPs or sanctions match that was reviewed and cleared; a case where enhanced due diligence was triggered; and any transaction where the timing of the check is questioned. In all three, the solicitor or HMRC inspector is not asking whether you used a recognised tool. They are asking what you did with the result.

Most agents cannot answer that question because their workflow was designed around getting a green result, not around documenting a decision.

SmartSearch, Credas, and Thirdfort are all legitimate verification platforms. The problem is not the tools. The problem is what agents do, or do not do, after the check completes.

A typical workflow looks like this: instruction received, verification link sent to vendor or buyer, green result returned, file marked as AML complete. That sequence produces a timestamp and a match score. It does not produce a documented review.

What it is missing:

  • A record of when the check was initiated relative to the date of instruction (Regulation 28 requires CDD before establishing a business relationship, or as soon as reasonably practicable)
  • A note of any flags returned, even low-risk ones, and the agent's response to them
  • Evidence that a human reviewed the result rather than the system auto-clearing it
  • Any enhanced due diligence steps taken, with a rationale
  • The name and role of the person who made the compliance decision

The platforms will give you the raw data. None of them, by default, give you a structured decision record that satisfies an auditor's question: "Who decided this was acceptable, and on what basis?"

This is the phantom file. It exists. It just does not contain what it appears to contain.

PEPs and sanctions screening is where the gap becomes most visible. If SmartSearch or Credas returns a potential PEPs match, the agent typically sees a flag and clicks through to resolve it. Some platforms require a manual override. Most log that an override occurred.

What they do not log automatically is the reasoning. Was the match a false positive because of a common name? Was the individual a domestic PEPs at lower risk? Was enhanced due diligence applied? Did the agent escalate to a principal or compliance officer?

Under Regulation 35, enhanced due diligence is mandatory for PEPs. The obligation is not just to identify them. It is to apply additional scrutiny and document that scrutiny. A log entry that says "PEPs flag reviewed, cleared" is not documentation of scrutiny. It is documentation that a button was pressed.

If you have processed any transactions involving a PEPs match in the last five years and your record is a cleared flag with no accompanying decision note, your file is not complete. It looks complete. That is different.

Here is the structure I recommend agents build into their AML workflow, regardless of which verification platform they use. This is the minimum a solicitor or HMRC inspector should be able to reconstruct from your records.

aml_decision_record:
  transaction_ref: "WPS-2026-0341"
  client_name: "Jane Doe"
  client_type: "vendor"
  instruction_date: "2026-05-10"
  cdd_initiated_date: "2026-05-10"
  cdd_platform: "SmartSearch"
  check_completed_date: "2026-05-11"
  result: "pass"
  flags_returned:
    - type: "PEPs"
      detail: "Name match: John Doe (unrelated individual, different DOB)"
      reviewed_by: "Sarah Patel, Senior Negotiator"
      review_date: "2026-05-11"
      outcome: "false positive confirmed, no further action"
  edd_required: false
  edd_rationale: ""
  ongoing_monitoring_note: "No material change to risk profile as of 2026-06-15"
  record_owner: "Sarah Patel"
  record_date: "2026-05-11"
  retention_delete_after: "2031-05-11"

This is not a replacement for your verification platform's output. It sits alongside it. The platform gives you the check. This gives you the decision.

The workflow question is where this record lives and who creates it. If the answer is "in someone's head" or "in a free-text notes field in the CRM," you have a phantom file.

You do not need new software to fix this. You need a structured decision record that your existing tools can store and retrieve.

Week one. Pull five completed transaction files from the last twelve months. For each one, ask: can I produce the date the check was run relative to instruction, the name of the person who reviewed the result, and a note on any flags? If you cannot answer all three for any file, your current process has a gap.

Week two. Design a decision record template. The YAML above is a starting point. It needs to be simple enough that a negotiator will actually complete it at the point of instruction, not reconstruct it later. A form in your CRM, a structured note in your property management system, or even a shared document template will work. The format matters less than the habit.

Week three. Identify who owns the decision for each transaction type. The check can be automated. The decision cannot be. Someone with a name and a role needs to sign off on every CDD outcome, and that sign-off needs to be retrievable in five years.

Ongoing. Build a review step into your instruction workflow so that CDD completion and decision logging happen before the file moves to the next stage. Not after. Not at completion. Before.

The AML workflow post on this site covers the broader process design in more detail, including how to structure ongoing monitoring for long-running transactions. If you are also thinking about how AI tooling fits into compliance workflows without creating new gaps, the post on why most AI pilots fail is worth reading alongside this one.

The audit trail problem is a workflow design problem. The check is the easy part. The documented decision is where most agents stop short, and it is the only part that matters when someone actually requests the file.

If you want to map where your current AML process breaks down before a solicitor does it for you, the AI Workflow Audit is the place to start.


Money Laundering, Terrorist Financing and Transfer of Funds (Information on the Payer) Regulations 2017 (SI 2017/692) (full text). Regulations 28, 35, and 40 cited.

Sources verified on 2026-06-15. This post does not constitute legal advice.