Basel III Endgame Risk-Weighted Assets Engine: Standardised Approach Architecture

Every capital ratio a bank publishes is a fraction, and the denominator is the hard part. Capital is a balance-sheet number that accounting already produces; risk-weighted assets are a derived quantity that depends on thousands of classification decisions, rating look-ups, collateral haircuts and rule versions, each of which must be reproducible years later for a supervisor. When the rulebook changes, as it is doing now across the United States, the United Kingdom and the European Union, the denominator moves even if the bank’s lending does not.

The timing matters. The US agencies re-proposed their Basel III endgame rules in March 2026, the UK Prudential Regulation Authority (PRA) published final Basel 3.1 rules in January 2026 for 1 January 2027, and the EU has applied its Basel III package since 1 January 2025. A calculation engine built for one regime now has to serve several rulebooks at once.

This post lays out a reference architecture for a standardised-approach regulatory capital engine and the data lineage that makes its output defensible. It is a systems analysis, not advice.

What this covers: the RWA concept and capital ratios, what the Basel III endgame changes, how the three major jurisdictions stand, and an engine design from ingestion to reconciliation, with a worked example and Python code.

Non-advisory note: this article describes software architecture for regulatory calculation. It is not legal, regulatory, financial or investment advice. Regulatory text and timelines change, and any production implementation must be validated against the current rules that apply to the institution.

Context and Background

A bank’s regulatory capital requirement is expressed as a ratio. Under the Basel Framework, Common Equity Tier 1 (CET1) must be at least 4.5% of risk-weighted assets, Tier 1 capital at least 6%, and total capital at least 8% (Basel Framework, RBC20). On top sits a 2.5% CET1 capital conservation buffer for all banks, and possibly a countercyclical buffer and surcharges for systemically important institutions. These minima are the same number for a small lender and a global bank; what differs is the denominator, which scales each asset by how risky the rules say it is.

That denominator is the sum of credit risk, market risk and operational risk components. Credit risk RWA is usually the largest. For each exposure, the bank computes an exposure at default, applies a risk weight, and sums the results. A risk weight of 100% means the exposure counts at face value; 20% means it counts at one fifth. Capital is held against the weighted amount, not the nominal one.

Why the denominator became political

Two approaches coexisted for decades. The standardised approach assigns supervisory risk weights from tables. The internal ratings-based (IRB) approach lets approved banks estimate probability of default and loss given default with their own models. Supervisors found that IRB banks reported materially different risk weights for similar portfolios, which undermined comparability. The December 2017 Basel Committee reforms, informally called “Basel III endgame” in the US and “Basel 3.1” or “Basel IV” elsewhere, answered with three moves: a more risk-sensitive standardised approach, constraints on internal models, and an output floor (BCBS, Basel III: Finalising post-crisis reforms).

The output floor changes the engineering problem. Binding RWA becomes the maximum of the bank’s model-based RWA and 72.5% of the RWA computed using only standardised approaches. A bank that used to run the standardised approach as an afterthought now has to run it on every portfolio, every reporting date, in parallel with its models. The standardised engine is no longer a fallback; it is a permanent second calculation whose output can set the capital requirement.

Where this fits in the wider risk stack

An RWA engine sits next to, not inside, the risk engines described elsewhere on this site. Market risk RWA depends on the Fundamental Review of the Trading Book, covered in our post on value-at-risk, expected shortfall and the FRTB risk engine. Balances come from the books of record, which we discuss in ledger database architecture for double-entry systems. And the requirement to explain every number later is a data-architecture problem, treated in bitemporal event sourcing for financial audit trails. The RWA engine is where those three concerns meet a rulebook.

The Basel III Endgame Rulebook an Engine Must Encode

The Basel Committee’s final reforms changed several calculation families at once. An engine design starts by separating what is stable across jurisdictions from what is local.

Standardised approach for credit risk

Basel’s revised standardised approach adds granularity. Corporate exposures in jurisdictions that allow external ratings carry 20% for AAA to AA-, 50% for A+ to A-, 75% for BBB+ to BBB-, 100% for BB+ to BB- and unrated, and 150% below BB-. Unrated corporate SMEs carry 85%, and jurisdictions that do not rely on ratings can apply 65% to investment-grade corporates (Basel Framework, CRE20). Bank exposures use the Standardised Credit Risk Assessment Approach (SCRA): a base weight of 40% for Grade A, 75% for Grade B and 150% for Grade C, with lower weights for short-term exposures.

