Model Risk Summary

1. Scope and intended use

The Verus valuation model produces fair-value estimates for private credit facilities across seven asset types — direct lending, mezzanine, CRE debt, distressed, distressed bonds, illiquid public bonds and secured borrowing — under the methodology summarised at /methodology. Intended uses: quarterly NAV computation, IFRS 9 staging input, IFRS 13 Level-3 mark substantiation, sensitivity / stress-test analysis, and internal reconciliation against independent valuation agents. Outputs are not investment advice, a recommendation, or a solicitation, and do not constitute a fairness opinion.

2. Framework alignment

• SR 11-7 (US Fed / OCC, 2011) — model development, implementation, use, validation, and governance.
• SS1/23 (Bank of England PRA, 2023) — the UK equivalent; principles 1–5 cover identification, governance, development, testing, and validation.
• IFRS 13.91–99 / ASC 820 — fair-value hierarchy disclosure and sensitivity to unobservable inputs.

Verus does not claim SR 11-7 certification — the framework is supervisory-issued, not a credential. What it does claim is that its development discipline, testing, and validation posture map cleanly onto SR 11-7 §§ V.5 and SS1/23 principles 3–5, and that a reviewer using either framework will find the corresponding artefacts on request.

3. Conceptual soundness

• Yield (DCF) path — canonical contractual- cashflow discounting: PV = Σ E[CF_t] × DF_OIS(t) × exp(−s·τ). Hazard- rate credit adjustment and LGD recovery applied to expected cashflows. No stochastic draws in the pricing path.
• Recovery path — EV waterfall allocation discounted at a distressed rate, invoked when coverage inputs show the subject tranche is inadequately covered.
• Blended path — probability-weighted mix of yield-base, yield-downside (with under-coverage spread uplift), and recovery, weighted by explicit scenario probabilities that are constrained to sum to 1.
• Calibration — the authoritative spread is solved from the transaction price at origination, then carried forward with a market-drift adjustment from the Verus spread composite. A calibration trace is written with every calibrated or grid-anchored run.

4. Data inputs & quality controls

• Deal-term inputs — day-count, frequency, margin/spread, amortisation, fees, OID, and covenant metadata captured on a versioned Deal record. Content-hashed via SHA-256 so every run has an identifiable input.
• Assumption sets — PD term structure, LGD parameters, CPR prepayment, scenario weights. Also content- hashed and versioned.
• Market data — OIS curve snapshots (FRED public-domain series) and the Verus spread composite (SEC EDGAR BDC filings + DTCC SDR CDS prints, markst-derived). Every persisted row carries its source; market-history series also record their fetch date.
• Reference datasets — quarterly BDC holdings (public 10-Q disclosures); a primary-source BSL facility corpus is under construction. Source and refresh cadence documented at /reference-data.

5. Validation and effective challenge

• 10-check validation suite runs in CI on every change: determinism (same inputs and engine release → same outputs), PV positivity, price and PV bounds, non-negative expected loss, monotonicity in spread, default probability and recovery, cashflow-to-PV consistency, and component additivity.
• Golden-number CI harness freezes PV, price, yield and DV01 on ten canonical deals and fails any change that moves them by more than about 0.1 bp. Re-baselining requires an explicit flag and a dedicated commit.
• Public-reference sanity benchmarks — (i) every run warns when its spread anchor is more than 90 days old or sits more than 40 bps from the live Verus composite level; (ii) the fair-value level is escalated to Level 2 only when an observable price or a reliable broker quote sits within tolerance of the mark; (iii) on request, the borrower is matched against ingested BDC 10-Q holdings and the cohort's marks are reported alongside. The primary-source SEC EDGAR 8-K BSL facility corpus that would extend these comparisons is under construction (see /reference-data §3–§4). They are sanity benchmarks, not a formal challenger model — see §6.
• Challenger model & back-testing cadence — see §6. An adversarial challenger runs today; the Comparable-Spread Reprice challenger and the back-testing rhythm are committed framework for the first production deployment. Independent model validation has not yet been performed.
• Outcomes analysis — on any facility exit event (prepay / amend / refinance / default) in a production deployment, the realised cashflow versus the model's projected distribution will be logged to the outcomes dataset defined in §6, which feeds the periodic review in §9.
• Review and challenge — every methodology change is a pull request reviewed and approved by the director, and is not released unless the golden-number harness and the full test suite pass. markst has no second reviewer today, so independent effective challenge will come from external model validation; until then the controls are those gates, the published limitations register and the change log.

6. Challenger model & back-testing cadence

6.1 Challenger model. The primary engine (see /methodology) is a hazard-adjusted DCF with calibrated spread. The challenger is deliberately structurally different so that a shared error in either model is unlikely to cancel in the comparison.

• Named specification. “Comparable-Spread Reprice” (CSR v1) — for each subject facility, the challenger reprices by taking the tightest-matching public reference (BSL tranche or BDC holding) by structure, sector, seniority and residual tenor, adjusting its observable spread for size, covenant-package and rating differentials using pre-set basis-point add-ons, and discounting the subject's contractual cashflows at that adjusted spread. No hazard- rate path, no waterfall, no LGD model — that structural simplicity is the point.
• Inputs. Subject deal terms (from the versioned Deal record); the comparable's observable spread and structure metadata (from the reference universe at the run reference date); the structural-adjustment table (published, versioned, same governance as the assumption set).
• Output. A single fair-value number per facility, an applied-adjustment breakdown, and the identity and distance of the chosen comparable. A CSR run is cheap and is produced alongside every primary run in deployments where the challenger is enabled.
• Scope & limits. CSR runs for facilities where at least one structural match exists within the distance tolerance. Where no match is available — thin-file CRE debt, unusual private placements, highly distressed — the challenger returns “no comparable” and the run carries that tag; a primary output is still produced.

