Last Updated: 2026-01-10 Status: Strategic Planning Author: Massimo Todaro / Claude

RISKCORE is a READ-ONLY risk aggregation platform. We never write back to source systems, never execute trades, and never modify client booking data. This fundamentally shapes our security posture:

What we ARE:

• A viewing and analytics platform
• A data processor (clients are data controllers)
• A read-only overlay on existing systems

What we are NOT:

• A trading platform (no risky actions can go through us)
• An order management system
• A data controller for position/trade data

This document covers authentication, authorization, data protection, GDPR compliance, and audit requirements.

1. Core Security Principles
2. Authentication
3. Authorization & Role-Based Access Control
4. Data Protection
5. GDPR & Data Residency
6. Audit Logging
7. Export Controls
8. API Security
9. Infrastructure Security
10. Incident Response
11. Compliance Roadmap
12. Future: Treasury Risk Module

Multiple layers of security:

┌─────────────────────────────────────────────────────────────┐
│                    LAYER 1: NETWORK                         │
│            HTTPS everywhere, API rate limiting              │
├─────────────────────────────────────────────────────────────┤
│                    LAYER 2: AUTHENTICATION                  │
│     Supabase Auth, JWT tokens, 2FA (Enterprise)            │
├─────────────────────────────────────────────────────────────┤
│                    LAYER 3: AUTHORIZATION                   │
│     Row Level Security, Role-based permissions              │
├─────────────────────────────────────────────────────────────┤
│                    LAYER 4: DATA PROTECTION                 │
│     Encryption at rest, encryption in transit               │
├─────────────────────────────────────────────────────────────┤
│                    LAYER 5: AUDIT                           │
│     Sensitive action logging, immutable audit trail         │
└─────────────────────────────────────────────────────────────┘

• Users get minimum permissions required for their role
• PMs see only their own book(s)
• Analysts see only assigned books
• No user can access another tenant's data

• RISKCORE never writes back to source systems
• We cannot modify booking system data
• No trade execution capability
• Risk mitigation: even if compromised, no financial damage to client portfolios

Provider: Supabase Auth

Features:

• JWT-based session management
• Secure password hashing (bcrypt)
• Email verification on signup
• Password reset flow
• Session expiry (configurable, default 7 days)

Availability: Enterprise tier only

Supported Methods:

• TOTP (Google Authenticator, Authy, etc.)
• SMS backup (optional)

Implementation: Supabase Auth MFA

-- User table extension for 2FA
ALTER TABLE users ADD COLUMN mfa_enabled BOOLEAN DEFAULT FALSE;
ALTER TABLE users ADD COLUMN mfa_secret TEXT; -- Encrypted TOTP secret

Status: Nice-to-have, Phase 2-3

Planned Support:

• SAML 2.0
• OAuth 2.0 / OpenID Connect
• Azure AD
• Okta
• Google Workspace

Implementation: Third-party provider (WorkOS, Auth0) or Supabase Enterprise

SUPERADMIN (RISKCORE Team)
    │
    └── ADMIN (Firm Admin)
            │
            ├── CIO/CEO (All books, view-only)
            │
            ├── CRO (All books, can set limits)
            │
            ├── PM (Own book(s) only)
            │
            └── ANALYST (Assigned books, view-only)

Implementation: Supabase PostgreSQL RLS

-- Enable RLS on all tables
ALTER TABLE positions ENABLE ROW LEVEL SECURITY;
ALTER TABLE books ENABLE ROW LEVEL SECURITY;
ALTER TABLE users ENABLE ROW LEVEL SECURITY;

-- Tenant isolation policy
CREATE POLICY tenant_isolation ON positions
    FOR ALL
    USING (tenant_id = (SELECT tenant_id FROM users WHERE id = auth.uid()));

-- Book access policy
CREATE POLICY book_access ON positions
    FOR SELECT
    USING (
        book_id IN (
            SELECT book_id FROM user_book_access WHERE user_id = auth.uid()
        )
        OR
        (SELECT role FROM users WHERE id = auth.uid()) IN ('admin', 'cio', 'cro')
    );

