SStratum APIs

For UK MLROs, AML supervision teams, and regulator stakeholders

What MLR-2017 inspection-acceptable audit evidence should look like in 2026

UK firms regulated under MLR-2017 face three converging pressures in 2026: higher screening expectations under LSAG-2025, higher inspection cadence at HMRC and SRA / CLC, and lower tolerance for fragile audit trails. Screenshots in folders, CSV exports without list-version timestamps, and PDFs without hash-binding all leave the inspector trusting the firm's word on integrity rather than verifying integrity from the evidence itself. This position paper sets out seven principles + a concrete format spec for what good looks like, and invites regulators into a public dialogue.

Seven principles for inspection-acceptable evidence

Hash-bound integrity (a SHA-256 the inspector can recompute against the cert content). Source-named provenance (OFSI, UN, EU, Companies House, MHCLG, EA named per signal). List-version stamping (the version of each list screened recorded on the cert). Server-side time-stamping (tamper-evident). Public verifier (a URL the inspector can hit independently of the firm to confirm cert integrity). Retention for the regulator window (7-year minimum; PITR-backed storage). Privacy-protective by default (the verifier confirms integrity without re-publishing PII). Each principle has a 60-second test the inspector applies on the day of the visit.

A concrete format spec

A single PDF with three logical sections (cover with cert ID + hash prefix + verifier URL, screening evidence per signal with source + list-version + result, footer with cert ID + page N of M repeated) plus a machine-readable JSON metadata dictionary embedded in the PDF or alongside as a sidecar. The full SHA-256 hash is computed over the canonical JSON form (sorted keys, ISO 8601 timestamps, no nulls) and the prefix is printed at the verifier URL. Inspector recompute matches printed hash; any post-fact edit fails the recompute. The verifier exposes integrity confirmation without exposing PII.

Why the principles are vendor-agnostic

The spec is small enough that any compliance vendor can implement it in 2-4 weeks; a regulator-published reference implementation (precedent: HMRC Making Tax Digital MTD reference clients) is also viable. Adoption across vendors + sectors makes the inspector's mental model consistent. We do not propose a new mandatory standard, a vendor lock-in, or a replacement for human compliance judgement; we propose a substrate the regulator + the regulated firm + the legitimate vendors all benefit from. The full paper at /docs/regulator-position-paper-2026-05-09.md (in our repo; happy to issue formally on request) covers regulator-engagement options + open questions.

Frequently asked

Is this a new mandatory standard?

No. The principles describe what good looks like; firms remain free to ship whatever audit format they choose. The spec is an opening offer for adoption, not a requirement. We lean toward a "recognised pattern" first step (regulators publicly acknowledge that certs meeting the principles satisfy MLR-2017 audit-trail expectations) rather than a formal mandate.

Should the verifier be regulator-hosted or vendor-hosted?

Vendor-hosted is the easier first step + matches the format. Regulator-hosted (eg an HMRC-operated verifier) would centralise the integrity surface but adds operational overhead. A middle path: regulators publish a list of recognised vendor verifier domains; inspectors check the domain is on the list before trusting the response.

Does this work outside letting + conveyancing?

Yes. The principles + format are sector-agnostic. The same hash-bound + source-named + list-version + verifier shape works for sanctions screening on a fintech onboarding, a wealth-manager client-acceptance, an accountant's new-engagement file, an art-market-participant transaction. Adoption across sectors strengthens the inspector's mental model.

How does this interact with EDD documentation?

EDD under MLR-2017 reg 19 can produce material too sensitive to ship in the same audit-cert (eg source-of-funds, ID-verification photos). The cert format records that EDD was performed + names the sensitive material; the actual material lives in the firm's separate secure document store. The cert is the integrity layer; the documents themselves stay with the firm.

How can a regulator engage with this?

We invite SRA, CLC, HMRC AML supervision team, FCA Consumer Duty oversight (and equivalents in Scotland, Wales, Northern Ireland) to read the spec, test the format against synthetic data (we will issue 5-10 reference certs free of charge), open a dialogue on whether the format should be acknowledged in the next LSAG / SRA / CLC / FCA AML supervision refresh, and refine the spec with us before publication. Contact: support@stratumapis.com.