Basel III and Basel IV: Risk and Capital Framework Architecture in Sparx EA

The short version: Basel III and Basel IV are usually read as capital rules — minimum capital ratios, leverage ratios, liquidity coverage. They are also architecture requirements. The Basel Committee’s BCBS 239 principles set out exactly how a bank must aggregate, govern, and report risk data, and supervisors keep finding banks that cannot meet them. Sparx EA is where that risk data architecture lives: documented data lineage, a canonical risk data model, and an Internal Ratings-Based (IRB) model governance framework, all in one governed repository that a supervisor can actually inspect.

Most teams discover the gap the hard way — at the next supervisory review, when a regulator asks where a number in the capital report came from and the honest answer is a chain of spreadsheets nobody fully owns. The work below is what closes that gap before it becomes a finding.

Basel III/IV: the architectural requirements

Capital adequacy is an architecture problem

Basel III — phased in from 2010 after the Global Financial Crisis — and its finalized extension (commonly called Basel IV, or the Basel III Final Rule, with implementation phased across jurisdictions toward the end of the decade) set capital adequacy requirements for banks. The rules require banks to hold enough capital to absorb losses across three risk categories:

Credit risk — the risk of loss from borrower default. Banks calculate credit risk capital using either the Standardized Approach (external ratings and supervisor-set risk weights) or the Internal Ratings-Based (IRB) Approach (internal models for probability of default, loss given default, and exposure at default). IRB requires regulators to approve the bank’s internal models and the data systems behind them.

Market risk — the risk of loss from changes in market prices (interest rates, equities, FX, commodities). The Fundamental Review of the Trading Book (FRTB), a central Basel IV component, substantially revises market risk capital and introduces the Internal Models Approach (IMA) for qualifying trading desks — again requiring regulator approval of internal models and data systems.

Operational risk — the risk of loss from failed processes, people, systems, or external events. Basel IV replaces the advanced operational risk approaches with the Standardized Measurement Approach (SMA), which is formula-based but depends on accurate historical loss-data aggregation.

For all three, the architecture question is identical: how is the underlying data collected, aggregated, and reported? Regulators repeatedly find that banks cannot show authoritative, traceable lineage from source systems to capital calculations. That is a BCBS 239 failure.

BCBS 239: the architecture mandate

BCBS 239 — published by the Basel Committee in 2013 and cited in supervisory reviews ever since — sets out 11 principles for risk data aggregation and reporting. The ones that land most directly on the enterprise architecture function are summarized below.

Principle	What it requires	What the architecture has to prove
2 — Data architecture & IT infrastructure	Design and maintain architecture that fully supports risk data aggregation.	End-to-end traceability; documented integration between source systems and risk engines; the ability to produce accurate reports fast.
3 — Accuracy & integrity	Risk data must be accurate and reliable; manual adjustments documented and governed.	Automated and manual data flows are distinguished, and every manual adjustment is auditable.
4 — Completeness	Capture and aggregate all material risk data.	No risk positions excluded — a complete mapping of position-taking systems to the aggregation layer.
5 — Timeliness	Aggregation completed within defined timeframes (intraday for the most material exposures of significant firms).	Real-time or near-real-time flows exist for critical risk data elements.
6 — Adaptability	Generate aggregated risk data for ad hoc requests during stress events.	A flexible, governed architecture — not bespoke scripts assembled under pressure.
7 — Accuracy of risk reports	Reports must be accurate, clear, and complete.	Reports are produced from governed data with documented provenance.

Supervisors in the UK (PRA), the EU (ECB), the US (Federal Reserve), and elsewhere have repeatedly found that significant banks cannot demonstrate compliance — specifically because their risk data architecture is undocumented, weakly governed, and dependent on manual processes that cannot satisfy principles 3 through 6.

---

BCBS 239 in Sparx EA

Data lineage documentation

The core of the BCBS 239 architecture in Sparx EA is the data lineage model: a record of how risk data flows from source systems, through transformation stages, to regulatory capital reports and risk reporting outputs. This is the heart of any serious data architecture for risk.

In Sparx EA, lineage is modeled at the information layer using ArchiMate Data Objects. Each Data Object is a distinct entity in the risk data chain:

Source Data Objects — raw risk data as captured by position-taking or transactional systems. Examples: Loan Record (loan origination system), Trading Position (trading system), Counterparty Exposure (CRM or credit system), Operational Loss Event (loss-event capture system).

Transformed Data Objects — risk data after extraction, transformation, and loading into the aggregation layer. Examples: Normalized Credit Exposure, Aggregated Market Position, Consolidated Operational Loss.

Aggregated Risk Data Objects — the canonical risk data elements produced by the aggregation layer and consumed by models and reporting. Examples: Credit Risk-Weighted Asset, Expected Loss, Value at Risk, Net Open Position.

