foxhunt/docs/sox/SOX_COMPLIANCE_GUIDE.md

SOX Compliance Guide - Foxhunt HFT Trading System

Version: 1.0 Last Updated: 2025-10-07 Status: Production Ready

---

Table of Contents

1. SOX Overview
2. Applicability to Trading Systems
3. Section 302: Internal Controls
4. Section 404: Assessment of Internal Controls
5. Section 409: Real-Time Disclosure
6. Audit Trail Requirements
7. Access Control Matrix
8. Change Management
9. Data Retention
10. Certification Process
11. Compliance Testing

---

SOX Overview

What is SOX?

The Sarbanes-Oxley Act of 2002 (SOX) is a U.S. federal law that establishes comprehensive auditing and financial regulations for public companies. It was enacted in response to major corporate and accounting scandals (Enron, WorldCom) to protect investors from fraudulent financial reporting.

Key Objectives

1. Improve Financial Reporting Accuracy: Ensure financial statements are accurate and reliable
2. Establish Internal Controls: Document and test controls over financial reporting
3. Prevent Fraud: Implement checks and balances to detect and prevent fraudulent activities
4. Management Accountability: Hold executives personally accountable for financial accuracy
5. Audit Independence: Ensure auditors are independent and objective

Relevance to Trading Systems

Trading systems handle financial transactions and must maintain:

• Accurate trade records (price, quantity, counterparty, settlement)
• Position valuations (mark-to-market, P&L calculations)
• Risk metrics (VaR, margin requirements, exposure limits)
• Compliance records (regulatory reporting, best execution)
• Audit trails (who did what, when, why)

Failure to comply with SOX can result in:

• Criminal penalties (up to 20 years imprisonment)
• Civil penalties (fines up to $5 million)
• Loss of trading licenses
• Reputational damage
• Class-action lawsuits from investors

---

Applicability to Trading Systems

In-Scope Activities

1. Trade Lifecycle Management

   • Order entry and routing
   • Execution and fills
   • Settlement and clearing
   • Position reconciliation

2. Financial Reporting

   • P&L calculations
   • Position valuations
   • Risk metrics (VaR, margin)
   • Management reports

3. Access Controls

   • User authentication/authorization
   • Role-based permissions
   • Segregation of duties
   • Privileged access monitoring

4. Change Management

   • Code deployments
   • Configuration changes
   • Infrastructure modifications
   • Emergency fixes

5. Data Retention

   • Transaction records (7 years)
   • Audit trails (7 years)
   • Financial reports (7 years)
   • Change logs (7 years)

Out-of-Scope Activities

• Market data feeds (external data, not generated by system)
• Research and analysis (pre-trade, not financial reporting)
• Customer relationship management (CRM activities)
• Non-financial HR/payroll systems

---

Section 302: Internal Controls

Requirement

Section 302 requires CEO and CFO to certify:

1. They have reviewed the financial report
2. The report does not contain material misstatements or omissions
3. Financial statements fairly present the company's financial condition
4. They are responsible for establishing and maintaining internal controls
5. They have evaluated the effectiveness of internal controls within 90 days
6. They have disclosed any material weaknesses or significant deficiencies to auditors

Implementation in Foxhunt

Control Framework

// trading_engine/src/compliance/sox_compliance.rs

pub struct InternalControl {
    pub control_id: String,              // Unique ID (e.g., "CTRL-001")
    pub control_type: ControlType,       // Preventive, Detective, Corrective
    pub control_objective: String,       // What risk it mitigates
    pub control_activities: Vec<String>, // Steps performed
    pub frequency: ControlFrequency,     // Daily, Weekly, Quarterly, Annual
    pub owner: String,                   // Person responsible
    pub testing_procedures: Vec<TestingProcedure>,
    pub implementation_status: ImplementationStatus,
    pub last_test_date: Option<DateTime<Utc>>,
    pub next_test_date: Option<DateTime<Utc>>,
}

pub enum ControlType {
    Preventive,  // Prevents errors before they occur
    Detective,   // Detects errors after they occur
    Corrective,  // Corrects errors after detection
}