Real estate is where the revision bites. For residential property where repayment is not materially dependent on the property’s cash flows, the weight depends on the loan-to-value (LTV) ratio: 20% up to 50% LTV, 25% to 60%, 30% to 80%, 40% to 90%, 50% to 100%, and 70% above 100% (Table 11 of the 2017 standard). Where repayment does depend materially on property cash flows, the corresponding weights run from 30% to 105% (Table 12). An engine therefore needs a current-LTV field, a cash-flow-dependency flag, and a clear policy on property revaluation, none of which the old flat 35% weight required.

Off-balance-sheet items use credit conversion factors (CCFs). The 2017 text sets 10% for commitments that are unconditionally cancellable, 40% for other commitments, 50% for note issuance facilities and certain transaction-related contingent items, and 20% for short-term self-liquidating trade letters of credit.

Operational risk and the business indicator

The standardised approach for operational risk replaces the earlier methods with a Business Indicator Component (BIC) built from financial-statement items. The marginal coefficients are 12% for a business indicator up to EUR 1 billion, 15% between 1 and 30 billion, and 18% above 30 billion; a bank with a BI of EUR 35 billion has a BIC of EUR 5.37 billion in the Committee’s own example. An Internal Loss Multiplier (ILM), built from ten years of loss data, scales the BIC for larger banks. This is a financial-statement calculation, so the lineage problem here is different: the inputs are accounting lines, not exposure records.

Market risk and the link to FRTB

Market risk capital moves to the revised framework known as the Fundamental Review of the Trading Book (FRTB), which has its own sensitivities-based standardised method. For the RWA engine it is an input feed: a market risk capital number converted to RWA, with a trading book boundary decision determining which positions flow to it. Implementation dates for FRTB differ and have slipped repeatedly, so the engine must treat market risk as a separately versioned module.

The output floor

The 2017 standard set the floor at 72.5% of standardised RWA, phased in from 50% on a schedule that originally began 1 January 2022 and ended 1 January 2027. The Committee later deferred the start by one year, which I recall as a March 2020 decision but have not re-verified for this post; check the current Basel Framework phase-in table (RBC90) before encoding dates. A transitional cap of 25% of pre-floor RWA on the incremental increase from the floor was also allowed at national discretion.

Where Each Jurisdiction Stands (Verified as of Late October 2026)

Timelines are the part of this topic most likely to be wrong by the time you read it, so each statement below names its source and the engine design later assumes none of these dates is final.

United States

On 19 March 2026 the Federal Reserve, OCC and FDIC issued three proposals and formally rescinded the 2023 proposals, with comments due 18 June 2026 (Freshfields summary). One proposal covers the Basel III endgame for the largest firms, one revises the standardised approach for the wider industry, and one covers the GSIB surcharge. Per law-firm analysis, the endgame re-proposal does not propose an effective date, and the agencies seek comment on timing and transition (Debevoise analysis). I found no final rule or compliance date in my research, so any date for the US should be treated as unknown.

The structure is notable for engineers. The expanded risk-based approach (ERBA) applies mandatorily to Category I and II firms, and Category III and IV firms may opt in. ERBA replaces today’s dual stack, in which a bank calculates under both the standardised and advanced approaches and the binding ratio is the lower one, with a single revised standardised stack. Based on the secondary sources I read, the re-proposal does not carry a Basel-style 72.5% output floor, possibly because Dodd-Frank Section 171 already requires a standardised floor; this inference is not verified against the rule text.

Proposed calibrations in the standardised approach proposal include a corporate risk weight cut from 100% to 95%, a 90% weight for exposures with no specific treatment, and residential mortgage weights from 25% to 75% for non-cash-flow-dependent loans, with 35% to 110% for cash-flow-dependent ones (Arnold & Porter; Debevoise). The agencies estimate RWA falls about 8.6% at covered depository institutions under the standardised proposal. For operational risk, the re-proposal keeps a BIC-based standardised approach but, per Debevoise, eliminates the internal loss multiplier. These are proposals; calibrations may change before any final rule.

