Collateral Management Architecture for Derivatives: A 2026 Reference Design

Most engineers who join a margin team assume the hard part is the maths. It isn’t. A competent quant can implement ISDA SIMM aggregation from the published methodology document in a few weeks, and the arithmetic is deterministic. The part that consumes years is agreeing with a counterparty on what the portfolio is — which trades are in scope, which agreement they hang off, which netting set they belong to, and whose reference data is stale. A collateral management architecture is best understood as a distributed-consensus problem wearing a risk-management costume: two firms with independent books must converge on a single number every day, by a hard cut-off, with money moving on the outcome.

This post is a systems and architecture analysis only. Nothing here is investment, trading, or legal advice.

What this covers: the canonical data model, end-of-day and intraday calculation pipelines, CRIF sensitivity exchange, dispute and reconciliation workflow, the call lifecycle state machine, collateral optimisation as a constrained-allocation problem, settlement and triparty integration, and the operational failure modes that actually cause losses.

Context and Background

Two regulatory waves created the system we build today. The first was the post-2008 clearing mandate, which pushed standardised derivatives into central counterparties (CCPs) and made CCP margin methodology a first-class integration surface. The second was the BCBS-IOSCO framework for margin requirements on non-centrally cleared derivatives, published by the Basel Committee and IOSCO and implemented across jurisdictions as the Uncleared Margin Rules (UMR). The BIS framework document is the reference text: it establishes that in-scope counterparties must exchange variation margin daily and, above a size threshold, must also exchange initial margin on a gross, segregated basis.

Scope is determined by Average Aggregate Notional Amount (AANA) of in-scope non-cleared derivatives, measured over a defined observation period. The phase-in ran from the largest dealers down to a final Phase 6 threshold — approximately USD 8 billion or EUR 8 billion depending on jurisdiction — which took effect on 1 September 2022. That phase completion is why the population of firms running margin systems expanded from a few dozen dealers to thousands of buy-side entities in the space of three years. There is a second, softer gate: parties whose calculated initial margin sits below the regulatory exchange threshold (commonly cited as EUR/USD 50 million at group level) may defer the custodial and documentation build until they approach it.

The incumbent commercial landscape is narrow. Sensitivity generation is usually in-house because it needs the firm’s own pricing library. Margin calculation is either in-house or from a vendor library. Message exchange is dominated by network utilities — Acadia’s MarginSphere and OSTTRA’s triResolve Margin are the two names you will meet — and portfolio reconciliation is a service layer on top of the same rails. Custody and segregation split between triparty agents and third-party custodians. Nearly every firm assembles these from parts, which is why the integration seams are where the defects live.

The design pressure that distinguishes this domain from, say, a real-time risk engine for crypto derivatives is the latency budget. Margin is latency-tolerant. Nobody needs the SIMM number in microseconds. What margin is instead is correctness-critical and deadline-bound: a number that is right at 11:00 and wrong at 09:00 is fine; a number that is wrong at 11:00 and right at 15:00 has already cost you a failed call.

The Reference Architecture

A production collateral platform is a ten-component pipeline with two feedback loops. Positions and market data flow into sensitivity generation; sensitivities flow into margin calculation; margin plus agreement terms produce a call; the call produces an allocation decision; the allocation produces a settlement instruction. The two loops are reconciliation feeding back into recalculation, and settlement confirmations feeding back into inventory.

Figure 1: Reference architecture. Reference data and market data are separate inputs with different failure signatures; reconciliation is a feedback edge into the call calculator, not a terminal step.

The diagram deliberately splits reference data (agreements, CSAs, eligibility schedules, legal entity hierarchies) from market data (curves, surfaces, fixings). They fail differently and they need different controls. Market data failures are loud and usually detectable by tolerance checks against the prior day. Reference data failures are silent: a trade booked under the wrong Credit Support Annex produces a perfectly valid margin number for the wrong netting set, and nobody notices until the counterparty disagrees by a suspiciously round amount.