pub enum ControlFrequency {
    Continuous,  // Real-time monitoring
    Daily,       // Daily batch processes
    Weekly,      // Weekly reconciliations
    Monthly,     // Month-end close
    Quarterly,   // Quarterly reviews
    Annual,      // Annual assessments
}

Key Controls

1. Trade Authorization Control (CTRL-001)

   • Type: Preventive
   • Objective: Ensure only authorized traders can enter orders
   • Activities:
     • User authentication with MFA
     • Role-based access control (RBAC)
     • Order size limits by trader level
     • Pre-trade risk checks
   • Frequency: Continuous
   • Testing: Quarterly - attempt unauthorized access, verify rejection

2. Position Valuation Control (CTRL-002)

   • Type: Detective
   • Objective: Ensure positions are valued accurately
   • Activities:
     • Daily mark-to-market calculations
     • Independent price verification
     • Variance analysis (> 1% requires review)
     • Reconciliation with broker statements
   • Frequency: Daily
   • Testing: Monthly - compare valuations with external sources

3. P&L Calculation Control (CTRL-003)

   • Type: Detective
   • Objective: Ensure P&L is calculated correctly
   • Activities:
     • Automated P&L calculation from trades
     • Independent recalculation by risk team
     • Variance threshold (> $10K requires investigation)
     • Month-end close reconciliation
   • Frequency: Daily (calculation), Monthly (reconciliation)
   • Testing: Quarterly - recalculate P&L for sample period

4. Audit Trail Integrity Control (CTRL-004)

   • Type: Preventive + Detective
   • Objective: Ensure audit trails are complete and tamper-proof
   • Activities:
     • Immutable audit logs (write-once)
     • SHA-256 checksums for tamper detection
     • Real-time persistence to PostgreSQL
     • 7-year retention enforcement
   • Frequency: Continuous
   • Testing: Quarterly - verify checksums, test immutability

5. Change Management Control (CTRL-005)

   • Type: Preventive
   • Objective: Ensure unauthorized changes don't occur
   • Activities:
     • Change request approval (CTO/CFO)
     • Risk assessment (5-point scale)
     • Rollback plan mandatory
     • Post-implementation review
   • Frequency: Per change
   • Testing: Quarterly - review change logs, verify approvals

Management Certification Workflow

Quarterly Process:

1. Control Testing (Days 1-60 of quarter)

   • Compliance team executes test procedures
   • Documents evidence of control effectiveness
   • Identifies deficiencies or weaknesses

2. Deficiency Assessment (Days 61-75)

   • Classify deficiencies (material weakness vs. significant deficiency)
   • Document remediation plans
   • Assign owners and due dates

3. Management Review (Days 76-85)

   • CFO/CTO review control test results
   • Review deficiencies and remediation plans
   • Sign off on certification

4. CEO/CFO Certification (Day 90)

   • CEO/CFO sign certification
   • File with SEC (if public company)
   • Disclose material weaknesses in 10-Q/10-K

Certification Template:

I, [CEO/CFO Name], certify that:

1. I have reviewed this quarterly report of Foxhunt Trading LLC.

2. Based on my knowledge, this report does not contain any untrue
   statement of a material fact or omit to state a material fact
   necessary to make the statements made, in light of the circumstances
   under which such statements were made, not misleading.

3. Based on my knowledge, the financial statements and other financial
   information included in this report fairly present in all material
   respects the financial condition and results of operations of the
   company as of, and for, the periods presented in this report.

4. I am responsible for establishing and maintaining disclosure controls
   and procedures and internal control over financial reporting for the
   company.

5. I have evaluated the effectiveness of the company's internal controls
   as of [Date], and have disclosed to the company's auditors and audit
   committee:
   - All significant deficiencies and material weaknesses in the design
     or operation of internal controls which could adversely affect the
     company's ability to record, process, summarize, and report
     financial data.
   - Any fraud, whether or not material, that involves management or
     other employees who have a significant role in the company's
     internal controls.

Date: [Date]

Signature: ______________________
[CEO/CFO Name and Title]

Deficiency Classification

Material Weakness:

