Skip to content

Financial Sector Overlay

Jump to bottom
evidentia-wiki-sync[bot] edited this page May 29, 2026 · 1 revision

Auto-generated mirror. This page mirrors docs/financial-sector-overlay.md, the canonical source of truth. Do not edit this file directly; edit docs/financial-sector-overlay.md and re-run scripts/wiki/sync_mirrors.py.

Financial-services regulatory overlay

The v0.7.9 + v0.7.10 capability surface together form Evidentia's financial-services regulatory overlay — a coherent module suite that brings the OSS GRC tool into alignment with the regulatory stack federally-supervised banks, broker-dealers, insurers, and credit unions are required to operate under.

This document narrates how the v0.7.9 TPRM module + v0.7.10 Model Risk Management module + v0.7.10 governance primitives compose into one auditor-defensible toolchain.

The regulatory stack

The four major financial-services regulators (OCC + FRB + FDIC + NCUA) plus FFIEC + state insurance commissioners promulgate a multi-layered supervisory framework:

Domain Primary guidance Evidentia surface
Third-party risk OCC Bulletin 2013-29; FRB SR 13-19; FFIEC IT Examination Handbook (Outsourcing booklet) evidentia tprm vendor (v0.7.9 P0.1)
Vendor due diligence Shared Assessments SIG / SIG-Lite; CSA CAIQ evidentia tprm dd-questionnaire (v0.7.9 P0.2)
Concentration risk OCC + FRB + FFIEC outsourcing concentration expectations evidentia tprm concentration-report (v0.7.9 P0.3)
Model risk OCC Bulletin 2011-12 / FRB SR 11-7 (active 2011-2026); OCC Bulletin 2026-13a / FRB SR 26-02 (April 2026 supersession) evidentia model-risk model (v0.7.10 P0.6)
Three Lines of Defense IIA Three Lines Model 2020 revision; FFIEC IT Examination Handbook (Management booklet) evidentia governance lines-report (v0.7.10 P1.5 G1)
Effective challenge SR 11-7 §III.D + SR 26-02 + OCC 2026-13a effective-challenge requirements evidentia governance challenge (v0.7.10 P1.5 G2)
AI / LLM governance SR 26-02 / OCC 2026-13a explicit GenAI exclusion — regulator-vacuum gap Evidentia GenerationContext + RiskStatement.model_inventory_ref (v0.7.1 + v0.7.10 P0.6.4)
Audit chain-of-custody Regulator examination-evidence requirements; Sarbanes-Oxley §404 OSCAL emit + Sigstore signing + (v0.7.11) WORM backends

The composition story

A regulated bank deploying ML/AI to make consumer-facing decisions needs to satisfy SR 11-7 / SR 26-02 model-risk expectations while ALSO satisfying TPRM expectations for any vendor-supplied component AND demonstrating proper Three Lines of Defense separation AND maintaining effective-challenge documentation.

Pre-Evidentia, this required:

  • A vendor management SaaS (Vanta / Drata / etc.) for TPRM
  • A separate model risk management product (SS&C Algorithmics / SAS / proprietary build) for SR 11-7 / SR 26-02
  • A governance / GRC platform (RSA Archer / Optro / OneTrust) for 3LOD + effective challenge logging
  • Spreadsheet-driven concentration reporting
  • Manual cross-referencing across the toolchain at audit time

With Evidentia v0.7.9 + v0.7.10, the entire flow happens in one OSS toolchain with cross-linked primitives:

Vendor inventory                     Model inventory
(evidentia tprm vendor)         (evidentia model-risk model)
        │                               │
        │ Vendor.id                     │ ModelInventory.vendor_id
        └───────────► cross-link ◄──────┘
                          │
                          ▼
                   Vendor-provenance models
                   carry vendor_id pointing at
                   the TPRM Vendor record so SR 11-7
                   §V (vendor-risk overlay) flows
                   from the same inventory