Report Data Objects — the metrics that appear in regulatory capital reports, stress-test submissions, and management risk reports. Examples: CET1 Ratio, Tier 1 Capital Ratio, Total Capital Ratio, LCR, NSFR.

Each Data Object carries a set of BCBS 239 tagged values:

• Source System — the application that produces or owns the element.
• Data Owner — the business function or person accountable for it.
• Lineage Reference — a pointer to the upstream Data Object it derives from.
• Transformation Type — automated (ETL, API), semi-automated (automated with a manual review gate), or manual (analyst-produced).
• Aggregation Method — the business rule used (sum, weighted average, maximum, and so on).
• Latency — the time lag between the source data and this derived element.
• Reconciliation Control — whether a documented control validates the element against its source.

ArchiMate Association relationships (labeled «Derives» or «Transforms») connect Data Objects along the chain — Source to Transformed to Aggregated to Report. That chain is the BCBS 239 documentation: it shows that every number in the regulatory capital report traces back to a source system, through documented transformations, with known owners and quality controls.

Risk data aggregation architecture

The aggregation layer — the systems that ingest source risk data and produce aggregated metrics — is modeled in the ArchiMate application layer. Application Components represent:

• Position-taking systems — trading, loan origination, credit, and treasury management systems. The sources of raw risk data.
• Data integration layer — the ETL platform or integration middleware that moves risk data from position-taking systems into the risk data warehouse or aggregation engine (for example Informatica PowerCenter, IBM DataStage, Denodo, or cloud-native pipelines on Azure Data Factory or AWS Glue).
• Risk data repository — the canonical risk data store: a warehouse, a data lake, or a purpose-built aggregation platform (for example Axiom, Wolters Kluwer OneSumX, or Moody’s risk infrastructure).
• Risk models — the computational models that consume aggregated data to produce metrics (IRB credit models, VaR market-risk models, SA-CCR counterparty calculations).
• Risk reporting platform — the systems that produce regulatory and management reports from aggregated metrics (for example Axiom RA, Oracle Financial Services Regulatory Reporting, MSCI RiskManager, or bespoke infrastructure).

Application Interface relationships carry the data-flow metadata: the specific Data Objects exchanged, the integration standard, the scheduled frequency, and the latency.

The application layer (systems and their connections) plus the information layer (the Data Objects flowing through them) together form the complete BCBS 239 documentation — systems and data in a single governed repository.

Canonical risk data model

BCBS 239 Principle 4 (Completeness) requires that all material risk positions are captured. The architecture therefore needs a canonical definition of each risk data element — agreed across the bank, not defined differently by each model or report.

In Sparx EA, the canonical risk data model is documented as a class diagram inside the information package. Entities represent canonical concepts: Counterparty, Facility, Exposure, Position, Contract, Loss Event. Attributes represent the required fields. Relationships represent the semantics (a Facility relates to one or more Counterparties; an Exposure is calculated from one or more Positions; a Loss Event maps to an Operational Risk Event Type).

This model is the governance artifact that settles disputes between risk, finance, and IT about what a data element means and how it should be calculated. When the credit risk team defines counterparty exposure differently from the market risk team, the canonical model is the reference for resolution.

---

IRB model governance architecture

The model risk governance challenge

Banks using the IRB approach for credit risk capital (or the IMA for market risk) must obtain regulatory approval for their internal models. Approval is not a one-time event. Models must be validated at least annually, material changes notified or re-approved, performance monitored, and limitations documented and disclosed.

In practice, a large bank may have dozens of approved IRB models — one per portfolio segment (mortgages, SME lending, large corporate, specialized lending) — and a complex validation process. The model inventory, the full list of approved models with owners, validation status, and change history, too often lives in a spreadsheet. That makes governance workflows hard to enforce and impossible to query automatically for regulatory reporting.

IRB model architecture in Sparx EA

In Sparx EA, the IRB model inventory is built as a requirements package, with each model at the top level and its governance attributes held as tagged values. Each approved IRB model is a Requirement element using the «Risk-Model» stereotype from the governance profile, with:

«Risk-Model» tagged values:

• ModelType — Credit Risk (IRB PD / LGD / EAD) | Market Risk (VaR / ES / FRTB IMA) | Operational Risk | IRRBB | Liquidity.
• ModelOwner — the business function accountable for the model (First Line of Defence).
• ModelDeveloper — the team that built and maintains it (quantitative analytics, risk technology).
• ValidationStatus — Approved | Under Validation | Materially Changed (pending approval) | Deprecated.
• ApprovalDate — the date of the most recent regulatory or internal approval.
• NextValidationDue — when the next scheduled validation falls due.
• MaterialChangeTrigger — the conditions that trigger a material change notification (parameter update threshold | methodology change | portfolio scope change | performance deterioration).
• PortfolioScope — the segments the model covers (for example Retail Mortgages, SME Unsecured).
• RegulatorApproved — boolean: whether the model has formal regulatory approval (for IRB/IMA approaches).

