Operational resilience, third-party risk and trustworthy decision evidence.
FCA, PRA and EU AI Act requirements create different obligations. Secoya does not establish compliance with any of them; it provides technical evidence controls that can strengthen an organisation’s ability to demonstrate what occurred and preserve verification context through operational change.
FCA SYSC 15A and PRA SS2/21
FCA SYSC 15A — operational resilience
FCA SYSC 15A requires in-scope firms to identify important business services, map the people, processes, technology, facilities and information needed to deliver them, and test severe-but-plausible disruption. That testing includes scenarios involving the unavailability of third-party services critical to an important business service. Firms must be able to remain within their defined impact tolerances.
PRA SS2/21 — outsourcing and third-party risk management
PRA SS2/21 sets supervisory expectations for PRA-regulated firms concerning material outsourcing and third-party risk management. These include appropriate access, audit and information rights, business-continuity planning, and viable planned and stressed exit strategies. It is a supervisory statement explaining PRA expectations, not a claim that software alone can establish compliance.
Secoya is designed to make selected historical evidence portable and its integrity independently testable when the original application or Secoya is unavailable, provided the verifier has the necessary authenticated trust material and an independently accepted trust anchor. This may support a firm’s wider resilience, audit and exit evidence; it does not keep an entire important business service operating and does not replace contractual audit or exit rights.
Primary sources: FCA Handbook — SYSC 15A and Bank of England — PRA SS2/21.
Your logs record what happened. Can an independent reviewer trust them?
Article 12 requires high-risk AI systems to support automatic event logging. It does not prescribe Secoya or require cryptographic sealing. This logging and traceability obligation is distinct from the FCA and PRA outsourcing, resilience and exit framework.
When the high-risk obligations apply
The EU’s AI Omnibus entered into force on 27 July 2026 and changed the implementation timetable. Earlier summaries that give 2 August 2026 as the general Article 12 deadline are now out of date.
| Date | Position |
|---|---|
| 2 Aug 2026 | Article 50 transparency obligations begin applying; this is not the general high-risk Article 12 date. |
| 2 Dec 2027 | High-risk rules apply to the Annex III categories, including biometrics, critical infrastructure, education, employment and access to essential services. |
| 2 Aug 2028 | High-risk rules apply to AI systems embedded in regulated Annex I products. |
Article 19 requires providers to keep automatically generated logs under their control for a period appropriate to the system’s intended purpose and for at least six months, unless applicable EU or national law provides otherwise. Article 26(6) imposes the corresponding minimum on deployers for logs under their control.
Primary sources: European Commission — AI Omnibus enters into force and Regulation (EU) 2024/1689.
Logging and evidential integrity are different controls.
Article 12 requires technical logging capabilities that support traceability, post-market monitoring and operational monitoring. An ordinary application log may satisfy important parts of that requirement. But its evidential weight can still depend on the surrounding access controls, retention system, administrators and vendor platform.
- Observability systems are designed to collect, search and correlate events; they do not automatically bind a business decision to the authority and policy in force.
- Write-once storage can provide strong retention controls, but independent review still depends on the storage platform and its configuration.
- A signature proves control of a signing key, not the truth of the signed statement or the completeness of the surrounding event history.
Secoya is designed to complement required logs by creating portable, tamper-evident records for selected high-consequence decisions. Those records can be checked outside the originating application using the required authenticated trust material and a trust anchor independently accepted by the verifier. Secoya does not, by itself, establish AI Act compliance.
Change the payload and watch its digest stop matching.
This small browser exercise demonstrates one integrity layer: a SHA-384 digest over a deterministic representation of five fields. It is not a complete Secoya Trust Record verification and it does not verify Ed25519 or ML-DSA-65 signatures. The full demonstration is available on the verification demo.
——The initial digest is established when this page loads. Edit a field to demonstrate detection; reload the page to reset it.
What the current Secoya build establishes.
Established by the implementation
- Changes to protected payload or metadata are detected.
- Signatures bind algorithm, key, authority and declared signing time.
- A relying party can enforce its own acceptance policy.
- Shared conformance material has been reproduced through separate TypeScript, Python and Rust implementations.
- Historical continuity and independence decisions have been reproduced by a reference implementation and a separately authored internal clean-room implementation.
Not established yet
- That the signed statement is factually true.
- Trusted external time or production protection against record deletion.
- Production key custody, durable replay protection or registry operation.
- Independent cryptographic audit, legal admissibility or regulatory compliance.
- Production assurance from a completed customer pilot.
The transparency demonstration shows how independently retained signed tree heads can expose deletion, rollback and rewritten observed history. It is an in-browser model, not a production transparency service. Detailed versions and results are maintained in the technical reference.
Start with one consequential approval.
One controlled workflow, one decision boundary and verification by your own team. The pilot determines the KMS, replay scope, retention period, timestamp jurisdiction and registry arrangement required for the real deployment.