Initial margin and variation margin are different systems

It is tempting to treat initial margin (IM) and variation margin (VM) as two outputs of one engine. Resist this. They have different economics, different data dependencies, and different failure modes.

Variation margin is the daily settlement of mark-to-market change on the netting set. It is a transfer of value — economically it settles a debt — and it is typically exchanged in cash, netted bilaterally, and title-transferred so the receiver can rehypothecate it. Its inputs are the portfolio valuation and the prior day’s collateral balance. Its correctness depends almost entirely on trade population and marks.

Initial margin is a forward-looking estimate of potential future exposure over a close-out horizon, calculated gross by each party, and posted into segregation so that neither party can use the other’s collateral. Under UMR, IM must be exchanged on a gross basis without netting the two directions — you post yours, they post theirs. Its inputs are risk sensitivities, not just valuations, and its correctness depends on the sensitivity generation pipeline being consistent between two firms that use entirely different pricing libraries.

That structural asymmetry has an architectural consequence: VM disputes are usually resolved by comparing trade populations and valuations, while IM disputes require comparing thousands of bucketed sensitivities. Build the two dispute paths separately or you will end up with a workflow that fits neither.

The canonical data model

Six entities carry the entire domain. Getting their cardinality right at design time saves a rewrite later.

Agreement is the legal envelope — the ISDA Master plus the Credit Support Annex, Credit Support Deed, or equivalent. It carries the terms that turn a number into an obligation: threshold, Minimum Transfer Amount (MTA), rounding increment, base currency, valuation agent, notification time, and the eligible collateral schedule with its haircuts. One agreement may govern several netting sets; regulatory IM commonly requires separate documentation from legacy VM CSAs, so a legal-entity pair frequently has three or four live agreements at once.

Portfolio / netting set is the calculation unit. It is the set of trades that legally net for close-out under a given agreement. This is the entity most systems get wrong, because the mapping from a trade to a netting set is derived from booking attributes and legal opinions rather than stated explicitly, and it drifts.

Position is the trade-level record with the attributes margin actually needs: product taxonomy, notional, currency, maturity, clearing status, and the netting-set key. Note it is not the front-office trade record — margin needs a stable identifier that survives lifecycle events, and front-office IDs frequently do not.

Sensitivity is a bucketed risk number: risk class, qualifier (curve or issuer), bucket, label1 (tenor), label2 (sub-tenor or basis flag), amount, and currency. This is the CRIF row. It is the highest-cardinality entity in the system by an order of magnitude and it is the one you will spend the most storage and reconciliation effort on.

Call is the workflow object: agreement, valuation date, direction, exposure, required amount, status, and a reason code if disputed. It is the state machine described later.

Movement is the settled fact: instrument, quantity, haircut applied, post-haircut value, account, settlement date, and status. Movements are append-only. Inventory is a projection over movements, never a directly mutated table — if you mutate inventory in place you lose the ability to reconstruct why yesterday’s allocation was chosen, which is exactly the question auditors ask.

Why reference data dominates the correctness budget

Consider what has to match for two firms to agree on an IM number. Both must have the same trade population in the netting set. Both must classify each trade into the same SIMM product class and risk class. Both must generate sensitivities with the same conventions — same tenor grid, same currency of expression, same treatment of notional versus per-unit sensitivity. Both must apply the same version of the model.

Only the last of those is a published, unambiguous rule. The first three are conventions, and conventions decay. A new product gets booked, one firm classifies it as an equity derivative and the other as a hybrid; both are defensible, and the numbers diverge by millions. This is the recurring lesson of the domain: the margin calculation is deterministic and testable, while the inputs to it are the product of two organisations’ independent judgement.

The practical mitigation is not better maths. It is a daily portfolio reconciliation running before the margin call, so trade-population differences surface as recon breaks rather than as margin disputes. Firms that reconcile after calling spend their operations capacity arguing; firms that reconcile before calling spend it fixing.

