Skip to content

R3. Major Event Control Runbook

Internal Use Only – Operational Reference

This material is for internal training, handover, and authorised operational reference. Reading this material does not grant permission to perform controlled actions.

R3 must not contain legacy platform paths, profile names, temporary-plan names, fixed parameters, screenshots, internal URLs or permanent minute-by-minute event rules.

Operating Authority Boundary

  • Dealer may identify, verify, preserve evidence, escalate, monitor, and complete handover.
  • Only personnel explicitly authorised for the specific action may execute it.
  • Dealer must not independently modify orders, adjust client risk status, apply event controls, restore accounts, inject or remove Credit, or communicate internal control logic to clients.

1. Purpose

R3 ensures that major market events are handled through approved preparation, monitoring, control validation, recovery confirmation, incident recording and handover. The purpose is to reduce operational uncertainty without converting temporary event controls into undocumented routine practice.

2. Event Identification and Scope

Before the control window begins, confirm:

  • event name and market relevance;
  • current approved Event Calendar / Event & Product Control Sheet reference;
  • expected affected products and sessions;
  • known holidays, liquidity conditions or platform constraints;
  • current client exposure and concentration;
  • prior incidents or recurring issue patterns;
  • required staffing, reviewer and escalation coverage.

Use the current approved event calendar and internal risk notes. Do not rely on memory or unofficial market chat.

3. Event Time & Timezone Validation

Event timing must be validated against the current approved calendar and current platform server-time reference. Previous event sheets, remembered timings, or historic timezone assumptions must not be used as the sole source of confirmation.

Before every major event, verify:

  • official release time;
  • MT Server Time;
  • Jakarta Time;
  • Hong Kong Time;
  • whether current server time is consistent across relevant platforms;
  • whether daylight-saving or standard-time conversion has been applied correctly.

Do not hard-code GMT+2, GMT+3, or any platform’s permanent time rule into this runbook.

Use these principles:

  • validate against the current platform server-time reference and current timezone rules;
  • if platform time, announcement time or roster reminder differs, pause further control confirmation and escalate immediately;
  • do not confirm event timing from memory, old sheets or previous-cycle event times.

Record:

  • person who validated the timing;
  • validation time;
  • event source used;
  • confirmed control window;
  • whether any timezone or platform-time difference exists.

4. Reminder & Announcement Verification

Before the event, confirm the following are prepared:

  • current Event Calendar has been updated;
  • roster or handover reminder has been arranged;
  • relevant personnel have received the required reminder;
  • internal announcement wording, event time and control window are consistent;
  • where applicable, external website or platform announcement has been checked by the designated owner;
  • current event tasks, owners and review timing are clear.

Do not record group names, personal names, internal URLs, legacy reminder paths or alarm-button instructions.

Use role names:

  • Event Owner;
  • Shift Leader;
  • Designated Operator;
  • Client Communication Owner;
  • Dealer;
  • IT On-call.

Role responsibilities:

Role Responsibility
Event Owner Confirms event calendar, time validation and reminder preparation are complete
Shift Leader Confirms shift coverage, handover information and responsible operators
Designated Operator Confirms relevant approved control status according to the approved plan
Client Communication Owner Confirms announcement wording and release timing
Dealer Confirms reminder received, monitors abnormalities, preserves evidence, escalates exceptions and completes handover
IT On-call Supports technical abnormality investigation; does not decide risk-control plan

A missing reminder, unclear ownership, or inconsistent announcement timing must be treated as an operational control gap and escalated immediately.

If a gap is found:

  • Dealer must not assume the process has been completed;
  • notify Shift Leader immediately;
  • Shift Leader assigns a remediation owner and records the remediation action;
  • if the control window is approaching and confirmation remains incomplete, escalate to Manager / Risk Owner.

5. Approved Event Control Plan

The approved plan should define:

  • control window;
  • affected products or account groups;
  • monitoring focus;
  • authorised temporary controls, if any;
  • approval owner;
  • reviewer and handover owner;
  • restoration condition.

Dealer verifies approved status, monitors conditions, preserves evidence, escalates exceptions, and completes handover.

Only an authorised Operator may apply or remove an approved temporary control through the current authorised system. A Dealer must not independently activate, adjust, extend, or remove an event control.

6. Staffing, Notification and Review

For major events, Shift Leader / Manager confirms:

  • who monitors quotes and execution;
  • who monitors exposure and concentrated flow;
  • who checks client complaints or disputes;
  • who validates temporary controls;
  • who approves changes during the control window;
  • who owns handover after the event.

Role names should be used instead of personal names in reusable training material.

7. Control Window Monitoring

During the event control window, monitor:

  • quote quality and spread behaviour;
  • order flow, rejection, timeout, partial fill and quick close-out signals;
  • exposure concentration and same-direction client flow;
  • client complaints or dispute signals;
  • platform and execution-chain health;
  • deviations from the approved control plan.

Do not change control scope based only on one observation. Escalate with evidence when the observed state differs from the approved plan or expected baseline.

8. Temporary Control Validation

If an approved temporary control is active:

  • confirm it is active within the approved scope;
  • confirm unrelated products, accounts or sessions are not affected;
  • confirm monitoring evidence is retained;
  • escalate immediately if the result differs from the approved instruction.

Validation must be repeated after any approved change.

9. Post-Event Restoration

After the control window:

  • validate that approved temporary controls have been removed, restored or retained according to instruction;
  • confirm quotes, execution and platform state have returned to the agreed operating condition;
  • review affected orders, disputes and unresolved client-impact signals;
  • document anything that must continue into the next shift.

Restoration is complete only after validation and handover, not when the market event ends.

10. Incident and Handover Record

The event record must include:

  • event and control-window summary;
  • approved plan and approval status;
  • control validation result;
  • quote, execution, exposure and complaint observations;
  • incidents or abnormal orders;
  • open items and assigned owners;
  • next review trigger.

11. Manager Confirmation Required

The following items require final Manager confirmation before becoming permanent rules:

  • event control windows;
  • event-time and timezone validation standard;
  • reminder and announcement ownership;
  • authority for temporary controls;
  • restoration standards;
  • client-dispute handling threshold;
  • escalation threshold for exposure concentration;
  • post-event review ownership.