Each IRB model element is linked, through trace relationships, to:

• The Data Objects it consumes (its input dependencies in the BCBS 239 lineage chain).
• The Data Objects it produces (its output metrics).
• The Application Component that hosts it (the risk calculation engine).
• The regulatory requirements it satisfies (Requirement elements for the relevant Basel articles).

Model validation framework architecture

The validation framework — the governance process for validating models — is modeled as a workflow in Sparx EA. Its stages are process elements with decision gates standing in for governance checkpoints:

1. Model change identified (trigger: scheduled revalidation, performance alert, or proposed methodology change).
2. Pre-validation scope assessment — is the change material (regulatory notification required) or non-material (internal validation only)?
3. Independent model validation — conducted by the Second Line validation function.
4. Validation findings remediation — model developer response to the findings.
5. Validation sign-off — model validation committee approval.
6. Regulatory notification (if material) — submission to the competent authority.
7. Model inventory update — refreshing the ValidationStatus and ApprovalDate tagged values in Sparx EA.

This workflow is the process documentation BCBS 239 Principle 3 calls for — evidence that model changes are governed, not ad hoc.

---

MDG design: risk architecture stereotype profile

An MDG Technology profile makes the risk vocabulary enforceable and queryable. The core stereotypes:

«BCBS239-DataElement» — applied to ArchiMate Data Objects in the risk data lineage. Tagged values: SourceSystem, DataOwner, LineageReference, TransformationType (Automated | Semi-automated | Manual), AggregationMethod, Latency_hours, ReconciliationControl (boolean), DataQualityScore (0–100, updated from monitoring tools).

«Risk-Model» — applied to Requirement elements representing IRB, IMA, or other internal risk models. Tagged values: ModelType, ModelOwner, ModelDeveloper, ValidationStatus, ApprovalDate, NextValidationDue, MaterialChangeTrigger, PortfolioScope, RegulatorApproved.

«Risk-Report» — applied to ArchiMate Data Objects representing regulatory report outputs. Tagged values: RegulatoryFramework (Basel III | Basel IV | DORA | EMIR | other), SubmissionFrequency, SubmittingEntity, CompetentAuthority, LastSubmissionDate.

---

Turning the model into live risk dashboards

Once the risk architecture is tagged and governed in Sparx EA, the repository becomes a queryable source for the risk data quality and model governance views that BCBS 239 auditors look for. Connected to a BI tool such as Power BI, the same model drives:

Risk data lineage dashboard — a visual of the lineage chain, from source systems through transformations to regulatory reports, with Data Quality Score and Reconciliation Control flags on each element. Red flags (missing controls, low quality scores, manual steps on critical elements) surface immediately rather than at the next supervisory review.

Model inventory dashboard — a complete view of the IRB inventory: model type, owner, validation status, approval date, and next validation due. Overdue validations, pending material-change notifications, and models nearing their next window are all highlighted.

BCBS 239 compliance tracker — a heat map of compliance across the 11 principles, assessed against tagged-value completeness on Data Objects (Principles 2–6) and model governance workflow coverage (Principles 7–11).

Capital calculation traceability — for each capital metric (CET1 Ratio, Total Capital Ratio), the lineage chain back to source Data Objects, so an auditor can trace any capital number to its sources in a single query.

---

Frequently asked questions

Q1: What is BCBS 239 and which banks does it apply to?

BCBS 239 (officially “Principles for Effective Risk Data Aggregation and Risk Reporting,” published by the Basel Committee in January 2013) originally applied to Global Systemically Important Banks (G-SIBs), with a compliance deadline of January 2016. National regulators have since extended the principles to Domestically Systemically Important Banks (D-SIBs) and, in many jurisdictions, to a wider set of significant banks through supervisory expectations. Regulators including the ECB (under TRIM, the Targeted Review of Internal Models), the PRA, and the Federal Reserve have cited BCBS 239 in findings against banks that cannot demonstrate adequate risk data architecture. In practice, any bank subject to the Supervisory Review and Evaluation Process (SREP) under CRD V should treat BCBS 239 as applicable.

Q2: What is the difference between Basel III and Basel IV?

