Without strong lineage and audit trails, FRTB reporting becomes difficult to defend because firms cannot reliably show how data sets, models, and risk calculations were produced. That creates pressure on capital measurement, transparency, and supervisory trust. In practice, the organisation may be unable to prove that reference data, pricing inputs, and aggregation logic are controlled.
Why FRTB Becomes Hard to Defend Without Lineage
For asset managers, FRTB is not just a calculation problem, it is an evidence problem. If the firm cannot trace where market data came from, how it was transformed, and which models or aggregation rules used it, supervisors can question the entire reporting chain. The result is weaker defensibility, slower challenge resolution, and more manual reconciliation.
Strong lineage turns FRTB from a black-box output into an auditable process. It lets teams answer basic but critical questions: which reference data version was used, whether pricing inputs were overridden, whether a model change altered a capital outcome, and whether the same logic was applied consistently across desks or legal entities. Without that traceability, even a correct number may be difficult to trust.
Asset managers also need to distinguish between technical correctness and supervisory acceptability. A calculation can be internally repeatable and still fail governance expectations if the supporting evidence is fragmented across spreadsheets, local files, or undocumented approvals. That gap is often what makes FRTB programmes fragile: the institution can compute a result but cannot prove the result’s provenance.
Useful supporting material on this control problem is captured in Ultimate Guide to NHIs, Regulatory and Audit Perspectives and Cloud Compliance Pulse 2025, both of which reinforce the need for auditable control evidence and governance visibility.
What Audit Trails Need to Show in Practice
Audit trails are only useful if they let reviewers reconstruct the decision path without relying on tribal knowledge. For FRTB, that means recording who changed inputs, when a model or parameter changed, what validation or approval occurred, and what downstream reports were regenerated as a result. The trail should be detailed enough to support challenge and replay, not just to show that a job ran.
Good auditability is usually strongest when controls cover the full chain: source data ingestion, enrichment, transformation, model execution, aggregation, and reporting output. Each step needs enough metadata to tie the result back to a specific version of data and logic. If any of those links is missing, the firm may be forced into after-the-fact explanations that are hard to defend under supervisory review.
Practitioners often underestimate how much operational discipline this requires. If change management, data stewardship, and model governance sit in separate teams, the evidence can become inconsistent even when each team believes it is controlling its own part correctly. The practical question is whether the organisation can reproduce the same answer, with the same inputs and approvals, weeks later under scrutiny.
For a broader governance view, the Ultimate Guide to NHIs, Key Challenges and Risks is useful for understanding how visibility gaps and unmanaged control paths undermine defensibility, while NHI Lifecycle Management Guide is a good reference for the kind of lifecycle discipline that audit trails depend on.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 and SOC 2 (AICPA) define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| ISO/IEC 27001:2022 | A.8.13 — Information Backup | Preserves recoverable records and evidence supporting regulated reporting processes. |
| A.8.15 — Logging | Requires logs that support reconstruction of data changes, model runs, and report generation. | |
| Recommendation — Retain versioned data and calculation evidence so FRTB outputs can be reconstructed and challenged. Log data lineage events, approvals, and report production steps for audit replay. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Audit Events | Defines which events to capture to reconstruct FRTB data and model decisions. |
| AU-3 — Content of Audit Records | Supports audit records with enough detail to trace FRTB calculations back to source data. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Enables review of lineage gaps and unexplained FRTB calculation changes. | |
| Recommendation — Capture ingestion, transformation, model execution, and output events for supervisory review. Record source versions, overrides, approvals, and output identifiers in each audit trail entry. Review audit trails for missing lineage links before relying on reported capital figures. | ||
| SOC 2 (AICPA) | CC7.2 — Monitoring Activities | Supports monitoring of changes and exceptions in regulated reporting workflows. |
| CC3.2 — Risk Assessment | Connects lineage and audit gaps to reporting integrity and supervisory trust risks. | |
| Recommendation — Monitor FRTB workflow exceptions and unresolved provenance gaps until they are closed. Assess lineage gaps as reporting-control risks that can affect capital defensibility. | ||
Practitioner Guidance
What to verify: Confirm that every material FRTB input, transformation, model run, and output can be traced to a versioned source with an accountable owner. If you cannot replay the calculation from evidence alone, the control design is too weak for regulatory challenge.
What practitioners underestimate: The hardest failure is not usually the math, it is the inability to explain why the math was allowed to use a particular dataset, parameter, or override. That is where lineage, approvals, and audit logs must converge.
Practitioner takeaway: Treat FRTB evidence as part of the control, not as a by-product of the control. If the firm cannot reconstruct the decision chain quickly and consistently, capital numbers remain operational outputs rather than supervisory-grade evidence.
Related resources from NHI Mgmt Group
- What happens when enterprises try to democratise data without clear policy and process controls?
- What happens when teams try to secure AI usage without data lineage and event context?
- What happens when organisations try to secure AI adoption without visibility into data lineage?
- What happens when organisations try to scale AI without strong data access controls?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