Calculation Pipelines: End of Day and Intraday

The end-of-day pipeline is the backbone. It is a batch job with a hard external deadline, and its design is dominated by that deadline rather than by throughput.

Figure 2: The end-of-day sensitivity and margin pipeline. The recompute edge on dispute is the expensive path — design so it can run on a subset without a full batch rerun.

Sensitivity generation is the throughput bottleneck

ISDA SIMM is a sensitivity-based model. Per the published SIMM methodology, margin for each risk class is the sum of delta margin, vega margin, curvature margin, and — where applicable — a base correlation margin, aggregated across risk classes with prescribed correlations. Risk classes cover interest rate, credit qualifying, credit non-qualifying, equity, commodity and FX, each with its own bucketing structure and risk weights. The model also incorporates inter-curve basis risk and concentration adjustments.

The engineering consequence is that you must produce delta and vega sensitivities for every trade, on the prescribed tenor grid, every day. For a vanilla interest rate swap that is cheap — an analytic or single-bump revaluation. For a path-dependent exotic priced by Monte Carlo, a full bump-and-revalue across a dozen curve tenors and a vega grid can mean dozens of full pricings per trade. This is where the compute goes: not in the SIMM aggregation, which is a few million floating-point operations over the CRIF, but in generating the CRIF in the first place.

Two design responses matter. First, adjoint algorithmic differentiation (AAD) where your pricing library supports it, which computes all sensitivities in a small multiple of a single pricing cost rather than one revaluation per bump. Second, aggressive caching keyed on trade economics plus market state, so unchanged trades under unchanged curves reuse yesterday’s sensitivities. In portfolios where daily turnover is a low single-digit percentage of trade count, the cache does more for your batch window than adding compute nodes.

Treat any wall-clock figure you read as environment-specific. As an illustrative shape rather than a benchmark: sensitivity generation typically dominates total pipeline time, SIMM aggregation is a small fraction of it, and the batch window is set by the counterparty notification deadline in the CSA rather than by any technical constraint.

CRIF is the interoperability contract

The ISDA Common Risk Interchange Format is the file standard for exchanging these sensitivities. ISDA describes CRIF as an industry standard for risk-data exchange, originally built for SIMM and since extended to standardised approaches for market risk and CVA. It is a column-based format — implementable as CSV or Excel — with a header row and roughly twenty fields covering trade and portfolio identifiers, risk type, qualifier, buckets, tenor labels, amount and currency.

CRIF is deceptively simple and this is a trap. The format is easy; the semantics are where firms diverge. Whether a sensitivity is expressed per basis point or per unit shift, which currency the amount is reported in, how a cross-currency trade is decomposed, how you label a tenor that falls between grid points — all of these are conventions layered on top of the file spec. A CRIF file can be schema-valid and still be meaningless to the receiver.

Design accordingly: version your CRIF generation logic explicitly, stamp the generating model version and convention set into the file metadata, and keep every file you send and receive immutably. When a dispute lands three weeks later, the only way to diagnose it is to replay the exact bytes both sides exchanged.

Intraday margin is a different pipeline, not a faster one

CCPs run intraday margin cycles. When market moves breach internal triggers, the CCP recalculates and issues an intraday call, and clearing members must fund it within hours — sometimes within one. Bilateral agreements can also provide for intraday calls, though in practice bilateral IM is usually a daily process while CCP intraday is routine.

The naive design runs the end-of-day pipeline more often. This fails, because the EOD pipeline is optimised for completeness while intraday needs latency and incrementality. The workable design is a separate, thinner path: revalue on current market data using cached sensitivities and a delta approximation, flag only netting sets whose estimated margin moves beyond a materiality band, and run the full calculation on that subset. You accept approximation error on the screening pass in exchange for finishing in minutes rather than hours.

