Executive Summary
The European Commission's November 2025 Digital Omnibus proposal has fundamentally restructured the EU AI Act's enforcement timeline, but this apparent reprieve masks a critical strategic inflection point. The proposed delay of high-risk AI system requirements from August 2, 2026 to a backstop date of December 2, 2027 creates a narrow window—not for complacency, but for building verification infrastructure that will define competitive advantage when enforcement begins.
This analysis examines three recent regulatory developments that directly impact algorithmic trading operations:
- Digital Omnibus Package (November 19, 2025): The proposed 16-month enforcement delay and its conditional nature
- CEN-CENELEC Acceleration Decision (October 23, 2025): Harmonized standards development and prEN ISO/IEC 24970 (AI System Logging)
- Article 73 Serious Incident Reporting Guidance (September 26, 2025): Correct reporting timeframes and implications for trading systems
Table of Contents
I. The Digital Omnibus Package: A "Stop-the-Clock" Mechanism, Not a Holiday
1.1 The Proposal's Context
On November 19, 2025, the European Commission published the Digital Omnibus on AI (COM(2025) 836 final, 2025/0359 (COD)), a legislative proposal that introduces significant modifications to the EU AI Act's enforcement timeline. Contrary to some industry commentary suggesting this represents a fundamental retreat from AI regulation, the proposal is better understood as a pragmatic acknowledgment that regulatory infrastructure has not kept pace with legislative ambition.
The core trigger for this proposal was the acknowledged failure of harmonized standards development to meet original deadlines. CEN-CENELEC's Joint Technical Committee 21 (JTC 21), responsible for developing technical standards under Standardisation Request M/593 and its January 2025 Amendment M/613, confirmed in October 2025 that standards would not be available until Q4 2026—well past the original August 2026 enforcement date for high-risk AI systems.
1.2 The Backstop Mechanism Explained
The Digital Omnibus introduces a conditional enforcement mechanism that operates as follows:
For Annex III High-Risk AI Systems (Article 6(2)):
- Obligations take effect 6 months after the European Commission confirms that adequate compliance support measures exist
- Regardless of when such confirmation occurs, obligations apply no later than December 2, 2027 (backstop date)
For Annex I High-Risk AI Systems (Article 6(1), product-integrated AI):
Final backstop date: August 2, 2028
Asymmetric Risk Warning
This mechanism creates asymmetric risk for organizations planning compliance timelines. If harmonized standards arrive in early 2027, the 6-month implementation window could begin immediately, leaving minimal preparation time for organizations that waited for "certainty."
1.3 Financial Services Implications
Financial services AI systems remain firmly within Annex III's high-risk classification. Explicitly enumerated categories include:
- Credit scoring and creditworthiness evaluation (Annex III, Point 5(b)): AI systems used to assess natural persons' creditworthiness or establish credit scores
- Insurance pricing and risk assessment: AI systems used for evaluating and pricing life and health insurance policies
While algorithmic trading systems are not directly named in Annex III, compliance officers at major financial institutions increasingly classify AI-driven trading as high-risk based on:
- Article 6's general high-risk criteria: Systems posing significant risks to health, safety, fundamental rights, or property
- Article 73's serious incident reporting scope: Market disruption events fall under "serious and irreversible disruption to critical infrastructure management and operation"
1.4 Legislative Timeline
| Milestone | Expected Date |
|---|---|
| Proposal Published | November 19, 2025 |
| Public Consultation | November 19, 2025 – January 14, 2026 |
| European Parliament Committee Review | Q1-Q2 2026 |
| Parliament/Council Negotiations | Q2-Q3 2026 |
| Expected Adoption | H2 2026 |
| Entry into Force | 20 days after OJEU publication |
Critical Uncertainty
If the European Parliament and Council cannot adopt the Omnibus before August 2, 2026, the original AI Act deadlines remain in effect. Organizations relying on the proposed delay without contingency planning face immediate compliance exposure.
II. CEN-CENELEC Harmonized Standards: The prEN ISO/IEC 24970 Imperative
2.1 The October 2025 Acceleration Decision
On October 23, 2025, following the 105th CEN Technical Board and 181st CENELEC Technical Board meetings (October 14-16, 2025), CEN-CENELEC announced an exceptional package of measures to accelerate AI standards delivery.
The acceleration measures include:
- Specialized Drafting Groups: New structures to enhance technical coordination before Public Enquiry stages
- Expedited Publication Procedures: Direct publication after positive Public Enquiry results, with comment responses incorporated in subsequent editions
- Target Delivery: Q4 2026: Revised timeline for availability of core AI Act harmonized standards
2.2 prEN ISO/IEC 24970: AI System Logging
The most relevant standard for algorithmic trading compliance is prEN ISO/IEC 24970 (Artificial Intelligence — AI system logging), which entered Draft International Standard (DIS) ballot in August 2025, with formal publication expected in Q4 2026.
Key Definitions
- AI system logs: Records of information related to AI system activities, supporting current or future retrieval, analysis, monitoring, and decision review
- Logging components: Functional elements supporting log data generation, acquisition, formatting, storage, and management
Core Requirements
- Timestamped events: All logged events must include temporal markers
- Traceability markers: Mechanisms enabling reconstruction of decision chains
- Data integrity checks: Verification that log data has not been modified
- Interpretability: Logs must be understandable to authorized reviewers
2.3 The Standards Gap
While prEN ISO/IEC 24970 provides essential guidance on what to log and how to structure logging systems, it notably does not mandate cryptographic verification mechanisms. The standard requires logs to be "stored securely" with "strict access controls," but this addresses only external threats—not internal modification by authorized personnel.
VCP v1.1 Solution
VCP v1.1 addresses this gap by adding cryptographic immutability on top of standard logging requirements. Where ISO/IEC 24970 requires secure storage, VCP requires mathematically verifiable integrity through its three-layer architecture.
III. Article 73 Serious Incident Reporting: Correcting the 72-Hour Myth
3.1 The Serious Incident Definition
EU AI Act Article 3(49) defines a "serious incident" as any incident or malfunction of an AI system that directly or indirectly leads to:
- The death of a person or serious damage to health
- A serious and irreversible disruption to critical infrastructure management/operation
- A breach of EU law obligations intended to protect fundamental rights
- Serious damage to property or the environment
For algorithmic trading systems, relevant scenarios include:
- Market disruption: High-frequency trading system malfunction causing exchange-level disruption (category 2)
- Discriminatory credit scoring: AI systematically excluding protected groups (category 3)
- Flash crash events: AI-driven cascades causing significant property damage (category 4)
3.2 Correcting the Reporting Timeline Myth
CRITICAL CORRECTION
Many industry sources incorrectly state that AI Act serious incidents must be reported within 72 hours. This is factually incorrect—a confusion arising from GDPR Article 33 (personal data breach notification, which is 72 hours) and NIS2 Directive requirements.
The correct reporting timelines under EU AI Act Article 73 are:
| Severity Level | Reporting Deadline | Legal Basis |
|---|---|---|
| Standard serious incidents | 15 days | Article 73(2) |
| Incidents resulting in death | 10 days | Article 73(4) |
| Widespread fundamental rights breach OR serious/irreversible critical infrastructure disruption | 2 days | Article 73(3) |
3.3 Evidence Requirements
Serious incident reports must include:
- AI system identification (name, version, Unique Device Identifier)
- Incident occurrence date and awareness date
- Impact severity assessment
- Causal relationship evaluation (critical for trading systems)
- Remediation measures taken or planned
For algorithmic trading systems, demonstrating causation requires:
- Complete audit trail of AI decisions leading to the incident
- Model version and parameters at the time of execution
- Input data that drove the decision
- Human oversight interventions (if any)
- Third-party verification capability
This is precisely where VCP's value proposition becomes critical. Without cryptographic audit trails, firms cannot definitively establish causation—leaving them vulnerable to both over-reporting (generating regulatory noise) and under-reporting (risking enforcement action).
IV. VCP v1.1: A Technical Response to Regulatory Demands
4.1 The Three-Layer Architecture
VCP v1.1 introduces a comprehensive three-layer integrity architecture explicitly designed to meet regulatory requirements at each evidence level:
Layer 1: Event Integrity
Purpose: Establish what was recorded at the individual event level.
Implementation:
- Each VCP event generates a SHA-256 hash (EventHash) of canonicalized event data following RFC 8785
- This hash serves as a unique fingerprint—any modification produces a completely different hash value
- VCP-CORE defines mandatory fields: EventID (UUIDv7), TraceID, Timestamp, AccountID
Regulatory Alignment: Addresses prEN ISO/IEC 24970's data integrity check requirements.
Layer 2: Collection Integrity
Purpose: Prove completeness of event sets and detect omissions.
Implementation:
- VCP batches events into Merkle trees following RFC 6962 conventions
- Domain separation (leaf: 0x00 prefix, internal: 0x01 prefix) prevents second-preimage attacks
- Each batch produces a Merkle root representing the cryptographic fingerprint of the entire collection
Regulatory Alignment: Addresses EU AI Act Article 12's automatic recording and traceability requirements.
Layer 3: External Verifiability
Purpose: Prove when records existed and who created them, without requiring trust in the log producer.
Implementation:
- Ed25519 digital signatures (default) authenticate event origin
- External anchoring commits Merkle roots to third-party timestamping services or distributed ledgers
- Anchor frequency varies by tier: 10 minutes (Platinum), 1 hour (Gold), 24 hours (Silver)
Regulatory Alignment: Implements "Verify, Don't Trust" principle required for third-party verification.
4.2 VCP v1.1 Changes from v1.0
| Change | Protocol Compatibility | Certification Impact |
|---|---|---|
| PrevHash → OPTIONAL | ✅ Fully compatible | Relaxation (no impact) |
| External Anchor → REQUIRED | ✅ Fully compatible | ⚠️ Silver tier must add anchoring |
| Policy Identification → REQUIRED | ✅ Fully compatible | ⚠️ All tiers must add field |
4.3 Extension Modules for Regulatory Compliance
VCP-CORE (Mandatory)
Provides foundational event structure:
- EventType: SIG (signals), ORD (orders), EXE (executions), ACK (acknowledgments), REJ (rejections), CXL (cancellations)
- VenueID, Symbol, Side, Quantity, Price
- Cryptographic chain fields: PrevHash (optional in v1.1), EventHash (mandatory)
VCP-GOV (Governance)
Captures AI governance metadata for EU AI Act Article 13 (transparency) and Article 14 (human oversight):
- ModelID, ModelHash (SHA-256 of model parameters at execution time)
- DecisionFactors (input features driving decisions)
- ConfidenceScore, OperatorID, LastApprovalBy (human oversight chain)
VCP-RISK (Risk Management)
Records risk management decisions for RTS 6 compliance and Article 73 incident causation:
- Position limit checks and margin calculations
- Pre-trade risk control triggers
- Error Event Types (NEW in v1.1):
ERR:RISKevents withSeverity: CRITICALfor risk limit violations
VCP-XREF (Cross-Reference)
Enables dual logging between independent parties:
- CrossReferenceID links events across separate VCP streams
- Detects discrepancies impossible to identify with single-party logging
- Provides non-repudiation evidence for disputes
| Scenario | Party A | Party B | Benefit |
|---|---|---|---|
| Prop Trading | Trader | Prop Firm | Prevents payout disputes |
| Broker Execution | Algo Provider | Broker | Best execution verification |
| Regulatory Audit | Trading Firm | Regulator | Independent verification |
4.4 Timing Requirements Alignment
VCP v1.1's clock synchronization requirements exceed MiFID II RTS 25 mandates:
| Tier | Protocol | Precision | ClockSyncStatus |
|---|---|---|---|
| Platinum | PTPv2 (IEEE 1588-2019) | ±1 microsecond | PTP_LOCKED required |
| Gold | NTP/Chrony | ±1 millisecond | NTP_SYNCED required |
| Silver | System clock | — | BEST_EFFORT permitted |
4.5 External Anchoring Requirements
| Tier | Frequency | Anchor Target | Proof Type |
|---|---|---|---|
| Platinum | 10 minutes | Blockchain or RFC 3161 TSA | Full Merkle proof |
| Gold | 1 hour | RFC 3161 TSA or attested database | Merkle root + audit path |
| Silver | 24 hours | Public timestamping service | Merkle root only |
V. Regulatory Mapping: VCP v1.1 to EU AI Act Requirements
| EU AI Act Requirement | VCP v1.1 Implementation | Compliance Level |
|---|---|---|
| Article 12 (Record-keeping) | Three-layer architecture + External Anchor | ✅ Full compliance |
| Article 13 (Transparency) | VCP-GOV extension (ModelID, DecisionFactors) | ✅ Full compliance |
| Article 14 (Human oversight) | VCP-GOV (OperatorID, LastApprovalBy) | ✅ Full compliance |
| Article 17 (Quality management) | Policy Identification, VCP-RISK | 🔄 Integration-ready |
| Article 72 (Post-market monitoring) | Continuous event capture, VCP-RECOVERY | 🔄 Infrastructure support |
| Article 73 (Incident reporting) | Error Event Types, VCP-XREF, causation evidence | ✅ Evidence provision |
| prEN ISO/IEC 24970 | EventHash, Merkle Tree, TraceID, timestamps | ✅ Full compliance |
| MiFID II RTS 25 | TimestampPrecision, ClockSyncStatus | ✅ Exceeds requirements |
VI. Completeness Guarantees: Beyond Tamper Evidence
6.1 The Omission Detection Problem
Traditional audit trails provide tamper evidence—detection that existing records were modified. However, they typically cannot prove that no records were omitted. A malicious actor could simply choose not to record inconvenient events, leaving no trace of their existence.
6.2 VCP v1.1's Solution
VCP v1.1 addresses omission detection through its three-layer architecture:
- Merkle Tree Construction: All events within a batch are incorporated into a single Merkle tree. The resulting Merkle root represents the complete batch content.
- External Anchoring: The Merkle root is committed to an external timestamp authority at tier-specified intervals. Once anchored, the log producer cannot retroactively add or remove events.
- Split-View Resistance: The external anchor serves as a single source of truth. If a log producer attempts to present different views to different verifiers, the anchor reveals the inconsistency.
6.3 VCP-XREF Enhanced Completeness
For scenarios requiring maximum completeness guarantees, VCP-XREF dual logging provides additional protection:
- Two independent parties maintain separate VCP logs
- Events are cross-referenced via CrossReferenceID
- Omission by one party is detectable through the other party's independent record
- Successful omission requires collusion between both parties AND compromise of external anchors
VII. GDPR Compatibility: The Crypto-Shredding Approach
7.1 The Apparent Paradox
A frequently raised objection to cryptographic audit trails is the apparent conflict between immutability requirements (for audit integrity) and GDPR Article 17's right to erasure. How can records be both permanent and deletable?
7.2 VCP-PRIVACY Resolution
VCP addresses this through crypto-shredding—a technique where personally identifiable information is encrypted with per-subject keys before being recorded in the audit chain:
- Pre-Recording Encryption: PII within VCP events is encrypted using unique cryptographic keys tied to specific data subjects
- Chain Storage: Only encrypted ciphertext appears in the immutable audit trail
- Erasure Implementation: Upon valid erasure request, the specific decryption key is destroyed in the Key Management System
- Effect: The ciphertext remains in the chain (preserving audit integrity), but becomes permanently indecipherable—functionally equivalent to deletion
VCP thereby satisfies both MiFID II's requirement for immutable transaction records (7-year retention) and GDPR's erasure rights.
VIII. IETF SCITT Integration
8.1 Standards Body Positioning
VCP's technical architecture is positioned within the IETF Supply Chain Integrity, Transparency, and Trust (SCITT) Working Group framework. SCITT defines interoperable building blocks for integrity and accountability:
- Transparency Services: Append-only logs using Merkle tree verifiable data structures
- Signed Statements: COSE_Sign1 messages containing claims about artifacts
- Receipts: COSE receipts with Merkle inclusion proofs
8.2 draft-kamimura-scitt-vcp
draft-kamimura-scitt-vcp (submitted to IETF) positions VCP as a SCITT profile for financial trading audit trails, extending the general-purpose SCITT architecture with domain-specific requirements:
- Nanosecond timing precision
- Regulatory compliance mapping (PolicyID)
- Crypto-shredding for GDPR compatibility
- Financial event type enumeration
IX. Practical Implementation Guidance
9.1 Short-Term Actions (Q1-Q2 2026)
Before Digital Omnibus adoption:
- VCP Silver Tier Pilot: Implement VCP logging in development/testing environments to identify technical integration challenges
- External Anchor Selection: Evaluate and contract with attested database providers (AWS QLDB, Azure SQL Ledger) or TSA services
- Policy ID Definition: Establish organizational PolicyID scheme using reverse-DNS format (e.g.,
org.acmecapital.prod:trading-algo-001) - Gap Analysis: Map existing MiFID II RTS 6 self-assessment processes to AI Act Article 17 quality management requirements
9.2 Medium-Term Actions (Q3-Q4 2026)
Post harmonized standards publication:
- Tier Upgrade Evaluation: Assess whether regulated systems require Gold or Platinum tier for higher assurance
- prEN ISO/IEC 24970 Alignment Verification: Confirm VCP log format compatibility with published standard through third-party audit
- MiFID II Integration: Incorporate VCP audit evidence into annual RTS 6 self-assessment reports
- Incident Response Preparation: Establish Article 73 reporting procedures with VCP evidence retrieval capabilities
9.3 Long-Term Actions (2027 and Beyond)
Full AI Act enforcement:
- VCP-XREF Deployment: Negotiate dual logging agreements with brokers, counterparties, and clearing houses
- Post-Quantum Readiness: Leverage VCP v1.1's crypto agility to plan migration toward Dilithium/FALCON signatures
- Continuous Compliance Monitoring: Build VCP log analytics infrastructure supporting Article 72 post-market monitoring and Article 73 incident early detection
X. The Strategic Opportunity
10.1 The Compliance Window
The Digital Omnibus proposal's conditional enforcement mechanism creates a unique strategic window. Consider the scenarios:
Worst Case (for procrastinators)
Parliament/Council fail to adopt Omnibus before August 2026. Original AI Act deadlines apply. Immediate compliance crisis.
Moderate Case
Omnibus adopted mid-2026, harmonized standards published Q4 2026. Six-month implementation window triggers mid-2027. Compressed timeline, premium implementation costs.
Best Case (for early movers)
Begin VCP implementation Q1 2026. Production-ready infrastructure by late 2026. Full compliance posture before any enforcement scenario materializes.
In all scenarios, organizations implementing cryptographic audit infrastructure now gain compounding advantages:
- Operational Experience: Production trading environments present complexity that testing cannot anticipate
- Regulatory Credibility: Supervisors distinguish between good-faith preparation and checkbox compliance
- Competitive Differentiation: Institutional clients increasingly require execution counterparties to demonstrate verifiable audit capabilities
- Cost Efficiency: Retrofitting compliance under enforcement pressure commands premium pricing
10.2 The Verification Imperative
The proprietary trading industry's 2024-2025 crisis—where 80+ firms collapsed amid transparency failures, frozen payouts exceeding €400 million, and accusations of retroactive log manipulation—demonstrated the catastrophic consequences of trust-based oversight models.
Traditional audit approaches rely on self-attestation: firms submit logs and assert their accuracy. This model fails when the attestor has incentives to misrepresent.
VCP inverts this model through third-party verifiability. Regulators can independently verify audit trail completeness without trusting the submitting firm. The burden of proof shifts from "trust our logs" to "verify this cryptographic evidence."
This philosophical shift—"Verify, Don't Trust"—aligns with where regulatory expectations are heading. The AI Act's emphasis on auditability, ESMA's focus on algorithmic trading controls, and FCA's multi-firm review identifying documentation gaps all point toward a future where mathematical verifiability replaces declarative compliance.
XI. Conclusion: The Standard That Fills the Standards Gap
The European Commission's Digital Omnibus proposal confirmed what sophisticated market participants already understood: harmonized AI standards will not arrive before compliance obligations crystallize. The question facing every algorithmic trading operation is whether to wait in regulatory limbo or build verification infrastructure that will satisfy requirements whenever they materialize.
VCP v1.1 offers a technically rigorous answer:
- Its three-layer architecture addresses Article 12 record-keeping, Article 72 post-market monitoring, and Article 73 incident reporting requirements
- Its precision timing fields satisfy MiFID II RTS 25 mandates and exceed prEN ISO/IEC 24970 expectations
- Its crypto-shredding mechanism resolves GDPR tensions without compromising audit integrity
- Its IETF SCITT alignment positions implementations for interoperability with emerging transparency log standards
The protocol does not claim to replace harmonized standards—it provides the cryptographic foundation upon which any future standard can build. When CEN-CENELEC's JTC 21 finalizes prEN ISO/IEC 24970, VCP implementations will already satisfy its logging requirements and exceed them through third-party verifiability that pure logging standards do not mandate.
The Time for Action is Now
The compliance window is open. The infrastructure investment required today will determine competitive positioning for years to come. Organizations that treat the Digital Omnibus as breathing room rather than opportunity will find themselves scrambling when enforcement begins.
Resources
References
Primary Regulatory Sources
- European Commission (2025). COM(2025) 836 final - Digital Omnibus on AI. EUR-Lex.
- CEN-CENELEC (2025). Update on CEN and CENELEC's Decision to Accelerate the Development of Standards for Artificial Intelligence. October 23, 2025.
- European Commission (2025). Draft Guidance on Reporting Serious Incidents under Article 73.
- ISO/IEC (2025). ISO/IEC DIS 24970 - Artificial Intelligence — AI system logging.
VCP Technical References
- VeritasChain Standards Organization (2025). VCP Specification v1.1.
- IETF (2025). draft-kamimura-scitt-vcp - VeritasChain Protocol as SCITT Profile.
Legal Analysis Sources
- Bird & Bird (2025). AI Act 2.0: The Commission's Regulatory Remix Proposal.
- Latham & Watkins (2025). European Commission Publishes Draft Guidance on Reporting Serious AI Incidents.
- Timelex (2025). The European Commission proposes a one-year delay for high-risk AI obligations.
About VeritasChain Standards Organization
The VeritasChain Standards Organization (VSO) is an independent, vendor-neutral standards body developing open protocols for verifiable audit trails in algorithmic and AI-driven trading systems. VCP v1.1 has been submitted for informational review to 67 regulatory authorities across 50 jurisdictions as of January 2026.
info@veritaschain.org
technical@veritaschain.org
certification@veritaschain.org
standards@veritaschain.org