United Kingdom

The PRA published Policy Statement PS1/26, “Implementation of Basel 3.1: Final rules,” on 20 January 2026. The rules take effect on 1 January 2027, and the PRA made only minor amendments to its near-final policy (Regulation Tomorrow summary; Bank of England PS1/26). The FRTB internal model approach is delayed one more year, to 1 January 2028, with existing internal model permissions retained in the interim. I did not retrieve the UK output floor transitional percentages and do not state them here.

European Union

The updated Capital Requirements Regulation and Directive (the CRR3 and CRD6 package) began applying on 1 January 2025. For market risk, the Commission adopted a delegated act on 12 June 2025 proposing to postpone the FRTB own-funds requirements to 1 January 2027, after an earlier delay to 1 January 2026, and said banks keep the pre-FRTB rules through 2026 (European Commission Q&A). I did not verify whether yet another postponement has since been proposed; later EU commentary suggests the topic was still moving. The EU output floor transitional schedule is, to my recollection, phased in over several years to 2030, but I did not verify this and flag it as unconfirmed.

What this means for architecture

Three jurisdictions, three rule sets, two with proposals or deferrals still in motion. The practical conclusion is that jurisdictional rules must be data, not code. A rule that says “residential, LTV 60 to 80, not cash-flow dependent, 30%” belongs in a versioned table with an effective date and a jurisdiction tag, and the engine should select the table by reporting entity and reporting date. Hard-coding Basel numbers into functions guarantees a rewrite when the next calibration lands.

Reference Architecture for a Standardised-Approach RWA Engine

The engine is a pipeline with a control plane. Data flows left to right; lineage and rule versioning cut across every stage.

Figure 1: End-to-end architecture of a regulatory capital engine. Dotted lines show lineage events emitted by ingestion, the rules engine and aggregation into a shared lineage store.

Figure 1 shows source systems feeding an ingestion layer with data quality gates, then classification, credit risk mitigation (CRM), a rules engine, RWA calculation for the three risk types, aggregation with the output floor, capital ratios, and regulatory reporting. The lineage store receives events from several stages rather than sitting at the end, which is the design choice that makes the result explainable.

An RWA engine is a deterministic pipeline that turns exposure records into risk-weighted assets by classifying each exposure, applying credit conversion factors and mitigants, selecting a versioned risk weight from a rules table, and aggregating the results. Determinism and traceability matter more than speed, because every output must be reproducible from archived inputs and rule versions.

Stage 1: Exposure data ingestion and quality gates

The engine’s quality ceiling is set by its inputs. Exposure data arrives from loan systems, card platforms, trade finance, treasury and derivatives systems, each with its own identifiers and conventions. A landing zone should take each extract with a batch identifier, a business date, a source-system version and a record count, then run validation before anything is classified.

Useful gates are structural (mandatory fields present, types valid), referential (counterparty identifiers resolve to a master record), and reconciling (extract totals tie to the ledger within tolerance). Failures should be quarantined, not dropped: a quarantined exposure that vanishes from RWA silently understates capital, while a quarantined exposure that triggers a conservative default weight is visible and fixable. Which default is acceptable is a policy decision for the bank and its supervisor; the engine only has to make the choice explicit and logged.

Stage 2: Classification

Classification maps each exposure to a regulatory exposure class: sovereign, public sector entity, bank, corporate, SME corporate, regulatory retail, residential real estate, commercial real estate, equity, defaulted, and so on. This is the most error-prone stage because it joins data from several domains. A loan is a corporate exposure by counterparty type, but real estate by collateral, and the rules say which wins in which case.

Model classification as an ordered decision table, evaluated top to bottom, with every rule carrying an identifier. Figure 2 sketches the first branching levels.

Figure 2: Simplified decision flow for standardised approach credit risk. Real engines have dozens more branches, including defaulted exposures, covered bonds, specialised lending and equity.

The diagram is deliberately simplified. Branches the figure omits, such as defaulted exposures with their own weights, covered bonds, subordinated debt and specialised lending, are where most production defects live. Because an exposure can match several rules, the order of evaluation is itself a regulatory decision and should be documented as such.

Stage 3: Credit risk mitigation