The operationally important output of intraday is not the margin number — the CCP will tell you that number anyway. It is the forecast: knowing before the CCP calls you that a call is coming, so treasury can pre-position collateral. That forecasting need is what ties this system to intraday liquidity architecture in real-time treasury, because an unanticipated intraday margin call is, from treasury’s perspective, an unfunded same-day cash obligation.

CCP margin models and the default waterfall

Cleared and uncleared margin differ in who computes what. In the cleared world you do not negotiate the number — the CCP computes it and you either fund it or default. Your architecture’s job is replication for forecasting, not agreement.

The model landscape has been shifting from scenario-grid approaches to portfolio VaR and expected-shortfall models. Historically, SPAN-class models applied scenario arrays and inter-commodity spread credits to positions. The industry has been converging on filtered historical simulation: LCH’s PAIRS methodology is described by LSEG as an expected-shortfall VaR model based on filtered historical simulation with volatility scaling, drawing on ten years of historical market data; Eurex introduced its PRISMA model on an FHS VaR basis; CME has migrated listed products to its SPAN 2 framework. The ECB’s occasional paper on CCP initial margin models in Europe observes the same convergence toward FHS VaR with recency weighting.

For a member, this matters because model replication is much harder for FHS VaR than for a scenario grid. A scenario-array model can be reproduced from published parameters. An FHS model depends on the CCP’s historical data set, its volatility filter, and its calibration — so replication becomes approximation, and your forecast has an error band you must size and monitor.

The default waterfall is the loss-allocation order if a member fails, and it should be modelled explicitly in your exposure system because it determines what your default fund contribution is actually exposed to. The standard sequence: the defaulter’s initial margin first, then the defaulter’s default fund contribution, then a tranche of the CCP’s own capital — the “skin in the game” — and only then the mutualised default fund contributions of non-defaulting members. CCP Global’s description of the lines of defence sets out this ordering. The skin-in-the-game tranche is small relative to the mutualised layer by design; its purpose is incentive alignment on margin-setting rather than material loss absorption. Treat your default fund contribution as a contingent, correlated exposure, not as a cash asset.

The Call Lifecycle and Dispute Resolution

A margin call is a state machine with a deadline. Model it as one explicitly — as an entity with states and legal transitions — rather than as a set of status flags on a row, because the audit and escalation requirements demand a full transition history.

Figure 3: Call lifecycle. The dispute branch loops back through reconciliation to re-issue rather than terminating, which is what makes naive status-flag implementations break.

Threshold and MTA gating

Not every exposure produces a call. The agreement defines a threshold — an unsecured exposure the parties tolerate before collateral is required — and a Minimum Transfer Amount, below which no transfer is made even if a delta exists. Rounding increments then round the transfer to a tradeable size. ISDA’s documentation guidance identifies threshold, collateral balance, MTA and rounding as core CSA terms.

The subtlety is that these interact with direction and with existing balances. A call is not “exposure minus threshold”; it is the required collateral amount given the exposure and threshold, minus what is already held, tested against MTA, then rounded. Get the order of operations wrong and you generate a stream of tiny calls that your counterparty rejects and your operations team has to chase. Under regulatory IM, thresholds are further constrained by the regulatory exchange threshold applied at consolidated group level, which is a legal-entity-hierarchy question, not a per-agreement one.

Dispute mechanics and tolerance

A dispute is a disagreement about the call amount, and disputes are routine rather than exceptional. The critical design decision is the tolerance rule: below what difference do you simply agree with the counterparty’s number rather than investigate?

Tolerance should be defined as the greater of an absolute floor and a percentage of the call, calibrated so investigation cost stays below the economic value of being right. A very tight tolerance produces a backlog that starves genuinely material breaks of attention. A very loose one lets systematic bias accumulate — a persistent one-sided error that never individually breaches tolerance but drifts the balance over months. Guard against that by monitoring the signed mean of within-tolerance differences over a rolling window. If it is not centred near zero, you have a convention bug, not noise.