• A deficiency, or combination of deficiencies, that results in a reasonable possibility that a material misstatement will not be prevented or detected on a timely basis.
• Examples:
  • P&L calculation error > $1M undiscovered for > 1 month
  • Unauthorized access to production trading system
  • Complete failure of audit trail logging
• Action: Immediate remediation, disclose to auditors and SEC

Significant Deficiency:

• A deficiency that is less severe than a material weakness, yet important enough to merit attention by those charged with governance.
• Examples:
  • Position valuation variance > $100K for > 1 week
  • Missing documentation for 10% of changes
  • Delayed reconciliation (> 5 business days)
• Action: Remediation plan within 90 days, disclose to auditors

Control Deficiency:

• A shortcoming in control design or operation that does not meet the company's control objectives.
• Examples:
  • User access review delayed by 2 weeks
  • Control test missed one quarter
  • Minor documentation gaps
• Action: Remediation plan within 180 days, internal tracking only

---

Section 404: Assessment of Internal Controls

Requirement

Section 404 requires:

1. Management to assess the effectiveness of internal controls over financial reporting (ICFR)
2. External auditors to attest to management's assessment
3. Documentation of control design and operating effectiveness
4. Annual report on internal controls included in 10-K filing

Implementation in Foxhunt

Control Testing Procedures

1. Design Effectiveness Testing:

• Objective: Verify controls are designed to achieve control objectives
• Approach: Review control documentation, interview control owners
• Evidence: Control narratives, flowcharts, policies, procedures
• Frequency: Annual (or when control changes)

2. Operating Effectiveness Testing:

• Objective: Verify controls operate as designed consistently
• Approach: Sample transactions, re-perform controls, inspect evidence
• Evidence: Control execution logs, approvals, reconciliations, reports
• Frequency: Quarterly (sample-based testing)

Example: Trade Authorization Control Testing

Design Test:

Procedure:
1. Review RBAC configuration for trader roles
2. Verify order size limits are configured per role
3. Confirm pre-trade risk checks are enabled
4. Interview IT team on MFA implementation

Evidence:
- RBAC configuration files
- Order limit matrix
- Risk check configuration
- MFA architecture documentation

Conclusion: Control is adequately designed to prevent unauthorized trades.

Operating Test:

Procedure:
1. Select 25 trades from Q1 2025 (random sample)
2. For each trade:
   a. Verify trader had active RBAC role at time of trade
   b. Confirm order size within trader's limit
   c. Verify pre-trade risk check passed
   d. Validate MFA used for session authentication

Evidence:
- Audit trail entries for 25 trades
- RBAC role assignments for 25 traders
- Risk check logs for 25 trades
- Authentication logs showing MFA tokens

Conclusion: Control operated effectively for 100% of sample (25/25).
No exceptions noted.

Sample Size Guidelines

Control Frequency → Sample Size (per quarter):

• Continuous (many occurrences/day): 25 samples
• Daily: 5 samples (1 per week)
• Weekly: 4 samples (1 per week)
• Monthly: 3 samples
• Quarterly: 1 sample (100% testing)
• Annual: 1 sample (100% testing)

Exception Handling:

• 0 exceptions: Control operating effectively
• 1-2 exceptions: Control deficiency (investigate root cause)
• 3+ exceptions: Significant deficiency or material weakness

Annual Assessment Report

Template:

MANAGEMENT'S REPORT ON INTERNAL CONTROL OVER FINANCIAL REPORTING

The management of Foxhunt Trading LLC is responsible for establishing
and maintaining adequate internal control over financial reporting as
defined in Rules 13a-15(f) and 15d-15(f) under the Securities Exchange
Act of 1934.

Our internal control over financial reporting is a process designed to
provide reasonable assurance regarding the reliability of financial
reporting and the preparation of financial statements for external
purposes in accordance with generally accepted accounting principles.

Because of its inherent limitations, internal control over financial
reporting may not prevent or detect misstatements. Also, projections of
any evaluation of effectiveness to future periods are subject to the risk
that controls may become inadequate because of changes in conditions, or
that the degree of compliance with the policies or procedures may
deteriorate.

Management has assessed the effectiveness of the company's internal
control over financial reporting as of December 31, 2024, based on
criteria established in Internal Control—Integrated Framework (2013)
issued by the Committee of Sponsoring Organizations of the Treadway
Commission (COSO).

