Regulatory Landscape¶

CalcBridge exists because financial regulations demand accurate, auditable, and timely calculations. Understanding which regulations drive which features helps engineers prioritize work and design systems that satisfy regulatory intent rather than just checking boxes.

This page covers the regulatory environment for both CLO management and loan servicing. Engineers do not need to become regulatory experts, but they do need enough context to understand why features exist and who mandates them.

Why Regulation Drives Demand for CalcBridge¶

Financial institutions do not adopt calculation platforms for fun. They adopt them because:

1. Manual processes cannot scale -- Regulators demand increasingly granular reporting. Running 24 compliance tests across 10 CLO deals in Excel takes 200+ hours per reporting cycle.
2. Audit trails are mandatory -- "I ran the numbers in my spreadsheet" is not an acceptable audit response. Regulators want timestamped, immutable records of who calculated what, when, with which data.
3. Errors have consequences -- A misreported OC ratio can trigger unnecessary cash diversion. A misclassified delinquency can result in regulatory fines. The cost of a compliance error exceeds the cost of a compliance platform.
4. Regulation is expanding -- New frameworks (DORA, updated Basel standards, CFPB rules) continuously add requirements. Each new regulation is a feature request.

flowchart TD
    REG["Regulatory Requirements"] --> DATA["Data Accuracy"]
    REG --> AUDIT["Audit Trails"]
    REG --> TIME["Timeliness"]
    REG --> REPORT["Reporting"]

    DATA --> CB["CalcBridge Features"]
    AUDIT --> CB
    TIME --> CB
    REPORT --> CB

    CB --> FORMULA["Formula Engine"]
    CB --> COMPLIANCE["Compliance Tests"]
    CB --> PROVENANCE["Export Provenance"]
    CB --> RETENTION["Data Retention"]

    style REG fill:#FEF3C7,stroke:#F59E0B
    style CB fill:#DCFCE7,stroke:#22C55E

Regulation Reference Table¶

European Regulations¶

EU Securitisation Regulation (Regulation 2017/2402)¶

What it requires: The EU Securitisation Regulation establishes a framework for simple, transparent, and standardized (STS) securitisations. Even non-STS securitisations must comply with transparency and due diligence requirements.

Key articles affecting CalcBridge:

DORA (Digital Operational Resilience Act)¶

What it requires: DORA mandates that financial entities manage ICT (Information and Communication Technology) risk with the same rigor as financial risk. It applies to virtually all regulated financial entities in the EU.

Relevant requirements:

• ICT risk management framework -- Documented policies and procedures for all technology systems
• Incident reporting -- Major ICT incidents must be reported to regulators within defined timelines
• Digital operational resilience testing -- Regular testing of ICT systems including penetration testing
• Third-party risk management -- Oversight of critical ICT service providers

CalcBridge relevance: As a calculation platform used for regulatory reporting, CalcBridge itself falls under third-party ICT risk management. Clients must be able to demonstrate that CalcBridge operates with appropriate controls. This drives requirements for:

• Audit logging and observability (OpenTelemetry, Prometheus)
• SOC 2 compliance evidence
• System availability and resilience documentation
• Incident response procedures

Solvency II¶

What it requires: Solvency II is the EU regulatory framework for insurance companies. When insurers invest in CLOs, they must calculate capital charges based on the underlying credit quality of the portfolio.

CalcBridge relevance: Insurance investors in CLOs need look-through analytics -- the ability to see past the CLO tranche rating to the underlying loan portfolio. CalcBridge's WARF calculations and rating analytics support this requirement.

UK Regulations¶

FCA SYSC 9 (Systems and Controls)¶

What it requires: The FCA requires regulated firms to maintain orderly records of their business and internal organization. This includes records of all services and transactions.

CalcBridge relevance: Every compliance test run, every calculation, every data import must be logged with sufficient detail for regulatory reconstruction. CalcBridge's audit trail infrastructure supports FCA record-keeping requirements.

MiFID II Article 16(5)¶

What it requires: Investment firms must keep records of all services, activities, and transactions for a period sufficient to allow supervisory authorities to monitor compliance. In practice, this means 7+ years of retention.

CalcBridge relevance: Compliance test results, calculation inputs, and formula configurations must be retained for the full regulatory period. This affects database sizing, archival strategies, and data lifecycle management.

US Regulations¶

SEC Rule 17a-4¶

What it requires: Broker-dealers must preserve certain records in a non-rewriteable, non-erasable format (WORM -- Write Once, Read Many). While CalcBridge clients are not all broker-dealers, the principle extends to any firm that produces records used for regulatory compliance.

CalcBridge relevance: Export provenance features ensure that reports generated by CalcBridge are traceable to their source data and calculations. The immutability of audit logs supports WORM-equivalent compliance.

US Risk Retention (Dodd-Frank Section 941)¶

What it requires: CLO managers must retain at least 5% economic interest in the deals they manage. This can be a horizontal slice (equity tranche), vertical slice (pro-rata across all tranches), or a combination.

CalcBridge relevance: Portfolio monitoring features track the manager's retained interest and verify it remains compliant. This is a CLO-specific requirement with no direct servicing equivalent.

CFPB Servicing Rules (Regulation X, 12 CFR Part 1024)¶

What it requires: The Consumer Financial Protection Bureau regulates mortgage servicers with rules covering:

• Early intervention -- Contact delinquent borrowers within 36 days
• Continuity of contact -- Assign dedicated personnel to delinquent borrowers
• Loss mitigation -- Evaluate borrowers for all available options within 30 days
• Dual-tracking prohibition -- Cannot advance foreclosure while modification is pending
• Periodic statements -- Monthly billing statements with specific disclosures
• Escrow management -- Annual analysis, surplus refunds, shortage notifications

CalcBridge feature mapping:

RESPA (Real Estate Settlement Procedures Act)¶

What it requires: RESPA regulates the real estate settlement process, including escrow account management. Key provisions:

• Escrow cushion limited to two months of disbursements
• Annual escrow analysis required
• Surplus above $50 must be refunded within 30 days
• Shortage may be spread over 12 months for borrower payment
• Initial escrow account statement at closing

CalcBridge relevance: Escrow calculation and validation logic must implement RESPA limits precisely. This is documented in the Servicing Compliance Tests framework.

State-Level Servicing Regulations¶

Challenge: US mortgage servicing is also regulated at the state level, with significant variation:

Global Frameworks¶

Basel III/IV and SR 11-7 (Model Risk Management)¶

What it requires: SR 11-7 (published by the US Federal Reserve and OCC) establishes expectations for model risk management. Any quantitative model used for decision-making or regulatory reporting must be:

• Independently validated -- Someone other than the model developer must verify it
• Documented -- Model assumptions, limitations, and methodology must be recorded
• Monitored -- Ongoing performance tracking to detect model degradation
• Governed -- Senior management oversight with clear accountability

CalcBridge relevance: CalcBridge's formula engine and compliance calculations are "models" under SR 11-7. The spec-based validation approach -- where calculation specifications are maintained separately from implementation -- supports independent validation. CalcBridge's audit trails provide the documentation and monitoring infrastructure.

flowchart LR
    subgraph SR11_7["SR 11-7 Requirements"]
        V["Independent\nValidation"]
        D["Documentation"]
        M["Monitoring"]
        G["Governance"]
    end

    subgraph CalcBridge["CalcBridge Implementation"]
        SPEC["Spec-Based\nFormulas"]
        AUDIT["Audit\nTrails"]
        METRICS["Prometheus\nMetrics"]
        RLS["Tenant\nIsolation"]
    end

    V --> SPEC
    D --> AUDIT
    M --> METRICS
    G --> RLS

    style SR11_7 fill:#FEF3C7,stroke:#F59E0B
    style CalcBridge fill:#DCFCE7,stroke:#22C55E

GDPR (General Data Protection Regulation)¶

What it requires: GDPR regulates the processing of personal data of EU residents. For financial platforms, this means:

• PII (personally identifiable information) must be encrypted at rest and in transit
• Data subjects have the right to access and erasure of their personal data
• Data processing activities must be documented
• Data breaches must be reported within 72 hours

CalcBridge relevance: CalcBridge's encryption service (AES-GCM) handles PII encryption for loan-level data that may contain borrower information. The right to erasure creates tension with MiFID II's 7-year retention requirement -- pseudonymization is the typical resolution.

European vs US Regulatory Differences¶

Engineers working across both segments should understand the structural differences between European and US regulatory approaches:

Regulatory Impact on Feature Prioritization¶

Understanding regulatory drivers helps product and engineering teams prioritize:

High Priority (Regulatory Mandate)¶

Features that directly satisfy a regulatory requirement with enforcement consequences:

Medium Priority (Competitive Advantage)¶

Features that go beyond minimum compliance and differentiate CalcBridge:

Lower Priority (Future Regulatory)¶

Features driven by regulations that are coming or expanding:

Servicing-Specific Regulatory Context¶

Servicing regulations are distinct from CLO/investment regulations in several ways that affect CalcBridge feature design:

Borrower-Centric vs Investor-Centric¶

CLO regulations protect investors -- the entities that bought CLO tranches. They care about portfolio-level metrics.

Servicing regulations protect borrowers -- the individuals or entities that took out loans. They care about individual loan-level accuracy.

This means servicing features must operate at loan-level granularity with per-borrower audit trails, while CLO features can operate at portfolio-level aggregates.

Continuous vs Periodic¶

CLO compliance is typically assessed monthly or quarterly, aligned with trustee reporting cycles.

Servicing compliance is continuous. A payment received today must be applied correctly today. A borrower who becomes 30 days delinquent today must be contacted within specific timelines starting today.

This affects monitoring architecture: CLO tests can run as batch jobs; servicing tests may need event-driven triggers.

Multiple Overlapping Regulators¶

A US mortgage servicer may be subject to:

• Federal: CFPB, HUD, Ginnie Mae, FHFA
• GSE: Fannie Mae, Freddie Mac servicing guides
• State: 50+ state regulatory agencies
• Investor: Private-label securitization servicing agreements

Each may impose different requirements for the same activity (e.g., foreclosure timelines). CalcBridge must accommodate the most restrictive applicable requirement.

Related Documentation¶

• Compliance Testing Overview -- CLO compliance test framework
• Servicing Compliance Tests -- Servicing test categories and implementation
• Servicer Domain -- Servicer domain architecture and FARF details
• CLO Domain -- CLO domain for regulatory context comparison