For IM disputes, the investigation path runs through the CRIF. You compare bucketed sensitivities against the counterparty’s file, rank differences by their contribution to the aggregated margin, and work down that list. Note the ranking must be by margin contribution rather than raw sensitivity size, because SIMM’s risk weights and correlations mean a large sensitivity in a low-weight bucket can matter less than a modest one in a high-weight bucket. Systems that rank by raw difference send analysts to the wrong rows.

Vendor networks matter here because they give both parties a shared record of what was sent and when. OSTTRA describes triResolve Margin as automating IM agreement management and margin call exchange with access to Acadia’s MarginSphere messaging, which is representative of the pattern: the utility is the shared log, and the shared log is what makes disputes tractable.

Cut-offs, notification times, and the clock

Every CSA specifies a notification time. A call delivered after it is deemed delivered the following business day, which silently costs you a day of exposure. This makes the batch deadline a legal deadline, and it means your architecture needs an explicit clock model: per-agreement notification times, per-jurisdiction business calendars, and time-zone-aware scheduling across the Asian, European and US windows.

Build the clock as a first-class service. The alternative — deadlines encoded as cron schedules and local timestamps — fails on holiday calendars, on daylight-saving transitions, and on any agreement whose notification time is not the same as the rest of the book. Every collateral operations team has a story about a holiday-calendar bug.

Collateral Optimisation as Constrained Allocation

Once calls are agreed, you must decide what to deliver. This is the one part of the system that is genuinely an optimisation problem, and the one most often implemented as a hard-coded preference list.

Figure 4: Allocation and settlement. Inventory, eligibility rules and funding cost feed one solver; infeasibility is an explicit output that must be surfaced, not silently relaxed.

The problem statement

You have a set of open calls, each with a required post-haircut value, a currency, and an eligibility schedule. You have an inventory of assets across accounts, each with a market value, a haircut per schedule, an internal funding cost, and possibly competing uses. You want an assignment minimising total cost subject to: each call being fully covered post-haircut; no asset allocated twice; concentration limits by issuer, asset class and currency respected; and settlement feasibility given cut-offs and locations.

That is a mixed-integer program. The objective is the “cheapest to deliver” principle: prefer assets whose internal opportunity cost is lowest, which usually means posting the asset you value least among those the counterparty will accept. Haircuts make this non-trivial — a cheaper asset with a punitive haircut requires more of it, and the comparison must be on post-haircut delivered value.

The constraint set is where the real work is. BCBS-IOSCO permits haircuts to be determined either by approved risk-sensitive quantitative models or by a standardised schedule, and the framework’s standardised schedule assigns haircuts by asset category and residual maturity, with a further add-on where the collateral currency differs from the currency of the obligation. Concentration limits exist to prevent inadvertent exposure to a single issuer, issuer type or asset class. Do not encode specific haircut percentages from memory; read them from the agreement’s eligibility schedule as data, because the negotiated schedule can be stricter than the regulatory floor and frequently is.

Why hard-coded preference lists fail

The common implementation walks a static preference list per agreement: cash first, then government bonds, then corporates. It is simple, explainable, and locally reasonable. It fails globally.

The failure mode is contention. Two agreements both prefer the same asset; the first call processed takes it; the second falls through to a materially more expensive asset. Order of processing then determines cost, and processing order is usually an accident of the batch. A solver that considers all calls jointly avoids this by construction. The gain is real but modest in normal conditions and larger under stress, when high-quality collateral becomes scarce — which is precisely when it matters.

The second failure mode is infeasibility handling. A preference list that runs out of eligible assets silently under-delivers. A solver should return infeasibility as an explicit, actionable signal: which call could not be covered, which constraint bound, and what relaxation would fix it — a substitution, a repo trade, or a currency conversion. Surface it to treasury before the settlement cut-off, not after.

Practical modelling notes. Keep the model linear where you can; the integer variables should be the discrete allocation decisions, not the values. Cap solve time and fall back to the preference-list heuristic rather than missing a cut-off — a slightly expensive allocation delivered on time beats an optimal one delivered late. And run the solver on a snapshot of inventory with an explicit version, because inventory changes underneath you as settlements confirm.

