Nija

🔒 RISK FREEZE POLICY - NIJA Trading Bot

Effective Date: February 12, 2026
Status: 🔒 ACTIVE - PERMANENT

🎯 PURPOSE

This RISK FREEZE establishes permanent governance over all risk management rules to ensure the trading bot remains profitable and safe long-term.

Core Principle

“No live changes to risk rules without validation through backtesting, simulation, versioning, and explicit approval.”

This is how real trading systems stay profitable long-term. Ad-hoc risk parameter changes are the #1 cause of strategy degradation in automated trading.

🚫 WHAT IS FROZEN

❌ No Changes Allowed Without Approval

From this point forward, the following require the full approval process:

1. Risk Parameter Changes

2. Risk Management Logic

3. Protected Files

Any changes to these files require full approval:

✅ APPROVAL PROCESS

All risk parameter changes MUST follow this process:

Step 1: Proposal & Documentation

Required:

Step 2: Backtesting

Required:

Acceptance Criteria:

Step 3: Paper Trading Simulation

Required:

Acceptance Criteria:

Step 4: Versioning

Required:

Step 5: Code Review & Approval

Required Approvals:

Review Checklist:

Step 6: Gradual Rollout

Required:

🚨 EMERGENCY EXCEPTIONS

When Immediate Changes Are Allowed

ONLY in these scenarios:

  1. Critical Safety Issue
    • Active trading causing immediate capital loss
    • Risk limit breach causing liquidation risk
    • Stop-loss failures causing runaway losses
    • Action: Halt trading first, then fix
  2. Regulatory Compliance
    • New regulation requires immediate change
    • Legal requirement for risk limit modification
    • Action: Document legal requirement, implement minimal change
  3. Exchange Rule Changes
    • Exchange modifies margin requirements
    • Exchange changes position limits
    • Exchange updates trading rules
    • Action: Adapt to maintain operation, document change

Emergency Exception Process

  1. Declare Emergency
    • Document the emergency situation
    • Explain why it can’t wait for full approval
    • Estimate impact of NOT making the change
  2. Make Minimal Change
    • Change ONLY what is necessary
    • Document exactly what was changed
    • Create rollback plan
  3. Immediate Notification
    • Alert all stakeholders
    • Log change in emergency change log
    • Schedule post-mortem review
  4. Post-Emergency Follow-up (within 48 hours)
    • Full retroactive approval process
    • Backtest the emergency change
    • Paper trade the change
    • Either: Formalize as permanent OR rollback to previous config
    • Document lessons learned

📊 RISK CONFIGURATION VERSIONING

Version Format

RISK_CONFIG_v{MAJOR}.{MINOR}.{PATCH}

MAJOR: Breaking changes to risk model
MINOR: New risk rules or significant adjustments  
PATCH: Minor parameter tuning

Version History Template

version: RISK_CONFIG_v2.1.0
date: 2026-02-12
author: Technical Lead
status: approved

changes:
  - parameter: max_position_size
    old_value: 0.10
    new_value: 0.08
    reason: Reduce exposure during high volatility period
    
  - parameter: stop_loss_atr_multiplier
    old_value: 1.5
    new_value: 1.8
    reason: Reduce premature stop-outs

backtesting:
  period: 2025-11-12 to 2026-02-12
  results:
    win_rate: 0.58 (+0.03)
    max_drawdown: 0.12 (-0.01)
    sharpe_ratio: 1.85 (+0.15)
  conclusion: Approved - improvements across all metrics

paper_trading:
  period: 2026-01-29 to 2026-02-12
  trades: 47
  win_rate: 0.60
  max_drawdown: 0.08
  conclusion: Approved - consistent with backtest

approvals:
  - role: Technical Lead
    name: [Name]
    date: 2026-02-12
    signature: [Signature]
    
  - role: Risk Manager
    name: [Name]
    date: 2026-02-12
    signature: [Signature]

Current Version

RISK_CONFIG_v1.0.0 - Baseline configuration (as of February 12, 2026)

🔍 MONITORING & COMPLIANCE

Automated Enforcement

Pre-commit Hooks:

CI/CD Checks:

Runtime Monitoring:

Manual Reviews

Weekly Risk Review:

Monthly Risk Audit:

Quarterly Strategy Review:

📋 CHANGE TRACKING

Risk Change Log

All risk changes must be logged here:

RISK_CONFIG_v1.0.0 (Baseline)

Date: February 12, 2026
Status: Active
Changes: Initial frozen configuration

Parameters:

Approvals:

🎓 PHILOSOPHY & RATIONALE

Why Risk Freeze Matters

1. Strategy Degradation Prevention

2. Institutional-Grade Governance

3. Psychological Protection

4. Capital Protection

What We Learn From This

The RISK FREEZE teaches:

📞 CONTACTS

Risk Freeze Enforcement

Change Proposals

Questions

📚 REFERENCES

Risk Management Files

Testing & Validation

✅ POLICY ACKNOWLEDGMENT

By working on NIJA risk management, all team members acknowledge:

  1. ✅ I have read and understand this RISK FREEZE policy
  2. ✅ I will NOT change risk parameters without full approval
  3. ✅ I will follow the 6-step approval process for any risk changes
  4. ✅ I understand that ad-hoc risk changes destroy profitability
  5. ✅ I commit to institutional-grade risk governance

📝 VERSION HISTORY

v1.0 - February 12, 2026

Policy Updates:

This RISK FREEZE is PERMANENT and applies to all future development.

Status: 🔒 ACTIVE - PERMANENT

🔐 COMMITMENT

We solemnly commit that:

From this point forward, NO risk management changes will be deployed to production without:

  1. ✅ Backtesting (minimum 3 months)
  2. ✅ Paper Trading (minimum 2 weeks)
  3. ✅ Version documentation
  4. ✅ Multi-stakeholder approval

This is how real trading systems stay profitable long-term.

“Discipline is choosing between what you want now and what you want most.”
— NIJA Trading Systems