CRM reduces the capital charge when collateral, guarantees or netting agreements protect the bank. The engine must decide per exposure whether a mitigant is eligible, apply haircuts for volatility and currency or maturity mismatch, and compute either a reduced exposure (collateral) or a substituted risk weight (guarantee). Figure 3 shows the flow from gross exposure through CCF, mitigation and risk weighting.

Figure 3: From gross exposure to RWA. The CCF converts off-balance-sheet commitments to credit equivalents before collateral or guarantees are considered.

CRM is a many-to-many problem. One collateral pool can secure several loans, and one loan can have several collateral items. The engine needs an allocation rule (pro rata, priority, or first-come) that is recorded, because the same collateral cannot reduce two exposures twice. In practice this is a join between an exposure table and a collateral table with an allocation column, and errors here produce understated RWA that is hard to spot because each individual number looks plausible.

Stage 4: The rules engine

The rules engine owns the mapping from classified, mitigated exposures to risk weights and CCFs. Two designs are common. In the table-driven design, rules live in versioned reference tables keyed by jurisdiction, exposure class, attributes and effective date; the engine joins exposures to the table. In the expression-driven design, rules are code or a domain-specific language evaluated against each exposure.

Tables are easier for compliance staff to review and diff between rule versions. Expressions handle conditional logic, such as “if LTV above 100 and the loan is a second lien, weight is 100”, more naturally. A hybrid usually wins: tables for the numeric calibration, a small, tested rule layer for the branching.

Whichever design you choose, three properties are non-negotiable. First, each result records the rule identifier and rule-set version that produced it. Second, rule sets are immutable once published; changes create a new version. Third, the engine can recompute any past reporting date using the rule version that was in force then, and also using the current version for what-if comparison.

Stage 5: RWA calculation and aggregation

For standardised credit risk the arithmetic is simple: RWA equals post-mitigation exposure at default times risk weight. The complexity is entirely upstream. Operational risk RWA is derived from the BIC, and Basel expresses the capital requirement as a multiplier of 12.5 to convert to an RWA equivalent. Market risk arrives from the FRTB engine.

Aggregation then sums the three risk types, applies the output floor where relevant, and divides eligible capital by the result. Because the floor requires a standardised RWA figure for every portfolio, the engine should compute standardised RWA for all exposures even when a bank also runs internal models. Aggregation should preserve dimensions (legal entity, business line, portfolio, exposure class) through to the final number, so that a change of one basis point in a ratio can be traced to the portfolios that caused it.

Data Lineage, BCBS 239 and Reconciliation

A regulatory number without provenance is a liability. The Basel Committee’s principles for effective risk data aggregation and risk reporting, known as BCBS 239, set expectations for accuracy, completeness, timeliness and adaptability of risk data. Our companion post on BCBS 239 risk data aggregation architecture and lineage covers the principles in more depth; this section applies them to the RWA pipeline.

What lineage must answer

For any reported RWA figure, an examiner may ask four questions. Which exposures contributed? Where did each exposure’s attributes come from, and when? Which rules and parameters turned them into a weight? And what changed since the last reporting period? Lineage is the metadata that lets you answer without a forensic project.

There are two granularities. Dataset-level lineage records that the corporate RWA table was built from the loan extract plus the ratings feed on a given date. Record-level lineage records, for exposure 8841-C, the extract row, the classification rule that fired, the rating used, the CRM allocation and the final weight. Dataset-level lineage is cheap and insufficient for challenge; record-level lineage is storage-heavy and sufficient. A pragmatic engine stores a compact per-exposure “calculation trace” (rule identifiers, key inputs, intermediate values) alongside the result, and keeps dataset-level lineage in a catalog.

Bitemporal records

Regulatory data has two time axes. Valid time says when a fact was true in the business world, such as the LTV on the valuation date. Transaction time says when the bank learned it. Restatements, late corrections and re-rated counterparties mean the same reporting date can legitimately be recomputed. Storing both axes lets the engine answer “what did we report on 30 June, as known on 15 July” and “what should we have reported, with hindsight.” The mechanics are described in our post on event sourcing and bitemporal data; an append-only calculation store is the natural fit.

Reconciliation as a control