Settlement, triparty, and substitution races

Delivery splits into two structurally different paths.

In the triparty model, both parties agree the amount and send a Required Value (RQV) to the triparty agent, which then selects specific securities from the pledgor’s long box within the agreed eligibility profile, allocates them to the segregated account, values them daily, and handles substitutions automatically. ISDA’s guidance on triparty versus third-party structures sets out the distinction. Architecturally, triparty means you send a value and the agent picks the assets — so your optimiser controls only the eligibility profile and the RQV, not the line items.

In the third-party custodian model you select specific securities yourself and instruct settlement to a segregated account. You keep full optimisation control and you take on the operational burden of instruction, matching and fails management.

The messaging layer reflects this split. Bilateral collateral messaging has moved to ISO 20022 MX messages in the colr business area — colr.003 is the margin call request and the family covers substitution, cancellation, status and reporting — while triparty instruction has long run on ISO 15022 MT messages such as MT 527, the triparty collateral instruction. That MT-to-MX coexistence is a real integration cost: your gateway must speak both, and must map between them without losing semantics. If you are already building ISO 20022 capability for payments, the ISO 20022 migration architecture work is directly reusable here — same canonical model discipline, same MT-to-MX mapping problems.

Substitution deserves specific attention because it is a race condition. The pledgor wants an asset back — it has become needed elsewhere — and offers a replacement. Between the substitution request and the confirmed swap, both assets are ambiguously owned. If your inventory projection marks the outgoing asset as available the moment the request is sent, you will double-allocate it. Model substitution as a two-phase commit with an explicit in-flight state, and never treat in-flight collateral as free inventory.

Trade-offs, Gotchas, and What Goes Wrong

Stale market data is the highest-frequency defect. A curve that fails to refresh produces a margin number that looks plausible and is wrong. It rarely trips a schema check. The defence is a comparison of every input surface against the prior day with a tolerance band, and a hard failure rather than a warning when a surface is bit-identical to yesterday. Identical is not “no market move” — identical is almost always a broken feed.

Missed cut-offs cost more than wrong numbers. A call delivered ten minutes after notification time is legally next-day. Budget the batch backwards from the earliest notification time in the book, not forwards from when data arrives, and build a partial-delivery path so a subset of agreements can be called while a slow netting set finishes.

Sensitivity mismatches are convention bugs. Nearly every persistent IM dispute traces to a convention difference — tenor grid interpolation, currency of expression, or product classification — rather than to a pricing error. Compare CRIF aggregates by risk class as a daily control, not only when disputing. A one-sided drift in one risk class is a convention bug you can find in an afternoon; the same bug found through a dispute takes a month.

Substitution races and double allocation. Covered above, and worth repeating because it recurs in every rewrite: in-flight collateral is not available collateral.

Legal-entity hierarchy drift. Regulatory thresholds apply at consolidated group level. If your entity hierarchy is a spreadsheet maintained by someone in legal, your threshold monitoring is a spreadsheet too. This is the least glamorous and most consequential reference-data dependency in the platform.

Over-modelling the optimiser. A solver with an elaborate cost model that nobody can explain will be overridden by operations at the first surprise, and then you have a solver nobody uses. Ship an explainable objective — a short, documented list of cost drivers — and add sophistication only when the current model is demonstrably leaving money on the table.

Assuming CCP model replication is exact. With FHS VaR models it is not. Size your replication error, monitor it against actual CCP calls, and set collateral buffers off the error band rather than off the point estimate.

Practical Recommendations

Start with reference data, not with the margin engine. If agreement terms, eligibility schedules, netting-set mappings and the legal-entity hierarchy are not clean, a correct SIMM implementation will still produce wrong calls. Model those entities properly, source them from the documentation system of record, and put change controls around them.

