Skip to content
Reltime
Regulatory rails

One engine, one template structure, every obligation provable.

Each rail is the same four elements filled for one regulation. Events, proofs, actions and reports. A bank running DORA, AMLR and eIDAS 2 shares one identity layer and one record across all three.

When the rules change, the rail is updated once and the record shows which version applied on which date.

Illustrative workflow
  1. 1

    Events

    What must be recorded

    Vulnerability received, assessed, exploitation confirmed, fix released

  2. 2

    Proofs

    What a third party must see

    Each step signed by an identified person in a defined role, with time and document version

  3. 3

    Actions

    What may only happen once proof exists

    Product release held until the fix is recorded and signed

  4. 4

    Reports

    What the supervisor receives

    Early warning in 24h, notification in 72h, final report within 14 days of a fix

Rail shown · Cyber Resilience Act

Read the full rail →

Who it reaches · Manufacturers of products with digital elements, including own-brand retailers

Events recorded
Vulnerability received, assessed, exploitation confirmed, fix released
Proofs
Each step signed by an identified person in a defined role, with time and document version
Actions gated on proof
Product release held until the fix is recorded and signed
Reports generated
Early warning in 24h, notification in 72h, final report within 14 days of a fix
Illustrative workflow
Step 1 of 5
  1. Awareness · anchored 09:14
  2. +24h · Early warning
  3. +72h · Notification
  4. Fix available
  5. +14 days · Final report
NIS2, DORA and CRA each have their own reporting stages and deadlines. This example shows CRA.

Supplier evidence before the goods arrive.

11 December 2027. From that day distributors check CE marking and documentation before they sell, and a product that can't show it doesn't move. Suppliers seal declaration, contact point and support period once per product version. Every item has a status before it reaches the shelf. If evidence changes or disappears, the alert goes out at once. The software bill of materials stays private in the manufacturer's file, anchored and provable. Ten years of trail, exactly as the CRA demands.

Illustrative workflow
  • Router X2 · v1.4✓ Declaration✓ Contact point✓ Support period✓ SBOM anchoredReady
  • Smart plug S · v2.0✓ Declaration✓ Contact point✕ Support period✕ SBOM anchoredMissing
  • Laptop L15 · v3.1✕ Declaration✓ Contact point✓ Support period✓ SBOM anchoredWithdrawn
Scope this railCheck if this applies to you

Read the full rail →

Who it reaches · Essential and important entities in 18 sectors

Events recorded
Security measures, incidents
Proofs
Incident owner, classification and every escalation signed with role and time
Actions gated on proof
Access to essential systems
Reports generated
Incident notifications
Scope this railCheck if this applies to you

Read the full rail →

Who it reaches · Financial entities and their ICT providers

Events recorded
ICT incidents, third-party changes, tests
Proofs
Approval chain with roles and the rule version that applied
Actions gated on proof
Change to critical ICT services
Reports generated
Incident and register reporting
Scope this railCheck if this applies to you

Read the full rail →

Who it reaches · Providers and deployers of high-risk AI

Events recorded
Training data, consent, model versions
Proofs
Model version and responsible role bound to each decision
Actions gated on proof
Model release
Reports generated
Technical documentation and logs
Scope this railCheck if this applies to you

Read the full rail →

Who it reaches · Obliged entities under EU AML rules

Events recorded
Customer checks, status changes, alerts
Proofs
Attestations from issuers, checked against their signatures
Actions gated on proof
Transactions above risk thresholds
Reports generated
Ongoing monitoring trail
Scope this railCheck if this applies to you

Read the full rail →

Who it reaches · Producers of products, now including software

Events recorded
Product state at release, changes, updates
Proofs
Release and update decisions signed with role, time and version
Actions gated on proof
Release of software and updates
Reports generated
Evidence pack for disclosure
Scope this railCheck if this applies to you

Read the full rail →

Who it reaches · Lenders and credit intermediaries

Events recorded
Creditworthiness checks, disclosures
Proofs
Each assessment bound to the rule version and the responsible role
Actions gated on proof
Credit decision and payout
Reports generated
Per-decision evidence
Scope this railCheck if this applies to you

One identity layer under every rail. eKYC and self-held identity with continuous monitoring.

See identity as evidence →
The question that comes

The supervisor will ask who acted, under which rule and when. Reltime has the answer as the work happens.

7%

of global turnover. The ceiling for the gravest breaches under the AI Act.

Money moves only when the proof exists.

A payment instruction is released only when an anchored acceptance exists. Delivery, inspection, approval and payment reference sit in one chain that the payer, the donor and the auditor can each check.

The bank or treasury stays the payer and keeps its own responsibilities. Reltime gates the instruction and holds the proof.

Illustrative workflow
Step 1 of 7

  1. 01

    Delivery recorded

  2. 02

    Inspection signed

  3. 03

    Acceptance anchored

    Anchored

  4. 04

    Approvals

    Two roles

  5. 05

    Payment instruction released

    Released

  6. 06

    Payer executes

Alternative branch · inspection fails

  1. 01

    Inspection failed

    Failed

  2. 02

    Instruction held

    Held

  3. 03

    Alert to the contracting officer

    Alert

ObligationWorkflowControlEvidenceStays with you
NIS2 incident handlingDetection to notificationOwner assigned and escalation enforcedSigned timeline of every stepClassification and reporting decision
DORA ICT third-party riskChange to a critical ICT serviceChange held until approvals are anchoredApproval chain with roles and rule versionRisk appetite and supplier choice
CRA vulnerability reportingVulnerability to fixRelease held until fix is signed24h / 72h / final report drafts from the recordSubmission to the authority
GDPR data minimisationIdentity checksProof shared, copy withheldAttestation receiptLawful basis and retention
AI Act loggingModel decisionModel version bound to each decisionEvent log with inputs reference and versionRisk classification of the system
AMLR ongoing monitoringCustomer relationshipAlert on status change or anomalyAnchored monitoring trailRisk assessment and action

Reltime is designed to support these obligations. Responsibility for compliance remains with your organisation.

Every look-up is evaluated before the data is released.

For people with protected personal details, a single wrong look-up can put a life at risk. Reltime evaluates the request before the data is released, records the decision and alerts the responsible team when someone without access tries.

Illustrative workflow
Step 1 of 7

Clinician

  • 1 Request record

Local control point

  • 2 Local decision in milliseconds
  • 4 Local log written
  • 7 Branch B · emergency break-glassApproved · flagged

Patient record system

  • 3 Permitted fields only

Reltime network

  • 5 Anchored after the decision

Security team

  • 6 Branch A · access outside roleDenied · alert
Care never waits for the network. The decision is made locally and the evidence is anchored right after.

  • No new register.

    Protection status is read where it already lives, at every check. No list of protected people is ever built.

  • Everything stays with the organisation.

    The full decision record stays in its own log. Only a checksum goes to the network.

  • Safe failure, per flow.

    If the control point does not answer, mailings and invoices are held, referrals go through with contact details masked, and urgent reading is granted as emergency access and flagged for follow-up.