Three reconciliations belong in every run. Balance reconciliation compares the engine’s exposure totals with the general ledger and flags breaks above a tolerance. Completeness reconciliation checks that every in-scope account appears in exactly one exposure record, which catches both drops and duplicates. Result reconciliation compares this period’s RWA with the last by exposure class and attributes the movement to volume, mix, rule change and data correction. The last one is where the engine proves its value to finance and risk teams, because it turns “RWA up 3%” into an explanation.

Figure 4: Run lifecycle. Each hand-off carries a batch identifier and rule version, and the final step freezes and archives inputs and outputs.

Figure 4 shows the lifecycle of a run. The key idea is the freeze at the end: once a figure is signed off for disclosure, its inputs, rule version and outputs are archived immutably, and later corrections create a new run rather than overwriting the old one.

A Worked Example: Computing RWA and the Output Floor

The following example is illustrative only. The portfolio, the amounts, the market risk figure, the capital figure and the “internal model” RWA are invented to show the mechanics; they do not describe any real bank. Risk weights and CCFs are taken from the 2017 Basel standardised tables cited above, which a given jurisdiction may modify.

Credit risk

Suppose a bank, with amounts in EUR billions, holds seven exposure groups:

Exposure	Amount	CCF	EAD	Risk weight	RWA
Corporate, rated A	100	n/a	100	50%	50.0
Corporate, unrated	80	n/a	80	100%	80.0
Corporate SME, unrated	20	n/a	20	85%	17.0
Residential mortgages, LTV 60 to 80	200	n/a	200	30%	60.0
Cancellable commitments, unrated corporate	100	10%	10	100%	10.0
Other committed facilities, unrated corporate	50	40%	20	100%	20.0
Bank exposures, SCRA Grade A	30	n/a	30	40%	12.0
Total credit RWA					249.0

Operational and market risk

Assume a business indicator of EUR 20 billion. That falls in bucket 2, so the BIC is 12% of the first billion plus 15% of the remaining 19 billion: 0.12 + 2.85 = EUR 2.97 billion. If we assume an ILM of 1 for illustration, operational risk capital is EUR 2.97 billion and operational risk RWA is 2.97 times 12.5, or EUR 37.125 billion. Assume market risk RWA of EUR 30 billion supplied by the market risk engine.

Standardised total RWA is 249.0 + 37.125 + 30.0 = EUR 316.125 billion. With CET1 capital of EUR 40 billion (assumed), the standardised CET1 ratio is 12.65%.

The output floor

Now suppose the bank’s internal models, applied to the portfolios where it has permission, produce a lower total of EUR 200 billion (assumed). The floor is 72.5% of 316.125, which is EUR 229.19 billion. Binding RWA is the higher of 200 and 229.19, so the floor binds, and the CET1 ratio is 40 divided by 229.19, or 17.45%. Had the internal-model total been 270, the floor (229.19) would not bind and the ratio would be 14.81%. The point for engineering is that the standardised figure must be correct even when it is not the binding one, because it determines whether the floor applies.

Implementation: A Python Sketch of the Rule Lookup and Floor

The code below shows the core pattern: rules as versioned data, CCF and risk-weight lookup, and an output floor calculation. It uses the illustrative figures above, not production calibrations. It is a teaching sketch with no persistence, error handling or jurisdiction logic.

from dataclasses import dataclass
from typing import Optional

RULESET = "BCBS-2017-illustrative-v1"

# LTV upper bound (inclusive) -> risk weight, residential, not cash-flow dependent
RESI_TABLE = [(0.50, 0.20), (0.60, 0.25), (0.80, 0.30),
              (0.90, 0.40), (1.00, 0.50), (float("inf"), 0.70)]

CORP_RATING = {"AAA-AA": 0.20, "A": 0.50, "BBB": 0.75, "BB": 1.00, "B-": 1.50}
CCF = {"cancellable": 0.10, "commitment": 0.40, "trade_lc": 0.20, "none": 1.00}

@dataclass
class Exposure:
    exp_id: str
    cls: str                    # corporate, sme, residential, bank
    amount: float
    ccf_type: str = "none"
    rating: Optional[str] = None
    ltv: Optional[float] = None
    scra_grade: Optional[str] = None