Model inventory                      Risk statement (AI-generated)
(evidentia model-risk model)         (evidentia risk generate)
        │                                       │
        │ ModelInventory.id                     │ RiskStatement.model_inventory_ref
        └────────────► cross-link ◄─────────────┘
                          │
                          ▼
                Every AI-generated risk statement
                traces back to the model inventory
                entry that documents tier classification,
                validation history, and approval chain.
                SR 11-7 / SR 26-02 audit trace-back
                becomes deterministic.

Owner identity (3LOD-classified)     Effective challenge log
(evidentia governance lines-report)  (evidentia governance challenge)
        │                                       │
        │ Owner.email + line_of_defense         │ EffectiveChallenge.challenger_email +
        │                                       │   challenger_role
        └────────────► used together to ◄───────┘
                       substantiate independence
                       of the challenge per SR 11-7
                       §III.D — challengers must be
                       independent of model dev
                       (typically 2nd or 3rd line)

Worked example

A regional bank wants to ship a new ML-driven credit-scoring model that consumes a vendor-supplied identity-verification service. The full Evidentia flow:

Step 1 — Vendor in TPRM inventory

$ evidentia tprm vendor add \
    --name "Experian Identity Verification" \
    --type saas \
    --criticality-tier critical \
    --relationship-owner vendor-mgmt@bank.example \
    --contract-start-date 2025-01-01 \
    --regulatory-classification financial-services \
    --region us-east
Added vendor (id: 7c3e1a8d-2f9b-4a1c-8d5e-3e7f2c8b1d6a)

Step 2 — Model in MRM inventory, cross-linked to vendor

$ evidentia model-risk model add \
    --name "Consumer credit-scoring model v2" \
    --purpose "Score credit applications using internal + Experian features" \
    --methodology ml \
    --vendor-or-internal vendor \
    --vendor-id 7c3e1a8d-2f9b-4a1c-8d5e-3e7f2c8b1d6a \
    --tier tier_1 \
    --owner credit-modeling@bank.example
Added model (id: 80e8b404-0f2b-4e29-bd8a-617275aa732c)

The ModelInventory.vendor_id cross-link is required for vendor-provenance models (enforced by @model_validator) — SR 11-7 §V vendor-risk overlay flows automatically.

Step 3 — Document the model

$ evidentia model-risk doc generate \
    80e8b404-0f2b-4e29-bd8a-617275aa732c \
    --output reports/credit-model-v2-doc.md
Wrote model documentation to reports/credit-model-v2-doc.md (1842 chars).

Step 4 — Independent validation; log findings

(Operator runs validation; logs findings via inventory edit.)

$ evidentia model-risk validation-report generate \
    80e8b404-0f2b-4e29-bd8a-617275aa732c \
    --output reports/credit-model-v2-validation.md

If any HIGH-severity finding is OPEN, the report carries a warning callout per SR 11-7 §III.D: HIGH findings should block production use until remediated.

Step 5 — 3LOD classification

$ cat owners.yaml
- email: credit-modeling@bank.example
  line_of_defense: first
  team: Consumer Credit
  title: Senior Data Scientist
- email: mrm-director@bank.example
  line_of_defense: second
  team: MRM
  title: Director, Model Risk
- email: audit-lead@bank.example
  line_of_defense: third
  team: Internal Audit
  title: VP, Internal Audit

$ evidentia governance lines-report \
    --classifications owners.yaml \
    --output reports/lines-of-defense.md

Step 6 — Effective challenge log

$ evidentia governance challenge add \
    --subject-model-id 80e8b404-0f2b-4e29-bd8a-617275aa732c \
    --challenger-email mrm-director@bank.example \
    --challenger-role "MRM Director (2nd line)" \
    --challenge-date 2026-01-15 \
    --challenge-topic "Methodology — protected-class fairness review" \
    --challenge-substance "Show disparate-impact analysis across age + race + gender protected classes per FFIEC fair-lending guidance" \
    --outcome pending