Based on this assessment, management has concluded that the company's
internal control over financial reporting was effective as of December 31,
2024.

[External Auditor Name], our independent registered public accounting
firm, has issued an attestation report on management's assessment of
internal control over financial reporting, which is included herein.

Date: [Date]

_______________________          _______________________
[CEO Name], CEO                  [CFO Name], CFO

---

Section 409: Real-Time Disclosure

Requirement

Section 409 requires companies to disclose material changes to their financial condition or operations on a rapid and current basis (within 4 business days).

Implementation in Foxhunt

Material Event Identification

Material Events (require disclosure within 4 business days):

1. Trading Loss > Threshold

   • Single-day loss > $10M
   • Weekly loss > $25M
   • Monthly loss > $50M

2. Risk Limit Breach

   • VaR limit breached by > 50%
   • Margin call not met within 24 hours
   • Counterparty default

3. Operational Failure

   • System downtime > 4 hours during trading hours
   • Data corruption affecting > 10% of positions
   • Security breach with potential financial impact

4. Regulatory Action

   • SEC/FINRA investigation notice
   • Trading suspension or license revocation
   • Significant fines or penalties (> $1M)

5. Management Changes

   • Departure of CEO, CFO, CTO, or CRO
   • Change in auditor
   • Bankruptcy or insolvency filing

Disclosure Workflow

Automated Detection:

// trading_engine/src/compliance/sox_compliance.rs

pub struct MaterialEventDetector {
    thresholds: MaterialEventThresholds,
    notification_queue: VecDeque<MaterialEvent>,
}

pub struct MaterialEventThresholds {
    pub daily_loss_threshold: Decimal,      // $10M
    pub weekly_loss_threshold: Decimal,     // $25M
    pub var_breach_threshold_pct: f64,      // 50%
    pub system_downtime_minutes: u64,       // 240 minutes (4 hours)
}

impl MaterialEventDetector {
    /// Check if P&L loss exceeds threshold
    pub fn check_pnl_threshold(&self, pnl: Decimal) -> Option<MaterialEvent> {
        if pnl < -self.thresholds.daily_loss_threshold {
            Some(MaterialEvent {
                event_type: MaterialEventType::TradingLoss,
                severity: Severity::High,
                detected_at: Utc::now(),
                description: format!("Daily P&L loss of ${} exceeds threshold", pnl.abs()),
                requires_disclosure: true,
                disclosure_deadline: Utc::now() + Duration::days(4),
            })
        } else {
            None
        }
    }
}

Disclosure Process:

1. Event Detection (T+0 hours)

   • Automated monitoring detects material event
   • Alert sent to CFO, CEO, CRO, Compliance Officer
   • Event logged in SOX compliance system

2. Event Assessment (T+24 hours)

   • CFO/CRO assess materiality and impact
   • Determine if 8-K filing required
   • Draft disclosure language

3. Legal Review (T+48 hours)

   • Legal counsel reviews disclosure
   • Ensures accuracy and completeness
   • Approves for filing

4. SEC Filing (T+72-96 hours)

   • File Form 8-K with SEC (within 4 business days)
   • Distribute press release
   • Update investor relations website

Form 8-K Template:

CURRENT REPORT
Pursuant to Section 13 or 15(d) of the Securities Exchange Act of 1934

Date of Report (Date of earliest event reported): [Date]

Foxhunt Trading LLC

Item 2.04. Triggering Events That Accelerate or Increase a Direct
Financial Obligation or an Obligation under an Off-Balance Sheet
Arrangement

On [Date], Foxhunt Trading LLC experienced a [describe event]. As a
result, [describe financial impact]. Management is taking the following
actions to address this situation: [describe remediation].

This event is expected to have [no material impact/material impact] on
the company's financial condition and results of operations for the
[quarter/year].

Signature: _______________________
[Authorized Officer Name and Title]
Date: [Date]

---

Audit Trail Requirements

The 6-Field Model

Every audit trail entry MUST contain these 6 fields:

1. WHO - Who performed the action?

   • User ID, trader ID, system account
   • Session ID for traceability

