Regulator-readable evidence — what is auditable, what stays operator-side

1. The boundary, named

Audit-readiness is a question of which artefacts can be cited and which artefacts remain in the operator’s or vendor’s gated domain. The boundary EEI draws is principled and stable across jurisdictions:

• Publishable — what a regulator can read without any access request, cite in their own publications, and re-run inside their own perimeter.
• Gated — what stays under operator control (the corpus, the operator’s policy of record) or available through the spec-access process (the full normative spec body).

Every artefact that bears on the correctness of the architecture is on the publishable side. Every artefact that bears on the specifics of an operator’s deployment is on the gated side. This is the right cut for both regulator and operator.

2. Publishable — what a regulator can audit against

The publishable set is the shape of each artefact, not the artefact itself:

• Wire-shape description. The structural framing of the Evidence Token — JWS-compact, ES256, two profiles — published in evidence-token-format.
• Verifier contract shape. The eight-stage pipeline as a contract — stages, order, failure-class structure — published in verification-pseudocode.
• Cross-language conformance property. The fact that four reference verifiers across four runtimes share one corpus and produce identical verdicts. See cross-language-test-vectors.
• Public spec TOC. /specification — sections, annexes, the eight-step verifier contract enumerated, the four reference verifiers listed.
• Standards-alignment grid. Rows on /specification mapping spec sections to RFC 2119, RFC 7515, RFC 4648 §5, RFC 6979, ISO 8583, EMV / EMV 3DS, and POPIA’s data-minimisation condition. Threat-modelling methodology (STRIDE) is listed separately on the spec TOC as the modelling register the threat-model section uses, not as an alignable standard.

3. Gated — and why

The gated set is also fixed:

• The full Evidence Token corpus for any specific deployment. Held by the operator under jurisdictional retention rules (POPIA [1], NDPA 2023 [2], analogous frameworks in the operator’s jurisdiction). The regulator may inspect it under the legal basis the jurisdiction provides; EEI does not interpose between operator and regulator.
• The operator’s policy document. Verdict rules — overlay → step-up, debugger → block, etc. Authored by the operator, accountable to the operator. The regulator audits the operator’s policy directly, not through EEI.
• The full normative spec body. YEI-001 sections and annexes — including the Evidence Token JSON Schema, the verifier pseudocode in RFC 2119 register, the per-stage failure-constant enum (the named codes the eight verifier stages emit on a failed check), and the signing-input construction rules (per RFC 7515 §5.1; no JSON canonicalisation step is required on the verifier side). The high-level signal class set (device.integrity, runtime.environment, code.integrity, binding.status, network.identity, plus surface-state classes such as overlay.detected and accessibility.active) is publishable as part of the wire-shape description; what stays gated is the per-stage verifier failure-constant enum that drives conformance, not the abstract signal categories. Maintained in the normative specification; available through the spec-access process.
• The conformance test corpus. Held in the spec repository alongside the four reference verifiers. Not publicly linked at this stage, as the corpus is the conformance bar; available through the spec-access process.
• The public-key registry. Operator-side. Not surfaced outside the operator’s verification path.

4. Why this boundary works

For a regulator, the public artefacts are sufficient for architectural pre-qualification: they confirm what is signed is what the spec says is signed, that the verifier checks what the spec says it checks, and that four independent runtimes agree on the verdict. Full audit, certification, or dispute replay requiring the normative schema, verifier corpus, or operator-held evidence proceeds under the applicable access process — for the normative spec body, through the spec-access process; for operator-held corpora, through the operator directly. (The per-stage failure-constant enum is maintained in the spec body for corpus-drift reasons, not because it bears on architectural correctness.) The regulator does not need anything from YinkoShield at audit time to perform the architectural pre-qualification.

For an operator, the audit shape is also straightforward: the policy document and the corpus the regulator wants to examine are theirs to provide, on their schedule, under their data-processing posture. EEI does not insert itself.

For YinkoShield, the boundary is structural: the supplier of the runtime has nothing to disclose at audit time because the supplier holds nothing. That is consistent with the custody story enumerated in local-key-custody.

5. Standards alignment — what the regulator sees

The eight standards rows on the public spec TOC are the framing the regulator reads first. The relevant rows for audit-readiness:

• RFC 7515 (JWS) — wire format. Confirmed by re-parsing any token with off-the-shelf JOSE tooling.
• RFC 6979 (deterministic ECDSA) — signing-side integrity property where the platform exposes it. The reference signer uses RFC 6979 deterministic nonce generation; hardware-backed signers commonly available on mobile (Android Keystore, Apple Secure Enclave) typically use CSPRNG-sourced k under the FIPS 186-4-era construction (FIPS 186-5, February 2023, now also permits the RFC 6979 deterministic construction for certified hardware), which produces non-deterministic but valid signatures. Where deterministic, the property is confirmed by reproducing test-vector signatures; in all cases, verification is deterministic and the signature is verifiable against the device’s public key regardless of how the signer’s nonce was produced.
• POPIA §10 (minimality) — privacy profile. Confirmed by mapping the published category set against POPIA’s data-minimisation principle, which sits under Condition 2 (Processing Limitation, §§9–12) — not Condition 3 (Purpose Specification, §13).
• PSD2 RTS on SCA [3] (when applicable) — Strong Customer Authentication evidentiary scope. Confirmed by mapping signal classes to the RTS authentication-element categories: Article 6 (knowledge), Article 7 (possession), Article 8 (inherence). Article 9 — independence of the elements — is a separate requirement on the relationship between elements rather than a fourth category, and is verified by the operator’s SCA design rather than by the signal stream.
• ISO 8583 [5] — the operator-side authorisation-rail message format. The alignment is downstream: the operator’s verifier output (verdict input record) feeds into the authorisation request the operator builds in ISO 8583, with tctx joinable to the operator’s own ISO 8583 fields. EEI does not produce an ISO 8583 message; the alignment is “verifier output → operator’s ISO 8583 construction”.
• EMV / EMV 3DS [5] — the alignment is composition, not substitution. EMV ARQC and EMV 3DS device-information categories are the rail-side artefacts; signal classes are the runtime-side artefacts. The alignment grid records which signal class composes with which rail-side category in the operator’s combined risk decision.
• ISO/IEC 27001 [4] is not on the alignment grid. Compliance certifications are out of scope by design (see /about); operator-side controls remain operator-side.

6. What this article is not

It is not a compliance checklist. EEI does not aggregate jurisdictional rules into an operator-facing playbook; that is the operator’s compliance function’s responsibility, sometimes done with external counsel. EEI provides the cryptographic and architectural inputs the operator’s audit answers cite.

7. Cross-references

• Sibling articles: evidence-token-format, dispute-evidence-workflow
• Architecture: /architecture/sovereign-verification, /specification
• Theme 5: local-key-custody, signal-vs-verdict-separation

8. External references

[1] Republic of South Africa. Protection of Personal Information Act (POPIA). popia.co.za. Cited 2026-05-04.

[2] Federal Republic of Nigeria. Nigeria Data Protection Act (NDPA) 2023. ndpc.gov.ng. Cited 2026-05-04.

[3] EBA. RTS on Strong Customer Authentication (Commission Delegated Regulation (EU) 2018/389). eba.europa.eu/regulation-and-policy/payment-services-and-electronic-money. Cited 2026-05-04.

[4] ISO. ISO/IEC 27001:2022 — Information security management. iso.org/standard/82875.html. Cited 2026-05-04.

[5] EMVCo. EMV Specifications — Books 1–4, EMV 3DS, Payment Tokenisation. emvco.com/specifications. Cited 2026-05-04.