The margin call that broke your week probably did not break because the calculation was wrong. It broke because a counterparty amended their Credit Support Annex (CSA) six weeks ago, the amendment sat in a shared drive, and the eligibility schedule in your system still allowed a bond that is no longer acceptable. Collateral management system requirements are where that failure is decided, months before anyone sees it.
Collateral management system requirements are the specification of how a platform stores agreement terms, calculates exposure and margin, issues and receives calls, moves assets and resolves disputes across the life of a collateralised trading relationship. Most requirements documents cover the first two properly and treat the rest as edge cases. That is the whole problem.
What follows assumes you know what a margin call is and that your firm sits under some margin regime. It does not assume the agreements are clean, the reference data is current, or that legal will tell you when a term changes. They will not.
What collateral management system requirements must cover
Collateral management system requirements must cover six domains: agreement terms and their version history, exposure and margin calculation, the call lifecycle, asset movement and settlement, dispute handling, and reporting. Each domain needs its own data model. Treating the agreement as static reference data is the most common and most expensive mistake.
Most documents you inherit are strong on calculation and thin everywhere else. Calculation is the part a business analyst can specify from a formula. The rest requires someone who has watched an operations desk work. The requirements that decide whether the system survives are the ones about change: what happens when a term is amended, an asset stops being eligible, or a counterparty disagrees.
Use these terms consistently across the document. Half the ambiguity in a collateral specification comes from two teams using "threshold" to mean different things.
- Credit Support Annex (CSA) — the legal document appended to a master agreement setting out what collateral each party posts, when, and on what terms.
- Eligibility schedule — the list of asset types a counterparty will accept, with the conditions attached to each.
- Haircut — the percentage discount applied to an asset's market value when counting it towards collateral cover.
- Threshold — the amount of exposure a party is not required to secure at all.
- Minimum Transfer Amount (MTA) — the smallest sum that can move in a single call, below which no transfer is made.
- Concentration limit — a cap on how much of a single issuer, sector or asset type can be posted against one agreement.
The eligibility schedule is a versioned rule set, not reference data
An eligibility schedule is a versioned rule set with effective dates, not a lookup table. The same counterparty can accept different assets under different agreements, and the set changes whenever the CSA is amended. If your data model holds one row per asset type per counterparty, you have already lost the ability to answer what was eligible last Tuesday.
The first consequence is version history on every term. Every agreement term needs an effective date, an amendment reference and a prior value, or you cannot reconstruct why a call was made. Auditors ask this question. So do counterparties, six months later, about a call nobody remembers.
The second consequence is ownership. Amendments arrive as signed PDFs into a legal inbox or a document management system, and somebody has to read them and change the configuration. Name that person in the requirements, with a service level, or the gap between the signed amendment and the configured rule becomes your largest operational risk.
[VERIFY: typical lag between a signed CSA amendment and the corresponding configuration change in the collateral system]
Concentration limits usually live in an annexe that nobody parsed into the system. They were negotiated once, scanned, and filed. The build team specified eligibility by asset type and stopped, because the annexe never made it into the requirements pack. The limit surfaces when a counterparty rejects a delivery and someone finally reads the agreement properly.
[ASHISH: add a real example of an eligibility or concentration term that existed in the agreement but not in the system, and what it cost when it surfaced]
The margin call lifecycle has more states than your specification admits
A margin call moves through more states than issued, agreed and settled. A working specification needs at least: calculated, issued, received, agreed, partially agreed, disputed, pending delivery, delivered, failed, substituted and closed. Each transition needs a timestamp, an actor and a reason code. Systems specified with three states push the rest into email.
The state skipped most often is partial agreement. A counterparty agrees the direction of a call but not the amount, transfers what they accept, and the difference sits open. With no representation for this, the operations desk records the call as settled and tracks the shortfall on a spreadsheet that never appears in any report.
Requirements that only describe the happy path produce a system whose exception queue becomes the real workflow. Count the reason codes you allow. If there are fewer than a dozen, someone will use "other" for a third of the volume and your reporting on failure causes is worthless within a quarter.
Timing matters as much as state. Calls carry notification deadlines set in the agreement, in the counterparty's time zone, against their holiday calendar. A system applying your calendar to their deadline generates calls that are technically late on days your desk is not working.
Valuation is the dependency that quietly decides everything. Your margin figure is only as defensible as the price source behind it, and the feed your risk system already pays for may not be licensed for the use you are about to put it to. The valuation feed is a licensing decision before it is a technical one, and the real cost of showing a price lands on this build.
A dispute is a state, not an email
A dispute is a state, not an email. When a counterparty disagrees with a call, the disagreement carries a value, a reason, an owner, a deadline and a resolution path, all of which belong in the system. Firms treating disputes as an exception handled by conversation cannot report on them, and cannot see the pattern.
The pattern is the point. Repeated disputes with the same counterparty usually trace to one of three causes: a portfolio reconciliation break, a valuation difference on a specific instrument type, or an agreement term each side reads differently. None of those can be fixed without dispute data structured by cause.
Specify the substitution workflow at the same time. A counterparty who posted a bond they now need back will ask to swap it, and the first substitution request arrives in week two of live running. Substitution touches eligibility, haircuts, concentration limits and settlement simultaneously. It is the single most revealing test of whether your data model holds.
The International Swaps and Derivatives Association (ISDA) publishes Suggested Operational Practices covering account setup, contact maintenance and margining specifics, which works as a checklist against your own specification. It describes practice between counterparties rather than system behaviour, so it will not write your requirements for you, and teams that treat it as a functional spec end up with a document about email etiquette.
Build, buy or tri-party, and how each option fails
Three delivery options exist for collateral management: build in-house, buy a vendor platform, or outsource operational handling to a tri-party agent. Each carries a different failure mode. The choice is usually made on cost when it should be made on how often your agreement terms change and how unusual they are.
Build a collateral management system only if collateral is the product you sell. For everyone else the calculation engine is commodity, and the differentiation lives in your agreement data and your operations process. This is the question most teams answer too early, usually before anyone has counted how many distinct agreement variants the firm actually holds.
| Option | What you get | How it fails |
|---|---|---|
| Build in-house | Exact fit to your agreement variants and existing settlement plumbing. | Eligibility and dispute models are built once by a team that then disbands. Regulatory change lands on a backlog with no owner, and the system ages badly from year two. |
| Buy a vendor platform | A tested calculation engine, existing connectivity, and someone else tracking regulatory change. | Unusual agreement terms become configuration workarounds or custom fields. Upgrades then stall because nobody can prove the workarounds survive them. |
| Tri-party agent | Operational handling, custody and eligibility enforcement outside your firm. | You lose granular visibility and inherit the agent's interpretation of eligibility. Reporting that was a query becomes a service request with a turnaround time. |
| Extend an existing risk or treasury system | Fastest route to a first calculation, no new vendor, no procurement cycle. | The host data model has no concept of an agreement version, so amendments are handled by overwriting. Your audit trail disappears silently. |
Whichever you choose, the compliance sign-off does not move to fit your sprint. The control assessment lands after the build is functionally complete, and the findings are about evidence rather than function: who approved this eligibility change, where is the four-eyes check, how do you prove which haircut applied on 14 March. Building for those questions from the start is what product work looks like when compliance has a veto.
How to write collateral management system requirements in seven steps
Writing collateral management system requirements starts with the agreements, not the workflow. Pull the actual documents, count the variants, and build the data model from what they contain. Teams starting from a process diagram produce a specification that fits the average agreement and breaks on the awkward ones, which are the ones generating disputes.
- Pull twenty live agreements at random, including at least three that have been amended. Read the eligibility schedules and annexes in full, not the summary sheet.
- Tabulate every distinct term you find: asset types, haircuts, thresholds, minimum transfer amounts, concentration limits, notification deadlines, valuation sources. Count the variants rather than describing them.
- Design the agreement data model with effective dates and version history on every term, before specifying a single screen.
- Write the call lifecycle as an explicit state machine including partial agreement, dispute and substitution. Attach a reason code list to each transition and cap the use of "other".
- Confirm the valuation source for each asset class with whoever owns the market data contracts, and record the licensed use alongside the technical feed.
- Specify who applies an agreement amendment to the system, within what period, and what evidence that change produces. Put the service level in the document.
- Run the substitution scenario end to end on paper with the operations desk before build starts. If it cannot be described in one pass, the data model is wrong.
Step one is the step that gets cut, because reading twenty agreements takes a fortnight and the plan allows two days for requirements. The desk interview is the other half, and it works differently from external research: your users cannot leave, so they will agree with whatever you propose and then work around it.
[ASHISH: add a real example of a requirements phase where reading the agreements changed the design, or where skipping that step caused rework]
What tokenised collateral changes, as of 2026
Tokenised collateral changes settlement speed, not the eligibility problem. Representing an asset as a digital token on a shared ledger moves it faster between custodians, but the token still has to be eligible under the agreement, valued from a licensed source, and within concentration limits. Your data model carries the same load.
The direction of travel is real. As of 2026 the European Central Bank permits certain marketable assets issued in tokenised form to be used as collateral in Eurosystem credit operations, treated as traditional securities are where they meet existing eligibility standards. The Bank of England has consulted on equivalent treatment under UK EMIR.
Vendor surveys put adoption higher than most operations desks would recognise. A Nasdaq and ValueExchange survey published in 2026 reports that more than half of surveyed firms expect to manage live tokenised collateral by the end of that year. Read it as stated intent from a sponsored sample, not as observed volume.
The failure mode is the one the International Monetary Fund set out in its April 2026 note on tokenised finance: real-time mobilisation eases collateral constraints in normal conditions and accelerates withdrawals and margin calls under stress, transmitting shocks faster across institutions. A system built only for the efficiency case has no throttles and no exposure visibility on the day that matters.
For requirements purposes the implication is narrow. Add a settlement venue attribute to the asset model, allow eligibility rules to distinguish a tokenised instrument from its traditional equivalent, and do not assume the two share a haircut. Everything else in your specification stays as it was.
Once the agreement data model holds, the next problem is the one you inherited rather than built: several hundred agreements already in the system, entered before anyone required an effective date, with no amendment history behind them. Migration is where most collateral programmes lose their second year. Decide now whether you reconstruct that history from the signed documents or accept a clean break with a stated start date, because that choice changes your audit position and is far harder to revisit later.
Frequently asked questions
What is a collateral management system?
A collateral management system is a platform that stores the terms of collateral agreements, calculates exposure and margin against those terms, issues and receives margin calls, tracks the movement of pledged assets, and records disputes and substitutions. It sits between trading systems, valuation sources, custodians and settlement, and is operated mainly by operations and treasury teams.
What should a collateral management requirements document include?
It should specify the agreement data model with version history, margin calculation rules, a full call lifecycle state machine covering disputes and partial agreement, asset movement and settlement, substitution handling, valuation sources with their licensed use, and reporting. It should also name who applies agreement amendments to the system and within what period.
What is the difference between initial margin and variation margin?
Variation margin covers the change in mark-to-market value of a portfolio and is exchanged to settle current exposure, usually daily. Initial margin covers potential future exposure over a close-out period and is held rather than settled, typically segregated with a third-party custodian. They carry different eligibility rules, settlement mechanics and regulatory treatment.
Should you build or buy a collateral management system?
Buy, unless collateral handling is the service you sell to clients. The calculation engine is commodity and vendors track regulatory change on your behalf. Build only where your agreement variants are genuinely unusual and you have a standing team to maintain the system after go-live. Extending an existing risk system is usually the worst of the three.
Why do margin call disputes happen?
Most disputes trace to three causes: a portfolio reconciliation break where each side holds a different trade population, a valuation difference on a specific instrument type, or an agreement term each side interprets differently. Recording disputes with a structured cause code makes the pattern visible. Without it, the same disagreement recurs every month.