Logged challenge (id: 47a4fdcf-c71f-4593-9c46-cc64ccd5a22f)

Step 7 — AI-generated risk statements with model linkage

When the model produces a control gap that needs a risk statement, the AI generator wires the model inventory id:

gen = RiskStatementGenerator(
    model_inventory_id="80e8b404-0f2b-4e29-bd8a-617275aa732c",
)
risk = gen.generate(gap, system_context)
# risk.model_inventory_ref now points at the inventory entry

Every risk statement is now SR-11-7-traceable.

Step 8 — OSCAL emit for examiner handoff

$ evidentia oscal export gap-report.json \
    --vendor-inventory vendors.json \
    --output examiner-package.json
$ evidentia oscal verify examiner-package.json
PASS — all 3 checks pass.

The OSCAL Assessment Results JSON carries the full vendor inventory in back-matter (v0.7.9 P0.5), Sigstore-signed for chain-of-custody integrity. Examiners load the file in compliance-trestle or any OSCAL-compatible viewer.

The GenAI regulator-vacuum positioning

The April 2026 supersession (OCC Bulletin 2026-13a / FRB SR 26-02) explicitly excludes generative AI and agentic AI from the SR 11-7 framework's scope. Banks deploying LLM-driven controls operate without a regulatory framework — which means they also operate without an audit-defensible trace-back framework.

Evidentia's GenerationContext (v0.7.1) captures model + temperature + prompt_hash + run_id + evidentia_version for every AI invocation. Combined with the v0.7.10 P0.6.4 RiskStatement.model_inventory_ref linkage, every LLM-driven risk statement carries:

  1. Pointer to the ModelInventory entry documenting the LLM as a managed model
  2. Provenance for the generation (model + temp + prompt_hash)
  3. Run-id correlation across batch runs

This is SR-replacement-grade audit evidence — banks deploying LLMs can present Evidentia's audit trail as a self-imposed discipline that satisfies the regulator's intent even though the formal framework isn't there yet.

When SR 26-02 / OCC 2026-13a are eventually amended to include generative AI in scope, Evidentia operators are already producing the right evidence — no migration cost.

OSS license + sovereignty

The financial-services overlay ships under Apache 2.0 like the rest of Evidentia. No commercial vendor lock-in; no SaaS fees; no data-residency concerns; air-gap-deployable; OSCAL-compatible output for any examiner toolchain.

Vendor + model + challenge inventories all live in operator-side JSON files (configurable via EVIDENTIA_VENDOR_STORE_DIR / EVIDENTIA_MODEL_STORE_DIR / EVIDENTIA_CHALLENGE_STORE_DIR env vars) — Evidentia never transmits this data to external services.

Coming in v0.7.10+

The financial-services overlay continues to grow:

  • v0.7.10 P1: 7 new bundled catalogs covering FFIEC IT Examination Handbook (Information Security / Audit / Management / Operations / Outsourcing booklets) + OCC 2011-12 / FRB SR 11-7 (model risk) + FFIEC Cybersecurity Assessment Tool. Bundled catalog count goes 89 → 96.
  • v0.7.11 audit chain-of-custody: retention metadata + WORM backend support (S3 Object Lock, Azure Immutable Blob, GCS Bucket Lock) for examiner-grade evidence retention.
  • v0.7.11+ KRI / KPI / KGI: structured metrics dashboards.
  • v0.7.11+ Open FAIR: dollarized risk quantification per Open FAIR taxonomy.
  • v0.7.11+ process-as-code: structured governance workflow primitives.

See also

  • docs/tprm.md — Third-Party Risk Management module deep dive
  • docs/model-risk.md — Model Risk Management module deep dive
  • docs/threat-model.md — STRIDE threat model with v0.7.10 surface
  • docs/positioning-and-value.md — strategic positioning context including the SR 26-02 GenAI-exclusion regulator-vacuum gap
  • docs/v0.7.10-plan.md — release plan for the current cycle

Evidentia wiki

Clone this wiki locally