Guide

    MiFID II controls: map record keeping to the workflow (and make evidence automatic)

    MiFID II is operationally hard because evidence spans systems, timestamps, approvals, and exceptions. This playbook shows how to map it to process steps and keep it current through change.

    No credit card required. Switch to a paid plan any time.

    MiFID II record keeping timeline

    Evidence is created at decision points. Toggle clock sync health to see how evidence becomes questionable when timestamps drift.

    Clock sync health
    Workflow
    Evidence
    Exceptions

    Operational rule

    If timestamps are unreliable, evidence becomes questionable. Treat clock sync as a process dependency with monitoring and an exception path.

    Evidence integrity

    Clock sync within tolerance
    Decision points are explicit
    Exceptions create structured records

    Tip

    Start with event evidence (IDs + metadata). Attach documents only when required and always with templates.

    17 min read
    Advanced

    Definition

    MiFID II process controls and record keeping means mapping reporting and record obligations to concrete workflow decision points (approvals, handoffs, timestamps) so evidence is produced automatically during operations instead of reconstructed later.

    Key takeaways
    • Map record-keeping obligations to **where the record is created** (decision points), not to the process title.
    • Treat timestamps and clock synchronization as part of the workflow, not as IT hygiene.
    • Standardize exception handling so every deviation creates a structured record.
    • Use conformance checking to detect bypasses and late evidence creation.

    What you should map (practically): records, decisions, timestamps, exceptions

    MiFID II obligations become operational when they are attached to events:

    • a decision was made (approval/rejection)
    • an order was placed/changed/cancelled
    • a communication occurred (where required by policy)
    • an exception happened (manual override, bypass, or out-of-policy step)

    Controls mapping must therefore focus on decision points and evidence events.

    Pattern: obligation → BPMN step → evidence artifact

    Use the same mapping pattern across all regulated controls:

    1. Obligation statement (testable wording)
    2. BPMN decision point (approval/handoff/gateway)
    3. Evidence artifact (queryable event id + metadata)

    Example (simplified):

    • Obligation: order record kept with timestamp and actor
    • BPMN step: Place order task + gateway validate order
    • Evidence: order_event_id, timestamp, user/system, validation outcome, exception code

    Avoid “document evidence” as the default

    Start with event evidence first (IDs + metadata). Attach documents only when required and always with templates and required fields.

    Clock synchronization: treat it as a process dependency

    Clock sync requirements fail when they are owned only by IT.

    Make clock sync explicit in the operating model:

    • define which systems produce timestamped records
    • define what happens when sync status is degraded
    • define escalation workflows and evidence of remediation

    In BPMN terms: clock sync is a precondition and a monitoring control that should have an exception path.

    Exception playbooks: every deviation must become a structured record

    If exceptions are handled in chats and emails, evidence becomes impossible.

    Standardize exceptions as a pattern:

    • classify exception type (override, bypass, late record, data correction)
    • capture reason + approver (if required)
    • capture remediation action and timestamp

    This is the difference between a control that looks good on paper and one that survives audits.

    Monitoring: the KPI set that indicates control health

    Start with a minimal set of health KPIs:

    • % steps with required evidence present
    • evidence timeliness (time-to-record)
    • exception rate and top exception codes
    • drift rate (model should vs logs is)

    Then publish scorecards with ownership. If there is no owner, there is no control.

    Conformance checking: should-path vs is-path for record keeping

    Record keeping controls are perfect candidates for conformance checking:

    • the “should” path is defined by BPMN + evidence points
    • the “is” path is extracted from event logs

    Conformance reveals:

    • bypassed validations
    • missing approvals
    • evidence created late
    • rework loops caused by unclear controls

    Related:

    Avoid these

    Common mistakes to avoid

    Learn from others so you don't repeat the same pitfalls.

    Mapping obligations to process titles

    You lose where evidence is actually produced.

    Map to decision points and record-producing steps.

    Ignoring exception structure

    Most compliance issues hide in exceptions.

    Standardize exceptions with codes, reasons, and timestamps.

    Assuming timestamps are always correct

    Clock drift makes evidence questionable.

    Make clock sync a process dependency with monitoring and remediation workflow.

    Expert insights

    What the experts say

    "Record keeping is not a storage requirement. It is a workflow requirement—because the record is created at the decision point."
    C

    Compliance Operations Lead

    Take action

    Your action checklist

    Apply what you've learned with this practical checklist.

    • List record-keeping obligations and where they occur operationally

    • Map each obligation to BPMN decision points

    • Define evidence artifacts (IDs + metadata) and exception codes

    • Make clock sync explicit: monitoring + exception workflow

    • Publish control health KPIs and assign owners

    Q&A

    Frequently asked questions

    Learn more about how Process Designer works and how it can help your organization.