Repository navigation
Margining and MPOR
📌 Guide, not policy. docs/methodology/README.md (the decisions on client clearing and MPOR combinations, and the traceability rows for CRE52.50–.53 and CRR Art. 279c, 285) is the project's governing implementation specification. Applicable law and official regulatory texts prevail over the repository and this guide. The engine's conservative choices and coverage limits are distinguished below.
The maturity factor scales each trade's contribution to the PFE to the time over which its exposure can grow: the remaining maturity, up to one year, for an unmargined trade, and the margin period of risk (MPOR) for a margined one. This page gives both factors, every MPOR floor the engine applies, how remargining, disputes and large or illiquid netting sets change the MPOR, and where the engine's choice is a recorded decision.
Status at v1.0.2: version 1.0.2, released on 2026-10-23
(GitHub Release).
New in 1.0.2: the 10-day floor of trade exposures to a CCP and the per-trade
horizon where the CCP retains VM, the role MULTI, settled-to-market trades,
and an INFO line on Checks for every client-clearing and CCP netting set.
M is the trade's remaining maturity in years, floored at 10 business days and
capped at one year (CRE52.48–.49; CRR Art. 279c(1)(a)). In the workbook, M is
the maturity date, or else the end date, or else the option expiry, in years of
DaysPerYear (365) from the reporting date; the floor is MinMaturityBD (10)
over BusinessDaysPerYear (250). These are the default conventions used in
the formulas and tables; 250 is a business-day conversion convention, not
an exchange holiday calendar. The month examples below use M = 0.25, 0.5
and 0.75 exactly; actual input dates need not give those exact year fractions.
Choose M from the contractual obligations, not merely a fallback date. Under CRR Art. 279c(1)(a), M covers all contractual obligations, including optionality; where the underlying is another derivative that can create further obligations, its obligations determine M. M, option expiry T and underlying end date E therefore need not coincide. The workbook's date precedence does not establish that the selected date meets the regulatory requirement.
Settlement and reset. A qualifying contract that settles outstanding
exposure and resets its value to zero uses the next reset date for M
(CRE52.37(5); CRR Art. 279c(2)). A daily VM transfer alone is not such a
settlement. The Basel FAQ on exchange-traded derivatives under CRE52.31–.32
treats daily settled trades as unmargined with M at the 10-business-day
floor; E remains the underlying end date. From 1.0.2 (#360), a qualifying
trade is declared with Settlement type STM and its next reset date in an
unmargined netting set: M in the maturity factor is then the time to that
date, floored at 10 business days, while M as entered, S, E and the option
expiry T keep their meaning, so a settled option can expire after its reset
date. The reset date must be after the reporting date and not after the
maturity as entered. The qualification is the user's; an STM trade in a
margined netting set makes it INVALID. Up to 1.0.1 such a trade was entered
with M equal to the next reset date, and an option expiring after it was
rejected. See clearing coverage
for the input contract and its limitations, and Inputs for the
columns.
| M | 10 business days (0.04 years) or less | 3 months | 6 months | 9 months | 1 year or more |
|---|---|---|---|---|---|
| MF | 0.2 (floor 10/250) | 0.5 | 0.707107 | 0.866025 | 1 |
MPOR in business days (CRE52.52–.53; CRR Art. 279c(1)(b)). Every trade in a
margined netting set takes the same factor, shown on TradeCalc as
MF margined next to MF unmargined, which the cap
still uses. The exception (from 1.0.2) is a CCP netting set whose CCP
retains VM without protecting the collateral: there a trade whose own horizon
exceeds the MPOR uses that horizon, so MF margined can differ between its
trades (below). This assumes the supported structure of one margin agreement
per netting set. The margined factor is not capped at 1 by this formula;
the separate EAD cap must still be applied.
| MPOR (business days) | 5 | 10 | 14 | 20 | 24 | 28 |
|---|---|---|---|---|---|---|
| MF | 0.212132 | 0.3 | 0.354965 | 0.424264 | 0.464758 | 0.501996 |
Both factors run through SACCR_MaturityFactor, also a
worksheet function. The unmargined factor is exercised by
CRE99 Example 3 (T07, a 9-month trade); the margined one by Example 5 (T14).
MPOR is the exposure horizon between the last collateral exchange before default and close-out/replacement. It is distinct from the remargining frequency N. Under CRE52.50, the bank must estimate MPOR for each netting set and use the higher of that estimate and the applicable supervisory floor. The engine derives a minimum from the supplied flags and frequency; it does not estimate liquidation time or assess market liquidity. Enter a higher required estimate through the MPOR override.
The engine works out the MPOR of each margined netting set in four steps
(CORE_Engine.LoadNettingSets):
- Floor F from the client clearing role and the regime (table below).
-
Large or illiquid: if the flag is
Y, F = max(F, 20). - Remargining: MPOR = F + N − 1, with N the remargining period in business days.
-
Disputes: if the flag is
Y, the result is doubled.
An MPOR override, if entered, replaces the result only when it is not below it; a lower override is ignored with a warning on Checks. MPOR is shown on Results for margined netting sets only. The override is the final MPOR in business days, not an increment to the derived value; the engine does not double it again after applying the disputes rule.
| MPOR override input | Treatment |
|---|---|
| Blank | Use the engine-derived value |
| Positive whole number at or above the derived value | Use the override |
| Positive whole number below the derived value | Ignore it, retain the derived value and warn |
| Explicit 0, negative, fractional or unreadable value | Netting set INVALID
|
These input checks also run for unmargined sets, although their maturity
factor does not use MPOR. A blank dispute or large/illiquid flag defaults to
N; that is a software default, not evidence that the regulatory condition
is absent.
The table shows the engine's base floors before frequency, disputes and override. It is not an exhaustive table of legal entitlements or CCP rules.
| Netting set | Client clearing role | CRR |
BCBS |
Locators |
|---|---|---|---|---|
| Bilateral | N |
10 | 10 | CRR Art. 285(2)(b); CRE52.50(1) |
| Clearing member facing its client | CM |
5 | 5 | CRR Art. 279c(1)(b); CRE54.12 |
| Client facing its clearing member | CLIENT |
5 | 10 | CRR Art. 279c(1)(b); CRE54.14–.17, CRE54.8(2) |
| Trade exposure to a CCP (from 1.0.2) | CCP |
10 | 10 | CRR Art. 304(3)(b); CRE54.8(2) |
| Multi-level client structure (from 1.0.2) | MULTI |
— | — | Not calculated: the netting set is INVALID
|
| Large/illiquid flag set on a supported margined netting set |
N, CM, CLIENT or CCP, flag Y
|
20 | 20 | Engine applies one combined flag; exceptions and limitations below |
The floors are the Params values MPORFloorBilateral (10),
MPORFloorCleared (5) and MPORFloorLarge (20); any other value makes the
run WHAT-IF. The 10 days of a CCP netting set are a
constant of the engine, not a Params value.
Every margined CM, CLIENT and CCP netting set gets an INFO line on
Checks (from 1.0.2) naming its role, the floor and the rule applied, and the
20 days of the large or illiquid flag when it raises the floor, for example
Clearing member facing its client: MPOR floor 5 BD (CRE54.12; CRR Art. 279c(1)). An unmargined one gets a line saying that no MPOR floor applies.
Client clearing (#39). CRR Art. 279c(1), last subparagraph, replaces the 10-day minimum with five business days for transactions between a client and a clearing member, for an institution acting on either side. Basel CRE54.12 expressly allows at least five days for the clearing member's exposure to its client.
For a Basel client, CRE54.14–.17 refers to CCP treatment when the prescribed
protection and portability conditions hold, or bilateral treatment otherwise;
CRE54.8(2) specifies ten days for OTC derivatives under CCP treatment.
However, the footnote to CRE54.2 also refers to CRE54.12 when describing
both parties to the clearing-member/client leg of an exchange-traded
derivative under a bilateral agreement. The project therefore records its
10-day BCBS CLIENT floor as a conservative interpretation, rather than
claiming that no alternative reading exists. It produces an INFO line on
Checks and is a documented regime difference.
Eligibility, segregation and portability remain the user's responsibility.
See clearing coverage and decisions
for the rationale and implementation boundaries. A multi-level client
structure is declared with role MULTI (from 1.0.2) and rejected:
INVALID: multi-level client structure, not supported; entered as CM or
CLIENT instead, it cannot be detected. A clearing member's trade exposure to
a CCP has its own role, CCP (below); a CCP
entered as ordinary role N is calculated as bilateral and cannot be
detected. A five-day client floor must not be used as a generic floor for
every centrally cleared trade.
From 1.0.2 (#112),
role CCP is the bank's trade exposure, as clearing member, to a CCP: its own
trades and the client trades it must reimburse on the CCP's default. Its
exposure value is SA-CCR, as for any netting set (CRR Art. 306(3); CRE54.8).
Two NettingSets columns are required for it and blank for every other role:
QCCP (Y/N) in R and CCP retains VM, collateral not protected (Y/N) in S
(Inputs).
| Item | Treatment | Locators |
|---|---|---|
| MPOR floor, margined | 10 business days in both regimes, plus N − 1, doubled with disputes, raised by an override not below it | CRR Art. 304(3)(b); CRE54.8(2) |
| Large or illiquid flag | Still sets 20 days, although the 5,000-trade floor does not apply to trade exposures: a conservative limitation of the one flag | CRR Art. 285(3)(a); CRE54.8(1) |
CCP retains VM, collateral not protected (S = Y) |
Each trade's horizon is the lower of one year and its remaining maturity, at least 10 business days; the trade takes the larger of that horizon and the netting set's MPOR, in its own margined maturity factor. Needs Margined = Y
|
CRR Art. 304(3)(d); CRE54.8(3) |
Unmargined CCP netting set |
No MPOR floor: each trade's unmargined maturity factor | CRE52.48; CRR Art. 279c(1)(a) |
| QCCP status (R) | Your attestation; sets the risk-weight rule stated on Checks, not the exposure value: 2% for a QCCP, the standardised weight of the CCP, to be determined outside K-SACCR, for a non-qualifying one. Not applied | CRR Art. 4(1)(88), 306(1); CRE50.3, CRE54.7, CRE54.41 |
With S = Y, the horizon in business days is
min(BusinessDaysPerYear, M × BusinessDaysPerYear), at least
MinMaturityBD, so
The illustrative case illustrative-ccp-retained-vm gives trades shorter
than 10 business days, between the MPOR and a year, and over a year the
margined factors 0.3, 1.0592 and 1.5, under CRR and BCBS.
The EAD stays in the regime's total on Results; Checks gives each regime with
CCP netting sets an INFO line with their number, how many are VALID, and
their EAD. Default-fund contributions, their own funds requirements and the
cap of CRR Art. 303(2) / CRE54.40 are not calculated
(#400).
| Input | Treatment |
|---|---|
| Blank | N = 1, daily remargining |
| 0 | Raised to 1 with a warning |
| A whole number from 1 to 10,000 | Used as entered |
| Negative, not whole, above 10,000 or unreadable | The netting set is INVALID
|
Basel prints the floor for non-daily remargining as nine business days plus the remargining period (CRE52.50(2)), which is F + N − 1 with F = 10; the CRR prints F + N − 1 (Art. 285(5)). For daily remargining, N = 1 and MPOR = F.
The trigger is more than two qualifying margin-call disputes on the same netting set over the immediately preceding two quarters. The increased minimum applies for the subsequent two quarters. Under CRE52.51(3), compare the dispute duration with the applicable MPOR before this provision's increase; under CRR Art. 285(4), the comparison refers to the applicable period under paragraphs 2 and 3. Do not compare against an already doubled value. For non-centrally cleared derivatives subject to MGN20, CRE52.51 FAQ1 limits the count to variation-margin disputes.
The workbook stores only a Y/N flag: it does not maintain dispute counts,
durations or the quarterly application window. The user must determine when
the flag applies and when it can be removed.
The following illustrates the project's interpretation of the interaction between frequency and disputes; the CRR does not print a single combined formula for that interaction:
| Text | What is doubled | Weekly remargining (N = 5), F = 10 |
|---|---|---|
| Basel, CRE52.51(3) | "the applicable supervisory floor", which for non-daily remargining is 9 + N (CRE52.50(2)): 2 × (F + N − 1) | 28 |
| Project reading of CRR Art. 285(4)–(5) | Double F first, then add N − 1: 2F + N − 1; an interpretation of the combined provisions, not an expressly printed formula | 24 |
| Engine, both regimes | 2 × (F + N − 1) | 28 |
The engine uses 2 × (F + N − 1) in both regimes. For weekly remargining
this gives 28 days, above the 24 days in the alternative reading shown above;
with daily remargining they coincide. This is the project's conservative
implementation choice, not a claim of a definitive regulatory interpretation
of every combination. A higher required MPOR estimate must still be supplied.
The decision (#39) is recorded in the methodology's
MPOR combinations.
The input-validation case netting-set-mpor-disputes-weekly (CRR, N = 5)
expects 28 days.
Under CRR Art. 285(3)(a), exceeding 5,000 trades at any point in a quarter triggers the 20-business-day minimum in the following quarter, subject to the stated exception for trade exposures. CRE52.51(1) specifies more than 5,000 transactions for sets not with a CCP, without the same explicit previous-quarter wording. Do not attribute the CRR timing rule to the Basel paragraph as if it were identically stated there.
Illiquid collateral or a hard-to-replace OTC derivative independently triggers a 20-day floor (CRR Art. 285(3)(b); CRE52.51(2)). Assess liquidity under stressed conditions, including the ability to obtain multiple quotes within two days without moving the market; CRR also requires consideration of concentration and the consequences of a counterparty's sudden exit.
Clearing exceptions. CRR Art. 285(3)(a) excludes trade exposures from its trade-count exception, and Art. 304(3)(c) permits a clearing member to disregard the trade-count floor for eligible client netting sets without illiquid collateral, disputed trades or exotic options. Basel CRE54.8(1) also provides conditional relief from the trade-count floor in its scope; CRE54.14 can extend the CCP treatment to qualifying client exposures. These are not blanket exemptions from illiquidity or dispute requirements.
The workbook cannot distinguish these conditions with its single
large/illiquid flag. If Y, it uses 20 + N − 1 for every supported role in
both regimes, CCP included. CRR Art. 285(3) and (5) expressly support adding the frequency
adjustment; Basel CRE52.51 sets 20 days without expressly adding N − 1.
The additional Basel adjustment and the inability to apply eligible
trade-count relief are conservative implementation limitations, documented
in clearing coverage.
The case netting-set-mpor-large-weekly-bcbs (N = 5) expects 24 days.
The flag is the user's. The workbook sees only today's trades, not the
previous quarter's count or the liquidity of the collateral, so it never sets
the flag. A margined netting set with more than 5,000 economic trades and
the flag N stays VALID with a warning on Checks asking the user to set the
flag if the netting set had more than 5,000 trades in the previous quarter
(case netting-set-over-5000-trades). VALID means the inputs passed the
engine's checks; it does not certify that leaving the flag off is permissible.
Economic trades are counted separately from their risk-factor legs.
| Netting set | F | N | Flags | MPOR | Covered by |
|---|---|---|---|---|---|
| Bilateral, daily | 10 | 1 | — | 10 | Derivation of fixture illustrative-posted-vm-cap
|
| Bilateral, weekly | 10 | 5 | — | 14 | CRE99 Example 5, CRE99.83: T11, published |
| Clearing member, daily, either regime | 5 | 1 | — | 5 |
netting-set-clearing-member-crr, -bcbs; illustrative-clearing-member-listed
|
| Client, daily, CRR | 5 | 1 | — | 5 | netting-set-clearing-client-crr |
| Client, daily, Basel | 10 | 1 | — | 10 | netting-set-clearing-client-bcbs |
| Client, weekly, CRR | 5 | 5 | — | 9 | illustrative-clearing-client-listed |
| Client, weekly, Basel | 10 | 5 | — | 14 | illustrative-clearing-client-listed |
| Client, daily, CRR | 5 | 1 | Disputes | 10 | netting-set-clearing-client-disputes-crr |
| Client, daily, Basel | 10 | 1 | Disputes | 20 | netting-set-clearing-client-disputes-bcbs |
| Bilateral, weekly, CRR | 10 | 5 | Disputes | 28 | netting-set-mpor-disputes-weekly |
| Bilateral, weekly, Basel | 20 | 5 | Large or illiquid | 24 | netting-set-mpor-large-weekly-bcbs |
| Clearing member, flagged large, either regime | max(5, 20) = 20 | 1 | Large or illiquid | 20 |
netting-set-clearing-member-large-crr, -bcbs
|
| CCP, daily, either regime | 10 | 1 | — | 10 |
netting-set-ccp-crr, -bcbs; illustrative-ccp-trade-exposure
|
| CCP, weekly | 10 | 5 | — | 14 | netting-set-ccp-weekly |
| CCP, daily | 10 | 1 | Disputes | 20 | netting-set-ccp-disputes |
| CCP, flagged large | max(10, 20) = 20 | 1 | Large or illiquid | 20 | netting-set-ccp-large |
Every case except T11 is illustrative.
The margined example adopted in the published validation catalogue (unchanged in v1.0.2): the trades of Examples 1 and 3 under a margin agreement with weekly remargining, threshold 0, MTA 5, independent amount 150 and total collateral 200, of which 50 is VM (USD thousands, CRE99.80–.81). CRE99.83 gives MPOR = 9 + 5 = 14 business days, the engine's 10 + 5 − 1. With MF = 1.5 × sqrt(14 / 250) = 0.354965 for every trade, CRE99 prints an aggregate add-on of 1,401, a multiplier of 0.958 and an EAD of 1,879 (T12–T14). The cap does not bind: under CRR the same inputs give the same EAD (T15, illustrative). Details are on Worked Examples. Use unrounded intermediate values to reproduce the calculation; published figures are rounded. CRE99.84 also directly presents the maturity-factor calculation. CRE99.98–.115 contains additional margined RC examples, so Example 5 is not the only published example involving margin agreements.
| Rule | Status |
|---|---|
| MPOR with remargining, F + N − 1 (CRE52.50) | Basel validated by T11; CRR not validated |
| Margined maturity factor (CRE52.52; CRR Art. 279c(1)(b)) | Basel exercised by T14; CRR not validated |
| Unmargined maturity factor (CRE52.48; CRR Art. 279c(1)(a)) | Basel exercised by T07; CRR not validated |
| Client-clearing floors, disputes, large or illiquid (CRE52.51; CRE54; CRR Art. 279c(1), 285(3)–(5)) | Not validated: illustrative TEST_InputValidation cases and the illustrative illustrative-clearing-*-listed cases |
| CCP floor and retained-VM horizon (CRE54.8(2)–(3); CRR Art. 304(3)(b), (d)) | Not validated: no published case; illustrative illustrative-ccp-* cases and netting-set-ccp-* cases, values from tests/derivations/ccp_trade_exposure.py
|
| Settled-to-market remaining maturity (CRE52.37(5); CRR Art. 279c(2)) | Not validated: illustrative illustrative-settled-to-market-* cases, values from tests/derivations/settled_to_market.py
|
The statuses describe checks actually adopted by the v1.0.2 catalogue, not the availability of published reference calculations. In particular, CRE99.84 supplies a margined maturity-factor reference; adding a dedicated expected MF and source locator to a passing test would be needed to promote the project's status. This documentation update changes neither the tests nor their validation classification.
Primary references: Basel CRE52, CRE54, CRE99, and CRR Art. 279c, 285 and 304 in the source register.