{
  "sub": "user-uuid",
  "email": "user@firm.com",
  "tenant_id": "tenant-uuid",
  "role": "pm",
  "book_ids": ["book-1-uuid", "book-2-uuid"],
  "plan": "pro",
  "mfa_verified": true,
  "exp": 1704931200
}

Policy: 5 years, not configurable

Rationale: Financial regulations typically require 5-7 year retention. Fixed policy simplifies compliance.

On account termination:

1. User requests deletion via Admin
2. 30-day grace period (recoverable)
3. Permanent deletion after grace period
4. Audit log retained (anonymized)

Note: Data may be retained longer if required by law (e.g., regulatory investigation).

Role: Data Processor

Why? RISKCORE processes data on behalf of clients (Data Controllers). We do not determine the purpose of data collection — clients do.

Client Role: Data Controller

Relationship:

Client (Hedge Fund) → Data Controller
         ↓ instructs
RISKCORE → Data Processor
         ↓ uses
Supabase → Sub-processor

Key Insight: Most RISKCORE data (positions, trades, risk metrics) is NOT personal data. GDPR primarily applies to user account data.

From research:

"GDPR does not mandate that data must physically reside within the European Union. However, it does heavily regulate any transfer of personal data to countries outside the EEA."

Legal Mechanisms for US Data Storage:

1. EU-US Data Privacy Framework — Adequacy decision for certified US companies
2. Standard Contractual Clauses (SCCs) — Contractual safeguards
3. Binding Corporate Rules — For corporate groups

MVP / Pro Tier:

• US infrastructure (Supabase, AWS us-east)
• Adequate for most clients
• SCCs and DPA template provided

Enterprise Tier (Phase 2-3):

• EU region option (Supabase EU, AWS eu-west)
• Required for some European clients
• IP whitelisting available

Required for all clients processing EU data. Template includes:

• Nature and purpose of processing
• Types of personal data processed
• Duration of processing
• Sub-processors list (Supabase, etc.)
• Security measures
• Breach notification procedures
• Data subject rights procedures

Clients are responsible for:

• Lawful basis for collecting position/trade data
• Informing their employees (PMs, traders) about data processing
• Responding to data subject requests
• Notifying RISKCORE of any data subject requests

RISKCORE is responsible for:

• Processing data only as instructed by client
• Implementing appropriate security measures
• Assisting client with data subject requests
• Notifying client of data breaches within 72 hours
• Maintaining records of processing activities
• Providing DPA to all clients

Sensitive actions only (start simple, expand later)

Rationale: We are a viewing platform, not a trading platform. No risky actions can go through us. We focus on logging:

• Authentication events
• Authorization changes
• Data exports
• Configuration changes
• Limit breaches

CREATE TABLE audit_logs (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    tenant_id UUID NOT NULL REFERENCES tenants(id),
    user_id UUID REFERENCES users(id),  -- NULL for system events
    action VARCHAR(100) NOT NULL,
    category VARCHAR(50) NOT NULL,
    resource_type VARCHAR(50),
    resource_id UUID,
    details JSONB,  -- Additional context
    ip_address INET,
    user_agent TEXT,
    created_at TIMESTAMPTZ DEFAULT NOW()
);

-- Index for efficient querying
CREATE INDEX idx_audit_tenant_date ON audit_logs(tenant_id, created_at DESC);
CREATE INDEX idx_audit_user ON audit_logs(user_id, created_at DESC);
CREATE INDEX idx_audit_action ON audit_logs(action);

{
  "action": "USER_LOGIN_SUCCESS",
  "category": "authentication",
  "details": {
    "method": "password",
    "mfa_used": true
  }
}

{
  "action": "EXPORT_RISKBOARD",
  "category": "data_export",
  "resource_type": "riskboard",
  "details": {
    "format": "csv",
    "books_included": ["book-1", "book-2"],
    "as_of_date": "2026-01-10"
  }
}

{
  "action": "LIMIT_BREACH",
  "category": "limit_events",
  "resource_type": "risk_limit",
  "resource_id": "limit-uuid",
  "details": {
    "limit_type": "hard",
    "risk_factor": "equity_beta",
    "limit_value": 5000000,
    "actual_value": 5234000,
    "breach_pct": 4.68
  }
}