Challenger in operation today. Until CSR is live, any facility can be run through an adversarial challenger pass: five bear shocks (spread +300 bps, hazard × 3, recovery −20 points, rates +200 bps, prepayment switched off) are priced independently, ranked by the value each removes, and the three largest are applied jointly. The pass is reproducible from a hash of its inputs and outputs.

6.2 Back-testing cadence. Back-testing means two different things here and the specification is explicit about both.

• Continuous, event-driven back-testing. On every facility exit event captured in a production deployment — contractual maturity, prepay, amend, refinance, default, recovery — the realised cashflow is compared against the model's projected distribution at the most recent reference date before the event. The error, signed and unsigned, is persisted to the outcomes dataset with the reference-date run id, the engine version, and the deal and assumption-set versions.
• Quarterly portfolio back-testing. At each quarter close, the aggregate error distribution is computed across all facilities with at least one reference-date run in the preceding four quarters. Headline statistics: mean signed error (directional bias), mean unsigned error (accuracy), 95th-percentile error (tail), and distribution of primary-minus-challenger divergence (model-disagreement). A quarterly back-testing memo is produced.
• Divergence investigation triggers. Any of the following trigger a scheduled investigation within one month: mean signed error exceeds ±50 bps of fair value on any stratum of ≥20 facilities; 95th-percentile unsigned error exceeds 200 bps; primary-vs-challenger divergence exceeds 100 bps on a single facility; or the divergence distribution shifts by more than one standard deviation quarter-over-quarter. Investigations conclude with a documented finding: no-action, parameter recalibration, methodology change (following change control in §7), or scope limitation.
• Artefacts. The outcomes dataset, the quarterly back-testing memos, and the investigation log will form part of the validation pack described in §10 and will be provided to an independent validator.

6.3 Current operational state. As of 26 September 2026, Verus is pre-production for customer books: trial and demonstration books run on the platform, but no customer uses Verus marks as its book of record. The CSR challenger model specification is complete; the calibration of its structural-adjustment table will be frozen immediately prior to the first production deployment and carried forward under the same change-control governance as the assumption set. The outcomes dataset holds no realised exit events, so the quarterly back-testing cadence begins at the first reference date after first production deployment. The public-reference sanity benchmarks in §5 run today on the built-in BSL and BDC universe for any valued facility.

7. Change control

• Every methodology change is a reviewed pull request and is not released unless the golden-number harness and the full test suite pass. CI also fails if the canonical outputs move without an engine version bump.
• Each release is recorded in the methodology change log with the change and its direction of effect on marks; a release that moves the canonical deal set re-baselines it in a dedicated commit.
• Every run records the engine version, the content hashes of its deal and assumption-set versions and the market-data snapshot hash; calibrated and grid-anchored runs also carry a calibration trace. Sub-model tables and calibration vintages carry their own version labels. The engine version follows a published policy: a major release for any change to a pricing convention or quote basis, a minor release for any other change that moves an output, bumped in the same change.
• Stored runs are not silently re-run when the methodology changes. Re-running one on the same engine release from its recorded inputs reproduces it; a market-data snapshot that no longer matches its hash is refused.
• Clients are notified of any release that would materially move an outstanding mark.

8. Known limitations

• Confidence ranges use normal-quantile bumps on a static spread volatility set by capital structure, not an empirically estimated one. Private-credit spread distributions exhibit skew and occasional kurtosis that a normal model understates — use the output range as an indicative band, not as a tail-risk estimate.
• Reference-data coverage (BDC holdings; the BSL corpus is under construction) is dense for middle- market US sponsor-backed deals; sparser for UK/EU private placements and for CRE debt. Absence of a comparable does not invalidate a mark but widens the defensibility surface.
• The engine is not a credit forecasting model. Hazard rates are taken from the assumption set; the model does not estimate obligor-specific PDs from raw financials.
• AI extraction is optional and human-reviewed; when enabled, mis-reads of term-sheet fields can propagate into inputs unchanged. See /legal/ai-usage.
• Facilities in currencies other than USD are discounted on the USD SOFR OIS curve plus a currency credit-spread basis unless a currency-specific curve is supplied.
• Multi-factor weights and score breakpoints are set by expert judgement. Their effect on a direct-lending mark is bounded to between −75 and +250 bps.
• The complete register, including implementation observations, is in the methodology whitepaper (§10).

9. Review cadence

The model is reviewed annually and on any material methodology change. The review covers: data-input quality, challenger model and sanity-benchmark performance, outcomes analysis and quarterly back-testing results (§6), known-limitations register, and regulatory / standards updates (IFRS, ASC, SR 11-7, SS1/23). The resulting report will form part of the validation pack (§10).

10. Requesting model documentation

The methodology whitepaper — equation set, approach router, spread-volatility derivation, validation-suite specification, known-limitations register and change log — is available under NDA from legal@markst.com. We return it within one business day and will walk a client's MRM function through it on a scheduled call. A full SR 11-7 / SS1/23 validation pack (conceptual soundness narrative, data-quality audit, effective-challenge record, outcomes analysis and back-testing results) is being assembled; its outcomes and back-testing sections begin with the first production book.

11. Related documents

• /methodology — what the model does.
• /legal/ai-usage — where AI is and is not used (it is not in the pricing path).
• /legal/conflicts-of-interest — governance posture preventing bias in the pricing path.
• /trust — security posture and compliance status.