def risk_weight(e: Exposure):
    """Return (risk weight, rule id) so the trace records why."""
    if e.cls == "corporate":
        if e.rating in CORP_RATING:
            return CORP_RATING[e.rating], "CORP-RATED"
        return 1.00, "CORP-UNRATED"
    if e.cls == "sme":
        return 0.85, "CORP-SME-UNRATED"
    if e.cls == "residential":
        for bound, rw in RESI_TABLE:
            if e.ltv <= bound:
                return rw, f"RESI-LTV<={bound}"
    if e.cls == "bank":
        return {"A": 0.40, "B": 0.75, "C": 1.50}[e.scra_grade], "BANK-SCRA"
    raise ValueError(f"unclassified exposure {e.exp_id}")

def calc(e: Exposure):
    ead = e.amount * CCF[e.ccf_type]
    rw, rule = risk_weight(e)
    return {"id": e.exp_id, "ead": ead, "rw": rw,
            "rwa": ead * rw, "rule": rule, "ruleset": RULESET}

def output_floor(model_rwa, standardised_rwa, floor=0.725):
    return max(model_rwa, floor * standardised_rwa)

book = [
    Exposure("c1", "corporate", 100, rating="A"),
    Exposure("c2", "corporate", 80),
    Exposure("s1", "sme", 20),
    Exposure("m1", "residential", 200, ltv=0.70),
    Exposure("k1", "corporate", 100, ccf_type="cancellable"),
    Exposure("k2", "corporate", 50, ccf_type="commitment"),
    Exposure("b1", "bank", 30, scra_grade="A"),
]
rows = [calc(e) for e in book]
credit = sum(r["rwa"] for r in rows)                 # 249.0
bic = 0.12 * 1 + 0.15 * 19                           # BI = 20, ILM assumed 1
op = bic * 12.5                                      # 37.125
mkt = 30.0                                           # assumed
std = credit + op + mkt                              # 316.125
bound = output_floor(200.0, std)                     # floor binds: 229.19
print(round(std, 3), round(bound, 2), round(40 / bound, 4))

Every result row carries a rule identifier and rule-set label, which is the minimum viable calculation trace. A production system would write rows to an append-only store keyed by run, entity and business date, and load tables from a governed reference-data service rather than module constants.

Performance considerations

The standardised approach is embarrassingly parallel at exposure level: each exposure’s EAD and weight depend only on its own attributes and its allocated mitigants. The expensive parts are joins (exposures to collateral, to ratings, to counterparty master) and the lineage writes. Columnar engines and partitioning by legal entity and business date handle the first; batching trace writes handles the second. I have not benchmarked a specific platform for this post, so I give no throughput figures; size the engine from your own record counts and your reporting deadline, and test with a full production-volume dry run.

Trade-offs, Gotchas, and What Goes Wrong

Rules in code. Teams that hard-code risk weights ship quickly and then spend months on each regulatory change. Because three major jurisdictions are mid-transition, table-driven rules with effective dates pay for themselves almost immediately.

One engine, several rulebooks. Sharing a pipeline across US, UK and EU reporting is attractive, but jurisdictions differ in definitions, not only in numbers. The US re-proposal reportedly conforms residential and retail weights to Basel while using a distinct treatment for some exposure types; the UK and EU have their own discretions. A multi-jurisdiction engine needs a jurisdiction dimension on every rule and an explicit “difference from Basel” register.

Classification drift. When a source system changes a product code, exposures can silently move class and weight. Monitor the distribution of exposures by class run over run, and alert on movements above a threshold before anyone sees RWA.

Stale collateral values. LTV drives real estate weights. If property values are revalued annually and the engine uses the origination value, the RWA is wrong in both directions through a housing cycle. The valuation date must be a first-class field.

Double counting in CRM. Allocating one collateral item to two exposures is the most common mitigation bug and the hardest to see. Add a control that the sum of allocated collateral never exceeds its eligible value.

Floor surprises. Because the floor can bind unevenly across portfolios, an optimisation that lowers modelled RWA in one area may do nothing to the binding figure. Engines should expose the floor headroom so the business can see where internal-model benefits are actually realised.

