R1 Client Risk 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.

Do not copy it into uncontrolled chats, sales groups, client communications, or uncontrolled storage.

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¶

This runbook guides the team through the request, approval, application, verification, handover, review, downgrade, and removal of client risk-control statuses.

It is not a public client-classification document and must not be used in communication with clients, sales teams, introducers, or partners.

2. Control Scope¶

2.1 Manager Account-Level Control¶

A control configured in Manager applies only to the specified trading account.

Use it for:

temporary control of a single account;
a case where linked-identity review is not yet complete;
approved account-level risk handling;
cases where a narrow impact scope must be retained.

2.2 RiskTool Linked-Identity-Level Control¶

A control configured in RiskTool by UID / linked identity may apply to existing and future accounts under the same linked identity.

Before use, confirm that:

the UID / linked-identity identification is correct;
the related scope has received the required review;
appropriate approval has been obtained;
the impact scope, communication boundary, and follow-up responsibility are clear;
existing and future account inheritance will be verified after implementation.

Important: UID / linked-identity-level control has cross-account impact. Do not expand a control from a single account to a linked identity without approval.

3. Risk-Control Depth Colours¶

The following colours represent increasing internal risk-control depth:

Black
Red
Yellow
DarkOrange
DarkTurquoise
Brown
MediumSpringGreen

Colours are used for internal execution, handover, and review. They are not public client labels and must never be explained externally.

3.1 MediumSpringGreen¶

MediumSpringGreen is the highest risk-control depth. It is used where the company no longer intends to accept the relevant risk trading flow.

The live execution configuration, parameters, and activation criteria must follow the currently approved system strategy and Manager instruction. Do not discuss them in uncontrolled files or chats.

3.2 SandyBrown¶

SandyBrown is not part of the risk-control depth sequence.

SandyBrown means: No New Positions.

Before applying SandyBrown, authorised personnel must confirm and record the company policy for:

whether existing positions may be closed or partially closed;
whether pending orders are retained, cancelled, or prevented from triggering;
the effect on stop-loss, take-profit, or stop-out mechanisms;
whether CRM wallet, internal transfer, deposit/withdrawal, or other account functions are also restricted;
the scope across platforms, related accounts, and future accounts;
the responsible owners for client communication, sales communication, and risk approval.

Do not assume the effect of SandyBrown on open positions, pending orders, or funding functions without a confirmed policy.

4. Criteria for Requesting a Control Status¶

A request should be supported by at least one of the following:

verified unusual short-holding activity, unusual order flow, or behaviour that may exploit execution conditions;
verified linked-account hedging, pairing, control avoidance, or abnormal coordinated behaviour;
confirmed material execution risk, event risk, or persistent risk;
a clear risk instruction from a Manager, Risk Owner, or Shift Leader;
another situation that meets the company’s current risk-governance standard after review.

Each request must include:

account / UID / linked-identity scope;
current control status;
proposed control status;
trigger reason;
orders, reports, screenshots, logs, or other evidence;
risk-impact explanation;
urgency;
proposed effective time;
requester, approver, and review date.

5. Approval and Execution¶

5.1 Authority Principles¶

Junior Dealer: identify, preserve evidence, escalate, confirm approved outcomes, and complete handover only.
Senior Dealer / Shift Leader: review, recommend, execute, or verify within delegated authority.
Manager / Designated Risk Owner: approve, adjust, expand, downgrade, or remove linked-identity-level controls and high-impact restrictions.
Anything outside delegated authority must be escalated.

5.2 Pre-Execution Checks¶

Before execution, confirm that:

the instruction source is clear and traceable;
the account / UID / platform / group is correct;
the request and approval status match;
no conflicting temporary plan, event control, or restriction is active;
the intended scope exactly matches the approval;
handover and review ownership are defined.

5.3 Post-Execution Verification¶

After execution, verify that:

the target account or UID displays the correct control status;
required existing accounts are covered;
where applicable, future related-account inheritance behaves as expected;
the scope has not been incorrectly expanded to unrelated accounts;
required handover, incident records, and audit fields are complete.

6. Audit Record Template¶

Record every addition, upgrade, downgrade, or removal:

Field	Required content
Date & time	Execution time and system timezone
Platform	Affected platform
Account / UID	Account or linked-identity identifier
Linked scope	Confirmed related-account scope
Old status → new status	Before and after
Trigger reason	Risk signal or approval reason
Evidence	Reports, screenshots, orders, logs, incident reference
Requester	Person who submitted
Approver	Person who approved
Executor	Person who applied the action
Verification result	Confirmed effect and exceptions
Review date	Next review time or trigger
Removal / downgrade criteria	Defined review standard
Notes	Handover or special notes

7. Review, Downgrade, and Removal¶

A risk-control status is not automatically permanent.

During review, consider:

whether the original risk behaviour remains;
whether new linked accounts or control-avoidance behaviour has appeared;
whether the current control remains effective and proportionate;
whether there was an incorrect application, missed scope, or unnecessary expansion;
whether approved downgrade or removal criteria are met;
whether SandyBrown or another restriction also requires adjustment.

Every downgrade, removal, expansion, or linked-scope change requires approval, documented rationale, and traceable records.

8. Confidentiality and Communication Boundaries¶

Do not:

explain colours, control depth, internal parameters, or execution strategy to clients;
disclose backend control status to sales teams, introducers, or unauthorised personnel;
discuss specific UID, colours, or handling strategy in unauthorised groups;
upload this runbook to the general training site, public folders, or uncontrolled knowledge bases;
use an internal control status as a basis for client-dispute explanation or negotiation.

Any external communication must be handled by an authorised owner using approved wording.

9. Handover Requirement¶

Every handover involving a client risk-control status must include:

affected account / UID;
current control status;
completed actions;
evidence location;
whether SandyBrown or another additional restriction is involved;
pending-review items;
next owner;
next review time / event trigger;
whether client, sales, or IT follow-up is pending.