• Retention: 5 years
• Storage: Immutable (append-only)
• Access: SuperAdmin and Admin (own tenant only)
• Export: SuperAdmin only

Potential future logging (not MVP):

• Page views / feature usage (for analytics)
• Search queries
• Correlation matrix views
• Every API call (for debugging)

Underlying Trades — SuperAdmin Only:

• Raw source data from client booking systems
• Most sensitive data in the platform
• Exporting could expose proprietary trading strategies
• Only RISKCORE team needs this for debugging/support

Riskboard — Admin, CIO, CRO:

• Aggregated exposure data
• CROs need to share risk reports with boards and regulators
• Already abstracted from individual trades

Correlation Matrix — Admin, CIO, CRO:

• Analytical output, not raw data
• Useful for board presentations
• No trade-level detail

PM Drill-down — CRO + PM (own book only):

• More sensitive than Riskboard (shows book-level detail)
• PMs should be able to export their own book's risk
• CRO needs access to all books for oversight
• Analysts can view but not export

All exports include:

• Timestamp
• User who exported
• Tenant name
• "Confidential — [Tenant Name]" watermark (PDF)

Availability: Admin role only

Method: API Key + JWT

# API request example
curl -X GET https://api.riskcore.io/v1/riskboard \
  -H "Authorization: Bearer <jwt_token>" \
  -H "X-API-Key: <api_key>"

• Keys created/revoked by Admin
• Keys are hashed in database (never stored in plain text)
• Each key has:
  • Name/description
  • Expiry date (optional)
  • Last used timestamp
  • IP whitelist (Enterprise)

Implementation: FastAPI middleware

from slowapi import Limiter
from slowapi.util import get_remote_address

limiter = Limiter(key_func=get_remote_address)

@app.get("/v1/riskboard")
@limiter.limit("100/minute")  # Pro tier
async def get_riskboard():
    ...

Implementation: Pydantic models

• All inputs validated before processing
• SQL injection prevention via parameterized queries
• XSS prevention via output encoding
• File upload validation (type, size)

HTTPS Everywhere:

• All traffic encrypted via TLS 1.3
• HSTS enabled
• Certificate managed by Cloudflare/Vercel

Secrets Management:

• Environment variables for all secrets
• Never commit secrets to code
• Rotate API keys annually
• Use .env.local for development (gitignored)

Dependency Security:

• Dependabot enabled for vulnerability scanning
• Monthly dependency updates
• No known critical vulnerabilities policy

1. Detect: Automated monitoring or user report
2. Contain: Isolate affected systems
3. Assess: Determine scope and impact
4. Notify:
   • Internal team: Immediately
   • Affected clients: Within 72 hours (GDPR requirement)
   • Regulators: Within 72 hours if required
5. Remediate: Fix vulnerability, restore systems
6. Review: Post-incident analysis, update procedures

• Security issues: security@riskcore.io
• General support: support@riskcore.io
• Emergency (Enterprise): Dedicated Slack channel

Future module for capital risk, regulatory capital, and liquidity risk:

Treasury Risk module will require:

• Stricter access controls (regulatory data)
• Enhanced audit logging
• Regulatory reporting exports (restricted)
• Potential data residency requirements (jurisdiction-specific)

Placement: Bottom-right corner of dashboard

Style:

• Small, subtle, non-intrusive
• Light gray text on light background
• Does not obstruct any functionality
• Tasteful, professional

Implementation:

// Free tier only
{plan === 'free' && (
  <div className="fixed bottom-4 right-4 text-xs text-gray-400 opacity-60">
    Powered by RISKCORE
  </div>
)}

Removal: Upgrading to Pro tier removes the watermark.

• All secrets in environment variables
• RLS enabled on all tables
• Input validation on all endpoints
• Rate limiting configured
• HTTPS enforced
• Audit logging active
• Backup system tested
• DPA template ready
• Privacy policy published
• Security contact published

Security architecture for RISKCORE platform