Make everything replayable. Store every CRIF sent and received, every market-data snapshot, every agreement version, and every allocation input set — immutably and addressable by valuation date. The single most valuable capability in a margin platform is the ability to reproduce exactly what you calculated on a date three months ago, because that is the question every dispute and every audit reduces to.

Separate the screening pass from the full calculation. Fast approximate revaluation for intraday and forecasting, full calculation for the official call. Trying to serve both from one pipeline gives you a slow forecast and a fragile batch.

A concrete checklist before go-live:

Reconciliation runs and clears before the call is issued, not after.
Every input surface has a prior-day comparison with hard-fail on identity.
Notification times, business calendars and time zones are a service, not constants in code.
CRIF generation stamps model version and convention set into every file.
Dispute investigation ranks differences by margin contribution, not by raw sensitivity.
Inventory is a projection over append-only movements, with an explicit in-flight state.
The optimiser returns infeasibility as a structured, actionable signal with a named binding constraint.
The solver has a time cap and a documented heuristic fallback.
Tolerance breaches are monitored for signed drift, not only for magnitude.
Default fund contributions are modelled as contingent correlated exposure, not as assets.

Frequently Asked Questions

What is the difference between initial margin and variation margin?

Variation margin settles the daily mark-to-market change on a netting set — it is a transfer of value, usually in cash, typically netted between the two parties, and generally reusable by the receiver. Initial margin is a forward-looking estimate of potential future exposure over a close-out period, calculated gross by each party, exchanged without netting the two directions, and held in segregation so neither party can use the other’s collateral. They have different inputs: VM needs valuations, IM needs risk sensitivities.

Which ISDA SIMM version applies and how often does it change?

ISDA publishes versioned SIMM methodology documents; version 2.8 with the calibration based on data to end-2025 is the current published line as of 2026. ISDA moved to a semiannual recalibration cycle agreed with global regulators, replacing the previous annual cadence, so the model parameters refresh twice a year on a published schedule. The methodology is also subject to independent external model validation on a multi-year cycle. Always read the version and calibration date from ISDA’s published document rather than assuming.

What is a CRIF file and why does it cause disputes?

CRIF is ISDA’s Common Risk Interchange Format, a column-based file — typically around twenty fields — carrying bucketed risk sensitivities for margin and capital calculations. It causes disputes because the file format is standardised but the conventions behind the numbers are not fully so. Tenor-grid treatment, currency of expression, product classification and sensitivity scaling all vary between firms’ pricing libraries. Two schema-valid CRIF files can encode genuinely different views of the same portfolio.

How does the CCP default waterfall order work?

The standard order applies the defaulting member’s own resources first: its initial margin, then its default fund contribution. Next comes a dedicated tranche of the CCP’s own capital, commonly called skin in the game. Only after those are exhausted are the default fund contributions of non-defaulting members mutualised. Further recovery tools sit beyond that in the rulebook. The skin-in-the-game tranche is deliberately sized for incentive alignment on margin-setting rather than for material loss absorption.

What is the difference between triparty and third-party collateral segregation?

Under triparty, both parties agree a Required Value and the triparty agent selects specific securities from the pledgor’s account within an agreed eligibility profile, then allocates, values and substitutes automatically. Under third-party custody, the pledgor selects the individual securities itself and instructs settlement into a segregated account at a custodian. Triparty trades optimisation control for operational simplicity; third-party keeps full control of which assets go out and takes on the instruction and fails-management burden.

Why is collateral optimisation a constrained-allocation problem rather than a sorting problem?

Because calls compete for the same inventory. A per-call preference list allocates greedily, so whichever call is processed first takes the cheapest eligible asset and later calls fall through to more expensive ones — making cost a function of batch ordering. Solving all calls jointly against shared inventory, eligibility schedules, haircuts and concentration limits removes that dependence. The benefit is modest in normal markets and grows materially under stress, when high-quality collateral becomes scarce.

Collateral and Margin Management Architecture for Derivatives (2026)