2. WHAT - What action was performed?

   • Action type (CREATE, UPDATE, DELETE, EXECUTE, APPROVE)
   • Resource affected (order, position, configuration, user)
   • Transaction details (symbol, quantity, price)

3. WHEN - When did the action occur?

   • Timestamp with nanosecond precision
   • Time zone (UTC)

4. WHERE - Where did the action originate?

   • Source IP address
   • Service/component (trading_service, api_gateway, etc.)
   • Venue (if market order)

5. WHY - Why was the action taken?

   • Business justification
   • Strategy name (for algo trades)
   • Reference to approval or authorization

6. RESULT - What was the outcome?

   • Success or failure
   • Error code/message (if failed)
   • Performance metrics (latency, queue time)

Implementation

// trading_engine/src/compliance/audit_trails.rs

pub struct TransactionAuditEvent {
    pub event_id: String,                    // Unique ID
    pub timestamp: DateTime<Utc>,            // WHEN (3)
    pub timestamp_nanos: i64,                // Nanosecond precision

    // WHO (1)
    pub actor: String,                       // User/trader ID
    pub session_id: Option<String>,          // Session for traceability

    // WHERE (4)
    pub client_ip: Option<String>,           // Source IP

    // WHAT (2)
    pub event_type: AuditEventType,          // Action type
    pub transaction_id: String,              // Transaction reference
    pub order_id: String,                    // Order reference
    pub details: AuditEventDetails,          // Transaction details

    // WHY (5) - in metadata
    // RESULT (6)
    pub before_state: Option<serde_json::Value>,  // State before
    pub after_state: Option<serde_json::Value>,   // State after

    // Compliance & Security
    pub compliance_tags: Vec<String>,        // SOX, MIFID2, etc.
    pub risk_level: RiskLevel,               // Low, Medium, High, Critical
    pub digital_signature: Option<String>,   // For non-repudiation
    pub checksum: String,                    // SHA-256 for tamper detection
}

Audit Trail Storage

Primary Storage: PostgreSQL with TimescaleDB

• Table: transaction_audit_events
• Partitioning: Monthly time-based partitions
• Indexing: Multi-column indexes on (timestamp, actor, event_type)
• Retention: 7 years (2,555 days)

Backup Storage: ClickHouse

• Table: audit_events_backup
• Replication: Real-time replication from PostgreSQL
• Use Case: Analytics and compliance reporting
• Retention: 7 years

Archive Storage: S3 Glacier

• Location: s3://foxhunt-audit-archive/YYYY/MM/
• Format: Parquet (compressed, columnar)
• Trigger: Monthly archival of events > 1 year old
• Retention: Indefinite (legal requirement)

Tamper Detection

Checksum Calculation:

impl AuditTrailEngine {
    fn calculate_checksum(&self, event: &TransactionAuditEvent) -> Result<String> {
        // Create JSON without checksum field
        let mut event_for_hash = event.clone();
        event_for_hash.checksum = String::new();

        let json = serde_json::to_string(&event_for_hash)?;

        // Calculate SHA-256
        let mut hasher = Sha256::new();
        hasher.update(json.as_bytes());
        let hash = hasher.finalize();

        Ok(format!("{:x}", hash))
    }

    pub fn verify_checksum(&self, event: &TransactionAuditEvent) -> Result<bool> {
        let stored_checksum = event.checksum.clone();
        let calculated_checksum = self.calculate_checksum(event)?;

        Ok(stored_checksum == calculated_checksum)
    }
}

Integrity Checks:

• Real-time: Checksum calculated on log_event() and stored
• Periodic: Monthly batch verification of all audit events
• On-demand: Before compliance audits or investigations
• Alerting: Critical alert if any checksum mismatch detected

---

Access Control Matrix

See SEPARATION_OF_DUTIES.md for detailed role definitions and SOD matrix.

Key Principles:

1. Least Privilege: Users have only the minimum permissions needed
2. Role-Based Access Control (RBAC): Permissions assigned to roles, not individuals
3. Separation of Duties (SOD): No user can control entire transaction lifecycle
4. Regular Reviews: Quarterly access reviews, annual role certifications
5. Termination Procedures: Immediate revocation upon employee departure

