Three lines of defence inside a regulatory change platform: what is acceptable in inspection

Most regulatory change platforms claim to “support the three-lines-of-defence model”. What that phrase covers in practice ranges from genuinely useful to frankly cosmetic. This article is a pragmatic guide to the difference, written for compliance and internal-audit leaders who are evaluating vendors, and for regtech builders who want to know what bar an inspector will actually set. The reference governance text is the Institute of Internal Auditors Three Lines Model(2020), with the prudential expectation fleshed out by the EBA Guidelines on internal governance (EBA/GL/2021/05) and the national-authority expectations embedded in BaFin MaRisk and ACPR's AMF-ACPR procédures guidance.

What the model says, in two paragraphs

The 3LoD model assigns three distinct roles. The first line owns the risk and manages it as part of doing business. In regulatory change, that is the head of a function — compliance, regulatory affairs, operational risk, financial crime — committing to whether a change applies, to whom, by when, with what severity and what evidence. The second linechallenges the first line's work independently. In regulatory change, that is an independent Compliance or Risk reviewer either countersigning the 1LoD's conclusion or returning it with a documented challenge. The third line provides assurance to the management body that the first two lines are doing their job. In regulatory change, that is internal audit reviewing the chain and producing an opinion.

The point of the model is independence: each line must be able to dissent from the one before. A process that records only the final agreed decision is not 3LoD — it is a signature line with a paper trail. A process that records the 2LoD challenges, the 1LoD re-works, and the management-body oversight is 3LoD.

What “3LoD support” actually means in vendor marketing

When scanning vendor decks, we see four levels of maturity claimed under the same label. The following table is our working taxonomy; use it to slice through the marketing.

Most vendors are L1 or L2 today. A handful are L3. Very few are L4. RegRadar targets L4 — see the three-lines-of-defence methodology for the SHA-256 schema and the verification pseudo-code.

The five most common 3LoD failure modes in regtech

1. The 2LoD is the same person as the 1LoD, wearing a different hat

A small compliance team is tempted to let one senior person sign both lines because the alternative is delay. Platforms that allow this explicitly or implicitly (shared accounts, role-switching inside a session) are a ticking finding. A defensible setup either blocks same-person 2LoD at the API layer or forces documented delegation with an expiry date.

2. The challenge return is a comment thread, not a recorded event

Many platforms handle disagreement by letting the 2LoD add a comment and send the impact back to the 1LoD queue. Inspection-grade 3LoD requires the challenge itself to be a hashed record: who challenged, when, why, against which version of the 1LoD signoff. If the 1LoD then revises and re-signs, the chain now contains four events (original 1LoD, 2LoD challenge, revised 1LoD, 2LoD countersign), each hashed. That is the audit trail inspection will look for — and the one that survives a call-out two years later.

3. Evidence lives outside the chain

A signoff that says “rationale: see the email from Fabien dated 2025-11-04” is not a signoff. Evidence attached by reference — a URL to an internal policy version, a document ID in the document management system, or a content-hash of an attached PDF — is chain-native. The 1LoD signature binds that reference to the signed payload, and the hash is over the reference. If the underlying document disappears, the reference breaks loudly; if someone substitutes a different policy at the same URL, the content hash on the signed payload fails to match. Evidence that is “somewhere in the team inbox” fails both tests.

4. 3LoD is granted write access

The third line's value is its independence. A platform that lets internal audit edit rationales, re-assign owners, or fix typos in a signed impact cannot produce a defensible report. 3LoD access should be explicitly read-only at the authorisation layer, with a separate export capability for snapshot generation. Any audit log entry tagged to a 3LoD user should be read-only action types (view, export, annotate-external).

5. No way to recompute the chain outside the platform

The strongest test of L4 maturity is this: can I (the customer) take a JSON export from your platform today, and in three years — when your platform version has changed, when my IT team has rotated, when the original signers have moved on — still recompute every signoff hash and confirm the chain is intact? If the verification code is a vendor-held binary, the answer is no. The verification algorithm needs to be documented (SHA-256 over a canonical-JSON representation), and the canonicalisation rules need to be stable. RegRadar publishes the verification pseudo-code and has tested the round-trip against six-month-old exports.

What inspection actually looks at

We have walked four banking supervisors and two EMI supervisors through signed chains in the past year. The patterns they probe are consistent:

1. Pick a specific obligation from the register.“Show me DORA Art. 17 — who owns it, when was it last reviewed, what's the evidence.”
2. Follow the chain to the impact that established it.“Show me the impact that first classified Art. 17 as applicable. Who signed 1LoD, who countersigned 2LoD, is there a challenge in between.”
3. Ask for the signed payload and hash.“Can I see the JSON representation of signoff #1784 and verify its hash.”
4. Ask the same for a challenge return.“Show me a case where the 2LoD sent the 1LoD back. Walk me through the four events.”
5. Ask about delegation.“Show me a signoff that was delegated. Where is the delegation window recorded, and who approved it.”
6. Ask to export the chain.“Produce the Audit Snapshot for the last twelve months. We'll have our auditor recompute the hashes offline.”

A checklist for compliance leaders buying a platform

1. Can I point to the database column that stores the signoff hash? What algorithm? Over what payload?
2. Is same-person 2LoD blocked at the API or only in the UI?
3. Is a 2LoD challenge return a first-class hashed event, or a comment on the 1LoD signoff?
4. Can 3LoD be configured as read-only end-to-end?
5. Can I export the full chain as JSON and re-verify it without the vendor's help? Is the verification algorithm documented?
6. How does the platform handle delegation during planned absence — with documented windows and expiry checks at signoff time, or with shared accounts?
7. Does each signoff carry the current tenant profile hash, so I can identify decisions made against a stale profile after an in-scope regulation change?
8. Is the audit export tamper-evident beyond the chain — can I verify the export itself has not been edited in transit?

A checklist for regtech builders

1. Start with the schema. A four-column signoff table with previous_signoff_id and signoff_hash is the floor.
2. Canonicalise your JSON representation early. Dictionary key order, null handling, Unicode normalisation — pick one and document it.
3. Treat the 2LoD challenge as a commit, not a comment. Emit an event, hash it, link it back.
4. Write and test the offline verifier. Ship it as an open-source Python script. Customers should be able to run it in a Jupyter notebook in ten minutes.
5. Expose the verification status in the UI. “Chain integrity valid as of 2026-04-22 14:12 UTC” on the Audit page, recomputed on every export.
6. Log every 3LoD interaction as read-only action types; reject writes at the authorisation layer.

Closing

The test for whether a regtech platform really supports 3LoD is not how many roles it shows in the sidebar; it is whether an inspector's auditor can walk away with a JSON file, re-verify the chain on their own laptop, and get a green check. If the platform cannot survive that test, the compliance team is still the one holding the risk — they just have a prettier spreadsheet.