Over-engineering lineage. Record-level lineage for every intermediate step of every run can produce more metadata than data. Keep traces compact, retain them for the regulatory retention period, and put the detail where examiners actually probe: classification, mitigation and manual overrides.

Manual overrides. Overrides are inevitable (a rating dispute, a data fix before a deadline). Treat each as a first-class record with approver, reason, expiry and a report of all active overrides, not as an edit to the data.

Practical Recommendations

Start with the rule model, not the pipeline. Agree a schema for rules (jurisdiction, effective-from, effective-to, exposure class, attributes, value, source citation) and load the Basel standardised tables as a baseline. Add jurisdictional deviations as overrides to that baseline, so the “difference from Basel” register falls out of the data.

Build the standardised calculation for the whole balance sheet first, even if your bank uses internal models. The floor, and any parallel-run requirement from your supervisor, depends on it, and it provides a clean cross-check on model outputs.

Invest early in reconciliation and run-over-run attribution. The first time the CFO asks why RWA moved, you want volume, mix, rule and data effects separated automatically. Treat data quality as a capital issue: a record that fails validation either blocks the run or takes a documented conservative treatment.

Finally, assume the dates will move. Keep the US as “proposal stage” in your plans, UK as “final rules, effective 1 January 2027,” and EU as “in force with market risk deferred,” and confirm each against the primary sources before each planning cycle.

• Rules as versioned data with effective dates and source citations.
• Standardised RWA computed for every portfolio, every run.
• Record-level calculation trace with rule version and key inputs.
• Immutable freeze of inputs, rules and outputs at sign-off.
• Three reconciliations: balances, completeness, run-over-run.
• Overrides as governed records with approver and expiry.
• Jurisdiction dimension on every rule and an explicit difference register.

Frequently Asked Questions

What are risk-weighted assets?

Risk-weighted assets are a bank’s exposures scaled by regulatory risk weights, plus capital-equivalent amounts for market and operational risk. A loan with a 100% weight counts in full, while one with a 20% weight counts at one fifth. Capital ratios divide eligible capital by this total, so the figure determines how much capital a bank must hold against its activities.

What is the Basel III endgame?

It is the US name for implementing the Basel Committee’s final post-crisis reforms, which revise the standardised approaches for credit and operational risk, constrain internal models, and add an output floor. Elsewhere the same reforms are called Basel 3.1 or Basel IV. In the US, the agencies re-proposed their rules in March 2026, with comments due 18 June 2026; no effective date had been proposed in the sources I reviewed.

What is the output floor and what does 72.5% mean?

The output floor requires a bank’s total RWA to be at least 72.5% of the RWA calculated with only standardised approaches. If internal models produce a lower figure, the floor figure becomes the binding denominator. It limits how much internal models can reduce capital requirements compared with the standardised baseline, and it is phased in over several years.

What are the minimum capital ratios under Basel III?

The Basel Framework sets minimum CET1 of 4.5% of RWA, Tier 1 of 6% and total capital of 8%, plus a 2.5% CET1 conservation buffer for all banks. Additional countercyclical and systemic buffers can apply. National regulators often add requirements, so actual ratios a bank must hold are typically higher than these global minima.

How does the standardised approach differ from the IRB approach?

The standardised approach assigns risk weights from supervisory tables based on exposure class, external ratings, loan-to-value and similar attributes. The IRB approach lets approved banks estimate default probability and loss severity with their own models. Under Basel’s final reforms, IRB use is constrained and the output floor links the two, so both calculations often have to run.

Why does an RWA engine need data lineage?

Because a supervisor, auditor or internal risk committee must be able to trace a reported RWA figure back to source data and the exact rules applied. BCBS 239 sets expectations for accuracy, completeness and adaptability of risk data. Lineage lets you reproduce past numbers, explain movements, and show that overrides and corrections were controlled.

Further Reading

• Value-at-risk, expected shortfall and the FRTB risk engine for the market risk input to RWA.
• Ledger database architecture for double-entry systems for the books of record the engine reconciles against.
• Event sourcing and bitemporal data for financial audit trails for storing recomputable regulatory history.
• BCBS 239 risk data aggregation, lineage and reporting for the principles behind the lineage design.
• Basel Framework, Credit risk standard CRE20 and PRA PS1/26 as primary sources.

By Riju — about