“Basel IV” is a market term (not used by the Basel Committee itself) for the finalization of the Basel III framework published in December 2017, with implementation phased across jurisdictions toward the end of the decade. The key Basel IV changes from an architecture perspective are: the Output Floor (IRB-calculated capital requirements cannot fall below 72.5% of the Standardized Approach result, raising the importance of Standardized Approach data); the Fundamental Review of the Trading Book (FRTB), which substantially revises market risk capital and the IMA framework; revised Credit Valuation Adjustment (CVA) requirements; and the replacement of advanced operational risk approaches with the Standardized Measurement Approach. Each change has implications for which data must be aggregated, at what granularity, and to what timeliness standard.

Q3: How does Sparx EA handle the complexity of a large bank’s risk data architecture?

Large banks may have hundreds of source systems, dozens of transformation stages, and scores of regulatory reports — producing a lineage model with thousands of elements. Sparx EA handles this through package hierarchy, diagram management, and MDG-governed tagged values. The lineage model is broken into packages by risk type (Credit, Market, Operational, Liquidity) and by stage (Source, Integration, Aggregation, Reporting). Diagrams within each package show specific lineage chains at the right level of detail for different audiences — technical data architects, risk owners, regulators. Repository queries aggregate across the full package structure, so the completeness view shows overall BCBS 239 coverage without forcing any single diagram to carry the full complexity.

Q4: What does the IRB approval process require architecturally?

Regulatory approval for IRB models — under CRR Article 143 (EU) or equivalent national regulations — requires a comprehensive application package: the model’s theoretical basis (methodology documentation), the data used to develop and calibrate it (data quality evidence, which maps to BCBS 239 lineage), back-testing results against observed defaults, internal validation results, and the governance framework under which the model is maintained. The data quality evidence and governance framework are where Sparx EA adds direct value — the BCBS 239 lineage model and the Risk-Model tagged-value set provide the structured documentation regulatory applications require, replacing narratives assembled by hand from scattered sources.

Q5: How should banks document the Output Floor impact on their risk architecture?

The Basel IV Output Floor requires that IRB-calculated risk-weighted assets cannot fall below 72.5% of the Standardized Approach result. This creates a new data architecture requirement: banks must maintain both an IRB calculation path and a Standardized Approach path in parallel, then compare them to find the binding constraint. In Sparx EA, this is modeled as two parallel lineage chains (IRB and SA floor) converging at a floor-comparison Data Object that feeds the regulatory report. The floor calculation adds new source-data requirements — for asset classes where the SA uses supervisory risk weights rather than internal estimates, the architecture must ensure that SA input data is as well-governed as the IRB data.

Q6: How does Sparx EA integrate with specialist risk technology platforms?

Specialist risk platforms — Axiom, Wolters Kluwer OneSumX, Moody’s Analytics, MSCI RiskManager, AxiomSL — are modeled as Application Components in Sparx EA, with Application Interfaces documenting their inputs and outputs. Sparx EA does not replace these systems; it governs the architecture above them — what data they consume, what they produce, and how they connect to the rest of the risk data chain. When a bank upgrades or replaces a platform, the Sparx EA model is the reference for impact assessment: which upstream systems feed the outgoing platform, which downstream reports consume its outputs, and what has to change in the integration layer.

Q7: Can Sparx EA support stress testing architecture documentation?

Yes. Regulatory stress testing (ECB stress tests, Bank of England exercises, ICAAP/ILAAP internal programs) requires demonstrating that the bank can rapidly aggregate and report stress scenarios across the full risk data architecture. In Sparx EA, stress testing is modeled as a variant view of the risk data architecture — showing the additional data flows and calculation sequences triggered during a stress scenario, and the timeline (which must sit inside regulatory reporting windows). BCBS 239 Principle 6 (Adaptability) is specifically about stress-scenario readiness, and the Sparx EA model demonstrates that readiness in a form supervisors can review.

Q8: What does an engagement on Basel and BCBS 239 architecture look like?

A practical engagement starts with an assessment — a risk data architecture inventory, a BCBS 239 gap assessment (which elements lack documented lineage, which transformation steps are undocumented), and an IRB model inventory. The build that follows develops the full BCBS 239 lineage model in Sparx EA and connects it to Power BI for ongoing risk data quality monitoring. Together, the assessment and the build deliver the BCBS 239 documentation and live monitoring capability supervisors increasingly expect to see. Paralysis to a Plan is the usual starting point.

---

Where this leaves your risk architecture

BCBS 239 readiness is not a reporting exercise — it is a governance capability, and a governed architecture repository is what makes it durable. Sparx EA holds the data lineage, the canonical risk model, and the IRB governance framework in one place a supervisor can inspect. For banks running this play, Paralysis to a Plan assesses current-state risk data architecture against the BCBS 239 principles, and the build that follows stands up the full lineage model and connects it to the BI tools your risk team already uses. See also how this fits a broader data architecture practice.