Cryptographic MLRO signoff. Verifiable by anyone.

Under FCA SMCR and the MAS individual-accountability regime, MLROs can be personally fined or banned from regulated roles for financial-crime control failures. The defense file an MLRO attaches to a contested decision is, in those regimes, the artifact that determines whether the personal-liability question is even serious.

In October 2024, the FCA fined Starling Bank £28.96m for AML and sanctions-screening control failures. Its Final Notice reinforced what regulators look for: clear audit trails of remediation and a senior manager who is accountable for financial-crime controls. That enforcement action made clear that the quality of a firm's defense file is itself a regulatory test point, not just the decision recorded in it.

Most compliance tools that produce defense files produce them as editable Word documents or PDF exports. There is no cryptographic binding between "the evidence at the moment of decision" and "the signature attached to it". A defense file modified six months after signing is functionally indistinguishable from one signed at the original time.

The OilFlow Defense Pack ledger fixes this. The signoff hash is computed at the moment of signing and stored on the row. Any later edit to the evidence, the narrative, the decision basis, the attestation, the signer name, or the signoff timestamp will break the hash. The regulator does not need to trust OilFlow; the verification can be performed independently from the raw row data.

At sign time, the POST /api/v1/defense/[request_id]/sign endpoint constructs a payload object from the following ordered fields:

1. 01request_id
2. 02counterparty_normalized
3. 03decision
4. 04decision_basis_summary
5. 05evidence_pack
6. 06narrative
7. 07signoff_by
8. 08signoff_at
9. 09signoff_attestation

The payload is canonicalized using a deterministic JSON serialization (recursive key-sort on objects, original order on arrays, standard JSON encoding for primitives). The SHA-256 digest of the canonical byte sequence is stored in the signoff_hash column on the defense_packs table (migration 164). The algorithm is published below; the source file is at platform/src/app/api/v1/defense/[request_id]/sign/route.ts.

function canonicalize(value):
  if value is null or primitive:
    return JSON.stringify(value)
  if value is array:
    return "[" + value.map(canonicalize).join(",") + "]"
  // object: sort keys alphabetically, then recurse
  keys = sorted(value.keys())
  parts = keys.map(k => JSON.stringify(k) + ":" + canonicalize(value[k]))
  return "{" + parts.join(",") + "}"

signoff_hash = sha256_hex(
  canonicalize({
    request_id, counterparty_normalized, decision,
    decision_basis_summary, evidence_pack, narrative,
    signoff_by, signoff_at, signoff_attestation
  })
)

The approach is the same idea as RFC 8785 (JSON Canonicalization Scheme) at a small scale. We control both producer and verifier so we do not need the full RFC; we only need "two identical payloads always produce identical bytes." The canonical serializer ships in both the sign route and the verify route, with identical implementations for cross-checking.

MLROs occasionally need to rescind a previously-signed pack — new evidence surfaces, a counterparty is later sanctioned, an escalation was missed. The rescind path on the OilFlow Defense Ledger is intentionally append-only.

Rescinding flips signoff_status to rescinded and stores the rescission attestation. It does NOT touch the original signoff_hash, signoff_by, or signoff_at. The cryptographic binding from the original moment of decision survives the rescission. A regulator can ask "at the time this MLRO signed this pack, what evidence did they have?" and get an answer that is independently verifiable years later, even if the underlying counterparty was subsequently re-classified.