---

Change Management

See CHANGE_CONTROL_TEMPLATES.md for templates and workflows.

Key Requirements:

1. Change Request: All changes require documented request
2. Risk Assessment: 5-point risk scale (Critical, High, Medium, Low, Trivial)
3. Impact Analysis: Business, technical, and compliance impact
4. Multi-Level Approval: CFO/CTO approval for High/Critical changes
5. Testing: All changes tested in staging before production
6. Rollback Plan: Documented rollback procedure for all changes
7. Post-Implementation Review: Verify change achieved objectives

Emergency Changes:

• Allowed only for Critical/P1 incidents
• Verbal approval from CFO/CTO required
• Documented change request filed within 24 hours
• Post-implementation review within 48 hours

---

Data Retention

Retention Policy

7-Year Retention (2,555 days):

• Transaction audit events
• Financial reports (daily P&L, month-end closes)
• Compliance reports (best execution, regulatory)
• Change logs and approvals
• Access control logs
• User activity logs

3-Year Retention (1,095 days):

• Market data (tick-by-tick)
• System performance metrics
• Application logs (info/debug level)

1-Year Retention (365 days):

• Session logs
• Health check logs
• Monitoring alerts (non-critical)

Archival Process

Automated Monthly Archival:

1. Identify Old Data (T+0)

   • Query for events older than 1 year
   • Group by month and partition

2. Export to Parquet (T+1)

   • Convert to Parquet format
   • Compress with Snappy
   • Calculate SHA-256 checksum

3. Upload to S3 Glacier (T+2)

   • Upload to s3://foxhunt-audit-archive/YYYY/MM/
   • Set lifecycle policy (Glacier Deep Archive after 1 year)
   • Tag with metadata (date range, event count, checksum)

4. Verify Archive (T+3)

   • Download sample of archived data
   • Recalculate checksum
   • Compare event counts

5. Purge from PostgreSQL (T+4)

   • ONLY after successful archive verification
   • Drop old partitions (fast, no DELETE scan)
   • Log purge operation in compliance system

Disaster Recovery:

• Archive stored in 3 AWS regions (us-east-1, us-west-2, eu-west-1)
• Monthly restore testing (sample 1% of archived data)
• RPO (Recovery Point Objective): 24 hours
• RTO (Recovery Time Objective): 4 hours

---

Certification Process

Quarterly Certification

Timeline: Within 90 days of quarter end

Steps:

1. Control Testing (Days 1-60)
2. Deficiency Assessment (Days 61-75)
3. Management Review (Days 76-85)
4. CEO/CFO Certification (Day 90)

See Section 302 for detailed certification template.

Annual Assessment

Timeline: Within 90 days of fiscal year end

Steps:

1. Design Effectiveness Testing (Days 1-60)
2. Operating Effectiveness Testing (Days 1-75)
3. Deficiency Remediation (Days 1-75)
4. Management Assessment Report (Days 76-85)
5. External Auditor Attestation (Days 86-90)

See Section 404 for detailed assessment report template.

---

Compliance Testing

Test Execution Schedule

Monthly:

• Position valuation control (CTRL-002)
• Audit trail integrity spot checks

Quarterly:

• Trade authorization control (CTRL-001)
• P&L calculation control (CTRL-003)
• Audit trail integrity comprehensive test (CTRL-004)
• Change management control (CTRL-005)
• User access reviews

Annual:

• Full control design effectiveness testing
• Full control operating effectiveness testing
• External auditor attestation

Test Documentation

Required Evidence:

• Test plan and procedures
• Sample selection methodology
• Control execution evidence (logs, approvals, reports)
• Test results (pass/fail, exception details)
• Management sign-off

Retention: 7 years (aligned with audit trail retention)

---

Additional Resources

• Audit Trail Queries: See AUDIT_TRAIL_QUERIES.md for SQL examples
• Separation of Duties: See SEPARATION_OF_DUTIES.md for SOD matrix
• Change Control: See CHANGE_CONTROL_TEMPLATES.md for templates

---

Document Owner: Compliance Officer Approval: CFO, CTO, General Counsel Next Review Date: 2026-01-01