Repository navigation
Regulatory Basis
📌 Guide, not policy. docs/methodology/README.md (regulatory basis, assumptions and scope, support matrix, parameters, traceability) is the project's governing implementation specification. Applicable law and the official regulatory texts prevail over both the repository and this guide. Implementation gaps and conservative choices are identified below.
This page summarises the project's regulatory basis and implementation policy: which regimes K-SACCR calculates, what the first release covers and leaves out, how a run is classified against the regulatory parameter set, what counts as validation, and what remains the user's responsibility.
Status at v1.0.2: version 1.0.2 was released on 2026-10-23
(GitHub Release).
It implements the clearing work specified in the
clearing coverage and accepted decisions:
a clearing member's trade exposures to a CCP, settled-to-market trades, the
rejection of declared multi-level client structures, and an INFO line on
Checks for every client-clearing and CCP netting set. Implemented does not
mean validated: these rules are tested on illustrative values only.
Statements on later milestones were checked against the README roadmap on
main; linked milestones may change.
See #8.
| Regime | Identifier | Role |
|---|---|---|
| EU Capital Requirements Regulation, SA-CCR | CRR |
Baseline. Template default; a netting set or test may explicitly select BCBS
|
| Basel Framework, CRE52 | BCBS |
Also supported; implemented as differences from the baseline |
- The Regime parameter on Params sets the default,
CRRin the template. - The Regime override column on NettingSets sets a netting set to
BCBSorCRR; blank takes the Params default, any other value makes the netting setINVALID. - Every Results row reports its regime, every expected test value names its
regime, and Results has one total per regime,
TOTAL CRRthenTOTAL BCBS, with no total across regimes. - Where the texts agree, the engine has one implementation tagged with both rule IDs. Where they differ, the difference is recorded in the methodology's regime differences before any code depends on it; see Basel vs CRR.
A Basel example that gives the same number under CRR is not thereby a published CRR result: CRE99 Example 5 under CRR (T15) is illustrative.
The settled positions, from the methodology's assumptions and scope:
| Topic | Position | Issue |
|---|---|---|
| Sources |
CRR uses the consolidated CRR of 26.06.2026 (version 021.001), Delegated Regulation (EU) 2021/931 as amended by (EU) 2025/855, and the interpretative EBA Q&A 2023_6962. BCBS uses CRE52 effective 1 January 2023, last updated 5 June 2020; CRE54 supplies the client-clearing and CCP rules, and CRE50 the definition of a QCCP. Articles 4(1)(88)–(91) and 300–311 of the consolidated CRR (CRR-CCP) cover exposures to CCPs. See Regulatory Sources for the registered extracts and their limits |
#33 |
| Scope | Supported parts of full SA-CCR only. Declared unsupported structures are rejected where an input and check exist; unsupported characteristics not represented by the input model cannot reliably be detected | #33 |
| Margined netting sets | In scope, with VM, NICA, threshold, MTA and MPOR as inputs | #33 |
| Day count | Default: S, E, M and T in years of 365 calendar days (DaysPerYear); floors and MPOR converted using 250 business days a year (BusinessDaysPerYear); no holiday calendars. These are implementation conventions, not universal regulatory mandates for every contract |
#33 |
| Currency | Amounts are converted into the reporting currency with the FX table on Params, whose rates the user supplies | #33 |
| Test cases | VBA generated from the JSON test files by a checked tool; cases run through the input sheets | #44 |
| Evidence | v1.0.2 validates rules only with the published values of CRE99; no independent values, which can come only from an external implementation registered as a source; no independent review is required |
#44, #410 |
| Interest-rate aggregation | Basel: formula with offsets or sum of absolute bucket values (IRBucketOffset); CRR: formula with offsets only |
#33 |
| Specific treatments | Climatic conditions 18%; no unrated credit sub-class; one other-risks hedging set per identical primary risk driver; inflation as interest rate (EUR-INFL); optional reductions for sold options and sold protection not applied |
#33 |
| Cap and one-way agreements | Cap with C = NICA in both regimes; VM held on an unmargined set rejected; VM posted on an unmargined set kept in C under Basel, rejected under CRR | #39 |
| Client clearing | Role N, CM or CLIENT; 5-day floor for CM in both regimes and for CLIENT under CRR. A BCBS client retains 10 days as a documented conservative interpretation. From 1.0.2, role MULTI declares a multi-level client structure, which is rejected, and every CM and CLIENT set gets an INFO line with its role, floor and rule |
#39, #359 |
| CCP trade exposures (from 1.0.2) | Role CCP, the clearing member's trade exposure to a CCP, with QCCP status (column R) and retained VM without protected collateral (column S), both required; 10-day MPOR floor in both regimes; with retained VM a per-trade horizon. The EAD stays in the regime's total, with a CCP subtotal on Checks; the risk-weight rule is stated, not applied. Default-fund contributions are not supported |
#112, #400 |
| Settled-to-market trades (from 1.0.2) | Settlement type STM and the next reset date: M is the time to the reset, floored at 10 business days, while S, E and T keep their meaning; rejected in a margined netting set |
#360 |
| MPOR combinations | The engine uses 2 × (F + N − 1) after qualifying disputes; large or illiquid sets take 20 + N − 1, also for CCP sets, where the trade-count floor does not apply (a conservative limitation). Under CRR the dispute treatment is conservative when N > 1: Art. 285(4) doubles F and Art. 285(5) adds N − 1, giving 2F + N − 1. See the qualification below |
#39 |
| Margin-agreement structures | Several agreements in one netting set (MIXED) or one agreement over several (SHARED) are declared and rejected; so is a settled-to-market trade in a margined netting set |
#33, #39, #360 |
What v1.0.2 calculates, in summary. The full support matrix says how each item is entered.
| Area | Supported |
|---|---|
| Method | Supported parts of full SA-CCR under CRR (default) and Basel CRE52, per netting set; exclusions below apply |
| Asset classes | Interest rate (inflation as EUR-INFL and similar), FX, credit, equity, commodity (climatic conditions under CRR); other risks under CRR only |
| Instruments | Linear trades; European, American, Bermudan and Asian options; CDO tranches and nth-to-default; basis and volatility transactions |
| Complex trades | Transactions with several risk drivers and option combinations, entered as legs of one economic trade (#38) |
| Netting sets | Unmargined and margined; VM, NICA, threshold, MTA; MPOR floors, remargining, disputes, large or illiquid sets, client clearing role; the cap |
| Clearing (from 1.0.2) | A clearing member's trade exposures to a CCP (role CCP), with QCCP status and retained VM; the risk-weight rule stated, not applied |
| Settlement (from 1.0.2) | Settled-to-market trades in unmargined netting sets, with their next reset date |
| Credit factors | Ratings AAA–CCC (Basel), credit quality steps CQS1–CQS6 (CRR), quoted IG and SG indices |
| Run control |
REGULATORY or WHAT-IF classification; statuses VALID, INVALID, INCOMPLETE, NO TRADES
|
"Not supported" means the applicable treatment is not implemented. Some cases
have no dedicated input; others are rejected when declared. The engine cannot
infer an unsupported legal or product characteristic that the user enters as
an ordinary supported case. In particular, a CCP entered with role N, a
multi-level client structure entered as CM or CLIENT, or a digital payoff
entered as ordinary option legs may escape that distinction. The
milestones hold the
current schedule.
| Item | Treatment in v1.0.2 | Planned in |
|---|---|---|
| Digital options | No digital instrument; option legs are an ordinary combination (neither the CRR payoff-sized collar nor the Basel cap of the effective notional is applied) | #120, v1.4.0 |
| Simplified SA-CCR (CRR Art. 281) | Cannot be entered | #107, v1.5.0 |
| Original exposure method (CRR Art. 282) | Cannot be entered | #111, v1.6.0 |
| Default-fund contributions to a CCP, their own funds requirements and the cap of CRR Art. 303(2) / CRE54.40 | Cannot be entered. Trade exposures to a CCP are calculated from 1.0.2 (role CCP); a CCP entered as an ordinary counterparty with role N is calculated as bilateral and cannot be detected |
Outside K-SACCR: K-Risk Engines |
| Multi-level client structures (CRE54.14(3); CRR Art. 305(4)) | Declared with role MULTI and rejected; entered as CM or CLIENT, not detected |
Not scheduled |
| Client trades a clearing member need not reimburse on the CCP's default | Exposure value zero; not entered | — |
| Securities financing transactions | Cannot be entered | Outside K-SACCR: K-SFTs |
| CVA | Cannot be entered | Outside K-SACCR: an engine of its own |
| Risk-weighted assets | Cannot be entered; for a CCP netting set the risk-weight rule is stated on Checks, not applied |
Outside K-SACCR: K-Risk Engines |
| Several margin agreements in one netting set; one agreement over several netting sets | Declared MIXED or SHARED; netting set rejected |
Not scheduled |
| Settled-to-market trades in a margined netting set (CRE52.74; CRR Art. 274(4)) | Netting set rejected: an all-STM set is misclassified and a mixed set needs the CRE52.74 treatment, not implemented; a limitation of the engine, not a regulatory prohibition |
Not scheduled |
| Optional reductions for sold options and sold credit protection (CRR Art. 274(5), (7); CRE52.1 FAQ1–2) | Not applied: ordinary treatment is retained, rather than using the optional relief, which gives an EAD not lower than with it (equal where it would not bind). Eligibility for each relief depends on its specific netting, margin and payment conditions | Not scheduled |
| Automated risk-driver mapping (CRR Art. 277(2)–(3)) and automatic decomposition of option combinations (Art. 274(6)) | The user enters legs | Not scheduled |
| Factor of an unlisted multi-name credit position (Art. 280c(5)(b)(ii)) | General case not supported by the listed factor rows: the required notional-weighted constituent factor need not equal any CQS or quoted-index factor. Do not substitute a CQS or quoted index; the multi-name correlation must also be retained | Not scheduled |
The unlisted multi-name limitation is substantive. With equal constituent
notionals and factors of 0.38% and 0.54%, the required weighted factor is
0.46%, which is absent from the CQS rows. A single-name row also carries a
50% correlation instead of the multi-name 80% (CRR Art. 280c(3), (5)).
Changing a factor-table row makes a run WHAT-IF; it does not establish that
the full required multi-name treatment has been implemented. The corresponding
mapping shortcut in the repository methodology needs the same correction.
For clearing, read the coverage inventory alongside this release summary. Its accepted decisions retain the conservative BCBS client floor of 10 business days: CRE54.12 expressly grants five days to the clearing member, while CRE54.2 and its footnote also address both parties to the exchange-traded member–client leg under a bilateral agreement. The project records its reading of that cross-reference as a conservative choice, not as an unqualified five-day prohibition for the client.
From 1.0.2, role CCP calculates a clearing member's trade exposure to a CCP
with SA-CCR, using the QCCP and retained-VM declarations; the protection of
posted collateral stays the user's (bankruptcy-remote collateral is left out
of NICA). Multi-level structures are rejected when declared, and default-fund
requirements are not supported (#400). Risk weights, RWA and default-fund
capital are distinct from SA-CCR EAD: Checks states the CCP risk-weight rule
but applies none.
The combined large-or-illiquid flag retains the 20-day floor even where
clearing-specific relief might be available; this is an accepted conservative
limitation pending separate inputs, kept in v1.0.2 also for CCP netting
sets, to which the trade-count floor does not apply. For disputes, doubling F + N − 1 follows
the project's reading of CRE52.50–.51, but exceeds the CRR minimum by N − 1
business days when remargining is not daily. These choices are documented
implementation policies, not additional numerical validation.
Every run is compared with the built-in regulatory parameter set
CRE52-CRR-2026-10-09 (CORE_Config.REF_SET_ID), whose values were checked
against the CRR, CRR-RTS Article 5 and the CRE52.72 table on 2026-10-09
(#41).
| Compared | Regulatory value |
|---|---|
Alpha |
1.4 |
MultiplierFloor |
0.05 |
BusinessDaysPerYear |
250 |
MinMaturityBD, SDFloorBD
|
10 business days each |
MPORFloorBilateral, MPORFloorCleared, MPORFloorLarge
|
10, 5, 20 business days |
BasisFactor, VolatilityFactor
|
0.5, 5 |
IRCorrBucket12, IRCorrBucket23, IRCorrBucket13
|
0.7, 0.7, 0.3 |
LambdaThresholdIR, LambdaThresholdCO
|
0.001 (0.10%), 0.1 |
| Every row of the supervisory-factor table | The 26 Basel and CRR rows, with factor, correlation, volatility, commodity hedging set and regimes; a row missing, changed or added counts |
| Each netting set's alpha override | 1.4 |
When everything equals the set, the run is REGULATORY: the run summary on
Results C4 and the message box name the set, and the silent result line gives
run_class=REGULATORY. Any difference makes it WHAT-IF, and each
difference is a warning beginning "What-if:" on Checks.
| Parameter | Why it is not compared | What still applies |
|---|---|---|
DaysPerYear |
A day-count convention, any value from 360 to 366. CRE99 Example 3 needs 360 to enter its printed 9 months as exactly 0.75 years | The default is 365 (day-count convention) |
IRBucketOffset |
The bank's option under CRE52.57(5) |
FALSE is valid only under Basel: a CRR netting set with interest-rate trades is then INVALID and its EAD withheld |
The reporting currency's FX rate must be 1, or the run stops; it is a condition of the run, not a what-if.
REGULATORY says the calculation used the regulatory calibration. It does not
certify the portfolio, validate the inputs, make a withheld EAD available,
decide eligibility or legal enforceability, or amount to supervisory approval.
A WHAT-IF run was not calculated with the regulatory calibration; Checks
lists each difference, so the result can be read as a sensitivity.
Release 1.0.2, like 1.0.0 and 1.0.1, validates rules only with values
printed in a registered source, and the only such values are the Basel worked
examples of CRE99, tests T01–T14. There are no independent values: from
1.0.2 they can come only from an external implementation registered as a
source, and no independent review is required (the project has no
separate reviewer). Because the published examples are Basel examples, implemented
CRR rules are not numerically validated under this evidence policy in
v1.0.2. The client-clearing, CCP and settled-to-market rules are implemented
and tested on illustrative values in both regimes, from the derivations in
tests/derivations/. Excluded rules remain not
implemented; the statement does not claim complete CRR coverage. A cross-check
against a second source is planned
(#100).
The traceability table uses four statuses: validated (a published output of the rule passes in that regime), exercised (no published output names the rule, but a published value that passes depends on it), not validated (implemented; any cases are illustrative) and not implemented.
| Status (Basel) | Rules |
|---|---|
| Validated | EAD and alpha (CRE52.1); unmargined RC (CRE52.10, T08); multiplier (CRE52.23, T05, T13); aggregate add-on (CRE52.25, T09, T12); supervisory duration and adjusted notional (CRE52.34, T01); option delta (CRE52.40, T02); MPOR with remargining (CRE52.50, T11); interest-rate formula with offsets (CRE52.57, T03) |
| Exercised | Margined RC (CRE52.18); PFE (CRE52.20); unmargined and margined maturity factor (CRE52.48–.49, .52); credit (CRE52.60–.64); commodity (CRE52.69–.70); the CRE52.72 factors used by the examples |
| Not validated | The cap (no published example makes it bind); sum of absolute bucket values; CDO delta; basis and volatility transactions; FX; equity; MPOR exceptions (disputes, large or illiquid) and the client-clearing floors; the CCP floor and retained-VM horizon (CRE54.8); the remaining maturity of settled-to-market trades (CRE52.37) |
| CRR | Implemented rules not validated, including the lambda shift, climatic conditions and other risks; exclusions remain not implemented |
Illustrative cases never count toward validation. Engine behaviour that is not a regulatory figure, such as a status, is tested too, but validates no rule. The suites and their counts are on Test Catalogue and Validation Approach.
K-SACCR applies the rules to the inputs it is given. These decisions and data stay with the user:
| Responsibility | Where it matters | Reference |
|---|---|---|
| Verify recognition and legal enforceability of netting; absent recognised netting, treat each transaction as its own netting set | One NettingSets row per legally recognised set, or per transaction; the workbook does not verify the legal opinions or recognition conditions | CRR Art. 272(4), 295–298; CRE52.7 |
| Enter collateral after applicable haircuts and currency-mismatch adjustments, and only eligible collateral; exclude posted collateral from NICA when held in a segregated, bankruptcy-remote account. Segregation alone is insufficient | VM and NICA columns | CRE52.11, .17; CRR Art. 276 |
| Enter a one-way CRR agreement as margined, with its threshold | Margined = Y |
CRR Art. 272(7a), 275(2) |
| Declare structures the engine does not model |
MIXED or SHARED
|
CRR Art. 274(4), 275(3); CRE52.74–.75 |
| Set the large-or-illiquid and disputes flags from the history the workbook cannot see (trade count in the previous quarter, disputes in the previous two quarters) | NettingSets flags; a warning above 5,000 trades with the flag N | CRE52.51; CRR Art. 285(3)–(4) |
| Check the clearing arrangement, the bank's role, and the applicable segregation, insolvency-protection and portability conditions |
CM or CLIENT changes the margined MPOR floor; it does not establish eligibility for CCP risk-weight treatment, which is outside scope |
CRE54.12–.17; CRR Art. 279c(1), 305(2)–(3) |
| Declare a trade exposure to a CCP, its QCCP status and whether the CCP retains VM without protecting the collateral; leave out client trades the member need not reimburse | Role CCP, NettingSets columns R and S; the status sets only the risk-weight rule stated on Checks |
CRR-CCP Art. 4(1)(88), 304(3), 306(1); CRE50.3; CRE54.7, .8, .41 |
| Map each transaction to its risk categories, primary risk driver and direction | One leg per risk category, same Economic trade ID | CRR Art. 277; CRR-RTS Art. 1–4, 6 (not checked by K-SACCR) |
| Choose the FX notional leg | The foreign leg, or the larger leg in the reporting currency when both are foreign | CRE52.35; CRR Art. 279b(1)(b) |
| Map unrated single-name credit correctly; distinguish unlisted multi-name positions | Under CRR: CQS3, CQS5 where Art. 128 applies, or the step mapped from an internal rating as applicable. These are single-name treatments; they do not replace the constituent-weighted factor and multi-name correlation for an unlisted basket |
CRR Art. 280c(3), (5)(a), (5)(b)(ii) |
| Derive the prescribed notional and dates for amortising, leveraged, multi-exchange or resetting trades | Apply the support matrix: time-weighted notional, leverage adjustment or remaining exchanges where required; declare a qualifying settlement-and-reset contract as STM with its next reset date, keeping its contractual M, E and T |
CRE52.37; CRR Art. 279b, 279c(2) |
| Enter a lambda for Basel options on negative or near-zero rates or prices | Lambda shift column (Basel); computed under CRR | CRE52.40 FAQ |
| Supply FX rates; keep the reporting currency's rate at 1 | FX table on Params | Methodology: currency |
| Keep real portfolio data out of the repository | Fixtures and examples | tests/README.md |
Settlement must also be distinguished from collateral. From 1.0.2
(#360), a
qualifying settled-to-market contract is declared with Settlement type STM
and its next reset date in an unmargined netting set: M in the maturity factor
is the time to the reset (subject to the 10-business-day floor), while the
contractual M, E and the option expiry T keep their roles, so a settled option
may expire after its reset. A collateralised-to-market contract remains
margined and uses MPOR; daily variation margin alone is not STM. The engine
checks the declaration and the dates, not the contract: whether it qualifies
is the user's. Up to 1.0.1 the next reset had to be entered as M, and an
option expiring after it was rejected.