Collateral (demo)

From

Quick range

Agreements

CSA VM CSA IM GMRA

Compare

Collateral posted vs exposurestacked bonds + cash, exposure overlaid

Bonds posted Cash posted Exposure

Coverage ratio by agreementposted ÷ exposure over time

Posted by agreementtotal collateral, end of period

Change vs prior period

Agreement breakdown

Agreement	Bonds posted	Cash posted	Total posted	Exposure	Excess / (deficit)	Coverage

Coverage = total collateral posted ÷ exposure. Excess / (deficit) = posted − exposure. A coverage below 100% indicates an under-collateralised position (margin call territory); typical operating buffers run 100–108%.

Period comparison

Metric	Current	Day / Day	Week / Week	Year / Year

Each comparison is anchored on the selected To date. Day/Day steps back one business day, Week/Week 7 calendar days, Year/Year 365 calendar days. Figures are in USD millions unless noted. All values are illustrative demo data generated deterministically in-browser.

Active run

Run

▸ The long form — summary by bond, where the bonds are posted today, and the two flow tables

▾ UI suggested by AI based on what is available from vendors in the market — approval blotter, benefits scorecard, scenario board, movement map and shortfall board

Optimisation Results

Cheapest eligible mix per agreement — click Ignore to exclude a line and see carry cost update live. One search narrows the cards and the posting table together.

Allocation by agreement

vs All-cash baselineannual carry cost

Full posting detail

Agreement	Asset	Type	Holding	Post (mv)	Haircut	Collateral value	Cost (bps)	Annual cost	Action

Optimization Model Research by AI

Same inputs, same rules, same run — a different algorithm deciding what to post. Pick one to see what it proposes.

Model

▾ Developer build detail — other algorithms considered and not built

This section is written for developers and is deliberately technical. Business readers can skip it. Nothing in it runs — it is a shortlist of what else this problem could be solved with, for the decision raised as OQ-46.

Data source

Upload your own production data files, map each demo (dummy) field to a field in your file, then flip the toggle to run the whole app on your real data. Uploads and mappings are saved in this browser, so they stay put across reloads and future visits — this is not a one-time import. With the toggle on Dummy data every screen is exactly the built-in demo. On Production data, each data set that has both an uploaded file and a usable mapping serves your data; any set without them falls back to the demo data. Each card below shows which source it is actually serving. Use Download mappings to save every field mapping to a small file, and Import mappings to restore them later — so if you overwrite the app you re-upload your data files and re-import this one file instead of re-mapping every column by hand.

What the Optimization Results screen reads added 26 Aug 2026 · data sets 12 & 13 detailed 9 Sep 2026

There are two ways to feed this screen, and today it uses the first. The five views — approval blotter, benefits scorecard, scenario board, movement map and shortfall board — present the answer a run already worked out. Today that run is worked out inside the app, so the screen reads nothing of its own and is fed by the same three master data sets the optimiser reads. If your own optimiser works the run out instead, you upload what it produced: data set 12 Optimization outputs (one row per proposed movement) and data set 13 Optimization exclusions & exceptions (one row per record held out or obligation left short). Both now carry a full field list on their own card below and are mapped exactly like every other set. The two tables that lead the screen have their own sets as well — 12.1 Bond sources (internal) and 12.2 Bond destinations (postings out) — and those two are wired: map them and the tables serve your rows instead of the ones the run derived, each falling back on its own. The rules behind a run — data set 11 Optimization rules — are never a file: you set them on the Rules engine tab, and what you set there is the data.

What the screen shows	Which of your files it comes from
The instrument to deliver, its type, where it is held, its market value and its funding cost	Bond inventory
The agreement, its counterparty, what it accepts, its haircut, its rating floor and its concentration limit	Agreements static
How much each agreement owes, which is what the run has to cover	Margin obligations
Haircut applied, collateral value, annual cost, coverage, saving, shortfall	Worked out from the three files above when the app runs the optimiser — or read straight from Optimization outputs when your own optimiser worked the run out
What the run held out, and every obligation it could not fill	Worked out by the app’s own run — or read straight from Optimization exclusions & exceptions
The rules the run applied, and the run’s own settings	Optimization rules — set on the Rules engine tab, never uploaded
Accepted / On hold / Rejected on a movement	None — this is the decision the user takes on the screen, not a value from a file

Two things to decide

The funding cost these screens price everything on is not the one your team maintains. Every “bps” figure on the blotter, and the annual carry and saving built from it, come from a small built-in table of four buckets by asset class and credit rating — not the Cost of funds rates kept on the User maintenance tab. Sample value: the blotter prices FRANCE OAT 1.25% 06/27 at 7 bps and IBRD WORLD BANK 2% 06/26 at 11 bps from that built-in table. Already raised as OQ-39.
Your call: switch the optimiser onto the maintained rates / leave it on the built-in buckets for now / the two are the same, do nothing. Be aware that on today's demo data every holding would fall to the “Others” row and price at zero until the maintained rates are filled in.
The field list below does not cover this screen. Raised as OQ-45. It is generated from the Overview and Inventory Manager screens only. The Rules engine has never been in it either, so no field on either of those two screens is checked against your data. Nothing has regressed — this screen inherits a gap that was already there.
Your call: add the Rules engine and Optimization Results screens to the check (it will raise the field count well above 159 and will produce new call-outs to work through) / leave the check on the two Overview screens.

Every field on the screens generated from the app — traced to your data, or called out

The goal is that every figure on every screen either comes from a file you supply, or is worked out from figures that do. This card is read straight out of the application, so it cannot flatter itself. Anything that does not trace back is listed below with the reason it broke, a real value read off the screen so you can see exactly which box is meant, and the answer that clears it — so this is a list of decisions to make, not a list of problems to worry about.

Every value you can see today is demo data — no file has been loaded yet, so the app fills all of it in. That is not what this card counts. It counts whether a box exists for the value to arrive in: a field is green when a card offers a column your file can carry, even though the demo is writing what you see today; it is amber when nothing you upload can change it, because no column feeds it at all.

159 fields on the screens. 157 have a column your file fills — nothing to do. None are left without one — every value the screens read now has somewhere in your file to come from. 2 have no column feeding them — the app writes those itself, so loading your file leaves them exactly as they are.

What to do with this — it is a short list of decisions, not a list of faults

Go down the lists below. Each line names one value, the screens that need it, and the upload card it would go on.
For each one, give one of three answers: “add it” — the field gets added to that card, so your file can carry it; “we don’t have it” — the field comes off the screen instead; “it’s the same as X” — it is already on a card under another name.
Send the answers back in one go (“add them all” is a valid answer). The cards get updated, this card is regenerated, and the red count drops.

References your files carry (3) — the demo writes an id so the screens have something to show, as it does for every value; the difference is that these now have a column to arrive in

Your call: nothing to do — you named the file each of these comes from and the field is on that card, so the made-up id is replaced by your column. Say “it is issued on our side after all” for any of them and it goes back to being the demo’s own reference.

Trade # — the demo shows TRD-600001 on the Bond postings table (Overview). On screen it reads Trade #, the app stores it as trade, and your file supplies it on the Collateral used data card.
ISIN — the demo shows USV8J7IDADZ2 on the Bond postings table (Overview). On screen it reads ISIN, the app stores it as isin, and your file supplies it on the Bond / securities static, G7 by bond, Optimization outputs, Bond sources (internal), Bond destinations (postings out), Collateral used data, Inventory data cards.
Trade ID — the demo shows MX163952437 on the Trade contributions drill-down (Overview). On screen it reads Trade ID, the app stores it as tid, and your file supplies it on the MX Trades Data card.

Worked out by a rule inside the app (2) — nothing to upload — but the rule has to be the right one

Your call: each rule is printed under the field it produces. Check it reads the way your business does it. If one is wrong, tell me the rule and it is changed; if it should come from a file instead, say which card carries it.

Expected post — reads $37.0M today on the Agreement summary table (Overview)
The rule: Worked out before it is shown: Depends on the app's own mc value — one of two values, chosen by a condition.
Expected collect — reads $0K today on the Agreement summary table (Overview)
The rule: Depends on exp collect — one of two values, chosen by a condition.

The same field on more than one file (21) — one thing carried on several files needs one master list, or two parts of the app can show different answers for the same record

The rule to build to: the identifier travels on every file, the description is held once. A holdings row carries the security’s code so the app can find it; everything else about that security — its issuer, coupon, maturity, rating — is read from the one file that owns securities. Each file below shows the label it uses and whether the field is that file’s own key.

Waiting on you (5)
Your call: name the file that is the master list for it — every other file then carries it only to point at the record; or say “different things” and it drops to the settled list below and stops being asked about.

The app stores this as end, on 3 files: Agreements static (as “Agreement end date”) · Bond sources (internal) (as “End Date”) · Bond destinations (postings out) (as “End Date”)
The app stores this as start, on 3 files: Bond sources (internal) (as “Start Date”) · Bond destinations (postings out) (as “Start Date”) · Inventory data (as “Trade Start”)
The app stores this as g7, on 2 files: G7 industry group (as “G7 industry group”) · G7 by bond (as “G7 industry group”)
The app stores this as interestRate, on 2 files: Agreements static (as “Interest / rebate rate”) · Agreement eligibility schedule (as “Interest / rebate rate”)
The app stores this as portfolio, on 2 files: Bond sources (internal) (as “Portfolio (Source)”, its own key) · Inventory data (as “Portfolio”)

Partly answered — one file still open (1) — what you have already said is recorded below and is not being asked again; only the line marked Still with you needs an answer

The app stores this as maturity, on 4 files: the date a bond redeems and the date a trade ends are two different dates
- the date the bond itself redeems — the inventory row holds that same bond, so it carries the same date: Bond / securities static (as “Maturity”) · Inventory data (as “Maturity Date”) — master: Bond / securities static — settled
- Still with you — Collateral used data (as “Maturity Date”). The card shows 20/09/2029 for it.
  you read this as the repo maturity. Each row on this file is one collateral line posted or held, and it carries the security code and asset class beside this date — so it reads as the maturity of the BOND that was posted, not of the repo. Your call: it is the posted bond's maturity (same value as the securities file) / it really is the repo's own end date / the file should carry both
- Still with you — MX Trades Data (as “Maturity”). The card shows 29/05/2028 for it.
  you asked whether this file is only repo and reverse repo. It is not — the trades behind an agreement are swaps, swaptions, FX forwards, futures and stock loans as well as repos, which matches your own point that these are the derivatives creating the exposure. So this date reads as the trade's own end date. Your call: call it the trade maturity / this file should carry repo trades only

Settled — master named (5) — shown in bold below; every other file carries it only to say which record the row is about

The app stores this as isin, on 7 files: Bond / securities static (as “ISIN”, its own key) · G7 by bond (as “ISIN”) · Optimization outputs (as “ISIN”, its own key) · Bond sources (internal) (as “ISIN”, its own key) · Bond destinations (postings out) (as “ISIN”, its own key) · Collateral used data (as “ISIN / Currency”, its own key) · Inventory data (as “ISIN”, its own key) — master: Bond / securities static
The app stores this as coupon, on 2 files: Bond / securities static (as “Coupon”) · Inventory data (as “Coupon”) — master: Bond / securities static
The app stores this as issuer, on 2 files: Bond / securities static (as “Issuer”) · Inventory data (as “Issuer Name”) — master: Bond / securities static — the agreement file holds a SELECTION of these values — the issuers it accepts as collateral — not one issuer of its own
The app stores this as label, on 2 files: Bond / securities static (as “Instrument Name”) · Inventory data (as “Instrument Name”) — master: Bond / securities static
The app stores this as seniority, on 2 files: Bond / securities static (as “Seniority”) · Inventory data (as “Seniority of Bond”) — master: Inventory data — the securities file does not carry seniority today, so the bond's own seniority is only on the inventory file; say the word and it moves onto the securities file with coupon, sector and maturity

Settled — several different things (2) — you have said the files carrying this name do not all mean the same value. Each meaning is listed below with the files that carry it; where a meaning is on more than one file, its master is in bold. Nothing to decide

The app stores this as ccy, on 4 files: a bond's currency, an FX rate's currency and a trade's currency are three different values
- the currency the bond itself is denominated in — the inventory row holds that same instrument, so it carries the same value: Bond / securities static (as “Bond Currency”) · Inventory data (as “Bond Currency”) — master: Bond / securities static — settled
- the currency an FX rate is quoted for: Market data — FX rates (as “FX Currency”, its own key) — on this file only — settled
- the currency the trade is booked in: MX Trades Data (as “Trade Currency”) — on this file only — settled
The app stores this as notional, on 2 files: the size of a bond we hold and the size of a trade are two different amounts
- the size of the bond position: Inventory data (as “Bond Notional (mm)”) — on this file only — settled
- the size of the trade: MX Trades Data (as “Notional”) — on this file only — settled

Settled — one value for the whole entity (1) — you have said this is set once for the entity, not carried record by record, so every file shows the same value and there is no master to name. Nothing to decide

The app stores this as repccy, on 2 files: Agreements static (as “Reporting currency”) · Collateral used data (as “Reporting Currency”) — one reporting currency for the whole Singapore entity, set once for the entity rather than carried record by record, so every file shows the same value and there is no master to name. The screens already state it in words: the Bond postings table heads its amount columns Posted (USD), Allocated (USD) and Unallocated (USD), and every money figure in the app prints a dollar sign. Those are typed into the app rather than read from this column — left as is on your instruction of 26 Aug 2026

Nothing to decide yet — no screen reads it (6) — the files offer this column but no chart, table or pop-up in the app reads it, and no heading states it either, so there is no place two answers could disagree. It becomes a question the day something displays it

The app stores this as rate, on 3 files: Market data — FX rates (as “Rate (USD per 1 unit)”, its own key) · Bond sources (internal) (as “Rate”) · Bond destinations (postings out) (as “Rate”) — no screen reads it today
The app stores this as agKey, on 2 files: Agreements static (as “Type code”, its own key) · Agreement eligibility schedule (as “Type code”, its own key) — no screen reads it today
The app stores this as agname, on 2 files: Optimization outputs (as “Agreement Name”, its own key) · Collateral used data (as “Agreement Name”, its own key) — no screen reads it today
The app stores this as amount, on 2 files: Bond sources (internal) (as “Amount”) · Bond destinations (postings out) (as “Amount”) — no screen reads it today
The app stores this as direction, on 2 files: Bond sources (internal) (as “Direction”) · Bond destinations (postings out) (as “Direction”) — no screen reads it today
The app stores this as runId, on 2 files: Optimization outputs (as “Run reference”, its own key) · Optimization exclusions & exceptions (as “Run reference”, its own key) — no screen reads it today

Settled — not one field (1) — two different things that happen to share a name. Nothing to decide; listed so nobody joins them by mistake

The app stores this as code, on 2 files: Counterparty static (as “Counterparty code”) · Currency static (as “Currency code”, its own key) — a counterparty's code and a currency's code are not the same value

One label, two different values — the same words on screen mean different things depending where you are; worth renaming one

Agreement is used for account on the Show all agreements view of the Trade contributions drill-down (Overview) and name on the Agreement summary table (Overview).
Issuer country is used for issuerCountry on the Concentration risk strip in the agreement pop-up (Overview) and issuerCtry on the security pop-up you get by clicking an ISIN (Inventory Manager).
Type is used for btype on the Bond postings table (Overview) and type on the security pop-up you get by clicking an ISIN (Inventory Manager) and the security pop-up you get by clicking an ISIN (Overview).

Same value, different labels on screen — 13 of them. Some differences are deliberate (a figure shown in millions on one screen and in dollars on another), so this is a decision to make, not an error to fix

Waiting on you (11)
Your call: pick the one wording for it, or say leave them and the screens keep their own words.

account appears as Agreement on the Show all agreements view of the Trade contributions drill-down (Overview) · Agreement Name on the Bond postings table (Overview)
industry appears as Industry Classification on the Column display view of the Bond inventory table (Inventory Manager) · Industry classification on the security pop-up you get by clicking an ISIN (Inventory Manager) and the security pop-up you get by clicking an ISIN (Overview)
issuer appears as Issuer on the Eligibility schedule in the agreement pop-up (Overview) and the security pop-up you get by clicking an ISIN (Inventory Manager) · Issuer Name on the Column display view of the Bond inventory table (Inventory Manager)
issuerCtry appears as Country of Issuer on the Time series of inventory table (Inventory Manager) · Issuer Country on the Column display view of the Bond inventory table (Inventory Manager) · Issuer country on the security pop-up you get by clicking an ISIN (Inventory Manager)
label appears as Instrument Name on the Column display view of the Bond inventory table (Inventory Manager) and the Time series of inventory table (Inventory Manager) · Security on the Bond postings table (Overview)
maturity appears as Maturity on the Bond postings table (Overview) and the Trade contributions drill-down (Overview) · Maturity date on the security pop-up you get by clicking an ISIN (Inventory Manager) and the security pop-up you get by clicking an ISIN (Overview)
name appears as Agreement on the Agreement summary table (Overview) · Instrument name on the security pop-up you get by clicking an ISIN (Inventory Manager) and the security pop-up you get by clicking an ISIN (Overview)
sector appears as Sector on the Bond postings table (Overview) · Sector of Issuer on the Column display view of the Bond inventory table (Inventory Manager) · Sector of issuer on the security pop-up you get by clicking an ISIN (Inventory Manager) and the security pop-up you get by clicking an ISIN (Overview)
seniority appears as Seniority on the Eligibility schedule in the agreement pop-up (Overview) and the security pop-up you get by clicking an ISIN (Inventory Manager) · Seniority of Bond on the Column display view of the Bond inventory table (Inventory Manager)
start appears as Start date on the Dates & Status card in the agreement pop-up (Overview) · Trade start on the security pop-up you get by clicking an ISIN (Inventory Manager) and the security pop-up you get by clicking an ISIN (Overview)
type appears as Agreement type on the Agreement Admin card in the agreement pop-up (Overview) · Type on the security pop-up you get by clicking an ISIN (Inventory Manager) and the security pop-up you get by clicking an ISIN (Overview)

Settled — different labels are right (2) — you have already said this name covers more than one value, so the screens must not be made to read the same. Nothing to decide

ccy appears as Bond Ccy on the Time series of inventory table (Inventory Manager) · Ccy on the Trade contributions drill-down (Overview) · Instrument Ccy on the Column display view of the Bond inventory table (Inventory Manager) · Instrument currency on the security pop-up you get by clicking an ISIN (Inventory Manager) and the security pop-up you get by clicking an ISIN (Overview) — a bond's currency, an FX rate's currency and a trade's currency are three different values
notional appears as Bond Notional (mm) on the Column display view of the Bond inventory table (Inventory Manager) · Notional (USD) on the Trade contributions drill-down (Overview) — the size of a bond we hold and the size of a trade are two different amounts

Label on screen	Stored as	Card field to map it to	Which chart or table shows it	Direct or computed	How it is worked out	What it shows today	Traces to your data?
Agreement Name	`account`	none yet	the Bond postings table Overview	Computed	Worked out before it is shown: Label, with the wording around it.	CSG_Amberlaine Bank_RIM↗	yes
Trade #	`trade`	trade	the Bond postings table Overview	Computed	Worked out before it is shown: Worked out from more than one stored value.	TRD-600001	yes
ISIN	`isin`	isin	the Bond postings table Overview	Computed	Worked out before it is shown: Built by the app's genISIN rule.	USV8J7IDADZ2	yes
Security	`label`	label	the Bond postings table Overview	Computed	Worked out before it is shown: Taken straight from name.	US TREASURY N/B 3.125% 06/26	yes
Type	`btype`	btype	the Bond postings table Overview	Direct	Taken straight from type.	UST	yes
Sector	`sector`	sector	the Bond postings table Overview	Direct	Taken straight from sector.	Sovereign	yes
Counterparty	`cpty`	cpty	the Bond postings table Overview	Direct	Taken straight from counterparty.	Amberlaine Bank	yes
Agreement Type	`—`	n/a — worked out	the Bond postings table Overview	Computed	Worked out from more than one stored value.	Bilateral CSA IM	yes
Custodian	`custodian`	custodian	the Bond postings table Overview	Direct	Taken straight from custodian (shown by its display name).	Euroclear	yes
Source	`source`	source	the Bond postings table Overview	Direct	Taken straight from source.	CT	yes
Maturity	`maturity`	maturity	the Bond postings table Overview	Direct	Taken straight from maturity.	24 Jun 2026	yes
Product	`prod`	prod	the Trade contributions drill-down Overview	Direct	Taken straight from product.	Cleared OIS	yes
Trade ID	`tid`	tid	the Trade contributions drill-down Overview	Computed	Worked out before it is shown: Worked out from more than one stored value.	MX163952437	yes
Trade date	`tradeDate`	tradeDate	the Trade contributions drill-down Overview	Direct	Taken straight from trade date.	07 Jan 2023	yes
Maturity	`maturity`	maturity	the Trade contributions drill-down Overview	Direct	Taken straight from maturity.	24 Jun 2026	yes
Notional (USD)	`notional`	notional	the Trade contributions drill-down Overview	Direct	Taken straight from notional (usd).	$15.05B	yes
Ccy	`ccy`	ccy	the Trade contributions drill-down Overview	Direct	Taken straight from ccy.	JPY	yes
MtM (USD)	`mtmUsd`	mtmUsd	the Trade contributions drill-down Overview	Direct	Taken straight from mtm (usd).	$60.2M	yes
Agreement	`account`	none yet	the Show all agreements view of the Trade contributions drill-down Overview	Computed	Worked out before it is shown: Label, with the wording around it.	GMRA	yes
Agreement	`name`	name	the Agreement summary table Overview	Computed	Worked out before it is shown: Taken straight from name.	GMRA	yes
Total exposure	`exposure`	none yet	the Agreement summary table Overview	Computed	Worked out before it is shown: Total exposure multiplied by the app's own w value.	$647.9M	yes
Call / obligation	`obligation`	obligation	the Agreement summary table Overview	Computed	Worked out before it is shown: Call / obligation multiplied by the app's own w value.	$635.9M	yes
Received (in)	`received`	received	the Agreement summary table Overview	Computed	Worked out before it is shown: Received (in) multiplied by the app's own w value.	$672.4M	yes
Margin call	`marginCall`	marginCall	the Agreement summary table Overview	Computed	Worked out before it is shown: Margin call multiplied by the app's own w value.	$37.0M	yes
Total	`—`	n/a — worked out	the Agreement summary table Overview	Computed	Bonds (posted) plus cash (posted).	$598.9M	yes
Bonds (Posted)	`bond`	bondRating (different name, same thing)	the Agreement summary table Overview	Computed	Worked out before it is shown: Bonds (posted) multiplied by the app's own w value.	$587.9M	yes
Cash (Posted)	`cash`	cash	the Agreement summary table Overview	Computed	Worked out before it is shown: Cash (posted) multiplied by the app's own w value.	$11.1M	yes
Total	`used`	none yet	the Agreement summary table Overview	Computed	Worked out before it is shown: Total multiplied by the app's own w value.	$598.9M	yes
Bonds (Allocated)	`bondUsed`	none yet	the Agreement summary table Overview	Computed	Worked out before it is shown: Bonds (allocated) multiplied by the app's own w value.	$587.9M	yes
Cash (Allocated)	`cashUsed`	cash (different name, same thing)	the Agreement summary table Overview	Computed	Worked out before it is shown: Cash (allocated) multiplied by the app's own w value.	$11.1M	yes
Unallocated	`unalloc`	none yet	the Agreement summary table Overview	Computed	Worked out before it is shown: Built by the app's unallocOf rule.	$0K	yes
Surplus	`surplus`	none yet	the Agreement summary table Overview	Computed	Worked out before it is shown: Built by the app's surplusOf rule.	$562.0M	yes
DoD (total allocated)	`dod`	none yet	the Agreement summary table Overview	Computed	Worked out before it is shown: Total minus the app's own u1 value.	▼ -$21.9M (-3.5%)	yes
WoW (total allocated)	`wow`	none yet	the Agreement summary table Overview	Computed	Worked out before it is shown: Total minus the app's own u7 value.	▼ -$39.4M (-6.2%)	yes
MoM (total allocated)	`mom`	none yet	the Agreement summary table Overview	Computed	Worked out before it is shown: Total minus the app's own u30 value.	▲ $112.7M (23.2%)	yes
Threshold	`threshold`	threshold	the Agreement summary table Overview	Computed	Worked out before it is shown: Threshold multiplied by the app's own w value.	$12.0M	yes
Expected post	`expPost`	none yet	the Agreement summary table Overview	Computed	Worked out before it is shown: Depends on the app's own mc value — one of two values, chosen by a condition.	$37.0M	no column feeds it
Expected collect	`—`	n/a — worked out	the Agreement summary table Overview	Computed	Depends on exp collect — one of two values, chosen by a condition.	$0K	no column feeds it
ITM Exposure	`itmExp`	none yet	the Agreement summary table Overview	Computed	Worked out before it is shown: Itm exposure multiplied by the app's own w value.	$228.2M	yes
OTM Exposure	`otmExp`	none yet	the Agreement summary table Overview	Computed	Worked out before it is shown: Otm exposure multiplied by the app's own w value.	-$145.9M	yes
Dispute Value	`disputeVal`	none yet	the Agreement summary table Overview	Computed	Worked out before it is shown: Dispute value multiplied by the app's own w value.	$427K	yes
Dispute Age	`disputeAge`	disputeAge	the Agreement summary table Overview	Direct	Taken straight from dispute age (zero if it is not supplied).	1d	yes
Base CCY	`baseCcy`	baseCcy	the Agreement summary table Overview	Direct	Taken straight from base ccy (a dash if it is not supplied).	USD	yes
Base Total Exp.	`baseTotalExp`	none yet	the Agreement summary table Overview	Computed	Worked out before it is shown: Base total exp. multiplied by the app's own w value.	$374.0M	yes
Base Call Amt	`baseCallAmt`	none yet	the Agreement summary table Overview	Computed	Worked out before it is shown: Base call amt multiplied by the app's own w value.	$21.3M	yes
Concentration limits group name	`group`	group	the Concentration risk strip in the agreement pop-up Overview	Direct	Taken straight from group.	—	yes
Limit type	`limitType`	limitType	the Concentration risk strip in the agreement pop-up Overview	Direct	Taken straight from limit type.	Max	yes
Limit type granularity	`granularity`	granularity	the Concentration risk strip in the agreement pop-up Overview	Direct	Taken straight from granularity.	—	yes
Limit	`limit`	limit	the Concentration risk strip in the agreement pop-up Overview	Direct	Taken straight from limit.	20%	yes
Limit unit	`unit`	unit	the Concentration risk strip in the agreement pop-up Overview	Direct	Taken straight from unit.	—	yes
Asset class	`assetClass`	assetClass	the Concentration risk strip in the agreement pop-up Overview	Direct	Taken straight from asset class.	Sovereign	yes
Asset type	`assetType`	assetType	the Concentration risk strip in the agreement pop-up Overview	Direct	Taken straight from asset type.	Government Bond	yes
Issuer sector	`issuerSector`	issuerSector	the Concentration risk strip in the agreement pop-up Overview	Direct	Taken straight from issuer sector.	Sovereign	yes
Issuer country	`issuerCountry`	issuerCountry	the Concentration risk strip in the agreement pop-up Overview	Direct	Taken straight from issuer country.	US, AU, CA, FR, DE, GB, SG	yes
Basis	`basis`	basis	the Concentration risk strip in the agreement pop-up Overview	Direct	Taken straight from basis.	Contract Collateral Basis	yes
MTM	`—`	n/a — worked out	the Exposure card in the agreement pop-up Overview	Computed	Mtm (shown formatted).	$150.4M	yes
Independent Amount (IA)	`—`	n/a — worked out	the Exposure card in the agreement pop-up Overview	Computed	Obligation minus mtm (shown formatted).	$50.1M	yes
Agreement type	`type`	none yet	the Agreement Admin card in the agreement pop-up Overview	Computed	Worked out before it is shown: Depends on the row — one of two values, chosen by a condition.	Bilateral CSA IM	yes
Margin type	`marginType`	marginType	the Agreement Admin card in the agreement pop-up Overview	Direct	Taken straight from margin type (a dash if it is not supplied).	Initial Margin (IM)	yes
Valuation frequency	`valuationFreq`	valuationFreq	the Agreement Admin card in the agreement pop-up Overview	Direct	Taken straight from valuation freq (a dash if it is not supplied).	Daily (T+0)	yes
Reciprocity	`reciprocal`	reciprocal	the Agreement Admin card in the agreement pop-up Overview	Direct	Taken straight from reciprocal (a dash if it is not supplied).	Yes	yes
Benchmark rate	`benchmarkRate`	benchmarkRate	the Agreement Admin card in the agreement pop-up Overview	Direct	Taken straight from benchmark rate (a dash if it is not supplied).	SOFR	yes
Start date	`start`	start	the Dates & Status card in the agreement pop-up Overview	Direct	Taken straight from start (a dash if it is not supplied).	10 Apr 2026	yes
End date	`end`	end	the Dates & Status card in the agreement pop-up Overview	Direct	Taken straight from end (a dash if it is not supplied).	14 Mar 2031	yes
ABC MTA	`—`	n/a — worked out	the Margin Call Summary card in the agreement pop-up Overview	Computed	Abc mta when the record carries one, otherwise the app's own mta value.	$500K	yes
Counterparty MTA	`—`	n/a — worked out	the Margin Call Summary card in the agreement pop-up Overview	Computed	Cpty mta when the record carries one, otherwise the app's own mta value.	$500K	yes
Rounding (delivery)	`roundingDelivery`	roundingDelivery	the Margin Call Summary card in the agreement pop-up Overview	Direct	Taken straight from rounding delivery (a dash if it is not supplied).	DOWN	yes
Rounding (return)	`roundingReturn`	roundingReturn	the Margin Call Summary card in the agreement pop-up Overview	Direct	Taken straight from rounding return (a dash if it is not supplied).	DOWN	yes
Collateral balance (posted)	`—`	n/a — worked out	the Margin Call Calculation card in the agreement pop-up Overview	Computed	Posted (shown formatted).	$174.0M	yes
Margin call / surplus	`—`	n/a — worked out	the Margin Call Calculation card in the agreement pop-up Overview	Computed	Margin call multiplied by the app's own wt value, with the plus or minus sign dropped (shown formatted).	$26.5M	yes
Direction	`—`	n/a — worked out	the Margin Call Calculation card in the agreement pop-up Overview	Computed	Depends on the row — one of two values, chosen by a condition (shown formatted).	Call — deliver collateral	yes
Total exposure	`—`	n/a — worked out	the Margin Call Calculation card in the agreement pop-up Overview	Computed	Obligation multiplied by the app's own wt value (shown formatted).	$647.9M	yes
ABC threshold	`abcThreshold`	abcThreshold	the Margin Call Calculation card in the agreement pop-up Overview	Direct	Taken straight from abc threshold (a dash if it is not supplied).	$0	yes
Cpty threshold	`cptyThreshold`	cptyThreshold	the Margin Call Calculation card in the agreement pop-up Overview	Direct	Taken straight from cpty threshold (a dash if it is not supplied).	$0	yes
Notification time	`—`	n/a — worked out	the Call Schedule card in the agreement pop-up Overview	Computed	The agreement's own notif time when it carries one, otherwise the standard one.	08:00 SGT	yes
Resolution time	`—`	n/a — worked out	the Call Schedule card in the agreement pop-up Overview	Computed	Resolution time when the record carries one, otherwise notif by.	T+1 14:00 NY	yes
Time zone	`timezone`	timezone	the Call Schedule card in the agreement pop-up Overview	Direct	Taken straight from timezone (a dash if it is not supplied).	America/New_York	yes
Holiday centre(s)	`holidayCentres`	holidayCentres	the Call Schedule card in the agreement pop-up Overview	Direct	Taken straight from holiday centres (a dash if it is not supplied).	New York, London	yes
Settlement delay	`settlementDelay`	settlementDelay	the Call Schedule card in the agreement pop-up Overview	Direct	Taken straight from settlement delay (a dash if it is not supplied).	0d	yes
Interest calc method	`interestCalc`	interestCalc	the Collateral Rules card in the agreement pop-up Overview	Direct	Taken straight from interest calc (a dash if it is not supplied).	SOFR	yes
Calculation rule	`calculationRule`	calculationRule	the Collateral Rules card in the agreement pop-up Overview	Direct	Taken straight from calculation rule (a dash if it is not supplied).	Simple	yes
Interest settlement date	`interestSettlementDate`	interestSettlementDate	the Collateral Rules card in the agreement pop-up Overview	Direct	Taken straight from interest settlement date (a dash if it is not supplied).	First of the Month	yes
Allow negative rate	`allowNegRate`	allowNegRate	the Collateral Rules card in the agreement pop-up Overview	Direct	Taken straight from allow neg rate (a dash if it is not supplied).	No	yes
Group	`—`	n/a — worked out	the Concentration risk strip in the agreement pop-up Overview	Computed	Built by the app's cGet rule.	IM Standard Concentration Limits	yes
Granularity	`—`	n/a — worked out	the Concentration risk strip in the agreement pop-up Overview	Computed	Built by the app's cGet rule.	Per Issuer Country	yes
Currency	`currency`	currency	the Eligibility schedule in the agreement pop-up Overview	Direct	Taken straight from currency (a dash if it is not supplied).	AUD, CAD, EUR, GBP, JPY, SGD, USD	yes
Interest / rebate rate	`interestRate`	interestRate	the Eligibility schedule in the agreement pop-up Overview	Direct	Taken straight from interest rate (a dash if it is not supplied).	SOFR	yes
Issuer	`issuer`	issuer	the Eligibility schedule in the agreement pop-up Overview	Direct	Taken straight from issuer (a dash if it is not supplied).	US Treasury, Agency, Supra-National	yes
Seniority	`seniority`	seniority	the Eligibility schedule in the agreement pop-up Overview	Direct	Taken straight from seniority (a dash if it is not supplied).	Unsubordinated	yes
Security rating	`—`	n/a — worked out	the Eligibility schedule in the agreement pop-up Overview	Computed	Security rating when the record carries one, otherwise rating floor2.	>= A- / A3 / A- (S&P/Moody/Fitch)	yes
Time to maturity	`timeToMaturity`	timeToMaturity	the Eligibility schedule in the agreement pop-up Overview	Direct	Taken straight from time to maturity (a dash if it is not supplied).	<= 25 years	yes
Haircut schedule	`haircutSchedule`	haircutSchedule	the Eligibility schedule in the agreement pop-up Overview	Direct	Taken straight from haircut schedule (a dash if it is not supplied).	0% — no haircut	yes
Exclusions	`exclusions`	exclusions	the Eligibility schedule in the agreement pop-up Overview	Direct	Taken straight from exclusions (a dash if it is not supplied).	Convertibles; subordinated debt; own-issue & affiliate paper	yes
Currency code	`—`	n/a — worked out	the Static Data reference screens Overview	Computed	Worked out from more than one stored value.	—	yes
Curve / index name	`—`	n/a — worked out	the Static Data reference screens Overview	Computed	Worked out from more than one stored value.	—	yes
Day count	`—`	n/a — worked out	the placeholder block at the foot of the security pop-up Overview	Computed	Worked out from more than one stored value.	— to be provided —	yes
Instrument name	`name`	name	the security pop-up you get by clicking an ISIN Overview	Computed	Worked out before it is shown: Taken straight from name (shown formatted).	US TREASURY N/B 3.125% 06/26	yes
ISIN	`isin`	isin	the security pop-up you get by clicking an ISIN Overview	Computed	Worked out before it is shown: Built by the app's genISIN rule (shown formatted).	USV8J7IDADZ2	yes
Type	`type`	none yet	the security pop-up you get by clicking an ISIN Overview	Computed	Worked out before it is shown: Depends on the row — one of two values, chosen by a condition (shown formatted).	UST	yes
Industry classification	`industry`	industry	the security pop-up you get by clicking an ISIN Overview	Direct	Taken straight from industry (shown formatted).	Sovereign	yes
Sector of issuer	`sector`	sector	the security pop-up you get by clicking an ISIN Overview	Direct	Taken straight from sector (shown formatted).	Government	yes
Classification Level 4 name	`l4`	l4	the security pop-up you get by clicking an ISIN Overview	Direct	Taken straight from l4 (shown formatted).	Others	yes
BICS Level 2 Industry Group Name	`bics`	bics	the security pop-up you get by clicking an ISIN Overview	Direct	Taken straight from bics (shown formatted).	Others	yes
Issuer Industry	`issuerIndustry`	issuerIndustry	the security pop-up you get by clicking an ISIN Overview	Direct	Taken straight from issuer industry (shown formatted).	GOVT NATIONAL	yes
G7 Industry group	`g7`	g7	the security pop-up you get by clicking an ISIN Overview	Direct	Taken straight from g7 (shown formatted).	Others	yes
Instrument currency	`ccy`	ccy	the security pop-up you get by clicking an ISIN Overview	Direct	Taken straight from ccy (shown formatted).	USD	yes
Coupon	`—`	n/a — worked out	the security pop-up you get by clicking an ISIN Overview	Computed	Coupon, with the wording around it (shown formatted).	3.125% · Bullet	yes
Clearer	`clearer`	clearer	the security pop-up you get by clicking an ISIN Overview	Direct	Taken straight from clearer (shown formatted).	Euroclear	yes
Issuer rating	`—`	n/a — worked out	the security pop-up you get by clicking an ISIN Overview	Computed	Issuer rating, with the wording around it (shown formatted).	AAA	yes
Bond rating	`—`	n/a — worked out	the security pop-up you get by clicking an ISIN Overview	Computed	Bond rating, with the wording around it (shown formatted).	AAA	yes
Bond notional	`—`	n/a — worked out	the security pop-up you get by clicking an ISIN Overview	Computed	Notional (usd) and ccy, with the wording around it (shown formatted).	46.7 mm USD	yes
MTM of notional	`—`	n/a — worked out	the security pop-up you get by clicking an ISIN Overview	Computed	Mtm and ccy, with the wording around it (shown formatted).	42.7 mm USD (price 91.48)	yes
Issue date	`issueDate`	none yet	the security pop-up you get by clicking an ISIN Overview	Computed	Worked out before it is shown: Built by the app's instrIssueDate rule (shown formatted).	24 Jun 2020	yes
Trade start	`start`	start	the security pop-up you get by clicking an ISIN Overview	Direct	Taken straight from start (shown formatted).	10 Apr 2026	yes
Maturity date	`maturity`	maturity	the security pop-up you get by clicking an ISIN Overview	Direct	Taken straight from maturity (shown formatted).	24 Jun 2026	yes
Portfolio	`portfolio`	portfolio	the Column display view of the Bond inventory table Inventory Manager	Direct	Taken straight from portfolio.	Treasury ALM	yes
Business Line	`bizline`	bizline	the Column display view of the Bond inventory table Inventory Manager	Direct	Taken straight from business line.	Repo & Collateral	yes
Holding	`holding`	holding	the Column display view of the Bond inventory table Inventory Manager	Direct	Taken straight from holding (shown by its display name).	Internal	yes
Instrument Name	`label`	label	the Column display view of the Bond inventory table Inventory Manager	Direct	Taken straight from label.	US TREASURY N/B 3.625% 03/32	yes
ISIN	`isin`	isin	the Column display view of the Bond inventory table Inventory Manager	Direct	Taken straight from isin.	USJN7J29IZS7	yes
Instrument Ccy	`ccy`	ccy	the Column display view of the Bond inventory table Inventory Manager	Direct	Taken straight from ccy.	USD	yes
Bond Notional (mm)	`notional`	notional	the Column display view of the Bond inventory table Inventory Manager	Direct	Taken straight from bond notional (mm).	2,136.7	yes
Issuer Name	`issuer`	issuer	the Column display view of the Bond inventory table Inventory Manager	Direct	Taken straight from issuer name.	US TREASURY N/B	yes
Issuer Country	`issuerCtry`	issuerCtry	the Column display view of the Bond inventory table Inventory Manager	Direct	Taken straight from issuer ctry.	United States	yes
Seniority of Bond	`seniority`	seniority	the Column display view of the Bond inventory table Inventory Manager	Direct	Taken straight from seniority of bond.	Senior Unsecured	yes
Callable / Coupon	`—`	n/a — worked out	the Column display view of the Bond inventory table Inventory Manager	Computed	Coupon, with the wording around it.	Bullet · 3.625%	yes
Clearer	`clearer`	clearer	the Column display view of the Bond inventory table Inventory Manager	Direct	Taken straight from clearer.	Fedwire	yes
Sector of Issuer	`sector`	sector	the Column display view of the Bond inventory table Inventory Manager	Direct	Taken straight from sector of issuer.	Government	yes
Industry Classification	`industry`	industry	the Column display view of the Bond inventory table Inventory Manager	Direct	Taken straight from industry classification.	Sovereign	yes
Issuer Rating	`issuerRating`	issuerRating	the Column display view of the Bond inventory table Inventory Manager	Direct	Taken straight from issuer rating.	AA+	yes
Bond Rating	`bondRating`	bondRating	the Column display view of the Bond inventory table Inventory Manager	Direct	Taken straight from bond rating.	AA+	yes
MTM of Notional (mm)	`mtm`	mtm	the Column display view of the Bond inventory table Inventory Manager	Direct	Taken straight from mtm of notional (mm).	2,104.4	yes
ISIN	`isin`	isin	the Time series of inventory table Inventory Manager	Direct	Taken straight from isin.	USJN7J29IZS7	yes
Instrument Name	`label`	label	the Time series of inventory table Inventory Manager	Direct	Taken straight from label.	US TREASURY N/B 3.625% 03/32	yes
Country of Issuer	`issuerCtry`	issuerCtry	the Time series of inventory table Inventory Manager	Direct	Taken straight from issuer ctry.	United States	yes
Bond Ccy	`ccy`	ccy	the Time series of inventory table Inventory Manager	Direct	Taken straight from ccy.	USD	yes
Day count	`—`	n/a — worked out	the placeholder block at the foot of the security pop-up Inventory Manager	Computed	Worked out from more than one stored value.	— to be provided —	yes
Instrument name	`name`	name	the security pop-up you get by clicking an ISIN Inventory Manager	Direct	Taken straight from name (shown formatted).	US TREASURY N/B 3.625% 03/32	yes
ISIN	`isin`	isin	the security pop-up you get by clicking an ISIN Inventory Manager	Direct	Taken straight from isin (shown formatted).	USJN7J29IZS7	yes
Issuer	`issuer`	issuer	the security pop-up you get by clicking an ISIN Inventory Manager	Direct	Taken straight from issuer name (shown formatted).	SINGAPORE GOVT	yes
Type	`type`	none yet	the security pop-up you get by clicking an ISIN Inventory Manager	Computed	Worked out before it is shown: Depends on the app's own cat value — one of two values, chosen by a condition (shown formatted).	Govies	yes
Issuer country	`issuerCtry`	issuerCtry	the security pop-up you get by clicking an ISIN Inventory Manager	Direct	Taken straight from issuer ctry (shown formatted).	United States	yes
Industry classification	`industry`	industry	the security pop-up you get by clicking an ISIN Inventory Manager	Direct	Taken straight from industry classification (shown formatted).	Sovereign	yes
Sector of issuer	`sector`	sector	the security pop-up you get by clicking an ISIN Inventory Manager	Direct	Taken straight from sector of issuer (shown formatted).	Government	yes
Classification Level 4 name	`l4`	l4	the security pop-up you get by clicking an ISIN Inventory Manager	Direct	Taken straight from l4 (shown formatted).	Others	yes
BICS Level 2 Industry Group Name	`bics`	bics	the security pop-up you get by clicking an ISIN Inventory Manager	Direct	Taken straight from bics (shown formatted).	Others	yes
Issuer Industry	`issuerIndustry`	issuerIndustry	the security pop-up you get by clicking an ISIN Inventory Manager	Direct	Taken straight from issuer industry (shown formatted).	GOVT NATIONAL	yes
G7 Industry group	`g7`	g7	the security pop-up you get by clicking an ISIN Inventory Manager	Direct	Taken straight from g7 (shown formatted).	Others	yes
Instrument currency	`ccy`	ccy	the security pop-up you get by clicking an ISIN Inventory Manager	Direct	Taken straight from ccy (shown formatted).	SGD	yes
Coupon	`—`	n/a — worked out	the security pop-up you get by clicking an ISIN Inventory Manager	Computed	Coupon, with the wording around it (shown formatted).	3% · Bullet	yes
Seniority	`seniority`	seniority	the security pop-up you get by clicking an ISIN Inventory Manager	Direct	Taken straight from seniority of bond (shown formatted).	Senior Unsecured	yes
Clearer	`clearer`	clearer	the security pop-up you get by clicking an ISIN Inventory Manager	Direct	Taken straight from clearer (shown formatted).	Fedwire	yes
Issuer rating	`—`	n/a — worked out	the security pop-up you get by clicking an ISIN Inventory Manager	Computed	Issuer rating, with the wording around it (shown formatted).	AA+	yes
Bond rating	`—`	n/a — worked out	the security pop-up you get by clicking an ISIN Inventory Manager	Computed	Bond rating, with the wording around it (shown formatted).	AA+	yes
Bond notional	`—`	n/a — worked out	the security pop-up you get by clicking an ISIN Inventory Manager	Computed	Bond notional (mm) and ccy, with the wording around it (shown formatted).	837.5 mm SGD	yes
MTM of notional	`—`	n/a — worked out	the security pop-up you get by clicking an ISIN Inventory Manager	Computed	Mtm of notional (mm) and ccy, with the wording around it (shown formatted).	826.7 mm SGD (price 98.71)	yes
Issue date	`issueDate`	none yet	the security pop-up you get by clicking an ISIN Inventory Manager	Computed	Worked out before it is shown: Built by the app's instrIssueDate rule (shown formatted).	12 Feb 2027	yes
Trade start	`start`	start	the security pop-up you get by clicking an ISIN Inventory Manager	Direct	Taken straight from start (shown formatted).	25 Sept 2025	yes
Maturity date	`maturity`	maturity	the security pop-up you get by clicking an ISIN Inventory Manager	Direct	Taken straight from maturity (shown formatted).	12 Feb 2030	yes

The cards follow the canonical data catalog (the same master list documented on Requirements 2) — the 15 top-level sets, with the user-maintained set (7) broken out into its eight datasets (7.1–7.8), each its own card. Sets tagged LIVE are wired into the screens today, so uploading + mapping them changes the app immediately. The other sets accept an upload and a saved mapping now; their live wiring is delivered as each set is connected.

📋 Requirements & Test Pack

A build & test specification detailed enough to rebuild a replica of the whole app from scratch. It covers the underlying data, the logic and the interactive behaviour. It is organised into Epics — one per feature area. Each epic opens with a collapsed “About” write-up: expand it for context and key terms. Under that sits a set of User stories — “As a user, I can …”. Every user story is a fold — click its title to open it. Inside a story you get its requirements: the exact fields, formulas, defaults and persistence keys the build must reproduce. At the end of every story is a second fold, 🧪 Test cases. It holds the scenarios that prove that story. Each scenario is a Do step and a Verify step. Use ⊕ Expand all / ⊖ Collapse all above to open or close everything at once. Jump to any epic from the Contents below. Overview 2 (the workspace builder, Epic 9) has its own tab, “Requirements 2 · Overview 2”. This tab (Requirements 1) covers everything else. No prior knowledge of the system is needed.

Scope: the Collateral Optimisation Engine at /j-collateraldemo. It covers Overview (collateral management, with the Inventory Manager inside it), Rules engine, Optimization Results and User maintenance. Overview 2 (the workspace builder) is retired as of 20 Aug 2026 and is NOT being built — its tab stays openable in the demo, and the Data source catalog on the Requirements 2 tab stays live, because the whole app is documented against it. · Last updated: 12 Oct 2026.

📝 Recent change log (click to expand)

The offline standalone app was missing the three designed screens — now it carries them (12 Oct 2026). The Tools tab builds a copy of the app that runs by double-clicking a file, with no server and no internet. Since the designed screens arrived on 01 Oct it had been quietly incomplete: Optimization Rules, Optimization Results and the Triparty AOE dashboard are separate documents, and every frame asked for them by a path starting at the root of the site. Opened from a folder, that path points at the root of the drive, so all three came up as the browser’s “file not found” page inside the frame — with nothing on screen saying why. The build now brings the three screens along, plus the runtime that draws them, and rewrites every one of those paths to point beside the file asking for it. What changes for you: the card lists seven files rather than three, and they all go in the same folder with their names exactly as shown — the screen file names contain spaces. Each designed screen carries its own React runtime inside it, so only one extra runtime file (support.js) travels separately; it has to, because it is the parser for these screens and inlining it makes a screen render its own runtime's source instead of itself. Babel is not in the bundle at all — it is 3MB, and the runtime only reaches for it when a screen is written in JSX, which none of these three are. If downloading is blocked outright, saving just the first three still gives you Overview, Overview 2, the Data screen and the Inventory Manager — only the designed screens go missing. Proved by building the bundle, opening it from a folder with the network switched off, and reaching all three screens plus the Inventory Manager: every one renders, with no page errors and not one request leaving the machine. The .zip pack above was broken the same way, for a different reason. It had the three screen files in it all along, but it flattened every file into one folder — and the app asks for them at aoe/…, so at the root of a flat folder there was no aoe and nothing could be found. collat-inventory.js and the runtime libraries were not in it at all, which also cost the Overview its tab strip. The pack now keeps the folders this site serves — aoe/ and vendor/ — carries all 14 files, and spells out the .html on its own routes so a plain static server finds them too. Unzip it, serve the folder, open j-collateraldemo.html. Also corrected on this page: the Rules engine epic still called itself a “standalone tab”, which it has not been since 01 Oct.
Requirements 1 now carries every Overview function as a “when I…, then…” user story (06 Oct 2026). Every story heading on US1.2 and Epics 2–8 and 10 now reads “As a user, when I X, then Y”. Developer stories read “As a developer, when I build X, then Y”. Two Overview functions had no story and now do. US2.8 — Optimization Results from the sidebar, with its Proposed allocation / Run views switch. US2.9 — the note under the agreement list, with its three exact wordings. Epic 4 is rewritten for Triparty AOE. The T+N ladder was retired on 01 Oct, and this page still described it. Four claims were wrong against the running app and are corrected. Granularity is Daily / Monthly / Yearly, not daily / weekly / monthly. The maturing presets are 7d / 30d / 90d / 180d / 1Y, not 90d / 180d / 365d. The sidebar names are Bilateral CSA IM and Bilateral CSA VM, not BIM and BVM. The dock has no “Optimization (Rules engine)” view; that line is removed from the views checklist. One thing on screen did change. The Proposed allocation / Run views switch on Optimization Results had no click handler, so Run views could never open. The two buttons now switch as the 01 Oct entry already said they did.
Three things this page said about User maintenance were out of date (04 Oct 2026). Found while checking the whole spec against the running app, and corrected here. One — the sub-tab strip is eight, not six. The “All six sub-tabs are there, in this order…” line listed Cost of funds, G7 industry group, Source of collateral, Special agreements, Adjusting exposures and Adjusting inventory, and left out G7 by bond and Tags & highlights — both of which are on the strip and both of which have their own epic further down this page. Two — the G7 industry group table has five columns, not four. Epic 14 said the first three were system-provided; Issuer Country was added and is the fourth, so the user fills the fifth. Its column checklist was missing that row too. Three — six rows are seeded, not two. Epic 14 named only Finance / XYZ_IND_GRP / GOVT NATIONAL and Government Owned, No Guarantee / Airlines / TRANS - NON RAIL. The table actually starts with six sample rows plus the catch-all, and every one of the six already carries a G7 group, so the screen does not open empty. All six are now listed with their country and their group. Nothing on any screen changed — only what this page claims about them.
Second Claude Design hand-over: the rule builder reads your own data, and triparty ranking gained nested tiers (02 Oct 2026). One — Real or Dummy, per clause. Every rule clause on Rules setup — one condition line inside a rule — now has a Data dropdown beside the data topic: Real is the live data feed, Dummy is the rows you keep yourself under User maintenance — Adjusting exposures, Adjusting inventory, dummy agreements and dummy eligibility sets. Pick Dummy and the Values box stops being a box you type into and becomes a pick list of your own records, added as small tags with + Add and removed with ×. The clause line carries a DUMMY badge so you can see at a glance which half of a rule is test data. A condition whose topic has no rows yet does not go quiet — it names the screen to add them on, e.g. “No dummy agreements for this tab. Create them in User Maintenance › Dummy agreements.” Two — the run carries the test data forward. Whatever those Dummy conditions actually match is worked out when you press Run and is carried into the run, so Optimisation results opens with a User-maintained data used in this run card and tags those allocations TEST DATA. Nothing is tagged when every condition is Real. Three — nested tiers on the eligibility-set ranking. The triparty set priority was a row of tags you nudged left and right. It is now a list: each set has an Include tick box, ▲▼ to move it up and down, and — the new part — its own + Then by rows, so you say how inventory is ranked within that one set (bond amount largest first, then cost cheapest first…) rather than once for the whole run. The eligibility-set table gains an Include, G7 Industry Group and Accepts column, and the sets are renamed Set 1 · EU Govs & Credit through Set 6 · Wide. The plain-English story under the ladder reads the whole thing back to you: “Fill Set 1 · EU Govs & Credit with EU Govs, Credit bonds by largest first. If still short, fill Set 2 · Gilts…” Four — triparty says RQV, not margin call. On the Triparty side of the switch the screen relabels the margin-call wording to RQV — Required Value, the amount of collateral the triparty agent asks you to hold, which is what a triparty desk calls the thing a bilateral desk calls a margin call. Bilateral & CCP is unchanged. Switching sides now also keeps each side’s rules separately instead of carrying one set across both. Five — the triparty ladder is a real calendar. Triparty AOE ran five columns labelled “Day 0…Day 4”. It now runs 15 business days from today with real dates (02 Oct, 05 Oct, 06 Oct…), weekends skipped, matching the Inventory Manager’s labels, and the short warning reads “Euroclear · from 06 Oct → 22 Oct (13 business days) · need 250, have 200”. Each triparty profile also expands by currency — the RQV is held in its own currency and every total is shown as a USD equivalent — the amount converted into US dollars — labelled as such. Six — the code pack is nine files, not eight: dummy-seed.js joins it, which is what seeds one sample agreement, exposure and inventory row so the Dummy pick lists are not empty on a browser that has never opened the app before. It never overwrites a row you entered yourself.
The rest of the Claude Design hand-over is in: the G7 screen, the code download, the designed screens fill the tab (01 Oct 2026). Four things the first pass missed. One — G7 industry group gains the treatment G7 by bond already had: an Issuer Country column, a search box over every column, four filters (Classification Level 4 name, BICS Level 2 Industry Group Name, Issuer Industry, Issuer Country), a tick box per row and a bulk apply — tick several rows, type one G7 industry group, set them all at once, or clear them. The starting table goes from 3 rows to 7 and arrives already classified. The CSV download and upload carry Issuer Country too, and an upload of the older four-column file still matches. Two — Rules setup and Optimisation results now fill the tab. They were opening through the shell’s ?only= embed, which put two more frames in the chain, and each inner frame sized itself against its own viewport — so the screen came out as a small inset box. The Overview sidebar now opens each designed screen directly. Three — Optimisation results has two run views: Proposed allocation (the designed screen) and Run views (the older tables), switched at the top. Four — the Triparty dashboard is on the Overview’s own Triparty filter, where it belongs: pick Triparty under Agreements and the view that was T+N Settlement Ladder is now Triparty AOE. The short-lived Triparty entry under Rules Engine is gone. The Tools tab also gains Full prototype code — one button that packs all eight files of the prototype into collateral-optimisation-prototype.zip, plus a download per file.
Optimization Rules, Optimization Results, Triparty and User maintenance are reached from the Overview sidebar only (01 Oct 2026). Those four had a top-level tab AND a door in the Overview page’s own left sidebar, which meant the same screen was offered twice from two different places. The tabs are gone. The Rules Engine group in the Overview sidebar now reads Optimization Rules, Optimization Results and Triparty, and User Maintenance stays under Maintenance. Each still full-bleed-embeds the real screen (?only=rules, ?only=optresults, ?only=triparty, ?only=usermaint) rather than carrying a second copy of it, so a rule edited through one door is the rule every other door shows. Triparty had no sidebar entry at all — it was only ever reachable from the tab — so one was added beside the other two; without it, removing the tab would have made the screen unreachable. Two things had to change for this to work: activateTab() used to give up when no tab button matched, which would have left every one of those doors rendering a blank page, and the ?only=rules embed used to haul the old Optimisation Results section up into the rules panel, which now sits under the designed screen as leftovers from the previous build. Both fixed. The tab strip keeps Overview, Overview 2, Data, Requirements 1, Requirements 2, UAT test cases, Open questions and Tools.
Rules engine, Optimization Results and a new Triparty tab now show the screens as designed (01 Oct 2026). Three screens were handed over from Claude Design and are now what those tabs open: Rules setup (the scope-of-optimisation ladder — defining inputs, scoping eligible inventory, ranking, with its own Bilateral & CCP / Triparty switch), Optimisation results (proposed allocation, with a Needs action section that lets a desk accept, accept-partial or reject each procurement proposal, and an insert-allocation row) and Triparty AOE (eligibility sets, concentration limits and the agreements-static read-only view), which gets a tab of its own beside Optimization Results. They are served as their own documents under /aoe/ and framed by the shell, so the design can be handed back and forth unchanged. The previous build of the first two screens is still in the page, hidden, and can be put back by removing one attribute. They talk to the shell rather than navigating: pressing Run on Rules setup, or Optimise to cover on Triparty, posts a message up and the shell switches to Optimisation Results carrying the run and the Bilateral/Triparty scope. What is not yet joined up: these screens carry their own worked example of the book, so the agreements, bonds and allocations on them are the design’s figures, not the ones the rest of the app derives; and their run picker reads a run store the app does not write yet, so it offers its own three runs rather than yours. The G7 industry grouping IS live — it reads the same mapping your Data screen writes. Joining the rest to the app’s own book is the next piece of work, not something this change claims to have done.
The whole app moves onto the AOE design system, and opens light (01 Oct 2026). Every screen — Overview, Overview 2, the Rules engine, Optimization Results, User maintenance, the Data screen and the Inventory Manager — is now drawn from one named set of colours, type sizes and spacing steps instead of each surface carrying its own. The page sits on a light grey (#F5F7F9) with white cards; the one accent colour is red (#FF3E3E), used for the thing you are on and the button that commits; green, amber and a brighter red are kept for good / watch / bad and mean nothing else. Text is Public Sans at three weights, labels stop shouting in small uppercase and read as ordinary sentence-case grey, and every card, input and button takes its padding and corner from the same short list of steps, so two screens built months apart now line up. The app opens light. It used to open dark; the design system is drawn light-first, so that is the state you now land in. Dark is still there on the toggle and every screen works in it. The theme you pick is remembered under a new name (collat-theme-ds2), so your first visit after this change starts fresh on light rather than inheriting the old dark preference. Nothing on any screen moved, was added or was taken away — this change is only how it all looks.
A ranking rule now carries its own sub-rule, and ranking rules finally decide the run (28 Sep 2026). New story US11.22, plus §11.4 for the two checklists it adds.

One — the preference has two halves, and the screen now holds both. A desk saying “take corporate paper first, then supranational — and within each of those, the biggest line” was saying two different things. The first half is an order of kinds, which the Ranking group already held. The second half says what to do once the engine is inside one of those kinds and several lines qualify, and there was nowhere to put it: written as a rule of its own it reads as if it governed the whole book, which is not what was meant. It is now a sub-rule carried on the ranking rule itself, drawn indented under the ordered list it belongs to, in the same edit panel. It offers two choices — none, and biggest inventory line first. The run’s four matching strategies are deliberately not repeated on it: they are set once, on the matching-strategy rule, and line size is the one ordering that rule could never express.

Two — ranking rules are now read by the optimiser. They were not. The engine ordered the eligible pool by the run’s matching-strategy rule alone, so Rule 1 – Asset Class rank and Rule 2 – Industry rank sat switched on in every run and changed nothing. The engine now reads, in order: each ranking rule’s bucket order in library priority, that rule’s sub-rule where two lines share a bucket, and the matching strategy as the final tie-break. A run’s answer moves as a result, because the rules that were being ignored now apply.

Three — ranking rules can be built from scratch. Setting Group to Ranking in + New Rule now opens the bucket order and its sub-rule, where before it fell back to the single-condition editor. An existing rule still keeps whatever editor its kind calls for, so moving a scoping rule into the Ranking group does not silently turn it into a bucket order.

Four — the sub-rule is visible without opening the rule. List mode prints a within each: … pill after the numbered order; Visual and Overview read Rank: A › B › C · then …. Ranking still never overrules eligibility: it reorders lines that already passed the issuer-group, asset-class and rating tests, and admits none that did not.
Special CSA became Special agreements; the tag now decides everything; an agreement is found before it is added; and every maintenance screen’s explanation is folded away (18 Sep 2026). Four changes to User maintenance (§16, plus §2.4 for the blotter filter and §12 for the fold).

One — the screen is named for what it holds. The sub-tab ⭐ Special CSA is now ⭐ Special agreements, and its heading with it. The list was never CSA-only — it has always offered every agreement name the app puts on screen, of every agreement type. The name said otherwise, so it was changed. The two tags keep their names: Zero-interest CSA and Korean CSA name CSA flavours, and what a tag MEANS is the user’s business. Nothing already maintained is lost — the same collat-csa-list holds it.

Two — the tag is the whole instruction, and the “Exclude from the app” tick box is gone. Tag an agreement Korean CSA and it is dropped from the app; that is what the tick box did, and ticking it was saying the same thing twice. Tag it Zero-interest CSA and it stays and becomes filterable on the dashboards. The tag drop-down names the effect beside each tag, the count line under the table counts effects rather than tags (“3 agreements · 1 dropped from the app · 2 filterable on the dashboards”), and the file is two columns now, Agreement name and Tag — an older file’s third Exclude column still uploads, read as the Korean CSA tag. Anything already excluded arrives tagged Korean CSA. The blotter’s Special agreement picker consequently offers only the tags that SELECT agreements: Korean CSA is never an option there, because those agreements are out of the book and the option could only come back empty, and Any special agreement now appears only when more than one filtering tag is in use.

Three — the screen is ONE table: query an agreement, see what it is, tag it. The flat drop-down of agreement codes is gone, and so is the second table it fed. Every agreement the app knows is a row, with a search box, an Agreement type filter, a Tag filter and Clear filters above it, and the columns Agreement name, Agreement type, Counterparty and Tag — the Tag drop-down sitting on the row itself, because setting a tag IS the job of this screen and nothing else on it is editable. An agreement is on the list precisely when it carries a tag; clearing the tag takes it off, so the list and the tags can never tell different stories. Tagged rows are always drawn first, tinted, so what the user has already marked is what the screen opens on, and the Tag filter narrows to them however large the book gets. A code like CSG_Amberlaine Bank_RIM does not say whether it is a CSA or a futures book, so the type and the counterparty sit beside every name; the Overview publishes them alongside it on collat-agreement-names. The user is never asked which screen a name belongs to — the names still arrive grouped by screen behind the scenes, because the app has two naming schemes, but that is the system’s concern and is neither shown nor filtered on.

Four — the explanation on every maintenance screen is folded away. All eight sub-tabs open with their paragraph of explanation closed behind one ℹ️ How this works toggle under the heading. The copy is unchanged and one tap away. The user’s words: “can u hide all those chunks of descriptions that u r explaining to me”.
Exclude CSA became Special CSA: one agreement list, maintained for two things (17 Sep 2026). The User maintenance sub-tab 🚫 Exclude CSA is now ⭐ Special CSA (§16). It is still the same list of agreements. What changed is how much it says about each one. Per agreement the user now sets a Tag — Zero-interest CSA or Korean CSA, or none — and ticks Exclude from the app or leaves it clear. A row may carry either, both or just the one. Excluding still does exactly what it did: the agreement is dropped from the individual-agreement views. It simply sits on the same row as the tag now. A tagged agreement is a special CSA. The list saves to collat-csa-list, and anything already on collat-exclude-csa is carried over once as rows with Exclude ticked.

Three things read it. First, the Overview’s bond-postings panel gained a Special CSA drop-down beside “Maturing only ≤ N days”. It shows on Postings, Postings by bonds and Bonds Maturing. Its options are the maintained list itself. First All agreements, then Any special CSA, then one option per tag in use. It stacks with every other filter. Second, the CSA VM sidebar’s Zero-interest only button. That button is not new, but zero-interest is no longer generated. It used to be about one agreement in three, decided by a fixed rule. It is now whatever the user tagged Zero-interest CSA here, so zero-interest is stated in one place only. Nothing is zero-interest until somebody says so. Third, the exclusions, as before.

The agreement drop-down is now grouped by screen. The app has two agreement naming schemes and both are headed “Agreement name” somewhere. Bond postings holds the names the blotter shows (CSG_Amberlaine Bank_RIM, GSG_JPM_VM …). Individual agreements holds the names the Detailed list shows (BVM-001, and Triparty’s counterparties). The Overview publishes both as it loads, under collat-agreement-names. Keeping them apart stops a row being maintained against a name the filter it was meant for never sees. Written up in US2.4 and §16.
The G7 industry group can now be set on one bond at a time (16 Sep 2026). The mapping table answers for a whole Issuer Industry at once, which is the right default and the wrong answer for the odd bond. A new User maintenance sub-tab, 🔖 G7 by bond (§14a), lists every bond in the securities static file — ISIN, Bond Name, Issuer Name, Issuer Country — beside the classification it carries, and lets the G7 industry group be typed on the bond itself. There is a search box, four filters and a bulk bar, so one value can be applied to many ISINs in one action, and a download / upload round trip for doing it in Excel. It stores the exceptions only: an untouched bond still follows the mapping table and still moves with it. A bond set by hand reads its own group on the instrument pop-up and moves into that slice of the G7 donut, on the Overview and in the Inventory Manager alike. A group named only on one bond still creates its Cost-of-funds rows. One correction came with it: the pop-up's Issuer Industry used to read the matched row's value, so an unmatched bond called itself "Others" when it is a corporate. It now reads the bond's own classification, which is what the match is made on.
The book is big enough to compare models on, and the research book is gone (16 Sep 2026). The models were being compared on a book of their own, which made the inputs the variable — the opposite of the point. The demo book is the thing that was wrong: it carried 2 lines per issuer industry, so most agreements had only 2–4 eligible bonds and, at a concentration limit of 15–20% of the call per bond, could never be covered whatever the algorithm did. The book now carries 6 per industry — 30 lines, the same total value held in more, smaller positions. Every obligation is now covered in full (100.0%, $1,756.9mm of $1,757.0mm, 36 movements), and the six models separate on what that cover costs to carry: the linear programme is the floor at $1.33mm a year against the engine's $1.38mm, so the greedy shortcut costs about $0.05mm a year. The model panel runs on the run again, with one set of inputs for every model. Every figure on every screen moves with the book: the Requirements Page worked examples, the five views' test cases and the spec twin are re-cut, and the shortfall board now reports a covered run rather than four shortfalls — it still draws its rows the moment a run cannot fill something.
The model research panel gets a book worth comparing models on (16 Sep 2026). Six different algorithms were returning the same answer, which read as broken. It was not: the firm’s book holds several times more eligible collateral than it owes and every obligation is capped out, so there is one allocation to find and all six find it. Algorithms only separate when collateral is scarce. The panel now runs its models over a research book — the same instruments in smaller parcels, each split into a cheaper and a dearer one — under the run’s own rules, obligations and limits, and says on screen that it is a scenario rather than the firm’s position. Nothing else in the app reads it and no figure anywhere else moves. The production row now runs the engine’s own procedure over that same book, so the baseline is the same problem the others are solving. vs engine leads with the cover difference rather than carry, because a model that delivers more cover for more carry is doing better, not worse. And the verdict under the table now decides by whether the models actually separate: it prices the gap to the linear programme, credits what re-ordering the queue alone recovers, and says what whole settlement lots cost — falling back to the old “the algorithm is not the constraint” reading only when the rows really do agree.
The three parts of the tab are named for what they are (16 Sep 2026). Proposed Optimization Results UI leads it — the screen being proposed, and where a user works. UI suggested by AI based on what is available from vendors in the market is the fold holding the approval blotter, benefits scorecard, scenario board, movement map and shortfall board, because that is where those five views came from. Optimization Model Research by AI closes the tab, where a different algorithm can be put over the same inputs. Nothing behaves differently; each part now says what it is.
The two halves of the tab are named for what they are (16 Sep 2026). The panel that leads the tab is titled Proposed Optimization Results UI — it is the screen being proposed, and it is where a user works. The fold beneath it, which holds the approval blotter, benefits scorecard, scenario board, movement map and shortfall board, is titled UI suggested by AI based on what is available from vendors in the market, because that is where those five views came from. Nothing behaves differently; the two now say what they are.
The panel is titled Proposed Optimization Results UI (16 Sep 2026). It leads the tab and is what a user works in, so it now says what it is on its own heading rather than describing its layout. What it does is unchanged; the line beside the title still explains how picking a row works.
The long form is folded away (16 Sep 2026). With the side-by-side panel leading the tab and doing the amending, the four surfaces under it — Summary by bond, Where the bonds are posted today, Internal sources of bonds and Where the bonds are posted to — were saying the same things a second time and pushing the rest of the run off the screen. They now sit behind ▸ The long form, collapsed, one click below the panel. Nothing is removed and nothing behaves differently: open it and every table, drill-down and control is exactly as it was.
Records can be added, not only amended — and a headline by kind of agreement (16 Sep 2026). Adding: each block of the side-by-side panel now carries + Add beside Save and Cancel, and what it offers is still only what exists — a new borrow starts on an inventory line the firm holds and is capped by it; a new recall asks where to recall this bond from and lists the postings of that bond that are out there and not already being called; a new posting starts on an agreement the bond is eligible for and from then on behaves exactly like one the run proposed, carrying that agreement’s call, counterparty, settlement date and custodian, counting towards its coverage, and amendable and removable like any other. The headline: a table now leads the panel with one row per kind of agreement — what it expects to be called for and what the run proposes to post to it — opening into the postings inside it, each naming the individual agreement, its counterparty and the bond, with those names working as doors into the two panes. RULE-55 and RULE-56 added.
What is amended can only be something that exists (16 Sep 2026). Editing let a user type in a desk, a portfolio and a date, which meant they could borrow from somewhere the firm holds nothing. Collateral is not conjured. A borrow is now a draw on an inventory line the firm holds: the row offers the list of lines (ISIN, portfolio, desk, and what it holds) and a box for how much, capped at what the line holds — pick another line, even another bond, and the borrow moves there with that line’s own dates and rate. A recall is a call on collateral that is actually posted out: the block lists every posting of that bond, each reading Being called back or Left where it is, and the decision is which to call, never what is there. A posting can be sent to another agreement the bond is eligible for — the same eligibility the optimiser applies — taking that agreement’s counterparty, expected margin call, settlement date, end date and where it is held with it. What goes OUT is deliberately left uncapped: posting more than the call is a buffer a desk may want. The same lists and the same caps now govern the borrow rows under Summary by bond and on Internal sources of bonds, and the agreement lines under Summary by bond, because it is one record. RULE-53 and RULE-54 added.
The Optimization Results tab gains an Optimisation model panel (16 Sep 2026). The engine is one algorithm, not the only one, and nothing on screen said so. A panel at the bottom of the Optimization Results tab now runs the same run through six models and shows what each proposes. They are the production greedy, cheapest-to-deliver heuristic; a greedy that serves the most-constrained obligation first; a global cost-ranked sweep with no obligation queue; a linear programme solved to optimality, which is the floor nothing can beat; a lot-constrained optimisation that settles in whole lots and states its gap to that floor; and a local search that starts from the engine’s answer and swaps until nothing improves. It is read the way the Rules engine is read — input → process → output — and the input column is identical for every model, because each is handed the same scoped obligations, the same eligible pool and the same limits. Only the process differs. Each model carries what it buys you and what it costs you, its own postings table, and a row in a side-by-side comparison of all six. Under that sits a verdict worked out from the models’ own answers: on today’s run every model lands level, and the panel says why — the eligible book holds far more than is owed, so what binds is the concentration cap, obligation by obligation, not the algorithm. A collapsed fold lists the families considered and not built. Picking a model does not change the run; which model the engine itself should use is raised as OQ-46. See US11.21.
The side-by-side panel gains its three searches and its Edit control (16 Sep 2026). Two things were missing from it. Searching: three boxes now sit above both panes — Search ISIN, Search agreement, Search counterparty — and each narrows both sides at once, because the two sides are one run read two ways: a bond stays listed while any of its lines is with a matching agreement or counterparty, an agreement while any bond meeting it matches the ISIN. Each heading counts what is listed out of what there is, the totals rows follow the rows listed, and the run’s four totals on the strip do not move. Amending: the panel is no longer read-only. Each block carries one ✎ Edit on its own heading, as under Summary by bond, and the unit is the same — the agreement line on the posting blocks, the row itself on the borrow block, and the recall block never editable because it is the state of the book. It writes to the same amendment layer, so a change here moves Summary by bond, the flow tables and the run totals at once, the same margin-call message speaks, and a figure typed back to what the run proposed stops being an amendment. The detail blocks also now carry the same fields as the same blocks under Summary by bond, each with its own heading and its own sideways scroll. And it now leads the tab, directly under the run picker and above Summary by bond, because it answers whichever of the two questions a user arrived with. Written into US11.20 with RULE-51 and RULE-52.
Bonds and agreements, side by side — now titled Proposed Optimization Results UI (14 Sep 2026). Reading the run one grouping at a time meant the other half of the answer was always on the view you were not looking at — a bond feeds many agreements, and an agreement is met by many bonds. A new panel under Where the bonds are posted to puts both groupings up at once: bonds on the left, agreements on the right, sorted worst-covered first. Picking a row on either side turns the other side into just the related records — a bond becomes what was borrowed, what is being recalled and where it is going; an agreement becomes the bonds meeting that one call — and picking it again clears. The side you picked on keeps its full list with the row highlighted, and the names inside the detail are links, so a user can walk bond → agreement → the other bonds on that agreement without touching a filter. The run’s four totals sit on the strip above and never move, so a narrowed pane never reads as a smaller run. Read-only — amendments stay in one place. Written up as US11.20.
Postings are amended at agreement level, with one control and a margin-call check (11 Sep 2026). Editing sat on the posting row — but a posting row is a window, a roll-up of the agreements inside it, and changing a roll-up cannot say which agreement it belongs to. The agreement is now the unit: pressing ✎ Edit on the Posted to heading opens every window and puts the boxes on the agreement lines, and the window figure is whatever those lines add up to. One control, not one per row — the repeated Edit / Propose removal buttons are gone from both lists under a bond, replaced by a single button on each heading with Save and Cancel in its place. The individual agreements are no longer generated for this screen: they are the margin obligations the app already carries, each with its own agreement reference, counterparty and expected margin call, and an agreement’s share of a posting is its own call over its type’s total. Expected Margin Call is now a column on the posting rows and the agreement lines (read-only, and never totalled — it belongs to the agreement, not to one bond), and Amount on the posting leg is renamed Collateral Amount. While the list is being edited, and for as long as any amendment stands, a message names every agreement whose expected margin call is no longer met, measured on collateral value across the whole run — it flags, it never blocks. The flow table of postings is read-only for the same reason and says where to amend. Written up under US11.16 and US11.18.
Where the bonds are posted today — what a full sweep has to recall (11 Sep 2026). Sweep the deck ON re-optimises as if nothing had ever been posted, which means every line already out with a counterparty has to be recalled first — and the screen never said which lines those were or who held them. A new table on Optimization Results now does: one row per line posted out, naming the bond, the agreement and counterparty holding it, where it is held, and the desk and portfolio it came from so it can be put back or re-posted from the same place, with its market value and its collateral value after haircut. The line under the heading says what this run does with them — recalled in full on a Sweep-ON run, left in place on a Sweep-OFF one. The existing-postings book (catalogue set 14) is no longer empty. It had been left deliberately unpopulated, which meant a Sweep-OFF run had nothing to retain and behaved exactly like a Sweep-ON one. It is now derived from the book itself — each agreement holds a few lines drawn from the same inventory the optimiser posts from, and only lines its own eligibility schedule accepts, so it can never contradict the rule the engine enforces. Sweep OFF now genuinely retains: the run log’s retained and pledged figures are the table’s own two totals ($1,158.83mm and $1,173.48mm over 19 lines), and the requirement still to cover drops from $1,757.0mm to $598.2mm. Sweep-ON runs are unchanged. Written up under US11.16a.
A posting is split by agreement window, and a bond’s lines can be amended from the bond (11 Sep 2026). “Bilateral CSA IM” is a kind of contract, not a contract: the firm signs many, each with its own end date and settlement terms, so one posting to a type does not all settle on one day. Where the bonds are posted to now carries one row per window — an agreement type plus one settlement date and one end date — so the same type appears several times for one bond with different dates. The posting is split across the windows by the share of the book each holds, exactly, to the cent. Opening a Posted to row under Summary by bond now shows a third level, Agreements in this window, naming the exact agreements and what each takes (counterparties for Triparty, which is never booked under standalone codes). And because production holds thousands of movements, every line under a bond now carries the same Edit and Propose removal the flow tables carry, writing to the same amendment layer — amend a line from the bond and the flat table shows it amended, because it is one record, not a copy. A line proposed for removal stays listed under its bond so the removal can be undone there, and stops counting towards Borrowed, Posted and the totals. Written up under US11.16 and US11.18.
Tags & highlights — put your own colour on anything in the book (11 Sep 2026). A seventh User maintenance dataset, 🏷 Tags & highlights. A tag names one value of one attribute — a bond ISIN, a portfolio, a desk, and the rest of the book’s text attributes — gives it a name and a colour, and every trade carrying that value is then highlighted in that colour in the Inventory Manager, on both Column display and Time series of inventory. The user tags a value, never a row, so a portfolio tagged once paints every trade in it. Matching is exact and ignores case; a half-typed value colours nothing. Nothing is filtered or hidden — counts, totals and sort order are untouched — and a coloured row says on hover which tag put it there. A change on the maintenance screen repaints an Inventory Manager that is already open. The Pivot table is not coloured, because its rows are roll-ups of many trades rather than one. Written up under EPIC 18a.
The pool now borrows more of a bond than it posts (11 Sep 2026). Summary by bond showed Borrowed and Posted as the same figure on every line, because both legs were reading one allocation, which made the table’s own question — how much of each bond we borrow, and how much of it we post — meaningless. The source leg now carries a real borrow: the postings that line supports, plus the run’s haircut buffer, rounded up to a whole million and capped at what the line holds on the snapshot date. What is borrowed and not posted is headroom left in the pool, not a shortfall. Nothing is typed in — the postings, the buffer and the line’s market value all come off the run, so the gap moves on its own when any of them changes. Today XS9Z40G1NNE9 reads $87.00mm borrowed against $86.55mm posted, and the run totals $1,290.70mm against $1,782.60mm. Written up under US11.16, “How much the pool borrows”.
The Optimisation Results view moved to the bottom of the Optimization Results tab (11 Sep 2026). The run’s answer — run log, summary figures, the one search box, the per-agreement cards, the two charts and Full posting detail — used to sit in a drawer at the bottom of the Rules engine tab, one tab away from the flow tables and the five views that read the same run. It now sits at the bottom of the Optimization Results tab, under those views, so everything one run produced reads on one screen. The Rules engine drawer keeps Inputs and Run-order; pressing ▶ Run (or clicking the flow canvas’s output box) moves you to the Optimization Results tab and scrolls there, so the run log animates in view. It is the same one screen moved, not a second copy — US11.9 still governs its search, its paging and which population each total covers.
Triparty postings carry Profile Name and Set (9 Sep 2026). Triparty collateral is held by the agent rather than booked under an agreement code, so the agent labels every allocation with the eligibility schedule it allocated against and the set it allocated into. Both are now columns on Postings, Bonds Maturing and Postings by bonds, sitting immediately after Custodian, and shown only while Triparty is the agreement selected — every other agreement type has neither. They are properties of one allocation, so they are never rolled up: where Postings by bonds adds a bond’s allocations into one row, the cell reports how many distinct values that row covers (“2 sets”, named in full on hover) instead of showing one as if it stood for all. Written up under US2.4, with the column checklist and the not-aggregated rule.
A summary by bond, and a run picker that says when the run was run (9 Sep 2026). The two flow tables answer “what is moving” one movement at a time, but not “what is happening to this bond”. Summary by bond now leads the screen: one row per ISIN with Borrowed and Posted side by side, sortable, filterable, with a totals row. Every row opens to show the lines behind both figures — Borrowed from (desk, portfolio, direction, amount, dates, rate) and Posted to (agreement, destination, direction, amount, dates, rate) — and closes again; Collapse all closes every open row. It is built from the same rows the two tables show, so an amendment moves it in step. On today’s demo data Borrowed equals Posted for every bond, because the built-in optimiser draws exactly what it posts; the gap appears when the two legs come from your own files, which are separate uploads. Above all of it sits a Run picker listing every saved run, each labelled with its name and the date and time it was last run; choosing one redraws the whole screen and stamps it as run now, and it is the same active run the Rules engine uses. Runs saved before the stamp existed are stamped on first load, so none is unlabelled. Written up as US11.18 and US11.19 with test cases RULE-43 to RULE-47.
Optimization Results now leads with the two flow tables, and a run can be amended (9 Sep 2026). The screen opened on five views of a proposal but never said the plainest thing about it: which desk the bond comes from, and which agreement it goes to. It now leads with Internal sources of bonds (ISIN, Desk (Source), Portfolio (Source), Direction, Amount, Start Date, End Date, Rate) and Where the bonds are posted to (ISIN, Agreement (Destination), Destination, Direction, Amount, Start Date, End Date, Rate) — the two legs of one movement, read off the run the engine published so neither can disagree with it. Both carry the Overview table treatment: sortable headings with a direction arrow, a filter box under every heading, and a totals row that adds up what the filters left rather than the whole run. The five views the screen used to start with are parked underneath, in a fold headed “UI suggested by AI based on what is available from vendors in the market”. Rows can now be amended: proposed for removal, edited, or added from scratch, with every row carrying one of four statuses — System proposed, User edited, User added, Proposed for removal — so an amendment is never mistaken for the engine’s answer. A removal is struck through rather than hidden, amendments are held per run and survive a reload, and Reset to system proposal returns one table to exactly what the engine proposed. Both tables are catalog sets 12.1 and 12.2, so real data can be uploaded and mapped for them like any other set; each falls back to the run on its own. Written up as US11.16 and US11.17 with test cases RULE-36 to RULE-42. A second defect fixed on the way: the single-tab embed activated its tab before modules in LATER script blocks existed, so ?only=data failed the same way ?only=usermaint did — it now waits for the whole document to parse.
User maintenance opens from the Overview sidebar, and Adjusting exposures gains Original Exposure (9 Sep 2026). The six datasets on the User maintenance screen decide figures the Overview shows, but reaching them meant leaving the Overview for a tab at the top of the app. The Overview sidebar now carries a Maintenance heading with one entry, User Maintenance, which fills the working area with the same screen the tab shows — the third door built this way, after Optimization Rules and Optimization Results, and never a second look-alike. Written up as US2.7 with test cases OVW-25 to OVW-27. Separately, Adjusting exposures now carries an Original Exposure column, sitting between Agreement name and Adjusted Exposure in USD, so an adjustment can be read against the figure it is adjusting; the dataset is six fields now rather than five, on screen, on upload, and in the data catalog (set 7.5). One defect fixed on the way: the single-tab embed used by all three sidebar doors reached its tab’s module before that module existed, which worked for the Rules engine and failed for anything declared later — it now activates the tab once the page’s modules are all defined.
Data models for what the optimiser produces (9 Sep 2026). The three optimisation data sets were slots with no field structure, so nothing the Rules engine or the Optimization Results screens show could be traced to a column, and none of it could be fed from your own system. Optimization outputs (data set 12) and Optimization exclusions & exceptions (data set 13) are now modelled field by field — 9 columns and 14 columns respectively — written up as Data model 12 in detail and Data model 13 in detail on the Requirements 2 tab, and both are uploadable and mappable on the Data tab exactly like every other set. Data set 12 is one row per proposed movement; data set 13 is one row per exception across four categories, with the shortfall columns filled in on the not-fully-covered rows only. Optimization rules (data set 11) stays deliberately fileless: the user sets the rules and runs on the Rules engine screen and what they set is the data, so its card now says so instead of offering a mapping that will never come. The Data tab’s “What the Optimization Results screen reads” card no longer claims the screen needs no new data — it now sets out the two ways to feed it, the app’s own run or your uploaded run. Test case DATA-11 updated. Two open items: which file is the master list for the run reference, which both new sets carry, and OQ-45 (the field check still covers the Overview and Inventory screens only).
New screen: Optimization Results, five views of one run (26 Aug 2026). The optimiser produced a proposal that could be read but not acted on, compared or chased. There is now an Optimization Results screen, reachable from its own tab and from the Optimization Results entry in the Overview’s left-hand menu under Rules Engine — the same screen through two doors, never two copies. It carries 01 Approval blotter (accept, hold or reject each proposed movement, then release the accepted set), 02 Benefits scorecard (six figures making the case for the run), 03 Scenario board (every saved run side by side against doing nothing, with a button to promote the winner), 04 Movement map (which inventory line feeds which agreement) and 05 Shortfall board (what could not be covered, and the rule that blocked it). No view recomputes anything: they all read the answer the Rules engine published, so a screen can never disagree with the run that made it. The blotter and the shortfall board are searched and paged, and every total covers the whole match rather than the visible page. Written up as US11.10–US11.15 with test cases RULE-23 to RULE-35, and the Data tab records that the screen needs no new data from you.
The run’s results now survive a book with thousands of agreements (26 Aug 2026). The results view drew one card per agreement and one row per posting, with nothing to narrow or page them — fine at seven agreements, unusable at several thousand. It now carries one search box above the cards that narrows the cards and the posting table together, paging on each list (eight cards, twenty-five rows), and an honest count on both. Every total is added up over all the matching postings rather than the rows on screen, so the total row does not move when you turn the page; the summary figures at the top still measure the whole run. A card matching only part of its agreement now reads “1 of 4 postings match” instead of a coverage percentage that could not be worked out from a subset. The Ignore button on the agreement cards also works now — it was drawn but never wired, so clicking it did nothing. Written up as US11.9, with the volume contract developers must build to.
The reporting currency is recorded as one setting for the whole Singapore entity (26 Aug 2026). You asked why the app carries a Reporting currency column when no screen appeared to use it. It does use it — the Bond postings table heads three of its columns Posted (USD), Allocated (USD) and Unallocated (USD), and every money figure prints a dollar sign, all of it typed into the app rather than read from that column. Your answer — “it’s for the whole SG entity, so just leave as is” — is now recorded: the Data tab lists it as settled instead of asking about it, the data dictionary says it is set once for the entity, and the postings note tells developers to take both the headings and the dollar sign from that one setting so changing it re-labels every screen. Nothing changed on screen.
The app no longer keeps a table of values you cannot supply (24 Aug 2026). You said the eligibility table’s three values — the minimum rating accepted, the collateral types accepted and the counterparty — come from the agreement static data, so all three are now columns on Agreements static. That rating floor was the one you found by hand weeks ago, and it was the last value the app decided with that no file could reach. You also said the Concentration limits group name belongs there — it already did: the card was reading a piece of the screen’s own HTML as if it were the rule, and reporting markup instead of naming the column. Same for Limit. 159 fields, 157 with a column. The two left are genuine calculations you may want to check: Expected post and Expected collect.
The two agreement thresholds now come off the agreement, and stopped printing every currency as dollars (24 Aug 2026). You said ABC threshold and Cpty threshold come from the agreement static data. They do — and the agreement record was already carrying both. The Margin Call Calculation card was working them out again from a separate table of type-level cushions, which is why two different fields showed the same number on every agreement, and why a EUR 18M threshold printed as “$18.0M” and a SGD 25M one as “$25.0M”. Both rows now read the agreement’s own figure, in its own currency, and both are columns on Agreements static. Separately, the Instrument Name on the Bond inventory table is mastered on Bond / securities static, which now carries it. 159 fields, 155 with a column — four left, all of them figures the app genuinely works out.
A helper’s name is not a rule — and the app’s shorthand for your columns now traces (24 Aug 2026). Looking at “Agreement — The rule: Built by the app’s agLabel rule” you asked what you were supposed to do with it. Nothing: that is a name inside the code. The card now reads the function and reports what it produces, so the Agreement column says it is taken from the agreement’s name, off the agreements list. Separately you asked whether Total exposure comes from the exposure / margin-call file — it does: the app stores it as oblig and that file carries it spelled out as Obligation. A screen label, a stored name and a column name are allowed to differ, so the card now follows that pointer instead of treating it as a missing field. One wrong statement was removed with them: name is the agreement on one table and the instrument on another, and the security pop-up had been claiming it showed an agreement. 159 fields, 151 with a column — up from 143 — and 8 left that the app works out.
Rules now say what they mean, and the fields that sit on more than one file are listed (24 Aug 2026). Reading “The app’s own mc value, with the plus or minus sign dropped” against Margin call / surplus, you said you could not follow it — and that the margin call is listed per agreement on the exposure / margin-call file. Both were right: the application’s own note on that line says read, not re-derived. Exposures & margin calls gained a Margin call column, and the card now follows a working name inside a rule to what it stands for, so that line reads “Margin call multiplied by the agreement’s share, with the plus or minus sign dropped”. Compound rules that used to read “worked out from more than one stored value” are now stated in words. Separately, the card answers your question about one field living on several files. Ten of them do — read off every file, not just the ones that reach a screen, which is why the count went from seven to ten. Each is listed with every file that offers it, the label that file gives it and whether it is that file’s own key, so you can name the master from the line itself. The list is split into waiting on you and settled, and only the waiting half asks anything: you said the security code is mastered on Bond / securities static, and that a counterparty code and a currency code sharing the name “code” is not something to worry about — both are recorded, so neither is asked again. Eight are still open. The rule to build to is stated with them — the identifier travels on every file, the description is held once: a holdings row carries the security’s code so the app can find it, and everything else about that security is read from the file that owns it. No screen changed.
Every value on every screen now has somewhere in your file to come from — and the “worked out by a rule” list was partly wrong (24 Aug 2026). Going down the Data tab’s remaining call-outs you placed the agreement pop-up’s terms on Agreements static, which gained Margin type, Valuation frequency, Reciprocity, Issuer sector, Time zone, ABC MTA, Counterparty MTA, Notification time, Resolution time, Interest calc method and Interest / rebate rate. Checking those answers exposed a fault in the card itself: it was reading punctuation inside seeded text as arithmetic, so a value stored as “Min / Max”, “Initial Margin (IM)” or “America/New_York” was reported as a figure the app works out, and a comma inside a stored phrase cut the value in half. It was also mistaking a column heading for the rule behind the value under it. Ten fields moved out of that list as a result — several of them vary per agreement (IM / VM / Repo, New York / Singapore), so “the same words on every row” was never true of them. 159 fields, 142 with a column, none left without one. No screen changed: nothing was added to, removed from or renamed on any view.
The last four values with nowhere to come from now have a column (24 Aug 2026). You answered the Data tab’s remaining call-outs, so the values were added to the cards you named. Agreements static gained Custodian — which clears both the Custodian column on the Bond postings table and the Clearer line in the security pop-up on the Overview, because that pop-up fills Clearer from the custodian. The same card’s eligibility-schedule Currency field was already there under a different name, so it is now keyed to what the app stores it as and simply maps — nothing was added for it. Inventory data gained Holding, and Bond / securities static gained Issuer Industry. That last one also answers open question 6 in §E.14: issuer classification is a security attribute, so the bond carries its Issuer Industry on set 2 and the app matches on it to find the bond’s row of the G7 industry-group mapping table (7.2) — nothing about it sits on Counterparty static (1). Every field on every screen now has somewhere in your file to come from: 121 of the 159 have a column, and the remaining 38 are values the app works out or writes itself. No screen changed: nothing was added to, removed from or renamed on any view.
The Data tab now names the chart or table a field is on, not just the screen (24 Aug 2026). Every call-out and every row of the Every field on the screens card used to locate a field as “on Overview”. The Overview carries five tables and three pop-ups, so that left you to go and find the field before you could answer anything about it. Each line now says exactly where to look — the Bond postings table, the Agreement summary table, the Trade contributions drill-down, the security pop-up, or the individual card inside the agreement pop-up (Exposure, Call Schedule, Eligibility schedule and the rest) — with the screen name after it. The names are read out of the application itself, so a heading renamed on a screen cannot leave a stale name behind here. No screen changed: nothing was added to, removed from or renamed on any view.
The three ids the demo was inventing now come from your files (23 Aug 2026). The Data tab had called out three references the demo makes up so the screens have something to show — the Trade # on a collateral line, the ISIN, and the Trade ID on the agreement pop-up’s Trades tab. You said which file carries each one, so Collateral used data gained a Trade # column: it was the only one of the three no card carried, because ISIN was already on Bond / securities static and Trade ID on MX Trades Data. The Collateral used data dictionary on Requirements 2 now documents Trade # alongside the other columns of a collateral line, and the Data tab lists all three under References your files carry instead of as questions — the demo still shows a made-up number on screen, and in production your column replaces it. No screen changed: nothing was added to, removed from or renamed on any view.
Every field on the screens now traces to data you can supply — and the fields nothing showed are gone (21 Aug 2026). You went through the Data tab's call-outs and said where each value comes from, so the values were added to the cards you named. Agreements static gained the agreement terms the detail pop-up shows (agreement end date, benchmark rate, the two rounding rules, holiday centre(s), settlement delay, calculation rule, interest settlement date, allow negative rate) and the whole concentration-limit record — group name, limit type, granularity, limit, limit unit and basis, which had been half on the card and half nowhere. Currency static gained base currency. Exposures & margin calls gained dispute age. G7 industry group and Source of collateral now declare the fields the screens read from them — they stay maintained on User maintenance, not uploaded here. And a new data set 16 · MX Trades Data was added for the agreement pop-up's Trades tab, which was showing figures that traced to nothing. It carries every column that tab shows — Trade ID, Product, Trade date, Maturity, Notional, Ccy and MtM (USD) — because everything on the Overview belongs on the Data tab, so a field that is on screen never waits to be asked about. What came off: the app was building nine lists of agreement fields it never put on any screen — 53 fields in total, including a Remaining Posting Capacity card and a Trade Contribution card. They were being counted as data for you to supply. They are deleted, and OQ-41 closes with them. The old four-column agreement utilisation table (Current util. with its day / week / month change pills) went the same way — it had been off the Overview for some time with its columns left behind. Nothing changed on any screen. The Data tab's field inventory now reads 0 fields that do not trace, down from 38.
Overview 2 is retired — kept usable, not being built (20 Aug 2026). The workspace builder stays in the demo so it can still be opened and clicked through, but it is out of scope for the build. Requirements 2 · Overview 2 and UAT test cases · Overview 2 both now open with a notice saying so, so a developer or tester cannot start on it by accident. The two Overview 2 handoff cards on the Tools page carry the same notice. Two things are deliberately not retired with it: the Data source catalog and The data models this app uses on the Requirements 2 tab, and the Data lineage matrix on the UAT tab. Those describe the master data sets the whole application runs on — this tab links to the catalog from every field it documents — and they only ever happened to live on those tabs. Nothing else was lost: Overview 2 showed no field the Overview does not already show. See the notice on each tab.
The Data tab is scoped to the Overview only (20 Aug 2026). Overview 2 is being retired, so the Data tab must only ask for data the screens you actually use need. Nothing had to be taken off it. The workspace builder never needed a field of its own — its widgets draw the Overview’s own tables, charts and popups, and it reads no data by itself. Driving both screens and comparing found no field on Overview 2 that is not already on the Overview; the Overview shows 19 more than it does, from the Margin Calls panel and the settlement ladder. So the field counts are unchanged: 225 fields, 109 traced, 42 not traced, 74 made up by the demo. What did change is the wording — every row on the Every field on the screens card used to be labelled “Overview & Overview 2” and now reads Overview, so the card never asks you to supply data for a screen you have stopped using. A test now fails if Overview 2 is named there again, or if a third screen is added without saying so.
The Overview’s Optimization Rules is now the Rules engine itself (20 Aug 2026). The Overview sidebar entry Rules Engine → Optimization Rules used to open a screen of its own — a fixed list of seven rules and six ranking criteria that could be read but never changed, and that ran nothing. It has been replaced by the real Rules engine, the same screen as the Rules engine tab at the top of the app, filling the Overview’s working area with the sidebar still beside it. It is the same tool in both places: the same saved runs, the same rules, the same run parameters, the same results — a run made in one is already in the other. This is how the Overview 2 “Rules engine” widget has always worked, so all three doors now open one screen. ▶ Optimize posting on an in-call agreement popup still opens it, but the old “🎯 Optimizing posting for [agreement]” banner is gone: the engine covers the whole book in a run, so a banner promising one agreement would have been telling you something the screen does not do. See US2.5.
The Rules engine has a fourth view: ⚠ Exceptions (12 Aug 2026). The view toggle now has four settings, not three. ⚠ Exceptions sits after ▦ Overview and answers one question — what did this run NOT use, and why. It lists four things, each with its own count: inventory the run’s rules held out, with the reason for each line; margin calls and agreements the same rules held out; obligations the run could not fully cover, with the shortfall; and missing or invalid values in the data the run reads. Nothing on the view is stored. It is worked out fresh from the run you have selected each time you open it, so it can never disagree with the run. Each section shows at most 100 rows and then says exactly how many more there are — nothing is cut short silently. A section with nothing to report says so, and is never padded. See US11.7.
The Rules engine has a Sweep the deck setting (12 Aug 2026). A new run parameter, saved with each run, next to the concentration cap, minimum transfer amount, rounding and haircut buffer. On (the default) assumes everything currently posted is clawed back, so each obligation is re-covered in full from the whole pool — this is what the engine has always done. Off leaves existing postings where they are: each obligation only needs the difference making up, and collateral already pledged out is not offered again. The figures for what is already posted come from Collateral used data (set 14), which is not loaded yet — so a Sweep-off run currently retains nothing and behaves like a Sweep-on run. It says so in the run log and raises it as an exception, rather than letting the two settings look identical for no visible reason. See US11.8.
The Inventory Manager moved into the Overview (12 Aug 2026). It is no longer a top tab. Open the Overview tab, then click Inventory Manager in the left sidebar, under the new Inventory heading. The Overview’s filter bar, charts and postings table are replaced by the Inventory Manager, filling the screen. Click any agreement, any sub-book, or any other sidebar entry to come straight back. It is the same Inventory Manager page as before, with all three views, and nothing inside it changed. The Overview 2 Inventory Manager widget, the Adjusting inventory screen and the Rules engine are untouched. The theme now travels two steps. The shell tells the Overview, and the Overview tells the Inventory Manager. Light and dark still follow the toggle.
The Inventory Manager has a third view: Pivot table (12 Aug 2026). The View toggle now has three settings, not two. The new Pivot table shows the same trades as the other two views, added up instead of listed, laid out the way the Overview’s T+N Settlement Ladder is laid out — a section per group, a row per category, one column per business day, and a Total line closing each section. You choose all three axes. Group by sets the section headings, Row by sets the rows, and Value sets which amount the cells add up. Every field of the Column display view is available: the fifteen text fields can be grouped by — including both ratings, Instrument Ccy, Issuer Country and Industry Classification (the bond type) — and the two amount fields, Bond Notional and MTM of Notional, are what the cells can count. The pickers are built from the Column display column list itself, so the two can never disagree and a field added there shows up here automatically. Neither grouping offers the field the other is using. It opens on Clearer × Issuer Country counting Bond Notional, and remembers all three choices. Group by can also be set to None, which removes the section layer entirely and leaves one flat table with a single Total line over the whole book — the quickest way to check that re-slicing has not changed the amount of book. Both grouping lists offer the same fifteen fields, with nothing withheld from either, and the same field may be used on both axes. No new field was added to the book — the amounts are the same day-by-day holdings the Time series view shows, converted to US dollars. One thing was flagged, not fixed: four of the offered groupings (Instrument Name, ISIN, Issuer Name, Callable / Coupon) are near-unique per holding, so the spec now requires the production build to page or cap the sections and rows rather than draw a row per trade, and to fetch the figures already totalled instead of adding up the whole book in the browser. Written up as US10.4, with eight test cases (INV-06 to INV-13).
Postings by bonds has a new Dirty Price column (12 Aug 2026). Bond prices are quoted clean, leaving out the interest earned since the last coupon. The new column adds that interest back, which is what a buyer actually pays: Dirty Price = clean price + accrued interest, per 100 of face. It uses the same clean price the instrument window shows — that price was pulled out into one shared routine so the window and the column can never drift apart — plus the coupon rate and maturity date already on the record. It is on Postings by bonds only; Postings, Bonds Maturing and the exposure drill are untouched. There is deliberately no column total, since averaging prices across different bonds means nothing. Two assumptions are flagged for the BA: the book does not record how often a bond pays, nor its day-count rule — both are still “to be provided” on the instrument window — so the column assumes semi-annual coupons and actual/actual day count. Both should be confirmed, and ideally become real fields, before production. Written up under US2.4, with two test cases (OVW-08e and OVW-08f).
The “Total posted” line now equals Total posted (08 Aug 2026). On the Overview’s Collateral utilisation history chart, the green line labelled Total posted was drawn 10% higher than the real figure. The comment in the code called it a demo over-collateralisation buffer. So the chart disagreed with the Total posting card and with the Agreement summary table, which both showed the true amount. The buffer is gone. The line is now the posted total itself, read straight off the record. It lands exactly on top of the Bonds + Cash bars. A line drawn above those bars is now a defect. This closes OQ-10, which had already asked for it. Note the Overview 2 chart is different, and is unchanged. There the bars are Total allocated, not Total posting, so its Total posted line does sit above the bars and the gap is the Unallocated figure. That is correct and stays. One new open question was raised. OQ-41 — on the agreement detail, Headroom to capacity limit assumes the limit is 130% of the obligation, for every agreement. No agreement carries that term. It is shown in green or red, so it tells you that you are near a limit that cannot be checked against anything. Also tidied. The two CCP sub-book covers added on 08 Aug are now written as plain values in CCP_COVER, the same way every other book carries its own cover. No figure moved.
The agreements now show four different margin-call situations, not one (08 Aug 2026). Every agreement used to allocate more than its margin call. So one whole situation could never be seen on screen, or tested. The sample data is now spread on purpose, and each agreement sits in a different place. The four situations. One. Over-posted, with collateral left over. Total allocated is less than Total posting, and the margin call is negative, meaning collateral can be collected back. That is Bilateral CSA VM, GMSLA, CCP and Triparty. Two. Over-posted, but the threshold soaks it up, so nothing is left unallocated. Total allocated equals Total posting and the call is still negative. That is Triparty · BNY Mellon. Three. A call is due and everything posted is allocated against it, and it still covers the call. That is GMRA, Bilateral CSA IM and Triparty · Clearstream. Four — the new one. The call is bigger than everything the agreement has posted. Allocating every dollar still falls short, so Surplus goes negative. That is Futures, and Bilateral CSA IM · Clearstream when you pick that custodian on its own. Worked example — Futures at 18 Jun 2026. Call / obligation $141.8M. Total posting $64.7M. Total allocated $64.7M, because you cannot allocate more than you posted. Margin call $77.2M. Surplus is Total allocated minus Margin call, so $64.7M − $77.2M = −$12.5M, shown in red. The sub-book toggles now differ too. The two IM custodians used to be near-identical on these figures. So did the CCP IM and VM books, and the three Triparty agents. Each pair or trio is now on a different side of full cover. Switching between them changes the situation, not just the size. Only sample values moved. No column, field, card or rule changed. The generation dials are listed in the developer section of Requirements 2 · Overview 2.
Every agreement now posts the same three bonds (08 Aug 2026). Each agreement sub-book holds exactly three bond postings. They are one US Government bond, one Singapore Government bond and one corporate bond. Before, each book held two postings, drawn from that agreement’s own bond-type weights. So the mix differed from book to book. Now it is the same three types everywhere. All three are pledged as at the reference date. A posting whose pledge would already have ended now runs on to the bond’s maturity instead. So Postings by bonds shows three rows for every agreement, never one or two. No total moves. Each sub-book’s posting target is unchanged, and simply split across three postings instead of two. Corporate bonds are now accepted everywhere. Bilateral CSA IM, GMSLA and Futures previously accepted Cash and Government bonds only. Corporate is now on their accept-list too. Without that, their corporate posting would have no eligibility card to sit under. The eligibility cards would then stop adding up to Total posting. Their agreement detail Eligibility schedule therefore gains a third card, Corp. The Rules engine accept-lists are unchanged. They are a separate maintained data set. They still read Cash and Government for those three.
One instrument window on both screens (07 Aug 2026). Click an ISIN or an instrument name anywhere. The pop-up now shows the same fields, in the same order, on the Overview and in the Inventory Manager. It follows the Inventory Manager’s list. That is Instrument name, ISIN, Issuer, Issuer country, Industry classification and Sector of issuer. Then Instrument currency, Coupon, Seniority, Clearer, Issuer rating and Bond rating. Then Bond notional, MTM of notional, Trade start, Maturity date and Deal status. The four classification fields now sit on both windows, directly under Sector of issuer. They are Classification Level 4 name, BICS Level 2 Industry Group Name, Issuer Industry and G7 Industry group. The Overview window’s old lines are all still there, in the new look. Type and Issue date are back as real fields, and now show on both screens. Type sits under Issuer; Issue date sits just above Trade start. Currency is now called Instrument currency, and Instrument rating is now called Bond rating — same fields, the Inventory Manager’s names. The “to be provided” block is the same five fields on both screens. Every money figure on the window can be checked. US8.4 says where each one comes from, and how to prove it.
Margin call is now read from the margin-call data, not worked out on screen (07 Aug 2026). The screen used to calculate the margin call itself, as Call / obligation minus Total posting. It did that as it drew each row. It no longer does. The margin call is a figure the business strikes and records. It belongs to the Exposures & margin calls data, catalog set 10. So it is now stored on the record for that agreement and date, and simply read. That is exactly how Received (in) already worked. Every surface reads the one stored figure. That covers the Agreement summary, the detailed table and the agreement detail popup. It also covers the Margin Calls view and the Rules engine’s shortfall note. Each of those used to do its own subtraction. No figure on screen changes value. In the sample data the call is struck as that day’s position, so it still comes to the same number. What changed is where it comes from, and it matters for the build. The production system must take the margin call from the margin-call data. It must never recompute it from what is displayed. The recorded call and that subtraction may one day disagree — a disputed call, a minimum transfer amount, a different cut-off. The recorded figure then wins, and the screen must show it. Figures worked out from the margin call are unaffected. Surplus, Expected post and Expected collect still derive from it.
Surplus was the wrong way round — it is now Total allocated − Margin call (07 Aug 2026, closes OQ-26). The two figures had been subtracted in the wrong order. So every row showed its own posting with a minus sign in front of it. Bilateral CSA VM read −$259.4M on a row where $34.1M was in fact spare. Surplus is what is left of the collateral allocated, once the margin call has been met. The margin call is signed positive when we have to post. So allocating $100M against a call of $50M leaves $50M spare. Mind the sign. A negative margin call means nothing has to go out, and it can be collected back. Subtracting it therefore adds to the surplus. Bilateral CSA VM now reads $225.2M − (−$34.1M) = $259.3M. Every surface computes it through the one shared rule. So the summary table, the detailed table and the total row cannot disagree. Nothing else moved. Total allocated, Unallocated, Margin call and the posting figures are unchanged.
“Used” renamed to “Allocated” everywhere on screen (07 Aug 2026). The figure showing how much posted collateral is consumed covering the exposure is now called Allocated. The Bond postings summary table column is Total allocated. Its two companion columns are Bonds (Allocated) and Cash (Allocated). The change columns read DoD / WoW / MoM (total allocated). The Key-figures cards read Total allocated, Bonds allocated and Cash allocated. The Over time chart’s two stacked bar series read Bonds (allocated) and Cash (allocated). The Agreements widget’s column legend reads Agreement · Posted · Allocated · Unallocated. Every tooltip follows: Unallocated = Total posting − Total allocated, and Surplus = Total allocated − Margin call. Only the wording changed. No figure, formula, column order or column choice was altered. Unallocated keeps its name, which now reads directly against Allocated. The Collateral used data set, data model 14, keeps its name. That is the name of the source data, not of the worked-out figure.
The posting and allocated columns now sit under a spanning two-row header (07 Aug 2026). On the Agreement summary table the six posting and allocated columns are no longer six headings in a row. The header is two rows deep. The upper row carries one centred heading, Total Posting, across the three columns it owns. Total Allocated spans its own three. The lower row names them Total · Bonds (Posted) · Cash (Posted) and Total · Bonds (Allocated) · Cash (Allocated). The first column under each heading is now just Total. The heading above already says which total it is. The ↳ arrow that used to mark the bonds and cash columns as sub-rows is gone. The heading does that job now. Everything else about them is unchanged. They are the same six columns, in the same order, with the same figures. Sort, filter, hide, reorder and pin behave exactly as before. Sometimes a column has to be named on its own. That happens in the column chooser, the filter title, and the Figure check sheet. It is then written as heading plus column, for example Total Posting · Total. Hiding or moving part of a group shrinks the heading. It then spans only the columns still sitting together. So it can never span a column that does not belong to it.
Every user story is now a fold, with its test cases folded inside it (07 Aug 2026). Each user story on this tab opens and closes on click. Its requirements sit directly inside it. Its scenarios now sit in a 🧪 Test cases fold at the end of that story. They no longer run on flat underneath it. New ⊕ Expand all and ⊖ Collapse all buttons sit at the top of the tab. They open or close every fold at once. Following a link to a story opens the folds it sits inside, so a link never lands on hidden text. Every story now carries test cases. Scenarios were written for the eight that had none: US1.3, US2.3, US3.2, US6.2, US6.3, US8.2, US11.4 and US12.1. The two instrument-modal field lists moved from US8.3 to US8.2, the story that owns them. Collapsed folds are still captured by select-all, so copy-paste is unchanged.
Duplicate field write-ups replaced with links, and every sentence cut to 20 words or fewer (07 Aug 2026). A field set is now written up once, under the story that owns it. Other stories that use the same fields link back, and record only what differs. US7.2's Collateral Posted columns were a verbatim copy of US2.4's postings columns; so were US18.1's inventory fields of US10.3's. Both are now pointers. The owning lists gained an “also used in …” line, naming every other story that reads them. So a change can be traced both ways. Separately, every sentence on this tab was cut to 20 words or fewer. Long ones were split, or turned into a list where the sentence was really an enumeration. The change log below is now one bullet per entry. No field, column, figure, filter or rule changed in any of this.
Instrument card now shows the bond’s G7 classification, and every bond maps back to the mapping table (07 Aug 2026). The Overview instrument detail card shows four more fields directly under Type. They are Classification Level 4 name and BICS Level 2 Industry Group Name. Then Issuer Industry and G7 Industry group. All four are read off one row of the User maintenance → G7 industry group table (§14). Matching is on the bond’s Issuer Industry. A bond that matches no row takes the table’s last row — the catch-all, where every column is the default. The same rule now classifies every bond on the Bond collateral by G7 industry group donut. It also classifies the solo By bond type chart. It replaces the old built-in default list. So a group can never appear on a chart or a card unless it is a value in that table. See §8 and §14.
Cost of funds rebuilt to the agreed file format (07 Aug 2026). The first column is now Security Type. Its values are the distinct G7 industry groups the team maintains on the G7 industry group screen. That screen is driven by the Bloomberg industry codes. An Others catch-all row is now always present, whatever the mapping says. The optimisation process falls back to it for a bond whose security type it does not recognise. All 4 fields are mandatory. A row still missing a rate is outlined in amber, and counted under the table. The upload is now all-or-nothing, and reports every problem. It no longer quietly ignores rows it cannot use. Four problems are each listed in a red box. A row on screen that the file leaves out. A Security Type that is not set up, with a pointer to fix the G7 mapping first. A currency outside the currency static list. And a blank or non-numeric rate. Nothing is applied until the file is clean. The exception handling is written down and implemented once. No matching security type means the Others row. A currency not in the table means a cost of funds of 0. New stories US13.1–US13.4, tests COF-01…COF-14, plus a figure-provenance table and a volume contract. A repeated row is also rejected and named. That means the same Security Type and Currency twice. It was not in the emailed rules, so it was raised as OQ-40. The user decided the same day: reject it and flag it out. Raised as OQ-39. The Rules engine's Cost (bps) column still comes from a built-in table, by asset class and rating. It does not come from this maintained set.
Selecting an agreement now narrows the Bond postings blotter to that agreement (07 Aug 2026). Selecting an individual agreement highlighted its name and put a chip above the table. But the Postings and Bonds Maturing blotters carried on listing every agreement’s postings. The chip said GMRA-002 while the rows underneath were everybody. The blotter is now narrowed to the postings the selected agreement holds. A bond posting is booked at agreement-type level. So an individual agreement holds its share of its type’s postings. The Agreement summary, the key figures, the agreement detail screen and Postings by bonds already give it that share. The blotter therefore keeps that type’s postings. It shows the agreement’s share of Original Amount, Posted (USD) and Allocated (USD). Two agreements of the same type hold their shares added together. Selecting all of a type’s agreements comes back to the type’s own total. A booking / portfolio code such as CSG_Amberlaine Bank_RIM behaves differently. It comes from the blotter’s own Agreement Name column, and is recorded on the postings themselves. So it matches its rows exactly, and keeps their full amounts. Triparty collateral sits with the agent. So selecting a Triparty counterparty narrows to its agent’s postings, and its share inside that agent’s book. The panel title names the agreement (“Bond postings — GMRA-002”) and the line under it ends “— GMRA-002’s share”. The Summary and Detailed agreement lists are still never hidden, so the next agreement to Ctrl+click is still there. Updated story: US2.6; new tests OVW-16/17/18.
One definition of Surplus everywhere; the margin-call column is renamed (07 Aug 2026). “Surplus” used to be written two different ways in this document. The on-screen note said what was posted minus what was used. An older appendix said what was received minus what was utilised. There is now one rule, on the Overview and Overview 2 alike: Surplus = Total posting − Total used. The app works Total used and Surplus out in a single shared place. So the two screens can never drift apart. Received (in) is information only — it is displayed, and it never feeds Surplus or any other worked-out figure. The agreement summary column “Total margin call” is renamed “Margin call”. That applies at both the Summary and the Detailed level. Its meaning is unchanged: Call / obligation − Total posting. Positive means deliver collateral; negative means collect it back. This closes open question OQ-18 / Gap Log GAP-01. No figure on screen changes value. The received-based Surplus only survived in a table already taken off the Overview.
Unallocated and Surplus are now two different figures; the margin-call column is renamed (07 Aug 2026). The leftover figure used to be called Surplus. It was written two different ways in this document. The on-screen note said what was posted minus what was used. An older appendix said what was received minus what was utilised. That is settled, and the naming changed with it. There are now two figures, each with one rule. Both are applied the same way on the Overview and on Overview 2. Unallocated = Total posting − Total used — the collateral posted but not consumed. That is the figure previously called Surplus. It is the same rule the postings screens have always applied to each bond line. The second is a new Surplus = Margin call − Total used. Both are columns on Agreement summary and Agreement summary — detailed. Postings, Postings by bonds and Bonds Maturing keep Unallocated (USD) = Posted (USD) − Allocated (USD). That is the same rule, one bond posting at a time. The key-figures card and the Overview 2 Agreements widget column that read Surplus now read Unallocated — same figure, corrected name. The app works Total used, Unallocated and Surplus out in one shared place, so no two screens can drift apart. Received (in) is information only. It is displayed and totalled. It never feeds Unallocated, Surplus, the margin call or any other worked-out figure. The agreement summary column “Total margin call” is renamed “Margin call” at both levels. Its meaning is unchanged: Call / obligation − Total posting. Positive means deliver collateral; negative means collect it back. Closes open questions OQ-17 and OQ-18, and Gap Log GAP-01. Raises OQ-26 on the new Surplus figure, which comes out large and negative on every agreement.
Clicking an agreement name now SELECTS it; the ↗ arrow opens its details (06 Aug 2026). On the Overview tab, an individual agreement name used to open the detail popup. It is now a selector. Clicking the name selects that agreement. It becomes a solid highlighted pill, plus a removable chip above the table. Ctrl+click — Cmd on a Mac — adds or removes one while keeping the others. Clicking a lone selected name clears it. The detail popup moved to a small ↗ arrow beside every individual agreement name. Selecting never hides rows — the list stays exactly as it was, so a second agreement is still there to Ctrl+click. This closes a dead end. Postings by bonds asked you to “select an agreement”, but the Overview tab had no way to select one. Only the Overview 2 Agreements widget could. Clicking one name now fills that view in. It no longer requires the sidebar to be narrowed to that agreement’s type first. With two or more selected it reads “N agreements selected — this view shows one at a time”. Overview 2 workspace widgets are unchanged. There the Agreements widget is the selector. The name still opens the popup, and no arrow is shown. New stories/tests: US2.6, OVW-13/14/15.
Every column on the agreement summary table now has a total (04 Aug 2026). The total row used to leave Received (in) and Surplus showing a dash. Dispute Age and Base CCY were left completely blank. Yet the Received and Surplus figures were already on the key-figures cards directly above the table. Every column now carries a total. Received (in) and Surplus now add their rows up. They match the Received (inbound) and Surplus cards exactly. The same two dashes on the Overview “Obligation & posting by agreement” table were filled in the same way. Dispute Age is a number of days, so adding it up would be meaningless. Its total row shows the oldest open dispute instead. That is the figure the desk acts on. Base CCY shows the base currency when every row shares one. When they do not, it shows an amber “Mixed”. That is also a warning about the two columns next to it: Base Total Exp. and Base Call Amt are stated in each agreement’s own currency. On a mixed selection their totals add different currencies together. That pre-existing issue is now visible rather than silent; how it should be presented is an open question
OQ-28).
LRP column removed from the agreement summary table (04 Aug 2026). The LRP column has been taken off the docked Summary / Detailed agreement table, at the user’s request. That covers Overview and Overview 2. It is no longer offered in that table’s column picker. LRP is unchanged everywhere else. The Margin Calls view of the same table still has its LRP column. The agreement detail popup still shows it. “LRP” as a funding source name in the Source-of-collateral list is a different thing entirely, and is untouched. No figure changes — only which columns that one table offers.
On-screen how-to text removed from the app (04 Aug 2026). At the user’s request, the explanatory copy has been taken out of the application itself. That copy told you how to read and use the screens. It covered the page footer. That held the demo-data disclaimer, the “Utilisation = …” and “Coverage = …” definitions, and the filter and click instructions. It covered the Overview 2 workspace-builder toolbar sentence. It covered the instructions on every chart and table. Those read “click a bar / click a header to sort / ⏷ to filter / ⚙ to show-hide”. It covered the column-meaning explanations under the postings blotter, and on the agreement detail Postings tab. It covered the “Illustrative demo data” disclaimers, and the equivalent lines on the Inventory Manager. One short line stays on screen. It says what is being shown, as at which date, and in what units — e.g. “Bond collateral by source as at 2026-06-18”, “Summary by agreement type, as at 2026-06-18” — plus empty-state and row-count messages. No figure, column, filter or control changed; only the words around them. The instructions still live in these Requirements pages, which is where the explanation belongs.
Statement Status column removed from the agreement summary table (04 Aug 2026). The Statement Status column has been taken off the docked Summary / Detailed agreement table. That covers Overview and Overview 2. It was removed at the user’s request. It is no longer offered in that table’s column picker either. Statement Status is unchanged everywhere else it appears. The Margin Calls view of the same table still carries it. It still shows on the agreement detail popup. Nothing about the underlying data changes — only which columns that one table offers.
Used is worked out agreement by agreement (04 Aug 2026). The Total used, Bonds used and Cash used key figures used to come from the grand totals. They took the smaller of all the collateral posted and all the exposure. That let a surplus on one agreement quietly cover a shortfall on another. So the cards did not agree with the summary table underneath them. They read about $2,095m against the $2,040m the rows added to. Used is now worked out one agreement at a time. Each agreement can only use what it posted, capped by what it owes. Those amounts are then added up. So the cards, the summary table, the Agreements panel and the Over time chart all show the same figure. Surplus moves with it, from about $25m to about $80m. Once each agreement is measured on its own, there is genuinely more posted-but-unused collateral. Nothing about the posted figures changes.
Money Market Funds removed from the list of securities (03 Aug 2026). MMF is no longer an accepted collateral type anywhere in the application. It has been taken out of every agreement’s accept-list and eligibility schedule. Bilateral CSA VM, GMRA and Triparty previously accepted it. It has been taken out of the Bond static data reference input. That input now carries two collateral classes, Govt and Corp, instead of three. It has been taken out of the agreement detail eligibility schedule. The violet MMF card and its chip are gone, so the cards are now Cash · Govt · Corp. It has also gone from the optimiser’s ranking and allocation chart. And from the user-maintained cost-of-funds bucket, now “Cash”, and the desk-preferred HQLA list. Nothing else moves. No inventory line was ever a money-market fund. So no posted figure, coverage percentage or total changes. Only the list of what an agreement could accept gets shorter. The accept-list is also used as an exclusion, in the “No equities” rule. MMF has been dropped from its value too. The /j-tool handoff brief and its repo twin, and the agreement-detail design skeleton, were updated in the same change.
Review-sized demo data — every type kept, two of each (03 Aug 2026). There was far too much dummy data on screen to check any figure by hand. So the demo book was cut right down, while keeping every agreement type. There are now 2 individual agreements of each of the 7 agreement types. Triparty is the exception: it carries 2 counterparties per triparty agent, so 6 in all. That way every agent keeps its own book. Previously there were 100 per coded type, and all 111 counterparties under Triparty. There are 2 bond trades of each of the 5 issuer industries, so 10 in total. Before there were 130 randomly-drawn trades. And there are 2 bond postings per agreement sub-book, against 3 to 16 before. No total moves. Each agreement type’s requirement is unchanged, and simply split across two rows. Each sub-book’s posting target is unchanged, and simply split across two postings. Each remaining bond trade is correspondingly larger, so the book’s total value stays in its usual range. Otherwise the calls could not be covered. Every agreement would then show a shortfall that was an artefact of the row count, not of the logic. Each of the three is a single build number. They are INDIV_PER_TYPE, PER_INDUSTRY and POSTINGS_PER_BOOK. So repopulating with more dummy data later is a one-number change per dataset. The trade sizes self-adjust. Known consequence to expect on the Rules engine. Multiply the number of eligible inventory lines by the concentration limit. A margin call can only be fully covered when that reaches 100%. With two trades per issuer industry, some agreements now report a shortfall. They are the ones whose eligibility schedule accepts only one or two issuer groups. Bilateral CSA VM and Futures take Sovereign only. CCP takes Sovereign and Agency. GMSLA has a 15% limit. That is arithmetic, not a defect. Raise the run’s Concentration cap parameter, or raise PER_INDUSTRY, to see them covered again.
Recommendations now respect each agreement’s eligible issuer groups (03 Aug 2026). The Rules engine used to decide what could be posted from the broad asset class alone. That meant “government bond”, “corporate bond”, “cash” or “money-market fund”. It lumped sovereign, supranational and agency paper together. It now also applies the issuer group each agreement’s eligibility schedule actually names, using the G7 industry grouping (Sovereign · Supranational · Agency · Financial Institutions · Corporates). Take an agreement that accepts supranational issuers only. It can no longer be covered with a corporate or sovereign bond, however cheap. Three things are visible on screen. The Agreements input drawer has a new Eligible issuer groups (G7) column. Each agreement’s block in the run log states its eligible groups, and how many inventory lines survived the eligibility tests. And every recommended posting names the issuer group it came from. The fill itself is unchanged in spirit, and is now spelled out in US11.6. Eligible holdings are ranked. Each one then contributes the smaller of three figures. Those are what is still needed, what it has left, and the concentration boundary. That runs until the call is covered. If eligible holdings run out, the log reports the shortfall. It never substitutes ineligible paper. One thing was also fixed in the same change. A run could emit a queue of $0.0mm postings, and a spurious “short $0.0mm”. That happened when the last unmet sliver of a call was smaller than the rounding increment. A residual that cannot be delivered now counts as covered. There is no new data source. Eligible groups come from the agreement’s existing eligibility schedule. Holding groups come from the existing G7 industry group mapping table in User maintenance.
Concentration limit — one stored value, shown in both the agreement pop-up and the Rules engine (03 Aug 2026). An agreement’s concentration limit caps how much collateral may come from one grouping — e.g. 20% per issuer country. It is now held as one record per agreement, in a single store. Both places that show it read that record. Those are the individual-agreement detail pop-up, whose Concentration risk strip is unchanged on screen, and the Rules engine. In the Rules engine, open the Agreements input with “↗ click to view”. Each agreement now shows a Concentration limit column. It gives the limit value, the type, and the grouping it is measured over — e.g. “20% Max · Per Issuer Country”, “15% Max · Per Common Code”), with the full scope (asset class, asset type, issuer sector, issuer country, basis) on hover. The two views read the same stored value, so they can no longer disagree. The optimiser now respects that same limit as each agreement’s posting boundary. It caps a line at the smaller of the run’s Concentration cap and the agreement’s own limit. Values: most types 20% Max per issuer country; GMSLA 15% Max per common code; Futures 100% Max; Triparty 20% Min/Max. The run’s own “Concentration cap (% per line)” parameter is a separate optimiser knob and is unchanged. Documented on Requirements 1 (US6.3 pop-up, and the Rules-engine scoping/boundary note) and Requirements 2 (data catalog set 6). No new field was invented. The same concentration-limit fields already existed on the pop-up. They are now stored once, and surfaced in the Rules engine too.
Bond postings — “Unique Bonds” is renamed “Postings by bonds”, and it now needs one subject picked (29 Jul 2026). The view was renamed. It now answers for one subject at a time. That is either one individual agreement of a non-Triparty type (e.g. GMRA-002, picked in the Overview 2 Agreements widget). Or it is one triparty agent — Triparty with only Euroclear, only Clearstream or only BNY Mellon left on. The button itself is never hidden, so the view is always discoverable. Until one of those is picked it shows no rows. In place of the table it asks for the pick: “Select an agreement to see the bonds posted to it”. It does not list everything instead. A group of agreements does not answer “which bonds are posted to this one”. It then lists the bonds posted to exactly that subject. For an agreement it shows one row per bond. Every row reads that agreement. Every amount is that agreement’s share of its type’s book. It is the same share the summary rows and the key figures give it. The key figures now scale to it on this view too. For an agent it shows one row per agreement and bond of that agent. Those totals still match the Postings view. Widening the selection brings the message back. The row is the bond, not a posting. So the view drops two Postings columns. Agreement Name would only repeat the one agreement selected. Trade # cannot describe a bond with several postings. It groups strictly by bond, pivot-table style. The row count moves to the ISIN footer, as “N bonds”. To make that aggregation visible, the demo book was adjusted. 7 of its bond postings are now second postings of a bond already posted to the same agreement. They were split out of existing lines, so every total is unchanged — e.g. SGE5TU515VF4 under Clearstream, $20.31M + $30.17M shown here as one $50.48M row. No new column, filter or figure was added.
Design system applied — new look, same screens (29 Jul 2026). The whole app now follows the supplied design specification. That covers Colours, Buttons, Widget Cards, and Dialogs & Overlays. In plain terms, the dark theme moved to a deep blue-grey canvas, with slightly lighter cards. Body text is white, and labels are a soft blue-grey. The primary blue marks anything you can act on: buttons, the selected option in a group, and active states. A brighter blue marks links. Green marks success. Orange marks warnings, and now also titles every card and widget header in capitals. Red is reserved for errors and destructive actions. Every button is the same size and shape: 26 pixels tall, small rounded corners, and a bold 13-pixel white label. Secondary buttons are slate blue. Disabled ones are dark and dimmed. Cards, inputs and widget frames use the same small corner radius. Pop-ups and dialogs use a larger one, with a slate hairline border. The screen behind a full-screen panel is dimmed and blurred. Widgets on the workspace sit 6 pixels apart instead of 10. Everything is set in the Public Sans typeface. Nothing on any screen changed apart from how it looks. No field, column, filter, control, tile or figure was added, removed or recalculated.
The blotter follows the agreement picked in the Agreements widget (29 Jul 2026). On Overview 2, pick one individual agreement in the Agreements widget. That is a counterparty under Triparty, or an agreement code under any other type. It now narrows the linked Bond postings widget to that agreement. Its Detailed view and its Margin Calls view at individual level show that agreement and nothing else. So the Agreement column reads the same counterparty you picked. The Key figures strip above the table scales to that agreement, so the cards still tie to the row. Picking the type again, ← Summary, All agreements or ✕ Clear widens it back. The bond-level views keep listing the whole type. Those are Postings, Unique Bonds and Bonds Maturing. Collateral is posted at agreement-type level, so there is no per-counterparty posting line to narrow to. No new column, filter or figure was added.
Triparty drills to counterparties, not TRI-nnn codes (29 Jul 2026). Triparty business is not booked under standalone agreement codes. The collateral sits with a triparty agent — Euroclear, Clearstream or BNY Mellon. Each agent administers the counterparties whose collateral it holds. Drilling Triparty now lists those counterparty names. It no longer shows the old “TRI-001, TRI-002 …” placeholders. That applies in the Overview 2 Agreements widget. It applies in the Overview Summary → Detailed and Margin Calls tables. And in the User-maintenance Exclude CSA and Adjusting exposures drop-downs. Each counterparty belongs to exactly one agent. So switching an agent off takes its counterparties out of the list. The shorter list still adds back to the agent’s own Posted. A counterparty’s own figure does not move when a different agent is toggled. The agreement-detail popup now shows the one agent that handles it, under “Triparty / custodian”. No new column, filter or figure was added.
Bond postings — new “Unique Bonds” view (29 Jul 2026). The docked bond-postings panel gains a Unique Bonds view, next to Postings. Postings lists every posting. So a bond posted to the same agreement on several dates appears once per date. Unique Bonds shows one row per agreement and bond, or per triparty repo agent and bond. It gives the unique bonds posted to that agreement. For each it shows how much is posted, allocated and unallocated, plus the rest of the bond’s details. Those postings are added together. Start date is the earliest of them, and Trade # is that posting’s. It uses the same columns, date window and cross-filters as Postings. It opens sorted by Agreement Name. The column totals are unchanged, because grouping moves no money. A triparty repo agent is treated like an agreement of any other type, because it holds its own bonds. The Custodian column now names the agent correctly on Triparty rows. BNY Mellon rows previously read “Clearstream”, which was wrong. No new column or figure was added.
Agreements widget — per-type sub-filters (29 Jul 2026). The Overview 2 Agreements widget now offers the same sub-filters the Overview sidebar has. They are specific to each agreement type, and appear under the type you select. Bilateral CSA IM gets Euroclear and Clearstream. Bilateral CSA VM gets Zero-interest only. CCP gets IM and VM. Triparty gets Euroclear, Clearstream and BNY Mellon. GMRA, GMSLA and Futures have none, being single-book types. Book buttons start on. They can be switched off one at a time, but never the last one. Switching one off re-works that type’s Posted, Used and Surplus from the books left on. It also re-works its individual agreements, and every same-colour Receiver. The parts always add back to the whole book. “Zero-interest only” narrows the individual CSA VM list to the flagged agreements. The filter is remembered per colour group, and resets when a different type is picked or ✕ Clear is used. No new field, column or figure was introduced — these are the existing sidebar sub-filters surfaced in the widget. Documented on Requirements 2 · Overview 2 (US9.5, US9.7 field table, the verification table and the widget lineage) and tested by TC-9.4.6 → TC-9.4.8.
Bond postings — the amount fields, and the Unallocated view retired (29 Jul 2026). The bond-postings blotter now carries all five amount fields together, at the end of the row. They are Original Ccy, renamed from “Collateral Ccy”, and Original Amount. Then Posted (USD), Allocated (USD) and Unallocated (USD). So a posting can be read end to end on one line — e.g. Original Ccy SGD, Original Amount 1,000,000, Posted (USD) 700,000, Allocated (USD) 500,000, Unallocated (USD) 200,000 (posted minus allocated). Original Amount now shows what was POSTED, in the instrument’s own currency. Previously it showed the allocated amount, which could not be reconciled against the other figures. The separate Unallocated view toggle was removed. The figure is a column on Postings now, so the view was duplicating it. No other field, filter or figure changed.
Inventory Manager is now also available as an Overview 2 widget (27 Jul 2026). The same Inventory Manager tool can be added as a standalone widget on the Overview 2 workspace builder. Add it from the palette, as “＋ Inventory Manager”. It embeds the very same /j-inventory page as the top-level Inventory Manager tab, so there is one source of truth. Like the Rules engine widget it is Standalone and single-instance. There is at most one per workspace, and no colour-group link. It neither drives nor follows the Agreements emitter. No field, column, figure or filter inside the Inventory Manager itself changed. Only that it can now be placed as a widget. Documented on Requirements 2 · Overview 2 (Widget → data & logic lineage + the widget stories).
Rules engine — stale saved rules are now cleared when the app’s defaults change (24 Jul 2026). The Rules engine saves your rules and runs in your browser. It used to keep them forever. So a browser that first opened an older version of the demo stayed stuck on that old default rule set. The retired Eligibility and Matching rule groups kept showing. So did rules like “No equities” and “G3 currencies only”. The current app no longer ships any of them. The app now records which version of the built-in defaults it last saved, in the marker aoe-re-seedver. Say that marker is older than the current one. On the next load your saved rules and runs are cleared and rebuilt from the current defaults. So an out-of-date set can never get stranded again. An ordinary reload with no defaults change leaves your work untouched.
Rules engine — a new run now opens on a blank “Fresh run — no rules yet” page (24 Jul 2026). Click + New to create a run. The Visual flow no longer shows the full rule library greyed out. It shows a clean blank page until the run has at least one rule. You build the run up with the + rule buttons on the input boxes. Those add the new rule straight to the run. You can also switch existing rules in from the ▦ Overview view. Runs that already have rules — including the seed runs — are unchanged. Only the empty-run display changed; no field, column, figure, filter or rule logic was altered.
Inventory data aligned to ONE canonical source — the Rules engine now reads the Inventory Manager's Bond Inventory (23 Jul 2026). The Rules engine's optimiser pool is no longer a separate hand-written list. It now IS the same 130-row canonical Bond Inventory shown in the Inventory Manager. It is generated once by a new shared module, collat-inventory.js. Both screens load it, so they can never differ. The pool is taken as-at today's snapshot (the amount HELD on that date, which varies within each trade's start→end window). Every optimiser-only attribute is now derived from reference data, rather than stored on the line. Asset type comes from the instrument. Sovereign, Supranational and Agency map to Govt; Financial Institutions and Corporates map to Corp. The rating floor comes from the agreement, while each line keeps its own bond rating for the eligibility check. The haircut comes from the agreement's eligibility and haircut schedule. It is a base by asset class and maturity, plus the agreement's haircut add-on, applied per posting. The cost of funds (bps) comes from the cost-of-funds table, by asset class and rating. It takes the internal rate for Internal holdings, and the external rate otherwise. Holding — Internal, External-held or Received — comes from the inventory line itself. That is a new field, now shown on the Inventory Manager's Column display and captured on the Adjusting inventory form. The Rules-engine inventory field library and default rules were re-based on the canonical taxonomy. Portfolios are SG Rates Trading, SG Credit Trading, London Repo Desk, NY Govvies, HK Flow Trading and Treasury ALM. Business Line was “Book”, and Clearer was “Custodian”. Asset type is Govt or Corp. Industry is Sovereign, Financial Institutions, Corporates, Supranational or Agency. Three rules were remapped to match. They are the seed rule “Include trading-desk portfolios only”, Rule 1 Asset-class rank, and Rule 2 Industry rank. User-added rows from Adjusting inventory flow into that one shared book. So does uploaded production Inventory data, set 15. Both appear on both screens. The /j-tool export pack + specs/collateral-demo twins now include collat-inventory.js as a required 4th replica file.
Rules engine — agreement scoping expanded to the full agreement term set (23 Jul 2026). The agreement Applies-to condition list previously offered only three fields. They were Rating floor, Agreement name and Settlement delay. The agreement-level terms on an agreement's detail pop-up are now carried in Agreements static (set 6). All of them are available as agreement scoping conditions, in four groups. Identity / admin holds Agreement ID, type, calculation type, category, group, entity, counterparty and credit rating. It also holds the agreement and end dates, and triparty or custodian. Then base, reporting and margin currency, and margin unit. Then rehypothecation, governing law, netting set, region, and agreement and statement status. Margin call summary holds margin type, and ABC and counterparty MTA. It also holds ABC and counterparty independent amount, and ABC and counterparty threshold amount. It also holds the rounding rules for return and delivery, IA management, delivery/return split, and gross-or-net. Valuation & call schedule holds valuation frequency and reciprocity. It also holds notification and resolution time, LRP, time zone, holiday centres, and securities settlement delay. Collateral rules holds interest calculation method, calculation rule, interest settlement date, and allow-negative-rate. The existing Rating floor, Agreement name and Settlement delay conditions are unchanged. Concentration limits and the eligibility rating floor were deliberately left out. They are optimisation boundaries, not scoping rules. Three places were updated to match. Requirements 1's Epic 11 scoping-fields list. The Requirements 2 data catalog, set 6. And Open-question OQ-33, now Closed. Sample per-agreement values were added for the demo. No other screen, figure or filter changed.
Rules engine — Visual "+ rule" fix and edit-panel Delete (23 Jul 2026). The + rule buttons on the Visual-flow input boxes were inert. They now open the "+ New Rule" editor. The rule-edit slide-in panel gained a 🗑 Delete rule button, shown only when editing an existing rule. It confirms before removing the rule from the library, and from every run's selection. Delete is no longer List-view-only.
Agreement summary & Bond postings columns trimmed (22 Jul 2026). On the docked Agreement summary table, the type-level Summary drops nine columns. They are Call Status, Action, Net Alternative, STD Amount, Cpty Amount, Agreed Amount, Category, Region and Credit Rating. The exposure-split
(ITM / OTM Exposure), dispute
(Dispute Value / Age) and base-currency
Base CCY / Base Total Exp. / Base Call Amt) columns now appear only at the Detailed (individual-agreement) level, not on the type-level Summary. On the Bond postings table, Allocated (USD) now shows what TMO used, not what G7 posted. It is the posted collateral value, scaled down by the agreement’s used-versus-posted coverage. That coverage is the smaller of 1, and exposure divided by total posting. So the postings add back to the agreement’s “Bonds (Used)”. Original amount is that same used amount, in the instrument’s own currency. Three columns were removed: Available (USD), Collateral (USD) and Unallocated (USD). Ccy was renamed Collateral Ccy, and In (days) was renamed Maturing in Days. Three places were updated to match. Requirements 1 — the Epic 2 column checklists, and the §E.1 and §E.5 lineage. Requirements 2 — data model 14, and the Overview 2 column-set mirror. And the UAT data-lineage case. Posted (what G7 posts) and used (what TMO uses) remain two distinct figures.
Data screen — three changes (22 Jul 2026). Eligibility Schedule fields were added to set 6. User-maintained data was split into six sets, 7.1 to 7.6. And an Overview 2 field-lineage completeness audit was run. On the Data tab’s 6 · Agreements static card, the agreement-detail Eligibility Schedule fields are now listed as mappable demo fields. They are Asset class, Asset type, Issuer, Issuer type and Issuer country. Then Currency, Seniority, Security rating, Time to maturity, Haircut schedule and Exclusions. They sit alongside the existing type-level fields. So an uploaded production file can carry each agreement type’s eligible-collateral schedule. Previously the card only exposed the type name, reporting currency, colour, sub-accounts and threshold. Yet the catalog already declared set 6 to include the eligibility schedule and concentration limits. This closes that gap between the card and the catalog. The bundled User-maintained data (set 7) is now broken out. It becomes six sets in their own right: 7.1 Cost of funds · 7.2 G7 industry group · 7.3 Source of collateral · 7.4 Exclude CSA · 7.5 Adjusting exposures · 7.6 Adjusting inventory. Each has its own card on the Data tab. Each has its own row in the Requirements 2 data-source catalog. And each has its own reference in the UAT data-lineage matrix. Sets 8–15 keep their numbers (no renumber), and every field / widget lineage that pointed at “User-maintained · 7” now points at the specific sub-set. The “By source” chart points at 7.3. The “By bond type” doughnut points at 7.2. Exclude-CSA drops point at 7.4, and so on. Finally, an Overview 2 field-lineage completeness audit was run. It traced every field, column, KPI card, chart series and label on Overview 2 back to the catalog. Each one either traces to a modeled data set, or is already an open question — OQ-10, OQ-11, OQ-14 or OQ-16. No new off-catalogue field was found. Category, Region and Credit Rating in the Detailed view were checked, and trace to Agreements static · 6, not a gap) — recorded on the ❓ Open questions tab (section F). Documentation + Data-tab field mapping only: no business figure, calculation or Overview / Overview 2 behaviour changed.
Data tab — large uploads now serve live, plus Download / Import mappings (22 Jul 2026). One case is fixed: uploading a wide production file (e.g. Inventory or Collateral-used data) and switching to Production. It showed “too large for live serving in this browser — stored durably”, then quietly fell back to demo data. The app only ever reads the columns you mapped. So the fast in-browser copy the screens read now stores just those mapped columns, instead of every column. A wide file mapped to a handful of fields fits comfortably. The message only appears when even the mapped columns overflow the browser’s storage. Reducing the number of mapped fields then serves it live. The full file always stays saved on-device either way. There are new Download mappings and Import mappings buttons at the top of the tab. Download mappings saves every set’s field mapping, and the current Dummy/Production choice, to a small collateral-data-mappings.json. Import mappings restores them. So after overwriting the app you re-upload your data files, then re-import this one file. You no longer re-draw every mapping by hand. Documented as Requirements 1 · US19.6 (DATA-12/13) with the storage detail updated in Epic 19. No business field, column, figure or filter on any screen changed. Earlier the same day:
Rules engine — Scoping rules are now built with a nested condition builder (22 Jul 2026). A Scoping rule's condition is no longer a single Field / Condition / Value row. It is a nested logic tree, like the one in a form-logic editor. Each group combines its conditions with And, meaning all must hold, or Or, meaning any holds. Not inverts a whole group. You can add sub-conditions and sub-groups to any depth. An example rule: “Currency is USD or EUR, and (Rating is at least A, or Asset type is Govt)”. Each condition is field → operator → value. The operators and the value entry adapt to the selected field's type. Category fields offer “is any of” and “is none of”, with a value picker. Rating offers “≥ / ≤ / is / is not” on the rating ladder. Number fields offer “≥ / ≤ / > / < / = / between”. Text fields offer “equals / contains / starts with / ends with / does not contain”. A record is kept when the whole condition is true. The builder opens when you edit or add a Scoping rule. Limits and Ranking keep their existing editors. The List, Visual and Overview views show the condition in plain English. Rules saved before this change keep working and open in the builder as their single condition, ready to extend. Documented as Requirements 1 · US11.5. A pre-existing crash was also fixed. Clicking ▶ Run threw instead of showing the allocation log. The optimiser now returns its run log. Earlier the same day:
Rules engine — “Eligibility” removed as a user-set rule group; new ▦ Overview view (22 Jul 2026). The rule-group dropdown is now Scoping / Ranking / Limits only. Eligibility is no longer a user-editable group. What a counterparty accepts is fixed by that agreement’s own eligibility schedule — its accepted asset types and rating floor. The optimiser already enforces that automatically on every posting. A user can only restrict their own inventory pool. That is what the Scoping group does. The four old Eligibility seed rules were deleted. They were Rating floor A, G3 currencies only, No MMF unless IM, and Keep received collateral free. Removing them does not weaken eligibility, because the agreement schedule still applies. The rules-view toggle gained a third option, ▦ Overview, alongside ☰ List and ◈ Visual. It is a read-only at-a-glance summary of the active run. Its rules are grouped into Scoping, Ranking and Limits. Each card shows the name, the condition in plain English, the run order and the active/off state. A Run-parameters panel shows the concentration cap, MTA, rounding and substitution buffer. Editing is still done in List. Note: the Overview has its own per-agreement “Optimization Rules” panel. You reach it from the Overview sidebar, or “▶ Optimize posting”. It is a distinct feature, and was left unchanged. No other field, column, figure or filter changed. Earlier —
New “Tools” tab — copy/download the Overview 2 + Data replica straight from the demo (21 Jul 2026). A new top-level Tools tab was added, as the last tab. It puts the app’s replica export here. So it can be grabbed from the demo, instead of the separate /j-tool page. It has two copy/download cards. The first is a standalone rebuild message. That is the first chat message you paste to hand two screens to another Claude, as its own application. Those are Overview 2, the workspace-builder screen, and the Data screen. The Data screen lets you upload your own files and map fields. It then flips the whole app between the demo and your production data. The message carries step-by-step verification checks. The second is a source-files card. It fetches the two live pages behind that handoff. They are j-collateral.html, the Overview 2 app, and j-collateraldemo.html, which carries the Data screen and the full spec. It fetches them as currently deployed, so they are never a stale copy. The same two cards remain on /j-tool as well. Utility only — no business field, column, figure, filter or behaviour on any screen changed. Earlier the same day:
New “Data” tab — upload production data, map fields and switch the whole app dummy ↔ production (21 Jul 2026). A new top-level Data tab was added, between User maintenance and Requirements 1. It is for replicating the demo inside a real company environment. It is organised around the canonical 16-set data catalog. There is one card per data set, in catalog order. Each shows the set’s number, name, plain-English description and status. Each card lets you upload a production file, as .csv or .json. The first CSV row is the column headers. It then shows the stored file’s name, row count and upload date, with Replace and Remove. Sets whose fields are defined get a field-mapping table. It links each demo field to a column in your file, with a sample value on each side. Placeholder sets show a “field structure not yet defined” note instead. One master toggle, Dummy data / Production data, flips the source for the whole app. Each set with an upload and a usable mapping serves your data. The rest fall back to the demo. Uploads and mappings are saved on-device, so they survive reloads. This is not a one-time import. The exact storage schema is in Epic 19’s Developer build detail. Two sets are wired LIVE today: Market data FX rates and Inventory data. Uploading and mapping them changes the screens immediately. The other mappable sets accept an upload and a saved mapping now. Each is connected as it is wired. The data-reading layer in the Overview and Inventory pages swaps only the source rows. Every worked-out figure keeps computing exactly as before. That covers Used, Surplus, the margin call and the chart aggregations. On Dummy every screen is byte-for-byte the demo. Documented as Requirements 1 · Epic 19, with a figure-provenance table and a Developer build detail fold. The Requirements 2 data catalog now notes that per-set production data can be uploaded here. Earlier the same day:
New “❓ Open questions” tab — the whole app’s pending questions in one place (21 Jul 2026). A dedicated top-level tab consolidates every open question and pending decision on the application. It gathers them from everyone who raised one. That is the Product Owner, the Business Analyst, a Developer and the Tester. Each row says what is unclear, and where it shows up. It also names who raised it, who it is pending on, and its status. It brings six things together. The data-source gaps and mappings to confirm from the Field → data model lineage review (§E.14). The placeholder data sets. The demo-modelled figures to replace with real values. The business decisions pending the product owner, including the meaning of “Valuation Date” and the feature-relabelling list. The tester figure-traceability findings from the Overview 2 review. Those are the margin-call-badge count, the Surplus definitions, the flat-3% versus scheduled haircut, and the “change since” pills. And the standard business-setup discovery questions a Business Analyst asks up front, never settled for this app. Those cover who will use it, and with what roles and permissions. How much data it holds and updates each day. The non-functional expectations of speed, security, audit trail, data retention and devices. And which systems feed it and consume from it. The old in-page “Open questions” section on the Requirements 1 tab is now a short pointer to the tab. So there is a single register, not two. Documentation only — no app field, column, figure, filter or behaviour changed. Earlier the same day:
Requirements 2 · Overview 2 — rewritten from the user’s perspective, and made far more legible (21 Jul 2026). The tab now reads as a user document, not a developer manual. The intro, the contents and the four “As a developer, I can reproduce…” stories were reframed in the user’s voice. Those stories are US9.6 to US9.9. All the developer rebuild detail was then moved wholesale. It went into a single collapsed “🔧 Developer build detail” fold at the end. That detail is the grid and reflow engine constants, and the data-model and loading seeds. It is also the generation formulas PROFILE and evolveBook. And the render config, the persistence schema and the verbatim UI strings. Nothing was deleted. Every formula, seed and schema is still present, just folded. So the tab stays a self-contained rebuild spec. A business reader simply never opens it. Formatting was overhauled for legibility. Walls of text were broken into short paragraphs and bullet lists. Those were the Agreements control-panel and the widget catalog. Major sections now carry headers and horizontal delineators. The order runs Data model, Verifying the figures, Lineage, the user stories, then the developer fold. The last remaining developer and maths tokens in the visible prose were spelled out in plain English. No app field, column, figure, filter or behaviour changed — presentation and voice only. Earlier —
Added a standing “Open questions & decisions” log (21 Jul 2026). A new section near the top of this tab lists everything the specification still needs confirmed, in plain English. Once answered, it keeps the decision made, with its date. It has two feeds. The first is the standard discovery questions a Business Analyst asks up front, never settled for this app. They are who will use it, and with what roles and permissions. How much data it holds and updates each day. The non-functional expectations — speed, security, audit trail, data retention, and devices and browsers. And which systems feed it and consume from it. The second feed is the open items testers raised while tracing figures, carried over from the test pack’s Gap Log. Those are the two “Surplus” definitions, and the flat-3% versus scheduled haircut. Also the zero-surplus reading on an under-collateralised agreement, and the inconsistent “change since” pills. Rows are never deleted — an open question becomes a decision when answered. Documentation only — no app field, column, figure, filter or behaviour changed. Earlier the same day:
Field → data model lineage — every displayed field is now traced (21 Jul 2026). Each is traced to its exact data set and field. Added as Requirements 1 · Appendix E — “Field → data model lineage”. It is a complete screen-by-screen list of every field the app shows. Each is mapped to its exact data set, from the 15-set catalog. Each also names the entity and field it comes from. Each is marked Referenced, Held-on-record or Worked-out. It covers the Overview summary table, KPI cards and charts. Then Margin Calls, the Bond-postings blotter and the T+N ladder. Then the Agreement-detail popup, Exposure drill and Instrument modal. And the Inventory Manager, Rules engine, Static-data screens and the six User-maintenance datasets. Each data-set and entity reference is a clickable link. It opens the Requirements 2 data dictionary at that definition. That is new cross-tab anchor navigation, with entity headers given anchors #req-ent1…6. A closing §E.14 · Off-catalogue & to-confirm flags every field that does not yet trace to a catalogued set. They are raised, not invented. The biggest are these. No derivative-trade data set, for the trades behind exposure. No security-price or valuation data set, for market values and MTM. The T+N ladder has no source. And the Clearer, Business Line and issuer-classification set assignments need confirming. Documentation only — no app behaviour, values or fields changed. Earlier the same day:
Requirements 2 · Overview 2 — every on-screen figure now carries a documented verification path (21 Jul 2026). This applies the standing rule for every figure the app shows. A spec must say where it comes from, how to confirm it is correct, and where to check. That is the “if the screen shows $10 million, is it right — how and where do I check?” Business-Analyst test). The Overview 2 Data model already documented each figure’s source. That is the 15-set catalog and the Widget → data lineage. It also documented the derivation — the US9.8 and US9.9 formulas, and the collateral-used column dictionary worked line. This adds the missing verification leg. Derived figures gained a “How to check it is correct” column. Posted, Exposure, Used, Surplus, Bonds-Cash used and the 9 cards each now name what to compare against on screen. A new 🔎 Verifying the on-screen figures reference block lists the figure-by-figure checks, and where to look. The Key-figures cards add up among themselves. Each strip matches its scope. The Agreements rows reconcile to the All-agreements total, with Triparty excluded. The drill parts sum back to the type. The (N) margin-call badge is counted. The four charts reconcile to the strip. So does the Week/Week pill. And the collateral-used column dictionary line ties out end to end. A follow-up the same day ran a figure-traceability review, per the Frontend Test Strategy. It set the Surplus description to exactly what it is: Total Posted minus Total Used. That is shown green as “surplus” when zero or positive, and red as “deficit” when negative, matching the app’s render. It also gave the Received (inbound) card its own source and verification. That card holds inbound collateral. It is checked by scope and its Week/Week pill, not by adding it to the other cards. It was the one KPI card with no verification path. The same review corrected two checks that did not match the live app. First, the (N) margin-call badge cannot be re-counted on screen, because individual drill rows show no per-agreement flag. It was reworded to verify by tooltip and determinism, and to flag the un-recomputable count as a gap. Second, the Over-time chart reconciles the stacked bar to the Total posting card. The green “Total posted” line equals the bar. (It used to carry a demo over-collateralisation buffer; that was removed on 08 Aug 2026.) By source reconciles to Bonds posted, which is bonds only, not cash. Documentation only — no app field, column, figure, filter or behaviour changed. No new UI structure was introduced. These describe checks on figures that already exist. Earlier —
Agreement summary table — Posted / Used columns split out (21 Jul 2026). Surplus and DoD/WoW/MoM were also re-based on Used. Two columns were removed from the docked Agreement summary table, at both levels. They were ↳ % bonds and ↳ % cash. ↳ Bonds was renamed ↳ Bonds (Posted), and ↳ Cash renamed ↳ Cash (Posted). Three columns were added after the posting split: Total used, ↳ Bonds (Used) and ↳ Cash (Used). Total used is the smaller of Total posting and Total exposure. You cannot use more collateral than you posted, or more than you owe. Bonds and Cash (Used) split that figure in the same proportion as the posting. So they add back to Total used. Surplus was redefined to Total posting − Total used. That is the over-collateralisation left after covering exposure, and it is never negative. It matches the Overview Key-figures cards. The DoD / WoW / MoM change columns now track the change in Total used, not Total posting. They compare with the reference date 1, 7 and 30 days earlier. Their headers now read “(total used)”. Requirements 1 was updated to match — its Epic 2 column checklist and column catalog. So was Requirements 2, in the Overview 2 column-set mirror. No other table and no Key-figures card changed. Earlier —
Collateral used data — the line-level collateral data set is now fully defined (20 Jul 2026). Data set 14 was renamed from “Collateral balance used” to Collateral used data. It was given a full column dictionary, on Requirements 2 · Overview 2. It lists every field a developer builds the real table from. Those are Agreement Name, Position (Delivered / Held), Counterparty, Asset Class (G7 group) and Agreement Category. Then ISIN / Currency, Maturity Date, Date of Posting and Valuation Date. Then Booking Currency, Par Amount, Booking Market Value, Booking Collateral Value and Haircut. And last Reporting Currency (USD), Market Value (USD), Collateral Value (USD) and FX Rate. Every column is traced to a source. Some are referenced from existing reference data sets. Those are Agreements static 6, Counterparty static 1 and Bond/securities static 2. Also Currency static 5, the user's G7 map 7, and Market data FX 8. Some are captured on the collateral line itself, set 14. The rest are worked out from the other columns on the line. Booking Collateral Value is the market value after the haircut. The two USD figures are the booking figures converted at the line's FX rate. A fully worked example ties out. It uses a Korean-won bond, with a haircut of 92 and a KRW FX rate of 0.00073. The Booking Currency (the instrument's original posting currency — e.g. KRW for a Korean bond, is an explicit column. The Par and Booking amounts sit in it. They are converted to USD at the line's FX rate. Three places were updated to reference the set and its columns. The Requirements 2 catalog row. The Widget → data & logic lineage table. And the UAT Data lineage matrix. A Data source note was added on Requirements 1, under Asset Holdings Summary and Collateral Posted. Confirmed by the product owner (20 Jul 2026). Reporting Currency is USD. Booking Currency is the instrument's original posting currency. Still open (⚑): the exact business meaning of Valuation Date. Existing feature labels are left unchanged pending the relabelling list. Earlier —
Overview 2 — added the 15-set “Data source catalog” and a “Widget → data & logic lineage” map (17 Jul 2026). The Requirements 2 · Overview 2 Data model now opens with a canonical catalog. It lists the 16 master data sets the app is fed by. They are Counterparty static, Bond/securities static, Holiday calendars, Portfolios static and Currency static. Then Agreements static. It covers CSA IM/VM, Triparty Repo, Futures Clearing, GMSLA, GMRA and CCP, with the eligibility schedule and concentration limits. Then User-maintained data, Market data FX and Market data benchmark rates. Then Exposures & margin calls. Then Optimization rules, Optimization outputs and Optimization exclusions & exceptions. And last Collateral balance used and Inventory data. Each carries a plain-English description and where it lives today. Each also carries a Status of Modeled, Partial or Placeholder — to be detailed. Some sets are listed as reserved placeholder slots, with no invented fields, to be detailed later. Holiday calendars and Benchmark rates are not yet built. Portfolios static and the Optimization rules, outputs and exclusions are not yet consumed by an Overview 2 widget. A Widget → data & logic lineage table then traces each Overview 2 widget back to the catalog. Those widgets are Agreements, Collateral charts, Bond postings and the Key-figures strips. For each it names the sets it reads, and the logic it applies. The same matrix, plus two lineage test cases TC-DL.1 and TC-DL.2, were added to the UAT test cases · Overview 2 tab. A new standing lineage rule was adopted. Every Overview 2 widget must draw its data from a catalog set. Whenever a widget is added or changed, its data must trace to one of the 15 sets. Any off-catalogue data source must be raised, and added to the catalog, before it is built. No app behaviour, values or fields changed — this is spec documentation only. Earlier on 17 Jul 2026: Requirements 2 · Overview 2 — requirements separated from test cases, with no more duplication. The step-by-step OV2-01…OV2-12b “Do / Verify” scenarios were removed from the Requirements 2 tab. Each user story, US9.1 to US9.5, now reads as a BA-style Functional requirements list. Those are declarative statements a developer builds from. The tester-facing step-by-step cases for these same stories already live on their own “UAT test cases · Overview 2” tab, as TC-9.1 to TC-9.9. So requirements read as requirements, and test cases read as test cases. Nothing is repeated across the two. No values, formulas, fields or behaviour changed. This is the first step of a standing convention. Requirements are written from a User and Business-Analyst perspective, for developers to build a replica. Test cases are a separate artifact, for a zero-context tester to execute UAT. The same treatment will follow on Requirements 1. Earlier on 17 Jul 2026: a full jargon sweep of both Requirements tabs. Every remaining developer or modelling shorthand now carries a layman explanation. In US9.7 “Data model & loading” it explains what a “seeded PRNG” and mulberry32 are. It also says why the data is identical on every load. It also covers what an agreement “weight” is, and what “normalised” means. And how the name-derived hashStr flags work, the “seeded weighted pick” for funding sources, and MS_DAY. It covers the scattered “deterministic / seeded RNG” mentions in the Overview KPI notes. Also the zero-interest flag, the in-call flag, the MtM hash%20 split, the 16%-terminated trades note, and Appendices A and B. And the US9.9 chart-config terms, doughnut “cutout” and x-axis “grace”. All values and formulas unchanged. A standing rule was reaffirmed and broadened. Requirements are written from a User and Business Analyst perspective, in layman-understandable English. They stay exact enough for developers to build a replica. Earlier on 17 Jul 2026: Requirements 2 — the US9.8 “Generation & computations” spec was rewritten in plain English. Every dial in the per-type generation profile now carries a lay explanation. Those dials are base / vol / drift / cover / bondShare / phase / amp / rf. The daily-walk bullets now lead with plain business wording, before each verbatim formula. All values and formulas are unchanged. Nothing was added or removed. This was adopted as a standing rule for all spec writing. Spec copy must never use unexplained modelling or developer shorthand. Every code-level term gets a plain-language explanation alongside. Earlier on 17 Jul 2026: Overview 2 — widget link roles are now FIXED by widget type. They are no longer a user choice. The chain popover no longer has Emitter and Receiver buttons. It shows the role as a read-only label. It only lets you pick the colour group, or Standalone. Agreements is the Emitter. Collateral charts and Bond postings are Receivers. A Receiver follows its colour’s Emitter when linked. When not linked it is standalone: Collateral charts shows a placeholder, and Bond postings shows all postings. Layouts persisted by the old role-pickable build are healed on load. coerceRolesByType() forces each role to its type’s role, and re-frees duplicate emitter colours. pruneOrphanReceivers() then runs. Documented in §9 (Rule A/B, OV2-11/12/12b and the linking build-detail). Earlier on 17 Jul 2026: Overview 2 — the ⟲ Reset layout button moved out of the top toolbar. It now sits in the Agreements control-panel widget, in its filter panel next to ✕ Clear. The toolbar now only holds the workspace tabs and the hint. Also on 17 Jul 2026: Overview 2 Agreements widget — each row's money figures expanded. Rows now show Total posting · Total used · Surplus. Previously they showed just the (N) active-agreements badge and the total posting. Total used is the smaller of total posting and exposure, for that agreement or type. Surplus = Total posting − Total used, shown green when zero or above and red when negative. This applies to All agreements, each type row, and each individual-agreement drill row. The three figures sit in right-aligned value columns under a single column legend (Agreement · Posted · Used · Surplus, so the labels are not repeated on every row. The Agreements widget's default width was widened from 3 to 4 grid columns. The charts receiver went from 9 to 8. That fits the columns alongside the agreement name. Also on 17 Jul 2026: Overview 2 linking fixed. A Receiver now shows data only when an Emitter is present on its colour group. Take a receiver linked to an emitter-less colour (e.g. Collateral charts set to green when no green emitter exists, or after its emitter is closed). It reverts to no data, showing a placeholder. A Receiver’s colour picker now offers only colours that currently have an Emitter. Each new Agreements widget auto-becomes an Emitter on the next unused colour. So two emitters never share a colour. This is documented in §9, as OV2-11 and OV2-12b. Follow-up the same day: this also fixes the display. A receiver on an emitter-less colour no longer shows as linked. Its coloured outline and ⬇ chain icon revert to the standalone 🔗 look, and the orphaned colour is cleared. So a widget only ever displays a link to an emitter that exists on the workspace. This self-heals on load, when an emitter is closed, and on any role or colour change. The helper is pruneOrphanReceivers(). Also today: Key figures is no longer a standalone Overview 2 widget. Its KPI cards now ride on two widgets. One strip sits across the top of the Collateral charts widget. It is scoped to the agreement and filters it receives from its Emitter. It is hidden when that widget is unlinked. The other sits across the top of the Bond postings widget, scoped to what the table currently shows. So each set of figures updates independently. The standalone Key figures widget was removed from the palette and the default workspace. Existing saved layouts drop it on load. Earlier the same day: the Requirements Page was restructured. Overview 2 now has its own dedicated section, §9 “Overview 2 — workspace builder”. It was pulled out of §1 “Global shell & navigation”. So its workspace-builder requirements are no longer co-mingled with the other tabs. Sections §9 to §16 were renumbered to §10 to §17. Those are the Inventory Manager, the Rules engine and the six User-maintenance datasets. The table of contents and the cross-references were updated to match. Earlier on 16 Jul 2026: User maintenance was rebuilt into six user-maintained datasets. Each has a Download on-screen, and an Upload that captures only editable fields. Each has an upload completed / error status, and a Last updated stamp. That stamp bumps on any on-screen edit or upload. The six are: 1. Cost of funds — a full grid of every distinct G7 Industry Group by currency. The currencies are AUD, CAD, CHF, USD and SGD. The user fills Rate (internal) and Rate (external). 2. G7 industry group — system columns plus a user-entered G7 Industry group, with an Others catch-all. The system columns are Classification Level 4 name, BICS Level 2 Industry Group Name and Issuer Industry. The distinct G7 groups now drive the Overview bond-collateral-by-G7 chart. Each posting is classified into a G7 group via the mapping, with a dummy default when unmapped. They also seed the Cost-of-funds grid. 3. Source of collateral — rules over portfolio fields, with Include and Exclude values assigning a Collateral Source. The fields are Product Lines, Book, Product Franchise, Attribute ID and Portfolio Description. The distinct Collateral Source values drive the Overview “Sources of collateral” chart. 4. Exclude CSA — now a system drop-down of agreement names (add / edit-by-re-pick / remove), excluded across the app; 5. Adjusting exposures — upload or add exposure adjustments, which add on to an agreement's exposure on the given date. Its fields are Agreement name, Adjusted Exposure in USD, Adjusted Exposure in Original Currency, Original Currency and Date. 6. Adjusting inventory — add inventory rows using the Inventory Manager “Bond Inventory” fields, appended into the Inventory Manager. Keys: collat-cost-of-funds, collat-g7-map, collat-source-rules, collat-exclude-csa, collat-exposure-adjust, collat-inventory-adjust, collat-um-updated. The old “User-uploaded data” schema-definition and generic “User mapping table” sub-tabs were removed. Earlier on 16 Jul 2026: Overview 2 linking was reworked. The Agreements widget is now the control panel. It carries the shared filter panel at its top. That holds Granularity, Quick range, From/To, the Reference chip and ✕ Clear. As an Emitter it broadcasts its agreement pick and those filters to same-colour Receivers. They are stored per colour in groupFilter. The Collateral charts widget is now Receiver-only. Its chain popover offers no Emitter role. When unlinked it shows a placeholder and no data. The default workspace ships pre-linked on blue. It carries the Agreements emitter and the charts receiver, so it renders out of the box
Earlier the same day: the Overview 2 four chart widgets were consolidated. They were Collateral utilisation history, Total collateral by agreement type, Sources of collateral, and Bond collateral by G7 industry group. They became a single “Collateral charts” widget, with a segmented toggle. That toggle offers Over time / By agreement / By source / By bond type. It switches which chart is shown. It mirrors the Single layout's solo view. The selected chart persists per instance, via a new soloDim field. The workspace store bumps to collat-workspaces-v2
Earlier the same day: Overview 2 became a workspace builder. A left palette adds widgets, each with a ✕ close. The user keeps multiple workspaces, via top tabs with ＋, rename and close. Any widget can be added many times, as independent instances. The old Agreements sidebar and Agreement summary widgets are merged into one Agreements widget. Each type row shows its $ total posting and its (margin-call count) badge, and drills into individual agreements. Static Data and Rules Engine were dropped, to return as their own widgets. Linking is now many-to-many by colour. Any widget is standalone, an Emitter (⬆) or a Receiver (⬇), set from its top-right chain icon. Emitters broadcast the agreement they show to receivers on the same colour group. Bond postings is limited to one instance per workspace. All of it persists to collat-workspaces-v2.
Also on 16 Jul 2026, in the Rules engine. The Scoping rule group now scopes all input datasets, not just inventory. Margin-call scoping covers Currency, Call size and MTA. Agreement scoping covers Rating floor, Agreement name and Settlement delay. Both now actually filter which margin calls and agreements enter a run. Out-of-scope calls and agreements are dropped. Each agreement's requirement re-aggregates from its in-scope calls. A Record age (days) inventory scoping field was added, measured against the latest booking date. That makes the “Exclude stale inventory” rule work. The 👁 Preview now marks in scope or out on the Inventory, Margin Calls and Agreements input tables. It also shows in and out counts on the visual-flow input boxes
Earlier, on 15 Jul 2026: Overview 2 gained a standalone Agreement summary widget. It is a master selector, listing All agreements and each agreement type with its total posting. It drills into individual agreements. Other widgets can be linked to it with 🔗, so they filter to the picked agreement. The charts and Key figures scale to an individual agreement’s share. The Bond-postings blotter filters to its type. Unlinked widgets keep following the global sidebar selection. Links and selection persist to collat-widget-links-v1
Earlier the same day: the Overview 2 tab was added. It is a widget dashboard that mirrors the Overview content. That means the agreement sidebar, the Key-figures KPI cards, the four charts and the Bond-postings dock. They become drag and resize widgets on a collision-aware 12-column grid. Moving or resizing one reflows the others so they never overlap, by pushing down and compacting up. Any widget can be pinned with 📌 to lock its position and size, and act as a fixed obstacle. Layout and pins save to localStorage, in collat-widgets-v2, with a ⟲ Reset layout control. The 4-layout selector is hidden while Overview 2 is active. Overview (§2) is unchanged
Earlier: on the Overview Collateral utilisation history chart, the bars now represent what TMO uses. The Total posted line shows what G7 posts. The separate Total used line, the bar total, is not shown on this chart
Earlier, a batch of screen changes. The “Call Required” (red) call-status value and its KPI tile were removed. Call statuses are now Pending Review, Margin Request Confirmed and No Call Required only. The “Collateral manager” field was removed from the Dates & Status card. The Coverage KPI tile was removed from the agreement detail banner. The Eligibility schedule was split into one block per eligible collateral type — Cash, Govt, Corp and MMF. Interest / rebate rate moved under Cash only. The Exposure card now lists MTM and IA separately, with no “Total Exposure” summed row. Benchmark rate now shows an actual reference rate: SOFR, Fed Funds, €STR or SORA. A Postings tab was added to the agreement detail popup, third beside Overview and Trades. It mirrors the main Bond postings table, filtered to that agreement. In-popup “View Postings” links now switch to this tab. They no longer close the popup and jump to the main screen. The Eligibility schedule is now a bordered card per type, colour-coded for clear visual separation. Each type's posted amount is integrated into its header — “$Xm posted · N% of collateral”, plus a share bar. Postings map to eligible types: Govt takes Sovereign and Agency, Corp takes Corporate, and Cash takes cash. A scaling bug was fixed, so the agreement-detail Asset Holdings Summary sector rows tie to their “Total bonds” figure. The IA management field was removed from the Margin Call Summary card. The sample postings were tuned, so every agreement posts a multi-type mix within its accepted collateral types. Corp bonds now appear for every Corp-eligible agreement — BVM, CCP, GMRA and TRI. Postings no longer fall outside an agreement's accept-list. A scaling fix keeps the detail Asset Holdings Summary consistent with the eligibility posted amounts. Total used, Bonds used and Cash used KPI cards were added to the Overview banner, before Surplus. Surplus was redefined as Total posting − Total used. The Agreements in call KPI card was removed from the Overview banner. A “Zero-interest only” filter under CSA VM was added to the sidebar, driven by an agreement-level flag. A user-maintained “Exclude CSA” list was added to the User-maintenance tab. It drops named agreements from the Overview's individual-agreement views. The agreement detail popup now hides the Trades tab and the trade-contribution link. That applies to pure Initial-Margin agreements: BIM and Futures. IM exposure is a single number, not trade-driven. Finally, GMRA and GMSLA became VM-only. Their IM/VM sub-book split and sidebar toggle were removed. CCP stays IM and VM.

Show layout:

Opens or closes every user story on this tab, and the test cases inside each one.

🧪 How to use this pack (read first) — open the app, work top-to-bottom by epic, run each scenario's Do/Verify

Open the app: go to jassica.sg/demo/collateral/ in a desktop browser. No login is required.
Work top to bottom. Each epic starts with “To get here” — the exact clicks to reach that screen. Then work through its user stories in order.
Open a user story by clicking its title. Inside you get that story's requirements first — the fields, rules and defaults it must deliver. At the end of the story is the 🧪 Test cases fold. Open it and run the scenarios in order. Use ⊕ Expand all at the top to open every story and every test-case fold at once.
Each test case has an ID, a Do (what to click/type) and a Verify (what you must see to pass). If what you see matches Verify, mark it Pass. If not, mark it Fail. Note the test ID and what you saw instead.
Field / filter checklists are numbered — mark each item once you confirm it is present and behaves as described.
A field is written up in full once. It is documented under the story that owns it. Other stories that use the same field link back to it rather than repeat it. Follow the link — it opens the story it lands in.
This is a plain document — select all, copy, and paste it into your own test-management doc or spreadsheet. Collapsed folds are still copied, so you do not have to open anything first. The only controls are the “Show layout” filter and the expand/collapse buttons at the very top. Both are excluded from the copy.
Recommended: test in the “2 · Split” layout by default. Split is the most complete layout to test in. It shows the charts and the bottom postings dock at the same time. So almost every Overview test case runs without switching layouts. Set the top-right Layout control to 2·Split. Confirm you are in Split by the drag handle on the border between the charts and the dock. See §1's “Overview layouts — how to identify each”. Only switch to another layout if a case is tagged for it (below).
Filtering the pack to a layout. Use the “Show layout” dropdown at the top. Pick 2 · Split only. Every case locked to another layout disappears, leaving the all-layout cases and the Split-only case. Your choice is remembered on refresh. Hidden cases are not copied when you select-all. So filtering to Split, then copying, gives you a clean Split-only document. Only four cases are layout-locked. Each carries a plain [Layout: …] tag, so it is findable with Ctrl/⌘-F. They are SHELL-06 (Split), SHELL-07 (Drawer), OVW-08 (Tabs) and OVW-12 (Single). SHELL-04 tests switching between all four, and always shows. Every case WITHOUT a tag applies to all layouts. It stays visible in every filter, and you run it in Split.
This is demo data. Exact numbers, names and dates will vary. They are not what you verify. Verify the behaviour, and that the listed items exist.
Resetting: a page refresh clears chart filters and selections. Edits in User maintenance are saved in the browser and survive refresh (that persistence is itself a test).
Don't know a term? Every finance abbreviation and field is defined in Appendix B · Glossary & data sources. It also says where each number comes from. That covers MtM, IA, MTA, ITM/OTM, LRP, threshold, haircut, seniority, T+N, cheapest-to-deliver and BICS.

📑 Contents — jump to an epic

E1 Global shell & navigation
US1.1 Switch tabs & toggle theme · US1.2 Choose an Overview layout (Tabs / Split / Drawer / Single) · US1.3 Top-right chrome & shell defaults
E2 Overview — collateral dashboard
US2.1 Filter by agreement & sub-book · US2.2 Set period/granularity, cross-filter & drill · US2.3 Read KPI cards & charts · US2.4 Bond-postings dock, snapshot & single-chart · US2.5 Optimize a posting · US2.6 Select individual agreements · US2.7 Open User maintenance from the sidebar · US2.8 Open Optimization Results from the sidebar · US2.9 The note under the agreement list
E3 Margin Calls panel
US3.1 Review the report & drill to agreements/disputes · US3.2 Tiles, statuses, columns & derivation
E4 Bonds Maturing & Triparty AOE
US4.1 Filter bonds maturing within N days · US4.2 Open the Triparty AOE dashboard (Triparty)
E5 Static Data reference screens
US5.1 Open each reference-data screen
E6 Agreement detail popup
US6.1 Open the popup, tab through & act · US6.2 Read the Overview cards & tabs · US6.3 Build defaults & derivation
E7 Exposure drill panel
US7.1 Drill trades vs collateral posted · US7.2 Sort / filter / columns
E8 Instrument detail modal
US8.1 Open the modal (Overview & Inventory) · US8.2 The two field sets
E9 Overview 2 — workspace builder → on its own tab, “Requirements 2 · Overview 2”
Canvas & workspaces — US9.1 add / duplicate / close · US9.2 move, resize, pin & reflow · US9.3 workspaces & persistence · US9.4 link by colour (emitter / receiver). Agreements widget — US9.5 select & drill · US9.6 shared filters & broadcast · US9.7 fields. Collateral charts widget — US9.8 switch charts · US9.9 chart drill / cross-filter · US9.10 fields. Bond postings widget — US9.11 blotter views · US9.12 maturing filter & columns · US9.13 fields. Key figures strip — US9.14 fields. Developer build detail — US9.15 data model · US9.16 generation & computations · US9.17 KPI strip, charts & blotter
E10 Inventory Manager
US10.1 Snapshot view & as-at date · US10.2 Time-series view · US10.3 Fields, controls & defaults · US10.4 Pivot view (Group by × Row by)
E11 Rules engine (standalone)
US11.1 Select & manage runs · US11.2 Build, run & preview · US11.3 Scope the input datasets · US11.5 Nested Scoping conditions · US11.6 Eligible issuer groups & how a recommendation is built · US11.4 Controls, parameters, output & seed runs · US11.16 The two flow tables · US11.17 Amend what the run proposed · US11.18 Summary by bond · US11.19 Pick the run · US11.20 Bonds and agreements side by side
E12 User maintenance — shared contract
US12.1 Download / upload / status / last-updated (common to all six datasets)
E13 Cost of funds
US13.1 One row per Security Type × currency, always including Others · US13.2 Type the rates straight into the grid · US13.3 Download, update in Excel, upload back (all-or-nothing, every problem listed) · US13.4 How a bond gets its cost of funds (exception handling)
E14 G7 industry group
US14.1 Map issuers to G7 groups & drive the bond-type chart
E14a G7 by bond
US14a.1 See every bond beside its classification · US14a.2 Search & filter the bond list · US14a.3 Set the G7 group on many ISINs at once · US14a.4 Download, edit in Excel, upload back
E15 Source of collateral
US15.1 Build source rules & drive the sources chart
E16 Special agreements
US16.1 Maintain the special-agreement list
E17 Adjusting exposures
US17.1 Add / upload exposure adjustments
E18 Adjusting inventory
US18.1 Add / upload inventory rows
E18a Tags & highlights
US18a.1 Tag a value in the book and give it a colour
E19 Data — upload production data & switch dummy ↔ production
US19.1 Switch the whole app between Dummy and Production data · US19.2 Upload a production file per data set · US19.3 Map each demo field to a column in my file · US19.4 See which source each set is serving · US19.5 Reserved (placeholder) sets

Reference library (build appendices, not epics): A · Data model & conventions · B · Glossary & data sources · C · Table controls · D · Tooltips, hovers & dynamic text · E · Field → data model lineage

Standing log: Open questions & decisions. It holds what is still to be confirmed, and the decisions already made.

OPEN Q

Open questions & decisions

Every open question and pending decision now lives on its own tab. It is ❓ Open questions, one register of everything still to be confirmed. It gathers questions from everyone who raised one. The product owner raises business setup: roles, volumes, service levels and connected systems. The testers raise figures that do not yet reconcile, from the test pack’s Gap Log. The data-model review raises fields with no agreed data source, from §E.14. Each row states the question in plain English. It names who raised it, who must answer it, and its status. Rows are never deleted — only moved from open to decided.

Open the ❓ Open questions tab for the full list.

EPIC 1

Global shell & navigation

ℹ︎ About this epic — where to find it (click to expand)

To get here: open the app. This epic applies to the whole screen. That means the top row of tabs, and the top-right controls.

US1.1 As a user, I can switch between the top-level tabs and toggle a light/dark theme so I can move around the app and read it comfortably.

Checklist — navigation tabs present

Overview — collateral management dashboard. Its left sidebar also opens the Inventory Manager, which is not a top tab
Overview 2 — a workspace builder: add / close widgets from a palette, multiple workspaces, multi-instance, emitter/receiver linking
Rules engine — allocation scoping & ranking rules
User maintenance — upload definitions, mapping tables & the Special-agreements list
Requirements 1 — this spec/test pack for the whole app except Overview 2
Requirements 2 · Overview 2 — the Overview 2 workspace-builder spec (its own tab)
CSA time-series — hidden (should NOT appear)

🧪 Test cases for US1.1 3 scenarios

SHELL-01 Default tab

Do: Open the app fresh (or refresh the page).

Verify: the Overview tab is highlighted/active and its content is shown by default.

SHELL-02 Tab switching

Do: Click each top tab in turn. Start with Overview 2, then Rules engine and User maintenance. Then Requirements 1 and Requirements 2 · Overview 2. Finish back on Overview.

Verify: exactly one tab's content is visible at a time; the clicked tab is highlighted and all others are hidden.

Verify: there is no Inventory Manager tab in the top row. It is reached from the Overview sidebar instead.

SHELL-03 Light / dark theme

Do: Click the theme toggle (top-right). Then refresh the page.

Verify: colours switch between light and dark on click; after refresh the last-chosen theme is still applied.

US1.2 As a user, when I pick one of the four layouts, then the charts and postings dock rearrange to match.

Overview layouts — how to identify each & its controls (build detail)

1 · Tabs (default). Charts fill the view; the postings dock is hidden. A “View” toggle (Dashboard / Holdings table) appears in the filter bar. “Dashboard” shows the charts. “Holdings table” replaces them with the full postings table. Identify by: the Dashboard/Holdings toggle is present and there is no dock at the bottom.
2 · Split. Charts on top and the postings dock docked at the bottom of the same screen, both visible at once. Identify by: a drag handle (“Drag to resize”) sits on the border between the charts and the dock. Split-only controls:
- Drag handle — drag the divider up/down to adjust the dock height (the resizable border). Default height ≈ 46% of the viewport; the chosen height persists while you stay in Split.
- ⤢ Maximize / restore — expands the dock to near-full height (≈ viewport − 150px) and back.
- ▾ Collapse / expand — collapses the dock to just its title bar (≈ 48px); the arrow flips ▾ ↔ ▴.
3 · Drawer. Charts fill the view. The postings table becomes a slide-in drawer from the bottom over a dimmed backdrop (≈ 84% height). Identify by: a “▤ Open holdings table” button in the filter bar. Controls: that button opens the drawer; ✕ Close closes it; clicking the dimmed backdrop also closes it.
4 · Single. The multi-chart grid is hidden. A single switchable chart shows instead. Its dimension toggle offers Over time, By agreement, By source and By bond type. The whole page scrolls as one column. The dock becomes a static panel below it, with no drag handle. Identify by: one chart + the dimension toggle; the page scrolls as a single column.

Checklist — layout-specific controls

Tabs: View toggle — Dashboard / Holdings table
Split: drag-to-resize handle (adjustable dock border)
Split: ⤢ Maximize / restore
Split: ▾ Collapse / expand
Drawer: ▤ Open holdings table
Drawer: ✕ Close + click-backdrop to close
Single: dimension toggle — Over time / By agreement / By source / By bond type

Build note — embedding & host↔iframe integration

Overview and Overview 2 are iframes. The shell loads /j-collateral?embed=1 for Overview. It loads /j-collateral?embed=1&widgets=1 for Overview 2 — the same page in workspace-builder mode. That mode adds the palette, close buttons, multiple workspaces, multi-instance widgets and emitter/receiver linking, and persists to collat-workspaces-v1. When embedded, each page hides its own top bar (the host owns the title + theme toggle).
The Inventory Manager is a nested iframe, one level deeper. It is not a tab of the shell. The Overview page itself loads /j-inventory, inside its own screen, when the sidebar entry is opened. The Overview 2 Inventory Manager widget loads the same address the same way.
The host drives the iframes via window.postMessage. A theme change posts {type:"theme", mode:"light"|"dark"} to both iframes. The Overview page passes the same message on to the Inventory Manager it holds. So the theme travels two hops. The Layout selector posts {type:"setLayout", lay:"tabs"|"split"|"drawer"|"single"} to the Overview iframe. Each iframe applies the message on receipt. The Layout selector is hidden while Overview 2 is active (widget mode has no fixed layouts).
Single-tab embed (?only=<tab>). Opening the shell with a query like /j-collateraldemo?embed=1&only=rules renders only that one tab. The top bar and the tab strip are hidden. The other tab panels stay hidden. The heavy Overview iframes are not loaded at all. This is how the Rules engine widget in Overview 2 reuses the real Rules engine. That widget lives in /j-collateral?widgets=1 and embeds /j-collateraldemo?only=rules. So there is one source of truth. Runs and rules edited in the widget, and through the Overview sidebar’s Optimization Rules entry, are the same records. (There is no longer a top-level Rules engine tab — see the 01 Oct 2026 change log entry.)

🧪 Test cases for US1.2 3 scenarios

SHELL-04 Overview layout selector — all 4 layouts[Layout: all — 1·Tabs, 2·Split, 3·Drawer, 4·Single]

Do: On the Overview tab, click each option in the top-right “Layout” control in turn: 1·Tabs, 2·Split, 3·Drawer, 4·Single.

Verify: the embedded Overview re-arranges as described below, and the layout-specific controls appear/disappear to match.

SHELL-06 Split — resize / maximize / collapse the dock[Layout: 2·Split only]

Do: In Split layout, drag the divider between the charts and the dock; then click ⤢ (maximize/restore) and ▾ (collapse/expand).

Verify: dragging changes the dock height. ⤢ toggles the dock to near-full height and back. ▾ collapses the dock to a bar, and the arrow flips ▾/▴.

SHELL-07 Drawer — open / close[Layout: 3·Drawer only]

Do: In Drawer layout, click “▤ Open holdings table”. Close it with ✕. Reopen it, then close it by clicking the backdrop.

Verify: the table slides up over a dimmed backdrop; both the ✕ button and a backdrop click close it.

US1.3 As a user, I see consistent top-right chrome and predictable defaults so the shell behaves the same every session.

Checklist — top-right chrome

Theme toggle (☀ / ☾ with “Light” / “Dark” label)
User box — “Welcome, Jassica!” + date + avatar “J”

Defaults & exact values (build)

Default tab = Overview (no explicit persistence — it always opens on Overview on load/refresh).
Default theme = light. Theme is persisted to localStorage key collat-theme-ds2 (values "light" / "dark"). If the key is absent the page is light. No data-theme attribute means light.
Default Overview layout = 1 · Tabs.

🧪 Test cases for US1.3 2 scenarios

SHELL-08 Top-right chrome is present

Do: Look at the top-right corner of the page.

Verify: both items on the checklist above are there. The theme toggle shows ☀ / ☾ with a “Light” / “Dark” label. The user box reads “Welcome, Jassica!” with today's date and a “J” avatar.

SHELL-09 Shell defaults on a first-ever visit

Do: Open the app in a private/incognito window, so nothing is remembered from before.

Verify: the app opens on the Overview tab. The theme is dark. The Overview layout control reads 1 · Tabs.

EPIC 2

Overview — collateral management dashboard

ℹ︎ About this epic — where to find it & the agreement sidebar (click to expand)

To get here: click the Overview tab (it is the default). The dashboard has four parts. A left sidebar of agreement types. A row of KPI cards. The charts. And a bond-postings panel docked at the bottom.

The left sidebar (agreement filter menu) — what it shows

All agreements at the top = no filter (shows every agreement except Triparty, which is a separate world). Click an agreement to filter to it; click again to clear.
Each row = a coloured dot (the agreement's colour) + its name.
The orange number, e.g. “(30)”, is NOT the total number of agreements. It counts the individual agreements of that type with a margin call in the last 14 days. Hover it for the tooltip. Source: demo — roughly 30% of each type's individual agreements are flagged.
Triparty carries an extra amber dot meaning it has its own separate dashboard/world.
Agreements with sub-books show toggle buttons underneath. CCP only gets IM / VM. Bilateral CSA IM gets its custodians — Euroclear and Clearstream. Triparty gets its agents — Euroclear, Clearstream and BNY Mellon. Toggling includes/excludes that sub-book (at least one always stays on). GMRA and GMSLA are VM-only for now — they have no IM sub-book / toggle (single book).
CSA VM (BVM) shows a “Zero-interest only” filter button underneath (visible only when CSA VM is selected). Zero-interest is user-maintained, not a data flag. An agreement is zero-interest when it is tagged Zero-interest CSA on User maintenance → Special agreements. Nothing is pre-flagged. When the button is on, the individual-agreement views for CSA VM show only the tagged agreements. Click it again to clear. Nothing tagged yet means the button empties the list, which is the honest answer — no agreement has been called zero-interest. This is the only place zero-interest is stated. Changed 17 Sep 2026: it used to be generated, roughly one agreement in three.

US2.1 As a user, when I click a sidebar agreement type, then every card, chart and table filters to it.

🧪 Test cases for US2.1 4 scenarios

OVW-11 Sidebar “(n)” means margin calls, not total

Do: Hover the orange number next to an agreement in the sidebar.

Verify: the tooltip reads “N agreement(s) with margin calls in the last 14 days”. It is the recent margin-call count, not a count of all agreements.

OVW-01 Filter by agreement type

Do: In the left sidebar, click one agreement type (e.g. BVM). Then click it again. Then click All.

Verify: the first click filters every chart, table and KPI card to that type. The second click deselects it. All shows everything again.

OVW-02 Sub-book toggle

Do: Under an agreement that shows sub-books (custodian for Triparty; IM/VM for CCP), untick one sub-book.

Verify: figures update to include only the selected sub-books. You cannot deselect the last remaining one — at least one stays on.

OVW-02b CSA VM zero-interest filter

Do: On User maintenance → Special agreements, search BVM-001 and set its tag to Zero-interest CSA. Select CSA VM (BVM) in the sidebar and drill to its individual agreements. Then click the “Zero-interest only” button under CSA VM.

Verify: the individual CSA VM list narrows to BVM-001 alone. The button shows an active state. Clicking it again restores the full list. The button only appears when CSA VM is selected. Re-tag BVM-001 as Korean CSA and the list empties — one tag at a time, and only the zero-interest tag feeds this button.

US2.2 As a user, when I change the period, granularity or reference date, then every panel recomputes to that slice.

Checklist — filters & controls (confirm each is present & works)

Granularity — Daily / Monthly / Yearly
Quick range — 1M / 3M / 6M / 1Y / 2Y
From date
To date
View — Dashboard / Holdings table
Reference date (snapshot as-at)
Clear all selections
Agreement sidebar — All agreements, Bilateral CSA IM, Bilateral CSA VM, GMRA, GMSLA, CCP, Futures, Triparty (orange “(n)” = margin-call count, last 14 days)
Sub-book toggles (custodian or IM/VM)
CSA VM “Zero-interest only” filter (reads the Zero-interest CSA tag; shown under CSA VM when selected)

🧪 Test cases for US2.2 5 scenarios

OVW-03 Date / range / granularity

Do: Change the Quick range (e.g. 1Y → 3M), or the From/To dates, or the Granularity.

Verify: all time-series charts and snapshot tables re-compute together to the new period.

OVW-04 Chart cross-filter

Do: Click a bar in a chart (e.g. an agreement-type bar, or a Sources-of-collateral bar).

Verify: the bond postings table filters to what you clicked, and a removable filter chip appears. (The Bond-collateral-by-G7 donut is display-only.)

OVW-05 Exposure amount → drill

Do: Open the docked bond-postings panel in Summary view, or the Holdings-table view. Click a “Call / obligation” or “Total exposure” amount — they carry a dotted underline.

Verify: the Trade contributions drill opens for that agreement (see §7).

OVW-06 Posting amount → postings

Do: In the docked panel, click a “Total posting” or “Bonds” amount.

Verify: the bond postings table opens filtered to that agreement.

OVW-07 Clear all

Do: Apply a few filters, then click “✕ Clear all selections”.

Verify: agreements, sub-books, chart cross-filters, reference date and table filters all reset to default.

US2.3 As a user, when I open the Overview, then nine KPI cards and four charts show exposure, posting and composition.

Checklist — KPI banner cards (in this order, confirm each appears)

Total exposure
Total posting
Bonds posted
Cash posted
Total allocated
Bonds allocated
Cash allocated
Unallocated (shown green; it cannot go negative, because nothing can use more than was posted)
Received (inbound) — collateral received from counterparties (Week/Week delta)

These same nine figures are also used in: 1) US2.4 — the docked Agreement summary table. That table shows them a row at a time, instead of book-wide. Where each one comes from, and how to check it, is written up once. It is in Appendix E.1 · the Figure check sheet. Do not repeat those rules here.

Checklist — charts

Collateral utilisation history (bars = bonds/cash used by TMO; lines = total posted by G7 & exposure)
Total collateral by agreement type (GMRA / GMSLA / CCP split into IM & VM, like Bilateral)
Sources of collateral
Bond collateral by G7 industry group (pie) — driven by the G7 mapping table (§14). Anything unmatched falls to that table’s catch-all row
Single-chart view — Over time / By agreement / By source / By bond type

Note: two mini-tables were removed from the Overview. They were “Obligation & posting by agreement” and “Utilisation change by agreement”. The same figures live in the docked bond-postings panel and its Holdings-table view.

🧪 Test cases for US2.3 3 scenarios

OVW-19 KPI banner — all nine cards, in order

Do: On the Overview tab, read the KPI banner across the top of the charts.

Verify: the nine cards on the checklist above are all present, in that order. Unallocated is shown green and is never negative. Received (inbound) carries a Week/Week change.

OVW-20 All four charts are drawn

Do: Look at the chart grid below the KPI banner.

Verify: the four charts on the checklist above are drawn, each with a title and a legend. None is blank.

OVW-21 KPI cards agree with the postings table

Do: Note the Total posting KPI card. Open the docked postings panel in Summary view.

Verify: adding up the Total posting column over every row equals the KPI card. Bonds posted plus Cash posted also equals Total posting.

US2.4 As a user, when I switch the docked panel’s view, then the table behind the charts changes to that view.

Checklist — bond postings dock views

Summary / Detailed
Postings / Postings by bonds / Bonds Maturing / Triparty AOE (Triparty only)
Margin Calls
Maturing-only day threshold (7 / 30 / 90 / 180 / 365)
Special agreement filter (Postings, Postings by bonds, Bonds Maturing)
Column show/hide, reorder & pin (⚙)

The “Special agreement” filter — showing only the agreements the user has tagged

Some agreements are watched more closely than the rest. The user names them on User maintenance → Special agreements, and tags each one Zero-interest CSA or Korean CSA. A tagged agreement is a special agreement, of any agreement type. This filter cuts the blotter down to the postings booked to those agreements. It offers the tags that select agreements; Korean CSA drops its agreements from the app instead, so it is never a filter option here.

Where it sits. In the panel header, to the right of the “Maturing only ≤ N days” control. It is a label reading Special agreement and a drop-down beside it. Its tooltip reads “Show only the agreements tagged as special on User maintenance → Special agreements”.
Which views show it. Three: Postings, Bonds Maturing and Postings by bonds. It is hidden on Summary, Detailed, Margin Calls and Triparty AOE, because none of those lists postings.
What the drop-down offers. The options ARE the maintained list, never a fixed menu. The first is always All agreements, which is the default and turns the filter off. After it comes one option per FILTERING tag actually in use — today that is Zero-interest CSA, and only once an agreement carries it. Any special agreement appears only when there is more than one filtering tag in use, because with one it would just repeat that option. Tag nothing and the drop-down has its one option.
The tag that drops an agreement is never offered here. A Korean CSA agreement is dropped from the app, so filtering to it could only ever come back empty. The picker lists the tags that select agreements, never the one that removes them. Re-tagging the selected tag’s last agreement to Korean CSA therefore drops the filter back to All agreements by itself.
What it keeps. A named tag keeps only the postings whose agreement carries that tag. “Any special agreement”, when it is offered, keeps every posting whose Agreement Name is on the list with any filtering tag. An untagged agreement on the list is never kept — a tag is what makes it special.
How it stacks. It narrows the same rows the other filters do. So it adds to the date window, the chart cross-filters, the agreement selection and “Maturing only”. On Bonds Maturing that means: maturing within N days and tagged.
On Postings by bonds the filter is applied to the postings before they are rolled up into one row per bond. That view already answers for one agreement. So the filter either keeps that agreement’s bonds or empties the table. An empty table is itself the answer to “is this one special?”.
The line under the panel title says so. It gains “, special agreements only” for Any, or “, special agreements only — Zero-interest CSA” for a named tag. For example: “Bond postings as at 2026-06-18, maturing within 7 days, special agreements only — Zero-interest CSA”.
Untagging or removing an agreement while its tag is the one selected drops the filter back to All agreements by itself. The blotter is never silently filtered by a tag that no longer exists.

The “Postings by bonds” view — the bonds posted to ONE agreement, or to ONE triparty agent

The Postings view lists every posting across everything selected. Say the same bond was posted to the same agreement on several dates. It then appears once per posting date. Clicking an individual agreement name narrows this view to that agreement’s own postings. It then shows that agreement’s share of each amount. See US2.6 below. Postings by bonds answers a narrower question about a single agreement. That question is: “which bonds have we posted to this agreement, or to this triparty repo agent?” And: “how much of each is posted, allocated and unallocated?” It answers with one row per bond. That bond’s postings are added together.

The button is always there — it is never hidden, so anyone using the blotter can see the view exists. It fills in once the selection names the one thing it answers for. That is either of two things. (a) One individual agreement of a non-Triparty type — for example GMRA-002. You select it by clicking its name in any agreement list on this page. Those lists are Summary at Detailed level, Postings, Bonds Maturing and Margin Calls. You can also pick it in the Overview 2 Agreements widget. (b) One triparty agent. That means Triparty with only Euroclear, only Clearstream or only BNY Mellon left switched on. The agreement does not have to be the only agreement type on show. With the sidebar still on “All agreements”, clicking GMRA-002 is enough. The view narrows to that agreement’s own type by itself.
Until one of those is picked the view shows NO rows — it asks for the pick instead. Several selections leave it in this state. All agreements. A whole agreement type, such as GMRA as a whole. Several types at once. Several individual agreements at once. Or Triparty with more than one agent switched on. The reason is simple: “which bonds are posted to this one agreement” has no answer for a group. In place of the table it shows three lines. The heading is “Select an agreement to see the bonds posted to it”. Then a line reading: “Click an agreement name in the Summary or Postings list. For example GMRA-002.” Then a line reading: “For Triparty, pick one agent instead — Euroclear, Clearstream or BNY Mellon.” When more than one agreement is selected the heading changes. It reads “N agreements selected — this view shows one at a time”. Under that: “Click one agreement name on its own.” The line above the panel reads “The bonds posted to one agreement — or, for Triparty, to one agent.” This is deliberately NOT a list of everything. A list of everything would answer a different question. The view buttons and the column ⚙ stay in place throughout.
Why Triparty is the agent and not an agreement code. Triparty collateral is not booked under a standalone agreement code. It sits with the triparty repo agent. The agent administers the counterparties whose collateral it holds. So for Triparty, bonds are posted to the agent. That is what the view is scoped by. Its rows still show one row per agreement and bond (the agent’s own agreement codes, e.g. TRI_CLEARSTREAM_Upperby Bank), and the Custodian column repeats the agent.
One agreement (non-Triparty). Every row is that one agreement. So the Agreement Name column reads the same value on every row, for example GMRA-002. The amounts are that agreement’s share of its type’s book. An individual agreement holds a share of its agreement type’s collateral. The Agreement summary rows, the key figures and the agreement detail screen all use that same share. So all three always agree.
It is a pivot of the Postings view, aggregated by bond. The same bond can be posted to the same agreement, or agent, several times. Different dates, different amounts. Each one is its own line on Postings. Here they become one row. Original Amount, Posted (USD) and Allocated (USD) are the sum of those postings. Unallocated (USD) is Posted minus Allocated, as usual. Start date is the earliest of them. Worked example. Bond SGTAEZ1GFSY0 (MAS BILL 4% 05/27) under Triparty · BNY Mellon is posted twice. It is $19.7M from 29 Sept 2025, and $16.0M from 19 Mar 2026. This view shows one row of $35.7M starting 29 Sept 2025. Adding the postings up moves no money: for a triparty agent the column totals here equal the Postings totals exactly.
Because the row is the bond, two Postings columns are not shown here. The first is Agreement Name. Every row is the one agreement, or the one triparty agent, you selected. So the column would only repeat itself. The second is Trade #. A bond can have several postings, so no single trade number describes the row. Both identifiers belong to a posting, and the postings have been added together. The other columns are the same as Postings, and the ISIN column’s footer counts the rows as “N bonds”.
Two Triparty columns are shown, but never added up. When this view is scoped to a triparty agent it carries Profile Name and Set like the other posting tables. Both describe a single allocation, and this view's rows add allocations together, so where a bond's postings sat in more than one set the cell reads “2 sets” rather than picking one of them. Hovering names them in full. Same rule for Profile Name. See “Profile Name and Set” below.
Same date window and same cross-filters as Postings; it opens sorted by Posted (USD), biggest first. The “Maturing only ≤ N days” control belongs to Bonds Maturing and is not shown here.
The panel title names exactly what the rows cover. It reads “Postings by bonds — GMRA-002”, or “Postings by bonds — Triparty Clearstream”. While it is still waiting for a pick it reads just “Postings by bonds”.

Defaults & exact values (build) — filter bar initial state

Granularity default = Monthly (options Daily / Monthly / Yearly).
Quick range default = 1Y. The five buttons map to day counts. 1M is 30, 3M is 90, 6M is 180, 1Y is 365 and 2Y is 730.
From / To dates default to the 1Y range. To is today — the demo’s “today”. From is today minus 365 days.
View default = Dashboard (other option: Holdings table).
Bond-dock view default = Summary (per agreement type); summary grouping level default = Category.
Single-layout dimension default = Over time.
Maturing-only default = off; the day threshold field defaults to 7 (range min 1, max 730, step 1). Preset buttons: 7d / 30d / 90d / 180d / 1Y.
Special agreement default = All agreements (the filter off). Its other options exist only once agreements carry a filtering tag.
No agreement, sub-book, chart cross-filter or reference date is pre-selected (sidebar shows “All agreements”; reference label shows “● latest”).

Build notes — how figures are derived

All figures are deterministic demo data, generated in the browser. In plain English: the app invents its own sample numbers. It uses a random-number generator that always starts from the same fixed “seed”. So the “random” data is identical on every load. Nothing is fetched from a backend. See appendix A for FX, agreement types, bond types and sectors.
Total exposure = obligation + threshold. Total posting = bonds + cash posted. Total allocated is the posted collateral consumed covering exposure. It is worked out one agreement at a time. Each agreement is capped at the smaller of its own Total posting and its own Total exposure. Those capped figures are then added up across the selection. So spare collateral on one agreement never covers a shortfall on another. Bonds allocated / Cash allocated split each agreement’s allocated amount by its own posting mix, then add those up. Per agreement, Bonds allocated = Total allocated × Bonds posted ÷ Total posting. So Bonds allocated plus Cash allocated equals Total allocated. Unallocated = Total posting − Total allocated (the over-collateralisation left after covering exposure; ≥ 0). Received (inbound) = collateral received from counterparties (Week/Week delta). (Coverage ratio and Net-excess cards were removed.)
KPI deltas compare the reference date vs one week earlier (Week/Week).

Checklist — docked “Summary / Detailed” agreement table columns (the big table)

Summary is per agreement type. Detailed is per individual agreement. Under Triparty the individual rows are the counterparties the agents handle, because there are no triparty agreement codes. So switching an agent off in the sidebar takes its counterparties out of the list. Sortable/filterable; “Call / obligation” & exposure cells drill (§7), posting cells open Postings. The two levels show different columns. The exposure, dispute and base-currency columns appear only at the Detailed level. They are not on the type-level Summary.

▸ Agreement summary (per agreement type)

Agreement
Total exposure
Call / obligation
Received (in)
Margin call
Total Posting — a heading, not a column of its own. It spans the next three columns: Total, Bonds (Posted), Cash (Posted)
Total Allocated — the same shape: a heading spanning Total, Bonds (Allocated), Cash (Allocated)
Unallocated
Surplus
DoD (total allocated)
WoW (total allocated)
MoM (total allocated)
Threshold
Expected post
Expected collect

▸ Agreement summary — detailed (per individual agreement): all of the above columns, plus these

ITM Exposure
OTM Exposure
Dispute Value
Dispute Age
Base CCY
Base Total Exp.
Base Call Amt

Where these figures come from, and how to check each one is written up once. See Appendix E.1 · the Figure check sheet. It works each rule through with the app’s own live numbers. The same figures are also used in: 1) US2.3 — the KPI banner, which totals them across the whole book. 2) US3.2 — the Daily Exposure Report. That report repeats these seven detailed-level columns, and adds its own call-handling ones.

How these columns are headed. The posting and allocated figures are not six separate headings in one row. The header is two rows deep. The upper row carries a single centred heading, Total Posting, across the three columns it owns. Beside it sits Total Allocated, across its own three. The lower row names the three columns under each heading. Under the first: Total, Bonds (Posted), Cash (Posted). Under the second: Total, Bonds (Allocated), Cash (Allocated). The first column under each heading is called just Total. The heading above it already says which total it is. Sometimes a column has to be named on its own. That happens in the column chooser, the filter title, and this document. It is then written as the heading and the column together, e.g. Total Posting · Total. Every other column has no heading above it, so its name occupies both rows. That covers Agreement, Total exposure, Margin call, Unallocated, Surplus and the rest. Sorting, filtering, hiding, reordering and pinning work on the lower-row columns exactly as before. The heading is a label only, and is never clickable. The column chooser may hide or move part of a group. The heading then shrinks to span only the columns still sitting together. It never spans a column that does not belong to it.

Posting vs Allocated columns: Total Posting · Total = the collateral posted (Bonds (Posted) + Cash (Posted)). Total allocated is how much of that posting is actually consumed covering the exposure. It is capped at what was posted — the smaller of Total posting and Total exposure. Bonds (Allocated) / Cash (Allocated) split Total allocated in the same proportion as the posting. So they add back to Total allocated. Unallocated = Total posting − Total allocated (the collateral posted but not consumed; never negative). Surplus = Total allocated − Margin call. DoD / WoW / MoM show the change in Total allocated. They compare with the reference date 1, 7 and 30 days earlier, as an amount and a percentage.

Checklist — docked “Postings / Postings by bonds / Bonds Maturing” table columns

Two of the columns below belong to Triparty only. Profile Name and Set are things a triparty agent gives an allocation. Collateral under every other agreement type is booked under an agreement code and has neither. So those two columns appear on these tables only while Triparty is the agreement selected, and never on the cross-category views. Described in full under “Profile Name and Set” below.

Note: Postings by bonds shows the same columns except the first two. It has no Agreement Name: every row is the one agreement, or the one triparty agent, that was selected. That column would only repeat itself. It has no Trade # either: one bond can have several postings, so no single trade number describes the row. Its first column is ISIN. The row count sits in the ISIN footer as “N bonds”. It also has one column the others do not: Dirty Price, described below. So Postings by bonds shows 17 columns — the 18 listed, less the first two, plus Dirty Price. On the Triparty screens each of these tables carries two more: Postings and Bonds Maturing show 20, Postings by bonds shows 19.

Agreement Name
Trade #
ISIN
Security
Type
Sector
Counterparty
Agreement Type
Custodian
Profile Name (Triparty views only)
Set (Triparty views only)
Source
Start date
Maturity
Maturing in Days
Original Ccy
Original Amount
Posted (USD)
Allocated (USD)
Unallocated (USD)

These same 18 columns are also used in: 1) US7.2 — the exposure drill's Collateral Posted mode. Change a column here and it must change there too.

Profile Name and Set — Triparty views only

What they are. Triparty collateral is not booked under an agreement code. The triparty agent holds it and decides which bonds cover what, so the agent gives every allocation two labels of its own. Profile Name is the eligibility schedule the allocation was made against — the agreed list of what the receiver will accept, which the agent allocates within. Set is the agent's account bucket the individual allocation actually sits in. One relationship can run several sets with the same agent, and the same bond can be allocated into more than one of them.
Where they appear. On Postings, Bonds Maturing and Postings by bonds, whenever Triparty is the agreement selected. They sit immediately after Custodian — for Triparty the Custodian column is the agent, so the profile it allocated against and the set it allocated into read straight after it. They also appear on the same two screens the postings table is shown behind: the Postings tab of a Triparty agreement's detail window, and the exposure drill's Collateral Posted mode when it is showing Triparty. Every other agreement type shows neither column at all.
They belong to ONE allocation — they are never added up. This is the rule that matters. A profile and a set describe a single allocation. They are not amounts, so there is nothing to total, and a row covering several allocations has no single one of either to report. So: where a row is one allocation, the row shows its own profile and its own set. Where a row adds several allocations together, the cell says how many distinct ones the row covers instead — “2 sets”, “3 profiles” — and hovering it names them in full, separated by a middle dot. The cell must never show one of the values as if it stood for all of them, and must never be blank.
Which rows add allocations together. Only Postings by bonds, which is one row per bond with that bond's postings added up. Postings and Bonds Maturing are one row per allocation, so every cell there is a plain single value. The columns have no footer total on any of the three tables, for the same reason: counting distinct profiles across a whole book answers no question the table is asking.
Worked example, from the app's own numbers. Triparty · Euroclear, reference date 18 Jun 2026. Bond US0CUK6MR6W9 (US TREASURY BILL 0.875% 06/26), posted by Yarrowfield Bank, appears twice on Postings: $36.8M in set EOC-RABO-01 and $25.0M in set EOC-RABO-02, both against profile Euroclear Sovereign Core. On Postings by bonds those two become one row of $61.8M (36.8 + 25.0). Its Profile Name reads Euroclear Sovereign Core — one distinct value, so the value itself is shown. Its Set reads “2 sets”, and hovering shows EOC-RABO-01 · EOC-RABO-02. The same pattern on Triparty · BNY Mellon: SGTAEZ1GFSY0 (MAS BILL 4% 05/27, Orrinford Bank) rolls two allocations into one row reading BNY Mellon Sovereign Core and “2 sets” (BNY-CRMU-01 · BNY-CRMU-02).
How the two values are set. The profile is agreed per relationship — the same counterparty allocating the same kind of paper with the same agent is always allocating against the same profile — so a bond's several allocations normally share one profile, which is why the profile cell above still shows a value while the set cell does not. The set is per allocation: a second allocation of the same bond goes into the next set of that relationship. Set codes read agent · counterparty · set number, for example EOC-RABO-02 = Euroclear, Yarrowfield Bank, that relationship's second set. The three agent prefixes are EOC (Euroclear), CLS (Clearstream) and BNY (BNY Mellon).
A profile only ever holds what it admits. Each profile names what it accepts: a Sovereign Core profile takes government and public-sector paper, a Corporates IG profile takes investment-grade corporate bonds, and a Global Extended profile takes both. A bond is only shown against a profile that accepts its sector, so a corporate bond can never appear under a Sovereign Core profile. Checking this is the quickest way to spot a wrong allocation: read the Sector column against the Profile Name column on the same row.
Sorting, filtering and the column ⚙. Both are ordinary text columns: they sort A–Z, they filter like the other text columns, and they can be hidden, reordered and pinned like any other. A rolled-up cell sorts and filters on what it displays (“2 sets”), because that is what the row actually reports. The Triparty tables keep their own saved column layout, separate from the cross-category tables' — a layout saved on the cross-category blotter has no place for these two columns and must not strand them.
⚠ For the BA to confirm before build. The demo shows one profile per relationship and up to three sets under it, which is enough to show both cases on screen. Real triparty books can run many sets per relationship, and a relationship can have more than one profile at the same agent — for instance a separate profile per exposure type. The rules above hold either way (the value shows when there is one, the count shows when there are several), but the source of both fields — the agent's own allocation record, per agent — needs naming before build.

Dirty Price — Postings by bonds only

What it is. Bond prices are quoted clean: the quote leaves out the interest the bond has been earning since it last paid a coupon. The dirty price puts that interest back, and it is what a buyer actually hands over. So Dirty Price = clean price + interest accrued so far, quoted per 100 of face value, to two decimal places. It sits immediately before the money columns, after Maturing in Days.
It appears on Postings by bonds only — not on Postings, not on Bonds Maturing, not on the exposure drill. Those tables are unchanged.
Source. The bond's clean price — the very same price the instrument window shows in brackets beside MTM of notional — plus its coupon rate and maturity date, both already on the posting record. Nothing else is read, and no new field was added to the book.
How the accrued interest is worked out. Coupon dates are the maturity date's anniversaries, counted backwards a period at a time. The last coupon date on or before the reference date opens the period the bond is currently in, and the next one closes it. The bond has earned that period's coupon in proportion to how far through the period the reference date sits: one period's coupon, multiplied by the days elapsed since the last coupon date, divided by the total days in the period.
Worked example, from the app's own numbers. Take the bond with coupon 3.125% maturing 24 Jun 2026, at the reference date 18 Jun 2026. Its coupon dates are 24 December and 24 June. So the current period runs 24 Dec 2025 → 24 Jun 2026, which is 182 days, and by 18 Jun 176 days of it have passed. One period's coupon is 3.125 ÷ 2 = 1.5625. Accrued = 1.5625 × 176 ÷ 182 = 1.5110. Its clean price is 91.48, so Dirty Price = 91.48 + 1.51 = 92.99.
How to verify it. Click the bond's ISIN to open the instrument window and read the price shown in brackets beside MTM of notional — that is the clean price, and the Dirty Price column must always be that figure plus a small amount. The difference can never be negative, and can never be larger than one period's coupon (half the annual coupon rate). A bond sitting on its coupon date shows no difference at all.
There is no total. Prices are per 100 of face, so adding or averaging them across different bonds would not mean anything. The column footer is deliberately left empty.
⚠ For the BA to confirm before build — two assumptions. The book records a bond's coupon rate and maturity date, but not how often it pays, nor which day-count rule it uses. Both are still shown as “to be provided” on the instrument window. This column therefore assumes every bond pays twice a year, and that interest accrues on actual days over actual days in the period. Real books carry bonds that pay annually or quarterly, and other day-count rules are common. Both need confirming, and ideally both should become real fields on the instrument record, before this is built for production.

The five amount fields on a bond posting (they sit together at the end of the table, in this order). Original Ccy = the currency the bond is denominated in. Original Amount = how much of that bond was posted, counted in its own currency. Posted (USD) = that same posted amount converted into US dollars at the exchange rate. Allocated (USD) = the part of it the collateral team actually used to cover this agreement’s margin requirement. Unallocated (USD) is Posted (USD) minus Allocated (USD). It is collateral posted into the long box but not consumed. It is never below zero, and a fully-used posting leaves nothing unallocated. The “(USD)” in those three headings is the reporting currency — one setting for the whole Singapore entity (confirmed 26 Aug 2026), not something each posting carries its own answer for. The demo writes it into the headings and into the dollar sign on every amount; the real system should take both from that one setting, so changing it re-labels every screen. Worked example: Original Ccy SGD, Original Amount 1,000,000 → Posted (USD) 700,000 → Allocated (USD) 500,000 → Unallocated (USD) 200,000.

Checklist — Sources of collateral (bar values)

Interbank Repo
Flow Reports
HQLA
MI
CT
LMM
LRP

Checklist — cross-filter chips (removable “×”, above the postings table)

As at <date>
Active in <period>
<agreement>
Type: <bond type>
Source: <source>
<name> breakdown
<name> postings
<individual agreement name>

🧪 Test cases for US2.4 9 scenarios

OVW-08e Dirty Price is the clean price plus accrued interest

Do: Open Postings by bonds for one agreement. Note a bond’s Dirty Price, then click its ISIN and read the price in brackets beside MTM of notional in the instrument window.

Verify: the Dirty Price is that clean price plus a small amount. The difference is never negative, and never more than half the bond’s coupon rate. The column sits between Maturing in Days and Original Ccy, and shows two decimal places.

OVW-08f Dirty Price is on this tab only, and has no total

Do: Switch to Postings, then to Bonds Maturing. Then return to Postings by bonds and look at the row beneath the last one.

Verify: neither of the other two tables has a Dirty Price column. On Postings by bonds the footer cell under Dirty Price is empty — no total and no dash — while Posted, Allocated and Unallocated still carry theirs.

OVW-08b Postings by bonds — always visible; asks for a pick until it has one

Do: With all agreements showing, click “Postings by bonds”. Then select a single agreement type (e.g. GMRA) and look again. Then switch the table to Detailed and click the agreement name GMRA-002.

Verify: the “Postings by bonds” button is there at every step — it is never hidden. For all agreements, and for the whole GMRA type, the view shows no rows at all. In place of the table it reads “Select an agreement to see the bonds posted to it”. It tells you to click an agreement name. For Triparty, it tells you to pick one agent. The title is plain “Postings by bonds”. As soon as GMRA-002 is clicked, the message is replaced by that agreement’s bonds. The title becomes “Postings by bonds — GMRA-002”. Removing the GMRA-002 chip brings the message back. So does Ctrl+clicking a second agreement name, leaving two selected.

OVW-08c Postings by bonds — one agreement: one row per bond, amounts added up

Do: With GMRA-002 selected, click “Postings by bonds”. Read the title, the Agreement Name column and one row.

Verify: the title reads “Postings by bonds — GMRA-002”. The table starts at the ISIN column. There is no Agreement Name and no Trade # column. Every row is GMRA-002, and adds several postings together. No bond appears twice, and the ISIN footer counts them as “N bonds”. Each row shows that bond’s Posted (USD), Allocated (USD) and Unallocated (USD), with the other bond details. The amounts are GMRA-002’s share, so they are far smaller than the GMRA type’s postings. The whole column adds up to one figure. That is the type’s posted total for the same date window, multiplied by GMRA-002’s share of GMRA. You can read that share off the Agreement summary. It is GMRA-002’s posting divided by the all-GMRA posting. Widening the selection back to the whole GMRA type leaves you in the same view. It now shows the “Select an agreement…” message and no rows.

OVW-08d Postings by bonds — one triparty repo agent

Do: Select Triparty, then switch off Euroclear and BNY Mellon so only Clearstream is on. Click “Postings by bonds”.

Verify: the title reads “Postings by bonds — Triparty Clearstream”. You see only the bonds posted to that agent. Every Custodian cell reads Clearstream. There is no Agreement Name or Trade # column. The counterparty whose collateral each bond is stays on the row, in the Counterparty column. The Posted (USD) total equals the one the Postings view shows for the same one-agent selection. Rolling the postings up moves no money. Switching a second agent back on keeps you in the view. It goes back to asking you to pick one agent.

OVW-08 Holdings-table view[Layout: 1·Tabs only — the Dashboard/Holdings toggle]

Do: Set the View control to “Holdings table”.

Verify: the charts are replaced by a full-height bond postings table; switching back to “Dashboard” restores the charts.

OVW-09 Reference date snapshot

Do: Click the Reference date control and pick an earlier date. Clicking a bar in the history chart also sets a period.

Verify: the snapshot panels show values as at that date. Those are the tables, sources, bond-type pie and maturing bonds. The label switches from “● latest” to “historical”. Time-series charts still run up to that date.

OVW-10 Cross-filter chips

Do: Apply a chart cross-filter — by agreement, bond type, source or date. Then click the “×” on the chip that appears.

Verify: each active cross-filter shows a removable chip; removing it restores the unfiltered view.

OVW-12 Single-chart view (Single layout)[Layout: 4·Single only]

Do: Set Layout to “4 · Single”. Then work through the dimension toggle: Over time, By agreement, By source, By bond type.

Verify: one chart shows the chosen dimension. “Over time” shows Bonds and Cash bars, with Total-posted and Exposure lines. It has no Received line, matching the main history chart. “By bond type” is a doughnut split by SGS, UST, Corporates, Supra and Agency. Note it splits by bond type, unlike the Overview donut, which splits by G7 group.

US2.6 As a user, when I click an agreement name or its ↗, then it is selected, or its details open.

Selecting individual agreements — click the name; the ↗ arrow opens the details

Several lists show individual agreements. They are the docked table at Detailed level, and the Margin Calls list at individual level. They also include the Postings, Bonds Maturing and Postings by bonds blotters. In all of them each agreement name is a selector, with a small ↗ arrow beside it. Clicking the name selects the agreement; clicking the arrow opens the agreement detail popup. Agreement type names are unchanged. Those are the coloured type rows on the Summary view. They still drill into that type’s individual agreements.

Click a name → that agreement is selected, and only that one. The name turns into a solid highlighted pill. A removable chip with its name appears in the cross-filter chip row above the table.
Ctrl+click (Cmd+click on a Mac) → add or remove one agreement, keeping the others. Any number can be held at once, including agreements of different agreement types.
Clicking a selected name on its own clears it. The same click that selected it also unselects it. Ctrl+clicking a selected name removes just that one from the group.
Clearing: remove one agreement with the × on its chip. Clear everything with “✕ Clear all selections” in the header.
What the selection is for — it narrows the bond postings. Selecting an agreement narrows the Postings and Bonds Maturing blotters. They then show the postings that agreement holds, and nothing else. Select GMRA-002 and the blotter lists GMRA-002’s postings only. Select several and the blotter covers all of them together. When exactly one agreement is selected, the Postings by bonds view also fills in for it. See the section above. With none, or more than one, selected that view shows its ask-for-a-pick message instead. The Summary, Detailed, Margin Calls, Optimization and T+N Ladder views are not narrowed by it.
The agreement lists are never hidden. You pick agreements from the Summary and Detailed agreement tables. Those two show exactly the same rows before and after a selection. The selected names are simply highlighted. This is deliberate. If picking the first agreement filtered the list down to it, there would be no second row left to Ctrl+click. Only the bond postings blotters narrow.
How much of a posting an agreement holds. A bond posting is booked at agreement-type level — the whole GMRA book, the whole CCP book. So an individual agreement holds its share of its type’s postings. The Agreement summary rows, the key figures and the agreement detail screen already give it that same share. So the blotter keeps that agreement type’s postings. It shows the selected agreement’s share of each amount. Original Amount, Posted (USD) and Allocated (USD) are each multiplied by that share. Unallocated (USD) stays Posted minus Allocated. Selecting two agreements of the same type shows that type’s postings once, holding the two shares added together. Nothing is multiplied when the name you selected is a booking / portfolio code — see the next bullet.
Selecting a booking / portfolio code is an exact match. The blotter’s own Agreement Name column holds booking codes: CSG_Amberlaine Bank_RIM, GSG_Eskdale Life & Pension_VM, TRI_EUROCLEAR_JPM and so on. Those are recorded on the postings. So selecting one keeps its own posting rows, and leaves every amount at its full value. There is no wider book to take a share of.
Triparty is scoped by its agent. Triparty collateral is not booked under an agreement code. It sits with the agent — Euroclear, Clearstream or BNY Mellon. Each counterparty’s share is measured inside its own agent’s book. For Triparty, the individual agreements are its counterparties. Selecting one narrows the blotter to that counterparty’s agent’s postings. It shows that counterparty’s share of them. Postings by bonds is unchanged for Triparty. It is still scoped by leaving a single agent switched on in the sidebar.
Where the narrowed figures come from and how to check them. Source: the same bond postings the unnarrowed blotter lists — data set 15, Inventory / bond postings. Plus the selected agreement’s share of its type, which comes from the agreement static data, data set 6. Derivation: keep the postings of the selected agreement’s type, for the date window and cross-filters already in force. Then multiply each amount by that agreement’s share. Verification: show that one agreement type with nothing selected, and note the Posted (USD) total. Now select the agreement. The new total must equal the first total multiplied by that agreement’s share of its type. You can read that share off the Agreement summary at Detailed level. It is the agreement’s own posting divided by the type’s posting. Select every individual agreement of one type. The total must come back to the type’s own total, because their shares add up to the whole book.
Overview 2 is unchanged. Inside a workspace widget the Agreements widget is the selector. So there the agreement name still opens the detail popup on a plain click. No ↗ arrow is shown. Clicking a name selects only on the Overview tab.
The ↗ arrow beside every individual agreement name opens the agreement detail popup. It is the same popup, with the same tabs and contents, that the name itself used to open. See EPIC 6. Clicking the arrow does not change the selection.

🧪 Test cases for US2.6 6 scenarios

OVW-13 Click an agreement name to select it

Do: With All agreements showing, switch the docked table to Detailed and click the agreement name GMRA-002.

Verify: GMRA-002’s name turns into a solid highlighted pill. A GMRA-002 × chip appears in the chip row above the table. The Detailed list still shows every agreement it showed before — the list you picked from is not filtered down. And no popup opens. Click GMRA-002 again: the highlight and the chip both go away.

OVW-14 Ctrl+click to hold several agreements

Do: Click GMRA-002, then hold Ctrl (Cmd on a Mac) and click CCP-002. Then Ctrl+click CCP-002 a second time.

Verify: after the Ctrl+click both names are highlighted and both chips are shown. That holds even though they are different agreement types. After the second Ctrl+click only GMRA-002 is left highlighted, and only its chip remains. Removing a chip with its × unselects that agreement; “✕ Clear all selections” clears the lot.

OVW-15 The ↗ arrow opens the agreement details

Do: Click the small ↗ beside GMRA-002.

Verify: the agreement detail popup opens on GMRA-002, with its usual tabs. The selection is unchanged. If nothing was selected before, nothing is selected after.

OVW-16 Selecting an agreement narrows the Bond postings blotter to that agreement

Do: With All agreements showing, click Postings. Write down three things. How many rows are listed. Which agreement types appear in the Agreement Type column. And the Posted (USD) total in the footer. Now switch the table to Detailed, click the agreement name GMRA-002, and click Postings again.

Verify: the blotter now lists only postings whose Agreement Type is GMRA. Every other type has gone. The panel title reads “Bond postings — GMRA-002”. The line under it ends with “— GMRA-002’s share”. The GMRA-002 × chip sits above the table. Now remove the chip with its ×. The row count, the agreement-type mix and the Posted (USD) total all come back to what you wrote down. Switching to Bonds Maturing while GMRA-002 is selected keeps the same narrowing.

OVW-17 The narrowed amounts are the agreement’s share — and the shares add back to the book

Do: Select the GMRA agreement type in the sidebar and open Postings. Write down the Posted (USD) footer total. That is the whole GMRA book for the date window. Switch to Detailed and write down, for each individual GMRA agreement, its Total posting. Now click GMRA-002 and read the Postings total again. Then Ctrl+click every other GMRA agreement so they are all selected. Read the total once more.

Verify: with GMRA-002 alone selected, check the Posted (USD) total. It equals the whole-book total multiplied by GMRA-002’s share of GMRA. That share is GMRA-002’s Total posting divided by the GMRA total posting, both read off the Detailed table. The agreement detail screen and Postings by bonds use the same share, so all three agree. With every GMRA agreement selected, the total comes back to the whole-book total you wrote down first. The individual shares add up to the whole book. The row count does not change between those two. The postings are the same postings. Only the amounts are shared out.

OVW-18 Selecting a booking code on the blotter keeps its own rows, at full value

Do: On Postings with nothing selected, look at the first row. Note its Posted (USD) figure, and the name in its Agreement Name column — for example CSG_Amberlaine Bank_RIM. Click that name.

Verify: the blotter now lists only the rows whose Agreement Name is that code. That first row’s Posted (USD) is unchanged. A booking code is recorded on the posting itself, so nothing is shared out. The title reads “Bond postings — CSG_Amberlaine Bank_RIM”, and the line under it does not say “share”.

US2.5 As a user, when I click Optimization Rules in the sidebar, then the Rules engine fills the working area.

▸ Overview sidebar → Optimization Rules

To get here: Overview → left sidebar → “Rules Engine → Optimization Rules”. Or open an in-call agreement popup and click “▶ Optimize posting”.

What it is: this entry has no screen of its own. It shows the Rules engine — the same screen as the Rules engine tab. It fills the Overview’s working area, with the sidebar still beside it. It is written up in full in §11 Rules engine. Nothing about it is repeated here. Every control behaves exactly as §11 says, because it is that screen.

Developers: build ONE Rules engine and show it in three places. Never build a second look-alike. Two builds of one screen drift apart. The user is then shown two answers to the same question.

Checklist — what this story requires

Clicking Optimization Rules hides the Overview’s filter bar, charts and docked table. The Rules engine takes their place, filling the working area.
The sidebar stays on screen throughout. The Optimization Rules entry is highlighted while it is open.
This is the same Rules engine as the tab. Same saved runs, same rules, same run parameters, same results. A run made in one place is already in the other.
▶ Optimize posting on an in-call agreement popup closes the popup and opens the same screen. It does not narrow the engine to that agreement. A run covers the whole book.
Clicking any other sidebar entry leaves the Rules engine. That means an agreement, a static-data entry, or Inventory Manager. The Overview’s filters, charts and table come back.
Opening Inventory Manager while the Rules engine is open swaps to Inventory Manager. Only one of the two is ever on screen.
The Rules engine loads the first time it is opened, then stays loaded. Returning to it is immediate, and it keeps whatever was on screen.

🧪 Test cases for US2.5 3 scenarios

OVW-22 The Overview’s Rules engine is the Rules engine tab

Do: Open the Rules engine tab at the top of the app. Write down what the Active run box says. Write down the name of every run in its list. Go back to the Overview tab. Click Optimization Rules in the sidebar.

Verify: the same screen appears. The Active run box is there, with + New, Rename, Duplicate and Delete beside it. So are the four views: ☰ List, ◈ Visual, ▦ Overview, ⚠ Exceptions. So are the preview switch and the ▶ Run button. The run list holds the same names, in the same order. The Overview’s own filter bar, charts and docked table are hidden. The sidebar entry Optimization Rules is highlighted.

OVW-23 A run made here is there on the Rules engine tab

Do: Open Optimization Rules in the Overview. Click + New and name the run Sidebar check. Switch to the Rules engine tab. Open its Active run list.

Verify: Sidebar check is in the list, already selected. It was not typed twice. There is one set of runs, shared by both places. Delete it from either place. It is gone from both.

OVW-24 Leaving the Rules engine, and the Optimize posting route

Do: Open Optimization Rules. Click Inventory Manager in the sidebar. Click Optimization Rules again. Then click an agreement in the sidebar. Finally open an in-call agreement popup and click ▶ Optimize posting.

Verify: Inventory Manager replaces the Rules engine. Only one of the two is on screen at a time. Coming back to Optimization Rules shows it as you left it. Clicking an agreement brings back the Overview’s filters, charts and table. ▶ Optimize posting closes the popup and opens the Rules engine. It covers the whole book, not just that one agreement.

US2.7 As a user, when I click User Maintenance in the sidebar, then User maintenance fills the working area.

▸ Overview sidebar → Maintenance → User Maintenance

To get here: Overview → left sidebar → “Maintenance → User Maintenance”.

What it is: this entry has no screen of its own. It shows User maintenance — the same screen as the User maintenance tab. It fills the Overview’s working area, and the sidebar stays beside it.

Why it is here: the six datasets on that screen decide figures the Overview shows. A cost-of-funds rate, an industry-group mapping, a collateral source, an excluded agreement, an exposure adjustment, an added inventory row. Noticing a wrong figure and fixing its data should not mean leaving the Overview.

Developers: build ONE User maintenance screen and show it in two places. Never build a second look-alike. Two builds of one screen drift apart. The user is then shown two answers to the same question.

Checklist — what this story requires

The sidebar carries a Maintenance heading. Under it sits one entry, User Maintenance.
Clicking it hides the Overview’s filter bar, charts and docked table. User maintenance takes their place, filling the working area.
The sidebar stays on screen throughout. The User Maintenance entry is highlighted while it is open.
This is the same User maintenance as the tab. Same six datasets, same saved values, same upload buttons. A rate edited in one place is already edited in the other.
All eight sub-tabs are there, in this order: Cost of funds, G7 industry group, G7 by bond, Source of collateral, Special agreements, Adjusting exposures, Adjusting inventory, Tags & highlights.
Clicking any other sidebar entry leaves User maintenance. That means an agreement, a static-data entry, Optimization Rules, Optimization Results or Inventory Manager. The Overview’s filters, charts and table come back.
Only one full-area screen is ever open. Opening another swaps to it.
User maintenance loads the first time it is opened, then stays loaded. Returning to it is immediate, and it keeps whatever was on screen.

🧪 Test cases for US2.7 3 scenarios

OVW-25 The Overview’s User Maintenance is the User maintenance tab

Do: Open the User maintenance tab at the top of the app. Write down the six sub-tab names in order. Go back to the Overview tab. In the sidebar, under Maintenance, click User Maintenance.

Verify: the same screen appears, filling the working area. The six sub-tabs are there, in the same order you wrote down. The filter bar, the charts and the docked table are gone. The sidebar is still there, with User Maintenance highlighted.

OVW-26 A value edited here is edited on the tab

Do: Open User Maintenance in the Overview. Go to Special agreements. Add CSG_Amberlaine Bank_RIM, tag it Zero-interest CSA. Switch to the User maintenance tab at the top. Open its Special agreements screen.

Verify: CSG_Amberlaine Bank_RIM is already in the list, already tagged Korean CSA. It was not typed twice. There is one list, shared by both places. Remove it from either place. It is gone from both.

OVW-27 Leaving User maintenance, and one screen at a time

Do: Open User Maintenance. Click Inventory Manager in the sidebar. Click User Maintenance again. Then click Optimization Results. Then click an agreement name in the sidebar.

Verify: Inventory Manager replaces User maintenance. Only one of them is on screen at a time. Coming back to User Maintenance shows it as you left it, on the same sub-tab. Optimization Results replaces it in turn. Clicking an agreement brings back the Overview’s filters, charts and table.

US2.8 As a user, when I click Optimization Results in the sidebar, then the run’s answer fills the working area.

▸ Overview sidebar → Rules Engine → Optimization Results

To get here: Overview → left sidebar → “Rules Engine → Optimization Results”. Or press ▶ Run on Optimization Rules. Or press “Optimise to cover” on Triparty AOE. All three land here.

What it is: this entry has no screen of its own. It shows the Optimization Results screen, written up in full in §11 (US11.10 onwards). Nothing about it is repeated here.
Two ways to read a run, switched by two buttons at the top of the working area. They are Proposed allocation and Run views. Exactly one is highlighted at a time.
Proposed allocation is the default. It is the designed screen: the allocation the run proposes, with its Needs action section.
Run views shows the older run tables of §11 — the same Optimization Results screen the Rules engine produced.
Developers: build ONE results screen and open it from every door. Never build a second look-alike. Two builds of one screen drift apart.

Checklist — what this story requires

Clicking Optimization Results hides the Overview’s filter bar, charts and docked table. The results screen takes their place, filling the working area.
The sidebar stays on screen throughout. The Optimization Results entry is highlighted while it is open.
Two buttons sit at the top: Proposed allocation (selected by default) and Run views.
Proposed allocation shows the designed Optimisation results screen. Run views shows the Optimization Results tables of §11.
▶ Run on Optimization Rules, and “Optimise to cover” on Triparty AOE, both open this entry carrying the run.
Clicking any other sidebar entry leaves it. That means an agreement, a static-data entry, Optimization Rules, Inventory Manager or User Maintenance. The Overview’s filters, charts and table come back.
Only one full-area screen is ever open. Opening another swaps to it.
Each view loads the first time it is opened, then stays loaded. Returning to it is immediate, and it keeps whatever was on screen.

🧪 Test cases for US2.8 4 scenarios

OVW-28 Open Optimization Results from the sidebar

Do: On the Overview, click Optimization Results under Rules Engine in the sidebar.

Verify: the filter bar, the charts and the docked table are gone. The results screen fills the working area. The sidebar is still there, with Optimization Results highlighted. The Proposed allocation button at the top is highlighted.

OVW-29 Switch between Proposed allocation and Run views

Do: Click Run views. Then click Proposed allocation again.

Verify: only one button is highlighted at a time. Run views shows the run tables described in US11.10. Proposed allocation comes back exactly as you left it.

OVW-30 A run lands here by itself

Do: Click Optimization Rules in the sidebar and press ▶ Run.

Verify: the working area switches to Optimization Results without another click. The sidebar now highlights Optimization Results, not Optimization Rules.

OVW-31 Leaving Optimization Results

Do: With Optimization Results open, click GMRA in the sidebar.

Verify: the Overview’s filter bar, charts and docked table come back, filtered to GMRA. Optimization Results is no longer highlighted. Click it again and it opens immediately, as you left it.

US2.9 As a user, when I change the sidebar selection, then the note under the list tells me what is showing.

Checklist — the note under the agreement list (exact wording)

Nothing selected (All agreements): “Showing all agreements except Triparty (shown separately).”
One or more cross-category agreement types selected: “Showing N of 6 cross-category agreements.” N is how many types are selected. 6 is the number of agreement types other than Triparty.
Triparty selected: “Showing the Triparty dashboard (its own world — excluded from cross-category totals).”

Cross-category means every agreement type except Triparty. Triparty is kept out of the book-wide totals, because its collateral sits with the agent. The note is the one place that says so in words.
The note sits directly under the agreement list, in the sidebar. It updates on every click in the list, and on ✕ Clear all selections.

🧪 Test cases for US2.9 1 scenario

OVW-32 The note follows the selection

Do: Read the note under the agreement list with nothing selected. Click GMRA, then CCP. Then click Triparty. Then click All agreements.

Verify: it starts “Showing all agreements except Triparty (shown separately).” After GMRA it reads “Showing 1 of 6 cross-category agreements.” After CCP, “Showing 2 of 6 cross-category agreements.” After Triparty, “Showing the Triparty dashboard (its own world — excluded from cross-category totals).” All agreements restores the first wording.

EPIC 3

Margin Calls panel

ℹ︎ About this epic — where to find it & what the terms mean (click to expand)

To get here: Overview tab → the docked panel at the bottom → click the “Margin Calls” button. (This is the Daily Exposure Report view.)

What these terms mean (read before verifying columns)

Margin call = exposure − collateral posted. Positive → you must deliver collateral (a call); negative → unallocated you can recall. Action shows Call (collect) vs Delivery (post out).
Total Exposure = value at risk to be collateralised. ITM Exposure (in-the-money, green) = the part in your favour; OTM Exposure (out-of-the-money, red) = the part against you. Net Alternative = the same exposure under an alternative netting/valuation basis, shown for comparison.
STD Amount (AI) = the call amount your system calculates. Cpty Amount = the counterparty's calculated amount. Agreed Amount = the figure both sides agree; shows “Disputed” when the two differ beyond tolerance. Dispute Value = the gap; Dispute Age = days open.
Threshold = an unsecured amount allowed before any collateral is due. LRP = the margin-run / reporting frequency (e.g. Daily) — how often exposure is recalculated and calls raised.
Base CCY = the agreement's own currency; reporting is in USD. “Base …” columns show amounts in that base currency.
Where it comes from: every figure is computed in the browser. It uses each agreement's demo exposure and postings at the reference date. There is no live feed. In production the source is the daily margin engine and the counterparty statements. Full definitions in Appendix B.

US3.1 As a user, when I click Margin Calls, then the Daily Exposure Report opens and drills to agreements and disputes.

🧪 Test cases for US3.1 3 scenarios

MC-01 Open Margin Calls

Do: Click “Margin Calls”.

Verify: a KPI strip (6 tiles) appears above a wide table with one row per agreement and a totals footer.

MC-02 Drill to individual agreements

Do: Click an agreement name in the table (or switch the dock to Detailed).

Verify: the row expands to the individual agreements under that type, each with its own call status.

MC-03 Disputes

Do: Find a row whose “Agreed Amount” shows “Disputed”.

Verify: that row shows a non-zero Dispute Value (red) and a Dispute Age in days (amber); non-disputed rows show “—”.

US3.2 As a developer, when I build the report, then its tiles, call statuses, columns and derivation match this story.

Checklist — KPI tiles

Total Margin Call
Pending Review
Confirmed
No Call
Disputes

Checklist — call-status values

Pending Review
Margin Request Confirmed
No Call Required

Checklist — table columns (Daily Exposure Report)

Agreement
Category
Call Status
Action (Call / Delivery)
LRP
Base CCY
Total Exposure
ITM Exposure
OTM Exposure
Call / Obligation
Margin Call
STD Amount (AI)
Cpty Amount
Agreed Amount
Dispute Value
Dispute Age
Threshold
Net Alternative
Base Call Amt
Base Total Exp.
Notification Time
Resolve By
Credit Rating
Statement Status
Region

Eleven of these columns are shared with the docked agreement table. Those eleven are Total Exposure, ITM Exposure, OTM Exposure, Call / Obligation and Margin Call. Plus Threshold, Dispute Value, Dispute Age, Base CCY, Base Total Exp. and Base Call Amt. They are written up once in US2.4, and their source and check are in Appendix E.1. The rest of the list is specific to this report. The call-handling columns are Call Status, Action, LRP, STD Amount and Cpty Amount. Then Agreed Amount, Net Alternative, Notification Time, Resolve By and Statement Status. The row also carries Category, Credit Rating and Region.

Defaults & exact values (build)

Which agreements are “in call”: a flag on each agreement decides it. The flag is derived from the agreement's name. The name is turned into a stable number, so the choice is fixed rather than random. About 30% of individual agreements are marked as having a margin call in the last 14 business days. The same agreements are flagged every time the screen is drawn. This is the same count shown as the orange “(n)” in the Overview sidebar.
Obligation floor: each agreement's obligation is max(baseNow × 0.35, seasonal/weekday/quarter-end adjusted value). So exposure never collapses to zero in the demo. baseNow is the agreement's normal size, grown by its yearly trend. It is defined in plain English in Requirements 2, US9.8.
Dispute rows: a subset of rows carry a gap between the STD and Cpty amounts. Those rows read Disputed under “Agreed Amount”. They show a Dispute Value in red, and a Dispute Age in days in amber. All other rows show “—” in both.

🧪 Test cases for US3.2 3 scenarios

MC-04 Five KPI tiles and the three call statuses

Do: Open the Daily Exposure Report. Read the tile strip, then the Call Status column.

Verify: the five tiles on the checklist above are present. Every Call Status cell reads one of the three listed values, and nothing else.

MC-05 All 25 report columns are present

Do: Scroll the report right to the last column, checking against the column checklist above.

Verify: every column on the checklist appears, and no column appears that is not on it.

MC-06 Disputed rows and the agreements in call

Do: Find a row whose Agreed Amount reads “Disputed”. Then count the rows that carry a margin call. Compare with the orange “(n)” in the Overview sidebar.

Verify: a disputed row shows a red Dispute Value and an amber Dispute Age in days. Every other row shows “—” in both. The count of agreements in call is roughly 3 in 10, and matches the sidebar “(n)”. Refresh the page: the same agreements are flagged again.

EPIC 4

Bonds Maturing & Triparty AOE

ℹ︎ About this epic — where to find it & what the Triparty AOE view is (click to expand)

To get here: Overview tab → docked panel → “Bonds Maturing”. The Triparty AOE button appears only when Triparty is selected in the sidebar. (It was called “T+N Ladder” until 01 Oct 2026.)

What the Triparty AOE view is (read before testing MAT-02)

It is not drawn by this page. The button frames the designed Triparty dashboard as its own document under /aoe/. See the preamble: the three designed screens are served as files, not built from this spec.
Outstanding triparty RQV — RQV is the Required Value. It is the collateral the triparty agent asks you to hold. A bilateral desk would call it a margin call. One block per agent: Clearstream, Euroclear, BNY Mellon. Each opens to its dummy ISIN profiles, and each profile to its currencies.
Outstanding bonds in longbox — the same agents, opening to sector and then to individual bonds. It shows what is actually available to meet the RQV.
A “Possible bond short” banner appears when the longbox falls below the outstanding trades on any day. It names the agent and the span. Its “Optimise to cover” button hands the run to the Optimization Results screen (US2.8).
Columns are 15 business days counted from today, headed with real dates (06 Oct, 07 Oct, …). Weekends are skipped. If today is a weekend the first column rolls forward to the Monday.
There are no “T+0…T+5” columns and no country rows. Both belonged to the retired ladder.

Where the numbers come from (build note)

In this demo: the designed screen carries its own worked example. That is an RQV per dummy ISIN per currency, converted at a fixed FX table. So its figures are the design’s, not ones this app derives. The retired ladder’s data is still in the page and no longer read.
In production: source from the triparty custodian’s RQV and settlement-availability feeds — Euroclear, Clearstream or BNY Mellon. That is the required value per agreement per currency, and the projected settleable quantity per settlement date.

US4.1 As a user, when I tick Maturing only and set N days, then only bonds maturing within N days remain.

🧪 Test cases for US4.1 1 scenario

MAT-01 Bonds maturing filter

Do: Click “Bonds Maturing” and tick “Maturing only ≤”. Pick a day preset — 7, 30, 90, 180 or 365 — or type a number.

Verify: only bonds maturing within that many days remain. The “Maturing in Days” column is colour-coded: red at 7 days or less, amber at 30 days or less.

MAT-03 Bonds maturing, special agreements only

Do: Note one agreement name from the blotter’s Agreement Name column. On User maintenance → Special agreements, add it and tag it Zero-interest CSA. Come back to Bonds Maturing with 30d selected, and set the Special agreement drop-down to Zero-interest CSA.

Verify: every remaining row is that agreement, and every one still matures within 30 days — the two filters add up. The line under the title ends “, special agreements only — Zero-interest CSA”. Setting the drop-down back to All agreements brings the other rows back. Described in full in US2.4.

US4.2 As a user, when I select Triparty and click Triparty AOE, then the designed Triparty dashboard fills the dock.

Checklist — triparty agents

Euroclear
Clearstream
BNY Mellon

Checklist — what the Triparty AOE view shows

Two stacked blocks: “Outstanding triparty RQV” and “Outstanding bonds in longbox”
15 columns, one per business day counted from today, each headed with a real date (e.g. 06 Oct); weekends skipped
RQV block opens three deep: agent → dummy ISIN profile → currency. A “total (USD equiv)” line sits at each level
Longbox block opens two deep: agent → sector → bond, with an agent “total (USD equiv)” line
A “Possible bond short” banner, when short, naming the agent and the business-day span, with an “Optimise to cover” button
The as-at line reads “Clearstream · Euroclear · BNY Mellon · as at <first business day> · USD mm”

Defaults & exact values (build)

“Maturing in Days” colour thresholds: red when days are 7 or fewer (CSS due-soon). Amber when days are 30 or fewer (CSS due-mid). No colour beyond 30 days.
Maturing-only field: default value 7, min 1, max 730, step 1. Preset buttons render 7d / 30d / 90d / 180d / 1Y. Ticking “Maturing only ≤” turns the filter on. Clicking “Bonds Maturing” ticks it on by itself.
Special agreement drop-down: sits beside the maturing control and defaults to All agreements. It is written up once, in US2.4. It applies here exactly as it does on Postings.
The Triparty AOE button is shown only when Triparty is the selected agreement. The view is a frame of the designed Triparty dashboard, opened on its dashboard side. It fills the dock and brings its own scrolling.
The dock title reads “Triparty AOE”. The line under it reads “Dashboard, rules, optimisation logic and output for Triparty only”.
Selecting any non-Triparty agreement while this view is open drops the dock back to Summary. The button hides again.

🧪 Test cases for US4.2 2 scenarios

MAT-02 Triparty AOE dashboard (Triparty)

Do: Select Triparty in the sidebar, then click “Triparty AOE”.

Verify: the designed Triparty dashboard fills the dock. It shows the two blocks and the 15 dated business-day columns above. The dock title reads “Triparty AOE”. Click an agent row to collapse it, and a profile row to open its currencies. No “T+0…T+5” columns and no country rows appear.

MAT-04 Leaving Triparty drops the view

Do: With Triparty AOE open, click GMRA in the sidebar.

Verify: the dock returns to Summary, and the “Triparty AOE” button is hidden. Select Triparty again and the button is back.

EPIC 5

Static Data reference screens

ℹ︎ About this epic — where to find it (click to expand)

To get here: Overview tab → left sidebar → the “Static Data” group → click any item. Each opens a reference-data modal (fields are placeholders “to be provided”).

US5.1 As a user, when I click a Static Data item, then a modal lists that reference screen’s field set.

Checklist — Counterparty

Counterparty name
Short code / LEI
Legal entity
Country of incorporation
Credit rating
Default / netting status
Onboarding date

Checklist — Instrument

Instrument name
ISIN / CUSIP
Instrument type
Issuer
Currency
Coupon / callable
Maturity date
Rating

This is the reference record for a bond. The live attributes a user sees for one bond are also used in two places. 1) US8.2 — the instrument detail modal, in both its field sets. 2) US10.3 — the Inventory Manager's Column display fields.

Checklist — Holiday Calendar

Calendar code
Centre / region
Holiday date
Holiday name
Settlement impact
Source

Checklist — Portfolio

Portfolio / account code
Agreement type
Counterparty
Booking entity
Base currency
Owner desk

Checklist — Currency

Currency code
Currency name
Decimal places
Settlement lag (T+)
Holiday calendar

Checklist — FX Rate

Currency pair
Spot rate
As-of date / time
Source
Bid / ask
Inverse rate

Checklist — Interest Rate

Curve / index name
Currency
Tenor
Rate (%)
As-of date
Day count
Source

🧪 Test cases for US5.1 1 scenario

STAT-01 Open each reference screen

Do: Click each item in the Static Data group.

Verify: a modal opens titled “Static Data · [name]” listing that type's fields (values shown as “— to be provided —”).

EPIC 7

Exposure drill panel

ℹ︎ About this epic — where to find it (click to expand)

To get here: on the Overview tab, click a “Call / obligation” or “Total exposure” amount in a table. Those amounts carry a dotted underline. A full-screen drill overlay opens with a “← Back” button and a “Trade contributions / Collateral Posted” toggle.

US7.1 As a user, when I click an exposure amount, then a drill opens showing its trades or the collateral posted.

🧪 Test cases for US7.1 3 scenarios

DRILL-01 Opens in Trade contributions

Do: Click an exposure amount.

Verify: the drill opens titled “Trade contributions — [agreement]”, listing derivative trades (Product, Notional, MtM) — NOT bonds.

DRILL-02 Toggle to Collateral Posted

Do: Click the “Collateral Posted” toggle button.

Verify: the same panel re-titles to “Collateral Posted — [agreement]” and now lists bond postings (ISIN, Security, Custodian…).

DRILL-03 Show all agreements

Do: Click “Show all agreements”.

Verify: the table expands from one agreement to the whole book, staying in the current mode (trades or collateral).

US7.2 As a user, when I sort, filter or choose columns in the drill, then the list reshapes to my choice.

Checklist — Trade contributions columns (the panel is opened from one agreement, so it does not repeat that agreement down every row; an Agreement column appears in front of these only under “Show all agreements”, where the rows span the whole book)

Product
Trade ID
Trade date
Maturity
Notional (USD)
Ccy
MtM (USD)

Checklist — Collateral Posted columns

Same 18 columns as the docked postings table. They are written up once, in US2.4 → “docked Postings / Postings by bonds / Bonds Maturing table columns”. Nothing is added or dropped here. Sorting, filtering and column show/hide behave the same way in both places.

🧪 Test cases for US7.2 1 scenario

DRILL-04 Sort / filter / columns

Do: Click a column header to sort, use ⏷ to filter, and ⚙ to show/hide columns.

Verify: the table sorts, filters and shows/hides columns as chosen.

EPIC 8

Instrument detail modal

ℹ︎ About this epic — where to find it (click to expand)

To get here: click any ISIN or instrument name — they carry a dotted underline. They appear in the Overview bond postings tables and in the Inventory Manager table.

One window, wherever you open it from. The instrument window is the same window on both screens. The Overview shows it, and so does every Overview 2 widget that embeds the Overview. The Inventory Manager shows the same one. Same fields, same order, same “to be provided” block. Only the source of the values differs. The two screens hold different books. The Overview knows the bond as collateral it has posted. The Inventory Manager knows it as a trade it holds.

US8.1 As a user, when I click an ISIN or instrument name anywhere, then that bond’s detail modal opens.

🧪 Test cases for US8.1 2 scenarios

INSTR-01 Open instrument detail (Overview)

Do: In a bond postings / drill table, click an ISIN or security name.

Verify: a modal opens, titled with the instrument name. It lists the 23 fields on the US8.2 checklist, in that order. Under them sits a “Further fields — to be provided” placeholder block.

INSTR-02 Open instrument detail (Inventory)

Do: In the Inventory Manager table, click an ISIN or instrument name.

Verify: the modal shows the same field list in the same order as the Overview one, and the same placeholder block.

US8.2 As a developer, when I build the instrument modal, then both screens share the one field set listed here.

Checklist — instrument modal fields (identical on the Overview and in the Inventory Manager)

Instrument name
ISIN
Issuer
Type
Issuer country
Industry classification
Sector of issuer
Classification Level 4 name
BICS Level 2 Industry Group Name
Issuer Industry
G7 Industry group
Instrument currency
Coupon (+ Callable/Bullet)
Seniority
Clearer
Issuer rating
Bond rating
Bond notional
MTM of notional (+ price)
Issue date
Trade start
Maturity date
Deal status (Live to maturity / Terminates …)
Placeholders: Day count, Settlement (T+), Haircut, Accrued interest, Country of risk

The four classification fields (numbers 8–11) are worked out in US8.3. That story is where the matching rule lives. Ratings are shown as small rounded labels. Deal status is green when the position runs to maturity, red when it ends earlier.

These bond attributes are also used in three other stories. 1) US10.3 — the Inventory Manager's Column display fields. That is the row this modal expands. 2) US5.1 — the Instrument reference screen, the static record they come from. 3) US2.4 — the docked postings tables. There ISIN, Security, Type and Sector appear as columns.

Where each screen gets the values from

Inventory Manager. Every value is held on the trade itself. The inventory book (data set 15) carries the issuer, its country and its sector. It also carries the coupon, seniority, clearer and both ratings. And the face notional, the market value with its price, the trade’s start, its maturity and the date it ends.
Overview. This screen’s book is a book of postings, not trades. The same fields are filled from what a posting knows, plus the security’s reference details. The issuer’s country and sector come from an issuer reference list. The industry classification comes from the bond’s type. Singapore Government paper and US Treasuries are Sovereign, and so on. The clearer is the place the collateral sits. Trade start is the earliest date the bond was posted. Deal status says whether the pledge runs all the way to maturity, or ends before it.
Type is the security bucket each screen already groups its own book by. On the Overview that is the bond type — SGS, UST, Supra, Agency or Corporates, the same values the bond-type chart and the eligibility rules use. In the Inventory Manager it is the holdings category on the summary cards — Govies, Supra, Agency, Financials or Corporates. So the same Singapore Government bond reads SGS on the Overview and Govies in the Inventory Manager. Neither screen invents a value: each shows the bucket it already sorts by.
Issue date is not held on either book. Both screens work it out the same way, from the security itself. It is a whole number of years back from maturity, between three and ten. The number is fixed by the ISIN, so a bond always shows the same issue date. In the real system it is a stored field on the security.
The money figures on the Overview are the bond’s whole position in that book. US8.4 traces each one and shows how to check it.
In the real system both screens read one instrument master and one holdings source. The two windows are then literally the same record. In the demo each page keeps its own book. That is why the same-looking bond can carry different amounts on the two screens.

🧪 Test cases for US8.2 2 scenarios

INSTR-05 Overview modal shows the shared field set

Do: On the Overview tab, open a bond from a postings table. Check it against the checklist above, top to bottom.

Verify: all 23 fields are shown, in that order, and nothing else. The five placeholder fields appear under a “Further fields — to be provided” block.

INSTR-06 Inventory modal shows the SAME field set

Do: Open the Inventory Manager from the Overview sidebar and click any ISIN. Put that window beside the Overview one.

Verify: the field names and their order are identical on both screens. That includes the four classification fields, between Sector of issuer and Instrument currency. The same five placeholder fields sit at the bottom of both.

US8.3 As a user, when I open a bond, then I see its G7 group and the classification it matched on.

How the four classification fields are worked out

Directly under Sector of issuer the window shows four more fields. Both screens show them — the Overview modal and the Inventory Manager one. They are Classification Level 4 name and BICS Level 2 Industry Group Name. Then Issuer Industry and G7 Industry group. Issuer Industry is the bond’s own classification, read off the bond. It is what the bond is matched on, so it never changes with the table. The other three are read off one row of a mapping table. That table is maintained under User maintenance → G7 industry group (§14). The row used is the one this bond is matched to. They are never worked out any other way. So the card and the table can never disagree.
One bond can overrule the table. The user can set a G7 Industry group on a single ISIN, under User maintenance → G7 by bond (§14a). Where they have, the card’s G7 Industry group reads that value instead. The other three fields do not move: an override answers the G7 question, it does not reclassify the industry.
How the bond is matched to a row. Every bond carries an Issuer Industry. See §14 for how the demo derives it from the bond’s sector. In the Inventory Manager it comes from the trade’s industry classification, which reaches the same wording. Sovereign paper is GOVT NATIONAL. Supranational and agency paper is PUBLIC SECTOR. Banks are BANKS, and corporates are CORPORATE. It matches on Issuer Industry, ignoring upper and lower case. The bond takes the first row of the mapping table that matches. That row must also have its G7 Industry group filled in.
When nothing matches — the catch-all. If no row matches, the bond takes the last row of the table. That is the catch-all, where every column is the default. It reads “Others / Others / Others”, with whatever G7 group the user typed on that row. So the card’s first two classification fields and its G7 group read the catch-all row’s values. Its Issuer Industry still reads the bond’s own. No bond is ever left without a group.
Where to check it. Open User maintenance → G7 industry group. Find the row whose Issuer Industry equals the one on the card. The card’s Classification Level 4 name and BICS Level 2 Industry Group Name must be that row’s values. So must its G7 Industry group. If the card shows the catch-all row instead, that bond’s Issuer Industry is not in the table yet. Add a row for it and the card will follow. If only the G7 group differs, that bond has been set by hand on G7 by bond (§14a).
Worked example (the app’s own numbers). Say the mapping table reads GOVT NATIONAL → Credit - Financial and TRANS - NON RAIL → Credit - Non-financial. Open a UST bond, whose Issuer Industry is GOVT NATIONAL. It shows Finance / XYZ_IND_GRP / GOVT NATIONAL / Credit - Financial. Now open a Corporates bond. Its Issuer Industry, CORPORATE, has no row. It falls to the catch-all: Others / Others / CORPORATE / Others.

🧪 Test cases for US8.3 3 scenarios

INSTR-03 Classification fields come from the mapping table

Do: In User maintenance → G7 industry group, set the GOVT NATIONAL row’s G7 Industry group to Credit - Financial. Go to Overview and open any UST or SGS bond from a postings table.

Verify: under Sector of issuer the modal shows four values. Classification Level 4 name is Finance and BICS Level 2 Industry Group Name is XYZ_IND_GRP. Issuer Industry is GOVT NATIONAL and G7 Industry group is Credit - Financial. They are the same four values as that row of the table. Now open a Sovereign bond in the Inventory Manager. Those four fields read exactly the same there.

INSTR-04 Unmatched bond falls to the catch-all row

Do: Open a Corporates bond (its Issuer Industry, CORPORATE, has no row in the mapping table).

Verify: the card reads Others / Others / CORPORATE / Others. The first two fields and the G7 group come from the last row — the catch-all. Its G7 Industry group is Others by default. Issuer Industry still reads CORPORATE, the bond’s own. Now add a mapping row for CORPORATE, reopen the bond, and the other three fields switch to that new row.

INSTR-04a A bond set by hand overrules the table on the card

Do: Note the four values on any bond’s card. In User maintenance → 🔖 G7 by bond, find that ISIN and set its G7 industry group to Sovereign-linked bank. Reopen the card, on both screens.

Verify: G7 Industry group now reads Sovereign-linked bank, on the Overview modal and the Inventory Manager one alike. The other three fields are unchanged. Clicking reset on that bond puts the card back to the mapping table’s value.

US8.4 As a user, when I read a money figure on an instrument window, then I see where it comes from.

The three money figures — where they come from and how to check them

MTM of notional — the market value of the bond’s position. Inventory Manager: the market value held on the trade (data set 15). Overview: the bond’s whole position in the posting book — take every posting of that ISIN and add up their amounts in the bond’s own currency. To check it: open the Postings by bonds view and find the row for that ISIN — it rolls the same postings into one line. The postings tables restate those amounts as at the reference date, so a table row can read differently from the card; the card is the position across the whole book, not one day of it.
Price — the bond’s clean price, shown in brackets after the market value. It is the security’s price, out of 100. In the demo it is part of the seeded security data; in the real system it comes from a price source, which is not yet on the data-source catalogue — see the open questions in §E.14.
Bond notional — the face amount that market value stands for. Inventory Manager: the face amount held on the trade. Overview: worked out from the other two figures on the same card — the market value divided by the price, expressed out of 100. To check it: multiply the notional shown by the price shown and divide by 100; you must land back on the market value on the card.

Worked example — the app’s own numbers

Bond	Bond notional	Price	Notional × price ÷ 100	MTM of notional on the card
SINGAPORE GOVT 3.125% 06/26 (Overview)	48.1 mm SGD	108.49	52.2	52.2 mm SGD ✓
MAS BILL 0.625% 06/26 (Overview)	50.2 mm SGD	89.28	44.8	44.8 mm SGD ✓
ASIAN DEV BANK 3.625% 08/28 (Inventory)	3,250.1 mm USD	87.52	2,844.5	2,844.5 mm USD ✓

🧪 Test cases for US8.4 2 scenarios

INSTR-07 The two amounts tie to the price

Do: Open any instrument window on either screen. Multiply Bond notional by the price in brackets and divide by 100.

Verify: the answer equals MTM of notional on the same card, to the nearest 0.1 million.

INSTR-08 Trade start and Deal status follow the position

Do: On the Overview, open a bond that appears more than once in the postings table.

Verify: Trade start is the earliest of those postings’ start dates. Deal status reads Live to maturity (green) when the pledge runs to the bond’s maturity, and Terminates <date> (red) when the last posting ends before maturity — the date shown is that end date.

EPIC 10

Inventory Manager

ℹ︎ About this epic — where to find it & what the terms mean (click to expand)

To get here: open the Overview tab. In its left sidebar, under the Inventory heading, click Inventory Manager. The charts and the postings table are replaced by the Inventory Manager, filling the screen. Click any agreement, or any other sidebar entry, to go back. Or add the Inventory Manager widget inside Overview 2. Both show this same page. See Requirements 2 · Overview 2. It shows a summary bar of holdings by category. Top-right sits a “Snapshot as-at” date picker and a View toggle. Below them is a table of bond trades. The View toggle has three settings: the trade list (Column display), the same trades day by day (Time series of inventory), and those same trades added up into a two-attribute grid (Pivot table).

What these terms mean

Notional = face amount of the bond. MTM of notional = market value = notional × price. Summary cards total the MTM value (FX-converted to USD), with face notional shown underneath.
Seniority = rank in the issuer's capital structure (Senior Secured > Senior Unsecured > Subordinated…), which affects the bond's rating. Callable = issuer can redeem early; Bullet = repays only at maturity. Clearer = the settlement venue (Euroclear, DTC, Fedwire, CCP…).
Industry classification is Sovereign, Financial Institutions, Corporates, Supranational or Agency. It drives the summary categories: Govies, Financials, Corporates, Supra and Agency. Sector of issuer is the finer business sector.
“Snapshot as-at” is the date the inventory is shown for. A trade is live only between its start date and its maturity or termination date. So changing the date changes which trades appear.
Where it comes from: a book built in the browser, the same way every time. It holds 2 demo trades of each of the five issuer industries, so 10 in total. It is deliberately review-sized, so you can check it by hand. There is no live feed. Full definitions in Appendix B.

US10.1 As a user, when I change the Inventory Manager’s as-at date, then the book shows as it stood that day.

🧪 Test cases for US10.1 3 scenarios

INV-01 Summary bar + table on open

Do: On the Overview tab, click Inventory Manager in the left sidebar, under the Inventory heading.

Verify: a row of summary cards (Total + categories) appears above a table of individual bond trades.

Verify: the sidebar entry is highlighted. The Overview filter bar, charts and postings table are hidden. The Inventory Manager fills the space beside the sidebar.

Verify: click any agreement in the sidebar. The Overview charts and postings table come back, and the entry is no longer highlighted.

INV-02 Snapshot as-at date

Do: Change the “Snapshot as-at” date to an earlier date.

Verify: the trade list changes to only trades live on that date, and every summary card re-totals accordingly.

INV-03 Today reset

Do: Click “Today”.

Verify: the snapshot date resets to today and the table/summary update to today's live trades.

US10.2 As a user, when I switch to Time series, then each holding’s notional runs across the next 14 business days.

🧪 Test cases for US10.2 1 scenario

Do: Switch the View toggle to “Time series of inventory”.

Verify: each row shows a notional figure per business day, across the next 14 business days. A cell is green when that day's notional rose against the prior business day. It is red when it fell. Cells read “—” once a trade has matured or ended. Each date column has a total footer.

US10.4 As a user, when I switch to Pivot table and pick two attributes, then the book totals by them daily.

To get here: in the Inventory Manager, set the View toggle to Pivot table — the third option, after Column display and Time series of inventory.

What this view is

It is the same book of trades as the other two views, added up instead of listed. Nothing is added and nothing is left out. The other two views show you one line per trade. This one shows you totals, and lets you decide what those totals are grouped by.
The screen is divided into sections. Each section has a heading. Inside it is a small table: one row per category, one column per day. A Total line closes the section.
You choose the two groupings and the amount. Group by decides what the section headings are, and can be set to None for no sections at all. Row by decides what the rows are. Value decides which amount the cells add up. Change any of the three and the whole view is re-cut immediately. It always shows the same book — only the way it is sliced, and which amount is being counted, changes.
Every field of the Column display view is available here, under the same name, reading the same value. A field's own nature decides how it can be used, and that is the only limit: the text fields are things you can group by, and the amount fields are things you can count. An amount is not a category, so Bond Notional and MTM of Notional fill the cells instead of labelling the rows.

Reading the screen

Section heading — one section for each value of the field chosen in Group by. With the starting choice of Clearer, that is one section per settlement venue: CCP - LCH, Clearstream, DTC, Euroclear and so on. Sections are listed in alphabetical order. With Group by set to None there are no sections and no headings at all — the whole book becomes a single table of rows closed by one Total line.
Row label — the first column of each little table, one row per value of the field chosen in Row by. With the starting choice of Issuer Country, that is one row per country. Rows are listed in alphabetical order inside their section. The heading over this first column is the name of the field you picked.
Date columns — one column for every one of the next 14 business days, the same 14 days the Time series view uses, labelled with the day and month.
Each amount — the chosen Value for that day, added up over all the trades that sit in that section and that row, converted to US dollars and shown in millions. With the starting choice of Bond Notional, that is the face amount of those bonds held on the day; choose MTM of Notional instead and it is what that same holding was worth on the day.
A dash (“—”) means no trade in that group was being held at all on that day — they have all matured, or ended early, or had not started yet. It does not mean a zero balance.
Total line — the last line of each section, adding up the rows above it for each day.
Count line — under the whole view, how many trades are included and how many sections they fell into. With Group by set to None it just gives the trade count, since there are no sections to count.
Only real combinations appear. A section or a row is drawn only when it actually holds trades. The view never prints an empty grid of every possible pairing.

Where every figure comes from and how to check it

Source. The inventory book — the single shared list of bond trades this whole application runs on (data source 15, “Inventory data”). The fields used are: the two attributes you picked in the pickers, the amount of the bond held on each day, the bond's price when the chosen Value is MTM, and the bond's own currency. No other source is read.
How each amount is worked out. Take every trade that is live on the snapshot date. Keep the ones whose chosen Group-by value matches the section, and whose chosen Row-by value matches the row. For each of the 14 days, take the amount of each of those bonds held on that day, multiply it by that bond's exchange rate to US dollars, and add them together. If not one of those trades was being held that day, print a dash instead of a figure.
What “the amount held on that day” means for each Value. For Bond Notional it is the face amount held that day — exactly the figure the Time series view prints for that trade in that date column. For MTM of Notional it is that same day's face amount valued at the bond's price: face for the day, multiplied by the price, divided by 100. So the market value moves with the holding, day by day, rather than being frozen at the snapshot.
How the Total line is worked out. Add up the amounts printed in the rows immediately above it, column by column. It is the same numbers added together, so a section total can never disagree with its own rows.
How to verify an amount by hand. Set Value to Bond Notional and switch to Time series of inventory. Find the trades that carry the section's value and the row's value. Read their figures in the same date column, multiply each by its currency's rate to US dollars, and add them up — that must equal the pivot cell.
How to verify the whole view. Add every section's Total line for one day. That is the whole live book, in US dollars, on that day. Change either grouping to any other field, or set Group by to None, and read the Total again — the day's figure must not change, because re-slicing the book cannot change how much of it there is. If it changes, that is a defect. Setting Group by to None is the quickest way to run this check, since it puts the whole book on one Total line. (Changing Value is expected to change it: face amount and market value are two different amounts.)
Why a Total can differ by a million or two from the rows above it. Each row is rounded to whole millions for display, but the Total adds up the true, unrounded figures. So on a table with many rows, adding the printed rows by hand can land a million or so away from the printed Total. That is correct behaviour, not a defect — the Total is the more accurate of the two.
What it deliberately does NOT equal. It does not equal the face figure on the Total holdings card above. That card shows each trade's headline notional. This view shows the amount actually held on each particular day, and that amount moves during the 14 days. It also does not equal the Time series view's own column footers, because those are added up without converting currencies and this view converts every amount to US dollars first.

Behaviour of the three pickers

Group by and Row by each offer all fifteen text fields of the Column display view — the same fifteen in both lists, nothing withheld from either: Portfolio, Business Line, Holding, Instrument Name, ISIN, Instrument Ccy, Issuer Name, Issuer Country, Seniority of Bond, Callable / Coupon, Clearer, Sector of Issuer, Industry Classification, Issuer Rating, Bond Rating. That covers every field the user asked to be able to pivot on — the two ratings (Issuer Rating and Bond Rating), the currency of the bond (Instrument Ccy), the country of the issuer (Issuer Country) and the type of bond (Industry Classification, the field that drives the Govies / Supra / Agency / Financials / Corporates summary cards).
Value offers the two amount fields of the Column display view: Bond Notional (mm) and MTM of Notional (mm).
The list is not maintained separately. The pickers are built from the Column display column list itself, so a field added to that view appears here automatically, under the same name and reading the same value. The two lists can never disagree.
Group by additionally offers "None", listed first, above the fifteen fields. Choosing it removes the section layer completely: no headings, one table, one Total line covering the whole book. Row by has no None — there is always a row dimension.
Nothing is withheld from either list, and the same field may be used on both. Setting Group by and Row by to the same field is allowed; it simply gives one section per value, each holding a single row of that same name, so the row and its Total are identical. It is not an error state and is not blocked.
The three pickers are shown only while the Pivot table view is selected. They disappear on the other two views.
The column settings button (⚙) is hidden on this view, and so is the trade table. Showing, hiding, reordering and pinning columns applies to the trade table only — this view's columns are the 14 days and are not configurable.
All three choices are remembered between visits.

What happens with a real book — read this before building

This view draws one section and one row for every distinct value it finds. Most of the fields offered have a small, known set of values — a handful of portfolios, currencies, ratings, venues — so the view stays a readable size however big the book gets.
Four of them do not: Instrument Name, ISIN, Issuer Name and Callable / Coupon. These are close to unique per holding. On the ten-trade demo book they are perfectly usable, and they are offered because the user asked for every field to be available. But on a production book of thousands of trades, grouping by one of them prints a section or a row for nearly every trade — which is the trade list again, not a summary. The build must therefore page or cap the sections and rows, show an honest “showing 20 of 1,240” count rather than silently cutting the list off, and never render the whole book at once.
At production volume, this view must be produced by asking the system for the already-totalled figures for the two chosen fields and the 14 days. It must not fetch every trade in the book and add them up in the browser, which is what the demo does on its ten sample trades.

🧪 Test cases for US10.4 8 scenarios

INV-06 Opening the pivot view

Do: Switch the View toggle to “Pivot table”.

Verify: the trade table and the ⚙ column button disappear. Three pickers appear, reading Group by = Clearer, Row by = Issuer Country and Value = Bond Notional (mm). The panel title reads “Pivot of inventory — Clearer × Issuer Country”. Below it are sections headed by clearer name, each with one row per issuer country, 14 dated columns and a Total line.

INV-07 A section total equals its own rows

Do: Pick any section and any one date column. Add up that column's figures across the rows of the section.

Verify: the answer equals the section's Total figure in the same column, to the nearest million.

INV-08 Re-slicing does not change the amount

Do: Add up every section's Total line for the first date column. Then change Group by to Portfolio and Row by to Industry Classification, and add up every section's Total line for that same date column again.

Verify: the two answers are the same, to the nearest million. The sections and rows are completely different, but the total amount of book is not.

INV-09 Every field is offered, and none can be picked twice

Do: Open the Group by list, then the Row by list, while Group by is set to Clearer. Then open the Value list.

Verify: both grouping lists offer the same fifteen text fields — including Issuer Rating, Bond Rating, Instrument Ccy, Issuer Country and Industry Classification. Nothing is missing from Row by just because Group by is using it, and setting both to Clearer is accepted. Group by has one extra entry, "None", listed first, so it shows sixteen. The Value list offers exactly two: Bond Notional (mm) and MTM of Notional (mm).

INV-13 Group by None gives one flat table

Do: Note the first date column's Total on each section with Group by = Clearer and add them up. Then set Group by to None.

Verify: the section headings disappear and one table remains, with a row per Issuer Country and a single Total line. The title drops to "Pivot of inventory — Issuer Country" with no "×", and the line underneath reads just "10 trades shown" with no group count. The Total in the first date column equals the figure you added up, give or take a million from display rounding.

INV-12 Switching the Value re-totals the whole view

Do: Note a section's Total in the first date column with Value = Bond Notional (mm). Switch Value to MTM of Notional (mm).

Verify: every figure changes and the wording under the title changes to “MTM of Notional in USD mm per business day…”. The sections and rows are unchanged. The new figures are lower or higher than the face amounts according to whether those bonds price below or above 100.

INV-10 Cross-check one figure against the time series

Do: Note one row's figure in the first date column. Switch to “Time series of inventory”, find the trades carrying that section's and that row's values, and add their figures in the same date column after converting each to US dollars.

Verify: the two agree, to the nearest million.

INV-11 Snapshot date and view switching

Do: Change the “Snapshot as-at” date to an earlier date, then switch to Column display and back to Pivot table.

Verify: the pivot re-totals to the trades live on that date, and the summary cards re-total with it. Switching away and back keeps your two picker choices, and the trade table works normally on the other two views.

US10.3 As a developer, when I build the Inventory Manager, then its cards, controls, field sets and defaults match this story.

Checklist — summary cards

Total holdings
Govies (Sovereign)
Supra
Agency
Financials
Corporates

Checklist — controls

View: Column display / Time series / Pivot table
Snapshot as-at date
Today reset
Column show/hide, reorder & pin (⚙)
Per-column sort ▲▼ and filter ⏷
Group by (pivot view only)
Row by (pivot view only)
Value (pivot view only)

Checklist — Column display fields

Portfolio
Business Line
Holding
Instrument Name
ISIN
Instrument Ccy
Bond Notional (mm)
Issuer Name
Issuer Country
Seniority of Bond
Callable / Coupon
Clearer
Sector of Issuer
Industry Classification
Issuer Rating
Bond Rating
MTM of Notional (mm)

These same fields are also used in two other stories. 1) US18.1 — Adjusting inventory, where the user types new rows in. Every field except Holding is captured there. 2) US8.2 — the Inventory instrument detail modal, which shows the same attributes for one bond. Change a field here and it must change in both.

Holding & the single inventory source (build)

Holding says where the line sits. Internal means our own box. External-held means held for us at a custodian. Received means posted to us by a counterparty. Roughly 68% Internal, 22% External-held, 10% Received. It is fixed per trade — a stable value derived from the trade number. So it is the same on every load.
One inventory book for the whole app. The bond inventory is generated once, by a shared module called collat-inventory.js. Both the Inventory Manager and the Rules engine load it. So the two screens show the same book. The Rules engine no longer keeps its own separate list. Rows the user adds under User maintenance → Adjusting inventory flow into that same shared book. So does any uploaded production Inventory data, set 15. Both therefore appear on both screens.
Holding date. A line is HELD only between its start date and its end date. The end date is maturity, or an earlier termination. The amount held varies day-to-day inside that window — see the Time series view. So a snapshot shows only the lines live on the chosen date, at the amount held that day.

Checklist — Time series fields

ISIN
Instrument Name
Country of Issuer
Bond Ccy
One notional column per business day (14)

Checklist — Pivot table fields

Section heading = the chosen Group by field (absent when Group by is None)
Row label = the chosen Row by field
One amount column per business day (14)
Total line per section

The pivot adds no new field to the book. It is built from the Column display list above: its two grouping pickers offer the fifteen text fields of that list, and its Value picker offers the two amount fields — Bond Notional (mm) and MTM of Notional (mm). Add a field to the Column display view and it appears in the pivot automatically. See US10.4.

Defaults & exact values (build)

Book size is 2 trades of each of the five issuer industries. Those are Sovereign, Supranational, Agency, Financial Institutions and Corporates. That gives 10 demo trades. The book is deliberately small, so every figure on every screen can be checked by hand. Each trade is correspondingly larger. So the book's total value stays in its usual range, and the margin calls remain coverable. To repopulate with more dummy data, raise the single build number described in the developer note below — nothing else changes. Roughly 16% of trades are terminated before maturity. It is always the same trades on every load, never re-picked at random. So a snapshot only shows trades live on the chosen date.
Snapshot as-at defaults to the demo “today” = 2026-06-18; “Today” resets to it. The Time series view spans the next 14 business days from the snapshot date.
Default View = Column display (the other options are Time series and Pivot table).
Pivot table starting choice = Group by Clearer, Row by Issuer Country, Value Bond Notional (mm). All three are saved on the machine and come back on the next visit — including None, which is a real saved choice rather than an absent one; if nothing has been saved yet, or a saved choice is no longer an offered field, it falls back to that starting set. Amounts are shown as whole US dollar millions, the same way the summary cards above show them.
FX → USD (summary totals, and every amount in the Pivot table): USD 1.00, EUR 1.08, GBP 1.27, SGD 0.74, JPY 0.0064.
Summary categories map from Industry Classification: Govies (Sovereign), Supra (Supranational), Agency, Financials (Financial Institutions), Corporates.

🧪 Test cases for US10.3 1 scenario

INV-05 Instrument detail

Do: Click an ISIN or instrument name.

Verify: an instrument detail modal opens with that bond's attributes.

EPIC 11

Rules engine (opened from the Overview sidebar)

ℹ︎ About this epic — where to find it & what it does (click to expand)

To get here: click the top-level Rules engine tab. Or add the Rules engine widget inside Overview 2. That widget embeds this same studio. See Requirements 2 · widget lineage. It is an allocation-optimisation studio. At the top is a hero bar, with the run selector and Run. Below it is a rule library, shown as a Visual flow or a List. At the bottom is a drawer holding Inputs and Run-order. The run’s Output is not here: the Optimisation Results view sits at the bottom of the Optimization Results tab, under the rest of that run’s answers, and “▶ Run” takes you straight to it. This is NOT the Overview's Optimization panel (§2). This one is richer, with its own named runs, drawer and parameters.

What it does

You build a run: an ordered set of rules. They scope the book, restricting which inventory, calls and agreements enter. They rank cheapest-to-deliver. And they apply limits. Eligibility is NOT a user rule. What each counterparty accepts is fixed by that agreement's own eligibility schedule. The engine enforces it automatically. “▶ Run” then proposes the cheapest eligible collateral mix per agreement. It also shows the annual carry saving against an all-cash baseline.

US11.1 As a user, I can select and manage optimisation runs so I keep several named rule sets and switch between them.

🧪 Test cases for US11.1 1 scenario

RULE-01 Select / manage a run

Do: Pick a run from the selector. The seed runs are “Baseline (all GFM)”, “CSG agreements only” and “USD margin calls only”. Then try + New, Rename, Duplicate and Delete.

Verify: the run's rules and parameters load. + New creates an empty run, with no rules selected. Its Visual flow opens on a blank “Fresh run — no rules yet” page. The rule library is not shown until the run has at least one rule. You add rules with the + rule buttons on the input boxes. You can also switch them in from the ▦ Overview view. Duplicate creates a copy carrying the current run's rules. Delete removes the run, after a confirm.

US11.2 As a user, I can build, run and preview rules in List, Visual, Overview or Exceptions mode so I shape a run, trace its pipeline, read an at-a-glance summary, or see everything the run held out.

🧪 Test cases for US11.2 3 scenarios

RULE-02 Add a rule to the run, enable/disable it, reorder or edit

Do: Click a rule's toggle directly. The toggle sits on every rule in List, Visual and Overview. There is no need to open the editor first. Note the toggle means two different things. In List it enables or disables the library rule across all runs. In Visual and Overview it adds the rule to, or removes it from, the current run only. In List mode, also drag its priority up/down. Then click the rule's ✏ edit control to open the edit panel.

Verify: in Visual and Overview, flipping a rule's toggle takes effect on the spot. It adds the rule to the active run, or removes it. A rule that is not in the run is greyed, shows a “–” run order, and has its toggle off. So a brand-new run starts with every toggle off, and reads “0 active”. In List, the toggle enables/disables the library rule everywhere (disabled rules are greyed in every run). List order changes with the priority arrows. The ✏ control opens the edit panel. It slides in from the right of the screen, and is not a floating pop-up. It saves changes on Save.

RULE-03 Run the engine

Do: Click “▶ Run”.

Verify: the app moves you to the Optimization Results tab and scrolls to the Optimisation Results view at the bottom of it. That view fills with five things. A row of summary figures for the whole run. A search box with a match count beside it. Per-agreement allocation cards, eight to a page. An “Allocation by agreement” chart and a “vs All-cash baseline” carry chart. And a “Full posting detail” table, twenty-five rows to a page. See US11.9 for the search, the paging and which figures each total covers.

RULE-04 List / Visual / Overview + Preview

Do: Toggle “☰ List” / “◈ Visual” / “▦ Overview” / “⚠ Exceptions”; toggle the Preview button.

Verify: List renders the editable rule rows. Visual renders the input→group→output flow canvas. Overview renders a summary of the active run. Its rules are grouped into Scoping, Ranking and Limits. Each card shows the name, the condition in plain English, the run order and the active/off state. Each also carries an add-to-run / remove-from-run toggle. A Run-parameters panel shows the concentration cap, MTA, rounding, substitution buffer and Sweep the deck. ⚠ Exceptions renders every record the run held out and every data problem behind it — see US11.7. Preview shows/hides the active-run impact. The only interactive control on Overview is each rule's run-membership toggle. Enabling a rule across all runs, and every other rule detail, are edited in List.

US11.3 As a user, I can scope which rows of every input dataset enter the run so inventory, margin calls and agreements are filtered before ranking and limits run.

Input scoping — the Scoping rule group (build)

The Scoping rule group decides which rows of each input dataset enter the engine. It runs before eligibility, ranking and limits. Scoping applies to all three data inputs — inventory, margin obligations (individual agreement-level calls) and agreements — not only inventory.
Where “Cost (bps)” comes from today ⚑. Every holding carries a cost figure, and the Annual cost is worked out from it. Both come from a small built-in table of four buckets, by asset class and credit rating. They do not come from the cost-of-funds rates the team maintains in §13. This is raised as OQ-39. Switching the optimiser onto the maintained table is a decision, not a tidy-up. On today's demo data every holding would fall back to the Others row. They would all price at zero until the rates are populated.
Inventory scoping fields: Portfolio, Business Line, Clearer, Asset type, Industry and Holding. Then Currency, Rating, Haircut %, Cost of funds (bps), G7 industry group, In dataset, Maturity (yrs), Record age (days) and Concentration. The user-maintained fields (Cost of funds, G7 industry group, In dataset) are appended onto each inventory line; there is no separate Uploaded-dataset input source. (Seed scoping rules: “Include trading-desk portfolios only”, “Exclude stale inventory (>5 days)”.)
Margin-call scoping fields: Currency, Call size (mm), MTA (mm). The seed rules are “Margin calls in USD only”, “Margin calls > USD 100mm” and “MTA USD 150,000”. A margin call is kept only if it passes the call rules. Its agreement must also be in scope.
Agreement scoping fields: the engine can scope agreements on any agreement-level term now carried in Agreements static (set 6), grouped as below. This is the full term sheet, which is wider than what the agreement detail pop-up puts on screen — the pop-up shows the terms a collateral manager reads day to day, while the engine can scope on every term the agreement record carries:
- Identity / admin: Agreement name, Agreement ID, Agreement type, Agreement calculation type and Agreement category. Then Group, Entity, Counterparty name and Credit rating (S&P / Moody / Fitch). Then Agreement date, Agreement end date and Triparty / custodian. On a Triparty row that names the one agent handling that counterparty, not all three. Then Base currency, Reporting currency, Margin currency and Margin unit. And last Rehypothecation allowed, Governing law, Netting set, Region, Agreement status and Statement status.
- Margin call summary: Margin type, ABC MTA (mm) and Counterparty MTA (mm). Then ABC and Counterparty independent amount (mm), and ABC and Counterparty threshold amount (mm). Then Rounding rule (return) and Rounding rule (delivery). And last IA management, Delivery / return split, and Gross or net.
- Valuation & call schedule: Valuation frequency, Reciprocity, Notification time and Resolution time. Then LRP, Time zone, Holiday centre(s), Securities settlement delay (days) and Settlement delay (days).
- Collateral rules: Interest calculations method, Calculation rule, Interest settlement date, Allow negative effective rate.
- Rating floor (the eligibility-schedule minimum rating) remains available as a scoping field.
The seed rules are “Bilateral CSA agreements only” and “Settlement delay T+1”. An agreement scoped out takes all of its margin calls out of the run. Note: concentration limits and the eligibility rating floor are agreement-level too. But they are optimisation boundaries, not scoping rules. So they are not offered as agreement scoping conditions.
Concentration limit shown per agreement (single source of truth with the agreement pop-up). Each agreement's concentration limit is displayed in the Agreements input drawer. Open that with “↗ click to view” on the Agreements input box. It is not a scoping condition. It is an optimisation boundary the engine respects. The drawer's Concentration limit column shows the limit value + limit type + granularity (e.g. “20% Max · Per Issuer Country”, or “15% Max · Per Common Code”). Hovering the cell shows a tooltip with the full scope. That is the group, asset class, asset type, issuer sector, issuer country and basis. This reads the same stored concentration-limit record the individual-agreement detail pop-up shows. See US6.3. So the two views never disagree. The optimiser also uses this same limit value as the per-agreement posting boundary. It caps how much one line may supply to a call. The cap is the smaller of two figures: the run's Concentration cap parameter, and the agreement's own limit. Developer note: the mirror store is CONC_LIMITS in j-collateraldemo.html, read via concLimitFor(agKey). Each entry in the engine's AGREEMENTS array gets two fields. conc is the full record, for display. concLimit is its numeric value, used by optimise().
Eligible issuer groups shown per agreement (the eligible-security rule). The Agreements input drawer also shows an Eligible issuer groups (G7) column. It lists the issuer groups that agreement's eligibility schedule accepts. Those are Sovereign, Supranational, Agency, Financial Institutions and Corporates. Where the schedule sets no restriction it reads “Any issuer group”. Like the concentration limit this is displayed, not editable. It is an optimisation boundary the engine enforces, not a scoping condition. A margin call can only be filled from holdings whose issuer falls in one of these groups. Full rule and worked example in US11.6.
Record age = how stale the inventory record is versus the snapshot date. The optimiser pool is the canonical Bond Inventory, taken as at today's snapshot. It is the amount held on that date. So every live line's record age is 0. The “Exclude stale inventory (>5 days)” rule therefore excludes nothing in the demo. The field stays available for uploaded production inventory. That data carries real record and booking-update dates. There, a line older than the rule's threshold — 5 days by default — is scoped out.
Text conditions for name/currency fields: starts with, ends with, contains, equals, exclude (case-insensitive).
Input drawer, Preview and the Run effect. Click an input's “↗ click to view”. It shows that input filtered to the rows that pass the active run's rules. The header states how many were filtered out. It re-filters live as rules change. None of this alters the data. Turning on the 👁 Preview button lists every row instead, with the dropped ones marked in or out. It also puts an “N in scope · M out” badge on each canvas input box. Only Run actually removes out-of-scope margin calls and agreements. It re-aggregates each agreement's required amount from its in-scope calls only. A fully scoped-out agreement is dropped, and its requirement leaves the total.

🧪 Test cases for US11.3 1 scenario

RULE-05 View an input filtered by the active run's rules (all inputs, not just inventory)

Do: In the visual flow, click “↗ click to view” on an input box (Inventory, Agreements, or Margin Calls). Then, with the drawer open, enable or disable a Scoping-group rule — e.g. “Exclude stale inventory (>5 days)”, “Margin calls in USD only” or “Bilateral CSA agreements only”.

Verify: the drawer opens already showing the filtered result of the active run. Only the rows that pass the rules are listed. The header reads “N in scope, M filtered out by active run <run name>.” Now adjust any rule: enable it, disable it, edit it, add one, or switch the active run. Each re-filters the open drawer live. The impact is visible immediately, without pressing Run. To see exactly which rows dropped and why, turn on the 👁 Preview button. The drawer then lists every row, with the dropped ones dimmed. A Scope column gives the reason each fell out, in the cell and on hover. Each input box on the canvas shows an “N in scope · M out” badge. Pressing ▶ Run then actually drops the out-of-scope margin calls and agreements. The Output total requirement falls. The run log shows an “Input scope: X/Y margin calls · A/B agreements in scope” line.

US11.5 As a user, I can build a Scoping rule as a nested condition (And / Or / Not) so I can include or exclude records with rich logic, nested to any depth.

Scoping condition builder (build)

A Scoping rule holds a condition tree. A group combines child conditions and sub-groups. And means all must hold; Or means any holds. Not inverts the whole group. A condition is one field, operator and value test. The rule keeps a record when the tree is true. Every condition in one rule reads from the rule's single input source (Inventory, Agreements or Margin Calls). User-maintained data is not a source of its own — it is appended to each inventory line, so it is picked under Inventory (e.g. Inventory → Cost of funds (bps) > 5, or Inventory → G7 industry group is any of Supranational).
The operators and the value entry adapt to the field's type (this is the “based on the data's format” behaviour):
- Category / list fields are Portfolio, Business Line, Clearer, Asset type, Industry, Holding, Currency and G7 industry group (the group from User maintenance → G7 industry group, for that line's issuer). Their operators are is any of and is none of. The value is a multi-pick from that field's known values.
- Rating is the credit rating. Its operators are ≥ (at least), ≤ (at most), is and is not. The value is a rating from the ladder, AAA down to D. So “≥ A” means A or better.
- Number fields are Haircut %, Cost of funds (bps), Maturity yrs, Record age days, Call size, MTA and Settlement delay. Their operators are ≥, ≤, >, <, = and between. The value is a number, or two numbers for “between”.
- Text fields are Agreement name and Margin-call currency. Their operators are equals, contains, starts with, ends with and does not contain, all ignoring case. The value is free text.
- In dataset (an Inventory field) means a ring-fence or exclusion list. Its operators are is in dataset and is not in dataset. The value is which uploaded list to use.
Concentration is not offered here. A per-line concentration cap is a Limits rule, applied as a posting cap. It is not a keep-or-drop scope condition.
Backward compatible. A rule saved before the builder held a single include, exclude, min or max condition. It still runs unchanged. It opens in the builder as that one condition, ready to extend.
Developer build detail. The tree is stored on the rule as expr. A group is {op:"and"|"or", not:bool, kids:[node…]}. A condition is {field, cop, value}. cop is the condition operator. Its values are in/notin, gte/lte/gt/lt/eq/ne/between, and equals/contains/startswith/endswith/notcontains. It is evaluated by evalExprOn(record, source, node); a rule with no expr falls back to the legacy single-condition evaluation. Rules persist to aoe-re-rules.

🧪 Test cases for US11.5 1 scenario

RULE-06 Build a nested condition

Do: Edit a Scoping rule (✏), or add one. In the edit panel — the right-side slide-in — pick “Applies to (input data)”. Then in the condition builder, add conditions and sub-groups. Choose And or Or on each group. Toggle Not to invert a group.

Verify: each condition reads field → operator → value. The operator and value entry match the field's type. See the build note below. A record is kept when the whole condition is true. Save; the List / Visual / Overview views show the condition in plain English (e.g. “Currency is any of USD/EUR AND (Rating ≥ A OR Asset type is any of Govt)”). Editing runs entirely through the builder — Scoping rules no longer use the single Field / Condition / Value rows.

US11.6 As a user, I can trust a call is only covered with eligible securities, and see why each was picked so the recommendation is one I could defend to the counterparty and to audit.

How a recommendation is built — eligible securities first, then fill the call

This is the rule the engine follows for every margin call, in this order. Nothing about price or cost is considered until eligibility has already been settled.

Start from the call amount — what that agreement needs covering today.
Narrow the inventory to what this agreement will accept. Three tests, all of which a holding must pass:
- Asset class — the agreement's Accepts list (cash, government bonds, corporate bonds, money-market funds).
- Issuer group — the kind of body that issued the paper. It is expressed in the G7 industry grouping: Sovereign, Supranational, Agency, Financial Institutions or Corporates. Only holdings whose issuer falls in a group named on that agreement's eligibility schedule can be used. This is the test that stops the wrong paper being offered. Take an agreement that only accepts supranational issuers. It can never be covered with a corporate bond. That holds however much is in inventory, and however cheap it is.
- Rating floor — the minimum credit rating on the agreement's eligibility schedule.
Put what survives in order — cheapest to fund first. The run's matching strategy can override that. The alternatives are prefer internal holdings, prefer cash and government, and longest maturity first.
Work down that list and fill the call. From each holding take the smallest of three figures. What is still needed. What that holding actually has left. And the concentration boundary — the smaller of the run's Concentration cap and the agreement's own limit. Then move to the next holding. Keep going until the call is covered — one call is normally covered by several holdings, not one.
If the eligible holdings run out first, the run log says so. It reads “⚠ short $X — no eligible line left within rules”. The engine never reaches for an ineligible security to close the gap; a shortfall is reported, not papered over.

Worked example — how to read (and check) a recommendation

Agreement 1 has a $100mm margin call. Its eligibility schedule accepts supranational issuers only. Inventory holds $100mm of corporate bond A, $50mm of supranational bond 2 and $80mm of supranational bond 3.

Eligibility. Corporate bond A is dropped — its issuer group is Corporates, which is not on this agreement's schedule. The size of the holding is irrelevant. The eligible pool is bond 2 ($50mm) and bond 3 ($80mm).
Fill. Take all $50mm of bond 2 — that is everything it has, so $50mm of the call is still open. Take $50mm of bond 3, which closes the call. The remaining $30mm of bond 3 stays free for another call.
Recommendation: $50mm bond 2 + $50mm bond 3.

Two things that change the split, and only these two. (a) Haircuts. The agreement may value that paper at less than face. The engine then delivers more than the figures above, so the collateral value still adds up to $100mm. The run log shows both numbers, as “post $X → $Y cover”. (b) The concentration boundary. Say the agreement's concentration limit caps any one holding at 20% of the call. The same $100mm is then spread across more holdings, instead of two. With no concentration limit biting and no haircut, the answer is exactly $50mm + $50mm.

Where the issuer groups come from, and how to check any figure

The agreement's eligible groups come from its own eligibility schedule. They are the Issuer and Issuer type lines on its schedule pop-up. Reach that from the Overview screen (Epic 6). That schedule is part of Agreements static · 6. They are shown on screen in the Agreements input drawer, column Eligible issuer groups (G7).
A holding's own group comes from a mapping table. The user maintains it in User maintenance → G7 industry group (Epic 14). It turns each Issuer Industry into a G7 group. Until that table is filled in, a holding falls back to its own issuer-industry classification. That comes from the bond inventory (Inventory data · 15). Its values are Sovereign, Supranational, Agency, Financial Institutions and Corporates.
To check a recommended amount: take one agreement in the run log. Add up the “cover” figures of every posting under it. The total equals that agreement's call amount. If it does not, the log states the shortfall. To check a single posting, open the Inventory input drawer and find that holding. The amount posted can never exceed the market value it holds on the snapshot date. Its Industry must also be one of the groups named on the agreement's heading line.
To check that nothing ineligible slipped in. Each agreement carries a line reading “N of M inventory lines are eligible”. Then compare the issuer group in brackets on every posting with the agreement's eligible groups. Any posting outside those groups is a defect.

🛠 Developer build detail — eligible issuer groups (business readers can skip this)

Every inventory line gets it.g7, its issuer's G7 group. lineG7(it) looks the line's industry up in the user's mapping. That mapping is localStorage collat-g7-map, holding rows of {issuer, g7} keyed on Issuer Industry, upper-cased. It falls back to it.industry, then to "Unclassified".
Every agreement in the engine's AGREEMENTS array carries eligG7. It lists the groups its eligibility schedule accepts, transcribed from the schedule's Issuer line. The values are as follows. bvm and fut are ["Sovereign"]. bim, gmra and tri are ["Sovereign","Agency","Supranational"]. gmsla is ["Corporates","Financial Institutions","Supranational","Agency"]. ccp is ["Sovereign","Agency"]. An empty or absent list means no issuer-group restriction.
g7Ok(it, ag) is the test. optimise() applies it as a pool filter before ranking. It sits alongside the existing call.accepts.includes(it.type) and ratingRank(it.rating) <= ratingRank(floor) filters.
The fill loop takes takeColl = min(need, cap, avail[it.id]·(1−hc)) per line. Here cap = call.req · min(run concentration cap, ag.concLimit)/100. It then grosses up to a delivered market value, postMv = roundTo(takeColl/(1−hc), P.round), bounded by avail[it.id]. A line whose postMv rounds to zero is skipped. A residual under half the rounding increment counts as covered, via doneTol = max(0.01, P.round/2). That is what stops a queue of $0.0mm postings and a spurious “short $0.0mm”.

🧪 Test cases for US11.6 1 scenario

RULE-07 Check the recommendation only uses eligible securities

Do: Click “▶ Run”, then read the run log at the top of the Optimisation Results view (bottom of the Optimization Results tab). Pick any agreement's block. Note the eligible issuer groups named on its heading line. Then read the issuer group shown in brackets on each posting beneath it.

Verify: every posting under that agreement belongs to one of the issuer groups on its heading line. There is never a posting from a group the agreement does not accept. The same groups appear in the Agreements input drawer, under Eligible issuer groups (G7). They match the Issuer and Issuer type lines of that agreement's eligibility-schedule pop-up on the Overview screen.

US11.7 As a user, I can see everything the run left out and why so I can tell a deliberate exclusion apart from a data problem, without reading the run log line by line.

The ⚠ Exceptions view is the fourth setting of the view toggle, next to ☰ List, ◈ Visual and ▦ Overview. It answers one question: what did this run NOT use, and why? Nothing on it is stored or typed in. Every row is worked out afresh from the run you have selected, each time you open the view, so it can never disagree with the run itself.

What the view shows

A one-line summary naming the run, how many rules it is using, whether Sweep the deck is on or off, and the total number of exceptions.
Four count chips, one per category. A chip turns amber when its category has something in it.
Four sections, in this order, each with its own table and its own count.

The four categories

Inventory held out by the run’s rules — one row per inventory line the run’s scoping and limit rules removed before any matching started. Columns: Trade, Instrument, Line detail (asset type, rating, portfolio, market value), and Why it was held out.
Margin calls and agreements held out by the run’s rules — the same scoping rules applied to the other two inputs. Columns: Reference, Agreement, Record detail, and Why it was held out.
Obligations the run could not fully cover — calls that ran out of eligible collateral before they were filled. Columns: Agreement, Counterparty, Coverage detail (what was needed, what was covered, what the agreement accepts, its rating floor, its eligible issuer groups), and the shortfall with the number of lines that were eligible for that call.
Missing or invalid values — data problems in what the engine reads. Each row is one distinct problem with a count of the records it affects, never one row per record, so a book with five thousand unmapped lines is one exception and not five thousand. Today it reports: an issuer industry with no G7 industry group mapped; a security type and currency with no cost-of-funds rate maintained; lines with no rating; lines with no market value; lines with no maturity date; and Sweep the deck being off while no existing-postings data is loaded (which does not arise today, because that data is loaded — the check stays so it can never go unnoticed if it stops being).

Where each figure comes from and how to check it

Every count chip and every section count = the number of rows in that section’s table. To check one, count the rows.
The total in the summary line = the four section counts added together. To check it, add the four chips.
Each “Why it was held out” reason is the same sentence the run log prints for that record. To check one, press ▶ Run and find the record in the run log — the wording must match.
A shortfall figure = what that obligation needed, less what the run managed to cover. To check one, open the Optimisation Results view at the bottom of the Optimization Results tab, find that agreement’s card, and subtract the collateral value posted from the requirement shown.
A “records affected” count = how many inventory lines carry the value that is missing. To check one, open the Inventory input and count the lines with that industry, security type and currency, or blank field.

Behaviour with production volumes

Each section shows at most 100 rows. When there are more, a line underneath says exactly how many there are and how many are not shown — for example “Showing 100 of 1,240 — 1,140 more not listed here.” A list is never cut short silently.
A section with nothing to report says so in words. It is never padded with made-up rows.
The real system asks its source for the records of the chosen run only. It does not read the whole book into the browser and filter it there, which is what the demo does at demo size.

🧪 Test cases for US11.7 3 scenarios

RULE-14 Open the Exceptions view

Do: On the Rules engine tab, with the run Baseline (all GFM) selected, click ⚠ Exceptions.

Verify: four sections appear, each with a count. “Inventory held out” lists TRD-700003 Fernhollow Bank HOLDINGS 4.875% 03/32, reason “Portfolio Treasury ALM not in include-list”. “Calls & agreements held out” shows 0 and says there is nothing to report. “Not fully covered” lists GMSLA, Futures, Bilateral CSA VM and CCP. The chip counts equal the section counts, and the total in the summary line equals the four added together.

RULE-15 A rule change moves the exceptions

Do: In ▦ Overview, switch the rule “Include trading-desk portfolios only” out of the run. Go back to ⚠ Exceptions.

Verify: the “Inventory held out” count drops by one and TRD-700003 is gone from the list, because the rule that was excluding it is no longer in the run. Switch the rule back on and the row returns.

RULE-16 The reason matches the run log

Do: Note the reason text on any row of “Inventory held out”. Then click ▶ Run and read the run log.

Verify: the run log gives the same reason for the same record. The two surfaces never disagree, because both read the same rule evaluation.

US11.8 As a user, I can choose whether the run starts from a clean deck or tops up what is already posted so I can either re-optimise the whole book or propose only the extra collateral needed today.

Sweep the deck is a run parameter, set in the Run parameters panel next to the concentration cap, minimum transfer amount, rounding and haircut buffer. It is saved with the run, so each run remembers its own setting. It has two settings.

On — claw back everything, re-optimise from scratch. The run assumes every piece of collateral currently posted is returned to us first. Each obligation then has to be covered in full, out of the whole pool. This is the setting to use when you want the best possible mix for the book as a whole, ignoring what happens to be posted today.
Off — keep what is posted, top up only. Whatever is already posted stays exactly where it is. Each obligation only needs the difference making up, and any collateral already pledged out is not offered again, because it is not ours to post. This is the setting for the normal daily top-up.

On is the default, for new runs and for the three runs the app starts with.

Where the “already posted” figures come from

They come from the Collateral used data set — data set 14 in the master list — using only its Delivered rows, which are the lines we have posted out and have not had back. Two figures are read from it:

What an obligation already has covered = add up the collateral value of every Delivered row for that agreement. The obligation’s top-up is then what it owes, less that amount, and never below zero.
What an inventory line has left to give = its market value, less the market value of that same instrument already delivered out. Never below zero.

This data set is not loaded yet. Data set 14 is catalogued but not yet connected to a live source, so the app holds no existing-postings rows today. Nothing is invented to fill the gap. Until real rows are loaded, a Sweep-off run has nothing to retain and produces exactly the same proposal as a Sweep-on run — and it says so, in the run log and as a “Missing or invalid values” exception, rather than letting the two settings look identical for no visible reason.

Worked example — how the figures move

Take GMRA, which owes $567mm across its two sub-agreements, in a book owing $1,757mm in total. Suppose one Delivered row is loaded against GMRA: an Asian Development Bank bond, $105mm of market value posted, worth $100mm of collateral value after its haircut.

Figure	Rule	Sweep the deck ON	Sweep the deck OFF
GMRA already covered	Add up the collateral value of GMRA’s Delivered rows; on is always nothing	$0mm	$100mm
GMRA still to cover	What it owes, less what it already has covered	$567mm	$467mm (567 − 100)
Whole book still to cover	Add up every obligation’s still-to-cover figure	$1,757mm	$1,657mm (1,757 − 100)
Inventory not available	Market value of instruments already delivered out	$0mm	$105mm
Asian Development Bank line left to give	Its market value, less the $105mm already delivered out	its full market value	its market value − $105mm

To check any of these on screen: press ▶ Run and read the run log. Its third line states the setting, the collateral value retained and the market value unavailable. Its fourth line states the still-to-cover total against the total owed. Each obligation’s own line states what it still needs.

Where each figure it changes comes from

“Requirement covered” on the Optimisation Results view is measured against what this run had to find — the still-to-cover total, not the total owed. On a top-up run it is therefore the coverage of the top-up. To check it, divide the collateral value posted by the still-to-cover figure in the run log.
The note under the posting table states the setting in words, and on a top-up run states how much collateral value was retained.
An obligation that is already fully covered by existing postings is not reported as skipped for being under the minimum transfer amount. Its run-log line reads “nothing to top up” instead, so a covered call is never confused with a call too small to bother with.

🧪 Test cases for US11.8 3 scenarios

RULE-17 The setting is saved with the run

Do: In ☰ List mode open the Run parameters panel, set Sweep the deck to Off. Switch to another run, then switch back. Reload the page.

Verify: the run you changed still reads Off, and the other run still reads On. The ▦ Overview run-parameters panel shows the same setting in words.

RULE-18 Off keeps what is already posted, and says how much

Do: With Sweep the deck Off, click ▶ Run and read the run log. Then open Optimization Results and read the totals on Where the bonds are posted today.

Verify: the run log says the setting is off, that existing postings stay in place, and names what it kept: $1,159mm of collateral value retained and $1,173mm of inventory market value already pledged and unavailable. Those are the same two figures as that table’s Collateral value and Market value totals, over its 19 lines. The requirement the run still has to cover reads $598.2mm rather than the $1,757.0mm owed, because the rest is already posted. If the existing-postings data (set 14) were ever empty, the run log would instead warn that nothing could be retained and the run behaves like a Sweep-on run, and ⚠ Exceptions would carry the matching row under “Missing or invalid values” naming data set 14 — the run never lets the two modes look silently identical.

RULE-19 On is unaffected by existing postings

Do: With Sweep the deck On, click ▶ Run.

Verify: the run log’s third line says every existing posting is clawed back. Each obligation’s line asks for the full amount owed — GMRA needs $567mm — and the total is $1,757mm, with no “still to cover” wording, whatever existing-postings rows exist.

US11.4 As a developer, I can reproduce the controls, parameters, output columns and seed runs so the studio rebuilds exactly — inputs, rule groups, parameters & persistence keys.

Checklist — hero-bar controls

Active run selector
+ New
Rename
Duplicate
Delete
☰ List / ◈ Visual / ▦ Overview / ⚠ Exceptions toggle
👁 Preview toggle
▶ Run
(List mode) + Add rule / Load preset / Clear

Checklist — input categories

📦 Inventory
🔔 Margin obligations
📄 Agreement details
🏦 Bond static data — reference attributes per eligible collateral class. They are Asset class, Asset type, Issuer, Issuer type and Issuer country. Then Currency, Seniority, Security rating, Time to maturity, Haircut schedule and Exclusions. They are the same fields as an agreement's eligibility-schedule pop-up. Read-only reference input (no "+ rule").
🗂️ Portfolio static — the book's portfolios with their static attributes (Portfolio name, Close entity, PC Code, Desk, Book, Product Lines, Product Franchise). Read-only reference input (no "+ rule").
⤓ Cost of funds & lists
⚙ Parameters

Checklist — rule groups

Scoping
Ranking
Limits

Eligibility is not a user-set rule group. What a counterparty accepts is fixed by that agreement's own eligibility schedule. It sets the accepted asset types, the accepted issuer groups in the G7 industry grouping, and the rating floor. The optimiser applies all three automatically to every posting. See US11.6. Users restrict only their own inventory pool, via the Scoping group.

Checklist — matching strategies

cheapest-to-deliver
prefer internal holdings
prefer HQLA (cash / govt)
post longest maturity first

Checklist — sub-rule choices on a ranking rule (see US11.22)

— none — leave the order inside a bucket to the next rule
biggest inventory line first

Checklist — Run parameters (drawer)

Concentration cap (% per line)
Min transfer amount ($mm)
Rounding ($mm)
Haircut buffer (%)
Sweep the deck (On / Off)

Checklist — Output “Full posting detail” table columns

Agreement
Asset
Type
Holding
Post (mv)
Haircut
Collateral value
Cost (bps)
Annual cost
Action

Checklist — Rule-edit panel fields (opens as a right-side slide-in panel, not a floating pop-up)

Name
Group (Scoping / Ranking / Limits)
Scoping rules — a condition builder replaces the single Field / Condition / Value rows. See US11.5. It has an “Applies to (input data)” source picker, and a nested And/Or/Not condition tree.
Limits rules — the simple single-condition editor (Input source / Filter by field / Condition / Value / criteria).
Ranking rules — a Rank by picker (Asset type rank / Industry rank), the ordered bucket list with ↑/↓ on every row, and a sub-rule nested under that list. See US11.22. The run's matching-strategy rule also sits in this group and keeps its own single drop-down.
Note
Enabled
🗑 Delete rule — shown only when editing an existing rule (hidden while adding a new one). Asks “Delete rule "{name}"? This cannot be undone.” before removing the rule from the library and from every run's selection.
Cancel / Save rule

Defaults & exact values (build) — seed runs & parameters

Three seed runs load on first open (persisted to localStorage aoe-re-runs / active run aoe-re-active):
1. Baseline (all GFM) — Concentration cap 35% per line and Min transfer amount 0.15 $mm ($150K). Rounding 0.15 $mm, Haircut buffer 0.5%.
2. CSG agreements only — same params except Concentration cap 30%.
3. USD margin calls only — same as Baseline (cap 35%).
+ New run defaults to Concentration cap 35% and Min transfer amount 0.5 $mm. Rounding is 1 $mm and Haircut buffer 0.5%. It starts as an empty run, with no rules selected — you add the rules you want. While the run has no rules, the rule library is not shown. The Visual flow shows a blank “Fresh run — no rules yet” page instead. Rules appear as you add them. Add them with the + rule buttons on the input boxes. Or switch existing rules in from the ▦ Overview view. Use Duplicate instead if you want a copy of the current run's rules.
Parameter field steps: Concentration cap step 1, Min transfer amount step 0.5, Rounding step 0.1.
Rules, runs and the active run all persist to localStorage (aoe-re-rules, aoe-re-runs, aoe-re-active). This is a separate parameter set from the Overview dock Optimization panel (§2). That panel's demo defaults are MTA $250K, Rounding $10K and Substitution buffer 5%.
Default-rules refresh (stale-seed guard). The app keeps a small marker, aoe-re-seedver. It records which version of the built-in default rules your browser last saved. Suppose the app’s built-in defaults have since changed, so your saved marker is older than the current one. Then the next page load clears your saved rules and runs, and rebuilds them from the current defaults. In plain terms: rules and runs are saved in your browser, and normally kept as-is between visits. Without this marker, an old default set could stay on your screen forever after we changed the defaults. The marker makes the app notice, and refresh to the current default rules automatically. It does not wipe anything on an ordinary reload. It only acts when the default set itself has moved on. Developer note: the current marker value is "2026-07-24"; bump it whenever the default rule library or seed runs change.

🧪 Test cases for US11.4 4 scenarios

RULE-08 Hero bar, input categories, rule groups and strategies

Do: Open the Rules engine tab. Read the hero bar, then the input list, the rule groups and the matching strategies.

Verify: every control on the four checklists above is present, and nothing else. Bond static data and Portfolio static are read-only, with no “+ rule” button. Eligibility is not offered as a rule group.

RULE-09 Run parameters and output columns

Do: Open the Run parameters drawer. Then click ▶ Run and open “Full posting detail”.

Verify: the drawer carries the four parameters listed above. The output table carries exactly the ten listed columns.

RULE-10 The three seed runs and their parameters

Do: Open the app in a private window. Open the Rules engine and read the run selector. Check each run's parameters in turn.

Verify: three runs are listed — Baseline (all GFM), CSG agreements only, USD margin calls only. Baseline reads cap 35%, min transfer 0.15 $mm, rounding 0.15 $mm, buffer 0.5%. CSG matches it except cap 30%. USD matches Baseline.

RULE-11 A new run starts empty, and everything survives refresh

Do: Click + New. Read its parameters and its Visual flow. Add a rule, then refresh the page.

Verify: the new run reads cap 35%, min transfer 0.5 $mm, rounding 1 $mm, buffer 0.5%. It starts with no rules, and the Visual flow reads “Fresh run — no rules yet”. After the refresh the run, its rules and the active selection are all still there.

US11.22 As a user, I can say which kind of collateral to reach for first AND which line to take once the engine is inside that kind so one instruction covers “credit non-financial first, then supranational — and within each, the biggest line”

Where to find it. Rules engine tab → any rule in the Ranking group. Open it from the ✎ on its box in Visual, or from its row in List. A new one is made with + New Rule on an input box, then setting Group to Ranking.

The problem this solves. A desk’s preference has two halves and the screen used to hold only the first. The first half is an ORDER OF KINDS — take corporate paper before supranational paper. The second half is what to do once the engine is inside one of those kinds and several lines qualify — take the biggest line, so the call is covered in the fewest movements. Written as two separate rules the second half reads as if it applied to the whole book, which is not what was meant. So it is carried on the ranking rule, nested under the order it belongs to.

When I open a Ranking rule → Do

The panel shows Name, Group, then Rank by, then Value / criteria, then Note and Enabled.
Rank by is a drop-down with exactly two choices: Asset type rank and Industry rank. Asset type ranks on Govt / Corp. Industry ranks on the issuer group — Sovereign, Financial Institutions, Corporates, Supranational, Agency.
Value / criteria lists that attribute’s values, one per row, numbered 1, 2, 3… in the order they will be used. Each row carries ↑ and ↓; the top row’s ↑ and the bottom row’s ↓ are greyed out.
Under that list, indented and joined to it by a left rule, sits the Sub-rule block. Its label reads ↳ Sub-rule — then within each of these, pick, followed by one drop-down.
The sub-rule drop-down offers exactly two choices, in this order: — none — leave the order inside a bucket to the next rule and biggest inventory line first. The run’s four matching strategies are deliberately not repeated here — they are already set once, on the matching-strategy rule, and offering them in two places invites a run whose two halves disagree. Line size is the one ordering the strategy rule could never express, which is why it is the one this control adds.
Under the drop-down is one line of help naming the value currently at the top of the list, so the sentence reads back as the rule the user just built.
Changing Rank by rebuilds the value list from that attribute’s own values, in their default order. Any ordering done on the previous attribute is lost, because it names values the new attribute does not have.
Save rule stores the ranked order and the sub-rule together on the one rule. Cancel and the ✕ discard both.

When I make a new Ranking rule → Do

Click + New Rule on an input box. The panel opens on Group = Scoping with the condition builder, as before.
Set Group to Ranking. The condition builder and the Input source / Filter by field / Condition rows are hidden, and Rank by plus the ordered list and its sub-rule take their place.
Setting Group back to Scoping or Limits restores that group’s editor. Nothing typed into Name or Note is lost in either direction.
Saving adds the rule to the library and, when it is Enabled, to the active run — the same as any other new rule.
An existing rule never changes editor when its Group is changed. A scoping rule moved into the Ranking group keeps its conditions; it does not silently become a bucket order.

When the run executes → Do

The engine decides which line to reach for first by reading, in this order: (1) each ranking rule’s bucket order, taken in the rule library’s own top-to-bottom priority; (2) that same rule’s sub-rule, used only to separate two lines that fell in the SAME bucket; (3) the run’s matching-strategy rule, as the final tie-break.
A line whose value is not on the ranked list sorts after every value that is. An unranked value is therefore used last, never dropped.
A rule with the sub-rule set to — none — decides the bucket and nothing else; two lines in one bucket pass to the next ranking rule, and finally to the matching strategy.
Ranking never overrules eligibility. A bucket an agreement’s schedule will not accept is still not posted to it, however high it sits on the list — ranking only chooses between lines that already passed the issuer-group, asset-class and rating tests.

Where the sub-rule is shown outside the edit panel

List mode — the rule’s row prints the numbered order, then one further pill reading within each: {sub-rule}. A rule with no sub-rule shows no extra pill.
Visual and Overview modes — the rule’s one-line description reads Rank: A › B › C · then {sub-rule}, and drops the “then…” half when there is no sub-rule.

Defaults & exact values (build)

The sub-rule is stored on the rule as sub, holding one key from the two choices above; the empty key means no sub-rule. A rule saved before sub-rules existed has no key and behaves as “none”.
Of the built-in default rules, Rule 2 – Industry rank ships with the sub-rule biggest inventory line first. Rule 1 – Asset Class rank ships with none.
Changing the built-in defaults bumps the stale-seed marker (aoe-re-seedver), so a browser holding the older set is re-seeded on its next load — see US11.4.

🧪 Test cases for US11.22 5 scenarios

RULE-40 The sub-rule is nested under the order it belongs to

Do: Rules engine → Visual. Click the ✎ on Rule 2 – Industry rank.

Verify: the panel reads Name, Group (Ranking), Rank by (Industry rank), then the five values numbered 1 Corporates, 2 Financial Institutions, 3 Agency, 4 Supranational, 5 Sovereign. Below them, indented behind a left rule, is ↳ Sub-rule — then within each of these, pick set to biggest inventory line first, with one line of help naming Corporates.

RULE-41 A new Ranking rule can be built from + New Rule

Do: Click + New Rule on the Inventory input box. Set Group to Ranking. Set Rank by to Asset type rank. Move Govt to position 1. Set the sub-rule to biggest inventory line first. Name it and Save.

Verify: the condition builder disappears the moment Group becomes Ranking. After saving, the rule appears in the library and in the active run, and its List row reads 1. Govt 2. Corp followed by within each: biggest inventory line first.

RULE-42 The bucket order changes the answer

Do: On Rule 2 – Industry rank, move Supranational above Agency. Save, then ▶ Run. Read the posting mix on Optimization Results.

Verify: the mix moves from Agency-heavy to Supranational-heavy. Nothing outside the eligible pool is posted, and no obligation goes short that was covered before.

RULE-43 The sub-rule changes the answer on its own

Do: Leave the bucket order alone. Change the sub-rule on Rule 2 from biggest inventory line first to — none —. Save and ▶ Run.

Verify: the buckets used are unchanged, but which lines inside them were drawn on changes — with no sub-rule the order inside a bucket falls through to the matching strategy — and the run's annual carry moves. The requirement stays fully covered.

RULE-44 Ranking cannot beat eligibility

Do: Put Corporates at the top of Rule 2 and run.

Verify: no corporate line is posted to an agreement whose eligibility schedule does not accept that issuer group. Ranking reorders the lines that already qualified; it never admits one that did not.

US11.9 As a user, I can search and page through a run's results so the output stays usable when the book holds thousands of agreements and postings.

Where to find it. The Optimisation Results view sits at the bottom of the Optimization Results tab, under the flow tables and the five views. It used to sit in a drawer at the bottom of the Rules engine tab. It is the same one screen, moved — so everything below it still applies, and pressing ▶ Run on the Rules engine takes you here.

The demo runs on a handful of agreements, so every result fits on one screen. The real book will not. This story is the contract for what the results view must do when it does not fit — and it is a build requirement, not a demo convenience. A results screen that draws one card per agreement is fine at seven and unusable at several thousand.

The one search box

A single search box sits directly under the run's summary figures, above the agreement cards. Its placeholder reads Search agreement, asset, type or holding…. A Clear button sits beside it.
It matches on four things at once, ignoring capital letters, anywhere in the text: the agreement name, the asset name, the asset type and the holding. Typing gmra finds the GMRA agreement; typing kfw finds every posting of a KFW bond whichever agreement it went to.
One search, both lists. The same search decides what the agreement cards show AND what the posting table shows. The two can never be looking at different sets of postings. There is no second search box anywhere in the results.
Results narrow as you type — there is no Search button and the run is not re-run. Searching never changes the proposal; it only changes what you are looking at.
To the right of the box, a count states what you are looking at. With nothing typed it reads “36 postings across 7 agreements”. With something typed it reads “5 of 36 postings · 1 agreement match”.
Clearing the box, or pressing Clear, returns to the whole run and sends both lists back to their first page.

Paging — neither list ever draws the whole book

Agreement cards: eight to a page. Under them sit < Prev and Next > and a count reading “Showing 8 of 214 agreements · page 1 of 27”.
Posting table: twenty-five rows to a page, with the same two buttons and its own count, “Showing 25 of 36 postings · page 1 of 2”.
The two lists page independently — moving to page 2 of the postings does not move the cards.
When everything fits on one page the buttons are not shown at all; the count still is, so the screen always states how much it is showing. When one page is available but not the first, Prev or Next greys out rather than disappearing.
The count is never rounded and never silently truncated. If a search matches 1,240 postings the count says 1,240, not “many” and not a capped number.
Typing in the search box sends both lists back to page one, so a match can never be hidden on a page you are not on.

Every total covers the whole match, never the page on screen

This is the rule that makes paging safe. A total added up from the twenty-five rows you can see would change every time you clicked Next, and would be wrong on every page.
The summary figures at the top always measure the whole run — all 36 postings — whether or not a search is active. They are the run's answer, and a search does not change the run.
The total row at the foot of the posting table covers every posting matching the current search, across all its pages. With nothing typed that is the whole run, and the row reads Total (27). With GMRA typed it reads Total (5 of 27 matching).
The note under the table says which of the two you are reading, in words, every time. With nothing typed: “The total row adds up all 36 postings, not just the page on screen.” With a search active it names the search, says the row covers all the matching postings rather than the page, and reminds you the summary figures above still measure the whole run.
A posting switched off with Ignore drops out of every total on the screen, exactly as before. Ignoring is a decision about the proposal; searching is not.

What an agreement card shows when the search only matches part of it

A card stands for one agreement and normally reads “100.0% covered” — how much of that agreement's requirement the proposal meets.
A search picks postings, so a card can end up showing only some of its agreement's proposal. How much is covered cannot be worked out from part of the proposal, so in that case the card does not print a percentage that would be wrong. It reads “1 of 4 postings match” in amber instead, and lists only the matching postings.
A card whose postings all match is unaffected and still shows its coverage percentage.

Volume contract (build)

No control anywhere in the results may list every record. No drop-down of all agreements, no chip per counterparty, no “select all” built from every distinct value in a column. The two shapes allowed are search and narrow-then-drill.
The demo may scan the whole result set in the browser because it holds a few dozen postings. The real system must not. It asks the server for the page it is about to draw, plus the totals over the whole match, and never fetches the entire book to filter it afterwards.
Sorting is applied to the whole match before the page is cut, never to the rows on the page. Agreement cards are ordered by agreement name; postings by agreement name, then largest collateral value first.
When a search matches nothing, both lists are empty, the count reads “0 of 36 postings · 0 agreements match”, and the total row reads zero. Nothing is hidden and no error is shown.

Where each figure on this screen comes from, and how to check it

Figure	Where it comes from	How to check it
The count beside the search box	How many proposed postings match what you typed, and how many different agreements those postings belong to.	Clear the search — it must read the same number of postings as the total row at the foot of the table, and the same number of agreements as the card count under the cards.
“Showing 8 of 214 agreements”	The cards drawn on this page, and the number of agreements with at least one matching posting.	Count the cards on screen. Page to the last page and check the last page's count is the remainder.
“Showing 25 of 36 postings”	The rows drawn on this page, and the number of postings matching the search.	Count the rows on screen; add up the rows across every page and the answer must be the second number.
Total row — market value posted, collateral value, annual cost	Each column added up across every matching posting that has not been switched off with Ignore, on all pages.	Click Next to page through the table: the total row must not move. Then add the column up by hand across the pages — it must equal the row.
“1 of 4 postings match” on a card	How many of that agreement's proposed postings match the search, out of all of them.	Clear the search: the card returns to a coverage percentage, and the number of postings listed on it must equal the second number.

🧪 Test cases for US11.9 3 scenarios

RULE-20 The total row does not change when you turn the page

Do: Open the Rules engine and click ▶ Run — the app lands on the Optimization Results tab — then scroll to “Full posting detail” at the bottom of it. Write down the three totals on the bottom row. Click Next >.

Verify: page 1 shows 25 rows and the pager reads “Showing 25 of 36 postings · page 1 of 2”. Page 2 shows the remaining 2 rows. The three totals are identical on both pages — $1,782.6mm posted, $1,756.9mm collateral value, $1.38mm annual cost — because they cover all 36 postings, not the page. The note under the table says so in words.

RULE-21 One search narrows the cards and the table together

Do: Type GMRA into the search box above the cards.

Verify: the count beside the box reads “5 of 36 postings · 1 agreement match”. Exactly one agreement card is shown, and it is GMRA. The table shows 5 rows and its total row reads “Total (5 of 27 matching)”, $579.2mm posted and $567.0mm collateral value — which is the same collateral figure the GMRA card shows. The summary figures at the top of the view have not moved. Press Clear and everything returns to 36 postings and 7 cards.

RULE-22 A card that only partly matches says so instead of showing a wrong percentage

Do: Type KFW 1.5% into the search box.

Verify: two cards are shown, CCP and GMSLA. Neither prints a coverage percentage. CCP reads “1 of 4 postings match” in amber and lists one posting; GMSLA reads “1 of 4 postings match” and lists one. The table shows those same 2 postings and totals them. Clear the search and both cards go back to showing a coverage percentage.

US11.10 As a user, I can open an Optimization Results screen that presents the run's answer five ways so the proposal can be approved, justified, compared, traced and chased without reading the raw output table.

Where to find it. Two doors, one screen. The top-level Optimization Results tab, next to Rules engine. And the Optimization Results entry in the Overview's left-hand menu, under the Rules Engine heading, beside Optimization Rules. The Overview entry does not rebuild the screen — it shows that same tab, framed full width, exactly the way Optimization Rules shows the Rules engine tab. Anything true of one door is true of the other, always.

What sits at the bottom of this tab. Under the flow tables and the five views is the Optimisation Results view — the run log, the summary figures, the one search box, the per-agreement cards, the two charts and the Full posting detail table. It moved here from the Rules engine tab's bottom drawer, so every run answer now reads on one tab. It is one screen, not a copy: US11.9 governs its search, its paging and which population each total covers.

The one rule that governs every figure on this screen

This screen never works a figure out again. The Rules engine runs the optimiser and publishes its answer; all five views read that same answer. So a number here can never disagree with the run that produced it. A developer who recomputes a total on this screen has built the defect this rule exists to prevent.
The five views are presentations of one run, not five calculations. Switching between them changes what you see, never what the run decided.
If no run has been made yet, opening this screen runs the active run once, so it is never empty.

Checklist — the screen's own controls

A five-button strip: 01 · Approval blotter, 02 · Benefits scorecard, 03 · Scenario board, 04 · Movement map, 05 · Shortfall board. The one you are on is highlighted.
A line of run detail. Every row on this screen belongs to one run, so the run has to be identifiable: it prints the Run ID and the Run date & time — the moment it was put through the optimiser — then how many movements it proposed, how many obligations it looked at, whether Sweep the deck was on, and how many runs are saved.
↻ Re-run — runs the active run again and repaints. Use it after changing a rule on the Rules engine tab.

Switching view clears the search and returns to page one, so you never arrive on a view already filtered by something you typed somewhere else.

🧪 Test cases for US11.10 2 scenarios

RULE-23 Both doors show the same run

Do: Open the Optimization Results tab and write down the run line and the total row at the foot of the blotter. Then go to the Overview tab and click Optimization Results in the left menu under Rules Engine.

Verify: both read run Baseline (all GFM) · 36 postings · 7 obligations · sweep ON and the same totals — $1,782.6mm market value and $1,756.9mm collateral value. They are the same screen, so they cannot differ. Clicking any other entry in the left menu leaves the screen and returns the Overview to its normal charts.

RULE-24 The five views agree with each other and with the run

Do: Read the collateral value on the blotter's total row, then open 02 · Benefits scorecard and read “Requirement covered”, then open 05 · Shortfall board and read the uncovered total.

Verify: the blotter totals $1,756.9mm; the scorecard shows 100.0% covered, being that same $1,756.9mm out of the run's $1,757.0mm requirement; and the shortfall board, with nothing left uncovered, says every obligation was covered in full rather than showing an empty table. The three views are reading one calculation, so they tie out.

US11.11 As a user, I can accept, hold or reject each proposed movement and release the accepted set so the run produces instructions rather than a report.

01 · Approval blotter is the working list. One row per proposed posting, every row decided.

Checklist — blotter columns

Agreement — the agreement name, with its counterparty underneath
Deliver — the instrument to deliver, with its asset type and where it is held underneath
Market value — how much of the instrument goes out
Haircut — the discount that agreement applies to it
Collateral value — what it is worth against the obligation once the haircut is taken
Cost — the funding cost of using that instrument
Decision — the current decision, and the three buttons that set it: Accept, Hold, Reject

How the decisions behave

Every row starts Accepted. The optimiser proposed it; the user's job is to take lines out, not to opt each one in.
A rejected row is dimmed and drops out of every total on the screen. A row on hold also drops out of the totals — it is not being released today — but is not dimmed, because it is a pause, not a refusal.
Three counters sit above the table: Accepted, On hold, Rejected, and the collateral value currently up for release. They count the whole run, not the page or the search.
Release sends the accepted set for settlement and confirms how many movements went. The button always states the number it will send. What that means in the real system is still open — where the movements go, who may release them, whether a second approval is needed and whether a released set can be recalled are OQ-42.
Decisions survive switching views and paging. Re-running the optimiser proposes a fresh set of postings, so decisions taken on the old set no longer apply. Whether the real system must keep them — an audit trail of who decided what and when, and whether a held line carries into tomorrow's run — is OQ-43.

Search and paging (the volume contract)

One search box above the table, matching the agreement, counterparty, instrument, asset type and holding at once, ignoring capital letters. It narrows what you are looking at; it never re-runs the optimiser.
Twenty rows to a page, with Prev / Next and an honest count. The buttons are hidden when everything fits on one page; the count is always shown.
The total row adds up every accepted posting that matches the search, across all pages — never the rows on screen. Turning the page must not move it.

Where each figure comes from, and how to check it

Figure	Where it comes from	How to check it
Market value, Haircut, Collateral value, Cost on a row	The posting the optimiser proposed: the instrument it chose, the discount that agreement applies, and the funding cost carried on that holding.	Open the Rules engine's own “Full posting detail” table and find the same agreement and instrument — the four figures must match to the penny.
Total row — market value and collateral value	Each column added up across every accepted posting matching the search, on all pages.	Click Next: the totals must not change. With nothing typed and nothing rejected they read $1,782.6mm and $1,756.9mm.
Total row — Cost	The cost of the accepted set as a whole, weighted by how much market value each posting sends out, so a large cheap posting counts for more than a small dear one.	With everything accepted it reads 7.8 bps, which sits between the cheapest holding used (7 bps) and the dearest (11 bps).
“$1,756.9mm to release”	The collateral value of every posting still marked Accepted, across the whole run.	Reject one line and it must fall by that line's own collateral value — rejecting the $41.4mm posting takes it to $1,375.4mm.

🧪 Test cases for US11.11 3 scenarios

RULE-25 The total row does not move when you turn the page

Do: Open 01 · Approval blotter. Note the pager and the three totals. Click Next >.

Verify: page 1 shows 20 rows and reads “Showing 20 of 36 postings · page 1 of 2”; page 2 shows the remaining 7. On both pages the totals read $1,782.6mm, $1,756.9mm and 7.8 bps, because they cover all 36 postings and not the page.

RULE-26 Rejecting a line re-prices the release at once

Do: On the first row (Bilateral CSA IM, KFW 1.25% 02/27, $41.9mm market value, $41.4mm collateral value) press Reject.

Verify: the row dims and its decision reads ✕ Rejected. The counters read Accepted 26, Rejected 1. The totals fall to $1,403.0mm and $1,375.4mm — each down by that row's own figures — and the Release button now reads Release 26 movements. Press Accept on the same row and everything returns.

RULE-27 The search narrows the list and the totals follow it

Do: Type GMRA into the search box.

Verify: the count beside the box reads “5 of 36 postings match”, five rows are listed, and the total row reads Accepted (5 of 5 matching), $579.2mm and $567.0mm. The counters above still count the whole run. Press Clear and all 27 return. Typing a counterparty instead — Dunmore Bank — finds the same five rows.

US11.12 As a user, I can see in six figures whether the run was worth doing so I can justify the system to someone who will never open the rules.

02 · Benefits scorecard. Six tiles and one comparison bar. Every tile counts only the postings still marked Accepted on the blotter, so the case being made is the case being released.

Checklist — the six tiles

Saved this year — what the run saves against funding the whole requirement in cash, and the same figure as a percentage
Annual carry — what the proposed mix costs to hold for a year, with the all-cash cost beside it
Requirement covered — how much of what is owed the run manages to cover
Blended funding cost — the cost of the whole accepted set, weighted by market value posted
Movements to make — how many postings that is, and how much market value goes out
Left uncovered — what the run could not fill, and how many agreements are short

Where each figure comes from, and how to check it

Figure	Where it comes from	How to check it
Saved this year — $6.52mm	The all-cash cost less what the proposed mix costs.	$7.91mm − $1.38mm = $6.52mm. Both are printed on the tile beside it.
▼ 82% cheaper	The saving as a share of the all-cash cost.	$6.52mm out of $7.91mm is 82%.
Requirement covered — 100.0%	The collateral value of the accepted postings, out of what the run's obligations add up to.	$1,756.9mm out of $1,757.0mm. The first figure is the blotter's own total row.
Left uncovered — $0.1mm	The requirement less the collateral value covered.	$1,757.0mm − $1,756.9mm. Every obligation is met in full on this run, so the shortfall board has nothing to list and says so.
The two bars	The all-cash cost is the full-width bar; the run's cost is drawn as its share of it.	$1.38mm is about a sixth of $7.91mm, and the green bar is about a sixth of the red one.

🧪 Test cases for US11.12 2 scenarios

RULE-28 The six tiles and their arithmetic

Do: Open 02 · Benefits scorecard with nothing rejected.

Verify: Saved this year $6.52mm and ▼ 84% cheaper; Annual carry $1.38mm against all-cash $7.91mm; Requirement covered 80.6%, being $1,756.9mm of $1,757.0mm; Blended funding cost 7.8 bps; Movements to make 27 at $1,445mm market value; Left uncovered $340.1mm across 4 of 7 agreements. Every subtraction above works out on the tiles themselves.

RULE-29 The scorecard measures what will actually be released

Do: Reject the first row on the blotter, then return to the scorecard.

Verify: Movements to make falls to 26 and the covered figure falls with it. The scorecard states the case for the accepted set, so it must move when the accepted set moves.

US11.13 As a user, I can compare my saved runs side by side against doing nothing so I can pick the run to release instead of only ever seeing one.

03 · Scenario board. One column per saved run, one row per measure, and a Do nothing column so every run is measured against the current book rather than only against each other.

How it is built

Every column is a real run of the same optimiser. The board borrows each saved run in turn, runs it, and puts the selection back — it never estimates a run it has not made, and it never disturbs which run is active.
Do nothing means funding the whole requirement in cash. Only its cost exists; the other rows read a dash, because doing nothing makes no proposal to measure coverage or movements against.
The best figure in each row is marked green. Lower is better for cost, movements and uncovered; higher is better for saving and coverage.
Market value posted is never ranked. More of it is neither good nor bad on its own, and colouring it would invent a verdict.
Under the table, a button per run makes that run the active one. The active run is labelled in its own column heading and has no button.
At most five runs are compared, and the footnote states how many were left out.

The seven rows, worked on today's runs

Measure	Do nothing	Baseline (all GFM)	CSG agreements only	USD margin calls only
Annual carry cost	$7.91mm	$1.38mm	$1.39mm	$1.38mm
Saved vs doing nothing	—	$6.52mm	$6.52mm	$6.52mm
Requirement covered	—	100.0%	100.0%	100.0%
Market value posted	—	$1,783mm	$1,783mm	$1,783mm
Movements to make	—	36	37	36
Blended funding cost	—	7.8 bps	7.8 bps	7.8 bps
Left uncovered	—	$0.1mm	$0.2mm	$0.1mm

Read that table before building it: the cheapest run is not the best run. “CSG agreements only” costs a hair less and saves a hair more, yet leaves $9.2mm more uncovered and covers half a point less. That trade-off is the whole reason this screen exists, and it is why no single row may be presented as the winner.

🧪 Test cases for US11.13 2 scenarios

RULE-30 Every saved run gets a real column

Do: Open 03 · Scenario board.

Verify: four columns — Do nothing, and the three seed runs. The figures match the table above. The Baseline column is labelled active run and has no promote button; the other two have one. Do nothing shows only a cost; every other cell in that column is a dash.

RULE-31 Promoting a run changes the active run everywhere

Do: Press Make “CSG agreements only” the active run, then open the Rules engine tab.

Verify: the board relabels that column active run, the run line at the top of the screen names it, and the Rules engine's own run selector has switched to it. The other views repaint on its figures — the blotter's totals become that run's.

US11.14 As a user, I can see which inventory line feeds which agreement so I can answer why a particular bond ended up at a particular counterparty.

04 · Movement map. Inventory lines on the left, agreements on the right, ribbons between them.

Each side lists the largest eight by collateral value and the footnote states how many there are in total, so the screen never draws the whole book.
Each bar is sized by that row's share of the largest one. On the right it is also coloured by how much of that agreement's requirement the run met — green in full, amber above 85%, red below.
Rejected postings are excluded, so the map shows what would actually move.
It shows where collateral GOES, not what MOVED. A before-and-after view needs the existing-postings data set, which is not loaded — a run with Sweep off currently retains nothing, so there is no “before” to compare against. The footnote says so on screen rather than implying a comparison it cannot make. Raised as OQ-44.

Worked on today's run

From inventory	Collateral value	To agreement	Collateral value
FRANCE OAT 1.25% 06/27	$301.7mm	GMRA · Dunmore Bank	$567.0mm
SINGAPORE GOVT 3% 02/30	$301.2mm	Bilateral CSA IM · Brackwater Bank	$206.9mm
KFW 1.25% 02/27	$267.8mm	GMSLA · Ironvale Bank	$190.7mm
IBRD WORLD BANK 2% 06/26	$230.8mm	CCP · LCH	$148.1mm
ASIAN DEV BANK 3.625% 08/28	$230.7mm	Triparty · Halvard Bank	$141.0mm
KFW 1.5% 10/27	$84.7mm	Bilateral CSA VM · Caldera Bank	$98.8mm
		Futures · CME	$64.4mm

Both sides add up to the same total — $1,756.9mm — because every posting leaves an inventory line and arrives at an agreement. That is the check: if the two columns disagree, a posting has been counted on one side and not the other.

🧪 Test cases for US11.14 2 scenarios

RULE-32 The two sides reconcile

Do: Open 04 · Movement map and add up each column by hand.

Verify: fourteen inventory lines feed seven agreements; both columns add to $1,756.9mm, which the footnote states and which equals the blotter's collateral-value total. GMRA is green (covered in full), CCP and Futures are red (below 85%).

RULE-33 A rejected posting leaves the map

Do: Reject the GMRA / KFW 1.25% 02/27 posting on the blotter, then open the movement map.

Verify: both the KFW line and the GMRA agreement fall by that posting's collateral value, and the footnote total falls with them. The map shows what would move, so a line you refused must not appear on it.

US11.15 As a user, I can see what the run could not cover and the rule that blocked it so an obligation left short is a decision I take rather than something I discover later.

05 · Shortfall board. Only the obligations the run could not fill, each with the constraint that stopped it.

Checklist — columns

Agreement — with its counterparty underneath
Needed — what that agreement's obligations came to
Covered — what the run managed to post against it
Short — the gap
Coverage — the same gap as a bar and a percentage: green covered in full, amber above 85%, red below
What blocked it — the collateral types that agreement accepts, the issuer groups it allows, how many inventory lines survive its own eligibility test out of the number the run's rules left in play, and its rating floor

Searchable by agreement or counterparty, twenty rows to a page, and the total row adds up every agreement listed, not the page. When a run covers everything, the board says so rather than showing an empty table.

Worked on today's run

Agreement	Needed	Covered	Short	Coverage	Eligible lines
Nothing to list on today's run. Every obligation is covered in full, so the board says “Every obligation in this run was covered in full.” instead of drawing an empty table. The columns above are what it draws when a run cannot fill something — narrow an agreement's eligibility, lower its concentration limit or take lines out of scope, and the rows come back.

Every column adds up: Needed less Covered is Short on each row, and the rows add to the total, each shown to the nearest $0.1mm.

What makes a row appear is almost never that the firm is out of collateral. It is that too few of its holdings pass the agreement's own eligibility test (accepted types, rating floor, issuer groups), and that each one that does pass may only carry a share of the call — that agreement's concentration limit. Cover a $247.0mm call from two eligible lines at a 20% limit and $98.8mm is all that can be delivered, whatever the optimiser does. That is the sentence a collateral manager needs, and it is why the eligible-line count and the blocking constraint sit on every row. On today's book the firm holds enough eligible paper that every obligation clears both tests, so the board reports a covered run instead.

🧪 Test cases for US11.15 2 scenarios

RULE-34 Every row's arithmetic, and the total

Do: Make a run the book cannot fill — on the Rules engine tab, drop the concentration cap to 10% and re-run — then open 05 · Shortfall board and check each row by hand.

Verify: one row per obligation the run could not fill, biggest short first. On every row Needed − Covered = Short, the coverage bar reads that same gap as a percentage, and What blocked it names the agreement's accepted types, its issuer groups and how many inventory lines survive its own eligibility test. The total row adds up every agreement listed, not the page, and the chip above it counts them out of the run's seven obligations. On today's run the board is not drawn at all, because nothing is short — see RULE-35.

RULE-35 A fully covered run says so

Do: Open 05 · Shortfall board on Baseline (all GFM), which covers every obligation.

Verify: the table is replaced by the words “Every obligation in this run was covered in full.” — not an empty table, and no total row. The scorecard beside it agrees: 100.0% covered, $0.1mm left uncovered, which is rounding rather than a shortfall.

US11.16 As a user, I can see where every bond came from and where it is going, at the top of the run so the first thing the screen answers is which desk lends me the bond and which agreement receives it.

▸ Optimization Results — the two tables that lead the screen

To get here: the Optimization Results tab, or the Optimization Results entry in the Overview’s left sidebar. Both open the same screen.

What it is: one movement has two legs. The bond leaves a desk inside the firm, and it arrives at an agreement outside it. The screen leads with one table per leg. Everything the screen used to open with sits underneath them, in a fold headed “UI suggested by AI based on what is available from vendors in the market”, open by default.

Table 1 — Internal sources of bonds

One row per line the run draws on. Where the same bond is drawn for several agreements, it is one row here and several rows on the second table.

A margin call is met two ways, not one

Collateral does not only come from a desk. A call can be met by borrowing a bond that is free at the desk, or by recalling one the firm already has posted out somewhere else. A Sweep-ON run assumes the second has happened — it re-optimises as if nothing were posted — so the recall is not a detail, it is half the supply, and somebody has to make those calls.

What the pool has to source for a bond is what it posts, plus the run’s haircut buffer, rounded up to a whole million (see below). That is the draw.
Everything already posted out comes back first. Under a Sweep-ON run the whole of it is recalled, whether the draw needs it or not — that is what the sweep means. Where more comes back than the draw needs, the surplus simply stays in the pool.
The desk lends the rest, and only the rest. Internal sources of bonds is therefore the fresh borrow: the draw less what is coming back. Where the recall covers the draw in full the desk lends nothing, and the line reads 0.00 rather than being hidden.
On a Sweep-OFF run nothing is recalled, so the whole draw is a fresh borrow and the recall list says so in words.
Both sources are shown together under the bond, in the order they happen — see US11.18. Each recall line names the agreement it is currently meeting, its counterparty and where it is held, because that is who has to be called.

Worked example, from the figures on screen today. XSBIY8G8VPB6 posts $308.55mm, so the pool must source $311.00mm. $158.03mm of that bond is already posted out — $89.63mm against Bilateral CSA VM (Caldera Bank), $41.93mm against CCP (LCH) and $26.47mm against Futures (CME) — and all of it is recalled. The desk therefore lends only the remaining $152.97mm fresh. XSFAIBBDJEA8 is the other shape: $288.97mm comes back against a draw of $273.00mm, so the desk lends nothing. XS9Z40G1NNE9 is the third: none of it is posted out, so all $87.00mm is a fresh borrow.

How much the pool borrows

The pool does not source the exact amount it posts. It sources a little more, for two reasons a collateral desk will recognise, and both are read off the run rather than typed in:

It covers the postings plus the run’s haircut buffer. The buffer is the run parameter of that name, shown on the Rules engine’s Run parameters panel. Borrowing it on top means a haircut move does not leave the pool short and having to go back to the desk for more.
It is rounded up to a whole million. A bond is drawn from a desk in whole millions, never to two decimal places. That is why every Amount on this table is a round figure while the amounts on the posting table are not.
It can never exceed what the line holds. A desk cannot lend more of a bond than it has on the snapshot date, so the borrow stops at the line’s market value.
What is borrowed and not posted stays in the pool. It is not a shortfall and it is not an error — it is the headroom the run deliberately drew.

Worked example, from the figures on screen today. The run posts $86.55mm of XS9Z40G1NNE9 — $48.75mm to GMSLA and $37.80mm to CCP. The active run carries a 0.5% haircut buffer, so the pool needs $86.55mm × 1.005 = $86.98mm, which rounds up to a whole $87.00mm borrowed from SG Credit Trading. $0.45mm stays in the pool. The line holds far more than that, so the cap does not bite. Across the whole run the summary reads $1,290.70mm borrowed against $1,782.60mm posted.

ISIN — the code of the bond being drawn.
Desk (Source) — the desk the bond is drawn from.
Portfolio (Source) — the portfolio inside that desk that holds it.
Direction — In where the bond moves into the collateral pool, Out where it goes back to the desk. Two values only.
Amount — how much of the bond the desk lends fresh from that line, in millions of US dollars: what the pool has to source, less whatever is being recalled from where the bond is posted today. It is 0.00 where the recall covers it all. See A margin call is met two ways below.
Start Date and End Date — the window the line is held for.
Rate — what that funding costs, in basis points.

Table 2 — Where the bonds are posted to

One row per proposed movement. This is the leg that leaves the firm.

An agreement type is not an agreement

“Bilateral CSA IM” is a KIND of contract, not a contract. The firm signs many of them, and each one is its own paperwork with its own end date and its own settlement terms. So one posting of a bond to Bilateral CSA IM does not all settle on the same day or run to the same end date — it is spread over the individual agreements that are covering it.

The individual agreements are the margin obligations the app already carries one level down — the same rows the Margin Obligations detail table lists, each with its own agreement reference, its own counterparty and its own expected margin call. They are not a second set invented for this screen.
An agreement’s share of its type’s book is its own expected margin call over the type’s total, so a posting is split by what each agreement actually owes, never by a weight typed in.
A row is one agreement TYPE, and one row only. A posting is decided against the type, so the type is what the row reports: what this bond posts to it, and what the type expects to be called for. Splitting it into a row per agreement would put two part-totals of one obligation side by side, which reads as two obligations.
The posting is split across the agreements underneath by what each of them owes — its own expected margin call over the type’s total — and the split is exact: the parts add back to the amount the run proposed, to the cent. Money can never appear or vanish between the run and this table.
Where the agreements do not share a date, the row reports the SPAN they cover, written as 19/06/2026 – 20/06/2026. A single date is never printed as if every agreement settled on it. Where they do share one, the cell simply shows that date.
Which agreements sit under the type is shown by opening the row under Summary by bond — see US11.18. Triparty is never booked under standalone agreement codes, so its individual agreements are named by the counterparty the triparty agent holds collateral for.

Worked example, from the figures on screen today. The run posts $50.40mm of XSBIY8G8VPB6 to Bilateral CSA VM. That is one row, reading $50.40mm of collateral against an Expected Margin Call of $247.00mm — what the whole type owes. Open it and the two agreements behind it appear: ISDA/CSA-VM-MS-001, which expects $148.00mm and therefore takes $30.20mm, settling 20/06/2026 and running to 01/07/2030; and ISDA/CSA-VM-MS-002, which expects $99.00mm and takes $20.20mm, settling 19/06/2026 and running to 01/07/2029. They add back to $50.40mm against $247.00mm. Because their dates differ, the row above reports the span — 19/06/2026 – 20/06/2026 and 01/07/2029 – 01/07/2030. CCP’s two agreements happen to share a date, so its row prints the one date.

Checklist — the columns

ISIN — the code of the bond being posted.
Agreement (Destination) — the agreement type the posting covers. The exact agreements under it are on the row’s own drill-down.
Destination — where it settles, which is that agreement’s custodian.
Direction — Out where the bond leaves for the agreement, In where it is recalled back. Two values only.
Collateral Amount — how much collateral is moving, in millions of US dollars.
Expected Margin Call — what the agreements in this window expect to be called for. It is a property of the agreements, not of this bond’s posting, so it reads the same on every bond’s row for that window and is never added up down the table — adding it would count the same call once per bond. It is read-only everywhere.
Start Date and End Date — the window it is posted for. The start is the day the movement settles on that window’s own settlement terms; the end is that window’s agreements’ end date.
Rate — what it costs there, in basis points, after the agreement’s haircut is taken off.

Checklist — how both tables behave

Every heading sorts. Clicking one sorts by it. Clicking it again reverses. An arrow on the heading shows which way. Both tables open sorted by Amount, largest first.
A filter row sits under the headings, one box per column. Typing in one narrows the table to rows containing what was typed. Boxes combine. Clear filters empties them all.
A totals row closes each table. It counts the rows still in the run and adds up their Amount. It counts what the filters left, not the whole run.
The count above each table reads how many rows the filters left, out of how many there are, then how many are system proposed, edited, added or proposed for removal.
Neither table recomputes anything. Both read the run the Rules engine published, so they can never disagree with the blotter beneath them.
Both tables can be fed with real data instead. They are catalog sets 12.1 and 12.2, uploaded and mapped on the Data tab like any other set. When a set is served that way the count line says Serving: your production file. Each table falls back to the run on its own, so one can be live while the other is not.

🧪 Test cases for US11.16 3 scenarios

RULE-36 The two tables lead the screen

Do: Open Optimization Results.

Verify: the first table is headed Internal sources of bonds, the second Where the bonds are posted to. The first has these headings in order: ISIN, Desk (Source), Portfolio (Source), Direction, Amount, Start Date, End Date, Rate, Status, Change. The second has: ISIN, Agreement (Destination), Destination, Direction, Amount, Start Date, End Date, Rate, Status, Change. Below both sits a fold headed UI suggested by AI based on what is available from vendors in the market, holding the five views the screen used to start with.

RULE-37 Sorting, filtering and the totals row

Do: On Internal sources of bonds, write down the Amount total in the last row. Click the Rate heading. Click it again. Then type a portfolio name into the filter box under Portfolio (Source).

Verify: the first click sorts by Rate with an arrow on the heading, the second reverses it. The table narrows to rows carrying that portfolio. The count above says how many rows are left out of how many. The Amount total is now the total of the rows on screen, not the total you wrote down. Clearing the filter brings the original total back.

RULE-38 The two legs tie to each other

Do: Take the top ISIN on Internal sources of bonds and note its Amount. Type that same ISIN into the ISIN filter on Where the bonds are posted to.

Verify: one or more rows appear. A bond drawn once can be posted to several agreements, so several rows on the second table against one row on the first is correct. Their Amount total is a little less than the amount borrowed on the first table, and the amount borrowed is a whole million: the pool borrowed the postings plus the run’s haircut buffer, rounded up. Today the top line reads $311.00mm borrowed against $308.55mm posted. The difference is the headroom left in the pool, not a missing posting.

US11.16a As a user, I can see where the collateral is posted today, so I know what a full sweep has to recall so the run’s assumption that everything comes back turns into calls somebody can actually make.

Why this screen exists. Sweep the deck ON is an assumption with a consequence. The run re-optimises as if nothing had ever been posted — which means every line already out with a counterparty has to be recalled first. Somebody has to pick up the phone. A run that silently assumes the recall, on a screen that never says what is being recalled or from whom, is not something anyone can act on. This table says it.

It is the state of the book, not a proposal. It is read from the existing-postings data (catalogue set 14, Collateral used data), not from the run, so changing a rule does not change it. What the run changes is what happens to it, and the line under the heading says which.

Checklist — the columns

ISIN and Instrument — which bond is sitting out there.
Agreement and Counterparty — who has it. This is the exact individual agreement the collateral is posted under, never the kind of contract it is: a recall is a call to somebody, and “Bilateral CSA VM” is not somebody. Triparty is named by its counterparty, as always.
Held at — where it physically sits: the custodian or the triparty agent.
Desk (Source) and Portfolio (Source) — where it came from inside the firm, so a recalled line can be put back where it belongs, or re-posted from the same place.
Market value — how much of the bond is out.
Collateral value — what it is worth to the counterparty after that agreement’s haircut. Always lower than the market value.

Checklist — how it behaves

Every heading sorts, and each has its own filter box. It opens sorted by Market value, largest first. A count says how many lines the filters left, out of how many.
A totals row closes it with the number of lines and both value columns added up, over what the filters left.
The line under the heading names what this run does with them. On a Sweep-ON run it reads that every line is recalled before the run re-optimises, so each one is a call to make. On a Sweep-OFF run it reads that they stay where they are and only the top-up is proposed.
Where nothing is posted out, it says so in words rather than showing an empty table.
Nothing here is editable. These are records of what IS posted, not proposals — the two tables below it are the proposals, and those are the ones that carry Edit and Propose removal.

The two totals must tie to the run, and that is how you check this screen. Press ▶ Run with Sweep the deck OFF and read the run log: the collateral value retained and the inventory market value already pledged are the same two figures as this table’s totals. Today that is $1,158.83mm retained against the Collateral value total, and $1,173.48mm pledged against the Market value total, over 19 lines. If they ever disagree, one of the two is reading a different book.

🧪 Test cases for US11.16a 2 scenarios

RULE-38a What a full sweep recalls

Do: Open Optimization Results with the Baseline (all GFM) run, which is Sweep ON. Read Where the bonds are posted today.

Verify: it lists 19 lines across the seven agreements, each naming the bond, the counterparty holding it, where it is held, and the desk and portfolio it came from. The line under the heading reads that Sweep the deck is ON and every line below is recalled before the run re-optimises. The totals row reads $1,173.48mm market value and $1,158.83mm collateral value. Every bond listed is one its agreement actually accepts — there is never a corporate bond sitting under a sovereign-only agreement.

RULE-38b Turning the sweep off ties the table to the run

Do: On the Rules engine tab set Sweep the deck to Off, press ▶ Run, and read the run log. Then come back to Where the bonds are posted today.

Verify: the run log now reads that existing postings stay in place, $1,159mm of collateral value retained and $1,173mm of inventory market value already pledged and unavailable — the same two figures as the table’s totals. The requirement the run still has to cover drops from $1,757.0mm to $598.2mm, because the rest is already posted. The line under the table’s heading now reads that the lines stay where they are. Set the sweep back to On, run again, and the requirement returns to $1,757.0mm.

US11.17 As a user, I can amend what the run proposed, and everyone can see what I changed so I can take a row out, correct one, or add one the engine missed, without anybody mistaking my amendment for the engine’s answer.

▸ Optimization Results — amending a run

What it is: the engine proposes; a person decides. Any row on either table can be proposed for removal, edited, or added from scratch. Every row therefore says where it came from, so the engine’s answer and a person’s amendment are never confused.

The four statuses — every row carries exactly one

System proposed — the engine put this row here and nobody has touched it.
User edited — the engine put this row here and a person changed one or more of its values.
User added — the engine never proposed this row. A person added it.
Proposed for removal — a person asked for this row to come out of the run.

Checklist — what this story requires

Every row carries an Edit button and a Propose removal button, in a Change column at the end.
Edit turns that row’s eight values into boxes. Direction becomes a drop-down of In and Out. The dates become date pickers. Amount and Rate take numbers. Save keeps the change; Cancel abandons it.
A saved edit sets that row to User edited. The row stays where it is and keeps counting towards the totals.
Propose removal sets the row to Proposed for removal. The row stays visible and is struck through, so nothing disappears silently. It stops counting towards the totals and the row count.
A row proposed for removal offers Keep in run instead of Edit and Propose removal. Clicking it puts the row back to what it was.
+ Add record adds an empty row at the bottom, already open for editing, set to User added. Direction starts at In on the sources table and Out on the destinations table. It can be edited and proposed for removal like any other row.
The count above each table names every status present, so the split between the engine’s rows and amendments is readable without scrolling the table.
Amendments are held per run. Switching runs shows that run’s own amendments. They survive a reload.
Reset to system proposal drops every amendment on that table and returns it to exactly what the engine proposed. It affects one table, not both.
Amending never changes the run itself. The five views underneath keep showing the engine’s own answer.

🧪 Test cases for US11.17 4 scenarios

RULE-39 Editing a row marks it as edited

Do: On Internal sources of bonds, note the top row’s Amount and the count line above the table. Click Edit on that row. Change Amount to 999.5. Click Save.

Verify: the row now reads 999.50, and its Status reads User edited. The count line, which said every row was system proposed, now says one fewer system proposed and 1 user edited. The totals row has moved by the difference.

RULE-40 Proposing a removal, and putting it back

Do: Click Propose removal on any row. Read the totals row. Then click Keep in run on that same row.

Verify: the row stays on screen, struck through, with Status Proposed for removal. The row count in the totals row has dropped by one and the Amount total no longer includes it. Its buttons are replaced by Keep in run. Clicking that restores the row, its status and the totals.

RULE-41 Adding a record the engine never proposed

Do: Click + Add record on Where the bonds are posted to. Type an ISIN and an agreement name into the new row. Click Save.

Verify: a new row is added at the bottom with Status User added, Direction already set to Out, and the values you typed. The count above says 1 user added. The row count in the totals row has gone up by one.

RULE-42 Amendments survive a reload, and reset clears them

Do: With an edit, a removal and an added row all in place, reload the page and reopen Optimization Results. Then click Reset to system proposal on that table.

Verify: after the reload every amendment is still there, with the same statuses. After the reset the table is back to what the engine proposed: the added row is gone, the edited row shows its original value, nothing is struck through, and every row reads System proposed. The other table is untouched.

US11.18 As a user, I can read the run one bond at a time, and open a bond to see both legs behind it so I can see that we borrowed 100 of a bond and posted 90 of it, and then find out exactly where each part went.

▸ Optimization Results — Summary by bond (folded under ▸ The long form)

What it is: the two tables below it are one row per movement, which answers “what is moving” but not “what is happening to this bond”. This table is one row per bond. It puts the amount borrowed and the amount posted side by side, and opens to show the lines behind both.

Two ways to read one run

A bond goes to several agreements, and an agreement is met by several bonds. Neither grouping can answer the other’s question: read down the bond view and no single row ever tells you whether an agreement is actually covered. So the summary carries a toggle — By bond and By agreement — and the user picks which question they are asking.

Both views are built from the same rows the run published, so they cannot disagree. Only the grouping differs, and every figure in one can be found in the other.
The toggle sits on the summary’s own heading, on the right. By bond is where it opens.
By agreement lists one row per individual agreement in the book — not per kind of contract, and including any that got nothing, because an agreement with nothing posted to it is the one most worth seeing. Its columns are Agreement, Counterparty, Expected Margin Call, Collateral Amount, Collateral Value and Shortfall.
Shortfall is what the agreement still expects, less what is actually posted against it, measured on collateral value — the basis the obligation is stated in. It reads zero where the call is met, and is picked out in amber where it is not. It is the same figure the margin-call warning names, worked out once.
Every heading sorts and every column filters, exactly as the bond view. A totals row closes it with the number of agreements and each column added up.
Opening a row shows the bonds meeting that one margin call — the thing the bond view cannot show. One row per bond, with its ISIN, the agreement type it went under, its collateral amount and value, its settlement date, its repo window, its source and its cost of funds, and a totals row that ties back to the agreement above it.
The by-agreement view is read-only. Amendments are made where the agreement lines are edited, under By bond, so there is one place a change is made and one amendment layer behind it.

The two views tie to the run, and that is how you check them. Today By agreement lists 14 agreements expecting $1,757.00mm — the run’s whole requirement — against $1,782.60mm of collateral posted, worth $1,756.89mm after haircut — met in full, with $0.22mm of rounding left over. That posted figure is the same total By bond shows, and that collateral value is the run’s own “requirement covered”.

Checklist — the summary (by bond)

One row per ISIN, whether the bond is only borrowed, only posted, or both.
Borrowed is everything the pool sources for that bond — the fresh borrow from the desk plus what is recalled from where the bond is posted today. The two lists under the row add up to it exactly. Posted adds up every movement out for it. Borrowed is the larger of the two — the pool sources more than it posts and keeps the difference.
Both headings sort, largest first on the first click. The table opens sorted by Borrowed, largest first.
A filter box sits under each heading. The count above says how many bonds the filters left, out of how many.
A totals row closes the table: how many bonds are listed, and the two column totals for those bonds.
The summary is built from the same rows the two tables below show, amendments included. Proposing a row for removal takes it out of these totals; editing an amount moves them.

Checklist — drilling down and back up

Every row carries a ▸ marker and the whole row is clickable.
Clicking opens the row. The marker turns to ▾ and three lists appear underneath it, in the order things happen: 1 · Borrowed fresh from the desk, 2 · Recalled from where it is posted today, and 3 · Posted to. A line above them says in words that a margin call can be met either way.
2 · Recalled from where it is posted today lists that bond’s existing postings: the exact individual agreement it is currently meeting — the one that has to be called, not the kind of contract — its counterparty, where it is held, the direction (always In — it is coming back), its market value and its collateral value, with a totals row. It is read-only — it is the state of the book, not a proposal. Where none of the bond is posted out, it says so. On a Sweep-OFF run it says nothing is recalled at all, because nothing is.
Borrowed from lists that bond’s source lines: Desk (Source), Portfolio (Source), Direction, Amount, Start Date, End Date, Rate, Status.
Posted to lists that bond’s movements out: Agreement (Destination), Destination, Direction, Amount, Start Date, End Date, Rate, Status. The same agreement type appears on several rows with different dates — one per window (see US11.16).
Neither list repeats the ISIN — it is the row that was opened.
Where a bond has nothing on one side, that list says so in words rather than showing an empty table.
Clicking the row again closes it. Any number of rows can be open at once. Collapse all closes every one, at every level.

Checklist — a third level: the exact agreements behind a posting

Every row on Posted to carries its own ▸ marker, because a row is an agreement type and the firm holds more than one agreement of that type.
A row opens whether or not the list is being edited. Reading which agreements a posting is actually going to is not an editing job — outside edit mode the agreements are simply listed, with no boxes and no removal control. Entering edit mode opens every window at once; leaving it again leaves open whichever rows the user had opened themselves.
Clicking anywhere inside an opened agreement table does not close the row above it.
Opening it shows Agreements behind this posting: one row per agreement, with the Agreement reference, the Collateral Amount it takes, its own Expected Margin Call, its own Start Date and End Date — which is where the exact dates live when the row above shows a span — and a Status. A totals row closes it with the count of agreements, their collateral and their calls.
The row’s figures ARE its agreement lines added up, to the cent — not the other way round. Both columns: the totals row equals the Collateral Amount and the Expected Margin Call printed above it. Each agreement starts on its share of what the run proposed (its own expected margin call over the type’s total), and the rounding leftover lands on the largest, so the parts can never drift from the row.
A row added by hand names no agreements under it, and says so in words rather than showing an empty table.
Three levels are on screen at once — the bond, the lines under it, and the agreements under a line — so each carries its own colour down its leading edge and a wash behind it. Depth is readable without counting indents, and the colours hold in both the light and the dark theme.
Triparty’s agreements are named by counterparty, not by an agreement code, because triparty collateral is never booked under a standalone agreement code.

Checklist — amending, and where the amendment is made

Production holds thousands of movements. This is where the user actually works: they find the bond, open it, and amend the lines under it — rather than hunting the same row down a flat table of thousands. Two rules shape how that works.

ONE control, not one per row. Each list carries a single ✎ Edit button on its heading, which turns the whole list into an editable grid and offers Save and Cancel in its place. Repeating Edit and Propose removal on every row buys nothing and drowns the figures. Only one list is ever in edit mode at a time.
A posting is amended at AGREEMENT level. A posting row is an agreement type, and a type is a roll-up of the agreements under it — change the roll-up and there is no saying which agreement it belongs to. So entering edit mode on Posted to opens every row and puts the boxes on the agreement lines. The type row itself stays read-only, and its figure is whatever its agreement lines now add up to. Edit mode is not how a row is opened — any row opens on its own, in or out of it.
On Borrowed from the row IS the unit, so edit mode puts the boxes on the rows themselves. The ISIN is not among them — inside a bond’s own row the ISIN is the row you opened.
Each editable line offers a ✕ that proposes it for removal, and a Keep that puts it back. A line proposed for removal stays listed — otherwise a removal made here could never be undone here.
A line proposed for removal stops counting: its window, the bond’s Borrowed and Posted figures and every total add up only the lines still in the run.
An amendment made here shows immediately on the flow tables below. There is one amendment layer, so the two can never disagree. The flow table of postings is a read-only view for that reason: it lists agreement types, and a type is not the unit an amendment is made against — it says so, and says where to go.
Typing in a box does not open or close the row it sits in.
A figure typed back to exactly what the run proposed is not an amendment, and the line goes back to reading System proposed.

Checklist — the margin-call check

An amendment can leave an agreement without enough collateral against it. The screen says so rather than letting it pass.

While Posted to is being edited — and afterwards, for as long as any amendment stands — a message sits above the list naming every individual agreement whose expected margin call is no longer met, what is posted against it, what it expects, and the shortfall. The six largest are named and the rest counted.
The check is run over the whole run, not over the bond on screen. A margin call belongs to an agreement, and an agreement is covered by several bonds — so an edit to one bond can leave an agreement short even though that bond still looks fine.
It is measured on collateral value, not on the amount posted. What the counterparty credits is the market value delivered less its haircut, which is the basis the obligation itself is stated in. Comparing the raw amount against the call would flatter every posting by its haircut.
It flags; it never blocks. The amendment is saved either way — this is a desk deciding, not a form refusing.

Borrowed is higher than Posted on every bond, and that is the point of the table. The pool borrows the postings plus the run’s haircut buffer, rounded up to a whole million and capped at what the line holds — the rule is written out under US11.16, “How much the pool borrows”. What is borrowed and not posted is headroom left in the pool, never a shortfall. Today the totals read $1,290.70mm borrowed against $1,782.60mm posted. The gap moves on its own when the run does: change the haircut buffer, or change what the run posts, and both columns follow. It widens differently again once the two legs come from your own files — catalog sets 12.1 and 12.2 are separate uploads, so a bond borrowed at 100 and posted at 90 reads as 100 and 90 here.

🧪 Test cases for US11.18 5 scenarios

RULE-46 One agreement type, two windows, and the agreements inside them

Do: Open Optimization Results and click the top row of Summary by bond (XSBIY8G8VPB6). Read the Posted to list. Then open the first Bilateral CSA IM row.

Verify: Bilateral CSA IM appears on two rows, not one — $28.20mm settling 19/06/2026 and running to 14/03/2030, and $14.10mm settling 20/06/2026 and running to 14/03/2031. They add to $42.30mm, which is what the run posted to that type. Their Expected Margin Call figures read $138.00mm and $69.00mm, and those are the agreements’ own calls — the same two figures appear against Bilateral CSA IM under every other bond, because a call belongs to the agreement and not to one bond. The row you opened lists ISDA/CSA-IM-GS-001 under Agreements in this window, whose amount equals the $28.20mm on the row above; the second lists ISDA/CSA-IM-GS-002. Open Triparty and its agreements are named by counterparty, never by a TRI code.

RULE-47 Amend at agreement level, with one control and a margin-call check

Do: With that bond open, press ✎ Edit on the Posted to heading. Change the Collateral Amount on ISDA/CSA-IM-GS-001 from 28.20 to 1 and press Save. Then press ✎ Edit again and click the ✕ beside that agreement; then click Keep.

Verify: there is no Edit button on any row — one on the heading, and that is all. Pressing it opens every window and puts a box on each agreement line; the window rows above them stay read-only. After Save the agreement reads User edited, its window falls to $1.00mm, the bond’s Posted figure drops by $27.20mm to $281.35mm, and the run total falls from $1,782.60mm to $1,417.60mm — on this screen and on the flow table below, because it is one record. A message above the list names ISDA/CSA-IM-GS-001 among the agreements now short of their expected margin call, with what is posted, what is expected and the shortfall. The ✕ greys the line, drops the window to $0.00mm and marks it Proposed for removal; Keep puts it back. Typing 28.20 back returns the line to System proposed.

RULE-43 The summary leads the screen and ties to the two tables

Do: Open Optimization Results. Read the Summary by bond totals row. Then read the totals row on Internal sources of bonds, and the one on Where the bonds are posted to.

Verify: the summary sits above both tables. Its Borrowed total equals the Amount total on Internal sources of bonds. Its Posted total equals the Amount total on Where the bonds are posted to. It lists fewer rows than either table, because several movements of one bond are one row here.

RULE-44 Opening a bond shows both legs

Do: Click the top row of Summary by bond. Note the ISIN and its Posted figure.

Verify: the row opens and two lists appear: Borrowed from and Posted to. The Borrowed from list names the desk and portfolio, with the start and end dates and the rate. The Posted to list names each agreement and where it settles, with its own dates and rate. The Amounts in Posted to add up to the Posted figure on the row you clicked. Clicking the row again closes it.

RULE-45 An amendment moves the summary

Do: Note a bond’s Posted figure in the summary. Scroll to Where the bonds are posted to, filter it to that ISIN, and click Propose removal on one of its rows. Scroll back up.

Verify: that bond’s Posted figure in the summary has dropped by the amount of the row you removed, and so has the Posted total. Opening the bond shows the removed line is gone from Posted to. Clicking Keep in run on that row puts both figures back.

US11.19 As a user, I can choose which run I am looking at, and see when it was run so I never mistake this morning’s answer for last week’s.

▸ Optimization Results — the run picker

What it is: every figure on this screen belongs to one run. The picker sits at the very top, above the summary, because it governs everything below it.

Checklist — what this story requires

A Run picker leads the screen. It lists every saved run.
Each run is labelled with its name, then the date and time it was last run, as dd/mm/yyyy hh:mm.
Beside the picker sits the run’s shape: how many movements, how many obligations, whether Sweep the deck was on, and how many runs are saved.
Choosing a run redraws the whole screen for it — the summary, both tables and the five views underneath.
Choosing a run stamps it as run now, because reading it puts it through the optimiser again. Its label updates to the current time.
This is the same active run the Rules engine uses. Switching here switches there, and the other way round.
A run made before this stamp existed is stamped the first time it is loaded, so no run is ever unlabelled.
A run created with + New or Duplicate is stamped as it is made.

🧪 Test cases for US11.19 2 scenarios

RULE-46 Every run is named and time-stamped

Do: Open Optimization Results and open the Run picker.

Verify: every saved run is listed. Each entry reads its name, then a dash, then a date and a time, for example Baseline (all GFM) — 09/09/2026 10:39. None is unlabelled. Beside the picker the run’s shape is stated: the number of movements, the number of obligations, whether sweep is on, and how many runs are saved.

RULE-47 Switching runs redraws everything, and both screens agree

Do: Note the Summary by bond count. Choose a different run in the picker. Then open the Rules engine tab and read its Active run box.

Verify: the summary, both tables and the views underneath all redraw for the run you chose. The chosen run’s label now carries the current time, because reading it ran it. The Rules engine’s Active run is the same run — there is one active run, shared by both screens.

US11.20 As a user, I can see the bonds and the agreements side by side and pick one to filter the other so I stop holding one list in my head while I read the other.

▸ Optimization Results — Proposed Optimization Results UI

What it is: the same run, grouped both ways at once, on one screen. It leads the tab, directly under the run picker — it is the first thing a user sees, because it answers whichever of the two questions they arrived with. Everything it replaced is still there: Summary by bond, Where the bonds are posted today and the two flow tables are folded away under ▸ The long form, one click below it, unchanged.

The two questions are asked together, not one tab at a time. A bond goes to several agreements and an agreement is met by several bonds, so whichever grouping is on screen, the other half of the answer is on the tab you are not looking at. Here both are up at once: bonds on the left, agreements on the right. Pick a row on either side and the other side becomes just the records related to it. Pick the same row again and both go back to the whole run. Nothing is hidden behind a toggle, and nothing has to be remembered across a click.

Checklist — what this story requires

Two panes, one run. Both are built from the same rows the run published, amendments included, so they cannot disagree. Only the grouping differs.
With nothing picked, the left pane lists every bond in the run — ISIN, Sourced, Posted and Aggs, the number of agreements that bond feeds — and the right pane lists every individual agreement in the book, sorted with the biggest shortfall first, because the agreement furthest from being covered is the one worth reading first. Its columns are Agreement, Counterparty, Call, Value and Short. Each pane closes with its own totals row — the bond side counting the bonds listed, their two column totals and how many agreements they feed between them.
Picking a bond rewrites the right pane into that bond’s own story, in the order things happen: 1 · Borrowed fresh from the desk, 2 · Recalled from where it is posted today, and 3 · Proposed post to. Each section carries its own subtotal, and each recall line names the exact individual agreement the collateral has to be called back from — never just the kind of contract. Each block carries the same fields as the same block under Summary by bond, because it is the same record read from the other side: the borrow block shows Desk (Source), Portfolio (Source), Direction, Amount, Start Date, End Date, Rate and Status; the recall block Agreement (currently meeting), Counterparty, Held at, Direction, Market value and Collateral value; the posting block Agreement, Counterparty, Destination, Direction, Collateral Amount, Expected Margin Call, Collateral Value, Settlement Date, Repo Start, Repo End, Source, Cost of funds and Status. Each block has its own heading and scrolls sideways on its own, so a wide block never carries its heading off the screen.
Picking an agreement rewrites the left pane into the postings meeting that one call — one row per posting, with the same fields the by-agreement drill-down carries: its ISIN, the Agreement type it goes under, its Collateral Amount and Collateral Value, its Settlement Date, Repo Start and Repo End, its Source (the desk, or the exact agreement it is recalled from), its Cost of funds and its Status — and a totals row.
The side you picked on is not filtered. Its full list stays, with the picked row highlighted, so you keep your place and can step down it one row at a time.
The detail is itself clickable. An agreement named inside a bond’s postings, or an ISIN named inside an agreement’s postings, is a link: clicking it moves the selection to that record on the other side. That is how a user walks from a bond, to an agreement it feeds, to the other bonds feeding the same agreement, without going back to a filter box.
A strip above the two panes says in words what is picked — the bond and how many of the book’s agreements it feeds, or the agreement and how many of the run’s bonds meet it — or, with nothing picked, that both sides show the whole run.
The run’s own four totals sit on that strip and never move: Sourced, Posted, Value and Short, always for the whole run. A pane narrowed to one record must never leave the user thinking the run itself got smaller.
What is proposed is amended here too, at the agreement, through the same amendment layer as Summary by bond (see US11.18) — there is one record, so a change made on either screen shows on both at once.
The two panes sit side by side on a wide screen and stack, bonds first, on a narrow one. Each scrolls on its own so a long list never pushes the other pane off the screen.

Checklist — the headline, by kind of agreement

Before either grouping, the question a desk asks first is how the run is doing against each kind of paper — Bilateral CSA IM, Bilateral CSA VM, GMRA, GMSLA, CCP, Futures, Triparty. That is the headline, and it leads the panel.

One row per kind of agreement, with the two figures that matter: the Expected Margin Call that kind expects to be called for, and the Proposed post the run wants to put against it. Biggest call first, and a totals row closes it.
Opening a row shows the postings inside it — one line per posting, naming the individual agreement, the ISIN going to it, the Collateral Amount and that agreement’s own Expected Margin Call. An agreement of that kind with nothing posted to it is listed too, saying so in words, because that is the one worth seeing. A subtotal closes the drill with how many postings and how many agreements.
The names inside the drill are doors. Clicking an agreement or an ISIN there picks that record in the two panes below, exactly as picking it in either pane would.
The headline obeys the searches like everything else, and its totals tie to the run: the calls add up to what the whole run is called for, and the proposed posts add up to what the run posts.
A kind of agreement can show more proposed than called for, and that is not an error — a desk may post a buffer over the call (see the amending rules below).

Today’s headline. GMRA expects $567.00mm and the run proposes $579.15mm — more than the call, on purpose; GMSLA $318.00mm against $194.10mm; Bilateral CSA VM $247.00mm against $100.80mm; Bilateral CSA IM $207.00mm against $210.30mm; CCP $185.00mm against $150.75mm; Triparty $141.00mm against $144.00mm; Futures $92.00mm against $65.70mm. Seven kinds, $1,757.00mm expected and $1,782.60mm proposed — the run’s own two totals. Opening Bilateral CSA VM shows 4 postings across 2 agreements adding to the $100.80mm on the row above it.

Checklist — the three searches

Production holds thousands of bonds and hundreds of agreements, so the user arrives knowing a name, not a row number. Three boxes sit above both panes, one for each name they might know.

Search ISIN, Search agreement and Search counterparty, side by side at the top of the panel. They match on part of the name, ignoring case, and take effect as the user types.
Each search narrows BOTH panes, because the two sides are the same run read two ways. A bond stays listed while any of its lines is with an agreement or counterparty that matches; an agreement stays listed while any bond meeting it matches the ISIN.
Inside an opened record the same searches narrow the rows that carry the field being searched for — the recall and posting lines by agreement and counterparty, the postings meeting an agreement by ISIN.
Searching narrows which rows are listed; it never changes what a row says. A bond that is listed still reports everything it sourced and posted, not just the part that matched.
Each pane’s heading counts what is listed out of what there is (“By bond · 5 of 6 bonds”) and its totals row adds up the rows listed. The run’s four totals on the strip do not move, because the run did not change. A Clear searches control appears as soon as anything is typed, and matching nothing says so in words rather than showing an empty table.

Checklist — amending from this panel

A user can only choose what exists. Collateral is not conjured: a borrow is a draw on an inventory line the firm actually holds, a recall is a call on collateral that is actually posted out, and a posting can only go to an agreement that would accept the bond. So all three are chosen from a list of what is there rather than typed in free hand, and what can be borrowed or called back is capped by what is there. The one figure left open is what goes OUT, because a desk may deliberately post more than the call.

One control per block, on the block’s own heading, exactly as under Summary by bond: ✎ Edit turns that block into an editable grid and offers Save and Cancel in its place. Only one block is ever in edit mode.
Borrowed fresh from the desk — the row IS an inventory line. Edit mode offers a list of the lines the firm holds (each one reading its ISIN, portfolio, desk and what it holds) and a box for how much of it to draw. Picking a different line — another portfolio, another desk, another bond — moves the borrow to that line, and it brings that line’s own dates and rate with it. The amount can never exceed what the line holds: a larger figure is written back as the whole line. The desk, portfolio, dates and rate are never typed, because a borrow from a desk that does not hold the bond is not a borrow.
Recalled from where it is posted today — the figures are facts, the decision is which to call. The block lists every posting of that bond that is out there today, each reading Being called back or Left where it is, and edit mode offers ✕ to leave one where it is and Call it to call it back. What is posted there cannot be edited — it is the book, not a proposal — so nothing can be called back that is not out there. To call somewhere else instead, leave this one and call another: on a Sweep the deck ON run everything starts called, on a Sweep OFF run nothing does, and either way the user says which. The subtotal counts only what is actually being called.
Proposed post to — the agreement itself can be changed. Each row is an individual agreement line, so it offers a list of the agreements this bond is eligible for (the same eligibility the optimiser applies before it ranks anything) and a box for the Collateral Amount. Sending a posting to another agreement takes that agreement’s counterparty, its own expected margin call, its settlement date, its end date and where it is held with it — and an end date is still never past the day the firm’s own holding of the bond ends. The amount is deliberately not capped: posting more than the call is a buffer a desk may want, and the screen lets them set it.
A block can be added to as well as amended. While a block is in edit mode it carries a + Add control beside Save and Cancel, and what it offers is, again, only what exists:
- + Add on the borrow block starts a new borrow on an inventory line the firm holds — it opens on a line of the bond on screen, the same list of held lines is there to change it to any other, and the amount starts at nothing and cannot pass what the line holds. The new row reads User added.
- + Add on the recall block asks where to recall this bond from, and lists the postings of that bond that are out there and not already being called — each naming the agreement holding it, its counterparty, where it is held and how much. Picking one calls it back. When every posting of the bond is already being called, it says so rather than offering an empty list.
- + Add on the posting block starts a new posting to an agreement the bond is eligible for, with the same list to change it to any other, and an amount that starts at nothing. It behaves from then on exactly like a posting the run proposed: it carries that agreement’s expected margin call, counterparty, settlement date, end date and where it is held, it counts towards that agreement’s coverage, and it can be amended or removed again.
Each editable line offers a ✕ that proposes it for removal and a Keep that puts it back. A line proposed for removal stays listed, greyed, or the removal could never be undone here. On the recall block the pair reads ✕ and Call it, and every posting of the bond stays listed either way, marked Being called back or Left where it is.
An amendment made here is the same amendment made anywhere else. It moves Summary by bond, the flow tables and the run totals the moment it is saved, and anything put back exactly as the run proposed it — a figure typed back, an agreement picked back, a recall called again — stops being an amendment and reads System proposed again.
The same rules hold wherever these rows are edited, because it is one record: the borrow rows under Summary by bond and on Internal sources of bonds offer the same list of inventory lines and the same cap, and the agreement lines under Summary by bond offer the same list of eligible agreements.
The margin-call check speaks here too, in the same words: while a block is being edited, and for as long as any amendment stands, a message above the blocks names every individual agreement whose expected margin call is not met, what is posted, what is expected and the shortfall. It is measured on collateral value, run over the whole run rather than the record on screen, and it flags without blocking.

The worked example, in today’s run. With nothing picked the strip reads Sourced $2,464.08mm · Posted $1,782.60mm · Value $1,756.89mm · Short $0.22mm; the left pane closes on 15 bonds at those first two figures and the right pane on 14 agreements expecting $1,757.00mm, covered to $1,756.89mm — met in full, the $0.22mm being rounding rather than a shortfall. Pick XSV2KLI4P6V3 and the strip reads “XSV2KLI4P6V3 → 12 of 14 agreements”: the right pane shows 1 line borrowed from SG Credit Trading for $308.00mm — the Sourced figure on the row still highlighted on the left — nothing to recall, because none of that bond is posted out today, and 12 postings totalling $305.55mm, which is that row’s Posted. Click GMRA/BRC-SGP-001 in that list and the sides swap roles: the strip reads “GMRA/BRC-SGP-001 ← 6 of 15 bonds” and the left pane shows those 6 postings for $345.22mm, worth $340.04mm — the same Value printed against that agreement on the right, against its $340.00mm call. Every figure on this panel is one of the run’s own figures read a different way round.

🧪 Test cases for US11.20 9 scenarios

RULE-48 Both groupings are on screen, and the run’s totals never move

Do: Open Optimization Results. Proposed Optimization Results UI is the first thing on the tab, under the run picker. Read both panes and the strip above them, picking nothing.

Verify: the panel opens the tab, above ▸ The long form. The left pane lists 15 bonds totalling $2,464.08mm sourced and $1,782.60mm posted; the right lists 14 agreements totalling $1,757.00mm expected and $1,756.89mm covered, with the biggest shortfall on top — today every agreement is met, so the Short column reads a dash or a rounding cent. The strip says both sides show the whole run and carries those same four totals.

RULE-49 Picking a bond rewrites the other side into its three legs

Do: Click XSV2KLI4P6V3 in the left pane. Read the right pane. Then click the same row again.

Verify: the strip reads “XSV2KLI4P6V3 → 12 of 14 agreements” and the four run totals are unchanged. The left pane still lists all fifteen bonds, with the picked row highlighted. The right pane is now three blocks: 1 · Borrowed fresh from the desk (one line from SG Credit Trading, $308.00mm, funding 12 postings), 2 · Recalled from where it is posted today (nothing to recall — none of this bond is posted out, and it says so in words) and 3 · Proposed post to (12 postings, $305.55mm, worth $301.78mm). The borrow equals the $308.00mm Sourced on the highlighted row and the postings equal its $305.55mm Posted. Clicking the row again puts both panes back to the whole run.

RULE-50 Picking an agreement flips the panel, and the detail is clickable

Do: With XSV2KLI4P6V3 picked, click GMRA/BRC-SGP-001 where it is named in the right pane’s Proposed post to list.

Verify: the selection moves to that agreement rather than clearing. The strip reads “GMRA/BRC-SGP-001 ← 6 of 15 bonds”. The right pane is the full list of 14 agreements again, with GMRA/BRC-SGP-001 highlighted. The left pane is now 6 postings from 6 bonds, each naming where the bond comes from, totalling $345.22mm and $340.04mm of value — the same value printed against that agreement on the right, against its $340.00mm call. Clicking an ISIN in that left list moves the selection back to that bond.

RULE-51 One search narrows both sides at once

Do: With nothing picked, type GMRA into Search agreement. Read the headline, both pane headings, both totals rows and the strip.

Verify: the headline falls to one kind of agreement, the left heading reads “By bond · 8 of 15 bonds” and the right “By agreement · 2 of 14 agreements” — the two GMRA agreements, and only the bonds that feed them. The panes’ totals rows add up the rows listed ($1,807.92mm sourced and $1,330.80mm posted on the left; $567.00mm expected and $567.06mm covered on the right), while the strip still reads the whole run’s $2,464.08mm / $1,782.60mm / $1,756.89mm / $0.22mm. Each listed bond still shows everything it sourced and posted, not only the GMRA part. Clear searches puts everything back, and a search matching nothing says so in words.

RULE-52 A posting is amended from this panel, at the agreement, into the same record

Do: Pick GMRA/BRC-SGP-001 on the right. Press ✎ Edit on the left pane’s heading, change the XSV2KLI4P6V3 line’s Collateral Amount from 69.08 to 10 and press Save. Then press Edit again, click the ✕ on that line, click Keep, type 69.08 back and Save.

Verify: there is one Edit control, on the heading — none on any row. After Save the line reads User edited, the left totals fall by the $59.08mm taken off, that agreement’s row on the right falls with them and shows a shortfall where it had none, and the strip’s run totals fall by the same amount — the same figures Summary by bond and the flow tables now show, because it is one record. The message above the block names the agreement that is no longer covered. The ✕ greys the line and leaves it listed so Keep can put it back; typing 69.08 back returns the line to System proposed and the run to $1,782.60mm / $1,756.89mm exactly.

RULE-53 A borrow can only be a draw on a line the firm holds, and never for more than it holds

Do: Pick XSBIY8G8VPB6 on the left and press ✎ Edit on 1 · Borrowed fresh from the desk. Read the row. Type 9999 into the amount and press Save. Press Edit again, type 151 back and Save. Press Edit once more and open the list.

Verify: the desk, portfolio, dates and rate are not typeable; the row offers a list of the 30 inventory lines the firm holds, each reading its ISIN, portfolio, desk and what it holds (this one reads XSBIY8G8VPB6 · London Repo Desk · Fixed Income Financing · holds 818.70), and a box for the amount whose ceiling is that figure. Saving 9999 writes back $818.70mm — the whole line, never more — and Sourced on the strip rises to $3,131.78mm. Typing 151 back returns the line to System proposed and the run to $2,464.08mm / $1,782.60mm / $1,756.89mm / $0.22mm. Picking a different line moves the borrow to that line and brings its desk, portfolio, dates and rate with it. The same list and the same ceiling appear on the borrow rows under Summary by bond and on Internal sources of bonds.

RULE-54 Nothing can be called back that is not posted out, and a posting can go elsewhere — buffer included

Do: Pick SGV8J7IDADZ1, a bond that IS posted out today. Press ✎ Edit on 2 · Recalled from where it is posted today and click ✕ on ISDA/CSA-VM-MS-001; then click Call it on the same line. Cancel, press ✎ Edit on 3 · Proposed post to, send a line to another agreement in the list and set its Collateral Amount to 500.

Verify: the recall block lists every posting of that bond that is out there — six of them, $331.25mm — each reading Being called back or Left where it is, and none of its figures can be typed. Leaving ISDA/CSA-VM-MS-001 drops the subtotal and Sourced on the strip by that line’s $67.92mm; Call it puts both back exactly. On the posting block the agreement is a list of the agreements this bond is eligible for — 12 of the book’s 14 for this bond — and moving a line takes that agreement’s counterparty, custodian, expected margin call and settlement date with it. $500.00mm against a call a fraction of that size is accepted and not trimmed — posting a buffer is the desk’s call — and Posted on the strip rises with it.

RULE-55 The headline reads by kind of agreement, and opens into the records behind it

Do: Open Optimization Results and read the table at the top of the panel. Click Bilateral CSA VM. Then click an ISIN inside it.

Verify: seven rows, biggest call first: GMRA $567.00mm / $575.70mm, GMSLA $318.00mm / $322.95mm, Bilateral CSA VM $247.00mm / $250.95mm, Bilateral CSA IM $207.00mm / $209.10mm, CCP $185.00mm / $187.20mm, Triparty $141.00mm / $143.40mm, Futures $92.00mm / $93.30mm, totalling $1,757.00mm expected and $1,782.60mm proposed — the run’s own totals. Every kind proposes slightly more than the call, which is the haircut buffer and not an error. Opening Bilateral CSA VM lists 10 postings across 2 agreements — ISDA/CSA-VM-MS-001 and -002, taking $29.93–30.20mm and $20.02–20.20mm from five bonds each — adding to the $250.95mm above. Clicking an ISIN there picks that bond in the panes below.

RULE-56 A borrow, a recall and a posting can each be ADDED — but only from what exists

Do: Pick SGV8J7IDADZ1. On block 1 press ✎ Edit, then + Add, set the new row to 60 and Save. On block 2 press Edit, ✕ the first line, press + Add and pick that posting back. On block 3 press Edit, press + Add, set the new posting to 25 and Save.

Verify: the new borrow opens on a line of that bond, offers the same list of held lines, caps at what the line holds, and after Save reads User added with the block subtotal and the run’s Sourced both up $60.00mm. On the recall block the add control asks where to recall this bond from and lists only the postings of that bond not already being called — picking one calls it back and restores the subtotal exactly. The new posting opens on an agreement the bond is eligible for, carries that agreement’s expected margin call, settlement date and where it is held, reads User added, and after Save the block, Posted on the strip and that agreement’s coverage all rise by $25.00mm. Every added record can be amended, removed and kept back like any other, and shows the same way on Summary by bond and the flow tables.

US11.21 As a user, I can run the same run through a different optimisation model and compare what each proposes so the algorithm behind the recommendation is a choice I make, not one that was made for me.

▸ Optimization Results — Optimization Model Research by AI

What it is: a panel at the bottom of the Optimization Results tab. It sits under Optimisation Results, separated by a rule. A dropdown picks an optimisation model. The screen then shows what that model would propose for the run on screen.

The engine is one way of deciding, not the only way. Today it fills the fussiest obligation first. Inside each one it posts the cheapest eligible bond. It never revisits a decision. That is a heuristic: a sensible shortcut, with no claim to be the cheapest answer. Other algorithms make the same decision differently. Some solve the whole book at once. Some improve an answer they already have. This panel runs them over the same run and shows what each proposes.

Picking a model here does not change the run. Every screen above this panel still shows the engine's answer. This panel answers a different question. It asks what a different algorithm would have proposed. Choosing which model the engine itself uses is a separate decision, raised as OQ-46.

It is read the way the Rules engine is read. The Rules engine draws a run as input → process → output. So does this panel, and for the same reason. Those three columns are what a reader compares when choosing between two algorithms. The input column is identical whichever model is picked. That is deliberate: every model is handed the same scoped obligations, the same eligible pool, the same holdings and the same limits. The process column is the model's own way of deciding. That is the only thing that differs. The output column is what it proposes, and what carrying it costs.

Checklist — the picker

One dropdown, labelled Model, at the top of the panel. It lists every model by name, followed by a short tag. Greedy · cheapest-to-deliver is first, tagged “Production engine — what this app runs today”. It is the default the panel opens on.
The choice is remembered between visits, per browser, under the key collat-opt-model. A remembered model that no longer exists falls back to the first in the list.
A line beside the dropdown names the run being read: its name, how many rules are active, whether Sweep is on, the strategy rule in force, and how many models are being run over these same inputs.
Changing model repaints the panel only. Nothing above it moves, because the run did not change.
Changing the run, the rules or the parameters invalidates every model's answer. Each is worked out again the next time it is asked for. A model is never run until the picker asks for it.

Checklist — the three columns

Input — the same for every model. Four cards, and they do not change when the model changes. Eligible inventory counts the holdings that survive the run's rules, out of the whole book. Obligations to cover counts the obligations, their total, and how many margin calls are in scope. Eligibility schedules counts the agreements in scope, and how many holding-to-obligation combinations the schedules leave standing. Limits this run sets names the concentration cap, the minimum transfer amount, the settlement lot size and the haircut buffer.
Process — this is what differs. One card. It carries the model's family as a coloured tag, its name, one sentence saying what it does, and a numbered list of the steps it actually took. Under those sit the model's own run figures and how long it took in milliseconds.
The step list is what the model did on this run, not a description of the method. Where a step counts something, the count is the real one. The linear-programming model, for example, names how many decisions it wrote and how many pivots it took.
Output — what it proposes. One card, headed by the annual carry on what the model proposes. Under it: Postings (how many, from how many holdings), Posted (market value), Cover delivered, Coverage, Blended cost in basis points and Left short.
Coverage is green at or above 99.5%, red below. Left short reads nothing when the run is fully covered.
Left short is the obligation less the cover delivered — the same subtraction the coverage figure beside it is made from. The two can never disagree.
Three families, three colours. Heuristic is amber, Exact is blue and Metaheuristic is purple. The same colours are used in the comparison table below. Each tag carries its plain meaning as a hover, so nobody has to know the word to read the screen. Heuristic reads “a sensible shortcut — it decides one step at a time and never goes back”. Metaheuristic reads “starts from an answer it already has and keeps improving it”.
On a narrow screen the three columns stack, in the order input, process, output, and the arrows between them are dropped.

Checklist — what this model buys you, and what it costs you

Under the three columns sits a panel headed with the model's name and its tag. It has two lists side by side. ✓ What it buys you is green-headed, ✗ What it costs you is red-headed.
Every model carries both lists, and neither is ever empty. A model with no stated cost would be a recommendation dressed as a comparison.

Checklist — what this model proposes

A table of the model's own postings, one row each, sorted by agreement. Its columns are Agreement, Asset, Type, Holding, Post (mv), Haircut, Collateral value, Cost (bps) and Annual cost. They are the same columns the Full posting detail table above carries, less Action, because a model's proposal is not approved or ignored here.
A totals row closes it, counting every posting the model made, with the market value posted, the cover delivered, the blended cost and the annual cost.
The table shows at most 60 rows and says so when there are more. The totals row still counts the whole set. A production book proposes thousands of movements, so the panel shows a window rather than the population.
A model that proposed nothing says so in words, rather than showing an empty table.
Anything left short is listed under the table. Each entry names the obligation, the shortfall, what was owed, what the agreement accepts, its rating floor, its eligible issuer groups, and how many holdings were eligible.

Checklist — every model, side by side

One row per model, in the order they appear in the dropdown. The selected model's row is highlighted.
Its columns are Model (with its tag underneath), Family, Postings, Lines used, Posted (mv), Cover delivered, Coverage, Annual carry, Blended bps, Left short, vs engine and Ran in.
Left short also names where the shortfall lands, underneath the figure, biggest first. On a run where every model costs the same, this is the only column on which they differ.
vs engine compares annual carry against the production engine. The engine's own row reads baseline. A cheaper model reads green with a minus sign, a dearer one red with a plus. A model within one cent reads level.
Every row is the same run, totalled by the same function the screens above this panel use.

Checklist — the verdict under the table

The panel states whether the choice of model matters on this run, and it works that out from the models' own answers. It is never a fixed sentence.
When every obligation is covered, it names the linear-programming row as the floor. It states what that floor carries, what the engine carries, and what the shortcut therefore costs a year. It then gives the spread across all models, in carry and in coverage.
When cover is left on the table, it says so, and names the ceiling that actually bit. It states what the eligible book holds against what is owed. It states what even the best possible answer reaches. It then lists every short obligation, one line each.
Each of those lines names the binding constraint in words. The three it can name are too few eligible lines, the concentration cap and the order lines were spent in. Each line also gives what that obligation's eligible holdings could deliver with no cap, and what they can deliver once the cap applies. Comparing the two is what identifies the constraint.
This is the panel's most useful output. A model can only be worth changing if the algorithm is what is holding the answer back. When the schedules or the cap are the ceiling, no algorithm can beat them.

Checklist — developer build detail, other algorithms considered

A collapsed fold closes the panel, headed “Developer build detail — other algorithms considered and not built”. It opens with a line saying it is written for developers, that it is deliberately technical, and that business readers can skip it.
It holds a table of model families that were considered and are not built. Its columns are Model, What it would do, What it would add and What it would cost.
Nothing in it runs. It is a shortlist for the decision raised as OQ-46, not a feature.

Building the greedy model? Its exact logic — every step, every formula, every tie-break and every edge case — is written out in the Developer build detail fold at the end of this story. It is the only place on this tab that carries verbatim formulas.

The models — reference

Six models are built and can be picked. This table describes each in plain words, without its industry name. The Model column here says what the model does; the name in the dropdown is in the “Name on screen” column. It carries no formulas. The rules each one obeys are the run's own rules, unchanged.

Model	Name on screen	Family	How it decides	What it is good for
Shortcut, cheapest holding first	Greedy · cheapest-to-deliver	A sensible shortcut	Serves the obligation with the narrowest eligibility schedule first. Inside each one it posts the cheapest eligible holding until it is covered. It never goes back on a decision.	Instant, and every posting has a reason a person can repeat. This is what the app runs today.
Shortcut, tightest obligation first	Greedy · most-constrained obligation first	A sensible shortcut	The same filling, but the queue is ordered differently. It measures how thin each obligation's own eligible pool is against what that obligation owes. The tightest one is served first.	Cutting shortfalls that are caused only by the order obligations were served in.
Shortcut, cheapest posting anywhere first	Global cost-ranked pair sweep	A sensible shortcut	There is no queue of obligations. It prices every holding-to-obligation combination in the book, sorts that one list cheapest first, and works down it.	Making the cheapest posting in the book first, wherever it happens to belong.
Solved in one go, any amount	Linear programming (exact optimum)	Worked out exactly, amounts unrestricted	It decides every posting at once rather than one at a time. A posting may be any amount, including one that could not actually be settled. Leaving an obligation uncovered is priced far above the dearest holding in the book. So it finds cover first, and argues about cost second.	The cheapest answer that exists under these rules. It is the floor every other model is measured against.
Solved in one go, whole lots only	MILP · lot-constrained	Worked out exactly, amounts must be whole lots	The same problem, with every posting forced into whole settlement lots. It works out the best answer with that rule lifted. It then rounds every posting down to a whole lot. Finally it buys the remainder back, one cheapest lot at a time.	An answer that could be settled exactly as it stands. It also states what having to deal in whole lots cost.
Shortcut, then keep improving it	Heuristic + local search	Improves an answer it already has	It starts from the engine's own answer. It then looks at every posting for a cheaper eligible holding with room for it. It takes the best swap it finds, and looks again. It stops when no single swap improves anything.	Improving an answer you already have. It can be stopped at any point and still hand back a valid answer.

The worked example, in today’s run. Open Optimization Results on Baseline (all GFM) and scroll to Optimization Model Research by AI. The input cards read 27 of 30 lines eligible, 7 obligations · $1,757mm, 14 of 14 margin calls in scope, 7 of 7 agreements and 84 feasible combinations, under a 35% cap, a 0.15mm minimum transfer, $0.2mm lots and a 0.5% haircut buffer. Those four cards do not move whichever model is picked. Every model covers the whole requirement on this book — 100.0%, $1,756.9mm of cover — so what separates them is what that cover costs to carry. Greedy · cheapest-to-deliver, the engine’s own procedure, proposes 36 postings from 14 lines, $1,782.6mm posted, at $1.38mm a year and 8 bps. Linear programming (exact optimum) lands the same cover for $1.33mm a year: the greedy shortcut costs about $0.05mm a year, which is the price of deciding one obligation at a time and never going back. Greedy · most-constrained obligation first recovers roughly $0.02mm of it by changing nothing but the queue, and the Global cost-ranked pair sweep about $0.04mm. MILP · lot-constrained reaches the same carry as the linear programme in 50 whole-lot postings rather than 37, which is what a settleable answer costs in movements. Heuristic + local search reads level: it only looks for cheaper lines, and the greedy it starts from already took the cheapest, so it finds 0 improving swaps.

What the panel is really for. The verdict under the table is chosen by what separates the models, not by whether everything was covered. Where they differ on cover it prices the gap to the linear programme and credits what re-ordering the queue alone recovers. Where they cover the same and differ on carry — today’s reading — it names the linear programme as the floor and says what the shortcut costs a year. And where they cannot be told apart at all, it says so and names the limit that is binding instead, because that is the run where the algorithm is not the thing to fix. A book with several times more eligible collateral than it owes, or obligations that are all capped out, will produce that third reading — six identical rows are a fact about the rules, not a fault in the models.

🔧 Developer build detail — the greedy model’s logic, step by step business readers can skip this

Skip this section unless you are building the engine. Everything above says what the greedy model does in words. This says it exactly, with every formula, every tie-break and every edge case, so a developer can build it without reading the demo’s source. It is the logic for Greedy · cheapest-to-deliver — the model the engine runs today. The other five models reuse steps 0, 2, 3 and 5 unchanged and differ only where noted in their own rows of the models table above.

D1 · What the model is handed

One builder produces the whole run context, once, before any allocation happens. Every model is handed the same object. Nothing downstream re-derives any of it.

Name	What it holds	How it is worked out
`concPct`	Run concentration cap, per cent	Run parameter. Falls back to 100 when unset.
`mta`	Minimum transfer amount, $mm	Run parameter. Falls back to 0.
`round`	Settlement lot size, $mm	Run parameter. 0 means no rounding.
`buffer`	Extra haircut added to every posting, per cent	Run parameter. Falls back to 0.
`strat`	Ranking strategy for the pool	The value of the run’s single active match rule. Defaults to `cheapest` when the run has none.
`fr`	The run’s active filter rules	Every rule that is enabled AND selected into this run, of kind `filter`.
`sweep`	Sweep the deck, on or off	Run parameter. ON is the default — only an explicit `false` turns it off.
`avail[lineId]`	Market value of each line still free to post, $mm	Sweep ON: the line’s whole market value. Sweep OFF: market value less what is already pledged out, floored at 0.
`elig`	Inventory lines that survive the run’s filter rules	Every line for which every filter rule passes. Book-wide; the per-obligation test comes later.
`calls`	The obligations this run must cover	See D2.

D2 · Step 0 — build the obligations

Take every individual margin call whose direction is “post”. Calls where collateral comes IN are not this engine’s business.
Drop the ones the run scopes out. A call is in scope only if it passes every call-level filter rule and its agreement passes every agreement-level filter rule. Both tests, not either.
Add the survivors up by agreement type. That total is gross requirement. The engine allocates against the type, not against each individual call, because collateral is posted under the type’s schedule.
Work out what is retained. Sweep ON retains nothing. Sweep OFF retains the collateral value already delivered against that agreement type, capped at the gross requirement.
Requirement = gross requirement − retained, floored at 0. That is what this run has to find.
Drop any agreement type whose gross requirement is 0.01 or less, and any whose agreement is out of scope.

Why gross and retained are both kept. A screen has to be able to say “$567mm owed, $0mm already posted, $567mm to find”. Storing only the difference loses two thirds of that sentence.

D3 · Step 1 — decide the order obligations are served in

Sort the obligations by how many asset classes each will accept, fewest first. An agreement that takes only cash and government paper is served before one that will also take corporates.
The sort must be stable. Obligations accepting the same number of classes keep the order they arrived in. See the warning below — this tie-break decides who goes short, and it is not a business rule.
The order is fixed before any allocation starts. It is never recomputed as inventory is spent.

⚠ Two known weaknesses in this step, both real and both worth a decision before you build it. First, it measures the wrong kind of fussiness. The count is of accepted asset classes only. It ignores the issuer-group list and the rating floor, which are usually what actually thins a pool. Read the eligible-line counts off today’s run in the order this step serves them: 17, 17, 12, 5, 5, 10, 16. The two thinnest pools are served fourth and fifth, behind two obligations with seventeen lines each. A genuinely most-constrained order would have been 5, 5, 10, 12, 16, 17, 17. Bilateral CSA VM is the clearest case: it accepts three asset classes, so it sorts late, but its schedule accepts Sovereign issuers only, leaving it 5 eligible lines against a $247.0mm call. At a 20% cap those five lines can deliver exactly what it needs and not a dollar more, so it covers with zero slack. It is not short today only because the book is deep enough to absorb the mistake. Second, the tie-break is arbitrary. Four obligations accept two classes each, so their order is simply the order they sit in the source data. Whichever sits last is the one that pays when the book is thin. Neither weakness is a bug — the code does what this step says — but both are why the most-constrained-obligation-first model exists, and both belong to OQ-46.

D4 · Step 2 — decide whether to serve this obligation at all

Already topped up. If something is retained and the remaining requirement is 0.01 or less, skip it. Log it as “nothing to top up”. It is not a shortfall.
Under the minimum transfer amount. If the requirement is below the MTA, skip it. Log it as skipped. It is not recorded as a shortfall either — nobody is owed a movement that is too small to make.
Both tests read the remaining requirement, never the gross.

D5 · Step 3 — build this obligation’s eligible pool

Start from the run’s eligible lines and apply four tests. All four run before any cost ranking. A cheaper line that fails any of them is never a candidate, however cheap.

Asset class. The line’s type must be on the agreement’s accept-list.
Issuer group. The line’s issuer group must be one the agreement’s eligibility schedule names. An agreement with an empty group list restricts nothing.
Rating floor. The line’s rating must be at or above the floor. The floor is the stricter of the margin call’s own minimum rating and the agreement’s. Ratings rank AAA, AA, A, BBB, BB, then anything unrecognised last.
Availability. The line must have more than 0.01 of market value still free. This is re-tested on the live figure, so a line spent by an earlier obligation drops out here.

D6 · Step 4 — rank the pool

The run’s strategy rule chooses the ranking. Four are defined. Cheapest (the default) sorts by effective cost ascending. Prefer internal sorts internal holdings first, then external-held, then received, and uses effective cost inside each group. Prefer liquid sorts cash first, then government, then everything else, and uses effective cost inside each group. Longest maturity sorts by years to maturity descending, and uses effective cost to break ties.
Effective cost is the tie-break in all four. It is the line’s funding cost in basis points divided by one minus its effective haircut — what a dollar of cover costs, not what a dollar of bond costs. A cheap bond with a punishing haircut is not cheap.
The ranking is computed once per obligation, on the pool as it stands when that obligation is served.

D7 · Step 5 — fill the obligation

Walk the ranked pool from the top. Two figures are carried: need, the cover still to find, which starts at the requirement; and availability, per line, shared across every obligation.

Stop test, checked before each line. Stop when need is at or below the done tolerance. That tolerance is half the lot size, or 0.01 if that is larger. A residual under half a lot rounds to nothing and can never be delivered, so chasing it only produces a queue of zero-value postings.
Concentration cap. One line may deliver at most the requirement times the cap, as a percentage. The cap used is the lower of the run’s cap and the agreement’s own limit. It is measured in collateral value, not market value, and it is measured against this obligation’s requirement — not against the book and not against the line.
How much cover to take from this line is the smallest of three: what is still needed, the concentration cap, and what the line’s remaining availability is worth after its haircut. If that comes to 0.01 or less, move to the next line.
Gross it up to a market value. Divide the cover by one minus the effective haircut, then round to the nearest lot. Round to nearest, not down.
Clamp to what the line holds. Rounding up can ask for more than the line has, so cap the market value at the line’s remaining availability. If what is left is 0.001 or less, make no posting and move on.
Record the posting and recompute the cover from the final market value, after rounding and clamping — never from the amount asked for before them.
Decrement both figures. Take the market value off the line’s availability. Take the cover off need. The line is now partly spent for every obligation still to come.

⚠ The rounding is the subtle part. Rounding to nearest, then clamping, means the cover actually delivered can be slightly more or slightly less than the cover asked for. So the cover must be recomputed from the final market value. Deriving it from the pre-rounding figure is the single easiest way to build this wrong: totals stop tying and the error compounds down the pool. The same rule applies on the way out — round once, when a figure is printed, never when it is stored.

D8 · Step 6 — record what could not be covered

After the pool is exhausted, if need is still above the done tolerance, record a shortfall. Otherwise record the obligation as fully covered.
A shortfall carries what it was, so a screen never has to reconstruct it: the agreement, the counterparty, the gross requirement, the retained amount, the requirement, the covered amount, the shortfall, the eligible line count, the accepted classes, the rating floor and the eligible issuer groups.
It also carries why — two ceilings, worked out separately. The uncapped ceiling is what the eligible pool could deliver with no concentration cap at all. The capped ceiling is what it can deliver once the cap applies to each line. If the uncapped ceiling is below the requirement, the binding constraint is too few eligible lines. If only the capped ceiling is below it, the binding constraint is the concentration cap. If neither is below it, the obligation could have been covered and was not, so the binding constraint is the order lines were spent in — which is the one case where a different model would have done better.
Skipped obligations never produce a shortfall row (D4). So the sum of the shortfall rows is not the run’s uncovered total — see D9.

D9 · Step 7 — totals

Every total comes off the posting list, through one function, ignoring any posting a user has marked ignored. Market value posted, collateral value delivered and annual cost are simple sums. Blended cost is annual cost divided by market value posted, expressed in basis points, and is 0 when nothing was posted.
Uncovered total is the requirement less the cover delivered — never the sum of the shortfall rows, which excludes skipped obligations and obligations covered to within the done tolerance. The two figures differ by a few cents on today’s run, and showing both on one screen is a defect (see the bug log entry of 16 Sep 2026).
The all-cash baseline is the requirement priced at the funding cost of a USD cash line, or of any cash line if there is no USD one, or 45 basis points if the book holds no cash at all.

D10 · Every formula in one place

Amounts are $mm. Costs are basis points a year. bps means one hundredth of one per cent.

Figure	Formula	Note
Effective haircut	`min(0.95, line.haircut + agreement.haircutAddon/100 + run.buffer/100)`	Capped at 95%. Three parts: the schedule’s base, the agreement’s add-on, the run’s buffer.
Effective cost	`line.fundingBps / (1 − effectiveHaircut)`	bps per $1 of cover delivered. The only figure any ranking uses.
Concentration cap	`requirement × min(run.concPct, agreement.concLimit) / 100`	In collateral value. Agreement limit absent → use the run’s.
Done tolerance	`max(0.01, run.round / 2)`	Half a lot. Below this, the obligation counts as covered.
Cover to take	`min(need, cap, avail × (1 − effectiveHaircut))`	Skip the line if this is ≤ 0.01.
Market value to post	`min(avail, roundToNearest(coverToTake / (1 − effectiveHaircut), run.round))`	Round then clamp, in that order. Skip if ≤ 0.001.
Cover delivered	`postMv × (1 − effectiveHaircut)`	Recomputed from the final market value, after rounding and clamping.
Annual cost of a posting	`postMv × line.fundingBps / 10000`	Priced on market value posted, not on cover delivered.
Blended cost	`totalAnnual / totalPostMv × 10000`	0 when nothing was posted.
Uncovered total	`totalRequirement − totalCoverDelivered`	Never the sum of the shortfall rows.

D11 · Edge cases a build must get right

A haircut of 100% would divide by zero. The effective haircut is capped at 95%, which is what stops it. Do not remove that cap.
Rounding can ask for more than the line holds. Always clamp after rounding, never before.
A line can be posted to several obligations. Availability is shared and mutable across the whole run; the concentration cap is per obligation and does not restrain the total a line gives to the book.
An obligation under the MTA is skipped, not failed. It produces no posting and no shortfall row.
Sweep OFF with no existing-postings data retains nothing, so the run behaves exactly like Sweep ON. Say so on screen rather than letting it look like a deliberate result.
A lot size of 0 means no rounding, and the done tolerance falls back to 0.01.
Order dependence is real and must be reproducible. Given the same inputs the model must produce the same postings every time, so the obligation sort must be stable and the pool sort must be deterministic.

The worked trace, in today’s run. Run Baseline (all GFM): cap 35%, MTA 0.15mm, lots $0.15mm, buffer 0.5%, strategy cheapest, Sweep ON. 27 of 30 lines survive the run’s 5 filter rules, leaving 84 workable line-and-obligation combinations. Seven obligations total $1,757mm. Step 1 settles the order as Bilateral CSA IM, GMRA, GMSLA, Futures (two accepted classes each), then Bilateral CSA VM, CCP, Triparty (three each). Bilateral CSA IM goes first: it needs $207mm, accepts Cash and Govt from Sovereign, Agency or Supranational issuers rated AA or better, and its own 20% limit beats the run’s 35%, so no line may deliver more than $41.4mm of cover. 17 of the 27 lines pass the four eligibility tests. The cheapest is FRANCE OAT 0.875% 01/27 at 7bps; the cap binds before the need does, so it posts $41.9mm of market value for $41.4mm of cover. Four more capped postings follow and the fifth takes need below half a lot — fully covered on 5 postings, five times $41.4mm being exactly the $207mm owed. Bilateral CSA VM, served fifth, shows the fill loop with no room in it: 5 eligible lines, each capped at 20% of a $247.0mm call, so all five are needed and all five are used. Across the run: 36 postings, $1,782.6mm of market value posted, $1,756.88mm of cover against $1,757mm owed. Note what that leaves. No obligation recorded a shortfall — every one finished within half a lot — yet $0.12mm is still uncovered. That is D9’s rule made visible: the sum of the shortfall rows is zero here, and the uncovered total is not. Build the uncovered figure as requirement less cover delivered, never by adding the shortfall rows up.

🧪 Test cases for US11.21 6 scenarios

RULE-53 The panel opens on the production engine and reads input, process, output

Do: Open Optimization Results on Baseline (all GFM). Scroll to the bottom, to Optimization Model Research by AI. Read the dropdown and the three columns without changing anything.

Verify: the dropdown reads Greedy · cheapest-to-deliver — Production engine — what this app runs today. The line beside it names the run, 8 rules active, sweep ON, strategy cheapest, and 6 models over these same inputs. The input column has four cards: 27 of 30 lines, 7 obligations · $1,757mm, 84 feasible combinations and the four limits. The process card is tagged Heuristic and lists four numbered steps. The output card reads $1.49mm, 29 postings from 12 parcels, $1,296.9mm posted, $1,269.5mm of cover, 72.3% in red, 11 bps and $487.5mm short.

RULE-54 Changing model changes only the process and output columns

Do: Pick Linear programming (exact optimum) in the dropdown. Read all three columns. Compare the input cards against what you read in RULE-53.

Verify: the four input cards are character for character the same. The process card is now tagged Exact · relaxed. Its steps read Listed the 84 postings it was allowed to choose from and Wrote down 108 ceilings: 7 obligations, 17 holdings, 84 concentration caps, with a time taken and Cheapest possible — yes, proven. The output card reads the same $1,756.9mm of cover as the engine, for $1.33mm a year rather than $1.38mm. Nothing above the panel has moved: the Full posting detail table still totals the engine's 27 postings.

RULE-55 The lot-constrained model settles in whole lots and states its gap

Do: Pick MILP · lot-constrained. Read the process card, then the postings table under it.

Verify: the steps say the best answer was worked out with the whole-lot rule lifted, that every posting was then rounded down to a whole $0.2mm lot, and that 16 lots were bought back one at a time. The figures name the lot size, the lots bought back, the best if lots could be any size and the extra cost of whole lots. The table lists 50 postings, fourteen more than the engine, and every Post (mv) is a whole multiple of the lot size — that count is what a settleable answer costs in movements.

RULE-56 The comparison table costs the same run six ways

Do: Scroll to Every model, side by side. Read every row. Note which row is highlighted, then change the dropdown and look again.

Verify: there are 6 rows, in dropdown order, each with its family tag in the family colour. The engine's row reads baseline under vs engine; the others read what they do to the engine's answer — a cover difference where there is one, otherwise a carry difference, cheaper in green. On today's run every row covers 100.0% and Left short is a dash or a rounding cent. The highlighted row follows the dropdown.

RULE-57 The verdict names the constraint that is actually binding

Do: Read the paragraph under the comparison table, and the list of obligations in it.

Verify: it reports what actually separates the models. On today's run that is carry: it says every model covers the same 100.0%, names the linear programme as the floor at $1.33mm a year, says the production engine carries $1.38mm so the greedy shortcut costs about $0.05mm a year on $1,756.9mm of cover, and credits re-ordering the queue and the cost-ranked sweep with part of that. Where a run leaves cover on the table instead, the same paragraph prices the gap in cover and says what re-ordering the queue alone recovers; where nothing separates the models at all, it says so and names the limit that is binding instead. It never prints a verdict the rows do not support.

RULE-58 The choice of model survives a reload, and the run still rules

Do: Pick Heuristic + local search. Reload the page and reopen Optimization Results. Then switch the run picker at the top of the tab to CSG agreements only and read the panel again.

Verify: the dropdown still reads Heuristic + local search after the reload, and its process card reports the swaps it found. After switching run, the line beside the dropdown names CSG agreements only, and every figure in all three columns is worked out again for that run. The models are not re-run until the panel asks for them.

EPIC 12

User maintenance — shared contract (eight datasets)

ℹ︎ About this epic — where to find it (click to expand)

To get here: click the User maintenance tab. A sub-tab strip selects one of eight datasets. They are 💰 Cost of funds, 🏭 G7 industry group and 🔖 G7 by bond. Then 🎯 Source of collateral, ⭐ Special agreements, 📈 Adjusting exposures, 📦 Adjusting inventory and 🏷 Tags & highlights.

US12.1 As a user, every dataset gives me the same download / upload / status / last-updated behaviour so all eight sub-tabs behave consistently and persist to the browser.

Common to all eight (every sub-tab has these controls)

⬇ Download on-screen — downloads a CSV of exactly what is on screen for that dataset. It carries every column shown, at its current value.
⬆ Upload — opens a file picker (CSV). The upload only captures the fields the user can edit for that dataset. System and auto columns are ignored, and re-derived. It never overwrites a read-only column.
Upload status — after an upload the strip reports the outcome. On success it shows a green “✔ Upload completed — …” with a count of what was applied. On failure it shows a red “✖ Upload error — …” with the reason. Examples are no data rows, or nothing matched.
Last updated — a stamp on the right reading “Last updated: <date>” (or “never”). It bumps on any change — an on-screen edit or an upload — not only uploads.
Persistence — every dataset is saved to browser localStorage and survives refresh. Timestamps live in collat-um-updated.
ℹ️ How this works — under each screen's heading sits one toggle reading “ℹ️ How this works”. It holds that screen's paragraph of explanation, and it is closed when the screen opens. One click or tap opens it, another closes it, and it starts closed again on the next visit — the state is not remembered. Every one of the eight screens has exactly one, and no screen shows its explanation until asked. The screen itself — the toolbar, the table, the controls — is what the user arrives to.
Exception — Cost of funds is stricter than the shared contract above. Its upload is all-or-nothing. The file must carry every row that is on screen. Every row in the file must be one the system knows. And all four fields must be filled in. Anything else is listed as a problem and nothing is applied. See §13.

🧪 Test cases for US12.1 4 scenarios

UM-01 All eight sub-tabs carry the same controls

Do: Open User maintenance. Visit each of the eight sub-tabs in turn.

Verify: every sub-tab shows ⬇ Download on-screen, ⬆ Upload, an upload-status strip and a “Last updated” stamp on the right.

UM-02 Download gives back what is on screen

Do: On any sub-tab, click ⬇ Download on-screen and open the CSV file.

Verify: the file carries every column shown on screen, with the current values, row for row.

UM-03 Upload status reports success or the reason for failure

Do: Upload the file you just downloaded. Then upload a file with a header row only and no data rows.

Verify: the first upload shows a green “✔ Upload completed” message with a count of what was applied. The second shows a red “✖ Upload error” message naming the reason.

UM-04 Last-updated bumps on any change, and edits survive refresh

Do: Note the “Last updated” stamp. Edit one value directly on screen. Read the stamp again, then refresh the page.

Verify: the stamp bumps on the on-screen edit, not only on uploads. After the refresh the edited value is still there.

EPIC 13

User maintenance — Cost of funds

ℹ︎ About this epic — where to find it & what it is (click to expand)

To get here: User maintenance → 💰 Cost of funds.

What it is

The cost of funds table — what it costs the bank to fund a bond, written as a rate. Every line carries two rates. The internal rate funds the position inside the bank. The external rate funds it in the market.
The system generates the rows. There is one row for every Security Type × every currency. The user never adds or deletes a row — the user fills in the two rates.
Security Type is the first column. Its values are the distinct G7 Industry group values the team maintains on the “G7 industry group” screen (§14). That screen is itself driven by the Bloomberg industry codes. They are its “BICS Level 2 Industry Group Name” column. So: whatever distinct groups have been entered on that screen are the Security Types that appear here. Nothing is typed into this column on this screen.
An Others row is always present, no matter what the mapping screen says. It is the catch-all. The optimisation process may meet a bond whose security type has no row. It then uses the Others row instead. The Others rows are shown in italic blue so a reader can pick them out.
Currency is the second column, and its values are the currency static list: AUD, CAD, CHF, USD, SGD. Nothing is typed into this column either.
All 4 fields are mandatory — Security Type, Currency, Rate (internal), Rate (external). The first two are supplied by the system; the user must supply both rates on every row. A rate that is blank, or is not a number, is outlined in amber. The line under the table counts how many rows are still short.
There are two ways to maintain it, and they do the same thing. Type straight into the grid. Or download the file, update it in Excel and upload it back.

What the terms mean (plain English)

Security Type — the kind of issuer the bond belongs to, in the bank's own grouping (for example Government, Financials, Transport). It is called “Security Type” on this file. The same value is called the “G7 Industry group” on the mapping screen that produces it.
Others — the fallback bucket for anything the mapping does not recognise. So no bond is ever left without a funding rate.
Rate (internal) / Rate (external) — the funding cost as a percentage rate. Internal = borrowed from inside the bank; external = borrowed in the market. Both are entered as plain numbers. A trailing per-cent sign is accepted and ignored. So 1.20 and 1.20% mean the same thing.

US13.1 As a user, I can see one row for every Security Type × currency, always including Others so I know which rates the system asks for, and no bond ends up without one.

🧪 Test cases for US13.1 3 scenarios

COF-01 The system generates the rows

Do: On the G7 industry group screen (§14) enter one group — for example Government — then open Cost of funds.

Verify: the table shows 10 rows. There are two Security Types: Government, and the always-present Others. Each is repeated once per currency — AUD, CAD, CHF, USD and SGD. The Security Type and Currency cells cannot be typed into. The line under the table reads “10 row(s) · 2 security type(s) × 5 currencies · …”.

COF-02 The Others row is always there

Do: Go to §14 and find the last row, the catch-all. Clear its G7 Industry group value, so the mapping names no group at all. Return to Cost of funds.

Verify: the table still shows the 5 Others rows, one per currency. The catch-all can never be removed from this table.

COF-03 Adding a Security Type adds its rows

Do: In §14 add a second distinct group — for example Transport.

Verify: Cost of funds now has 15 rows — 3 Security Types times 5 currencies. The rates already entered against the other Security Types are untouched.

US13.2 As a user, I can type the internal and external rate straight into the grid so I can correct one row without going near a spreadsheet.

🧪 Test cases for US13.2 2 scenarios

COF-04 Enter rates on screen & keep them

Do: On the Government / AUD row type 1.20 into Rate (internal) and 1.45 into Rate (external). Refresh the browser and come back to the screen.

Verify: both values are still there. The amber outline on that row has gone. “Last updated” shows today's date and time.

COF-05 A mandatory rate that is missing is flagged

Do: Clear the Rate (external) you just typed.

Verify: that cell is outlined in amber again. The count at the bottom moves: one fewer “complete”, one more “still missing a mandatory rate”. The wording changes to “· all 4 fields complete on every row” only when nothing is outstanding.

US13.3 As a user, I can download the table, update it in Excel and upload it back so I can fill in hundreds of rows at once instead of one at a time.

🧪 Test cases for US13.3 7 scenarios

COF-06 Download, edit, upload — the happy path

Do: Click ⬇ Download on-screen. Open the file in Excel. Fill in every Rate (internal) and Rate (external), and save it. Then click ⬆ Upload and pick it.

Verify: the file has 4 columns — Security Type, Currency, Rate (internal), Rate (external). It has exactly the rows that were on screen. After the upload the status strip reads “✔ Upload completed — N rate row(s) updated”. The grid shows the uploaded rates, and no cell is outlined. The count reads “all 4 fields complete on every row”. Downloading again and uploading that file back without changing it is always accepted.

COF-07 A row on screen that is missing from the file is an error

Do: Download the file, delete one whole row from it, save and upload it.

Verify: the upload is rejected. A red box lists “Your file is missing 1 row(s) that are on screen: <Security Type> / <Currency>. Every row on screen must be in the file.” The status strip reads “✖ Upload error — 1 problem(s) found”. None of the file's other rows were saved.

COF-08 A Security Type in the file that the system does not know is an error

Do: In the downloaded file, change one Security Type to a group that is not set up. Use Airlines, for example. Then upload it.

Verify: the upload is rejected. The box says “Line N: Security Type “Airlines” is not set up in the system. Add it as a G7 industry group on the “G7 industry group” screen first, then upload again.” It names where to go and fix it. (The row it replaced is also reported as missing, because the file no longer carries it.)

COF-09 A currency the system does not know is an error

Do: Change one Currency in the file to JPY and upload it.

Verify: the upload is rejected. The box reads “Line N: Currency “JPY” is not in the currency static list.” The list is AUD, CAD, CHF, USD and SGD.

COF-10 A blank or non-numeric rate is an error — all 4 fields are mandatory

Do: In the file, blank out one Rate (external), and type the word abc into another row's Rate (internal). Upload it.

Verify: the upload is rejected, with one line per problem. One reads “Line N (<Type> / <Ccy>): Rate (external) is blank — all 4 fields are mandatory.” The other reads “Line N: Rate (internal) is not a number.”

COF-11 Nothing is half-applied

Do: Take a file where most rows are good and one row is wrong. Note the rates showing on screen first. Then upload it.

Verify: the upload is rejected. Every value on screen is exactly as it was before. A file is accepted whole or not at all. So the user is never left with a half-updated table. Fix the file, upload again, and everything applies in one go. The red box clears on the successful upload.

COF-12 The same row twice in one file is an error

Do: Duplicate one line in the downloaded file. Keep the same Security Type and Currency, but give it a different pair of rates. Then upload it.

Verify: the upload is rejected. The red box names the repeat: “Line N: <Security Type> / <Currency> appears more than once in the file. Each Security Type and Currency may only appear once — remove the extra line and upload again.” Neither of the two rate pairs is saved. The system never quietly picks one of them. So a rate can never load that the user did not intend. Delete the extra line and upload again — it is accepted.

US13.4 As a user, I know which rate the optimisation process will use for any bond, including the awkward ones so a bond with an unrecognised security type or an unexpected currency never stops the run.

How a bond gets its cost of funds (the exception handling)

Take the bond's security type — its issuer's G7 industry group — and its currency. Read the rate off the row that matches both.
No matching security type. The bond's security type may have no row in this table. The Others row for that currency is then used instead. This is why the Others row always exists.
Currency not found. The bond's currency may not be one of the currencies in this table. The cost of funds is then 0.
Whether the internal or the external rate applies depends on how the bond is held. Held internally takes one; held outside takes the other. This screen does not decide it.
How to test this today ⚑. These two rules are built and can be exercised. But no screen calls them yet. The Rules engine still works its cost figure out from a built-in table. That is raised as OQ-39. Until that is decided, a tester checks COF-13 and COF-14 in the browser's developer console. The exact call is in the Developer build detail below. Once the optimiser is switched over, the same two cases become visible on the Rules-engine cost figures.

Where every figure on this screen comes from, and how to check it

Figure on screen	Where it comes from	How it is worked out	How to check it
Security Type cell	The G7 industry group mapping (§14) — data set 7.2 — plus the built-in Others catch-all.	List the different G7 Industry group values on that screen, keeping the order they were first seen in. Add Others if it is not already among them.	Open §14, read down its G7 Industry group column, and write out the different values you see. That list, plus Others, must be exactly the Security Types here.
Currency cell	The currency static list — data set 5.	Every Security Type is repeated once for each currency in the list, in the order AUD, CAD, CHF, USD, SGD.	Count the currencies on any one Security Type: there must be 5, and the same 5 against every Security Type.
Rate (internal) / Rate (external)	Typed in by the user, or loaded from the user's uploaded file — data set 7.1.	Shown exactly as entered; nothing is calculated, rounded or converted.	Download the file and compare it with the screen line by line. They must be identical, because the download is the screen.
Row count in the line under the table (“10 row(s)”)	The rows on screen.	Number of Security Types multiplied by number of currencies.	Count the rows in the table; and check the multiplication against the two counts quoted next to it.
“N complete”	The rows on screen.	Count of rows where both rates are filled in and both are numbers.	Count the rows with no amber outline — it must match.
“N still missing a mandatory rate”	The rows on screen.	Total rows minus the complete count. When it is zero the text is replaced by “all 4 fields complete on every row”.	Count the rows that carry an amber outline; complete + missing must always add back to the row count.
“N problem(s) found” on a rejected upload	The uploaded file, checked against the rows on screen.	Count the messages listed in the red box. There is one per bad line, plus one covering all the rows the file left out.	Count the bullet points in the red box — it must equal the number in the status strip.

When the table gets big (production volumes)

The table is as many rows as Security Types times currencies. So it grows with the mapping, not with the size of the bond book. A bank with 40 industry groups and 5 currencies sees 200 rows. It is shown in full, in a scrolling panel, and is not paged.
Because it is a whole-table replace, an upload must carry every row. The download is always the right starting point. It is generated from the screen, so it can never be missing a row.
The error box lists at most 50 problems, then says how many more there are. So a badly wrong file cannot flood the screen. The “missing rows” message names the first 8 and then counts the rest.
The system never quietly drops a row it does not like. A row it cannot use is always reported, never skipped.

Checklist — columns (all 4 are mandatory)

Security Type — generated by the system (read-only); the distinct G7 industry groups, always including Others
Currency — generated by the system (read-only); AUD / CAD / CHF / USD / SGD
Rate (internal) % — user-entered, must be a number
Rate (external) % — user-entered, must be a number

🛠 Developer build detail — exact names, keys and rules (business readers can skip this)

Saved data. Rates persist to browser storage under collat-cost-of-funds, shaped {rates:{"<Security Type>|<CCY>":{ri:"1.20",re:"1.45"}}}. Values are stored as the strings the user typed. The last-updated stamp lives in collat-um-updated under the key cof.
Security types. cofTypes() is g7Groups() with "Others" appended. g7Groups() gives the distinct non-blank G7 values from collat-g7-map, in first-seen order. "Others" is only appended when no case-insensitive match is already present. The grid is cofTypes() × CCYS where CCYS = ["AUD","CAD","CHF","USD","SGD"].
Rate validation. cofRate(v) trims, drops one trailing %, rejects empty, then requires isFinite(Number(s)). Blank and non-numeric are reported differently but both fail.
Upload contract. Header row required; columns in the order Security Type, Currency, Rate (internal), Rate (external). Security Type and Currency are matched case-insensitively (currency is upper-cased). Validation is all-or-nothing: the parse collects every problem, and if any exist nothing is written. There are seven problem classes. A blank key field. An unknown Security Type. An unknown Currency. The same Security Type and Currency twice. A blank rate. A non-numeric rate. And keys on screen that the file does not carry.
Lookup. UM.costOfFunds(securityType, currency) is the single implementation of the exception handling and returns {securityType, ccy, internal, external, fallback}. No case-insensitive match on securityType → "Others"; currency not in CCYS → both rates 0. Any consumer must call this rather than reading the store directly, so the rule exists once.
Re-render triggers. Editing the G7 mapping calls renderCof(), so adding or renaming a group reshapes this grid immediately.

🧪 Test cases for US13.4 2 scenarios

COF-13 Unrecognised security type falls back to Others

Do: Set up and price both Government and Others. Then ask for the cost of funds of a USD bond whose security type is Airlines.

Verify: the rates returned are the Others / USD rates, and the answer records that the Others row was used.

COF-14 Unknown currency gives zero

Do: Ask for the cost of funds of a Government bond in JPY (not in the currency static list).

Verify: both rates come back as 0, and the answer records that the currency was not found.

EPIC 14

User maintenance — G7 industry group

ℹ︎ About this epic — where to find it & what it is (click to expand)

To get here: User maintenance → 🏭 G7 industry group.

What it is

A mapping table. The first four columns are system-provided and read-only. They are Classification Level 4 name, BICS Level 2 Industry Group Name, Issuer Industry and Issuer Country. The user fills the fifth: G7 Industry group.
Six rows are seeded as sample system data, each already carrying a G7 group: Finance / XYZ_IND_GRP / GOVT NATIONAL / United States → Government, Government Owned, No Guarantee / Airlines / TRANS - NON RAIL / Singapore → Transport, Sovereign / Sovereigns / GOVT NATIONAL / Germany → Government, Supranational / Supranationals / PUBLIC SECTOR / Luxembourg → Supranational, Banking / Banks / BANKS / United Kingdom → Financials and Industrial / Aerospace & Defense / CORPORATE / United States → Credit – Non-financial. The last row is a catch-all, reading Others / Others / Others. It covers anything not mapped. Its G7 group defaults to Others, and is editable.
Drives the charts. The distinct G7 Industry Group values become the categories of the Overview “Bond collateral by G7 industry group” chart. That covers both the row-2 donut and the solo “By bond type” chart. Every bond in the system is mapped back to a row of this table. The match is on its Issuer Industry, ignoring upper and lower case. Only rows above the catch-all that have a G7 group filled in can be matched. A bond that matches no row takes the last row. That is the catch-all, where every column is the default: “Others / Others / Others”. So every bond is always grouped. And it is grouped by a value that exists in this table and nowhere else. The same rule fills the four classification fields on the instrument detail card (§8). The distinct groups are also the Security Types the Cost-of-funds table asks for a rate against (§13). Every distinct group entered here creates one Cost-of-funds row per currency. An Others row exists there whether or not it is named here. Persistence key collat-g7-map.

Where a bond’s Issuer Industry comes from. In the real system it is part of each bond’s static data. In this demo it is derived from the bond’s type, as follows. This is the value the match above is made on.

Bond type	Issuer Industry the bond carries
Singapore Government Securities (SGS), US Treasuries (UST)	GOVT NATIONAL
Supranational, Agency	PUBLIC SECTOR
Corporates	CORPORATE

One bond can be answered on its own. This table answers for a whole Issuer Industry at a time. Sometimes one bond needs a different answer from the rest of its industry. That is done on the next screen, 🔖 G7 by bond (Epic 14a). It records the exceptions to this table, one ISIN at a time. A bond with an exception uses it. Every other bond keeps following this table. So this table stays the default answer, everywhere.
Nothing is grouped outside this table. There is no separate built-in list of industry groups anywhere in the app. A bond carries the G7 group of the row it matched. Failing that, it carries the G7 group on the catch-all row. Suppose no row above the catch-all has a G7 group filled in. Then every bond is in the catch-all group, and the donut is a single slice. Its hint line says so.

US14.1 As a user, I can map issuers to G7 industry groups so the distinct groups drive the Overview bond-type / G7 chart and seed the cost-of-funds grid.

Checklist — columns

Classification Level 4 name — read-only (system)
BICS Level 2 Industry Group Name — read-only (system)
Issuer Industry — read-only (system)
Issuer Country — read-only (system)
G7 Industry group — user-populated (editable); last row is the Others catch-all

🧪 Test cases for US14.1 4 scenarios

G7-01 Fill G7 group & catch-all

Do: Enter a G7 group for the GOVT NATIONAL row (e.g. Credit - Financial); leave/edit the Others row.

Verify: the summary shows the classified count and the number of distinct G7 groups; values persist on refresh.

G7-02 Drives the bond-type chart

Do: Go to Overview → the “By bond type” chart (and the row-2 donut).

Verify: the chart's slices are your distinct G7 Industry Groups, not raw bond types. Clicking a slice filters the Bond postings table to that G7 group.

G7-03 Download / Upload (G7 column only)

Do: Download the CSV, change the G7 Industry group column, upload it back.

Verify: only the G7 column is applied, matched on the three system keys. The read-only columns are unchanged. The status strip shows the number of mappings updated.

G7-04 Every bond maps back to this table; unmatched bonds take the catch-all

Do: Set the GOVT NATIONAL row to Credit - Financial and leave the TRANS - NON RAIL row blank. Go to Overview and open the Bond collateral by G7 industry group donut. Then open one UST bond and one Corporates bond from a postings table.

Verify: the UST card reads Finance / XYZ_IND_GRP / GOVT NATIONAL / Credit - Financial. The Corporates card falls to the catch-all row. So its first two fields read Others / Others, and its G7 group reads Others. Its Issuer Industry still reads CORPORATE, because that is the bond’s own classification and not the row’s. The donut has exactly these two slices and no others. No group appears that is not a value in this table. Adding up the two slices equals the total bond collateral posted, because every bond lands in one of them.

EPIC 14a

User maintenance — G7 by bond

ℹ︎ About this epic — where to find it & what it is (click to expand)

To get here: User maintenance → 🔖 G7 by bond.

What it is

Every bond in the book, on one screen. One row per ISIN, taken from the bond / securities static file (data set 2). Each row shows the bond’s own static data beside the classification it carries.
Why it exists. The 🏭 G7 industry group screen (Epic 14) answers for a whole Issuer Industry at a time. Sometimes one bond needs a different answer from the rest of its industry. This screen is where the user gives it that answer.
It holds the exceptions, not the rule. The mapping table stays the default for every bond. This screen records only the bonds the user has set by hand. A bond that has not been touched follows the mapping table, and moves with it.

Where each column comes from. The four bond-static columns are read off the bond. Two of the classification columns are read off the mapping row the bond falls on. The last column is the answer in force.

Column	Read-only or editable	Where the value comes from
ISIN	read-only	the bond’s own static data
Bond Name	read-only	the bond’s own static data (its instrument name)
Issuer Name	read-only	the bond’s own static data
Issuer Country	read-only	the bond’s own static data
Classification Level 4 name	read-only	the mapping row this bond falls on
BICS Level 2 Industry Group Name	read-only	the mapping row this bond falls on
Issuer Industry	read-only	the bond’s own static data — it is what the mapping row is matched on
G7 industry group	editable	the value set on this bond, or the mapping row’s value where none is set

How a bond gets its G7 industry group. It is worked out in two steps. First the mapping table answers for the bond’s whole Issuer Industry. Then a value set on this screen replaces that answer, for that one bond. Clearing the value puts the bond back on step one.
What an exception does not change. It answers the G7 question for one bond. It does not reclassify the industry. So Classification Level 4 name and BICS Level 2 Industry Group Name still read the mapping row’s values.
Where the answer shows up. Wherever the app already shows a bond’s G7 industry group. That is the instrument pop-up on the Overview and in the Inventory Manager. It is also the Bond collateral by G7 industry group donut and the solo By bond type chart. A bond given its own group moves into that group’s slice.
It also feeds Cost of funds. The Security Types on the 💰 Cost of funds grid (Epic 13) are the distinct G7 industry groups in use. A group named only here still counts. So naming a new group on one bond adds that Security Type, with one row per currency.
Persistence key collat-g7-bond. Only bonds with a value set are stored. The Overview and the Inventory Manager read the same key.

US14a.1 As a user, I can see every bond beside the classification it carries so I can check what each ISIN is grouped as before I change anything.

Checklist — columns, left to right

A tick box — selects the row for a bulk edit (US14a.3)
ISIN — read-only
Bond Name — read-only
Issuer Name — read-only
Issuer Country — read-only
Classification Level 4 name — read-only
BICS Level 2 Industry Group Name — read-only
Issuer Industry — read-only
G7 industry group — editable, one text box per row

Checklist — what each row tells you under the G7 box

A bond following the mapping table reads “From the mapping table” in grey.
A bond set by hand reads “Set on this bond · inherits “<the mapping value>”” in the accent colour.
That second line carries a reset link. It clears the bond’s own value in one click.

Checklist — the summary line, bottom right

How many bonds are on screen, out of how many bonds there are.
How many of them are set on the bond rather than following the mapping table.
How many distinct G7 groups the bonds on screen carry.

🧪 Test cases for US14a.1 3 scenarios

G7B-01 Every bond is listed once, with its own static data

Do: Open User maintenance → 🔖 G7 by bond. Read the table without changing anything.

Verify: there is exactly one row per ISIN, sorted by ISIN. Each row shows that bond’s Bond Name, Issuer Name and Issuer Country. The summary says the same bond count as the row count. Every G7 box reads a value, and the line under it says where the value came from.

G7B-02 An untouched bond follows the mapping table

Do: On 🏭 G7 industry group, set the GOVT NATIONAL row to Government. Come back to 🔖 G7 by bond.

Verify: every bond whose Issuer Industry reads GOVT NATIONAL now reads Government, and still says “From the mapping table”. Their Classification Level 4 name and BICS Level 2 Industry Group Name now read that row’s values too. Bonds of any other Issuer Industry have not moved.

G7B-03 A bond that matches no mapping row falls to the catch-all

Do: Leave the TRANS - NON RAIL mapping row blank. Look at a bond whose Issuer Industry is CORPORATE.

Verify: its Classification Level 4 name and BICS Level 2 Industry Group Name read Others, and its G7 industry group reads the catch-all row’s value. Its Issuer Industry still reads CORPORATE, because that is the bond’s own classification.

US14a.2 As a user, I can search and filter the bond list so I can find the bonds I need to change without scrolling a whole book.

Checklist — the controls above the table

Search — one box, free text. It matches any part of any column on the table. Those columns are:
- ISIN
- Bond Name
- Issuer Name
- Issuer Country
- Classification Level 4 name
- BICS Level 2 Industry Group Name
- Issuer Industry
- G7 industry group
Upper and lower case are treated the same.
Issuer Industry — a dropdown. It offers “Issuer Industry — all”, then every Issuer Industry in the book.
Classification Level 4 name — a dropdown, built the same way.
BICS Level 2 Industry Group Name — a dropdown, built the same way.
G7 industry group — a dropdown, built the same way.
Clear filters — a button. It empties the search box and puts all four dropdowns back to “all”.

Checklist — how the controls behave

Every dropdown is built from the bonds themselves. It can never offer a value no bond carries.
A dropdown that is not on “all” is shown in the accent colour, so an active filter is visible.
The search box and the four dropdowns apply together. A bond must pass all of them to stay on screen.
At most 200 rows are drawn at once. Beyond that a note reads “Showing the first 200 of <n> matching bonds — narrow the search to see the rest.”
When nothing matches, the table shows one line reading “No bond matches this search.”

🧪 Test cases for US14a.2 3 scenarios

G7B-04 Search narrows the list

Do: Copy an ISIN off any row. Paste it into the search box. Then clear it and type an issuer name instead, in lower case.

Verify: the ISIN search leaves exactly one row. The summary reads 1 of <total> bond(s). The issuer search leaves every bond of that issuer, whatever the case you typed.

G7B-05 The four dropdowns stack with the search

Do: Pick an Issuer Industry in its dropdown. Then type a country name in the search box. Then click Clear filters.

Verify: after the dropdown only that Issuer Industry is listed, and the dropdown is shown in the accent colour. After the search only bonds of that industry AND that country remain. Clear filters brings the whole book back and empties the search box.

G7B-06 Nothing matches

Do: Type zzzz into the search box.

Verify: the table shows one line reading “No bond matches this search.” The summary reads 0 of <total> bond(s). No error is shown.

US14a.3 As a user, I can set the G7 industry group on one bond, or on many ISINs at once so a whole basket of bonds can be reclassified in one action.

Checklist — editing one bond

Type into that row’s G7 industry group box. The value is saved as you type.
The Last updated stamp bumps on the edit, as it does on every other sub-tab.
Leaving the box redraws the row, so its line now reads “Set on this bond”.
Clearing the box, or clicking reset, puts the bond back on the mapping table.
Typing exactly what the bond already inherits is not stored as an exception. The bond keeps following the mapping table.

Checklist — the bulk bar, above the table

A tick box on every row selects that bond.
A tick box in the header row selects, or clears, every bond currently on screen.
The bar reads “<n> bond(s) selected”, or “No bonds selected”. It counts only bonds the current search still shows.
The bar is highlighted in the accent colour whenever at least one bond is selected.
A text box takes the G7 industry group to apply. It suggests the groups already in use, and accepts a new one.
Apply to selected — sets that value on every selected bond, in one action.
Reset selected to mapping — clears the value on every selected bond, in one action.
Either button with nothing selected reports “Tick at least one bond first.” and changes nothing.
Apply to selected with an empty text box reports “Type the G7 industry group to apply.” and changes nothing.
On success the strip reports “<n> bond(s) set to “<value>””, or “<n> bond(s) back on the mapping table.”

🧪 Test cases for US14a.3 5 scenarios

G7B-07 Set one bond on its own

Do: Pick one bond. Type Sovereign-linked bank into its G7 industry group box. Click elsewhere. Refresh the page and come back to the sub-tab.

Verify: that row reads Sovereign-linked bank and its line reads “Set on this bond”, naming what it inherits. The Last updated stamp has bumped. No other row has moved. The value is still there after the refresh.

G7B-08 Set many ISINs in one action

Do: Filter Issuer Industry to CORPORATE. Tick the header tick box. Type Corporates in the bulk text box. Click Apply to selected.

Verify: the bar counted exactly the bonds on screen. Every one of them now reads Corporates and “Set on this bond”. The strip reports the same count. Clear the filter: no bond of any other Issuer Industry has changed.

G7B-09 Reset puts bonds back on the mapping table

Do: With those bonds still selected, click Reset selected to mapping. Then click reset on one other row’s line.

Verify: every reset row reads its mapping value again, and its line reads “From the mapping table”. The summary’s set on the bond count falls by the number you reset.

G7B-10 The two buttons refuse an empty selection

Do: With nothing ticked, click Apply to selected. Then tick one bond, empty the bulk text box and click it again.

Verify: the first click reports “Tick at least one bond first.” The second reports “Type the G7 industry group to apply.” Neither changes a single row.

G7B-11 A new group reaches Cost of funds, the pop-up and the donut

Do: Set one bond to a group name nothing else uses. Open 💰 Cost of funds. Then open that bond’s instrument pop-up, from the Overview or the Inventory Manager. Then look at the Bond collateral by G7 industry group donut.

Verify: Cost of funds now carries that Security Type, with one row per currency, all rates blank and counted as missing. The pop-up’s G7 Industry group reads the new name. Its Classification Level 4 name and BICS Level 2 Industry Group Name are unchanged. The donut has gained a slice for that bond, and the slices still add up to the same total.

US14a.4 As a user, I can download the list, edit it in Excel and upload it back so a large reclassification can be prepared offline.

Checklist — the file

The download carries eight columns, in screen order. They are:
- ISIN
- Bond Name
- Issuer Name
- Issuer Country
- Classification Level 4 name
- BICS Level 2 Industry Group Name
- Issuer Industry
- G7 Industry group
The file name is g7_by_bond.csv.
Download on-screen means what the search and filters have left on screen. Filter first to export a subset.

Checklist — the upload

Rows are matched on ISIN. Upper and lower case are treated the same.
Only the G7 Industry group column is applied. The seven read-only columns are ignored.
A blank G7 Industry group clears that bond’s own value. The bond goes back to the mapping table.
A partial file is allowed. Bonds not in the file are left exactly as they were.
An ISIN the securities static file does not hold is an error. Nothing at all is applied, and the strip names the first few offending ISINs.
On success the strip reports “✔ Upload completed — <n> bond(s) updated”.

🧪 Test cases for US14a.4 3 scenarios

G7B-12 Download gives back what is on screen

Do: Filter to one Issuer Industry. Click ⬇ Download on-screen and open the file.

Verify: the file holds exactly the rows that were on screen, and all eight columns, at their current values.

G7B-13 Upload applies only the G7 column

Do: In the downloaded file, change some G7 Industry group values and blank others. Also change an Issuer Name. Upload the file back.

Verify: the changed G7 values are applied and the blanked ones go back to the mapping table. The Issuer Name you changed is ignored, because it is read-only. The strip reports the number of bonds updated. Bonds not in the file have not moved.

G7B-14 An unknown ISIN stops the whole upload

Do: Add a row with a made-up ISIN to the file, alongside valid rows. Upload it.

Verify: a red error names the made-up ISIN and says it is not in the securities static file. Nothing at all is applied — even the valid rows in the same file are left alone.

EPIC 15

User maintenance — Source of collateral

ℹ︎ About this epic — where to find it & what it is (click to expand)

To get here: User maintenance → 🎯 Source of collateral.

What it is

A rules builder. Each rule assigns a Collateral Source value to portfolio data that matches its filter criteria. Each criterion picks a portfolio field, a match mode of Include or Exclude, and a value. Several values can be given, separated by commas. It is the same include/exclude idea as the table column filters.
The Field dropdown offers five portfolio fields. They are Product Lines, Book, Product Franchise, Attribute ID and Portfolio Description.
Drives the chart. Take the distinct Collateral Source values across all rules. Those become the categories of the Overview “Sources of collateral” chart. Persistence key collat-source-rules (stores {sources, rules}); the Overview reads sources to set the chart's source list.
Controls: a per-rule Collateral Source input, with + Add criterion and ✕ to remove one. Plus ✕ Remove rule, and a page-level + Add source rule. Summary shows rule count, distinct-source count and the source list.

US15.1 As a user, I can build source rules that assign a Collateral Source to matching portfolio data so the distinct sources drive the Overview “Sources of collateral” chart.

Checklist — per-criterion controls

Field — Product Lines / Book / Product Franchise / Attribute ID / Portfolio Description
Match — Include / Exclude
Value(s) — comma-separated
Collateral Source — user-entered (the value assigned)

🧪 Test cases for US15.1 3 scenarios

SRC-01 Build a rule

Do: Add a rule, set Collateral Source (e.g. Interbank Repo), add a criterion (Field = Product Lines, Match = Include, Value = Repo).

Verify: the summary lists your distinct sources; values persist on refresh.

SRC-02 Drives the “By source” chart

Do: Define two distinct Collateral Source values, then open Overview → “Sources of collateral” (and solo “By source”).

Verify: the chart's categories are your Collateral Source values (postings distribute across them).

SRC-03 Download / Upload rules

Do: Download the CSV (columns: Collateral Source, Field, Match, Value), edit it, upload it back.

Verify: the rules rebuild from the file (grouped by Collateral Source); status shows the rule / source count imported.

EPIC 16

User maintenance — Special agreements

ℹ︎ About this epic — where to find it & what it is (click to expand)

To get here: User maintenance → ⭐ Special agreements. This was the 🚫 Exclude CSA screen until 17 Sep 2026, and ⭐ Special CSA until 18 Sep 2026.

What it is

One user-maintained list of agreements, and one thing to set on each: its Tag. The user finds an agreement, adds it, and sets its tag. The tag alone decides what happens to that agreement — there is nothing else to tick, and no second field that could disagree with it.
Every kind of agreement belongs here, not only CSAs. The list offers every agreement name the app puts on screen, whatever type it is booked under — Bilateral CSA IM, Bilateral CSA VM, GMRA, GMSLA, CCP, Futures and Triparty. That was always true of the list; the screen was called “Special CSA” until 18 Sep 2026, which said otherwise, so the screen was renamed. The two tags keep their names, because they name CSA flavours — a user may tag any agreement, and what a tag MEANS is the user’s business.
Tag it Korean CSA and the agreement is dropped from the app. It disappears from the individual-agreement views, exactly as the old Exclude CSA list dropped it and as the “Exclude from the app” tick box then did. That behaviour did not change — what changed is that the tag now IS the instruction. There is no tick box any more, because ticking it was saying the same thing twice.
Tag it Zero-interest CSA and the agreement stays, and becomes filterable on the dashboards. The bond-postings panel’s Special agreement picker and the CSA VM sidebar’s Zero-interest only button both read it.
An agreement carries one tag at a time, or none. No tag means an ordinary agreement: nothing is dropped and nothing is filtered. Clearing a tag puts the agreement straight back.
A dropped agreement is never also a filter option. It is not in the book, so the dashboards never offer it as something to filter to — an option that could only ever come back empty.

What reads this list

The bond-postings blotter’s Special agreement filter. It narrows Postings, Postings by bonds and Bonds Maturing to the tagged agreements. Written up in US2.4.
The CSA VM sidebar’s “Zero-interest only” button. It shows the CSA VM agreements tagged Zero-interest CSA. That button is not new. What changed on 17 Sep 2026 is where it gets its answer. Zero-interest used to be generated, roughly one agreement in three. It is now whatever the user tagged here. Zero-interest is stated in one place only. It reads CSA VM agreements only, so tagging a GMRA or a futures book Zero-interest CSA is allowed and simply does not show up there — the bond-postings filter still finds it.
Every individual-agreement view, for the Korean CSA agreements. One of those is dropped from all of them.

Where the agreement names come from

The system provides them. Behind the scenes they arrive grouped by the screen each name appears on, because the app has two agreement naming schemes and both are headed “Agreement name” somewhere. That grouping is the system’s concern, not the user’s — it is not shown on screen and never something the user picks. It matters only in that every name the app puts on screen is offered, so a tag can always be set against the name the view it is meant for actually shows.
Bond postings — the names the blotter’s Agreement Name column shows, for example CSG_Amberlaine Bank_RIM or GSG_JPM_VM. These are what the Special agreement filter matches.
Individual agreements — the names the Detailed agreement list shows, for example BVM-001, plus Triparty’s counterparty names. These are what “Zero-interest only” and the exclusions match.
Each name arrives with two things that say which agreement it is: the agreement type it is booked under, and its counterparty. They are published because the codes alone do not say what an agreement is — nothing in CSG_Amberlaine Bank_RIM tells the user it is a Bilateral CSA IM with Amberlaine Bank. Where the app does not name a counterparty for an agreement, the counterparty shows as a dash; the generated individual-agreement codes are the case in point.
The Overview screen publishes both groups as it loads, under collat-agreement-names. Until the Overview has loaded once there are no names to offer. The finder and the list then both read “The agreement names come from the Overview screen. Open the Overview tab once, then come back.” Both fill themselves in the moment the names arrive, with no refresh.

The screen — one list: search, read, tag

There is ONE table on this screen, and the tag is set on it. No “add it here, then tag it down there”: setting a tag is the job, so the Tag drop-down sits on every row of the search results. An agreement is on the list precisely when it carries a tag — setting a tag puts it on, setting the tag back to — not tagged — takes it off, and there is no other way to be on it, so the list and the tags can never tell different stories.
Why a search and not a drop-down. A production book holds thousands of agreements, so the screen never lists them all in one control, and it never asks the user to recognise a code they cannot read. They search, look at what comes back, and tag the one they meant.
The bar is four controls, left to right: a search box with the placeholder “Search agreement name, type, counterparty…”; an Agreement type filter; a Tag filter; and Clear filters.
The search box matches as you type, case-insensitively, anywhere inside the agreement name, the agreement type, the counterparty or the tag. Typing Amberlaine Bank, GMRA or Korean all narrow the list.
Agreement type offers Agreement type — all, then every agreement type actually present among the names, alphabetically. It is not fixed in the software ahead of time — it is built live from what the Overview published, so a type that leaves the book leaves the filter with it.
Tag offers Tag — all, then Tagged — any, then Zero-interest CSA, then Korean CSA, then Not tagged. That is how the user sees just what they have marked, however large the book is.
A filter that is set is drawn in the accent colour. Clear filters empties the search box and both filters in one click.
The table is four columns: Agreement name, Agreement type, Counterparty and Tag. The first three are read-only; Tag is the one editable cell on the screen, and it names the effect beside each value: — not tagged —, Zero-interest CSA — filter on the dashboards, Korean CSA — dropped from the app.
Tagged rows are always drawn first, and are tinted and bolded. So the agreements the user has already marked are what they see the moment the screen opens, without filtering or scrolling for them.
At most 50 rows are drawn at once. Above that, the line under the table reads “Showing the first 50 of N matching agreements — tagged ones first. Narrow the search to see the rest.”. Below that it reads the count instead: “N of M agreement(s) on screen”. When nothing matches, the table reads “No agreement matches this search.”
The line on the right counts what is tagged, by effect: “3 tagged · 1 dropped from the app · 2 filterable on the dashboards”, or “Nothing tagged yet”. It counts the whole list, not the rows on screen.
On a narrow screen (up to 640px wide) each row becomes one block instead of a sideways-scrolling table: the agreement name, then its type and counterparty on one line beneath it, then the full-width Tag drop-down. The tag is always reachable without scrolling sideways, because it is the only thing this screen is for.

Saving, sharing and the file

The list is kept sorted by agreement name, and an agreement can appear once, because the tag lives on the agreement itself.
Saved to collat-csa-list as one agreement name and one tag per row, and shared with the Overview on the same origin. The Overview picks a change up live, and after a refresh. Anything already maintained arrives tagged Korean CSA if it was on the old collat-exclude-csa list, or had Exclude from the app ticked while that tick box existed — because that tag is now what excluding an agreement means.
The shared Download on-screen / Upload / status / last-updated strip sits at the top, as on every other sub-tab. The file is special_agreements.csv, two columns: Agreement name and Tag. An older file with a third Exclude column still uploads: a Yes in it means what the Korean CSA tag means now, so it is read as that tag. Download and upload carry the list, never the finder — the finder is a way of looking, not a dataset.
The screen’s own explanation sits behind the shared ℹ️ How this works toggle under the heading, closed on arrival, as on every other sub-tab (see US12.1).

US16.1 As a user, I can keep one agreement list and say, per agreement, which kind of special it is and whether to exclude it so the app filters on the special ones and drops the excluded ones.

Checklist — fields

Agreement name — system, read-only; the row is the agreement
Agreement type — system, read-only, beside the name so the user can read what they are tagging
Counterparty — system, read-only; a dash where the app names none
Tag — the one field the user sets, on the row itself: — not tagged —, Zero-interest CSA (filter on the dashboards) or Korean CSA (dropped from the app)

🧪 Test cases for US16.1 8 scenarios

SPCSA-01 Search, read the row, tag it — on one table

Do: Open the screen and look at it before touching anything. Then type Amberlaine Bank in the search box, read the row that comes back, and set its Tag to Korean CSA.

Verify: there is exactly one table on the screen, and every row of it carries a Tag drop-down — tagging is never somewhere else. The row reads CSG_Amberlaine Bank_RIM · Bilateral CSA IM · Amberlaine Bank, so the agreement type and the counterparty are on screen before the tag is set, and no screen is named or asked for. After tagging, the row is tinted and bolded, and the line on the right reads “1 tagged · 1 dropped from the app · 0 filterable on the dashboards”. Clear the search: the tagged row is now first in the table. An agreement appears once, so it cannot be tagged twice.

SPCSA-06 The list is not CSA-only

Do: Clear the search. Set Agreement type to GMRA. Read the count line, then tag one GMRA agreement. Set the filter to Futures, then to Triparty, and tag one of each.

Verify: the Agreement type filter offers every type present in the book — Bilateral CSA IM, Bilateral CSA VM, CCP, Futures, GMRA, GMSLA and Triparty — and nothing else. Each setting shows only that type’s agreements, and the right-hand count reads “N of M agreement(s)” with N the matches and M the whole catalog. All three sit among the tagged rows at the top beside the CSA one: an agreement of any type can be a special agreement, and each can be tagged either way.

SPCSA-07 Search, filter and clear work together

Do: Set Agreement type to Bilateral CSA VM and type BVM. Then set the Tag filter to Tagged — any. Then click Clear filters.

Verify: only the CSA VM agreements whose name contains BVM are listed, and a set filter is drawn in the accent colour. Tagged — any narrows to the agreements carrying a tag, which is how the user sees just what they have marked however big the book is; Not tagged is the other way round. Clear filters empties the search box and both filters in one click and the whole catalog is back, with the count reading “M of M agreement(s) on screen”. Searching something absent, for example zzz, reads “No agreement matches this search.” There is no Screen control anywhere on the screen.

SPCSA-08 The explanation is folded away on arrival

Do: Open the screen. Look under the Special agreements heading. Click ℹ️ How this works, then leave the sub-tab and come back.

Verify: on arrival there is no paragraph of explanation — only the toggle. Clicking it opens the same copy as before; clicking it again closes it. Coming back to the screen shows it closed again. Every one of the eight maintenance sub-tabs behaves the same way.

SPCSA-02 Zero-interest CSA makes it filterable on the blotter

Do: Set that row’s tag to Zero-interest CSA. Go to the Overview. Open the docked panel’s Postings view. Set the Special agreement drop-down to Zero-interest CSA.

Verify: every remaining row’s Agreement Name is CSG_Amberlaine Bank_RIM. The picker’s options are All agreements and Zero-interest CSA — no “Any special agreement”, because only one filtering tag is in use, and no Korean CSA, because that tag drops agreements rather than selecting them. The line under the panel title ends “, special agreements only — Zero-interest CSA”. Re-tagging the row replaces the first tag — a row never carries two.

SPCSA-03 Zero-interest is whatever is tagged here

Do: Search BVM-001 and set its tag to Zero-interest CSA, on the row. On the Overview, select CSA VM, drill to its individual agreements, and click Zero-interest only.

Verify: the list narrows to BVM-001 alone. Set the tag back to — not tagged — and the same button empties the list — nothing is zero-interest until somebody says so, and untagging is also what takes an agreement off the list.

SPCSA-04 Korean CSA drops the agreement, on its own

Do: Set the BVM-001 row’s tag to Korean CSA. Go to the Overview, select Bilateral CSA VM and open the Detailed agreement list.

Verify: the tag drop-down, on the agreement’s own row, offered Korean CSA — dropped from the app, and there was nothing else to tick and nowhere else to go. BVM-001 is gone from the list; BVM-002 is still there. Clearing the tag brings BVM-001 straight back. The count line reads “… · 1 dropped from the app · …”. On the bond-postings panel the Special agreement picker does not offer Korean CSA — that agreement is out of the book, so filtering to it could only come back empty.

SPCSA-05 Download / Upload the list

Do: Download the CSV. Add a valid agreement name with the tag Korean CSA, one unknown name, and one valid name with the tag Nonsense. Upload it back. Then upload an older file that still carries a third Exclude column with Yes against a valid name and no tag.

Verify: the file has the two columns Agreement name and Tag. The valid tagged row is added. The unknown name is skipped and counted. The unrecognised tag is left blank and counted. The status reads “✔ Upload completed — N added · M tagged · 1 unknown name(s) skipped · 1 unknown tag(s) left blank”. The older file’s Yes row comes in tagged Korean CSA, because that is what excluding an agreement means now.

EPIC 17

User maintenance — Adjusting exposures

ℹ︎ About this epic — where to find it & what it is (click to expand)

To get here: User maintenance → 📈 Adjusting exposures.

What it is

A file upload (plus on-screen add/edit) for exposure adjustments that add on to a specific agreement's exposure. All six fields are user-editable. They are Agreement name, a drop-down of system agreement names. Then Original Exposure — the agreement’s exposure before this adjustment, so the adjustment can be read against what it is adjusting. Then Adjusted Exposure in USD and Adjusted Exposure in Original Currency. Then Original Currency, one of AUD, CAD, CHF, USD or SGD. And last, Date.
The Date decides which exposure date the adjustment hits. The adjustment is then reflected everywhere that agreement's exposure is shown. Persistence key collat-exposure-adjust.
Controls: + Add adjustment (blank row), per-row ✕ remove, and the shared Download / Upload / status / last-updated strip.

US17.1 As a user, I can add or upload exposure adjustments per agreement & date so an agreement’s exposure is adjusted wherever it is shown.

Checklist — fields (all user-editable → all captured on upload)

Agreement name
Original Exposure
Adjusted Exposure in USD
Adjusted Exposure in Original Currency
Original Currency
Date

🧪 Test cases for US17.1 2 scenarios

EXP-01 Add an adjustment

Do: Click “+ Add adjustment”, pick an Agreement name, enter USD & original-currency amounts, currency and date.

Verify: the row is saved and persists on refresh; “Last updated” bumps.

EXP-02 Upload adjustments file

Do: Click “⬆ Upload” and choose a CSV with the five columns.

Verify: the rows are appended; status shows “✔ Upload completed — N row(s) added”, or an error if no populated rows.

EPIC 18

User maintenance — Adjusting inventory

ℹ︎ About this epic — where to find it & what it is (click to expand)

To get here: User maintenance → 📦 Adjusting inventory.

What it is

Lets the user add inventory rows using the same fields as the Inventory Manager “Bond Inventory” (Column display) table. The added inventory is reflected everywhere the app uses inventory data. It is appended into the Inventory Manager. Persistence key collat-inventory-adjust.
Controls: + Add inventory row, which adds a blank row, and a per-row ✕ to remove. Plus the shared Download / Upload / status / last-updated strip. Instrument Ccy defaults to USD.

US18.1 As a user, I can add or upload inventory rows using the Bond-Inventory fields so the added inventory is reflected everywhere the app uses inventory data.

Checklist — fields

The same fields as the Inventory Manager's Bond Inventory table. They are written up once, in US10.3 → “Column display fields”. One difference: Holding is not captured here. It is worked out by the app, not typed in. Everything else on that list is a field the user can fill in on this screen.

🧪 Test cases for US18.1 2 scenarios

INV-ADJ-01 Add inventory & see it in the Inventory Manager

Do: Add a row (Portfolio, Instrument Name, ISIN, Notional, etc.), then open the Inventory Manager from the Overview sidebar.

Verify: your added instrument appears in the Bond Inventory table; it persists on refresh.

INV-ADJ-02 Upload inventory file

Do: Click “⬇ Download on-screen”, add rows in the CSV, upload it back.

Verify: the rows are appended; status shows the count added.

EPIC 18a

User maintenance — Tags & highlights

ℹ︎ About this epic — where to find it & what it is (click to expand)

To get here: User maintenance → 🏷 Tags & highlights.

What it is

Lets the user put their own label and their own colour on anything in the book. A tag says: “this value, of this attribute, is mine, and it looks like this”. A bond the desk is watching, a portfolio being wound down, a desk under review — whatever the user needs to pick out of a long table at a glance.
Once a tag exists, every trade carrying that value is highlighted in that colour in the Inventory Manager, on both the Column display and the Time series of inventory views. The user does not tag rows one by one; they tag a value, and every row that carries it follows.
Nothing is filtered, hidden or removed by a tag. It is a colour on a row and nothing else — the totals, the counts and the sort order are exactly what they were before the tag existed.
Persistence key collat-tags. It is shared, so the screen where the tag is maintained and the screen where it is painted read the same list.

US18a.1 As a user, I can tag a value in the book and give it a colour so the rows I care about stand out wherever the book is listed, without filtering anything away.

Checklist — the four things a tag carries

Tag is for — which attribute of the book the tag keys on, chosen from a drop-down. The choices are Bond ISIN, Instrument name, Portfolio, Business line (desk), Holding, Issuer name, Issuer country, Instrument currency, Clearer, Sector of issuer and Industry classification. That list is the book’s own text attributes — a tag can never name a field a trade does not carry. A new row starts on Bond ISIN.
Value — the value it applies to, typed in. For a Bond ISIN tag that is an ISIN; for a Portfolio tag, a portfolio name.
Tag — what the user calls it, in their own words.
Colour — a colour swatch the user clicks to open their browser’s colour picker. It is never typed. A new row starts on amber.

Checklist — the rules a tag follows

A value matches exactly, ignoring upper and lower case. Typing bond123 matches a row whose value is BOND123, and does not match bond1234. Half a value matches nothing, so a row still being typed never flashes colour across the whole table.
A tag with no value yet matches nothing. Adding a blank row changes no screen until a value is filled in.
Where two tags would match one trade, the first one in the list wins. That is the order the user maintains them in, so moving a tag up or down decides which colour a row wears.
The colour reaches the Inventory Manager without a reload. Changing a tag on this screen repaints the rows on an Inventory Manager that is already open.
The Pivot table is not highlighted, and that is correct: its rows are roll-ups of many trades, not single trades, so there is no one row a tag could belong to.

Checklist — the controls

+ Add tag adds a blank row; a per-row ✕ removes one. Every change saves as it is made.
The shared Download on-screen / Upload / status / last-updated strip, exactly as the other six datasets carry it. The downloaded file is tags_and_highlights.csv and its four columns are the four above.
A count of how many tags are held sits under the table.

🧪 Test cases for US18a.1 3 scenarios

TAG-01 Tag a portfolio and see the rows carrying it turn colour

Do: Open User maintenance → 🏷 Tags & highlights and click + Add tag. Set Tag is for to Portfolio, type NY Govvies as the Value, name the tag watchlist, and pick a red from the colour swatch. Then open the Inventory Manager from the Overview sidebar.

Verify: on Column display, the two trades whose Portfolio reads NY Govvies are washed in that red and carry a solid red edge down their left-hand side. Every other row is untouched. The trade count under the table still says 10 of 10 trades shown — a tag colours rows, it never filters them. Switch to Time series of inventory: the same two trades are coloured there. Switch to Pivot table: nothing is coloured, because those rows are roll-ups of several trades.

TAG-02 Changing the tag repaints an open Inventory Manager

Do: With the Inventory Manager open, go back to the maintenance screen and change the Value from NY Govvies to London Repo Desk. Return to the Inventory Manager without reloading it.

Verify: the two NY Govvies rows are plain again and the three London Repo Desk rows now carry the colour. Changing the colour swatch instead repaints the same rows in the new colour.

TAG-03 An exact value, and a tag that matches nothing

Do: Add a second tag, Tag is for = Bond ISIN, and type only the first few characters of an ISIN. Then complete it to the whole ISIN.

Verify: the part-typed value colours nothing at all — no row is highlighted while it is incomplete. The moment the whole ISIN is there, that one bond’s row turns colour. Typing it in lower case highlights the same row, because case is ignored. A tag whose value matches nothing in the book simply colours nothing, and no error is shown.

EPIC 19

Data — upload production data & switch dummy ↔ production

ℹ︎ About this epic — where to find it & what it is (click to expand)

To get here: top tabs → Data (between “User maintenance” and “Requirements 1”).

What it is

The demo runs on built-in dummy (sample) data. This tab is for a person replicating the app inside their own company. They can upload their real data files. They then tell the app which column in their file matches each demo field. That is the “mapping”. They can then flip the whole app onto their real data with one switch. So they move back and forth between the demo and their live environment.
The tab is organised around the canonical 16-set data catalog. That is the same master list documented on Requirements 2, under “Data source catalog”. There is one card per data set, in catalog order. Each card shows the set’s number and name, its plain-English description and its status. It also carries a place to upload a file. Sets whose fields are defined also get a field-mapping table.
The uploads and mappings are saved in your browser. They stay put across reloads and future visits. This is not a one-time import. Nothing you upload leaves your browser.

What the terms mean (plain English)

Dummy data — the built-in demo numbers the app ships with.
Production data — your own real data, uploaded here.
Mapping — the link you draw between a demo field (e.g. “Currency”) and the matching column in your uploaded file (e.g. your file’s “CCY” column). The app uses the mapping to read your file as if it were the demo data.
Serving — which of the two sources a data set is actually feeding to the screens right now (Dummy or Production).
LIVE set — a data set already wired into the screens. Uploading and mapping it changes the app straight away. Sets not tagged LIVE accept an upload and a saved mapping now. Their live wiring is delivered as each set is connected.
Reserved (placeholder) set — a data set on the master list whose field structure has not been detailed yet. You can still store a file against it, but there is no mapping table until its fields are defined.

US19.1 As a user, I can switch the whole app between Dummy and Production data with one toggle so I can move seamlessly between the demo and my real company data without re-uploading anything.

🧪 Test cases for US19.1 3 scenarios

DATA-01 The master toggle switches the source

Do: Go to the Data source switch at the top of the Data tab. Pick Dummy data or Production data.

Verify: the note beside the switch updates. On Dummy it reads that every screen is exactly the demo. On Production it says how many sets are served from your uploads. The rest fall back to demo data. The Overview, Overview 2 and Inventory Manager screens refresh to the chosen source.

DATA-02 Dummy is unchanged from the demo

Do: Set the switch to Dummy data and open Overview, Overview 2 and Inventory Manager.

Verify: every figure and row is exactly the built-in demo. Switching to Dummy leaves the app as if this tab had never been used.

DATA-03 The choice sticks

Do: Choose Production data, then reload the page.

Verify: the switch is still on Production after the reload — the choice is remembered in this browser.

US19.2 As a user, I can upload a production file for a data set so the app can read my real records instead of the demo ones.

🧪 Test cases for US19.2 3 scenarios

DATA-04 Upload a file to a set

Do: On a set’s card, click Upload .csv / .json and pick a file. For a CSV the first row must be the column headers; for JSON, an array of row objects.

Verify: the card shows a green confirmation. It then shows the stored file’s name, its row count, and the date and time it was uploaded. The buttons change to Replace file and Remove.

DATA-05 Replace or remove a file

Do: Use Replace file to upload a different file, or Remove to delete the stored one.

Verify: Replace swaps in the new file’s name, count and date. Remove clears the file, and the card returns to serving demo data.

DATA-06 Uploads survive a reload

Do: Upload a file, then reload the page and return to the Data tab.

Verify: the file’s name, row count and upload date are still shown — the upload was not a one-time import.

US19.3 As a user, I can map each demo field to a column in my uploaded file so the app reads my columns as the fields it expects.

🧪 Test cases for US19.3 2 scenarios

DATA-07 Map a demo field to a column

Do: After uploading, use the Field mapping table. The left column lists the demo fields, each with a sample demo value. The right column is a dropdown of your file’s column headers, plus “— not mapped —”. Pick the matching column for each field. When you pick one, a sample value from your file is shown beside it so you can eyeball the match.

Verify: the mapping saves immediately (the dropdown is highlighted once set) and is remembered on reload.

DATA-08 Required fields must be mapped to go live

Do: Take a LIVE set — FX rates or Inventory data. Map only some fields. Leave a field marked *, meaning required, unmapped.

Verify: while any required field is unmapped, the card keeps serving Dummy. That holds even in Production mode. It says the required fields are not mapped yet. Once every required field is mapped, it serves Production.

US19.4 As a user, I can see which source each set is serving so I always know whether a screen is showing demo or my real data.

🧪 Test cases for US19.4 2 scenarios

DATA-09 Per-card serving indicator

Do: Read the Serving badge on each card while switching the master toggle.

Verify: it reads a green Serving: Production data only when four things hold. The master switch is on Production. The set is a LIVE set. It has an upload. And all its required fields are mapped. Otherwise it reads Serving: Dummy data, with a short reason (e.g. “no file uploaded yet”, “required fields not mapped yet”, or that the set’s live wiring is still being connected).

DATA-10 A live change flows through to the screens

Do: Upload a small FX rates file (set 8) with one currency at a made-up rate — e.g. EUR at 2.0 US dollars — map Currency and Rate, switch to Production, then open Overview or Inventory Manager.

Verify: any figure that converts euros to US dollars now uses your 2.0 rate. Currencies you did not supply keep their demo rate. Switch back to Dummy and the figures return to the demo rates.

US19.5 As a user, I can store a file against a reserved (placeholder) set so the slot is kept even before its fields are detailed.

🧪 Test cases for US19.5 1 scenario

DATA-11 Reserved sets have no mapping yet

Do: Open a reserved set’s card (e.g. Holiday calendars or Benchmark interest rates). Then open a set that is maintained elsewhere (e.g. Cost of funds, or Optimization rules).

Verify: on both, you can upload a file but no mapping table appears. On a reserved set the note in its place says the field structure is not yet defined, and that a mapping becomes available once the set is detailed — no demo fields are invented for it. On a set maintained elsewhere the note names the tab that maintains it instead, and says there is nothing here to map. Optimization outputs and Optimization exclusions & exceptions are not in either group any more: both were detailed on 9 Sep 2026 and show a full mapping table.

US19.6 As a user, I can download all my field mappings to a file and import them back later so I can restore every mapping in one step, instead of re-drawing them by hand.

Where every displayed figure on this tab comes from & how to check it

How to read this table. It has one row per thing the Data tab shows. The middle columns say where it comes from and how it is worked out. The last column says how to prove it is right.

Figure on screen	Where it comes from	How it is worked out	How to check it
Row count on a set’s card (“777 rows”)	The file you uploaded to that set.	The number of data rows read from your file. For a CSV that is the number of lines after the header row. For JSON it is the number of objects.	Open your file and count the data rows (all lines except the header). It must equal the number on the card.
Upload date & time	Your browser’s clock at the moment you uploaded.	Stamped when the upload succeeds; refreshed when you Replace the file.	It should match when you clicked Upload; re-upload and confirm it updates.
File name	The file you picked.	Shown exactly as your file was named.	Compare with the file on your computer.
Sample value beside a mapped column	Your uploaded file (its first data row).	The value in the first data row of the column you mapped.	Look at the first data row of that column in your file — it must match.
Serving: Dummy / Production badge	Worked out from the master switch, whether the set has an upload, and whether its required fields are mapped.	Reads Production only when four things hold at once. The switch is on Production. The set is LIVE. It has an upload. And every required field is mapped. Otherwise it reads Dummy, with the reason.	Flip the switch and add / remove the mapping — the badge must follow the rule above.
“N sets served from your uploads” note	The set of cards currently serving Production.	A count of the LIVE sets whose Serving badge reads Production.	Count the green “Serving: Production data” badges — it must equal N.

Checklist — the tab’s controls & states

Master Data source toggle: Dummy data · Production data
Note beside the toggle (demo vs “N sets served”)
Download mappings · Import mappings buttons (+ their confirmation / error note)
One card per data set, in catalog order (1–15, with the user-maintained set 7 shown as its eight datasets 7.1–7.8)
Per card: set number · name · description · status chip (Modeled / Partial / Placeholder)
Per card: LIVE tag on wired sets (FX rates, Inventory data)
Per card: Serving badge (Dummy / Production + reason)
Upload: Upload .csv / .json → then file name · row count · upload date · Replace file · Remove
Field mapping table (mappable sets): demo field + sample → your column dropdown + sample; * = required
Reserved sets: upload allowed, “field structure not yet defined” note instead of a mapping table

🔧 Developer build detail — storage, adapter & live wiring (expand only if you are building the app)

Where it lives: the tab is the #tab-data panel in j-collateraldemo.html; the controller is the DataTab module. The Overview / Overview 2 / Inventory Manager iframes are same-origin, so they share the browser storage below.
Storage — two tiers. The full uploaded rows, every column, are stored durably in IndexedDB. That is database collatData, object store sets, keyed by set id. They survive reloads. Alongside it, a synchronous read-model is written to localStorage, so the iframes read it without waiting. collat-data-mirror-<id> holds only the mapped columns, re-projected whenever the mapping changes. collat-data-meta-<id> holds the file name, row count, upload date, headers and a first-row sample. The iframes only ever read the mapped columns. Storing just those keeps a wide file well under the browser’s localStorage quota. The mirror is skipped only if even the mapped columns overflow the quota. The card then flags it “too large for live serving — stored durably”. The durable IndexedDB copy is always kept. Reducing the number of mapped fields lets it serve live again.
Mode & mapping. collat-data-mode is the raw string "dummy" or "production". collat-data-map-<id> is a small object of { demoFieldKey: yourColumnHeader }.
Download / Import mappings. Download mappings serialises every set’s collat-data-map-<id>, plus the current mode, to collateral-data-mappings.json. Its shape is { app, version, exportedAt, mode, sets:[{id,name,map,file}] }. Import mappings reads such a file and writes each collat-data-map-<id> back. It restores the mode. It re-projects the mirror for any set whose rows are already in IndexedDB. Then it reloads the iframes. The data files themselves are not in this export — the user re-uploads those; only the mappings are restored.
Data-access adapter (in each iframe): a CollatData helper reads collat-data-mode + the stored upload/mapping. In Dummy mode every getter returns the built-in demo data unchanged, byte-for-byte. In Production mode a set with an upload and a usable mapping is served from the uploaded rows. Its columns are translated to the demo field names. Only the source rows swap. Every worked-out figure keeps computing exactly as before, on top of whichever source is active. That covers Used, Unallocated, the margin call and the chart aggregations.
“Usable mapping” means one thing. Every field marked required (*) for that set maps to a header the uploaded file actually has.
Two sets are LIVE today. The first is set 8 · Market data — FX rates. It feeds both the Overview and the Inventory Manager. Your rates replace the demo FX table, {USD:1,EUR:1.08,GBP:1.27,SGD:0.74,JPY:0.0064}. They are merged over the demo defaults, so unsupplied currencies keep their demo rate. The second is set 15 · Inventory data. It is the shared bond-inventory book behind both the Inventory Manager and the Rules engine, via collat-inventory.js. Unmapped fields fall back to sensible defaults, so every uploaded row still renders. An uploaded Holding column of Internal, External-held or Received is honoured. The other mappable sets are 1, 2, 5, 6, 10 and 14. They accept an upload and a saved mapping now. Each is wired as it is connected.
Applying a change. Two actions reload the three app iframes, so they re-read the active source. Switching the master toggle. And changing a LIVE set’s upload or mapping while in Production mode.
Reserved sets get no mapping table. They are 3 Holiday calendars and 4 Portfolios static. Then the eight user-maintained datasets 7.1 to 7.8, which live on the User maintenance tab. Then 9 Benchmark interest rates. And last 11 Optimization rules, 12 Optimization outputs, and 13 Optimization exclusions & exceptions.

🧪 Test cases for US19.6 2 scenarios

DATA-12 Download every mapping to a file

Do: Map one or more sets, then at the top of the tab click Download mappings.

Verify: a file named collateral-data-mappings.json is downloaded, and the note by the buttons confirms how many sets were saved. The file holds, for every set you have touched, the demo-field → your-column mapping plus the current Dummy/Production choice. (If you have not mapped or uploaded anything yet, it tells you there is nothing to download.)

DATA-13 Import mappings to restore them

Do: Start on a fresh browser, or after the app was overwritten and the mappings cleared. Re-upload your data files. Then click Import mappings and pick a previously downloaded collateral-data-mappings.json.

Verify: every mapping in the file is restored on the matching set. Its dropdowns are re-filled and highlighted. The Dummy/Production choice is restored too. The note confirms how many sets were restored. Any set whose data file is already loaded serves your data immediately. A set whose file is not loaded keeps the restored mapping. It serves as soon as you upload a matching file. Importing a file that is not a mappings export shows a short error and changes nothing.

REF · A

Data model & conventions (build reference)

For developers: reference values the app is built on. All data is deterministic demo data, generated in the browser. It uses a random-number generator started from a fixed “seed”. So every load produces exactly the same sample numbers. There is no backend and no live feed. Exact numbers are reproducible but illustrative.

FX rates (USD per 1 unit of currency)

Ccy	USD	EUR	GBP	SGD	JPY
Rate	1.00	1.08	1.27	0.74	0.0064

Agreement types

Code	Full name	Base ccy	Sub-books
BVM	ISDA / CSA — Variation Margin	USD	—
BIM	ISDA / CSA — Initial Margin	USD	—
GMRA	GMRA — Repurchase	USD	VM only
GMSLA	GMSLA — Securities Lending	EUR	VM only
CCP	CCP — Cleared	USD	IM / VM
Futures	Futures / Cleared Derivatives	USD	—
Triparty	Triparty Collateral	SGD	Custodians (Euroclear / Clearstream / BNY)

Bond types (collateral)

SGS
UST
Supra
Agency
Corporates

Holdings sectors

Sovereign (SOVGN)
Public Sector (PBSEC)
Corporate (CORPO)
Credit Institution (CRDN)
Other Financial (OTFIN)

Inventory industry categories (Inventory Manager summary)

Sovereign → “Govies”
Supranational → “Supra”
Agency
Financial Institutions → “Financials”
Corporates

Rating scale (best → worst)

AAA · AA+ · AA · AA- · A+ · A · A- · BBB+ · BBB · BBB- · BB+ · BB

Key formulas & defaults

Total exposure = obligation + threshold · Coverage = posted ÷ exposure · Net excess = posted − exposure · Unallocated = total posting − total allocated. Received (in) is shown for information only — it never feeds Unallocated or any other worked-out figure.
Concentration limit default = 20% per issuer. Breach when any asset-type or issuer share > the limit.
Inventory summary and category totals are FX-converted to USD before aggregating.
Agreement popup MtM ≈ 75–95% of exposure; the remainder is Independent Amount (IA). Trades tab / Trade-contributions net MtM ties exactly to that MtM.
Persistence — browser localStorage keys: collat-theme-ds2 (light/dark); aoe-cols:<view> per-table column layout (e.g. tblBonds:summary, tblBonds:postings, tblDrill:trades, tblDrill:postings, tblInv:columns, tblInv:series); collat-inv-pivot, the Inventory Manager pivot view's chosen groupings and amount ({group,row,value}, defaulting to clearer × issuerCtry, notional). Then aoe-re-rules, aoe-re-runs and aoe-re-active for the Rules-engine tab's rules, runs and active run. Then the User-maintenance datasets. collat-cost-of-funds. collat-g7-map, which drives the bond-type and G7 chart. collat-source-rules, which drives the sources chart. collat-csa-list, the Special agreements list — one row per agreement, holding its tag and its exclude flag. Alongside it collat-agreement-names holds the agreement catalog the Overview publishes for it, grouped by screen — each name with the agreement type it is booked under and its counterparty, which is what the finder searches and shows. collat-exposure-adjust. And collat-inventory-adjust. And last collat-um-updated, holding the last-updated stamps.

REF · B

Glossary & data sources

For testers and developers. This lists every finance term and abbreviation used in the app. Each gets a plain definition. Where the term is a number, it also says where that number comes from. All values are deterministic in-browser demo data. They are invented sample numbers that come out identical on every load, with no live feed. The “production source” notes say where the real data would come from.

Exposure & valuation

MtM (Mark-to-Market) — the current market value of the trades/positions. Source: valuation engine / pricing feed (here demo-derived, ≈75–95% of exposure).
IA (Independent Amount) — an extra margin buffer held on top of MtM. It is independent of daily price moves, such as an initial-margin add-on. Total exposure = MtM + IA.
Total Exposure / Obligation — the amount that must be collateralised; the “Call / obligation”. = MtM + IA (allowing for threshold).
Threshold — an unsecured amount each party allows before any collateral is due; only exposure above it is called.
ITM Exposure (in-the-money) — the part of exposure in your favour (you are owed) — shown green.
OTM Exposure (out-of-the-money) — the part against you (you owe) — shown red.
Net Alternative — the same exposure recomputed under an alternative netting/valuation basis, shown for comparison.
Coverage ratio — posted ÷ exposure. Net excess — posted − exposure. Unallocated — total posting − total allocated. Received (in) is shown for information only — it never feeds Unallocated or any other worked-out figure.
Margin call / unallocated — exposure − posted. Positive = deliver collateral (call); negative = recall (unallocated).
Utilisation / Posted — total collateral posted = bonds + cash. Received — collateral posted to you (inbound).

Margin-call workflow (Daily Exposure Report)

STD Amount (AI) — the standard/agreed-internal call amount your system calculates.
Cpty Amount — the counterparty's own calculated call amount.
Agreed Amount — the amount both sides agree; shows “Disputed” when STD and Cpty differ beyond tolerance.
Dispute Value / Dispute Age — the gap between the STD and Cpty amounts. And how many days the dispute has been open.
Call Status — Pending Review · Margin Request Confirmed · No Call Required.
Action — Call (collect collateral) vs Delivery (post collateral out).
LRP — the margin-run / reporting period, i.e. how often exposure is recalculated and calls raised (e.g. Daily).
MTA (Minimum Transfer Amount) — calls below this are not exchanged, to avoid tiny transfers.
Rounding (delivery / return) — call amounts are rounded to a unit; delivery and return can round differently.
Base CCY vs Reporting CCY — base = the agreement's own currency; reporting = USD. “Base …” columns are in the base currency.
Statement Status — whether the margin statement is Approved / Pending. Source: daily margin engine + counterparty statements.

Agreement & legal

BVM / BIM / GMRA / GMSLA / CCP / Futures / Triparty — the agreement types. Full names and base currency are in appendix A.
Sub-books IM / VM — Initial Margin vs Variation Margin sub-ledgers within one agreement.
Custodian — where triparty collateral is held (Euroclear / Clearstream / BNY Mellon).
Reciprocity / Bilateral — both parties post to each other (bilateral) vs one-way.
Rehypothecation — whether received collateral may be re-used/re-pledged.
Netting set / Governing law — legal/ops attributes of the CSA/agreement.

Collateral & instrument

Notional — face amount of a bond. MTM of notional — market value = notional × price.
Haircut — a percentage discount applied to a bond's value, as a risk buffer. Collateral value = market value × (1 − haircut).
Seniority — rank in the issuer's capital structure (Senior Secured > Senior Unsecured > Subordinated…); affects rating/haircut.
Callable vs Bullet — callable can be redeemed early by the issuer; bullet repays only at maturity.
Coupon — the bond's interest rate. Clearer — the settlement/clearing venue (Euroclear, DTC, Fedwire, CCP…).
Issuer rating vs Bond rating — creditworthiness; the bond's rating can differ from the issuer's by seniority notching.
ISIN — 12-character international security identifier. Bond types (SGS/UST/Supra/Agency/Corporates) & sectors (SOVGN…): see appendix A.
Eligibility schedule — the counterparty's rules for acceptable collateral. They cover asset class and type, issuer, rating floor, maturity limit, seniority and exclusions. It is shown as one block per eligible collateral type.
Concentration limit / breach / basis. The limit is the most collateral allowed from one issuer or asset type, 20% by default. A breach means it is over the limit. The basis is the pool the percentage is measured against. Source: deterministic demo bond book.

Settlement

T / T+N — trade/today, and the settlement horizon in business days (T+0 same day, T+1 next business day). A general finance term; the app no longer draws a T+N ladder — see §4.
Settlement delay / Settlement (T+) — the number of business days a trade takes to settle.
T+N ladder — RETIRED 01 Oct 2026. It showed collateral available to settle at each horizon per triparty agent and country. The button in its place is now Triparty AOE (§4).

Optimisation (Rules engine)

Scoping / Ranking / Limits — the user-set rule categories: scope the pool (restrict which rows enter), rank cheapest-to-deliver, cap concentrations. Eligibility is not a user category. The optimiser enforces each agreement's own eligibility schedule automatically. The user never sets it.
Cheapest-to-deliver — choose the lowest-cost eligible collateral to post against a call.
Concentration cap — max share per line/call. Substitution buffer — spare capacity kept so posted collateral can be swapped later. Partial fill — allow a call to be covered partially.

Data & mapping

Classification Level 4 name · BICS Level 2 Industry Group Name · Issuer Industry — issuer-classification fields from Bloomberg. BICS is the Bloomberg Industry Classification System.
G7 Industry group — your own coarse industry bucket, manually mapped from the Bloomberg fields (see §14).
Reference date / Snapshot as-at — the date the snapshot views are anchored on. Those are the tables, pies and inventory. Time-series charts run up to it.

REF · C

Table controls (sort · filter · columns) — shared by every table

Applies to the Overview docked tables — Summary/Detailed, Postings and Margin Calls. Also the exposure drill, in both modes, and the Inventory Manager table. They all share the same behaviour, so it is documented once here.

Sort, footer & empty state

Click a column header to sort by it; click again to reverse. The active column shows ▲ (ascending) or ▼ (descending).
Numeric columns show a totals footer; a footer line shows “N of M … shown”.
When filters exclude everything, the body shows “No rows match the filters.”.

Checklist — column config (⚙ button)

Title “Columns — drag to reorder”
Display all
Hide all
Per-column show/hide checkbox
Drag ⠇ to reorder
📌 pin-to-left (sticky, accent divider on last pinned)

Checklist — filter (⏷) operators · number

≥ at least
≤ at most
= equals
is one of

Checklist — filter operators · text

contains
does not contain
begins with
does not begin with
ends with
does not end with
equals
is one of

Checklist — filter operators · date

on or after
on or before
on
between (range)
is one of

Checklist — filter popover controls

Operator dropdown
Value input
Between range (two inputs)
“is one of” checkbox list
select all / clear links
Apply
Clear

TBL-01 Sort, filter & configure any table

Do: On any table, click a column header to sort. Open ⏷ and apply a filter using the operators above. Open ⚙ and hide, reorder and pin a column. Then refresh the page. (These controls are not labelled on screen — the table header carries the ▲▼ / ⏷ / ⚙ affordances themselves.)

Verify: sorting, filtering and column show/hide/reorder/pin all work, and the column layout persists after refresh.

REF · D

Tooltips, hovers & dynamic text

Build detail: every hover tooltip (the exact title= text), hover-cursor behaviour, chart tooltip, and status text that changes at runtime. Reproduce these strings verbatim.

Overview — button / control tooltips (hover to show)

Theme toggle → “Toggle light / dark mode”.
Reference date box → “Snapshot tables, sources, bond-type and maturing-bonds are as at this date; time-series run up to it.”
“✕ Clear all selections” → “Reset agreements, custodian, chart cross-filters, reference date and table filters”.
Column-config cog (⚙) → “Show / hide & arrange columns”.
Dock drag handle → “Drag to resize”. ⤢ → “Maximize / restore”. ▾ → “Collapse / expand panel”. ✕ → “Close”.
“▶ Optimize posting” (agreement popup) → “Open the AOE Rules Engine to source the cheapest eligible collateral for this call”.

Overview — data-cell / link tooltips (hover to show)

Sidebar count badge (n) → “N agreement(s) with margin calls in the last 14 days”.
Triparty's extra amber dot → “Separate dashboard”.
“Call / obligation” and “Total exposure” cells read “Click to see contributing trades”. Their footer totals read “Click to see all trades”.
Posting cells read “Click to view bond postings”, “Click to view cash postings” or “Click to view postings”. Their footer totals read “Click to view all postings”.
Agreement-type name link → “Drill into individual agreements”. Individual agreement name → “Click to select this agreement · Ctrl+click to add another”. The ↗ arrow beside an individual agreement name → “Open agreement details”.
Column-config “pin” button → “Pin to left”. Cross-filter chip “×” → “remove”.

Overview — hover-cursor & underline affordances

Anything clickable shows a pointer cursor on hover. That covers table cells with drill or post links, chart bars and doughnut slices, and agreement or ISIN links. It also covers table headers, and the filter (⏷) and cog (⚙) buttons.
Clickable text values use a dotted underline (ISIN, security name, agreement name); card links use a dashed underline.
Table rows highlight (background change) on hover.

Charts — hover tooltips (all charts)

Hovering a bar, line or slice shows a tooltip with the series label and value. The doughnut is “Bond collateral by G7 industry group”. Its tooltip reads “label: $value (pct%)”. The doughnut/pie legend on the right shows each slice's value + %.
Cursor becomes a pointer only over clickable elements; clicking a bar/slice cross-filters or drills (see §2).

Overview — dynamic status text

Sidebar selection note changes with the selection: “Showing all agreements except Triparty (shown separately).” · “Showing the Triparty dashboard (its own world — excluded from cross-category totals).” · “Showing N of M cross-category agreements.”
Reference-date badge shows “● latest” (green) when it's today, else “historical” (amber).
The dock title and hint change per view — Bond postings, Margin Calls, Triparty AOE and so on. The postings hint states the as-at date, and any maturing-days filter.

Inventory Manager — tooltips & dynamic text

Theme toggle → “Toggle light / dark mode”. Snapshot date input → “Show the inventory as it stood on this date”. “Today” → “Reset to today”. Column cog → “Show / hide, reorder & pin columns”. Pin button → “Pin to left”.
ISIN / instrument-name links are dotted-underline and pointer-cursor (→ instrument modal).
Footer text updates to “N of M trades shown” as filters change.

Demo shell & Rules engine — tooltips

Theme toggle → “Toggle light / dark mode”. Overview iframe title “Collateral management overview”; Inventory iframe title “Inventory Manager”.
Rules engine, list mode. The priority arrows read “Higher priority” and “Lower priority”, or “Move up” and “Move down”. The enable toggle reads “Enable / disable”. Edit reads “Edit rule”, and delete reads “Delete rule”. The Visual and Overview modes carry the same toggle on each rule. Its tooltip reads “Enable rule” when off, and “Disable rule” when on.
Input categories read “Click to view {category}” and “Add a rule for {category}”. The output pill reads “Click to view results”. Rule chips carry the rule's Note as a hover tooltip.

This page is the single source of truth & test pack for what the app does. It must be updated whenever any feature, field or filter changes.

REF · E

Field → data model lineage — every displayed field mapped to its exact data set & field

What this is. A complete, screen-by-screen list of every field the application shows. Each is traced back to the exact data it comes from. That means the numbered data set, from the 15-set Data source catalog. Where relevant it also names the entity and field in the Data model & data dictionary. This is the field-level companion to the widget-level “Widget → data & logic lineage” on Requirements 2.

How the links work. Each coloured data-set or entity name is a link. Click it to jump to that set in the catalog, or that entity in the data dictionary. It opens the Requirements 2 tab and scrolls to the definition. How to read the “Comes from” column. A value is one of three things. Referenced means looked up from one of the 15 sets, and it always matches that set. Held on the record itself means the screen’s own stored data. Worked out means calculated from other fields. Those plain-English formulas live in the dictionary’s derived figures. Everything on these screens is deterministic in-browser demo data. It is the same on every load, with no live feed. The mappings say where the real data would come from.

Standing rule (data lineage): every field must trace to a set in the 15-set catalog. Some fields below do not yet trace to a catalogued set. They are gathered in §E.14 · Off-catalogue & to-confirm, and flagged with a ⚑. They are raised, not invented. A source must be agreed and added to the catalog before the field is built for real.

§E.1 · Overview — “Agreement summary” table (Summary / Detailed)

The docked per-agreement table (§2, Epic 2). One row per agreement type (Summary) or per individual agreement (Detailed). Every money figure is worked out from the daily book record (data models 10 & 14) at the reference date. The two levels show different columns. Three groups appear only at the Detailed level, and never on the type-level Summary. They are the exposure split (ITM / OTM). The dispute pair (Value / Age). And the base-currency set (Base CCY / Total Exp. / Call Amt).

Field (column)	Data set	Entity · field	Comes from (plain English)
Agreement	Agreements static · 6 (Triparty also Counterparty static · 1)	data model 6 · name, colour	Referenced — the type’s name and colour dot. At Detailed level it is the individual agreement’s account code, from data model 6. Under Triparty there are no agreement codes. There it is the counterparty’s name — the counterparty whose collateral that agent holds.
Total exposure	Exposures & margin calls · 10 + Agreements static · 6	derived figures (Exposure)	Worked out — what’s owed that day plus the type’s threshold cushion.
Call / obligation	Exposures & margin calls · 10	data models 10 & 14 · obligation	Referenced — the day’s obligation (what needs covering).
Received (in)	Collateral used data · 14	data models 10 & 14 · received	Referenced — inbound collateral received that day. Information only: it is displayed and totalled, and it never feeds Unallocated, the margin call, or any other worked-out figure.
Margin call	Exposures & margin calls · 10	Exposures & margin calls · 10	Read straight from the margin-call record for that agreement and date — not worked out from anything on the screen. Positive means collateral must be delivered; negative means there is more posted than owed and it can be collected back. To check it, read the same figure back from the margin-call data. The Margin Calls view shows it. Do not recompute it from the other columns.
Total posting	Collateral used data · 14	data models 10 & 14 · total posting	Referenced — the collateral posted that day (bonds + cash).
Bonds (Posted)	Collateral used data · 14	data models 10 & 14 · bonds posted	Referenced — the bond part of the posting.
Cash (Posted)	Collateral used data · 14	data models 10 & 14 · cash posted	Referenced — the cash part of the posting.
Total allocated	Worked out	derived figures (Allocated)	Worked out — the smaller of Total posting and Total exposure.
Bonds (Allocated)	Worked out	derived figures	Worked out — Total allocated split into bonds in the same proportion as the posting.
Cash (Allocated)	Worked out	derived figures	Worked out — the cash part of Total allocated.
Unallocated	Worked out	derived figures (Unallocated)	Worked out — Total posting minus Total allocated. To check it: read that row’s Total posting and Total allocated and subtract; it must equal this cell.
Surplus	Worked out	derived figures (Surplus)	Worked out — Total allocated minus Margin call. To check it: read that row’s Total allocated and Margin call and subtract; it must equal this cell. Watch the sign: where Margin call is negative, subtracting it adds to the surplus.
DoD / WoW / MoM (total allocated)	Worked out	derived figures	Worked out — the change in Total allocated versus the same figure 1 / 7 / 30 days earlier.
Threshold	Agreements static · 6	data model 6 · threshold cushion	Referenced — the type’s threshold cushion.
Expected post / Expected collect	Worked out	derived figures	Worked out — the deliver amount when short (post) or the recall amount when in unallocated (collect).
ITM / OTM Exposure (Detailed level only)	Exposures & margin calls · 10 ⚑	derived figures	Worked out — the in-your-favour / against-you split of exposure. Shown only at the individual-agreement (Detailed) level. ⚑ The split is a modelled proportion, not a real mark-to-market feed (see §E.14).
Dispute Value, Dispute Age (Detailed level only)	Exposures & margin calls · 10	derived figures	Referenced/worked out — the size and age of any dispute between your figure and the counterparty’s. Shown only at the Detailed level; modelled close to the call amount in the demo (see §E.14).
Base CCY, Base Total Exp., Base Call Amt (Detailed level only)	Agreements static · 6 + Market data FX · 8	derived figures	Referenced/worked out — the agreement’s own reporting currency, and the exposure / call amount converted into it using the FX rate. Shown only at the Detailed level.

Individual-agreement rows take each type figure and scale it down. The scale is that agreement’s share of the type, from data model 6. Rows can also be dropped by the user’s Exclude-CSA list (Exclude CSA · 7.4), and by the zero-interest filter.

Figure check sheet — every figure on the Agreement summary, with the live numbers

This sheet is generated from the running application, not typed by hand. The numbers below are read straight off the Agreement summary table at /j-collateral (Summary by agreement type, as at 2026-06-18). Every worked-out figure is then re-calculated from the other figures on the same row. It is then compared with what the screen shows. So the rules written here and the figures the application produces cannot disagree. If they ever did, this sheet would flag the row in red and the build would fail its checks. Open the screen beside this page and follow the "How to check it" column. Every figure can be confirmed with a subtraction you can do in your head.

Figure	What it means / how it is worked out	How to check it	Worked example — live figures
Call / obligation	What the agreement's trades owe on the reference date, before any collateral is taken into account.	It is the starting figure on the row — everything else on the row is built from it. Click the cell to list the trades that make it up; their amounts add up to this figure.	GMRA reads $635.9M.
Threshold	The unsecured cushion written into the agreement — the amount that may go uncovered before collateral is required.	Fixed per agreement type (GMRA $12.0M, GMSLA $18.0M, all others zero). Compare with the agreement's own terms.	GMRA reads $12.0M.
Total exposure	Everything the agreement has to cover: what is owed plus its threshold cushion.	Add the row's Call / obligation and Threshold. The answer must equal this cell.	GMRA: $635.9M + $12.0M = $647.9M
Total Posting · Total	All the collateral posted against the agreement — bonds and cash together. It is the Total column of the Total Posting group.	Add the row's Bonds (Posted) and Cash (Posted) — the other two columns under Total Posting. Click the cell to list the individual postings; they add up to this figure.	GMRA: $587.9M + $11.1M = $598.9M
Margin call	The call struck against the agreement on the reference date. A positive figure means collateral must be delivered. A negative figure means more is posted than owed, and it can be collected back. It is an INBOUND figure, read from the Exposures & margin calls data, catalog set 10. It is not worked out from anything else on the row.	Do not recompute it from this row. Read it back from the margin-call record for that agreement and date. The Margin Calls view shows the same figure. In the sample data the call is struck as the day's position. So it currently also equals Call / obligation minus Total Posting · Total. But that is a property of the sample, not the rule. The build must READ the figure; if the data and that subtraction ever disagree, the margin-call data wins.	GMRA reads $37.0M.
Total Allocated · Total	How much of the posted collateral is actually consumed covering the exposure. It is never more than was posted, and never more than the exposure needs. It is the Total column of the Total Allocated group.	Take the smaller of the row's Total Posting · Total and its Total exposure. The answer must equal this cell.	GMRA: the smaller of $598.9M and $647.9M = $598.9M
Total Allocated · Bonds (Allocated) + Cash (Allocated)	The allocated total split between bonds and cash in the same proportion as the collateral was posted.	Add the other two columns under Total Allocated: Bonds (Allocated) and Cash (Allocated). The answer must equal Total Allocated · Total.	GMRA: $587.9M + $11.1M, which must equal Total Allocated · Total = $598.9M
Unallocated	The collateral posted but not consumed — what is sitting there spare. Never negative, because nothing can use more than was posted.	Subtract the row's Total Allocated · Total from its Total Posting · Total. The answer must equal this cell.	GMRA: $598.9M − $598.9M = $0.0M
Surplus	What is left of the collateral allocated once the margin call has been met. The margin call is positive when we have to post. Allocate $100M against a call of $50M, and $50M is spare. A negative call means nothing has to go out. It can be collected back, so it adds to the surplus.	Subtract the row's Margin call from its Total Allocated · Total. The answer must equal this cell. Watch the sign: where Margin call is negative, subtracting it ADDS to the surplus.	GMRA: $598.9M − $37.0M = $562.0M
Expected post	The collateral expected to go out: the margin call when it is positive, otherwise nothing.	Read the row's Margin call. If it is positive this cell repeats it; if it is negative or zero this cell reads zero.	GMRA: Margin call is $37.0M, so this cell = $37.0M
Expected collect	The collateral expected to come back: the margin call when it is negative, shown without the minus sign, otherwise nothing.	Read the row's Margin call. If it is negative, this cell shows the same amount without the minus sign. If it is positive or zero, this cell reads zero. Bilateral CSA IM shows a dash, because initial margin is not collected back.	GMRA: Margin call is $37.0M, so this cell = $0.0M
Received (in)	Collateral counterparties have posted TO us on the reference date. It is INFORMATION ONLY.	There is nothing on this row to reconcile it against, and that is deliberate. Received (in) never feeds the margin call, Unallocated, Surplus or any other worked-out figure. If a change ever makes another figure move when Received moves, that is a defect.	GMRA reads $672.4M.

▸ The live Agreement summary figures these examples were read from (Summary by agreement type, as at 2026-06-18)

Agreement	Total exposure	Call / obligation	Received (in)	Margin call	Total Posting · Total	Total Posting · Bonds (Posted)	Total Posting · Cash (Posted)	Total Allocated · Total	Total Allocated · Bonds (Allocated)	Total Allocated · Cash (Allocated)	Unallocated	Surplus	Threshold	Expected post	Expected collect
GMRA	$647.9M	$635.9M	$672.4M	$37.0M	$598.9M	$587.9M	$11.1M	$598.9M	$587.9M	$11.1M	$0K	$562.0M	$12.0M	$37.0M	$0K
CCP	$485.1M	$485.1M	$513.9M	-$28.4M	$513.5M	$263.7M	$249.8M	$485.1M	$249.1M	$236.0M	$28.4M	$513.5M	$0K	$0K	$28.4M
GMSLA	$394.9M	$376.9M	$404.2M	-$32.0M	$408.9M	$373.8M	$35.1M	$394.9M	$361.0M	$33.9M	$14.0M	$426.9M	$18.0M	$0K	$32.0M
Bilateral CSA VM	$225.2M	$225.2M	$254.5M	-$34.1M	$259.4M	$79.7M	$179.7M	$225.2M	$69.2M	$156.0M	$34.1M	$259.4M	$0K	$0K	$34.1M
Bilateral CSA IM	$200.5M	$200.5M	$209.1M	$26.5M	$174.0M	$139.6M	$34.4M	$174.0M	$139.6M	$34.4M	$0K	$147.4M	$0K	$26.5M	—
Futures	$141.8M	$141.8M	$148.2M	$77.2M	$64.7M	$13.3M	$51.3M	$64.7M	$13.3M	$51.3M	$0K	-$12.5M	$0K	$77.2M	$0K
Total (6)	$2.1B	$2.07B	$2.2B	$46.2M	$2.02B	$1.46B	$561.3M	$1.94B	$1.42B	$522.6M	$76.5M	$1.9B	$30.0M	$140.7M	$94.5M

▸ The Key-figures cards must equal the table’s total row

The cards above the table and the table’s own total row are two views of the same figures. Read one against the other — they must agree, allowing for rounding. The cards are rounded to whole millions or billions. The table is rounded to one decimal place. This is the quickest check that the screen is internally consistent.

Key-figures card	Card shows	Table total row column	Total row shows	Agree?
Total exposure	$2.1B	Total exposure	$2.1B	✓ agree
Total posting	$2B	Total Posting · Total	$2.02B	✓ agree
Bonds posted	$1.5B	Total Posting · Bonds (Posted)	$1.46B	✓ agree
Cash posted	$561M	Total Posting · Cash (Posted)	$561.3M	✓ agree
Total allocated	$1.9B	Total Allocated · Total	$1.94B	✓ agree
Bonds allocated	$1.4B	Total Allocated · Bonds (Allocated)	$1.42B	✓ agree
Cash allocated	$523M	Total Allocated · Cash (Allocated)	$522.6M	✓ agree
Unallocated	$76.5M	Unallocated	$76.5M	✓ agree
Received (inbound)	$2.2B	Received (in)	$2.2B	✓ agree

Result of this run: every figure ties — no mismatches.

Field check sheet generated — do not hand-edit

What this is. A generated check that every field the Data tab lets you map is actually read by a screen. It is the field-level companion to the Figure check sheet: that one stops the numbers in this document drifting from the app, this one stops the fields drifting. It is written by a script and re-checked by the standing test run, so a field that quietly stops being read cannot sit here unnoticed.

How to read it. Read means mapping that field changes what a screen shows. Not read means the box is there and nothing looks at it — a field you could fill in for no effect. Set not wired means no screen asks for that data set at all yet, so every one of its fields is in that position today.

Summary. 14 data sets accept a mapping. 4 are wired into the screens (8, 15, 121, 122). 10 are not: 1 · Counterparty static, 2 · Bond / securities static, 5 · Currency static, 6 · Agreements static, 6.1 · Agreement eligibility schedule, 10 · Exposures & margin calls, 12 · Optimization outputs, 13 · Optimization exclusions & exceptions, 14 · Collateral used data, 16 · MX Trades Data. Of the fields on wired sets, 0 are never read.

Set	Field you can map	Status	Read by
1 · Counterparty static	Counterparty name *	not wired	—
1 · Counterparty static	Counterparty code	not wired	—
2 · Bond / securities static	ISIN *	not wired	—
2 · Bond / securities static	Instrument Name	not wired	—
2 · Bond / securities static	Issuer	not wired	—
2 · Bond / securities static	Coupon	not wired	—
2 · Bond / securities static	Maturity	not wired	—
2 · Bond / securities static	Bond Currency	not wired	—
2 · Bond / securities static	Bond type	not wired	—
2 · Bond / securities static	Asset class	not wired	—
2 · Bond / securities static	Asset type	not wired	—
2 · Bond / securities static	Issuer type	not wired	—
2 · Bond / securities static	Issuer country	not wired	—
2 · Bond / securities static	Seniority	not wired	—
2 · Bond / securities static	Rating1	not wired	—
2 · Bond / securities static	Rating2	not wired	—
2 · Bond / securities static	Rating3	not wired	—
5 · Currency static	Currency code *	not wired	—
5 · Currency static	Base currency	not wired	—
6 · Agreements static	Type code *	not wired	—
6 · Agreements static	Short name	not wired	—
6 · Agreements static	Full name	not wired	—
6 · Agreements static	Reporting currency	not wired	—
6 · Agreements static	Colour	not wired	—
6 · Agreements static	Sub-accounts	not wired	—
6 · Agreements static	Custodian	not wired	—
6 · Agreements static	Threshold cushion ($mm)	not wired	—
6 · Agreements static	Agreement end date	not wired	—
6 · Agreements static	Benchmark rate	not wired	—
6 · Agreements static	Rounding (delivery)	not wired	—
6 · Agreements static	Rounding (return)	not wired	—
6 · Agreements static	Holiday centre(s)	not wired	—
6 · Agreements static	Settlement delay	not wired	—
6 · Agreements static	Calculation rule	not wired	—
6 · Agreements static	Interest settlement date	not wired	—
6 · Agreements static	Allow negative rate	not wired	—
6 · Agreements static	Concentration limits group name	not wired	—
6 · Agreements static	Limit type	not wired	—
6 · Agreements static	Limit type granularity	not wired	—
6 · Agreements static	Limit	not wired	—
6 · Agreements static	Limit unit	not wired	—
6 · Agreements static	Basis	not wired	—
6 · Agreements static	Margin type	not wired	—
6 · Agreements static	Valuation frequency	not wired	—
6 · Agreements static	Reciprocity	not wired	—
6 · Agreements static	ABC MTA	not wired	—
6 · Agreements static	Counterparty MTA	not wired	—
6 · Agreements static	Notification time	not wired	—
6 · Agreements static	Resolution time	not wired	—
6 · Agreements static	Time zone	not wired	—
6 · Agreements static	Interest calc method	not wired	—
6 · Agreements static	Interest / rebate rate	not wired	—
6 · Agreements static	Issuer sector	not wired	—
6 · Agreements static	ABC threshold	not wired	—
6 · Agreements static	Counterparty threshold	not wired	—
6 · Agreements static	Minimum rating accepted	not wired	—
6 · Agreements static	Collateral types accepted	not wired	—
6 · Agreements static	Counterparty	not wired	—
6.1 · Agreement eligibility schedule	Type code *	not wired	—
6.1 · Agreement eligibility schedule	Eligibility schedule name	not wired	—
6.1 · Agreement eligibility schedule	Collateral type	not wired	—
6.1 · Agreement eligibility schedule	Eligible currencies	not wired	—
6.1 · Agreement eligibility schedule	Minimum security rating	not wired	—
6.1 · Agreement eligibility schedule	Time to maturity	not wired	—
6.1 · Agreement eligibility schedule	Haircut schedule	not wired	—
6.1 · Agreement eligibility schedule	Exclusions	not wired	—
6.1 · Agreement eligibility schedule	Interest / rebate rate	not wired	—
7.2 · G7 industry group	Issuer Industry	not wired	—
7.2 · G7 industry group	Classification Level 4 name	not wired	—
7.2 · G7 industry group	BICS Level 2 Industry Group Name	not wired	—
7.2 · G7 industry group	G7 industry group	not wired	—
7.3 · Source of collateral	Collateral source	not wired	—
7.8 · G7 by bond	ISIN	not wired	—
7.8 · G7 by bond	G7 industry group	not wired	—
8 · Market data — FX rates	FX Currency *	read	collat-inventory.js, j-collateral.html
8 · Market data — FX rates	Rate (USD per 1 unit) *	read	collat-inventory.js, j-collateral.html
10 · Exposures & margin calls	Agreement type *	not wired	—
10 · Exposures & margin calls	Date *	not wired	—
10 · Exposures & margin calls	Obligation (what’s owed) *	not wired	—
10 · Exposures & margin calls	Total posting	not wired	—
10 · Exposures & margin calls	Bonds posted	not wired	—
10 · Exposures & margin calls	Cash posted	not wired	—
10 · Exposures & margin calls	Received (inbound)	not wired	—
10 · Exposures & margin calls	Bond share for the day	not wired	—
10 · Exposures & margin calls	Margin call	not wired	—
10 · Exposures & margin calls	Dispute age	not wired	—
12 · Optimization outputs	Run reference *	not wired	—
12 · Optimization outputs	Run name	not wired	—
12 · Optimization outputs	Agreement Name *	not wired	—
12 · Optimization outputs	ISIN *	not wired	—
12 · Optimization outputs	Market value posted ($mm)	not wired	—
12 · Optimization outputs	Haircut applied	not wired	—
12 · Optimization outputs	Collateral value ($mm)	not wired	—
12 · Optimization outputs	Funding cost (bps)	not wired	—
12 · Optimization outputs	Annual carry cost ($mm)	not wired	—
12.1 · Bond sources (internal)	ISIN *	read	j-collateraldemo.html
12.1 · Bond sources (internal)	Desk (Source)	read	j-collateraldemo.html
12.1 · Bond sources (internal)	Portfolio (Source) *	read	j-collateraldemo.html
12.1 · Bond sources (internal)	Direction	read	j-collateraldemo.html
12.1 · Bond sources (internal)	Amount	read	j-collateraldemo.html
12.1 · Bond sources (internal)	Start Date	read	j-collateraldemo.html
12.1 · Bond sources (internal)	End Date	read	j-collateraldemo.html
12.1 · Bond sources (internal)	Rate	read	j-collateraldemo.html
12.2 · Bond destinations (postings out)	ISIN *	read	j-collateraldemo.html
12.2 · Bond destinations (postings out)	Agreement (Destination) *	read	j-collateraldemo.html
12.2 · Bond destinations (postings out)	Destination	read	j-collateraldemo.html
12.2 · Bond destinations (postings out)	Direction	read	j-collateraldemo.html
12.2 · Bond destinations (postings out)	Amount	read	j-collateraldemo.html
12.2 · Bond destinations (postings out)	Start Date	read	j-collateraldemo.html
12.2 · Bond destinations (postings out)	End Date	read	j-collateraldemo.html
12.2 · Bond destinations (postings out)	Rate	read	j-collateraldemo.html
13 · Optimization exclusions & exceptions	Run reference *	not wired	—
13 · Optimization exclusions & exceptions	Exception category *	not wired	—
13 · Optimization exclusions & exceptions	Record reference *	not wired	—
13 · Optimization exclusions & exceptions	Record name	not wired	—
13 · Optimization exclusions & exceptions	Record detail	not wired	—
13 · Optimization exclusions & exceptions	Why it was held out	not wired	—
13 · Optimization exclusions & exceptions	Records affected	not wired	—
13 · Optimization exclusions & exceptions	Amount needed ($mm)	not wired	—
13 · Optimization exclusions & exceptions	Amount covered ($mm)	not wired	—
13 · Optimization exclusions & exceptions	Amount short ($mm)	not wired	—
13 · Optimization exclusions & exceptions	Collateral types accepted	not wired	—
13 · Optimization exclusions & exceptions	Minimum rating accepted	not wired	—
13 · Optimization exclusions & exceptions	Eligible issuer groups	not wired	—
13 · Optimization exclusions & exceptions	Eligible lines that qualify	not wired	—
14 · Collateral used data	Agreement Name *	not wired	—
14 · Collateral used data	Trade #	not wired	—
14 · Collateral used data	Position	not wired	—
14 · Collateral used data	Counterparty	not wired	—
14 · Collateral used data	Asset Class	not wired	—
14 · Collateral used data	Agreement Category	not wired	—
14 · Collateral used data	ISIN / Currency *	not wired	—
14 · Collateral used data	Maturity Date	not wired	—
14 · Collateral used data	Date of Posting	not wired	—
14 · Collateral used data	Valuation Date	not wired	—
14 · Collateral used data	Booking Currency	not wired	—
14 · Collateral used data	Par Amount	not wired	—
14 · Collateral used data	Booking Market Value	not wired	—
14 · Collateral used data	Booking Collateral Value	not wired	—
14 · Collateral used data	Haircut	not wired	—
14 · Collateral used data	Reporting Currency	not wired	—
14 · Collateral used data	Market Value (USD)	not wired	—
14 · Collateral used data	Collateral Value (USD)	not wired	—
14 · Collateral used data	FX Rate	not wired	—
15 · Inventory data	Portfolio	read	collat-inventory.js
15 · Inventory data	Business Line	read	collat-inventory.js
15 · Inventory data	Holding	read	collat-inventory.js
15 · Inventory data	Instrument Name	read	collat-inventory.js
15 · Inventory data	ISIN *	read	collat-inventory.js
15 · Inventory data	Bond Currency	read	collat-inventory.js
15 · Inventory data	Bond Notional (mm)	read	collat-inventory.js
15 · Inventory data	Issuer Name	read	collat-inventory.js
15 · Inventory data	Issuer Country	read	collat-inventory.js
15 · Inventory data	Seniority of Bond	read	collat-inventory.js
15 · Inventory data	Coupon	read	collat-inventory.js
15 · Inventory data	Callable	read	collat-inventory.js
15 · Inventory data	Clearer	read	collat-inventory.js
15 · Inventory data	Sector of Issuer	read	collat-inventory.js
15 · Inventory data	Industry Classification	read	collat-inventory.js
15 · Inventory data	Issuer Rating	read	collat-inventory.js
15 · Inventory data	Bond Rating	read	collat-inventory.js
15 · Inventory data	MTM of Notional (mm)	read	collat-inventory.js
15 · Inventory data	Trade Start	read	collat-inventory.js
15 · Inventory data	Maturity Date	read	collat-inventory.js
16 · MX Trades Data	Product	not wired	—
16 · MX Trades Data	Trade ID *	not wired	—
16 · MX Trades Data	Trade date	not wired	—
16 · MX Trades Data	Maturity	not wired	—
16 · MX Trades Data	Notional	not wired	—
16 · MX Trades Data	Trade Currency	not wired	—
16 · MX Trades Data	MtM (USD)	not wired	—

§E.2 · Overview — Key-figures cards (9 KPI tiles)

Card	Data set	Entity · field	Comes from (plain English)
Total exposure	10 + 6	derived figures	Worked out — obligation across the selection plus each threshold cushion.
Total posting · Bonds posted · Cash posted · Received (inbound)	Collateral used data · 14	data models 10 & 14 · posting / bonds / cash / received	Referenced — the day’s posting figures and inbound collateral, added across the selection.
Total allocated · Bonds allocated · Cash allocated · Unallocated	Worked out	derived figures	Worked out. Allocated is the smaller of posting and exposure. It is split into bonds and cash by the posting mix. Unallocated is posting minus allocated. Each card’s sub-line compares versus one week earlier.

§E.3 · Overview — charts & cross-filter chips

Element	Data set	Comes from (plain English)
Utilisation history — Bonds / Cash bars	Collateral used data · 14	The period-average bonds and cash posted (data models 10 & 14), bucketed to the chosen granularity.
Utilisation history — Exposure line	10 + 6	Worked out — obligation plus threshold across the selection.
Utilisation history — Total-posted line	Worked out	The posted total itself, read straight off the record — the same figure as the Total posting card and the Agreement summary table. It lands exactly on top of the Bonds + Cash bars. The fixed 10% demo buffer that used to lift it was removed on 08 Aug 2026 (OQ-10, closed).
By agreement — stacked posting mix	14 + 6	Posted per agreement (colours from Agreements static).
Sources of collateral — bars	14 + Source of collateral · 7.3	Posted value grouped by funding source; the source of each posting follows the user’s Source-of-collateral rules.
Bond collateral by G7 group — doughnut	14 + 2 + G7 industry group · 7.2	Posted bond value grouped by G7 industry group — each bond’s sector (Bond static) mapped through the user’s G7 map.
Cross-filter chips (As at / Active in / Agreement / Type / Source / breakdown / postings)	follows the filtered dimension	Each chip is a filter over the dimension it names. Those are agreement (6), bond type (2), source (7.3/14), or a date or period from screen state.

§E.4 · Margin Calls view (Daily Exposure Report) — Epic 3

Same underlying figures as the Agreement summary table (§E.1). Every column is either an Agreements static · 6 attribute or an Exposures & margin calls · 10 figure.

Field	Data set	Comes from (plain English)
Agreement · Category · LRP · Threshold · Base CCY · Notification time · Resolve by · Credit Rating · Statement Status · Region	Agreements static · 6	Referenced — attributes carried on the agreement / its type.
Total Exposure · Call / Obligation · Margin Call	Exposures & margin calls · 10	The day’s obligation (+ threshold for exposure); Margin Call = owed minus posted.
Call Status · Action	10	The call’s review status; Action = Delivery or Call.
ITM / OTM Exposure · Net Alternative ⚑	10 ⚑	Modelled split of exposure — no real mark-to-market feed (see §E.14).
STD Amount · Cpty Amount · Agreed Amount · Dispute Value · Dispute Age	10	Your figure, the counterparty’s, the agreed one, and any dispute; modelled close to the call amount in the demo.
Base Total Exp. · Base Call Amt	10 + FX · 8	Exposure / call amount converted into the agreement’s base currency.
KPI tiles: Total Margin Call · Pending Review · Confirmed · No Call · Disputes	10	Totals / counts of the rows by call status and dispute.

§E.5 · Bond postings / Postings by bonds / Bonds Maturing blotter — Epic 2 / 4

Column	Data set	Entity · field	Comes from (plain English)
Agreement Name	6 + 1	data model 14	The individual agreement’s account code (agreement + counterparty + sub-book).
Trade #	Collateral used data · 14	data model 14	Held on the posting line — its posting/trade reference.
ISIN · Security · Type · Sector · Original Ccy · Maturity	Bond / securities static · 2	data model 14 (instrument attributes)	Referenced — the security’s reference details.
Counterparty	Counterparty static · 1	data model 14	Referenced — who the collateral is with.
Agreement Type	Agreements static · 6	data model 6 · name	Referenced — the type this posting sits under.
Custodian	6 / 14	data model 14	The custody agent (the type’s sub-account, or the settlement agent held on the line). On a Triparty line this is the triparty repo agent — Euroclear, Clearstream or BNY Mellon.
Source	Source of collateral · 7.3	data model 14	The funding source, per the user’s Source-of-collateral rules.
Start date	Collateral used data · 14	data model 14	Held on the line — when the posting started.
Maturing in Days	Worked out	derived figures	Worked out — days from the reference date to maturity.
Original Amount	Collateral used data · 14 + FX · 8	data model 14	Worked out — how much of the bond was posted on this line. It is counted in the instrument’s own currency. Take the posted value in US dollars and convert it back at the line’s exchange rate.
Posted (USD)	Collateral used data · 14 + FX · 8	data model 14	What G7 posted on this line, in US dollars — the Original Amount multiplied by the line’s exchange rate. The posted lines of an agreement add back to that agreement’s “Bonds (Posted)” figure in the summary.
Allocated (USD)	Collateral used data · 14 + Exposures & margin calls · 10	data model 14	Worked out — what TMO allocated on this posting, not what G7 posted. Take the Posted (USD) figure and scale it down by the agreement’s allocated-versus-posted coverage. That coverage is the smaller of one, and the exposure divided by the total posting. So the postings add back to the agreement’s “Bonds (Allocated)” in the summary.
Unallocated (USD)	Worked out	data model 14	Worked out — Posted (USD) minus Allocated (USD). It is what was posted into the long box, but not consumed by the agreement’s margin requirement. Never below zero; a fully-used posting shows nothing unallocated.

§E.6 · T+N settlement ladder (Triparty) — Epic 4

Field	Data set	Comes from (plain English)
Triparty agent (section)	6 / 14	The triparty custody agent (Euroclear / Clearstream / BNY Mellon).
Country (row) ⚑	⚑ none	⚑ The country breakdown has no catalogued source — a fixed demo list (see §E.14).
T+0 … T+5 amounts & total ⚑	⚑ none	⚑ The settlement-availability amounts are demo placeholder numbers. They are not drawn from Collateral used (14) or Inventory (15). A source must be agreed — see §E.14.

§E.7 · Agreement detail popup — Epic 6

Most of the popup is the agreement’s term sheet — all Agreements static · 6. The live money figures re-use the Overview book (§E.1).

Card · field	Data set	Comes from (plain English)
Exposure card — MTM & Independent Amount (IA) ⚑	10 ⚑	Worked out — the obligation split into a market-value part and an independent-amount buffer. ⚑ The split is modelled, not a real valuation feed (see §E.14).
Required / Posted / Shortfall / % covered	10 + 14	Worked out — obligation vs posting at the reference date.
Agreement Admin — type, margin type, valuation frequency, reciprocity	Agreements static · 6	Referenced — the agreement’s legal / mechanics terms.
Agreement Admin — Benchmark rate ⚑	6 (name) / 9	The reference-rate name only (e.g. SOFR). ⚑ Benchmark rate levels (set 9) are a placeholder — no rate value is modelled.
Dates & Status — Start / End date; Agreement status	6 / Worked out	Start/End referenced; status worked out from whether there is a call.
Eligibility schedule — Cash / Govt blocks (asset class, currency, interest/rebate rate, issuer, seniority, rating floor, maturity limit, haircut schedule, exclusions)	Agreements static · 6	Referenced — the agreement’s eligible-collateral schedule (per collateral type).
Eligibility schedule — Corp block ⚑	6 ⚑	⚑ Several Corp schedule rows carry the same fixed wording for every agreement, rather than per-agreement data. They should be sourced from each agreement’s schedule. See §E.14.
Eligibility — “$X posted · Y%” per type	14 + 2	Worked out — the agreement’s postings grouped into Cash / Govt / Corp.
Concentration risk — limit meta (group, limit type, granularity, limit, unit, basis)	Agreements static · 6	Referenced — the agreement’s concentration limits.
Concentration risk — by-asset-type & by-issuer bars, breach flag	14 + 2	Worked out — each asset type’s / issuer’s share of the posting, compared to the limit.
Asset Holdings Summary — sector rows, Total bonds / Cash / Total posted ⚑	14 + 2	Worked out — the agreement’s postings by sector. ⚑ The Delivery / Market-Value / Collateral-Value columns use fixed demo factors rather than real per-line values (see §E.14).
Margin Call Summary — ABC / Cpty MTA, rounding	Agreements static · 6	Referenced — minimum transfer amounts and rounding terms.
Margin Call Calculation — balance, call/unallocated, thresholds, total exposure	10 + 14 + 6	Worked out — posted vs owed and the resulting call, against the thresholds.
Call Schedule — notification / resolution time, time zone, settlement delay	Agreements static · 6	Referenced — the agreement’s call-timing terms.
Call Schedule — Holiday centre(s) ⚑	6 (text) / 3	Free-text on the agreement. ⚑ A real holiday calendar (set 3) is a placeholder.
Collateral Rules — interest calc method, calc rule, interest settlement, allow negative rate	Agreements static · 6	Referenced — the agreement’s interest/collateral terms.
Trades tab (Product, Trade ID, Trade date, Maturity, Notional, Ccy, MtM) ⚑	⚑ none (MtM ties to 10)	⚑ The individual derivative trades have no catalogued source — only their total mark-to-market ties back to the exposure (see §E.14).
Postings tab	14 + 2	The same postings blotter (§E.5), filtered to this agreement.

§E.8 · Exposure drill — trade contributions — Epic 7

Column	Data set	Comes from (plain English)
Agreement	6 / 1	Referenced — the agreement the trade belongs to.
MtM (USD)	Exposures & margin calls · 10	Worked out — the per-trade mark-to-market; the total ties to the agreement’s exposure.
Product, Trade ID, Trade date, Maturity, Notional (USD), Ccy ⚑	⚑ none	⚑ The individual trade attributes have no catalogued source — a derivative-trade feed is needed (see §E.14).
(Collateral-Posted mode)	14 + 2	The same postings blotter (§E.5).

§E.9 · Instrument detail modal — Epic 8

Field	Data set	Comes from (plain English)
Instrument name, ISIN, Issuer, Issuer country, Industry classification, Sector of issuer, Instrument currency, Coupon (and whether it is callable), Seniority, Maturity date	Bond / securities static · 2	Referenced — the security’s reference details. On the Overview the country and the sector come from the issuer reference list. The industry classification comes from the bond’s type. In the real system all of them are held once, on the security.
Clearer ⚑	2 / 14 ⚑	Where the collateral settles and sits. On the Overview it is the posting’s custodian or triparty agent. ⚑ Confirm whether it belongs to the security’s settlement instructions or to the position (see §E.14).
Bond rating, Issuer rating ⚑	2 ⚑	Worked out from the bond type. The bond’s own rating is then moved off the issuer’s by its seniority. Subordinated paper rates lower; secured and covered paper rates higher. ⚑ Not a stored per-security rating (see §E.14).
Classification Level 4 name, BICS Level 2 Industry Group Name, Issuer Industry, G7 Industry group	G7 industry group · 7.2	Every bond maps to one row of the G7 industry group mapping table (§14). All four are that row’s values. That is the row whose Issuer Industry matches the bond’s, and that has a G7 group filled in. When nothing matches, it is the table’s last row — the catch-all, where every column is the default. To check, open User maintenance → G7 industry group and read that row.
Bond notional, MTM of notional, price ⚑	Collateral postings · 14 + 2 ⚑	Worked out. The market value is every posting of this bond added up, in the bond’s own currency. The face notional is that value divided by the price, out of 100. ⚑ The price needs a security-price source, which is not on the catalogue (see §E.14). Full trace and worked example: US8.4.
Type ⚑	Bond / securities static · 2 ⚑	The security bucket each screen already groups its own book by. On the Overview it is the bond type (SGS, UST, Supra, Agency, Corporates). In the Inventory Manager it is the holdings category on the summary cards (Govies, Supra, Agency, Financials, Corporates). ⚑ Confirm the one list of types the real system should hold on the security (see §E.14).
Issue date ⚑	2 ⚑	Worked out back from maturity — a whole number of years, three to ten, fixed by the ISIN. ⚑ Not a stored field yet (see §E.14).
Trade start, Deal status	Collateral postings · 14	Worked out from the pledge window. Trade start is the earliest date this bond was posted. Deal status reads “Live to maturity” when the pledge runs to maturity. It reads “Terminates” with that date when the pledge ends earlier.
Day count, Settlement (T+), Haircut, Accrued interest, Country of risk ⚑	2 (placeholder) ⚑	⚑ Shown as “to be provided”, on both screens. These are Bond static (set 2) fields not yet surfaced here. See §E.14.

§E.10 · Inventory Manager — Epic 10

The whole page is fed by the holdings pool — Inventory data · 15. Each holding carries reference attributes and its own economics. The reference attributes come from Bond static · 2, Portfolios · 4 and Currency · 5. USD figures convert via FX · 8. User-added rows come from Adjusting inventory · 7.6.

Field	Data set	Comes from (plain English)
Summary tiles (Total holdings, N trades, face; Govies / Supra / Agency / Financials / Corporates)	Worked out over 15 + 8	Worked out — holding values added up (and grouped by industry), converted to USD.
ISIN, Instrument Name, Issuer Name, Issuer Country, Sector, Industry Classification, Seniority, Callable / Coupon, Instrument Ccy, Issuer Rating, Bond Rating	Bond / securities static · 2	Referenced — the instrument’s reference details (Bond Rating is notched from the issuer rating).
Portfolio	Portfolios static · 4	Referenced — the owning portfolio the holding points to.
Business Line ⚑	4 ⚑	The owning desk / business line. ⚑ Confirm this is a Portfolios-static attribute (see §E.14).
Bond Notional (mm), MTM of Notional (mm) ⚑	Inventory data · 15 ⚑	Held on the holding — face amount and market value. ⚑ The market value needs a security-price source, which is not on the catalogue (see §E.14).
Clearer ⚑	15 / 2 ⚑	The settlement / custody location. ⚑ Confirm whether it belongs to the holding (15) or the security’s settlement instructions (2) — see §E.14.
Time-series view — per-day notional	Inventory data · 15	Worked out — each holding’s notional as at each business day (nil when not live).
Snapshot as-at date, filters, column show/hide	screen state	Presentation controls; the date bounds come from the holdings’ start / maturity dates.
Instrument modal “Further fields” (Issue date, Day count, Settlement T+, Haircut, Accrued interest, Country of risk) ⚑	placeholder ⚑	⚑ Declared “to be provided”. They would map to Bond static (2), Currency / Holiday (5 / 3), and Collateral used (14, haircut). None is sourced yet.

§E.11 · Rules engine — Epic 11 (also reached from the Overview sidebar and the Overview 2 widget — one screen, three doors)

Field	Data set	Comes from (plain English)
Rule library — name, group, input source, filter field, condition, value, note, enabled	Optimization rules · 11	The rule configuration the user builds, plus the built-in starter rules already loaded when the app opens.
Run parameters (concentration cap, MTA, rounding, buffer, allow partial)	Optimization rules · 11	The run’s parameters.
Input tables (Inventory / Margin calls / Agreements) with in-scope / out flags	15 / 10 / 6 + 13	The input rows come from those sets; the in-scope / out decision is an exclusion (set 13).
Agreements input drawer — Eligible issuer groups (G7)	Agreements static · 6 + User-maintained data · 7	Referenced — the issuer groups named on that agreement’s own eligibility schedule (its Issuer / Issuer type lines). The groups themselves are the ones the user maintains in the G7 industry group table.
Output drawer — allocation cards, coverage, carry saving, full posting detail	Optimization outputs · 12	What a rules run produces.
Output drawer — the issuer group shown against each recommended posting	Inventory data · 15 + User-maintained data · 7	Referenced — the holding’s issuer industry, from the bond inventory. The user’s G7 industry group mapping table translates it into a G7 group. Until that table is filled in, it is left as the issuer industry itself.

§E.12 · Static Data reference screens — Epic 5 (all placeholder)

Screen	Data set	Status
Counterparty	Counterparty static · 1	Placeholder — schema only (“— to be provided —”).
Instrument	Bond / securities static · 2	Placeholder — schema only.
Holiday Calendar	Holiday calendars · 3	Placeholder — schema only.
Portfolio	Portfolios static · 4	Placeholder — schema only.
Currency	Currency static · 5	Placeholder — schema only.
FX Rate	Market data FX · 8	Placeholder — schema only (only conversion factors modelled).
Interest Rate	Benchmark rates · 9	Placeholder — schema only.

§E.13 · User maintenance — six datasets — Epics 12–18 (each now its own catalog set 7.1–7.6)

Each dataset mixes system-provided columns (referenced read-only from another set) and user-entered columns. All persist to the browser and stamp a “Last updated”.

Dataset · column	Data set (source)	Who fills it
Cost of funds — Security Type	G7 industry group · 7.2	System (read-only) — the distinct G7 groups from set 7.2, always including the Others catch-all.
Cost of funds — Currency	Currency static · 5	System (read-only).
Cost of funds — Rate (internal) / Rate (external)	Cost of funds · 7.1	User-entered.
G7 industry group — Classification L4 / BICS L2 / Issuer Industry	2 + 7.2	System (read-only). Confirmed 24 Aug 2026: the bond carries its Issuer Industry on Bond / securities static (2); the app matches on it to find the bond’s row of the G7 industry group mapping table (7.2), and reads Classification L4 and BICS L2 off that row.
G7 industry group — G7 group (+ Others)	G7 industry group · 7.2	User-entered. Drives the Overview “By bond type” chart. It also drives the four classification fields on the instrument detail card (§8). Every bond is matched back to a row of this table. Anything unmatched takes the catch-all row.
Source of collateral — Field (portfolio dimensions)	Portfolios static · 4	System (dropdown list).
Source of collateral — Match / Value / Collateral Source	Source of collateral · 7.3	User-entered. Drives the Overview “Sources” chart.
Special agreements — Agreement name	Agreements static · 6	System (found on screen, not typed) — the agreement names the app puts on screen, each shown with the agreement type it is booked under and its counterparty.
Special agreements — Tag	Special agreements · 7.4	User-entered, and the only thing the user sets here. One of Zero-interest CSA, which makes the agreement filterable on the dashboards, or Korean CSA, which drops the agreement from the app, or none, which leaves it ordinary.
Adjusting exposures — Agreement name	Agreements static · 6	System (dropdown).
Adjusting exposures — Adjusted Exposure (USD / orig), Original Ccy, Date	Adjusting exposures · 7.5 (applied onto 10); Ccy from 5	User-entered. Adjusts an agreement’s exposure on the given date.
Adjusting inventory — 16 Bond-Inventory fields	Adjusting inventory · 7.6 (structure mirrors Inventory · 15)	User-entered. Appended into the Inventory Manager.

§E.14 · Off-catalogue & to-confirm (⚑) — raised, not invented

These displayed fields do not yet trace cleanly to one of the 15 catalogued data sets. Or their source needs the product owner’s confirmation. Per the standing lineage rule, they are listed here for a decision. A source must be agreed and added to the catalog before the field is built for real. Nothing has been invented to fill the gap.

#	Where	Gap	Suggested resolution
1	Exposure drill (§E.8) & Agreement detail → Trades tab (§E.7)	No derivative-trade data set. Six trade fields have no source among the 15 sets. They are Trade ID, Product, Notional, Trade date, Maturity and Ccy. Only the trades’ total mark-to-market ties to Exposures · 10.	Add a “Trades / derivative positions” data set to the catalog (the trade-level feed exposure is calculated from).
2	Inventory Manager (§E.10); Agreement Exposure card MTM/IA (§E.7); ITM/OTM split (§E.1/§E.4)	No security-price / valuation data set. Market value (MTM) needs a per-security price. The catalog has FX (8) and benchmark rates (9) only. There is no security-price feed.	Add a “Market data — security prices / valuations” data set (or extend Bond static · 2 with a price).
3	T+N settlement ladder (§E.6)	No source for the ladder. The T+0 to T+5 settlement-availability amounts are demo placeholder numbers, and so is the country breakdown. Neither is drawn from Collateral used (14) or Inventory (15).	Confirm the source: a settlement-availability view over Inventory (15) / Collateral used (14) by agent, country and settlement horizon.
4	Inventory “Clearer” (§E.10)	Ambiguous set. The settlement/custody location could be a holding attribute (Inventory · 15) or the security’s settlement instructions (Bond static · 2).	Confirm which set owns the clearer / SSI attribute.
5	Inventory “Business Line” (§E.10)	To confirm. Mapped to Portfolios static (4), but the set’s description doesn’t name business line explicitly.	Confirm business line is a Portfolios-static attribute.
6	G7 industry-group system columns (§E.13)	Answered — 24 Aug 2026. Issuer Industry is a security attribute and lives on Bond / securities static (2), where it is now a field you can map. It is the value each bond is matched on when the app looks up its row of the G7 industry group mapping table; Classification Level 4 name, BICS Level 2 Industry Group Name and G7 Industry group are that row’s own columns and stay on G7 industry group (7.2).	Closed. Issuer Industry sits on Bond / securities static (2); nothing about issuer classification is held on Counterparty static (1).
7	Various demo-modelled figures	Modelled, not fed. Four items are modelled rather than sourced. The History chart’s Total-posted line, being posted lifted by a fixed 10% buffer. The ITM, OTM, Net-Alternative, STD, Cpty and Dispute amounts, modelled close to the call. The Agreement Holdings Delivery, Market and Collateral factors. And the hard-coded Corp eligibility rows.	Not off-catalogue data — flagged so a developer replaces the demo assumption with the real per-agreement / per-line value when building.
8	Instrument modal placeholders (§E.9, §E.10)	Placeholder fields. Six fields are shown as “to be provided”. They are Coupon frequency, Country of risk, Day count, Settlement (T+), Haircut and Accrued interest. Coupon and Sector already exist on the record.	Surface the existing Bond-static fields; add the remaining ones to Bond static (2) / Collateral used (14, haircut).

📋 Requirements 2 · Overview 2 — workspace builder

⚠ Overview 2 is retired — do not build the workspace builder

Decided 20 August 2026. The screen stays in the demo so it can still be opened and clicked through. It is not part of the system being built.

Developers: skip every user story on this tab — US9.1 through to the end. None of it is in scope.
Testers: do not run the UAT test cases · Overview 2 pack. It tests this screen only.
One section on this tab is still live and still needed: The data models this app uses, and inside it the Data source catalog — the master list of the data sets the whole application runs on. Requirements 1 links to it from every field it documents. It is not an Overview 2 section; it only happens to live on this tab. Keep building against it.
Nothing was lost by retiring it. Overview 2 showed no field the Overview does not already show — it re-drew the Overview’s own tables, charts and pop-ups. The Overview shows 19 more than it did.

This tab describes Overview 2 — the workspace builder (the 2nd tab in the app) — from your point of view as the person using it: what you can see, what you can do, and how to tell every figure is right. It is written in plain English so you can read it without any technical background. It was detailed enough for developers to build the real thing from it — that is no longer its purpose, see the notice above. It is kept as the record of how the screen works, so the decision can be reversed without rewriting it. It contains: a short About note, a Data model & data dictionary (what information the screen holds and where each number comes from), a guide to verifying the on-screen figures, and then the things you can do (“As a user, I can …”). The exact rebuild formulas a programmer needs are tucked into a single collapsed Developer build detail section at the end — you never need to open it. The step-by-step test scripts live on their own tab, “UAT test cases · Overview 2”. Finance terms and the shared table controls are explained in the appendices on the Requirements 1 tab.

📑 Contents — what’s on this page

The reference sections come first (what the screen holds and how to check it), then the things you can do, and finally an optional developer-only section you can skip.

📦 The data models this app uses — every data item & structure in one place
🧩 Building your workspace — canvas & workspaces
US9.1 Add, add again & close widgets
US9.2 Move, resize, pin & reflow
US9.3 Keep multiple workspaces — persist & reset
US9.4 Link widgets into colour groups
🎛️ The Agreements widget — control panel (Emitter ⬆)
US9.5 Select & drill agreements
US9.6 Set the shared filters & broadcast them
US9.7 What the Agreements widget shows
📊 The Collateral charts widget (Receiver ⬇)
US9.8 Switch between the four charts
US9.9 Click a chart to drill / cross-filter
US9.10 What the Collateral charts widget shows
📋 The Bond postings widget (Receiver ⬇ · single)
US9.11 Switch the blotter view
US9.12 Filter maturing & configure columns
US9.13 What the Bond postings widget shows
🔢 The Key figures strip
US9.14 What the strip shows
🔎 Checks that span more than one widget — where each number comes from & how to check it
🔧 Developer build detail — optional; formulas, seeds & schema (you can skip it)

ℹ︎ About this epic — what a workspace builder is & where to find it (click to expand)

To get here: click the Overview 2 tab (2nd tab).

Overview 2 is a workspace builder: a left palette lists every available widget; the user adds widgets onto a collision-aware grid, closes them, pins them, and drags / resizes them (widgets never overlap — moving or resizing one pushes the others out of the way and the set compacts upward).

The user can keep several workspaces (top tabs), each with its own independent set of widgets and layout, and can add the same widget many times (each instance is independent).

Everything inside each widget behaves the same way as on the Overview (§2–§8): clicking a chart drills in or cross-filters, the postings panel’s view toggles and column ⚙ work, and drill-downs open as full-screen overlays above the canvas.

Nothing on this page is left undocumented — the exact rebuild formulas a programmer needs (how the sample numbers are made, how each figure is worked out, how the layout is saved) are all here, gathered into the single collapsed Developer build detail section at the end so they don’t clutter the read; a business reader never needs to open it.

The three shared full-screen overlays that can open above the canvas — the agreement-detail popup, the exposure drill and the instrument modal — look and behave exactly as they do on the Overview, so they are specified once on the Requirements 1 tab (Epics 6 / 7 / 8) rather than repeated here.

📦 Data model & data dictionary — every data item & structure in one place

For the BA / developer: this single reference lists all the data Overview 2 needs — every entity, each of its fields (name · type · format/example · how it is derived), the reference/look-up tables, the derived figures shown on screen, and the exact persisted data structure.

Nothing here is a new field — it is the same data described in context under US9.15–US9.17, gathered in one place so you can see the whole model at a glance.

All figures are generated in-browser from fixed seeds (no backend); user-maintenance overrides are read from localStorage.

For every figure the screen shows, this spec documents not just where it comes from and how it is worked out, but how to confirm it is correct and where to look — if a card reads $10.0mm, a business analyst or tester must be able to prove that number rather than take it on trust.

The figure-by-figure checks are gathered under 🔎 Verifying the on-screen figures below (and the one fully worked collateral line in the collateral-used column dictionary is the template for checking a single line end to end).

Data source catalog — the canonical data sets (the master data list)

What this is, in plain terms: a collateral-management system is fed by a fixed set of source data sets — reference lists it looks things up in (who the counterparties are, what a bond is, which currencies exist), market data (exchange rates, interest rates), the day-to-day activity (exposures, margin calls, what collateral is posted), and the optimisation layer (the rules and what they produce).

The data sets below are the canonical master list for this whole application — the 15 top-level sets, with the user-maintained set (7) broken out into its eight datasets (7.1–7.8), each a set in its own right. Every widget on Overview 2 must draw its data from one of these sets — see the “Widget → data & logic lineage” table further down for which widget reads which set.

Status tells the developer how much of each set actually exists in the demo today:

Status	What it means
Modeled	The data set is fully generated / present and drives the screens.
Partial	Only a slice exists (e.g. a single exchange-rate number rather than a full market-data feed); the rest is still to be provided.
Placeholder — to be detailed	Not built yet. It is listed here on purpose as a reserved slot so nothing is forgotten; the field-level detail will be supplied later, and until then no field structure is invented for it.

#	Data set	What it holds (plain English)	Status	Where it lives today / maps to
1	Counterparty static	The reference list of who we face (names, codes; and later legal entity, LEI, rating, country, netting status).	Partial	A live name/code list drives selections and, under Triparty, the counterparties each triparty agent handles; the full Counterparty reference screen (Requirements 1 · Epic 5) is a schema-only placeholder (“— to be provided —”).
2	Bond / securities static	Reference details of each security (ISIN, issuer, issuer industry, coupon, maturity, currency, bond type, sector, rating).	Modeled	Instrument-level data behind the postings (data model 14) and the Inventory Manager; feeds the blotter and the “By bond type” chart. Also surfaced as the Rules engine widget’s Bond static data input (reference attributes per eligible collateral class).
3	Holiday calendars	Business-day / settlement calendars per market or currency (which dates are non-working).	Placeholder — to be detailed	Not built as data. Only a placeholder reference screen and free-text “holiday centres” exist. No Overview 2 widget consumes it yet.
4	Portfolios static	The reference list of portfolios / books / trading desks and their owning entity.	Partial	Live portfolio dimensions exist in the Inventory Manager and Rules engine; a portfolio reference screen (Requirements 1 · Epic 5) is a placeholder. Now read by the Rules engine widget via its Portfolio static input (Portfolio name, Close entity, PC Code, Desk, Book, Product Lines, Product Franchise).
5	Currency static	The reference list of currencies (code, name, decimal places, settlement lag, holiday calendar).	Partial	Only the FX conversion factors exist (see set 8); the full Currency reference screen is a placeholder.
6	Agreements static (CSA IM, CSA VM, Triparty Repo, Futures Clearing, GMSLA, GMRA, CCP — incl. eligibility schedule & concentration limits)	The term-sheet data for each agreement type: margin mechanics, thresholds/MTA, legal terms, the eligible-collateral (eligibility) schedule and the concentration limits.	Modeled	All 7 types present (data model 6); full per-type term sheets incl. eligibility schedule + concentration limits (agreement-detail popup, Requirements 1 · Epic 6). The concentration limit is one stored record per agreement (group, limit type, granularity, limit value/unit, scope, basis) held in a single canonical store, read by both the agreement-detail popup and the Rules engine widget’s Agreements input — one source of truth, so the limit shown in the two places is always the same value.
7	User-maintained data — the eight datasets the user edits/uploads themselves. Each is listed below as its own set (7.1–7.8), maintained on the User-maintenance tab and read by Overview 2 each time it loads. (The exact browser storage-key names are in the Developer build detail.)
7.1	Cost of funds	The internal and external cost-of-funds rate for every Security Type × currency (AUD / CAD / CHF / USD / SGD). Security Type is the G7 industry group from set 7.2, and an Others catch-all row is always present for anything the mapping does not recognise. All four fields are mandatory.	Modeled	User-maintenance tab → Cost of funds (the exact saved-data name is in the Developer build detail).
7.2	G7 industry group	The mapping from each issuer’s classification (Classification Level 4 name / BICS Level 2 Industry Group name / Issuer Industry) to a user-defined G7 industry group, with an Others catch-all.	Modeled	User-maintenance tab → G7 industry group. Drives the Overview “By bond type” chart and seeds the Cost-of-funds grid.
7.3	Source of collateral	User rules over portfolio fields (Product Lines / Book / Product Franchise / Attribute ID / Portfolio Description) with Include / Exclude values that assign each posting a Collateral Source.	Modeled	User-maintenance tab → Source of collateral. Drives the Overview “By source” chart.
7.4	Special agreements	One user list of agreement names. Per agreement it holds one tag, and the tag is the whole instruction: Korean CSA drops the agreement from the app, Zero-interest CSA leaves it in and makes it filterable on the dashboards.	Modeled	User-maintenance tab → Special agreements.
7.5	Adjusting exposures	User exposure adjustments (Agreement name, Original Exposure, Adjusted Exposure in USD, Adjusted Exposure in original currency, Original currency, Date) that add on to an agreement’s exposure on a given date.	Modeled	User-maintenance tab → Adjusting exposures.
7.6	Adjusting inventory	User-added inventory rows (using the Inventory Manager “Bond Inventory” fields) appended into the Inventory Manager.	Modeled	User-maintenance tab → Adjusting inventory.
7.7	Tags & highlights	The user’s own labels on the book. One row per tag: which attribute of the book it keys on (bond ISIN, instrument name, portfolio, business line, holding, issuer name, issuer country, instrument currency, clearer, sector of issuer or industry classification), the value it applies to, the name the user gives it, and its colour. Every trade carrying that value is highlighted in that colour in the Inventory Manager.	Modeled	User-maintenance tab → Tags & highlights; read by the Inventory Manager.
7.8	G7 by bond	The bonds whose G7 industry group the user has set by hand, one row per ISIN. It holds only the exceptions to set 7.2: a bond that is not listed here follows the mapping in 7.2. Where a bond is listed, its value is the G7 industry group used for that bond everywhere.	Modeled	User-maintenance tab → G7 by bond. Read by the instrument pop-up and the “By bond type” chart, and its distinct values are Security Types on the Cost-of-funds grid.
8	Market data — FX rates	Exchange rates used to convert every currency to the reporting currency (and later spot / bid-ask / as-of time / source).	Partial	A single conversion factor per currency (the FX exchange-rate look-up table in the reference / look-up tables); a full FX market-data feed is a placeholder.
9	Market data — benchmark interest rates	The reference interest rates / curves (e.g. SOFR, €STR, SORA) with levels, tenor, as-of date, day count.	Placeholder — to be detailed	Only rate names appear as text on agreement term sheets; no rate levels are modeled. No Overview 2 widget consumes it yet.
10	Exposures & margin calls (all agreements)	Each agreement’s daily exposure (what needs covering), its margin calls (requests to post more collateral), and the collateral received in from counterparties each day (the inbound side, which is what the Received (inbound) figure is drawn from).	Modeled	Daily book records (data models 10 & 14’s “Obligation (what’s owed)” field) + the margin-call flag / call statuses (data model 6); drives the Margin Calls view and the Exposure figures.
11	Optimization rules	The scoping, limit and ranking rules that decide how collateral is allocated, the runs they are grouped into, and each run’s own settings (concentration cap, minimum transfer amount, rounding increment, haircut buffer, Sweep the deck).	Modeled	Rules engine tab — the same screen the Overview sidebar entry and the Overview 2 widget show. This set is never a file. The user sets the rules and runs on that screen and what they set is the data, so the Data tab offers no upload or mapping for it. Lives outside Overview 2 — no Overview 2 widget consumes it yet.
12	Optimization outputs	What a rules run produces — one row per proposed movement: the run it belongs to, the agreement being covered, the security to deliver, the market value posted, the haircut applied, the collateral value that gives, and what the line costs to fund. The run’s headline figures (annual carry, saving against posting all cash, requirement covered, blended funding cost) are added up from these rows, not stored on them.	Modeled	The Optimisation Results view and all five Optimization Results views — every one of them on the Optimization Results tab. Field-by-field breakdown at Data model 12 in detail; uploadable and mappable on the Data tab since 9 Sep 2026. Lives outside Overview 2 — no Overview 2 widget consumes it yet.
12.1	Bond sources (internal)	Where each bond in a run comes from inside the firm — one row per sourced line: the desk and portfolio it is drawn from, whether it is moving into the collateral pool or back out to the desk, how much, the window it is held for, and what that funding costs.	Modeled	The Internal sources of bonds table that leads the Optimization Results screen (US11.16). Uploadable and mappable on the Data tab; when mapped it replaces the rows the run derived.
12.2	Bond destinations (postings out)	Where each bond in a run is posted to — one row per movement window: the agreement type it covers, where it settles, whether it is going out or being recalled, how much, the settlement date and end date the agreements in that window share, and what it costs there. One agreement type can appear on several rows for one bond, because the firm’s agreements of that type were not all papered together.	Modeled	The Where the bonds are posted to table that leads the Optimization Results screen (US11.16). Uploadable and mappable on the Data tab; when mapped it replaces the rows the run derived.
13	Optimization exclusions & exceptions	Everything a run held out and every data problem behind it — one row per exception, in four categories: inventory lines the run’s rules removed from the pool, margin calls and agreements its scoping rules kept out, obligations it could not fully cover, and missing or invalid values in what it read. Shortfall rows also carry what was needed, what was covered, what is short, and the eligibility terms that blocked it.	Modeled	Live on the Rules engine’s ⚠ Exceptions view (see US11.7) and on the Optimization Results 05 Shortfall board. Field-by-field breakdown at Data model 13 in detail; uploadable and mappable on the Data tab since 9 Sep 2026. Lives outside Overview 2 — no Overview 2 widget consumes it yet.
14	Collateral used data	The individual collateral lines posted out (Delivered) or received and held (Held) against each agreement — for each line: the instrument (its ISIN, or for cash the currency), the amounts in the original booking currency (par, market value, and collateral value after the haircut), the dates (posting, valuation, maturity), the agreement and counterparty, the haircut, and the reporting-currency (USD) conversion. This same line-level data also underpins the bonds-vs-cash split and the available / allocated / unallocated views.	Modeled	Also read by the Rules engine when Sweep the deck is off (US11.8): its Delivered rows are what a top-up run keeps in place and nets off each obligation, and what a Sweep-ON run has to recall — which is what Where the bonds are posted today lists (US11.16a). The line-level records behind the Bond postings blotter and the Overview Asset Holdings Summary — the full column dictionary is the collateral-used column dictionary below. Also rolled up into daily book records (data models 10 & 14 — the day's total posting amount and its bonds-vs-cash split) plus each posting's available / allocated / unallocated amounts (data model 14), to drive Posted / Allocated / Unallocated and the Key figures.
15	Inventory data	The pool of collateral we hold and can post — each line's identity, economics, portfolio, business line, clearer, Holding (Internal / External-held / Received) and its held window (a start date and end date, with the amount held varying day-to-day in between). One shared book (one shared inventory data file that feeds both this screen and the Inventory Manager) feeds both screens, so they never differ.	Modeled	Inventory Manager (Requirements 1 · Epic 10) + the Rules-engine inventory (both load the shared module); the postings blotter (data model 14) is the Overview 2 view onto it.
16	MX Trades Data	The individual trades that add up to an agreement's mark-to-market. One row per trade: its reference, the product traded, when it was traded and when it matures, the notional and the currency it is in, and what it is marked at in US dollars.	Partial	The agreement detail pop-up's Trades tab (Requirements 1 · Epic 6). Added 21 Aug 2026 — the pop-up was showing trade figures that traced to no data set.

Gap highlight (declared but not yet consumed by any Overview 2 widget): sets 3 Holiday calendars and 9 Benchmark interest rates are on the master list but no current Overview 2 widget reads them (both are placeholder reference data). They stay listed so the slot is reserved. (Sets 2 Bond/securities static, 4 Portfolios static, 11 Optimization rules, 12 Optimization outputs and 13 Optimization exclusions & exceptions are now read by the Rules engine widget — via its Bond static data, Portfolio static, scoping-rules, output and exclusions inputs.)

Standing lineage rule: every Overview 2 widget must draw its data from a set in this catalog.

Whenever a widget is added or changed, its data must trace back to one of the 15 sets — if a widget would need data that is not on this list, that gap must be raised with the product owner and added to the catalog before it is built, rather than introducing an off-catalogue data source silently.

The “Widget → data & logic lineage” table below and the matching matrix on the UAT test cases · Overview 2 tab are kept in step with this list.

Uploading your own data (the Data tab). Every set in this catalog can now be fed with real production data from the Data tab: upload a file for the set, map each demo field to a column in your file, and switch the app to Production data (see Requirements 1 · Epic 19). This does not change any set’s Status above — Status describes what the built-in demo models; your upload replaces the demo source rows for that set at run time without changing how any figure is worked out. Two sets are wired live today (8 · Market data FX rates and 15 · Inventory data); the other mappable sets accept an upload + mapping now and are connected as each is wired.

Where to find each data model in detail

The 15 data models above are the master list. Eight of them are big enough to need a record-by-record breakdown, and those breakdowns follow below — each one says which data model it belongs to, so there is only ever one set of numbers to keep track of.

Data model	What its detail section covers
6 · Agreements static	Two breakdowns: the 7 agreement types (the rows in the Agreements widget, with the dials that generate each one), and the individual agreements beneath each type — 100 numbered agreements for each of the six coded types, and for Triparty the counterparties handled by each agent.
10 · Exposures & margin calls and 14 · Collateral used data	The daily book record — one point per type per day across the 1,100-day history. This is what drives every chart and every dollar figure on the screen.
14 · Collateral used data	Two breakdowns: the posting row behind the Bond postings blotter, and the column-by-column dictionary of a collateral line, with a worked example that ties out end to end.
12 · Optimization outputs	The proposed movement a run produces, column by column — one row per movement, with what is on the file, what is read from the other files by reference, and what the screens add up for themselves.
13 · Optimization exclusions & exceptions	The exception row, column by column — the four categories, the reason column the set exists for, and the seven shortfall columns that are filled in on the not-fully-covered rows only.
1, 2, 5 & 8	The reference / look-up tables — exchange rates, threshold cushions, funding sources, bond types to sector, and the G7 industry groups.

Two things that are not data models, so they are documented elsewhere: the figures the screen works out for itself (Posted / Exposure / Allocated / Unallocated and the nine Key-figures cards) are nothing to do with stored data and live under Checks that span more than one widget; and the saved workspace layout (your widgets, links and filters, kept in your browser) is a storage detail, covered in the Developer build detail at the end.

Data model 6 in detail · The 7 agreement types

How to read this table: the Field column names each piece of data in plain words; the last column explains what it means.

A few of the fields are “generation dials” — the settings that decide how this type’s sample numbers are made up for the demo (there is no live feed).

The Typical values column shows the range those settings sit in.

Field	Type	Typical values	What it means (plain English)
Type code	text (unique)	bim · bvm · gmra · gmsla · ccp · fut · tri	The short code that identifies the type.
Short name	text	“GMRA”, “Bilateral CSA IM”	The short name shown as the row label in the Agreements widget.
Full name	text	“GMRA — Repurchase”	The longer descriptive name.
Reporting currency	a currency	USD · EUR · SGD	The currency this type reports in; every figure is converted into it using the FX rates.
Colour	a colour	green, blue…	The colour of the dot shown beside the name.
Sub-accounts	a list	Euroclear & Clearstream · or a single book	The sub-accounts a type is split into (e.g. two custodians). Only the ones switched on are added into the totals.
Threshold cushion	$ millions	0 · 12 · 18 · 25	A cushion amount (in $ millions) that is added on top of what’s owed when working out Exposure.
Starting size	$ millions	about $150m–$520m	Generation dial. How big this type is at the start of the ~3-year history.
Day-to-day jiggle	small setting	low … high	Generation dial. How much the daily amount moves up and down from one day to the next — a bigger setting means a choppier line.
Yearly growth trend	a percentage	about 1%–10% a year	Generation dial. The steady yearly growth trend — how much the type grows over a year.
How well covered	a ratio	0.42 … 1.22	Generation dial. How much collateral is posted compared with what’s owed: 1.00 = exactly covered, 1.22 = 22% over-posted, 0.93 = 7% short, 0.42 = less than half of it posted. The agreements are spread across that range on purpose, so every situation appears somewhere. Those are: over-posted with collateral left over; exactly covered; a small call outstanding; and a call so large that everything posted still does not meet it.
Target bond share	a percentage	20% … 100%	Generation dial. The target share of the posting that is bonds rather than cash (20% = aim for one-fifth bonds).
Seasonal cycle (timing & strength)	two settings	peak month · swing size	Generation dials for the yearly cycle: one sets which month of the year the cycle peaks; the other sets how strong that up-and-down seasonal swing is.
Received vs owed	a ratio	1.05 … 1.13	Generation dial. How much inbound collateral is received compared with what’s owed (1.10 = 10% more received than owed).

The full per-type value tables are listed under US9.15 (the agreement book) and US9.16 (the generation dials). Triparty is left out of the combined “All agreements” total.

Data model 6 in detail · The individual agreements under each type

Each type is made up of individual agreements — the rows you see when you drill into a type. Each field below is described in plain words.

Six of the seven types are made up of 100 numbered agreements. Triparty is different, and deliberately so: triparty business is not booked under standalone agreement codes. The collateral sits with a triparty agent — Euroclear, Clearstream or BNY Mellon — and each agent administers the counterparties whose collateral it holds. So the rows under Triparty are those counterparty names (111 of them, each belonging to exactly one agent), never “TRI-001 / TRI-002” style codes. Which agent handles a given counterparty is fixed and the same on every load.

“Decided by a fixed rule based on the agreement name” means the demo always makes the same choice for the same agreement on every load — it is worked out from the name, not re-rolled each time.

Field	Type	What it means & how it is set (plain English)
Agreement name	text (unique)	For the six coded types: the agreement’s account code, numbered 001–100 within its type — for example BIM-001 to BIM-100. For Triparty: the counterparty’s name — for example Brackwater Bank, Upperby Bank, Verdance Capital.
Triparty agent	text (Triparty only)	Which of the three triparty agents — Euroclear, Clearstream or BNY Mellon — administers this counterparty. Every Triparty counterparty belongs to exactly one agent; the six other types leave this blank. Roughly a third of the counterparties sit with each agent, decided by a fixed rule based on the counterparty name.
Share of the type	a percentage	How big this one agreement is within its type. For the six coded types: each of the 100 agreements is given an amount, and then all 100 are scaled so that together they add up to 100%. For Triparty: a counterparty’s share is measured inside its own agent’s book — the counterparties of one agent add up to 100% of that agent — and to place it in the whole Triparty book that share is multiplied by the agent’s share of the book. Either way, that share is what shrinks the agreement’s Posted / Allocated / Unallocated down from the whole type’s figures.
Zero-interest?	yes / no	Marks the agreement as zero-interest. It is not held on the agreement. It is true when the user has tagged that agreement Zero-interest CSA on the Special agreements screen. Nothing is zero-interest until somebody says so.
Had a margin call in the last 14 days?	yes / no	Marks that the agreement had a margin call in the last 14 days. About 30% (3 in 10) do, again decided by a fixed rule based on the agreement name. The number of these within a type is the orange (N) badge.
Call status	one of three fixed labels	Where this agreement has got to in the margin-call process, and what the Margin Calls view’s count tiles count. Every agreement carries exactly one of three: Pending Review (about 2 in 10 agreements), Margin Request Confirmed (about 4 in 10) and No Call Required (the remaining 4 in 10). Which one an agreement gets is decided by a fixed rule based on its name, so the same agreement always shows the same status on every load. When a whole agreement type is shown as one row, it takes the most urgent status found among its agreements — Pending Review outranks Margin Request Confirmed, which outranks No Call Required. To check the tiles: count the rows in each status on the Margin Calls table; each count tile must equal its own status’s row count, and the three counts must add up to the number of rows shown.

Data models 10 & 14 in detail · The daily book record (per type, per day — the day-by-day history that drives every figure)

For each type there is one record per day for the last ~3 years, and these day-by-day records drive every chart and every dollar figure. Each row below is described in plain words.

A “small random wobble” just means the value is nudged up or down by a small random amount each day so the line isn’t unnaturally smooth.

Field	Type	How it is worked out each day (plain English)
Date	a calendar date	One row per day for the last 1,100 days (about 3 years), from the start date up to the anchor “today” (18 Jun 2026).
Obligation (what’s owed)	US$ amount	What the type owes / needs covering that day. It starts from the type’s normal size grown by its yearly trend, then is nudged by the season, a slow multi-year wave, the day of the week, and month-end / quarter-end spikes; it is never allowed to fall below 35% of normal.
Total posting	US$ amount	The collateral posted that day: what’s owed multiplied by the cover ratio, then nudged up or down by up to 3%.
Bonds posted	US$ amount	The bond part of the posting: the day’s total posting multiplied by that day’s bond share.
Cash posted	US$ amount	The cash part of the posting: whatever is left after the bonds.
Received (inbound)	US$ amount	Inbound collateral received that day: what’s owed multiplied by the received factor, then nudged up or down by up to 2%.
Bond share for the day	a percentage (5%–99%)	The share of the posting that is bonds on that day; it gradually drifts toward the type’s target bond share.

Data model 14 in detail · The posting row behind the Bond-postings blotter

Column group	Columns it contains
Postings / Bonds-Maturing columns	Agreement Name, Trade #, ISIN, Security, Type (bond type), Sector, Counterparty, Agreement Type, Custodian, Source (funding source), Start date, Maturity, Maturing in Days, then the five amount fields — Original Ccy, Original Amount (what was posted, in the instrument’s own currency), Posted (USD) (the same posted amount in US dollars), Allocated (USD) (the part of it TMO used), Unallocated (USD) (Posted minus Allocated).
Summary / Detailed (per-agreement) columns	Agreement, Total exposure, Call/obligation, Received (in), Margin call, Total posting, Bonds (Posted), Cash (Posted), Total allocated, Bonds (Allocated), Cash (Allocated), Unallocated (= Total posting − Total allocated), Surplus (= Total allocated − Margin call), DoD/WoW/MoM total allocated, Threshold, Expected post, Expected collect. Detailed (individual-agreement) level only, in addition: ITM/OTM Exposure, Dispute Value, Dispute Age, Base CCY, Base Total Exp., Base Call Amt.
Margin Calls columns	The Daily Exposure Report fields + 5 KPI tiles (Total Margin Call, Pending Review, Confirmed, No Call, Disputes).

These column sets are identical to the Overview dock — full definitions live on the Requirements 1 tab (Epic 2). They are listed here so the data inventory is complete.

Data model 14 in detail · Collateral used data — the line-level records, column by column

What this is, in plain terms: the Collateral used data set is the list of individual collateral lines — each bond or cash amount that has been posted out to (Delivered) or received and held from (Held) a counterparty under an agreement. One row = one collateral line.

The same bond can be posted to the same agreement (or the same triparty agent) more than once — on different dates and for different amounts. Each of those is its own collateral line with its own Trade # and Start date, and the Postings view lists them all. The Postings by bonds view is the pivot of exactly this: it aggregates by bond, so those lines become one row whose Original Amount, Posted (USD) and Allocated (USD) are the sums of the lines and whose Start date is the earliest of them. In the demo book 5 of the 38 bond postings are second postings of a bond already posted to the same agreement, so the aggregation is visible on screen — for example bond SGTAEZ1GFSY0 (MAS BILL 4% 05/27) under Triparty · BNY Mellon: two lines, $19.7M posted from 29 Sept 2025 and $16.0M from 19 Mar 2026, which Postings by bonds shows as one row of $35.7M starting 29 Sept 2025.

The Where it comes from column tags every field as one of three things: referenced from one of the other 16 data sets (and it always matches that set), captured on the collateral line itself (this set's own data), or worked out from the other columns on the same line.

The right-hand column carries one fully worked example line so every figure can be checked end to end. A ⚑ marks a field the product owner still needs to confirm.

Values are illustrative demo data.

Column	What it means (plain English)	Where it comes from	Worked example line
Agreement Name	The individual agreement this collateral line belongs to.	Referenced from Agreements static (set 6) — the individual agreement's name.	GMRA-001
Trade #	The reference your system issues for this collateral line — the number you would quote to look the posting up. Every line has its own; where one posting is settled in two parts, each part carries its own Trade #.	Captured on the collateral line itself (this set's own data). The demo makes one up so the screen has something to show; in the real system it comes from your file.	TRD-600001
Position	Whether we delivered this collateral out to the counterparty, or hold collateral we received from them.	Captured on the collateral line itself (this set's own data). Just two possible values: Delivered or Held.	Delivered
Counterparty	Who the collateral is posted to, or received from.	Referenced from Counterparty static (set 1).	Fernhollow Bank
Asset Class	The G7 industry-group classification of the collateral — for a bond, the group its issuer falls in; for a cash line, simply “Cash”.	Referenced from the user-maintained G7 industry group map (set 7.2), applied to the security's bond type from Bond / securities static (set 2).	Government
Agreement Category	The agreement type this line sits under — for example GMRA, GMSLA, Bilateral IM.	Referenced from Agreements static (set 6) — the agreement's category / type.	GMRA
ISIN / Currency	For a security, its ISIN code; for a cash line, the cash currency instead.	The ISIN is referenced from Bond / securities static (set 2); for a cash line, the currency is referenced from Currency static (set 5).	KR103502GA34
Maturity Date	The security's maturity date. Left blank for a cash line.	Referenced from Bond / securities static (set 2).	20/09/2029
Date of Posting	The date this collateral line was posted or received (day / month / year).	Captured on the collateral line itself (this set's own data).	12/06/2026
Valuation Date ⚑	The date the line's values are struck as at — set a few business days after the posting date. ⚑ The exact business meaning is still to be confirmed by the product owner; treated as a placeholder for now.	Captured on the collateral line itself (this set's own data); for now, the posting date plus a few business days.	16/06/2026
Booking Currency	The original currency the collateral is posted in — the instrument's own currency (for example a Korean government bond is posted in KRW). The Par Amount, Booking Market Value and Booking Collateral Value are all in this currency.	Referenced from Bond / securities static (set 2) — the security's denomination currency; for a cash line it is the cash currency itself (Currency static, set 5), the same as the ISIN / Currency column.	KRW
Par Amount	The face (nominal) amount of the security posted, in its Booking Currency.	Captured on the collateral line itself (this set's own data).	2,643,000,000
Booking Market Value	The market value of the line in its booking (instrument) currency.	Captured on the collateral line itself (this set's own data).	2,626,523,538
Booking Collateral Value	The value the collateral is credited at after the haircut, still in the booking currency — the market value reduced by the haircut.	Worked out from this line: the Booking Market Value taken down to the Haircut percentage of itself (here 92, i.e. 92% of the market value).	2,416,401,655
Haircut	The percentage of market value the collateral is allowed to count for. 100 means no haircut; less than 100 means a discount (92 = an 8% haircut).	Referenced from Agreements static (set 6) — the agreement's eligible-collateral / haircut schedule.	92
Reporting Currency	The single currency every line is reported in, so lines in different Booking Currencies can be compared and added together. Confirmed = USD, set once for the whole Singapore entity rather than carried record by record.	A fixed system reporting setting for the Singapore entity — US dollars (USD); the currency code itself is one of Currency static (set 5).	USD
Market Value (USD)	The Booking Market Value converted from the Booking Currency into the reporting currency (US dollars).	Worked out from this line: the Booking Market Value converted using this line's FX Rate.	1,917,362
Collateral Value (USD)	The Booking Collateral Value converted from the Booking Currency into the reporting currency (US dollars).	Worked out from this line: the Booking Collateral Value converted using this line's FX Rate.	1,763,973
FX Rate	The exchange rate used to convert this line's Booking Currency into the reporting currency — US dollars per 1 unit of the Booking Currency.	Referenced from Market data — FX rates (set 8).	0.00073 (KRW → USD)

Reading the worked example: the line is a Korean-won (KRW) government bond delivered to Fernhollow Bank under GMRA-001 — its Booking Currency is KRW, so the Par Amount and both Booking values are in won.

Its haircut of 92 turns a Booking Market Value of 2,626,523,538 into a Booking Collateral Value of 2,416,401,655 (92% of it). Converting both at the won FX rate of 0.00073 US dollars per won gives a Market Value (USD) of 1,917,362 and a Collateral Value (USD) of 1,763,973.

Every referenced column ties to its source data set; every worked-out column can be re-derived from the other columns on the same line — so a developer can check the whole row without any hidden inputs.

Every column maps to a source (the standing lineage rule): Agreement Name, Agreement Category and Haircut come from Agreements static (set 6); Counterparty from Counterparty static (set 1); Asset Class from the user's G7 map (set 7.2) over Bond / securities static (set 2); ISIN, Maturity Date and the Booking Currency from Bond / securities static (set 2); the cash Currency and the Reporting Currency (a fixed setting = USD) from Currency static (set 5); FX Rate from Market data FX (set 8).

Trade #, Position, Date of Posting, Valuation Date, Par Amount and Booking Market Value are captured on the line itself (this set, #14). Booking Collateral Value, Market Value (USD) and Collateral Value (USD) are worked out from the other columns.

Reporting Currency = USD and Booking Currency = the instrument's original posting currency are confirmed (the reporting currency is one setting for the whole Singapore entity, re-confirmed 26 Aug 2026); one item stays flagged (⚑) for the product owner: the exact business meaning of Valuation Date.

How the bond-postings blotter's five amount fields map onto this dictionary: Original Ccy is the Booking Currency; Original Amount is the Booking Collateral Value (the posted, after-haircut amount in that currency); Posted (USD) is the Collateral Value (USD) — the same amount converted at the line's FX Rate; Allocated (USD) is the part of Posted (USD) the collateral team used against the agreement's margin requirement; Unallocated (USD) is Posted (USD) minus Allocated (USD).

🔧 Developer build detail — Collateral used data formulas & worked example (expand only if you are building the app)

Booking Collateral Value = Booking Market Value × Haircut ÷ 100.
Market Value (USD) = Booking Market Value × FX Rate (US$ per 1 unit of the booking currency).
Collateral Value (USD) = Booking Collateral Value × FX Rate.
Valuation Date = Date of Posting + N business days (N provisional — business meaning to be confirmed).
FX Rate source: the FX feed (set 8). The app currently models five rates (the reference / look-up tables) — USD 1 · EUR 1.08 · GBP 1.27 · SGD 0.74 · JPY 0.0064 (US$ per 1 unit); set 8 is a Partial set and must carry a rate for every Booking Currency present in the collateral data. The example line's Booking Currency is KRW, converted at a dummy 0.00073 US$ per KRW.
Worked example (ties out): Haircut 92 → 2,626,523,538 × 0.92 = 2,416,401,655. FX 0.00073 (KRW → USD) → 2,626,523,538 × 0.00073 = 1,917,362 and 2,416,401,655 × 0.00073 = 1,763,973.

Data model 12 in detail · Optimization outputs — the proposed movements a run produces

What this is, in plain terms: when the rules are run, the answer is a list of movements — “deliver this security against that agreement”. This data set is that list. One row = one proposed movement. It is what the Optimisation Results view and all five Optimization Results views read — every one of them on the Optimization Results tab.

Where the rows come from. Today the app works the run out itself from three files it already has — the securities and inventory it can post (data sets 2 and 15), the agreements and what each will accept (data set 6 and its eligibility schedule 6.1), and what each agreement owes (data set 10). If your own optimiser works the run out instead, you upload its answer as this data set on the Data tab and map each column, exactly as for any other set.

What this file deliberately does not carry. The row names the security by its code only. What that security is — its name, issuer, coupon, rating — is read from the securities file, and which portfolio and holding it sits in is read from the inventory file. Who the counterparty is comes from the agreement. The rule is the standing one for this whole application: the identifier travels on every file, the description is held once.

The run’s headline figures are not on the file either. Annual carry, the saving against posting all cash, how much of the requirement is covered and the blended funding cost are all added up from these rows against what the agreements owe. They are worked out when the screen is drawn, so no run can ever show two different answers for the same total.

Values are illustrative demo data.

Column	What it means (plain English)	Where it comes from	Worked example row
Run ID	The reference of the run this movement belongs to. Every row of a run carries the same one, which is how a proposal is filed, re-opened and argued against later.	The run itself. The Optimization Results run bar prints it.	Modeled
Run date & time	The moment the run was put through the optimiser. A proposal is only as good as the book it was worked out on, so this says which.	Stamped when the run is run; printed beside the Run ID.	Modeled
Agreement	The individual agreement this movement covers — its own reference, not the kind of contract it is. Triparty is named by its counterparty, because it is never booked under a standalone agreement code.	The margin obligations one level down (data set 10).	Modeled
Expected margin call	What that individual agreement expects to be called for. It belongs to the agreement, so it reads the same on every bond posted to it and is never added up down the file.	The obligation’s own requirement.	Modeled
Settlement date	When the margin call has to be settled — the day the collateral must be with the counterparty. Today plus that agreement’s own settlement days.	Worked out from the agreement’s settlement terms.	Modeled
ISIN	The code of the security to deliver. For a cash line this is the currency instead.	Referenced from Bond static (data set 2).	Modeled
Collateral amount	How much of that security is being delivered, at today’s market price, in millions of US dollars.	What the run proposed for that agreement.	Modeled
Start date	When the proposed repo of the collateral begins — the day it goes out. It is the settlement date, because the repo starts when the collateral is delivered.	Derived from the settlement date.	Modeled
End date	When that repo ends and the collateral is due back. It is the earlier of the agreement’s own end date and the day the firm’s holding of the bond itself ends — a bond cannot be committed for longer than it is held, nor to an agreement after it has expired.	Derived from the agreement terms and the inventory line.	Modeled
Source	Where this collateral is coming from, so the movement can actually be instructed. Either Desk and the portfolio it is borrowed fresh from, or Recall and the agreement it has to be called back from. A movement that takes from both names both. What is already posted out comes back first; the desk lends only the rest.	Worked out from the inventory line and the existing postings (data set 14).	Modeled
Cost of funds	What it costs to fund this security for a year, in basis points, after the agreement’s haircut is taken off it.	Cost of funds (data set 7.1) grossed up by the haircut.	Modeled

Accepted / On hold / Rejected is not on this file. That is the decision a person takes on the Approval blotter after reading the proposal, so it is never uploaded. It lives only for as long as the screen is open, and re-prices the release the moment it changes.

What is left out of the totals. A movement marked Rejected is dropped from every figure on the results screens; one marked On hold is dropped from the accepted totals but still counted in the on-hold tally. Nothing is deleted from the file.

Still with the product owner: the run reference appears on this file and on the exceptions file (data set 13) and both call it the same thing. Which of the two is the master list for a run needs naming, so every other file carries it only to point back at that run.

Data model 13 in detail · Optimization exclusions & exceptions — what a run held out

What this is, in plain terms: a run does not use everything it is given. It leaves inventory out because a rule says so, it leaves agreements and margin calls out because they fall outside what the run was scoped to, it runs out of eligible collateral before some obligations are filled, and it meets data it cannot use. This data set is the list of all four. One row = one exception. It is what the Rules engine ⚠ Exceptions view and the Optimization Results 05 Shortfall board read.

Four categories, one file. Every row says which category it belongs to, and the four are: inventory held out by the run’s rules; margin calls and agreements held out by the same rules; obligations the run could not fully cover; and missing or invalid values in what the run read.

A data problem is one row, not one row per record. A book with five thousand lines missing the same thing is one exception affecting five thousand records, not five thousand exceptions. The Records affected column carries that count. The other three categories are one row per record, because each record was held out for its own reason.

The last seven columns are filled in on the not fully covered rows only, because they describe an obligation. On the other three categories they are blank.

Values are illustrative demo data.

Column	What it means (plain English)	Where it comes from	Worked example row
Run reference	The run that raised this exception. The same reference the proposed movements carry, so a run and everything it held out stay together.	Captured on the run itself (this set’s own data). Required.	RUN-01
Exception category	Which of the four kinds of exception this row is. Exactly four values: Inventory held out · Calls and agreements held out · Not fully covered · Missing or invalid values.	Captured on the exception itself (this set’s own data). Required.	Inventory held out
Record reference	What the exception is about, named the way that kind of record is named: a trade reference for an inventory line, a margin-call reference or an agreement name for a held-out obligation, the agreement name for something not fully covered, and the field name for a data problem.	Referenced from whichever file owns that record — the inventory, the margin calls, the agreement book. Required.	TRD-600001
Record name	The record in words, so a reader recognises it without looking it up: the instrument for an inventory line, the counterparty for an obligation, or what is missing for a data problem.	Referenced from the file that owns the record.	FRANCE OAT 1.25% 06/27
Record detail	A one-line description of the record as it stood when the run held it out — enough to tell two similar records apart on the screen.	Referenced from the file that owns the record, read at the moment of the run.	Govt · AA · SG Rates Trading · $41.2M
Why it was held out	The reason, in plain words: which rule removed it, or what is wrong with the value. This is the column the whole data set exists for.	Worked out by the run, from the rule that fired.	Portfolio is not in the run’s included list
Records affected	How many records this one problem affects. Filled in on the missing-or-invalid-values rows; blank on the others, where each row is already one record.	Worked out by the run.	12
Amount needed	What the agreement had to cover, in millions of US dollars. Not fully covered rows only.	Referenced from Exposures & margin calls (data set 10).	312.0
Amount covered	How much of it the run managed to cover, in millions of US dollars. Not fully covered rows only.	Worked out by the run, adding up the collateral value of the movements it proposed for that agreement.	286.4
Amount short	What was left uncovered — the needed amount less the covered amount, in millions of US dollars. Not fully covered rows only.	Worked out by the run, from the two columns above.	25.6
Collateral types accepted	What that agreement will take as collateral. Shown on the shortfall row because it is usually the reason the pool was too small. Not fully covered rows only.	Referenced from the agreement eligibility schedule (data set 6.1).	Cash/Govt
Minimum rating accepted	The lowest credit rating that agreement will accept. Not fully covered rows only.	Referenced from the agreement eligibility schedule (data set 6.1), taken together with the margin call’s own rating floor — whichever is stricter.	A
Eligible issuer groups	The kinds of issuer whose paper that agreement will accept — sovereigns, supranationals, agencies, financial institutions, corporates. Not fully covered rows only.	Referenced from the agreement eligibility schedule (data set 6.1), read against the user-maintained G7 industry group map (data set 7.2).	Sovereign/Supranational
Eligible lines that qualify	How many inventory lines survive that agreement’s own eligibility test, out of the ones the run’s rules left in play. The smaller this number, the harder the obligation is to fill. Not fully covered rows only.	Worked out by the run.	2

The three exclusion lists are not this data set. The rules that hold records out live in Optimization rules (data set 11, set on the Rules engine tab); the Special-agreements list lives in the user-maintained data (data set 7.4); the per-line Ignore switch is a choice made on the results screen. This data set is what those three produced on a given run — the record of what was actually left out, and why.

Where it is shown. The Rules engine ⚠ Exceptions view shows all four categories, one section each, with a count on every section and the first hundred rows of each listed (the true total is always stated). The Optimization Results 05 Shortfall board shows the not-fully-covered category on its own, sorted with the largest shortfall first.

Data models 1, 2, 5 & 8 in detail · The reference / look-up tables

Look-up table	What it holds
FX (USD per 1 unit)	USD 1 · EUR 1.08 · GBP 1.27 · SGD 0.74 · JPY 0.0064.
Thresholds ($mm, per type)	bim 0 · bvm 0 · gmra 12 · gmsla 18 · ccp 0 · fut 0 · tri 25.
Funding sources (7)	Interbank Repo · Flow Reports · HQLA · MI · CT · LMM · LRP (overridable by the user’s Source-of-collateral rules).
Bond types (5) → sector	SGS/UST → SOVGN (sovereign / government) · Supra/Agency → PBSEC (public-sector & agency) · Corporates → CORPO (corporate).
G7 industry groups	From the user’s G7 industry-group map; every bond is matched to a row of it on Issuer Industry, and a bond that matches no row takes the last row — the catch-all where every column is the default; drives “By bond type”. (The exact override keys are in the Developer build detail.)

🔧 Developer build detail (technical — the exact saved-layout structure, seeds & grid constants; expand only if you are building the app)

Persisted data structure — localStorage["collat-workspaces-v2"]

{
  active:  "<wsId>",                       // currently open workspace
  order:   ["ws-1", "ws-2", …],           // tab order
  ws: {
    "ws-1": {
      name: "Workspace 1",
      seq:  3,                             // instance counter
      instances: [                         // one per widget on the canvas
        { iid:"agreements-1", type:"agreements|charts|dock|rules|inventory",
          x:0, y:0, w:4, h:14,             // grid rect (12-col grid)
          pinned:false,
          soloDim:"time|agreement|source|type",   // charts widget only
          link:{ color:"blue|green|amber|purple|pink|teal|null",
                 role:"emitter|receiver" }        // role is FIXED by type
        }
      ],
      groupSel:    { "<color>": { level:"all|type|indiv", key, account, weight } },  // each emitter's pick
      groupFilter: { "<color>": { gran:"daily|monthly|yearly", fromMs, toMs, refMs } } // each emitter's filters
    }
  }
}

Widget instance = {iid, type, x, y, w, h, pinned, soloDim, link:{color, role}}. role is always coerced to the type’s role on load (coerceRolesByType()); orphaned receiver colours are cleared (pruneOrphanReceivers()).
Colour set (6): blue #3b82f6 · green #22c55e · amber #f59e0b · purple #a855f7 · pink #ec4899 · teal #14b8a6.
User-maintenance override keys read at load (shared with Requirements 1): collat-source-rules · collat-g7-map · collat-csa-list · collat-agreement-names · collat-exposure-adjust · collat-inventory-adjust.

Constants & seeds (determinism)

Time anchor: TODAY = 18 Jun 2026 UTC · START = TODAY − 1100 days · MS_DAY = 86400000.
Seeds (the fixed starting numbers that make the demo produce the same figures every load): book time series 424242 · bond inventory 20260618 · per-agreement weights 2000 + ai·131 · individual agreements 8800 + ai·1337.
Grid constants: COLS=12 · ROW=34 · GAP=6 · MINW=2 · MINH=2; row pitch 40px; column width = canvas width ÷ 12.

🧩 What I can do in Overview 2 — the user stories

Each story below is one thing you can do, told in your own words (“As a user, I can …”), followed by the plain rules the app follows so it behaves that way. Read straight down — there is no technical detail here; the formulas are all kept in the collapsed Developer build detail section at the very end.

The stories are grouped: first the canvas itself (adding, arranging, linking widgets), then one section per widget — Agreements, Collateral charts, Bond postings — and finally the Key figures strip that rides on two of them.

There are five widget types (Agreements, Collateral charts, Bond postings, Rules engine, Inventory Manager) plus a Key figures strip that rides on top of two of them. The Rules engine and the Inventory Manager are both Standalone, single-instance widgets — each embeds a whole existing tool (the Rules engine embeds the Rules engine tab, §11; the Inventory Manager embeds the Inventory Manager tab, §10) and takes part in every canvas behaviour below (add, move, resize, pin, close, persist), but neither joins a colour group, so neither has a chain icon and neither drives nor follows the Agreements emitter.

Every widget carries the same handles: a ⋮⋮ grip to drag it, a chain icon to link it into a colour group, a 📌 to pin it, a ✕ to close it, and a bottom-right corner to resize.

Each widget section ends with a “What this widget shows” table: for every field it gives what it shows, how it is worked out, and which numbered Data source catalog set it draws from.

Fields marked “control” are things you operate rather than figures, so they have no data source. The one-row-per-widget Widget → data & logic lineage table above is the at-a-glance summary of the same mapping.

🧩 Building your workspace — canvas & workspaces

These four things are about the canvas itself: adding the widgets you want, arranging them on the grid, keeping several workspaces, and wiring widgets together into colour groups so one drives the others.

US9.1 As a user, I can add widgets, add the same widget again, and close them from the palette so I compose the workspace from the widgets I want.

Functional requirements

Add a widget. The left “Add widgets” palette lists every widget type (Agreements, Collateral charts, Bond postings, Rules engine, Inventory Manager), each with a ＋ button. Adding a widget creates a new instance placed on the grid below the existing widgets, compacted up into the first free space, and it renders its content immediately.
Multiple independent instances. A widget type can be added many times; each instance is fully independent (its own content, position, size, pin state and colour link). Exception: Bond postings, the Rules engine and the Inventory Manager are single-instance widgets (shown as “(single)”) — at most one of each per workspace, and its palette row is disabled while one exists.
Close a widget. Every widget header carries a ✕ (“Close — remove from this workspace”). Closing removes that instance and the remaining widgets compact up to fill the gap; closing a single-instance widget re-enables its palette row.

US9.2 As a user, I can move, resize and pin widgets on a collision-aware grid so the layout reflows and widgets never overlap.

Functional requirements

Move. A widget is dragged by its header bar (the ⋮⋮ grip + title; “move” cursor). While dragging it rises above the others (raised shadow + accent border) and snaps to the underlying 12-column grid, clamped to x,y ≥ 0. A pointer-press on a button/input inside the header does not start a drag.
Resize. A widget is resized from the handle at its bottom-right corner (diagonal hatch, “nwse-resize” cursor, “Drag to resize”), in whole grid steps down to a minimum of 2 columns × 2 rows; its charts re-render live to fill the new size.
Pin. The 📌 header button (“Pin — lock this widget’s position & size”) locks a widget’s position and size — it shows an accent border, cannot be moved or resized (its resize handle is hidden), and acts as a fixed obstacle other widgets flow around. 📌 again unpins it (“Unpin — allow this widget to move & resize”).
No-overlap reflow. On every move, resize or add, any widget the active one lands on is pushed down and all unpinned widgets then compact upward into free space, so no two widgets ever overlap. Pinned widgets and the widget being dragged are never moved by the reflow.

US9.3 As a user, I can keep multiple workspaces and have everything persist & reset so my layouts survive refresh and I can start over per workspace.

Functional requirements

Multiple workspaces. Workspaces are top tabs, each holding an independent set of widgets and layout: ＋ adds a new (empty) workspace, single-click switches, double-click renames inline (Enter commits, Escape cancels), and ✕ closes. There is always at least one workspace (the last remaining tab has no ✕).
Persistence. Every workspace — its widget instances (type, position, size, pin state, colour link, and the Collateral-charts selected dimension) together with the active workspace — is saved automatically to your browser and restored exactly when you refresh or re-open the page (the exact storage key is in the Developer build detail).
Reset layout. The ⟲ Reset layout control lives on the Agreements control-panel widget (in its filter panel, beside ✕ Clear) — not the top toolbar. It unpins and re-tiles the current workspace’s widgets to their default sizes in a tidy stack; widgets and links are kept, not deleted.

US9.4 As a user, I can link widgets into colour groups where an Emitter broadcasts to same-colour Receivers so charts & blotters follow a control panel, with roles fixed by widget type.

Linking — emitter / receiver colour groups

Each widget’s role is FIXED by its type — it is never a user choice. Agreements is always an Emitter (⬆), the Collateral charts and Bond postings widgets are always Receivers (⬇), and the Rules engine and Inventory Manager are always Standalone (they neither emit nor receive, so they have no chain icon at all).

The top-right chain icon therefore does not let you pick a role — it only sets which colour group the widget joins (under its fixed role), or Standalone (unlink).

A widget’s chain popover shows its role as a read-only label (“Emitter ⬆” / “Receiver ⬇”), then the colour swatches, then Standalone.

Emitters broadcast the agreement they show and their filter panel to every Receiver on the same colour group. This is one Emitter per colour, with any number of Receivers on that same colour; two Emitters can never share a colour, and different colour groups are independent.

A colour group only exists while an Emitter is present on it — see the two rules below.

Rule A — a Receiver only follows a colour that has a live Emitter. A receiver renders group data only when an Emitter widget is currently present on its colour.

If a receiver is linked to a colour with no emitter in the workspace (or its emitter is later closed / moved to another colour), the receiver reverts to no data: the Collateral charts widget shows its placeholder; other receivers fall back to the workspace’s global default.

There is no “phantom” group data from a colour that has no emitter. The receiver also stops showing as linked: its coloured outline and chain icon revert to the standalone look (🔗) and the now-orphaned colour is dropped from its link — a widget only ever displays a link to an emitter that actually exists on the workspace.

Rule B — Emitters auto-take a distinct colour; roles are set by type. Because the role follows the widget type, no role step exists.

Adding an Agreements widget makes it an Emitter on the next unused colour automatically (blue is taken by the default workspace, so the 2nd Agreements becomes green, the 3rd amber, …), so two emitters never share a colour; in its chain popover an emitter’s colour swatches are the colours not already used by another emitter (plus its own).

A Receiver (Collateral charts, Bond postings) starts standalone and only renders group data once you link it to a colour; in a Receiver’s colour picker the only swatches shown are colours that currently have an Emitter — a receiver can only bind to an emitter that is actually there.

Layouts saved by an older version (which used to let you pick roles) are corrected automatically when they load, so the roles are always right.

Functional requirements

Set a widget’s colour group (role is fixed by type). The chain icon opens a popover whose Role is a read-only label (“Emitter ⬆” for Agreements, “Receiver ⬇” for Collateral charts / Bond postings) — there are no role buttons. The user picks a colour group swatch or Standalone (unlink). A linked widget gains a coloured outline and its chain icon shows ⬆/⬇ in the group colour; Standalone returns it to the 🔗 look.
Role-aware swatches. A Receiver’s picker offers only colours that currently have an Emitter (empty state: “No emitter groups yet — add an Agreements widget (it becomes an Emitter) first”); an Emitter’s picker offers only colours not already used by another emitter (plus its own). A new Agreements widget auto-arrives as an Emitter on the next free colour, so two emitters never share one.
Emitter broadcasts to same-colour receivers. Picking an agreement on an Emitter re-renders every Receiver on the same colour (an individual agreement scales the type’s figures to its share; a receiver blotter filters to the type). Receivers on other colours and standalone widgets are unaffected; separate colour groups work independently.
A receiver only follows a live emitter. A Receiver renders group data only while an Emitter is present on its colour. If its colour has no emitter (never linked, or the emitter was closed / recoloured) it reverts to no data (Collateral charts → placeholder; other receivers → global default) and stops showing as linked — its outline and chain icon revert to the standalone 🔗 and the orphaned colour is cleared. This self-heals on load, on emitter close, and on any colour change.

🎛️ The Agreements widget — control panel (Emitter ⬆)

The Agreements widget is Overview 2’s control panel and its role is fixed as an Emitter (⬆): it holds the shared filters and the agreement selector, and broadcasts both to every same-colour Receiver.

US9.5 As a user, I can select and drill agreements — All agreements, a type, or an individual agreement so I see each agreement’s posted / allocated / unallocated position and can drive every same-colour Receiver.

It does two jobs at once: it holds the shared filters, and it is the agreement selector you drill through.

Below the filter panel is the agreement list. A single column legend labels the money columns once — Agreement · Posted · Allocated · Unallocated — then the list shows All agreements (the grand totals) and one row per agreement type.

Each row has: a colour dot, the type name, an orange (N) badge (the number of that type’s agreements with a margin call in the last 14 days), the three values Posted, Allocated and Unallocated lined up under the legend, and a › drill arrow. The labels appear only in the legend, not on every row.

How Allocated and Unallocated read: Allocated is the smaller of Posted and the type’s exposure (what’s owed plus its threshold cushion); Unallocated is Posted minus Allocated, shown green when zero or more and red when negative.

Click a type to drill into its individual agreements (e.g. GMRA-001, GMRA-002 …), each showing its share in the same columns; ← Summary returns to the type list. Drilling Triparty lists the counterparties handled by the selected triparty agent(s) (e.g. Brackwater Bank, Upperby Bank …) instead of agreement codes.

What you pick is what the Receivers show, right down to the individual agreement: pick Fernhollow Bank under Triparty and the linked Bond postings widget lists Fernhollow Bank alone — its Agreement column reads the very counterparty you picked — and the Key figures above it are Fernhollow Bank’s. Pick the type row again (or ← Summary, All agreements, ✕ Clear) and the Receivers widen back to the whole type.

Sub-filters — each agreement type has its own

Some agreement types are kept as more than one book, and some carry a flag you may want to narrow by. When you pick a type, its own sub-filter buttons appear immediately underneath that row (they are the same sub-filters the Overview sidebar offers). They are specific to the type — a type that has none shows none:

Bilateral CSA IM — Euroclear / Clearstream: the two custodians its initial margin is held with.
Bilateral CSA VM — Zero-interest only: shows only the CSA VM agreements tagged Zero-interest CSA on User maintenance → Special agreements.
CCP — IM / VM: its initial-margin book and its variation-margin book.
Triparty — Euroclear / Clearstream / BNY Mellon: the three triparty agents its collateral sits with.
GMRA, GMSLA and Futures — none. GMRA and GMSLA are variation-margin only for now (a single book), so there is nothing to split.

The custodian / agent / IM-VM buttons all start switched on (you are seeing the whole book). Click one to leave it out; click it again to bring it back — you can never switch the last one off, so at least one book is always showing. “Zero-interest only” starts off.

What changes when you use one: the type’s own Posted, Allocated and Unallocated figures on that row are re-worked from only the books you left on, its individual agreements are re-worked the same way, and — because this widget is the control panel — every same-colour Receiver (charts, Key figures, Bond postings) re-draws on that narrower book too. Switching “Zero-interest only” on narrows the individual CSA VM list to the flagged agreements only (about one in three). The sub-filter belongs to the agreement type you picked: the other rows keep their whole-book totals, and picking a different type starts that type fresh with every book on and zero-interest off.

(Static Data is not on Overview 2. The Rules engine and the Inventory Manager are now Overview 2 widgets in their own right — they sit in the palette and are covered in this document.)

Functional requirements

Row content & drill. A single legend row labels the money columns once — Agreement · Posted · Allocated · Unallocated. All agreements and each type row then show a colour dot, the name, the (N) active-agreements badge (agreements of that type with a margin call in the last 14 days), and three right-aligned values aligned under the legend — Posted, Allocated and Unallocated (green when zero or more, red when negative; Unallocated is Posted minus Allocated) — with no per-row labels. Selecting a type row drills into its individual agreements (e.g. GMRA-001, GMRA-002 …), each showing its share of the type in the same columns; a “← Summary” button returns to the type list. Triparty is the exception: it has no agreement codes, so its drill list is the counterparties handled by the triparty agent(s) left on (e.g. Brackwater Bank, Upperby Bank …), and the note above the list reads “Triparty — counterparties handled by the selected triparty agent · posting / allocated / unallocated shown”.
Per-type sub-filters. The selected agreement type shows its own sub-filter buttons directly under its row — in the type list and above the individual agreements after drilling in. The sets are fixed per type: Bilateral CSA IM → Euroclear / Clearstream; Bilateral CSA VM → Zero-interest only; CCP → IM / VM; Triparty → Euroclear / Clearstream / BNY Mellon; GMRA, GMSLA and Futures → none. Book buttons (custodian / agent / IM-VM) all start on, toggle on click, and the last one on cannot be switched off. “Zero-interest only” starts off and toggles on click.
What a sub-filter re-works. With one or more books switched off, the type’s Posted, Allocated and Unallocated (and its individual agreements’ figures) count only the books left on, and every same-colour Receiver re-draws on that narrower book. The whole book always equals the sum of its parts — e.g. CCP Posted = CCP IM Posted + CCP VM Posted. “Zero-interest only” narrows the individual CSA VM list to flagged agreements only and leaves the money figures on the full CSA VM book. Rows other than the selected type keep their whole-book totals, as does All agreements.
Scope & reset. The sub-filter travels with the selection: it is remembered per colour group (so two colour groups filter their sub-books independently), it survives a reload with the rest of the workspace, it is kept when the same type is re-selected or drilled into, and it is reset — every book on, zero-interest off — when a different type is picked or ✕ Clear is used.

US9.6 As a user, I can set the shared filters and broadcast them so one widget drives the granularity and date window for its colour group.

The Agreements widget is the control panel for Overview 2. (In widget mode the standard Overview’s top filter bar is hidden, so its controls live here instead.)

At the top sits the filter panel:

Granularity — Daily / Monthly / Yearly.
Quick range — 1M / 3M / 6M / 1Y / 2Y.
From and To date pickers.
Reference-date chip — shows the as-at date with a green ● latest tag (you’re looking at the newest day) or an amber historical tag (you’ve gone back in time).
✕ Clear — resets this group’s agreement selection and reference date.
⟲ Reset layout — unpins and re-tiles every widget back to its default size (this button lives here, not on the top toolbar).

When this widget is linked as an Emitter, its agreement pick and its filters drive every same-colour Receiver; when standalone, its filters drive the workspace’s global default instead.

Functional requirements

The pick carries down to the individual agreement. Whichever level is selected — All agreements, a type, or one individual agreement — is what every same-colour Receiver shows. When it is an individual agreement, the Receiver’s per-agreement tables list that agreement only (Bond postings: the Detailed view, and the Margin Calls view when it is at individual level), so the Agreement column reads the same counterparty or agreement code that is highlighted here, and the Key figures strip above the table scales to that agreement so the cards tie to the row. The bond-level views Postings and Bonds Maturing stay on the whole type — collateral is posted at agreement-type level, so there is no per-counterparty posting line to narrow to. Postings by bonds is the exception, and it is the reason the view exists: it stays empty until one individual agreement (or one triparty agent) is picked, and then lists that agreement’s bonds, each amount being that agreement’s share of the type’s posting. Selecting the type row again, ← Summary, All agreements or ✕ Clear widens the Receivers back.
Control-panel broadcast. When the widget is an Emitter, its agreement selection and its whole filter panel (Granularity, Quick range, From/To, Reference date) broadcast to every same-colour Receiver — the Collateral charts and receiver Bond-postings widgets and the Key-figures strips riding on them — which re-render at that granularity and date window. ✕ Clear resets that colour group’s selection to All and its reference date to latest. Each emitter colour group filters its own receivers independently.

US9.7 As a user, I can see exactly what the Agreements widget shows so I know every field it displays, how it is worked out, and where the data comes from.

As a user, when I add the Agreements widget and pick All agreements, a type, or an individual agreement, then it drives every same-colour Receiver and shows me each agreement’s posted / allocated / unallocated position.

It is the control panel: it broadcasts its agreement pick and its whole filter panel to every same-colour Receiver.

Field	What it shows	How it is worked out	Data set it draws from
Granularity (Daily / Monthly / Yearly)	The time bucket receivers draw at.	Your choice, broadcast to same-colour receivers.	Control (no data set).
Quick range (1M / 3M / 6M / 1Y / 2Y)	A shortcut that sets the From/To window.	Your choice; sets the date window sent to receivers.	Control (no data set).
From / To date pickers	The start and end of the date window.	You set them; they bound every receiver’s figures.	Control (no data set).
Reference-date chip	The as-at date, tagged green “● latest” (newest day) or amber “historical” (stepped back in time).	The newest day in the history unless you step back; drives every “as at” figure and the Week/Week pills.	Data set 10 · Exposures & margin calls (the dated book).
✕ Clear	A reset for this colour group.	Resets the group’s pick to All and the reference date to latest.	Control (no data set).
⟲ Reset layout	A re-tile control (it lives here, not the toolbar).	Unpins and re-tiles the workspace’s widgets to default sizes; keeps widgets + links.	Control (no data set).
Column legend (Agreement · Posted · Allocated · Unallocated)	Labels the three money columns once, above the rows.	Static labels; the rows line up under them.	Control (label only).
Colour dot	The type’s colour beside its name.	The type’s assigned colour.	Data set 6 · Agreements static.
Row label (All agreements + one row per type)	The grand-total row, then the 7 type names.	The 7 type names, plus an All-agreements roll-up that deliberately excludes Triparty.	Data set 6 · Agreements static.
(N) margin-call badge	The orange count beside a type.	The number of that type’s individual agreements that had a margin call in the last 14 days; fixed on every load. For Triparty that is counted over its counterparties.	Data set 10 · Exposures & margin calls.
Posted	Collateral posted for the row.	Add up the collateral posted across the row’s selection; an individual agreement is scaled down by its share of the type.	Data set 14 · Collateral used data.
Allocated	Collateral actually used.	The smaller of Posted and Exposure (Exposure = what’s owed plus the type’s threshold cushion).	Data sets 14 + 10 + 6.
Unallocated	Spare collateral (green) or shortfall (red).	Posted minus Allocated.	Derived from the two rows above.
Sub-filter buttons (under the selected type only)	The sub-filters that belong to the type you picked: Bilateral CSA IM → Euroclear / Clearstream; Bilateral CSA VM → Zero-interest only; CCP → IM / VM; Triparty → Euroclear / Clearstream / BNY Mellon; GMRA, GMSLA, Futures → none.	Book buttons start on and can be switched off one at a time (never the last one); the type’s Posted / Allocated / Unallocated, its individual agreements and every same-colour Receiver are then re-worked from the books left on, and the parts always add back to the whole book. Zero-interest only starts off; switching it on narrows the individual CSA VM list to the flagged agreements.	Data set 6 · Agreements static (the sub-books and the zero-interest flag) — the money is re-worked from data set 14 · Collateral used data.
Drill chevron › / individual-agreement rows	Opens the type’s individual agreements (e.g. GMRA-001…), each with its own Posted / Allocated / Unallocated; “← Summary” returns. Under Triparty the rows are the counterparties handled by the agent(s) left on (e.g. Brackwater Bank…).	Each individual row is the type figure scaled by that agreement’s share of the type (the shares shown add to 100%). For a Triparty counterparty the share is its share inside its own agent’s book multiplied by that agent’s share of the books on show, so the counterparty’s figure stays the same however the other agents are toggled.	Data set 6 · Agreements static (the individual agreement, its triparty agent where it has one, and its share).

📊 The Collateral charts widget (Receiver ⬇)

The Collateral charts widget’s role is fixed as a Receiver (⬇). Unlinked — or linked to a colour that has no Emitter present — it shows a placeholder and no data, and its Key figures strip is hidden.

US9.8 As a user, I can switch between the four charts — Over time, By agreement, By source, By bond type so I view the received selection the way I need.

A segmented toggle at the top of the widget picks which of the four charts is displayed; the choice is remembered per widget instance.

Each chart and how it is worked out is set out in the “What the Collateral charts widget shows” table below.

US9.9 As a user, I can click a chart to drill in or cross-filter so I focus the whole colour group on what I clicked.

Chart clicks drill / cross-filter (source, G7 group, agreement) or set the reference date, with one important limit that applies only on Overview 2. Clicking a By source bar or a By bond type slice switches that cross-filter on or off, and it does so for every widget on the page — these two cross-filters are shared page-wide rather than being confined to one colour group. Clicking an Over time bar or a By agreement bar has no visible effect on a linked chart: a linked widget always redraws from what its Agreements control panel is broadcasting, and that broadcast overrides the click. Known limitation (open, raised 31 Jul 2026): there is currently no way for a chart click to move its own colour group’s reference date or agreement pick — use the Agreements panel for that. Whether bar clicks ought to drive the colour group is an open question for the product owner.

US9.10 As a user, I can see exactly what the Collateral charts widget shows so I know every field it displays, how it is worked out, and where the data comes from.

As a user, when I add the Collateral charts widget and link it to an Emitter’s colour, then it shows the collateral position of whatever that Emitter has selected, drawn as one of four charts I switch between.

Its role is fixed as a Receiver. Unlinked — or linked to a colour that has no Emitter present — it shows a placeholder and no data, and its Key figures strip is hidden.

Field	What it shows	How it is worked out	Data set it draws from
Key figures strip (across the top)	The nine summary cards.	Computed for this widget’s scope (the agreement + filters it receives from its Emitter).	See the Key figures strip widget below.
Segmented toggle (Over time / By agreement / By source / By bond type)	Which of the four charts is displayed.	Your choice; it persists per widget instance.	Control (no data set).
Over time — Bonds (allocated) + Cash (allocated) bars	The collateral actually allocated in each period, stacked into its bond and cash parts. The two bars together are that period’s Total allocated.	Worked out one agreement at a time, then added up: for each agreement in the selection take the smaller of what it posted and what it owes (its obligation plus its threshold cushion) — that is its used amount, and it can never be more than that agreement posted. Split each agreement’s used amount into bonds and cash in the same proportion as that agreement posted them, and add the bond parts together for the blue bar and the cash parts for the orange bar. A unallocated on one agreement is never allowed to cover a shortfall on another. When the period covers more than one day (monthly or yearly), each bar is the average of that period’s daily figures. Verify: set granularity to Daily and click the bar at the reference date — the blue bar must equal Bonds (Allocated), the orange bar Cash (Allocated), and the two together Total allocated, on the Bond postings table’s footer and on the Total allocated / Bonds allocated / Cash allocated key-figures cards.	Data set 14 · Collateral used data + data sets 10 & 6 (the exposure and threshold that cap it).
Over time — Total-posted line	A line in the ordinary text colour (white on the dark theme) running above the stacked bars, showing everything that was posted — used and unused together.	Add up the total posting (bonds plus cash) of every agreement in the selection, for the same period as the bars; on monthly or yearly granularity it is the average of that period’s daily figures. Because the bars show only the part that is used, the gap between this line and the top of the bars is the unallocated — collateral posted but not consumed. The line sits on or above the bars, never below. Verify: read the line at the reference date against the Total posting key-figures card; the gap to the bar tops must equal the Unallocated card.	Data set 14.
Over time — Exposure line	A line above the obligation.	What’s owed plus the type’s threshold cushion.	Data sets 10 + 6.
By agreement	The posting mix stacked per agreement.	Posted value per agreement, coloured by type.	Data sets 14 + 6.
By source	Bonds posted grouped by funding source (bars).	Each posting’s funding source, taken from the list of source categories; bonds only, no cash. The user’s Source-of-collateral rules supply the list of categories shown here; in the demo each posting is then given one of those categories by a fixed repeatable rule, rather than by testing that posting against the rules’ include/exclude criteria one at a time.	Data sets 14 + 7.3.
By bond type (doughnut)	Posted bond value grouped by G7 industry group; each slice labelled with its value and its % of the whole.	Each bond’s sector mapped through the user’s G7 map; the slices add to 100%.	Data sets 14 + 2 + 7.2.

📋 The Bond postings widget (Receiver ⬇ · single)

The Bond postings widget’s role is fixed as a Receiver (⬇). It is a single-instance widget — at most one per workspace — and is never an Emitter, so it never broadcasts.

US9.11 As a user, I can switch the blotter view — Summary, Detailed, Postings, Postings by bonds, Bonds Maturing, Margin Calls — and, whenever Triparty is the selection, a seventh view: T+N Ladder so I see the columns I need.

A view toggle picks which set of columns the blotter shows; each view and its columns are set out in the “What the Bond postings widget shows” table below.

The Summary view is one row per agreement type; the Detailed view is one row per individual agreement. When the Agreements widget it follows has picked one individual agreement, Detailed shows that agreement only — its Agreement column reads the counterparty (or agreement code) picked there — and the heading underneath the title names it, e.g. “Summary by individual agreement — Fernhollow Bank, as at 18 Jun 2026”. Margin Calls narrows the same way when it is listing individual agreements. Switching views keeps the pick; it is the Agreements widget that widens it again.

The Postings view carries the Unallocated (USD) figure itself — what is posted minus what is allocated — so the bonds sitting in the longbox that the agreement’s margin requirement did not consume are visible on the posting line. (There is no separate Unallocated view; it was removed once the figure moved onto the Postings view.) A fully-used agreement leaves nothing unallocated.

The Postings by bonds view answers “which bonds have we posted to this agreement — or to this triparty repo agent — and how much of each is posted, allocated and unallocated?”. It is a pivot of the Postings view, aggregated by bond: the same bond can be posted to the same agreement (or agent) several times — different dates, different amounts, each its own line on Postings — and here they become one row whose amounts are the sums and whose Start date is the earliest of them, so no bond is listed twice. Because the row is the bond and not a posting, it drops two of the Postings columns — Agreement Name (every row is the one agreement or agent selected) and Trade # (a bond can have several postings, so no one trade number describes the row) — and starts at ISIN, whose footer counts the rows as “N bonds”. Same date window and cross-filters as Postings; it opens sorted by Posted (USD), biggest first.

Its button is always there — never hidden, so anyone using the blotter can see the view exists. It fills in once the selection names the one thing it answers for: either (a) the Agreements widget has picked one individual agreement of a non-Triparty type — for example GMRA-002 — or (b) Triparty is selected with only one agent left switched on (Euroclear, Clearstream or BNY Mellon).

Until then it shows no rows and asks for the pick. All agreements, a whole type, several types, or Triparty with more than one agent on all leave it waiting, because “which bonds are posted to this one agreement” has no answer for a group. In place of the table it reads “Select an agreement to see the bonds posted to it”, then “Click an agreement name in the Summary or Postings list — for example GMRA-002 — and this view lists every bond posted to it.” and “For Triparty, pick one agent instead — Euroclear, Clearstream or BNY Mellon — because triparty collateral is held with the agent, not under an agreement code.” It deliberately does not fall back to listing everything — that would answer a different question. The title says which state you are in: “Postings by bonds — GMRA-002”, “Postings by bonds — Triparty Clearstream”, or plain “Postings by bonds” while it waits.

Triparty is scoped by agent, not by an agreement code, because triparty collateral is not booked under a standalone agreement code — it sits with the agent, who administers the counterparties whose collateral it holds. Those rows are one per bond held with that agent, the Custodian column repeats the agent and the Counterparty column keeps whose collateral each bond is; because the same postings are only being grouped, the column totals match the Postings totals for that same one-agent selection. For one individual agreement every row is that agreement’s (which is why the column naming it is not repeated on every line), and the amounts are that agreement’s share of its type’s book — the same share the Summary/Detailed rows, the key figures strip and the agreement detail screen give it — so its totals are the type’s Postings totals multiplied by that share, not equal to them.

US9.12 As a user, I can filter maturing bonds and configure the columns so I focus the blotter on what’s coming due and lay it out the way I want.

The “Maturing ≤ N days” filter limits Bonds Maturing to lines maturing within N days, and the column ⚙ shows/hides, reorders and pins columns — both are detailed in the field table below.

US9.13 As a user, I can see exactly what the Bond postings widget shows so I know every field it displays, how it is worked out, and where the data comes from.

As a user, when I add the Bond postings widget, then a blotter of individual collateral lines appears.

If it is linked to an Emitter it filters to that agreement / type; standalone, it shows all postings. Its role is fixed as a Receiver — it is never an emitter and does not broadcast. Only one per workspace.

When the Emitter has picked one individual agreement, the views whose rows are individual agreements — Detailed, and Margin Calls at individual level — list that agreement alone, so the Agreement column ties to what is highlighted in the Agreements widget. The bond-level views Postings and Bonds Maturing still show the whole type; Postings by bonds is the one bond-level view that follows the pick — its button is always available, it lists that agreement’s (or that triparty agent’s) bonds alone once one is picked, and until then it shows no rows and asks for the pick.

Field	What it shows	How it is worked out	Data set it draws from
Key figures strip (across the top)	The nine summary cards.	Computed for whatever the table currently shows (the widget’s selection + filters).	See the Key figures strip widget below.
View toggle (Summary / Detailed / Postings / Postings by bonds / Bonds Maturing / Margin Calls / T+N Ladder)	Which set of columns the blotter shows, and at what level of detail each row sits.	Your choice. Every view’s button is always on offer; Postings by bonds additionally needs one individual agreement (non-Triparty) or one triparty agent to be selected before it has rows to show.	Control (no data set).
“Maturing ≤ N days” filter	Limits Bonds Maturing to lines maturing within N days.	Your day count checked against each line’s maturity date.	Data set 2 · Bond / securities static (maturity).
Postings by bonds view (the Postings columns except Agreement Name and Trade #)	One row per bond posted to the one agreement — or the one triparty repo agent — currently selected, each with its posted / allocated / unallocated amounts and the rest of the bond’s details. The button is always available; until one agreement or one agent is selected it shows no rows and asks for that pick.	Takes the same postings as the Postings view, keeps only those of the selected agreement (or agent) and adds together the postings of the same bond: Original Amount, Posted (USD) and Allocated (USD) are the sums, Unallocated (USD) is Posted minus Allocated and Start date is the earliest posting’s. The agreement code and the Trade # belong to a posting, not to the rolled-up bond, so neither column is shown; the ISIN footer counts the rows as “N bonds”. For a triparty agent the Custodian column repeats the agent, so the totals match the Postings view for the same one-agent selection. For one individual agreement every amount is its share of its type’s book (the same share the Summary rows and the key figures use), so the totals are the Postings totals multiplied by that share. Opens sorted by Posted (USD), biggest first.	Data sets 14 · Collateral used data (the postings and their amounts) · 2 · Bond / securities static (the bond’s details) · 6 · Agreements static (the agreement / triparty agent it was posted to).
Column ⚙	Show/hide, reorder and pin columns.	Your layout control.	Control (no data set).
Postings columns (Agreement Name, Trade #, ISIN, Security, Type, Sector, Counterparty, Agreement Type, Custodian, Source, Start date, Maturity, Maturing in Days, then the five amount fields: Original Ccy, Original Amount, Posted (USD), Allocated (USD), Unallocated (USD))	One row per collateral line.	Every column’s what/computation/source is the column dictionary in the collateral-used column dictionary — instrument reference from set 2, counterparty from set 1, funding source from set 7.3, FX from set 8.	Data set 14 · Collateral used data (+ sets 1, 2, 7.3, 8).
The five amount fields on every postings row (Original Ccy · Original Amount · Posted (USD) · Allocated (USD) · Unallocated (USD))	Original Ccy the currency the bond is denominated in. Original Amount how much of the bond was posted, counted in that currency. Posted (USD) the same posted amount in US dollars. Allocated (USD) the part of it the collateral team used to cover this agreement’s margin requirement. Unallocated (USD) what is posted but not consumed — it sits in the longbox. Worked example: Original Ccy SGD, Original Amount 1,000,000, Posted (USD) 700,000, Allocated (USD) 500,000, Unallocated (USD) 200,000.	Posted (USD) = Original Amount multiplied by the line’s exchange rate. Allocated (USD) = Posted (USD) scaled down by the agreement’s used-versus-posted coverage (the smaller of: one, and the exposure divided by the total posting). Unallocated (USD) = Posted (USD) minus Allocated (USD), never below zero. Verify: pick any row — Original Amount times the currency’s rate must give Posted (USD); Posted (USD) minus Allocated (USD) must give Unallocated (USD); the Allocated column’s footer total must equal that agreement’s “Bonds (Allocated)” figure on the Summary view, and the Posted column’s footer total its “Bonds (Posted)” figure. Known defect (open, raised 31 Jul 2026): the build currently normalises every posting of a book — including postings that have already matured — up to the day’s bond figure, and only then hides the ones not live at the reference date. The result is that the postings on screen add up to less than the Bonds posted card whenever a selection holds matured postings: at the latest reference date GMRA shows about $448m of postings against a $588m card, and GMSLA about $296m against $374m. Bilateral CSA IM and VM, CCP, Futures and Triparty happen to tie out because all of their postings are still live. The tie-out described here is the intended behaviour and the build is to be corrected to match it — until then, expect GMRA and GMSLA to fall short and do not raise it as a new defect. A fully-used agreement (total posting at or below exposure) shows nothing unallocated on any line.	Data set 14 · Collateral used data (posted & used amounts) + set 8 · FX (the rate) + sets 10 & 6 (the coverage).
Summary / Detailed (per-agreement) columns	The same money figures as the Agreements table, per agreement. Summary is one row per agreement type; Detailed is one row per individual agreement — and when the Agreements widget has picked one individual agreement, that one row only.	Exposure / Call / Margin call from set 10 (+ 6 for thresholds); Posting / Bonds / Cash / Received from set 14. An individual agreement’s figures are the type’s figures scaled by that agreement’s share of the type — the same share the Agreements widget shows it at, so the two screens agree. Full definitions in data model 14 and the Overview field table (Requirements 1 · Epic 2).	Data sets 10 + 14 + 6.
T+N Ladder view (Triparty only — Country · T+0 · T+1 · T+2 · T+3 · T+4 · T+5)	How much triparty bond collateral could be settled on each of the next six business days. The button appears only while Triparty is the selection and disappears when any other type is picked. It shows three separate tables, one per triparty agent — Euroclear, Clearstream and BNY Mellon. Each table has one row per settlement location — GB, FR, HK, EA, AU, US and Corp — and one column per settlement horizon, from T+0 (settles today) out to T+5 (settles in five business days). Every cell is an amount in US$ millions: the unallocated bond collateral sitting in that agent’s longbox that could settle in that location at that horizon. Amounts of half a million or less are shown as a dash rather than a number. A Total row closes each table.	Each agent’s ladder starts from that agent’s own book size shared across the seven locations, and then falls away as the horizon lengthens — roughly 15% less at each step out, so T+0 is always the largest column and T+5 the smallest. The Total row is simply the seven location rows for that column added together. Verify: add up the seven country figures in any column — the result must equal that column’s Total. Read across any row and the amounts must fall as the horizon lengthens. The same figures appear on every fresh load, so two testers on two machines must read identical numbers. Lineage note (open, raised 31 Jul 2026): unlike every other figure in this document, these amounts are a fixed illustrative table in the demo — they are not worked out from the collateral lines behind the Postings view, so they will not reconcile to the Unallocated column or to any other figure on the screen. Before this view is built for real it needs its source data set confirmed and added to the data model list above.	Not yet traced to a data model — see the lineage note.
Margin Calls view + 5 KPI tiles (Total Margin Call, Pending Review, Confirmed, No Call, Disputes)	The Daily Exposure Report rows and their roll-up tiles. When it is listing individual agreements and the Agreements widget has picked one, it lists that agreement alone and the five tiles count only it.	Totals and counts of the rows by call status and dispute.	Data set 10 · Exposures & margin calls.

🔢 The Key figures strip — rides on Collateral charts & Bond postings

The Key figures strip is not a standalone palette widget; it rides on top of the Collateral charts and Bond postings widgets, each strip scoped to its own widget.

US9.14 As a user, I can see exactly what the strip shows so I know every card, how it is worked out, and where the data comes from.

As a user, when I add a Collateral charts or Bond postings widget, then a strip of nine summary cards appears across its top, each scoped to that widget — so two strips can show different numbers at once.

The Bond postings strip always describes the table underneath it: when that table is narrowed to one individual agreement (the Agreements widget picked it and the view is Detailed, Postings by bonds, or Margin Calls at individual level), every card is that agreement’s share — so Total exposure equals the row’s Total exposure, Total posting equals its Total posting, and so on down the row. The cards scale the same way on Postings by bonds once that view has an agreement to show. On the remaining bond-level views (Postings, Bonds Maturing) the table is still the whole type, so the cards are the whole type’s.

It is not a standalone palette widget; it only ever rides on those two widgets.

Field	What it shows	How it is worked out	Data set it draws from
Total exposure	What’s owed plus the threshold cushion across the selection.	Add up each obligation plus its threshold.	Data sets 10 + 6.
Total posting	Collateral posted across the selection.	Add up the day’s posting across the selection.	Data set 14.
Bonds posted	The bond part of the posting.	The posting times the bond share.	Data set 14.
Cash posted	The cash part of the posting.	Total posting minus Bonds posted.	Data set 14.
Total allocated	Collateral actually used.	Worked out one agreement at a time and then added up: for each agreement in the selection take the smaller of what it posted and what it owes (obligation plus threshold), and add those amounts together. A unallocated on one agreement never covers a shortfall on another, so this can be less than simply taking the smaller of the two grand totals.	Data sets 14 + 10.
Bonds allocated	The bond part of Allocated.	Each agreement’s used amount split in the same bonds-to-cash proportion as that agreement posted, then added up across the selection.	Data set 14.
Cash allocated	The cash part of Allocated.	Total allocated minus Bonds allocated.	Data set 14.
Unallocated	Spare collateral (green “unallocated”) or shortfall (red “deficit”).	Total posting minus Total allocated; no Week/Week pill.	Derived from the two rows above.
Received (inbound)	Collateral counterparties posted to us.	An independent inbound figure — not derived from Posted / Allocated / Unallocated; it moves with the selection and date window.	Data set 10 · Exposures & margin calls.
Week/Week pill (on every card except Unallocated)	The change versus a week earlier.	The figure now compared with the same figure seven days before the reference date; the percentage is the change divided by that earlier figure.	The same set as the card it sits on.

🔎 Checks that span more than one widget — reading the whole screen together

Everything above described one widget at a time: what it is for, what you can do with it, and where each of its figures comes from. This last section is the opposite view — the checks that only make sense when you look at two or more widgets together, plus the one-line summary of which widget reads which data model.

If you are verifying a single number, you will find it in that widget’s own “what this widget shows” table further up. Come here when you want to prove that two widgets agree with each other.

Derived figures — the numbers the screen works out for itself (never stored in any data model)

These are not stored anywhere — they are added up from the daily records whenever a screen is drawn. “The selection” means whatever the user has picked (all agreements, one type, or one individual agreement).

Figure	How it is worked out (plain English)	How to check it is correct (what to compare it against, on screen)
Posted (Total posting)	Add up the collateral posted across everything selected. For a whole type use it as-is; for one individual agreement, scale it down by that agreement’s share.	On a Key-figures strip, the Total posting card must equal Bonds posted plus Cash posted (its two halves added together). In the Agreements widget, the All agreements Posted must equal the sum of the individual type-row Posted figures except Triparty (left out of the All-agreements total) — add the visible type rows and compare.
Exposure	Add up what’s owed across the selection, plus each one’s threshold cushion.	On the Over time chart the Exposure line sits above the obligation by the type’s threshold cushion — for a type with a $12mm threshold, Total exposure minus what’s owed should be $12mm. A type with a zero threshold (e.g. Bilateral IM/VM) shows Exposure equal to what’s owed.
Allocated (Total allocated)	For each agreement, the smaller of what it Posted and its own Exposure — you can’t use more collateral than you posted, or more than you owe. The card is those per-agreement amounts added up, so a unallocated on one agreement never covers a shortfall on another.	Open the Agreements panel and read each type row’s Posted and Allocated: every row’s Allocated must be the smaller of its own Posted and its own Exposure, and adding the rows up (skipping Triparty) must give the Total allocated card. Do not check it by taking the smaller of the two grand-total cards — that only agrees when every agreement leans the same way. Where a type posted less than it owes, its Allocated equals its Posted and it contributes no unallocated.
Unallocated	Total Posted minus Total Allocated. It is shown green with the word “unallocated” when it is zero or positive, and red with the word “deficit” when it is negative.	Read the Total posting and Total allocated cards and subtract — the Unallocated card must equal Posted minus Allocated (to the displayed rounding).
Bonds / Cash allocated	Split each agreement’s Allocated figure into bonds and cash in the same proportion as that agreement posted them, then add up across the selection.	Bonds allocated plus Cash allocated must add back to Total allocated. The bonds share of Allocated will be close to, but need not exactly equal, the bonds share of the posting — each agreement is split by its own mix, so agreements that are more bond-heavy or more cash-heavy than average shift the blend. Check it agreement by agreement instead: on any single type row, Bonds (Allocated) ÷ Total allocated must equal Bonds (Posted) ÷ Total posting.
Received (inbound)	The collateral that counterparties have posted to us for the selection — the inbound side, the opposite direction to Posted (what we post out). It is drawn from the Exposures & margin calls data (set 10) and is an independent figure: it is not worked out from Posted, Allocated or Unallocated.	Received has no partner card to add or subtract against on the same strip (it is inbound, the others are outbound), so check it two other ways: (1) scope — it must move when you change the agreement selection or the date window, matching whatever the strip is scoped to; (2) its Week/Week pill — set the To date back 7 days on the Agreements panel and the Received you then read must equal what the pill was comparing against. On fresh loads it is always the same number — the demo’s sample data is fixed, so reloading the page never changes it.
Key-figures cards (9)	The nine summary cards: Total exposure · Total posting · Bonds posted · Cash posted · Total allocated · Bonds allocated · Cash allocated · Unallocated · Received (inbound collateral).	The cards cross-check each other by the rows above (Bonds added to Cash gives the total; Allocated is the Agreements panel’s type rows added up; Unallocated is posting minus used). Each strip must also match its own scope — the Collateral charts strip follows the agreement and dates the Agreements control panel broadcasts, the Bond postings strip follows whatever the blotter currently shows. Allow for the displayed rounding ($ millions to one decimal).

🔎 Verifying the on-screen figures — where each number comes from & how to check it

Why this section exists (for the BA and the tester): every figure Overview 2 shows must be checkable — if a card reads $10.0mm Total posting, we have to be able to say where that number came from and prove it is right, not take it on trust.

Overview 2 shows no figure that cannot be re-derived from the data documented above and cross-checked against another figure on the same screen.

Below, figure by figure, is the check to run and where to look.

(The underlying build formulas are in US9.15–US9.17 and the developer folds; these are the same checks in plain words, so a non-technical reviewer can confirm any number by comparison alone. Allow for the displayed rounding — the Key-figures cards and the Agreements widget’s Posted / Allocated / Unallocated figures are shown in whole $ millions, while the table cells and the Unallocated card show one decimal place. So when you add displayed figures together, allow up to about $1m of rounding difference for each figure you add — adding three sub-book readings can legitimately be about $3m off the total.)

Figure / check	How to verify it	Where to look
The nine Key-figures cards add up among themselves.	On either strip: Bonds posted plus Cash posted must equal Total posting; Bonds allocated plus Cash allocated must equal Total allocated; Total allocated is the Agreements panel’s type rows added up (each capped at its own posting), not the smaller of the two grand totals; Unallocated is Total posting minus Total allocated. Read the cards and do the arithmetic — they must tie out. Unallocated shows green (“unallocated”) when it is zero or positive and red (“deficit”) when it is negative.	The Key-figures strip across the top of the Collateral charts widget and the one across the top of the Bond postings widget.
Received (inbound) is an independent figure — check it by scope, not by arithmetic.	Received is collateral counterparties posted to us, so unlike the other cards it does not add up with them. Confirm it moves with the selection (change the Agreements pick or date window and it changes) and that its Week/Week pill is checkable (set the To date back 7 days on the Agreements panel — the Received you then read equals what the pill compared against).	The Received (inbound) card at the right-hand end of each Key-figures strip.
Each strip matches its own scope.	The Collateral charts strip must equal the agreement selection and date window the Agreements control panel is broadcasting to that colour group — change the Agreements pick and the strip must move with it. The Bond postings strip must equal whatever the blotter is currently showing (its view and filters). A strip that does not follow its scope is a defect.	Compare each strip with its host widget’s current selection.
The Agreements rows reconcile to the grand total.	In the Agreements widget the All agreements row’s Posted / Allocated / Unallocated must equal the sum of the individual type rows below it — except Triparty, which is deliberately excluded from the All-agreements total (see data model 6). Add the visible type-row figures (skip Triparty) and compare with the All-agreements row. Each type row’s Allocated must be the smaller of its Posted and its Exposure, and its Unallocated is Posted minus Allocated. Fixed 04 Aug 2026 (was raised 31 Jul 2026): the All agreements row used to work its Allocated out as the smaller of the two grand totals rather than by adding the type rows up, so it read about $2,095m Allocated / $25m Unallocated where the type rows added to about $2,040m / $80m. It now adds the type rows, and the row reconciles.	The Agreements control-panel widget’s row list.
Drill down and the parts add back to the whole.	Click a type to drill into its individual agreements: each shows its share of the type, and the shares add up to the whole type (they total 100%). So the individual Posted figures sum back to the type’s Posted total — spot-check by adding a few and confirming the proportion. This holds for Triparty too, where the rows are the counterparties the agents handle: with all three agents on, all the counterparties’ Posted figures add back to All Triparty; with one agent on, only that agent’s counterparties are listed and they add back to the agent’s own Posted.	The individual-agreement drill list (the “← Summary” button returns).
A Triparty counterparty’s figure does not move when you change agents.	Drill into Triparty with all three agents on and write down one counterparty’s Posted. Switch off the two agents that do not handle it — the counterparty must still be listed and still show the same Posted, because its size is measured inside its own agent’s book. Switch off its own agent instead and the counterparty must disappear from the list altogether (it is handled by that agent only).	The Triparty drill list and the Euroclear / Clearstream / BNY Mellon buttons above it.
A sub-filter’s parts add back to the whole book.	Pick a type that has sub-filter buttons (Bilateral CSA IM, CCP or Triparty) and write down its Posted with every button on. Switch all but one book off and write that Posted down; repeat for each of the other books. The separate readings must add back to the figure you started with (allow 0.1 for rounding) — e.g. CCP with IM only plus CCP with VM only equals CCP with both on. Check the same holds for the same-colour Receivers: the charts’ Total posting card must equal the Agreements row you are filtering to. For Bilateral CSA VM, switching “Zero-interest only” on must narrow the individual list to about a third of the agreements and leave the money figures on the full CSA VM book.	The Agreements widget’s sub-filter buttons, under the type you selected; then the linked Collateral charts widget’s Key-figures strip.
The blotter’s Agreement column ties to the agreement picked in the Agreements widget.	Drill into a type in the Agreements widget and click one individual agreement — say Fernhollow Bank under Triparty; note its Posted, Allocated and Unallocated there. On the linked Bond postings widget switch to Detailed: it must list exactly one row, its Agreement column must read Fernhollow Bank, and that row’s Total posting must equal the Posted you noted (allow the displayed rounding). The Key figures cards above it must equal that single row figure for figure — Total posting to Total posting, Total exposure to Total exposure. Then check it widens back: click the type row again and the table returns to all of that type’s agreements with the cards back at the type totals. Switch to Margin Calls and it is the same one agreement; switch to Postings and the bond lines are the whole type’s, which is expected — collateral is posted at agreement-type level.	The Agreements widget’s drill list, and the Detailed / Margin Calls / Postings views of the Bond postings widget with its Key figures strip.
Rolling one agent’s postings up by bond moves no money.	Select Triparty with only one agent switched on (say Clearstream). Read the Posted (USD), Allocated (USD) and Unallocated (USD) totals in the footer of the Postings view, then switch to Postings by bonds and read them again — they must be the same (allow the displayed rounding), because the view only groups those same postings by agreement and bond. Spot-check one row: its Unallocated must equal its Posted minus its Allocated, and no agreement may list the same ISIN twice. (For one individual agreement the two views do not match, and should not: Postings by bonds shows that agreement’s share of the type’s postings, so its total is the Postings total multiplied by the agreement’s share of its type.)	The Bond postings widget — the Postings and Postings by bonds buttons, and the totals row at the foot of the table.
The (N) margin-call badge is a fixed count.	The orange (N) beside a type is the number of that type’s agreements that had a margin call in the last 14 days; it is the same on every fresh load (not random). Known limitation (a gap to raise): the individual-agreement drill rows do not display a per-agreement margin-call flag, so N cannot be independently re-counted on screen — verify it by its tooltip and its consistency across reloads, and flag the un-recomputable count to the Business Analyst.	The badge on each type row.
The charts reconcile to the strip.	On Over time, the height of each stacked bar (Bonds (allocated) and Cash (allocated) together) equals that period’s Total allocated — set granularity to Daily, click the bar at the reference date, and compare it with the Total allocated card and with the Bond postings table’s Total allocated footer; the two bar segments must equal Bonds (Allocated) and Cash (Allocated). The Total posted line runs above the bars, and the gap between the line and the bar tops is the Unallocated card — a line sitting below the bar tops is a defect (you cannot use more than you posted). It is drawn in the ordinary text colour (white on the dark theme), not green. The Exposure line sits above the obligation by the type’s threshold cushion, and the bars sit at or below it. On By source, the funding-source bars add up to Bonds posted (see the known defect note below) (this chart shows bonds only, not cash). On By bond type, the doughnut slices add up to Bonds posted Known defect (open, raised 31 Jul 2026): the build currently normalises every posting of a book — including postings that have already matured — up to the day’s bond figure, and only then hides the ones not live at the reference date. The result is that the postings on screen add up to less than the Bonds posted card whenever a selection holds matured postings: at the latest reference date GMRA shows about $448m of postings against a $588m card, and GMSLA about $296m against $374m. Bilateral CSA IM and VM, CCP, Futures and Triparty happen to tie out because all of their postings are still live. The tie-out described here is the intended behaviour and the build is to be corrected to match it — until then, expect GMRA and GMSLA to fall short and do not raise it as a new defect. and each slice’s label shows its value and its % of the whole — the percentages add to 100%.	The Collateral charts widget’s segmented toggle (Over time / By agreement / By source / By bond type).
The Week/Week pill is checkable.	Each card’s W/W pill compares the figure now with the same figure seven days before the reference date; the percentage is the change divided by that earlier figure. To check it, set the To date back 7 days on the Agreements panel (the reference-date chip itself is a read-out, not a control — the To date is what moves it); the figure you then read must equal what the pill was comparing against.	The pill under each Key-figures card (Unallocated has no pill).
A single collateral line ties out end to end.	The fully worked line in the collateral-used column dictionary shows the whole chain — booking amount → value after the haircut → converted to US dollars — and every referenced field points back to its source data set, so a developer can re-derive the row with no hidden inputs. Use it as the template for checking any line in the Bond postings blotter.	the collateral-used column dictionary above, and the Postings view of the Bond postings widget.

🔗 Widget → data & logic lineage — which widget reads which data set

This traces every Overview 2 widget back to the Data source catalog above: the numbered data sets it reads and the logic it applies to them.

Overview 2 ships five widget types (Agreements, Collateral charts, Bond postings, Rules engine, Inventory Manager) plus the Key-figures strips that ride on two of them. Read the numbers against the 15-set catalog.

This table is the one-row-per-widget summary. The field-by-field breakdown — every field a widget shows, what it shows, how it is worked out, and which data set it draws from — is in each widget’s “What this widget shows” table, starting with US9.7 · what the Agreements widget shows.

Widget	Role	Data sets it reads (catalog #)	Logic it applies
Agreements (control panel)	Emitter ⬆	6 Agreements static (the 7 types, names, colours, thresholds; each individual agreement and, for Triparty, the agent that handles it) · 1 Counterparty static (the counterparty names listed when Triparty is drilled) · 10 Exposures & margin calls (obligation; the 14-day margin-call flag) · 14 Collateral used data (Posted — the Collateral Value of its lines; see the collateral-used column dictionary) · 8 FX (base-currency → USD)	Per type/selection: Exposure = add up each one’s obligation plus its threshold cushion; Allocated = the smaller of Posted and Exposure; Unallocated = Posted minus Allocated (green if zero or positive, red if negative). The (N) badge = count of that type’s individual agreements that had a margin call in the last 14 days. Drilling a type lists its individual agreements, each scaled by its share of the type (the shares add up to 100%). Drilling Triparty lists counterparties, not agreement codes — triparty collateral is held by an agent, so the rows are the counterparties the selected agent(s) handle, and switching an agent off removes its counterparties from the list. The selected type’s own sub-filters (Bilateral CSA IM → Euroclear / Clearstream · Bilateral CSA VM → Zero-interest only · CCP → IM / VM · Triparty → Euroclear / Clearstream / BNY Mellon) re-work that type’s figures from only the books left on, and travel with the selection to the colour group’s receivers. Broadcasts the agreement pick + filter panel to same-colour receivers.
Collateral charts	Receiver ⬇	14 Collateral used data (bonds/cash posted — Booking / USD values of its lines; see the collateral-used column dictionary) · 10 Exposures (the exposure line) · 6 Agreements static (By agreement mix) · 7 User-maintained — Source of collateral (By source) & G7 map (By bond type = the line's Asset Class) · 2 Bond/securities static (bond type → sector/G7) · 8 FX (FX Rate per line)	Buckets the daily book records to the emitter’s granularity (Daily/Monthly/Yearly) & date window, then draws one of four dimensions: Over time (stacked Bonds (allocated) + Cash (allocated) bars, which add up to Total allocated, with a Total-posted line above them and an Exposure line), By agreement (stacked mix), By source (funding-source bars, using the user’s Source-of-collateral rules), By bond type (doughnut by G7 group, using the user’s G7 mapping — the line’s Asset Class). Chart clicks cross-filter (source / G7 / agreement) or set the reference date. Shows a placeholder + hides its Key-figures strip when it has no live emitter.
Bond postings (single)	Receiver ⬇	15 Inventory data & 2 Bond/securities static (each posting: ISIN, Security, Type, coupon, maturity) · 1 Counterparty static (Counterparty column) · 7 User-maintained — Source of collateral (Source column) & G7/sector · 14 Collateral used data (the posting line itself: Position, Par Amount, Booking & USD Market/Collateral Value, the five amount fields — Original Ccy, Original Amount, Posted (USD), Allocated (USD) (what TMO used, scaled by the used-versus-posted coverage) and Unallocated (USD) (Posted minus Allocated); see the collateral-used column dictionary) · 10 Exposures & margin calls (Margin Calls view + 5 KPI tiles) · 6 Agreements static (Agreement Category / Custodian, Haircut; the agreement filter) · 5/8 Currency / FX (Ccy, Base CCY, FX Rate columns)	Filters the postings to the emitter’s broadcast agreement/type (or shows all postings when standalone). When the emitter has broadcast one individual agreement, the views whose rows are individual agreements — Detailed, and Margin Calls at individual level — list that agreement alone (its figures being the type’s scaled by that agreement’s share of the type), so the Agreement column matches the emitter’s pick; the bond-level views stay on the whole type, as postings are held at agreement-type level. Toggles Summary / Detailed / Postings / Postings by bonds / Bonds Maturing / Margin Calls views; the Postings by bonds view rolls the postings of a single agreement (non-Triparty) or a single triparty agent up to one row per bond, adding that bond’s postings together, and shows no rows — just an ask-for-a-pick message — until the selection names one; the “Maturing ≤ N days” filter; the column ⚙ (show/hide, reorder, pin). The Unallocated (USD) column on the Postings view shows posted-minus-allocated per line (what is posted to the longbox but not consumed by the margin requirement). Its Key-figures strip scopes to whatever the table currently shows. Never an emitter — it does not broadcast.
Rules engine (single)	Standalone — (neither emits nor receives)	15 Inventory data (the collateral pool to allocate) · 10 Exposures & margin calls (the requirements to cover — one per agreement type) · 6 Agreements static (eligibility schedule, rating floor, haircut add-on, concentration limit, minimum transfer amount, settlement delay) · 2 Bond/securities static (the Bond static data input — reference attributes per collateral class: asset class/type, issuer, issuer type/country, currency, seniority, security rating, time to maturity, haircut schedule, exclusions) · 4 Portfolios static (the Portfolio static input — Portfolio name, Close entity, PC Code, Desk, Book, Product Lines, Product Franchise) · 14 Collateral used data (its Delivered rows — what is already posted; read only when the run’s Sweep the deck setting is off, so the run tops up instead of starting from a clean deck) · 13 Optimization exclusions & exceptions (what the ⚠ Exceptions view reports) · 11 Optimization rules (the active run’s scoping & ranking rules) · 12 Optimization outputs (the resulting postings) · 13 Optimization exclusions & exceptions (lines the user ignores / excludes)	Embeds the standalone Rules engine as a widget — it is the very same allocation-optimisation studio documented in full on Requirements 1 · §11 Rules engine, shown here through `/j-collateraldemo?only=rules` so the two stay one source of truth. In short: it scopes the inputs by the active run’s rules, then for each agreement picks the cheapest eligible collateral that satisfies eligibility, haircut, concentration and minimum-transfer limits, and reports the per-agreement postings plus the carry-cost saved versus posting all cash. Standalone: it never joins a colour group, so it neither follows nor drives the Agreements emitter. This is one of two Overview 2 widgets whose internals are specified on Requirements 1 rather than in full here, because it is an embed of that existing tool, not a native re-build.
Inventory Manager (single)	Standalone — (neither emits nor receives)	15 Inventory data (the transaction-level bond holdings — every trade row: Portfolio, ISIN, Security, Notional/Par, Market & Collateral Value, category, dates) · 2 Bond/securities static (each holding’s reference details: type, coupon, maturity, sector, rating) · 8 FX (base-currency → USD for the value columns)	Embeds the standalone Inventory Manager as a widget — it is the very same inventory tool documented in full on Requirements 1 · §10 Inventory Manager, shown here through the `/j-inventory` page (it hides its own top bar when framed) so the two stay one source of truth. In short: it shows the holdings summary bar by category, a “Snapshot as-at” date picker, a View toggle, and the transaction-level table of bond trades. Standalone: it never joins a colour group, so it neither follows nor drives the Agreements emitter. This is the second of two Overview 2 widgets whose internals are specified on Requirements 1 rather than in full here, because it is an embed of that existing tool, not a native re-build.
Key figures strips (ride on Collateral charts & Bond postings)	— (part of the host widget)	14 Collateral used data · 10 Exposures · 2 Bond/securities static (bonds-vs-cash split)	Computes the nine derived cards (derived figures) — Total exposure, Total posting, Bonds/Cash posted, Total/Bonds/Cash allocated, Unallocated, Received — each for its host widget’s own scope (the charts strip follows the charts widget’s emitter; the postings strip follows what the table shows — including scaling down to a single individual agreement when the table is narrowed to one).

No current Overview 2 widget reads sets 3 or 9 — see the Gap highlight under the catalog. (Sets 11, 12 and 13 — the optimization rules, outputs and exclusions — plus sets 2 Bond/securities static and 4 Portfolios static are now read by the Rules engine widget, via its Bond static data and Portfolio static inputs.) If a future widget needs any of them (or any data not on the 15-set list), raise it and add it to the catalog before building.

🔧 Developer build detail — grid & reflow engine, data model & loading, generation formulas, render config, persistence & verbatim UI strings (for developers rebuilding the app; business readers can skip all of this)

Everything inside this fold is the exact, verbatim technical detail a programmer needs to recreate Overview 2 number-for-number — code names, seeds, formulas, grid constants and storage schemas. It is kept here, collapsed, so the rest of the page reads in plain English; you never need to open it to use or check the screen.

Grid, reflow, palette, workspaces & linking

Grid model (exact constants): COLS=12, ROW=34, GAP=6, MINW=2, MINH=2 (px / cells). Column width = canvas clientWidth ÷ 12 (responsive; colW()). Row pitch = ROW+GAP = 40px. A widget at grid {x,y,w,h} is positioned by applyLayout() as left = x·colW, top = y·40, width = max(1, w·colW − 6), height = max(1, h·40 − 6) (the −6 is the GAP gutter — a 3px margin each side of a widget, per the design system). Minimum size 2×2 cells; moves/resizes snap to whole cells via Math.round and clamp to x∈[0, 12−w], y≥0, w∈[2, 12−x], h≥2. A drag starts immediately on header pointerdown (left button) — no pixel threshold — and is suppressed if the pointer is on a button/input/select/a/[contenteditable] or the widget is pinned. Canvas min-height = max(viewportH−47, bottom-most widget +20)px; a ResizeObserver re-applies the layout on width change.
No-overlap reflow: on every move/resize/add the engine (a) pushes any colliding non-pinned, non-active widget down below the active one (cascading), then (b) compacts all non-pinned widgets upward into free space. Pinned widgets and the widget being dragged are never moved by the reflow. Result: widgets always tile without overlapping.
Palette (left rail): a fixed “ADD WIDGETS” list — one row per widget type (Agreements, Collateral charts, Bond postings, Rules engine, Inventory Manager) with a ＋ that appends a new instance of that type to the active workspace. Types marked (single) (Bond postings, Rules engine, Inventory Manager — singleton:true in the catalog) allow only one instance per workspace; their row disables while one is present.
Close / Pin: the ✕ header button removes an instance from the workspace (its chart is destroyed); the 📌 header button toggles the instance’s pinned flag (accent border, drag & resize disabled, acts as a fixed obstacle in the reflow).
Workspaces: top tabs; ＋ adds an empty workspace, single-click switches, double-click renames (inline, Enter/Escape), ✕ closes (minimum one workspace). Each workspace holds its own instance list + layout + colour-group selections.
Linking (emitter / receiver by colour): each instance has a link:{color, role} where color ∈ {blue, green, amber, purple, pink, teal} (or none = standalone) and role ∈ {emitter, receiver}. The role is fixed by the widget type — typeRole() returns emitter for Agreements and receiver for Collateral charts & Bond postings — so the UI never lets you change it; only the colour (or Standalone) is user-set. An emitter’s current agreement selection is stored per colour on the workspace (groupSel[color]) and its filter panel per colour (groupFilter[color] = {gran, fromMs, toMs, refMs}); every receiver on that colour re-renders with both (All → all agreements; a type → that type; an individual agreement → that agreement, scaled by the agreement’s share/weight; a receiver blotter filters to the type) at the emitter’s granularity / date window. Standalone widgets follow the workspace’s global selection + the global default filter. The chain icon shows the group colour + ⬆/⬇ (matching the fixed role); the popover shows the role as a read-only label and only sets the colour or Standalone.
- A receiver is “linked” only when an emitter is present on its colour. A colour group is active only while some widget with role:"emitter" holds that colour (helper emitterColors()). Receiver gating (recvSel, effFilter, and the Collateral charts empty-state) all require hasEmitter(link.color) — a receiver on a colour with no emitter reads as unlinked (charts → placeholder; other receivers → global default). Closing or recolouring an emitter re-renders its old colour group, then pruneOrphanReceivers() clears the now-orphaned link.color of any receiver left on that colour and refreshes its chrome via chainChrome(), so the coloured outline + ⬇ icon revert to the standalone 🔗 look — the widget never shows as linked to an emitter that isn’t there. The same pruning runs on load (so a persisted phantom link self-heals) and whenever a widget’s role/colour is changed in the chain popover. chainChrome() also independently treats a receiver whose colour has no emitter as unlinked.
- Roles are fixed by type; emitters auto-claim a distinct colour. Adding an Agreements widget sets link:{color:freeEmitterColor(), role:"emitter"} — the first colour not already used by an emitter (null if all six are taken). A Receiver widget (Collateral charts, Bond postings) is added as link:{color:null, role:"receiver"} = standalone until linked. On load, coerceRolesByType() forces every persisted instance’s role back to its type’s role (and re-frees any duplicate emitter colour), so older saved layouts that let the user pick roles are healed. No two emitters share a colour.
- The colour picker is role-aware (role itself is not pickable). For a Receiver (Collateral charts, Bond postings) the swatches shown are exactly the colours that currently have an emitter; for the Emitter (Agreements) they are the colours not yet used by another emitter (plus its own). The chain popover has no role buttons — it shows the fixed role as a read-only label, then the swatches, then Standalone.
The Collateral charts and Bond postings widgets are Receivers (fixed by type, no emitter role offered) and render no group data until linked to a colour that has an emitter (Collateral charts shows a placeholder; Bond postings falls back to the global/all-postings view).
Toolbar (top of the tab): the workspace tabs. There is no explanatory hint text in the toolbar (removed 04 Aug 2026). The ⟲ Reset layout button is no longer in the toolbar — it now lives on the Agreements control-panel widget (see §9's Agreements filter panel).
Default workspace (first load — migrate()): one workspace ws-1 named “Workspace 1” with three instances at these exact grid rects: Agreements {x:0,y:0,w:4,h:14} link {blue, emitter}; Collateral charts {x:4,y:0,w:8,h:14} link {blue, receiver}; Bond postings {x:0,y:14,w:12,h:9} link {null, receiver} (standalone). Workspace-level groupSel:{}, groupFilter:{blue: defaultFilter()}; every instance carries soloDim:"time" and pinned:false. So it ships pre-linked on blue (Agreements Emitter + Collateral-charts Receiver) and renders immediately, while the Bond-postings dock starts standalone (all postings). Note: these first-load sizes differ from the per-type catalog defaults used by Reset layout (CATALOG.def): Agreements 4×10, Collateral charts 9×11, Bond postings 12×9 — Reset unpins and re-tiles each type stacked at x=0 in the order Agreements → Collateral charts → Bond postings → Rules engine → Inventory Manager.
Persistence key: collat-workspaces-v2 — {active, order:[wsId…], ws:{wsId:{name, seq, instances:[{iid, type, x, y, w, h, pinned, soloDim, link:{color, role}}], groupSel:{color:{level, key, account, weight}}, groupFilter:{color:{gran, fromMs, toMs, refMs}}}}}. The Collateral charts instance also stores soloDim (time | agreement | source | type) — which of its four charts is shown; groupFilter holds each emitter colour group’s granularity + date window + reference date. Any layout saved under an earlier key is replaced by the default on first load.
Same page as Overview: Overview 2 is the same /j-collateral page. The host iframes it as /j-collateral?embed=1&widgets=1. On load the page runs its normal init (buildNav(); setTheme(localStorage["collat-theme-ds2"] || "light"); setLayout("tabs"); renderAll()); because it is embedded (window.self !== window.top) it hides its own top bar and listens for the host’s postMessage — {type:"theme", mode:"light"|"dark"} re-themes, {type:"setLayout", lay} is ignored in widget mode. Then, because ?widgets=1, the workspace-builder IIFE adds body.wmode (which hides the standard <main> and the Overview <aside> sidebar) and builds the toolbar + palette + canvas. The four-layout selector, the Split drag-handle/maximize/collapse and the Drawer/Single behaviours do not apply in Overview 2.
Standalone embed widgets (Rules engine & Inventory Manager). Two catalog entries embed an existing tool instead of re-implementing it, each as its own iframe filling the widget body (role:null, singleton:true): Rules engine (kind:"rules", def w:12 h:22) frames /j-collateraldemo?embed=1&only=rules (frame class wrules-frame, widget class wframe-rules); Inventory Manager (kind:"inventory", def w:12 h:20) frames /j-inventory (frame class winventory-frame, widget class wframe-inventory). The framed page hides its own top bar because window.self !== window.top, and follows the host’s {type:"theme"} messages. Because each is role:null its chain icon is removed (no colour group), and drawFn is a no-op — the embedded page draws itself, so edits made in the widget and in the corresponding top-level tab are the same data (one source of truth). In the offline standalone export both routes to the Inventory Manager — this widget and the Overview sidebar entry — have their iframe src rewritten to ./j-inventory.html, the copy of that page the bundle carries as its third file.

US9.15 As a developer, I can reproduce the exact demo data model and how it loads so Overview 2 shows identical figures with no backend.

Data loading & determinism

No backend / no live feed. Every figure is invented in-browser by a random-number generator that always starts from the same fixed number (its “seed”) — the generator is mulberry32, a “seeded PRNG” (pseudo-random number generator). Because the seed never changes, the “random” data comes out identical on every load — that is all “deterministic and reproducible” means. Time anchor: TODAY = 18 Jun 2026 UTC (Date.UTC(2026,5,18)), history START = TODAY − 1100 days, MS_DAY = 86400000 (the number of milliseconds in one day).
Seeds (the fixed starting numbers — a rebuild must use these exact values): the per-book time series uses mulberry32(424242); the bond inventory uses mulberry32(20260618); each agreement’s source/type weights use mulberry32(2000 + ai·131); the individual agreements of each type use mulberry32(8800 + ai·1337). Same seeds → same numbers every load.
User-maintained overrides (read from localStorage, shared with Requirements 1’s User-maintenance epics): collat-source-rules replaces the funding-source list that drives “By source”; collat-g7-map drives the G7 grouping of “By bond type”; collat-csa-list, collat-exposure-adjust, collat-inventory-adjust apply the same way they do on Overview.

The agreement book — 7 types (verbatim from the data engine)

Key	Name (sidebar)	Full name	Base ccy	Dot colour	Sub-books	Threshold $mm
bim	Bilateral CSA IM	ISDA / CSA — Initial Margin	USD	`#2563eb`	Euroclear · Clearstream (custodian)	0
bvm	Bilateral CSA VM	ISDA / CSA — Variation Margin	USD	`#60a5fa`	— single book	0
gmra	GMRA	GMRA — Repurchase	USD	`#10b981`	— VM-only, single book	12
gmsla	GMSLA	GMSLA — Securities Lending	EUR	`#34d399`	— VM-only, single book	18
ccp	CCP	CCP — Cleared	USD	`#8b5cf6`	IM · VM	0
fut	Futures	Futures / Cleared Derivatives	USD	`#22d3ee`	— single book	0
tri	Triparty	Triparty Collateral	SGD	`#6366f1`	Euroclear · Clearstream · BNY Mellon	25

Triparty (tri) is its own world — excluded from cross-category “All agreements” totals. agVals() for a sub-book type sums only the enabled sub-books (subEff()).
2 individual agreements per coded type (bim, bvm, gmra, gmsla, ccp, fut — not tri, see the next bullet). Account code = <LABEL>-NNN zero-padded (e.g. BIM-001, BIM-002). Each agreement gets a weight — its share of the type's total (a bigger weight = a bigger agreement): a raw size w = 0.3 + rng() is drawn, then all 100 are scaled so they add up to exactly 100% of the type (“normalised”): weight = w / Σw. Two yes/no flags are derived from each agreement's account code rather than at random, so the same agreements are always flagged: a zeroInterest flag = hashStr(account+"zi") % 3 === 0 (~1 in 3) and the margin-call-in-14-days flag = hashStr(account) % 10 < 3 (~30%); the per-type count of flagged agreements is MC_COUNT[type] = the orange (N) badge. hashStr(s) turns a piece of text into a stable number (the same text always gives the same number): h=0; for each char h=(h·31 + charCode) >>> 0.
Triparty's individuals are counterparties, one per triparty agent — there are no TRI-NNN codes. Build AGINDIV.tri by keeping the first INDIV_PER_TYPE counterparties that land on each triparty agent (2 per agent × 3 agents = 6 of the 111, so every agent keeps its own book — this is the one type that carries more than INDIV_PER_TYPE rows, by design): account = cpty = cp.name, and agent = subKeys("tri")[hashStr(cp.name+"triagent") % 3] (one of euroclear / clearstream / bny) — the agent rule is unchanged; the review-sized book simply stops at the first 2 counterparties that map to each agent, currently Euroclear: Brackwater Bank, Caldera Bank · Clearstream: Fernhollow Bank, Halvard Bank · BNY Mellon: Aldmoor Bank, Dunmore Bank. Raw size w = 0.3 + rng() from the same mulberry32(8800 + ai·1337) stream, then normalise within the agent: wAgent = w / Σw over that agent's counterparties (so each agent's counterparties total 100% of that agent). A static whole-book share is also kept for fallbacks: weight = wAgent · TRI_AGENTS[agent].base / Σ base, where the Σ runs over the agents that actually hold one of these counterparties, so the individual rows always add back to the Triparty total. zeroInterest is always false for triparty.
indivList(agKey, subsOn) is the single accessor every consumer uses. For non-tri types it returns AGINDIV[agKey] untouched. For tri it keeps only the counterparties whose agent is in subsOn (defaulting to all three) and re-weights each to its share of the books on show — weight = wAgent · posted(agent) / Σ posted(agents on show), reading refRec().ag.tri[agent].posted. That gives two guarantees: the listed rows always sum back to the sub-filtered type total, and a counterparty's own figure (typeTotal · weight) is invariant to which OTHER agents are toggled. Consumers: agSummaryRows() and renderMarginCalls() pass subEff("tri"); the Overview 2 Agreements widget passes new Set(selSubs(sel,"tri")); indivWeight(agKey,account) wraps it for openAgModal() and the Rules-engine context banner. Toggling a triparty agent OFF while one of its counterparties is the current selection drops the selection back to the type level. INDIV_IX maps every individual agreement name → {key, indiv} so agDetails() resolves a counterparty name to tri, fills Counterparty name from it, and shows Triparty / custodian as that counterparty's ONE agent rather than all three.
FX (USD per 1 unit): USD 1 · EUR 1.08 · GBP 1.27 · SGD 0.74 · JPY 0.0064.
Thresholds ($mm, per type): bim 0 · bvm 0 · gmra 12 · gmsla 18 · ccp 0 · fut 0 · tri 25.
Funding sources (7, drive “By source”): Interbank Repo · Flow Reports · HQLA · MI · CT · LMM · LRP (each posting is assigned one source using the fixed-seed random generator, with some sources more likely than others — a “seeded weighted pick”, so every load assigns the same sources; overridable via collat-source-rules).
Review-sized demo data — the three build numbers (developer note). The demo book is deliberately small so every figure can be checked by hand, and each dataset has exactly ONE number that controls how much of it is generated. Raise a number to repopulate with more dummy data; nothing else needs changing. INDIV_PER_TYPE (in j-collateral.html) = individual agreements per agreement type, currently 2 (Triparty takes that many counterparties per triparty agent, so it shows 6 rows). PER_INDUSTRY (in collat-inventory.js) = bond trades per issuer industry, currently 2 — with SIZE_SCALE = 130 / (PER_INDUSTRY × 5) multiplying each trade’s notional so the book’s total value stays in the range of the original 130-trade book (it becomes 1.0 at 26 per industry). POSTINGS_PER_BOOK (in j-collateral.html) = bond postings per agreement sub-book, currently 3, splitting the same unchanged money target across fewer postings. This one is not a free dial like the other two: it is the length of POSTED_TYPES, the fixed list ["UST","SGS","Corporates"]. Each book gets one posting of each type in that list, in that order. To repopulate with more postings per book, lengthen that list rather than the number.
Bond types (5): SGS · UST · Corporates · Supra · Agency, mapping to sectors SGS/UST→SOVGN, Supra/Agency→PBSEC, Corporates→CORPO.

US9.16 As a developer, I can reproduce the per-book generation and every core figure so Posted / Allocated / Unallocated and the individual-agreement split compute exactly.

Per-type generation profile (PROFILE) — the sample-data dials, verbatim

In plain English: the demo invents its own daily history — there is no real feed. Each agreement type has eight dials that shape its made-up numbers so they move like a real book. The table below is copied exactly from the code (a rebuild must use these exact values); what each dial means:

base — the book's normal size, in $mm (e.g. gmra sits around $520mm). Every other number is generated around this.
vol — day-to-day randomness: how much the number jumps from one day to the next (0.027 = choppy line, 0.011 = smooth line).
drift — slow growth across the year (0.06 ≈ the book grows ~6% over a year).
cover — how much collateral gets posted relative to what is owed (1.15 = posts ~115% of the obligation, so it runs a healthy unallocated; 0.93 = posts only ~93%, so it tends to show a deficit). This one dial decides which of the four situations a book is in, because Total posting = obligation × cover and every other figure follows from it: above 1 + threshold÷obligation the book leaves collateral unallocated; above 1 its margin call is negative and can be collected back; below 1 a call is due; and below 0.5 the call is bigger than everything the book has posted, so Surplus goes negative.
bondShare — the split of the posted collateral: the fraction that is bonds, the rest is cash (0.30 = 30% bonds / 70% cash).
phase — where in the calendar this book's seasonal peak lands, so the types don't all peak in the same month.
amp — how strongly this book swings with the seasons (1.40 = big seasonal swings, 0.85 = fairly flat).
rf — the received factor: how much collateral comes back in from counterparties, relative to the obligation (1.05 = receives ~105% of it).

Type	base	vol	drift	cover	bondShare	phase	amp	rf
bvm	240	0.022	0.02	1.15	0.30	4	1.30	1.13
bim	180	0.012	0.10	0.93	0.80	1	1.15	1.06
gmra	520	0.014	0.06	0.97	1.0	7	0.85	1.05
gmsla	300	0.016	0.04	1.10	0.90	10	1.10	1.06
ccp	410	0.018	0.09	1.06	0.55	2	1.25	1.07
fut	150	0.027	0.01	0.45	0.20	5	1.40	1.05
tri	360	0.011	0.07	1.04	0.92	8	0.95	1.05

Sub-book generation profiles (BIM_CUST, TRI_AGENTS, SUBPROF) — required to reproduce three of the seven types

Read this before using the PROFILE table above. Three types are not walked directly from their PROFILE row. Bilateral CSA IM, CCP and Triparty are generated one book per sub-filter, each from its own profile below, and the sub-books then add back to the type total. For these three, the PROFILE row seeds the sub-books rather than being walked itself; a rebuild that walks PROFILE directly will produce the wrong figures for them. The other four types (Bilateral CSA VM, GMRA, GMSLA, Futures) are single-book and do come straight from PROFILE. Note also that data models 10 & 14’s “one record per type per day” becomes one record per sub-book per day for these three.

// Bilateral CSA IM — one book per custodian (they sum to the IM total)
BIM_CUST = {
  euroclear:   {base:110, vol:0.013, drift:0.11, cover:1.06, bondShare:0.82, phase:0,  amp:1.10, rf:1.06},
  clearstream: {base:70,  vol:0.018, drift:0.05, cover:0.42, bondShare:0.74, phase:6,  amp:1.35, rf:1.06},
}

// Triparty — one book per agent (they sum to the Triparty total, base 360)
TRI_AGENTS = {
  euroclear:   {base:150, vol:0.012, drift:0.09, cover:1.22, bondShare:0.95, phase:7,  amp:0.90, rf:1.05},
  clearstream: {base:130, vol:0.014, drift:0.06, cover:0.93, bondShare:0.93, phase:11, amp:1.00, rf:1.05},
  bny:         {base:80,  vol:0.016, drift:0.07, cover:1.03, bondShare:0.90, phase:3,  amp:1.05, rf:1.06},
}

// CCP only — IM / VM derived from the CCP PROFILE row p (GMRA & GMSLA are VM-only, single book)
SUBPROF.ccp = {
  im: {base:p.base*0.40, vol:p.vol*0.8,  drift:p.drift*0.9, cover:CCP_COVER.im, rf:p.rf,
       bondShare: noCash ? 1.0 : Math.min(0.98, p.bondShare+0.05), phase:(p.phase||0)+1, amp:(p.amp||1)*0.8},
  vm: {base:p.base*0.60, vol:p.vol*1.25, drift:p.drift,     cover:CCP_COVER.vm, rf:p.rf,
       bondShare: noCash ? 1.0 : Math.max(0.10, p.bondShare-0.10), phase:(p.phase||0)+4, amp:(p.amp||1)*1.2},
}
// CCP_COVER = {im: 1.1872, vm: 0.9805} — each sub-book carries its own cover, the same
// way every book in BIM_CUST and TRI_AGENTS does, either side of the parent 1.06
// noCash = the agreement type does not accept Cash, so its sub-books stay all-bonds
SUBPROF.bim = {euroclear: BIM_CUST.euroclear, clearstream: BIM_CUST.clearstream}
SUBPROF.tri = {euroclear: TRI_AGENTS.euroclear, clearstream: TRI_AGENTS.clearstream, bny: TRI_AGENTS.bny}

Note the covers differ from the parent PROFILE row, deliberately: Bilateral CSA IM’s sub-books use 1.06 / 0.42 (not PROFILE’s 0.93), Triparty’s use 1.22 / 0.93 / 1.03 (not 1.04), and CCP’s sub-books carry their own 1.1872 / 0.9805 in CCP_COVER (not PROFILE’s 1.06). Each sub-book is placed on a different side of full cover so the custodian, agent and IM/VM toggles each move between different situations rather than showing the same one twice. The Triparty weight formula in US9.15 that cites TRI_AGENTS[agent].base reads its values from the table above.

The daily walk (evolveBook) — how obligation / posting / received are made

In plain English: each day the demo rolls every book forward one step — start from the book's trend size, let it wobble randomly, apply calendar effects (seasons, weekends, month-end, quarter-end), floor it so it never hits zero, then split the result into posted bonds/cash and collateral received. The exact formulas a rebuild must reproduce (rng = the seeded random-number generator, giving a value between 0 and 1):

Today's trend size — the book's normal size grown by its yearly growth dial: baseNow = base·(1 + drift·yearFrac) where yearFrac = dayIndex/365.
The wandering obligation — each day the amount owed (ob) is pulled 4.5% of the way back toward the trend (so it drifts but never runs away) and then nudged by a random daily shock sized by the book's randomness dial: ob += (baseNow − ob)·0.045 + (rng−0.5)·2·(vol·2.6)·baseNow.
Calendar effects — four multipliers make the line move like a real book: a yearly seasonal wave seas = 1 + amp·(0.22·sin((m+phase)/12·2π) + 0.10·sin((2m+phase)/12·2π)); a slow ~14-month cycle slow = 1 + amp·0.13·sin(i/430·2π + phase); a weekday wiggle (quieter weekends: 0.97 on Sat/Sun, else 1 + 0.013·sin((dow+1)·1.7)); a month-end build-up (dom≥26 → 1 + 0.10·(dom−25)/6) and a quarter-end bump (month%3===2 && dom≥24 → ×1.10).
Obligation (what is owed today) — the wandering value with all the calendar effects applied, floored at 35% of the trend so exposure never collapses to zero: max(baseNow·0.35, ob·seas·slow·weekday·monthEnd·quarterEnd).
Bond/cash split — the split (mix) drifts gently toward the book's bondShare dial, with a little noise: mix = clamp(0.05…0.99, mix + (bondShare−mix)·0.025 + (rng−0.5)·0.02).
Total posting (collateral put up) — the obligation times the cover dial, with ≈ ±3% noise: obligation·(cover + (rng−0.5)·0.060). Bonds = posted·mix; Cash = posted − bonds.
Received (collateral coming in) — the obligation times the rf dial, with ≈ ±2% noise: obligation·(rf + (rng−0.5)·0.04).

Core figures used by the Agreements widget & Key figures (exact)

Posted (Total posting) for a type = agVals(refRec, key).posted (with WLINK=null so it is the full, unscaled type total).
Exposure for a type = obligation + THRESH[key].
Allocated (Total allocated) = min(Posted, Exposure) — collateral utilised to cover exposure, capped at what is posted.
Unallocated = Posted − Allocated (green when ≥ 0, red when negative; the over-collateralisation remaining).
Per individual agreement (drill): Posted = typePosted · weight; Exposure = typeExposure · weight; Allocated = min(Posted, Exposure) — both already scaled once by the weight above; do not apply the weight a second time . Mechanically, WLINK is set to the agreement’s weight and agVals() multiplies oblig / posted / bonds / cash / received / unallocated by it — so a Receiver linked to an Emitter showing one individual agreement renders that agreement’s share of the type.
Sub-book types sum only enabled sub-books before scaling; All agreements = Σ over every type except tri — for Allocated too: allUsed = Σ min(agPosted(k), agExposure(k)) over the non-Triparty types, never min(Σposted, Σexposure), so the row equals the rows beneath it.

US9.17 As a developer, I can reproduce the Key-figures strip, the four charts and the bond-postings blotter so each widget renders exactly, at its own scope.

Key figures strip (renderCards) — 9 cards in this order, with formulas

The strip is not a standalone widget — one copy rides across the top of the Collateral charts widget (scoped to the agreement + filters it receives from its Emitter; hidden when the charts widget is unlinked) and one across the top of the Bond postings widget (scoped to what that table currently shows). Each card except Unallocated shows a Week/Week delta pill (prior = the same aggregate at reference − 7 days, rendered like ▼ -$14.0mm (-1.5%)).

Total exposure = Σ obligation of the selected agreements + selThreshold() (Σ THRESH of the selection)
Total posting = Σ posted
Bonds posted = Σ bonds
Cash posted = Σ cash
Total allocated = usedSel(rec).u = Σ_{a ∈ selection} min(posted_a, oblig_a + THRESH[a]) — per agreement, then summed. Not min(Σposted, Σexposure): the aggregate form lets one agreement’s unallocated cover another’s deficit and breaks the tie-out with the summary table (it read $2,095m where the rows added to $2,040m).
Bonds allocated = usedSel(rec).bu = Σ_a (posted_a ? used_a · bonds_a ÷ posted_a : 0) — each agreement split by its own posting mix
Cash allocated = usedSel(rec).cu, the same per-agreement split on cash (Bonds allocated + Cash allocated = Total allocated). Note the blended bonds share of Allocated need not equal the bonds share of the posting.
Unallocated = Total posting − Total allocated — green + word “unallocated” when ≥ 0, red + “deficit” when negative; no W/W pill
Received (inbound) = Σ received

The four charts (soloConfig) — segmented #soloDim toggle: Over time / By agreement / By source / By bond type

Over time (time) — a stacked bar chart: Bonds (allocated) (colour --bond = #0567f7) + Cash (allocated) (colour --cash) stacked, so the bars add up to Total allocated (usedSel(rec).bu / .cu — per agreement, capped at its own posting, each split by its own posting mix), plus two lines: Total posted (--txt, = aggSel(rec).po, which therefore runs on or above the bar tops — the gap is the unallocated) and Exposure (--exp, = obligation + selThreshold()). Buckets are the time series averaged per period at the current granularity. Y-axis beginAtZero, ticks "$"+value.toLocaleString(); tooltip " <series>: $Xmm". Click a bar → set the reference date to that bucket’s end (setRefAt). Matches the Overview history chart (no “Received” line).
By agreement (agreement) — a stacked bar, one dataset per selected agreement, each coloured with the agreement’s dot colour. Click a bar → toggle that agreement’s filter and reveal the postings table.
By source (source) — a horizontal bar, one bar per funding source, sorted descending, coloured from SRCCOLORS (a bar dims to --line when a source cross-filter excludes it); value labels on; x-axis grace 12% (12% of empty headroom is added past the longest bar so its value label fits). Click a bar → toggle that source cross-filter (xfSource).
By bond type (type) — a doughnut by G7 industry group (each posting classified via bondG7 against the collat-g7-map table — matched on Issuer Industry, and anything unmatched takes the table’s last row, the catch-all where every column is the default), colours G7_COLORS (an Unclassified slice uses --line), cutout 52% (the “cutout” is the empty hole in the middle of the doughnut — just over half the chart's diameter). The right legend shows each slice’s label + $value + %; slice tooltip " <label>: $X (pct%)". Click a slice → toggle that G7 cross-filter (xfG7). This is by G7 group, not raw bond type. The widget caps this chart’s width at 720px.

The selected chart persists per instance as soloDim ∈ {time, agreement, source, type}. A Collateral-charts widget renders its strip + chart under the agreement & filters of its Emitter; unlinked (or on an emitter-less colour) it shows the placeholder “This is a Receiver — link it to an Agreements Emitter: open the chain icon (🔗, top-right) and pick a colour group that has an Emitter. Without one, it shows no data.” and the Key-figures strip is hidden.

Bond postings widget — views, columns & scoping

The widget hosts the real docked postings panel (the same #dock DOM is moved into the widget body, and moved back when the widget is closed). It therefore exposes every dock view via its own segmented controls: Summary / Detailed, Postings / Bonds Maturing (T+N Ladder appears only when Triparty is selected), and Margin Calls, plus the “Maturing only ≤ N days” toggle with presets 7d / 30d / 90d / 180d / 1Y and the column ⚙ (show/hide, reorder, pin).
Column sets (identical to the Overview dock — Requirements 1 Epic 2): Summary / Detailed = the per-agreement table (Summary, per agreement type: Agreement, Total exposure, Call/obligation, Received (in), Margin call, Total posting, Bonds (Posted), Cash (Posted), Total allocated, Bonds (Allocated), Cash (Allocated), Unallocated (= Total posting − Total allocated), Surplus (= Total allocated − Margin call), DoD/WoW/MoM total allocated, Threshold, Expected post, Expected collect; Detailed, per individual agreement, adds: ITM/OTM Exposure, Dispute Value, Dispute Age, Base CCY, Base Total Exp., Base Call Amt). Postings / Postings by bonds / Bonds Maturing = Agreement Name, Trade #, ISIN, Security, Type, Sector, Counterparty, Agreement Type, Custodian, Source, Start date, Maturity, Maturing in Days, then the five amount fields — Original Ccy, Original Amount (what was posted, in the instrument’s own currency), Posted (USD) (the same amount in US dollars), Allocated (USD) (what TMO used), Unallocated (USD) (Posted minus Allocated). Postings by bonds takes the Postings column set minus Agreement Name and Trade # (both identify a posting, and its row is one bond of the one agreement — or one triparty repo agent — selected), and it shows no rows until one is selected: the postings of one bond are added together (Original Amount / Posted (USD) / Allocated (USD) summed, Unallocated (USD) = Posted − Allocated, Start date = the earliest posting), the ISIN footer counts them as “N bonds”, it opens sorted by Posted (USD) descending and keeps its own saved column layout. For an individual agreement its amounts are that agreement’s share of the type’s book. Margin Calls = the Daily Exposure Report columns + its 5 KPI tiles (Total Margin Call, Pending Review, Confirmed, No Call, Disputes).
Scoping: as a Receiver linked to an Emitter, the blotter filters to the Emitter’s broadcast selection (all → all; a type → that type). For the dock, WLINK is forced null, so the weight is not applied the way the charts apply it. The individual-agreement pick instead travels as a row filter: the Detailed and Margin-Calls rows carry that agreement’s share of the type, and the Key-figures cards above the table scale to the same share, while the bond-level Postings rows stay at whole-type amounts. Standalone / unlinked → the workspace’s global selection = all postings. Its Key-figures strip scopes to whatever the table currently shows.

Linking internals — exact helpers & colours

Colour set (6, verbatim): blue #3b82f6 · green #22c55e · amber #f59e0b · purple #a855f7 · pink #ec4899 · teal #14b8a6. A widget’s link = {color, role} where color ∈ those keys (or null = standalone) and role ∈ {emitter, receiver} is fixed by type via typeRole() (Agreements → emitter; Collateral charts, Bond postings → receiver).
Emitter selection per colour lives in groupSel[color] = {level:"all"|"type"|"indiv", key, account, weight}; its filter per colour in groupFilter[color] = {gran, fromMs, toMs, refMs}. A Receiver on a colour resolves its selection with recvSel() and its filter with effFilter() — both require hasEmitter(color), so a colour with no live Emitter yields no group data.
Helpers: emitterColors() = the set of colours that currently have an emitter; hasEmitter(c); freeEmitterColor() = first colour not used by an emitter (adding an Agreements widget auto-claims it); pruneOrphanReceivers() clears a receiver’s colour once its emitter is gone; coerceRolesByType() (run on load) forces each stored role back to its type’s role and re-frees any duplicate emitter colour. redrawGroup(color) re-renders every widget on a colour after the emitter changes.
chainChrome(): a link is “live” when color is set and (emitter, or receiver with a live emitter). Live → the widget gets a coloured outline (--wlink) and the chain button shows ⬆ (emitter) / ⬇ (receiver) with title "<Role> · <color> group"; otherwise the button shows 🔗 with title "Link — emitter / receiver".
Chain popover rows: a read-only Role label ("Emitter ⬆" / "Receiver ⬇"), a Group swatch row, and a Standalone (unlink) button. Receiver swatches = only colours that have an emitter; Emitter swatches = colours not used by another emitter (plus its own). Empty states: receiver → “No emitter groups yet — add an Agreements widget (it becomes an Emitter) first.”; emitter → “All colours are already in use by emitters.”

Persistence (collat-workspaces-v2) — schema, healing & save triggers

Schema: {active, order:[wsId…], ws:{ wsId:{ name, seq, instances:[{iid, type, x, y, w, h, pinned, link:{color, role}, soloDim}], groupSel:{color:{level,key,account,weight}}, groupFilter:{color:{gran,fromMs,toMs,refMs}} } }}.
load() healing: drop instances whose type ∉ CATALOG; ensure groupFilter exists; run coerceRolesByType() then pruneOrphanReceivers(); if the stored DB is missing/invalid, build the default via migrate(). The old keys collat-widgets-v2 / collat-widget-links-v1 are not migrated — an older layout simply falls back to the fresh default.
save() (writes the whole DB) fires on: load-time healing; drag end; resize end; pin toggle; reset layout; a filter change; ✕ Clear; an emitter selection change; a chain link change; add / close widget; a soloDim change; workspace rename / new / switch / close.

Exact UI strings (verbatim — reproduce these)

Toolbar: the workspace tabs only — no hint / instruction text (removed 04 Aug 2026).
Palette: header “Add widgets”; add-button title “Add to workspace”; singleton row suffix “ (single)”.
Widget bar buttons: chain title “Link — emitter / receiver”; pin “Pin — lock this widget’s position & size” / when pinned “Unpin — allow this widget to move & resize”; close “Close — remove from this workspace”; resize handle “Drag to resize”; header grip glyph “⋮⋮”.
Workspace tabs: add “＋” (title “New workspace”); per-tab close “✕” (title “Close workspace”); double-click a tab name to rename inline (Enter commits, Escape cancels).
Agreements filter panel: “✕ Clear” (title “Reset the agreement selection and reference date for this group”); “⟲ Reset layout” (title “Reset this workspace’s layout”); Reference chip shows the date + “● latest” (green) or “historical” (amber); column-header titles “Total posting” / “Total allocated” / “Unallocated = Total posting − Total allocated” / “Surplus = Total allocated − Margin call”; drill note “<Agreement> — individual agreements · posting / allocated / unallocated shown” with a “← Summary” back button; the (N) badge title “N agreement(s) with margin calls in the last 14 days”.
Agreements status note (linkNote): emitter → “Emitter · <color> group — receivers linked to this colour follow the agreement you pick here.”; receiver → “Receiver · <color> group — following its emitter’s selection.”; standalone → “Pick an agreement. This is an Emitter — open the chain icon (🔗, top-right) to give it a colour group so receivers can follow. Click a type to drill into its individual agreements.”

🧪 UAT test cases · Overview 2 — workspace builder

⚠ Do not run this pack — Overview 2 is retired

Decided 20 August 2026. Every test on this tab exercises the Overview 2 workspace builder, which is not being built. The screen is still in the demo, so the tests would still pass — passing them proves nothing about the system being delivered.

Test the Overview instead. Its test cases are on Requirements 1, inside each user story. The Optimization Results screen added on 26 Aug 2026 is tested there too — RULE-23 to RULE-35, under stories US11.10 to US11.15: both doors showing one run, the blotter’s decisions and totals, the scorecard arithmetic, the scenario board, the movement map reconciling to the blotter, and the shortfall board.
One section here is still live: the Data lineage matrix below still describes the master data sets the whole application uses. It is kept in step with the Data source catalog on Requirements 2 · Overview 2.
The pack is kept, not deleted, so the decision can be reversed without rewriting it.

A User Acceptance Testing (UAT) pack for Overview 2 only — the widget workspace builder. It is written for a tester with no prior knowledge of the system: every test can be run by following the words alone. Each test case traces to exactly one user story on the Requirements 2 · Overview 2 tab, whose stories are now grouped by widget and numbered US9.1–US9.17 (US9.1–US9.4 canvas & workspaces · US9.5–US9.7 Agreements widget · US9.8–US9.10 Collateral charts widget · US9.11–US9.13 Bond postings widget · US9.14 Key figures strip · US9.15–US9.17 developer build detail). The test IDs keep the form TC-9.<n>.<n> (they were not renumbered); the Traceability matrix at the bottom shows which current story each case verifies. Read the “How to use this pack” box first, then work top-to-bottom, running each case’s Steps and comparing what you see to the Expected result.

Scope: Overview 2 (the workspace builder) at /j-collateraldemo → Overview 2 tab — retired 20 Aug 2026, do not run this pack. · Last updated: 21 Aug 2026.

📝 Change log (click to expand)

(Unallocated and Surplus are now two different figures; the margin-call column is renamed (07 Aug 2026): the leftover figure used to be called Surplus, and it was written two different ways in this document — the on-screen note said what was posted minus what was used, an older appendix said what was received minus what was utilised. That is settled, and the naming changed with it. There are now two figures, each with one rule, applied the same way on the Overview and on Overview 2: Unallocated = Total posting − Total allocated (the collateral posted but not consumed — this is the figure previously called Surplus, and it is the same rule the postings screens have always applied to each bond line), and a new Surplus = Total allocated − Margin call. Both are columns on Agreement summary and Agreement summary — detailed. Postings, Postings by bonds and Bonds Maturing keep Unallocated (USD) = Posted (USD) − Allocated (USD), which is that same rule one bond posting at a time. The key-figures card and the Overview 2 Agreements widget column that read Surplus now read Unallocated — same figure, corrected name. The app works Total allocated, Unallocated and Surplus out in one shared place, so no two screens can drift apart. Received (in) is information only — it is displayed and totalled, and it never feeds Unallocated, Surplus, the margin call or any other worked-out figure. The agreement summary column “Total margin call” is renamed “Margin call” at both levels; its meaning is unchanged — Call / obligation − Total posting (positive = deliver collateral, negative = collect it back). Closes open questions OQ-17 and OQ-18 / Gap Log GAP-01; raises OQ-26 on the new Surplus figure, which comes out large and negative on every agreement.)(04 Aug 2026 — LRP removed from the Bond postings widget’s Summary / Detailed table, and from its column picker. The Margin Calls view keeps its own LRP column and the agreement detail popup still shows LRP.)(04 Aug 2026 — the workspace-builder toolbar hint and every “click / drag / sort / filter” instruction were removed from the Overview 2 screens, at the user’s request. Chart and table subtitles keep only what is shown and the as-at date. Nothing about the data, widgets, links or layout changed. See the Requirements 1 change log for the full list.)(04 Aug 2026 — Statement Status removed from the Bond postings widget’s Summary / Detailed table. The column is gone from that column set and from its column picker. The Margin Calls view of the same widget keeps its own Statement Status column, and the agreement detail popup still shows Statement status — only the Summary / Detailed set changed.)(04 Aug 2026 — the Over time chart now shows Total allocated as its bars, with Total posted as a line above them. The stacked bars used to be the collateral posted, split into bonds and cash, with the Total-posted line lying exactly on top of them (so the line told you nothing the bars did not). the bars are now the collateral allocated — Bonds (allocated) + Cash (allocated), adding up to Total allocated — and the Total-posted line sits above them, so the gap between the line and the bars is the unallocated you can now see at a glance. The bars tie to the Total allocated / Bonds (Allocated) / Cash (Allocated) figures on the Bond postings table and to the Allocated key-figures cards. To make that tie-out true, Allocated is now worked out one agreement at a time (each agreement capped at what it posted, split by its own bond/cash mix) and then added up, everywhere it appears — the chart, the key figures and the All agreements row of the Agreements panel. That closes the open item OQ-25 / gap G4: the All-agreements row now adds up to the type rows beneath it ($2,040m Allocated / $80m Unallocated, where it previously read $2,095m / $25m). TC-9.8.3 was extended to check Allocated and Unallocated, not just Posted.)(29 Jul 2026 — TC-9.9.10 rewritten for the renamed, scope-gated Postings by bonds view (was “Unique Bonds”): it now checks the button is present at every step, that with all agreements / a whole type / Triparty with several agents on there are no rows and the “Select an agreement…” message instead, that picking one individual agreement (GMRA-002) fills it so every row reads that agreement with no ISIN twice and its Posted total is the Postings total times that agreement’s share of its type, that Triparty with a single agent on fills it the same way with totals still equal to the Postings view, that widening the selection brings the message back, and that the aggregation is visible — 4 Clearstream postings become 3 bonds, with SGE5TU515VF4’s two lines ($20.31M + $30.17M) shown as one $50.48M row starting on the earlier date.) (29 Jul 2026 — design system applied: Overview 2 now follows the supplied design specification. Widget frames sit on the lighter card colour with a fine dark hairline, a small 4-pixel corner radius and a soft outer shadow; the header bar is 26 pixels tall and its title is in capitals, bold 14-pixel Public Sans, in the warning orange; the pin / link / close buttons are 26×26 squares with a 2-pixel radius that highlight white-on-hover, and the close button turns dark red. A widget joined to a colour group keeps that colour as a 2-pixel border and takes a stronger shadow. Widgets sit 6 pixels apart instead of 10 (grid constant GAP 10 → 6, so the row pitch is 40 pixels). Buttons, the segmented view switches and the date fields all take the shared button styling; the three full-screen overlays and the link pop-up use the dialog styling with a dimmed, blurred backdrop. No widget, field, column, control, key figure or calculation changed — presentation only.) (29 Jul 2026 — TC-9.9.11 added: picking one individual agreement in the Agreements widget must narrow the linked Bond postings Detailed view (and Margin Calls at individual level) to that agreement, so its Agreement column reads the counterparty picked, with the Key figures cards tying to that single row; the bond-level views stay on the whole type, and the type row widens everything back. The Data lineage matrix’s Bond postings row notes the same narrowing.)(29 Jul 2026 — TC-9.8.4 added: drilling Triparty must list the counterparties the selected triparty agent(s) handle, never “TRI-001 / TRI-002” codes, and a counterparty’s Posted must not move when a different agent is toggled. It also checks the agent-filtered list still adds back to the agent’s own Posted.)(29 Jul 2026 — TC-9.9.10 added for the blotter’s new Unique Bonds view (one row per agreement or triparty repo agent × unique bond; the column totals must match the Postings view; no agreement lists the same ISIN twice; the Custodian column is the triparty agent), and TC-9.9.6 now walks the Unique Bonds button too.) (29 Jul 2026 — three new cases for the Agreements widget’s per-type sub-filters: TC-9.4.6 (each type shows its own set — Bilateral CSA IM → Euroclear / Clearstream; Bilateral CSA VM → Zero-interest only; CCP → IM / VM; Triparty → Euroclear / Clearstream / BNY Mellon; GMRA, GMSLA, Futures → none), TC-9.4.7 (a sub-filter re-works Posted / Allocated / Unallocated and the same-colour receivers, the parts add back to the whole book, and the last book cannot be switched off) and TC-9.4.8 (CSA VM “Zero-interest only” narrows the individual list; picking another type starts fresh). TC-9.4.5 gained one expected-result line (✕ Clear also clears the sub-filter). No existing case’s steps or data changed.) (21 Jul 2026 — traceability re-alignment to the re-grouped Requirements 2 spec: the Requirements 2 stories are now grouped by widget and renumbered (US9.1–US9.4 canvas & workspaces; US9.5–US9.7 Agreements widget; US9.8–US9.10 Collateral charts; US9.11–US9.13 Bond postings; US9.14 Key figures strip; US9.15–US9.17 developer build detail). Every existing test case was re-mapped to the story it actually verifies under the new structure — no test’s steps, data or expected result changed (this was a re-grouping / renumber of the spec, not a behaviour change), and the TC ids were kept (not renumbered). The story-group headers, Contents index and Traceability matrix now name the current story numbers/titles, and a short Gap Log sits at the top of the matrix flagging the two user-facing stories with no dedicated case (US9.7 the Agreements field table; US9.12 maturing filter & column config).

(21 Jul 2026 — figure-traceability review (per the Frontend Test Strategy): aligned the pack with the Requirements 2 “🔎 Verifying the on-screen figures” checks so every documented figure check now has a test case. Strengthened TC-9.8.2 (the individual shares must add back to the type total, not just be smaller); added TC-9.8.3 (the type rows reconcile to “All agreements”, excluding Triparty), TC-9.9.8 (the charts reconcile to the KPI strip — the Over-time stacked bar = the Total posting card, By source & By bond type both add up to Bonds posted, doughnut % add to 100), TC-9.9.9 (the Week/Week pill = now − 7-days-ago, checkable); reworked TC-9.4.3 so the (N) badge is verified by its tooltip + its consistency across reloads, and flagged the gap that the per-agreement margin-call flag is not shown in the drill so N cannot be re-counted on screen. Set the Unallocated definition everywhere (derived figures, the verify checks, glossary, TC-9.4.2, TC-9.8.1) to exactly what it is — Total Posted minus Total Allocated, shown green (“unallocated”) when zero-or-positive and red (“deficit”) when negative, matching the app’s render — and removed the earlier claim that it is “always zero-or-positive / always green / red is a defect” (that was never a stated rule and the app has a live red/deficit path); and documented the Received (inbound) card’s source + how to check it (it was the one KPI card with no verification path).

(20 Jul 2026 — the Data lineage matrix now names data set 14 as Collateral used data (renamed from “Collateral balance used”) and traces the Bond-postings lines to its per-line fields (Position, Par, Market/Collateral Value, FX Rate); the full column dictionary is the collateral-used column dictionary on the Requirements 2 · Overview 2 tab. Earlier on 17 Jul 2026 — added a Data lineage matrix section (widget → data set & logic) plus two lineage test cases (TC-DL.1, TC-DL.2), tracing every Overview 2 widget back to the 15-set Data source catalog on the Requirements 2 tab; a tester can now see which data set feeds each widget’s figures. Earlier on 17 Jul 2026 — new tab. First release of the UAT pack for Overview 2, derived from the Requirements 2 · Overview 2 build spec (US9.1–US9.9) and the live workspace builder: covers add / duplicate / close, move / resize / pin / reflow, workspaces & persistence, the Agreements control panel, emitter/receiver colour linking, the widget catalog & defaults, the deterministic data model, the Posted / Allocated / Unallocated computations, and the Key-figures strip, four charts & bond-postings blotter — happy paths, negative & boundary cases, every dropdown option, empty states and hand-checkable calculations, plus a traceability matrix and a results summary sheet.)

🧪 How to use this pack (read first) — open Overview 2, reset to a clean state, run each case’s Steps vs Expected result

Open the app: go to jassica.sg/demo/collateral/ in a desktop browser (Chrome or Edge recommended, full-screen). No login is required. Then click the Overview 2 tab (2nd tab along the top).
Reset to a clean state BEFORE any case that says “fresh state”. Unlike the rest of the app, Overview 2 remembers your layout between visits, so you must reset or your saved widgets will be there instead of the default.
- Easiest — a private window: open a new private / incognito window (Chrome/Edge: Ctrl+Shift+N; Firefox: Ctrl+Shift+P), go to the link above and click Overview 2. You will see the default (one “Workspace 1” with three widgets). Close the private window when you finish to discard everything.
- Precise — clear stored data: in your normal window press F12 → Application tab → Local storage → select the site → delete every key starting with collat- (especially collat-workspaces-v2) → refresh the page.
Each test case has an ID, Preconditions, Test data, numbered Steps and a numbered Expected result. Do the Steps in order; if what you see matches the Expected result, mark it Pass. If not, mark it Fail, note the test ID, write what you saw instead, and take a screenshot.
This is demo data. Exact numbers, names and dates are sample values and will vary — they are not what you verify. Verify the behaviour, that the listed items are present, and that the stated relationships hold (e.g. two numbers add up to a third).
Record your results in the Results summary sheet at the bottom (ID / Pass / Fail / notes).
Don’t know a term? Every word you will see on screen is decoded in the Glossary below.
Plain document: you can select-all, copy and paste this whole pack into your own spreadsheet or test tool — there are no interactive controls to get in the way.

📑 Contents — Overview 2 test scenarios

A About Overview 2 & Glossary
9.1 Add, add again & close widgets
→ Req 2 US9.1 · TC-9.1.1 → TC-9.1.4
9.2 Move, resize, pin & reflow
→ Req 2 US9.2 · TC-9.2.1 → TC-9.2.4
9.3 Workspaces & persistence
→ Req 2 US9.3 · TC-9.3.1 → TC-9.3.5
9.4 The Agreements widget — select, drill & shared filters
→ Req 2 US9.5 (TC-9.4.1–9.4.3) & US9.6 (TC-9.4.4–9.4.5)
9.5 Link widgets by colour (emitter / receiver)
→ Req 2 US9.4 · TC-9.5.1 → TC-9.5.6
9.6 Palette, toolbar & default workspace
→ Req 2 US9.1 (TC-9.6.1–9.6.2) & US9.4 (TC-9.6.3)
9.7 Data model & determinism
→ Req 2 US9.15 · TC-9.7.1 → TC-9.7.2
9.8 Posted / Allocated / Unallocated computations
→ Req 2 US9.16 · TC-9.8.1 → TC-9.8.3
9.9 Key figures, four charts & blotter
→ Req 2 US9.8–US9.14 & US9.17 · TC-9.9.1 → TC-9.9.12
D Data lineage matrix — widget → data set & logic
T Traceability matrix
R Results summary sheet

ABOUT

About Overview 2 & Glossary

What this application is: Overview 2 is a build-your-own dashboard for a collateral-management team. You add movable boxes called widgets onto a canvas, arrange them (they never overlap), link some together so one controls the others, and keep several saved workspaces. The data (agreements, postings, charts) is realistic sample data generated in the browser — there is no live feed.

Glossary — every term you will see on screen

Workspace — a saved canvas of widgets. You can keep several (the tabs at the top); each has its own widgets and layout.
Widget — a movable box on the canvas. There are five kinds: Agreements, Collateral charts, Bond postings, Rules engine and Inventory Manager. The last two are Standalone: they never join a colour group, so they have no chain icon.
Palette — the “Add widgets” list down the left; its ＋ buttons add widgets.
Emitter (⬆) — a “control” widget that broadcasts its selection to others. The Agreements widget is always an Emitter.
Receiver (⬇) — a widget that follows an Emitter. Collateral charts and Bond postings are always Receivers.
Colour group / link — widgets sharing a colour are “linked”. The chain (🔗) icon on a widget sets which colour group it belongs to.
Pin (📌) — locks a widget’s position and size so it stays put when other widgets rearrange.
Reflow / compact — the automatic re-arranging that stops widgets overlapping (it pushes widgets down out of the way, then pulls the set back up to fill gaps).
Grid — the invisible 12-column layout that widgets snap to when you move or resize them.
Granularity — how time is grouped on the charts: Daily, Monthly or Yearly.
Quick range — a shortcut date window button: 1M, 3M, 6M, 1Y or 2Y.
Reference date (“as-at” date) — the date the figures are shown for. A green ● latest tag means today; an amber historical tag means a past date.
Agreement — a collateral contract with a counterparty. Agreements are grouped into types.
Agreement type — the category of agreement: Bilateral CSA IM, Bilateral CSA VM, GMRA, GMSLA, CCP, Futures, Triparty.
Posted — the total value of collateral posted for an agreement / type.
Exposure — the amount that needs covering (obligation + threshold).
Allocated — the collateral actually used to cover exposure = the smaller of Posted and Exposure.
Unallocated — the leftover (over-collateralisation) = Total Posted minus Total Allocated. Shown green (“unallocated”) when zero or positive, red (“deficit”) when negative.
Key figures (KPI strip) — the row of summary number-cards across the top of the Collateral charts and Bond postings widgets.
Blotter — the Bond postings table listing individual collateral postings.
Bonds vs Cash — the two forms collateral is posted in.
Funding source — where the collateral came from (drives the “By source” chart).
G7 group — an industry grouping bonds are bucketed into (drives the “By bond type” chart).
Margin call — a request from a counterparty to post more collateral.

TC 9.1

Add, add again & close widgets

US9.1 As a user, I can add widgets, add the same widget again, and close them from the palette.

TC-9.1.1 Add a widget from the palette

Preconditions: Fresh state (see “How to use”). On /j-collateraldemo, click the Overview 2 tab. You see a left “Add widgets” palette and a canvas holding three widgets (Agreements, Collateral charts, Bond postings).

Test data: none.

Steps:

In the left “Add widgets” palette, click the ＋ button on the “Collateral charts” row.

Expected result:

A new Collateral charts widget appears on the canvas, placed below the existing widgets and then compacted upward into the first free space; it renders a chart immediately. No existing widget is removed, moved off-screen, or overlapped.

TC-9.1.2 Add the same widget several times — independent copies

Preconditions: Overview 2 open.

Test data: add “Collateral charts” three times.

Steps:

Click ＋ on the “Collateral charts” palette row three times.
Move one of the new widgets.

Expected result:

Three new independent Collateral charts widgets appear, each rendering its own chart.
Moving one does not move the others — each instance is independent (can be moved / resized / closed / linked on its own).

TC-9.1.3 Bond postings is limited to one per workspace (negative)

Preconditions: Fresh state — the default workspace already has one Bond postings widget.

Test data: none.

Steps:

Look at the “Bond postings” row in the palette.
Try to click its ＋.
Close the existing Bond postings widget with its ✕, then look at the palette row again.

Expected result:

The “Bond postings” row shows the suffix “(single)” and is greyed out / disabled while one Bond postings widget is on the canvas.
Clicking its ＋ adds nothing — there is never a second Bond postings.
After closing it, the “Bond postings” palette row is enabled again.

TC-9.1.4 Close a widget — others compact up

Preconditions: A workspace with at least two widgets.

Test data: none.

Steps:

On a widget’s header, hover the ✕ button (its tooltip reads “Close — remove from this workspace”), then click it.

Expected result:

That widget is removed and the remaining widgets compact upward to fill the gap. If you closed the (single) Bond postings widget, its palette row re-enables.

TC-9.1.5 Rules engine & Inventory Manager — single-copy standalone widgets

Preconditions: Overview 2 open on a fresh workspace.

Test data: the palette rows Rules engine (single) and Inventory Manager (single).

Steps:

In the palette click ＋ on Rules engine, then ＋ on Inventory Manager.
Look at both palette rows again, and at the header buttons on each new widget.
Click ＋ on each of those two rows a second time.
Add an Agreements widget and pick GMRA in it. Watch the two new widgets.
Drag, resize and 📌 pin each of them, then refresh the page (F5).
Close both with ✕ and look at the palette once more.

Expected result:

Both widgets appear, each showing its full tool inside — the Rules engine shows the rules studio, the Inventory Manager shows the holdings summary bar and the bond table.
Both palette rows grey out while their widget is on the canvas, and clicking ＋ again adds nothing — only one copy of each is allowed.
Neither widget has a chain icon. They are Standalone: they never join a colour group, so picking GMRA in the Agreements widget changes neither of them.
Both take part in moving, resizing and pinning like any other widget, and both come back exactly as you left them after the refresh.
Closing them re-enables both palette rows.

TC 9.2

Move, resize, pin & reflow

US9.2 As a user, I can move, resize and pin widgets on a grid so the layout reflows and widgets never overlap.

TC-9.2.1 Move a widget — no overlap, others reflow

Preconditions: A workspace with at least two widgets side by side.

Test data: none.

Steps:

Point at a widget’s header bar (the strip with the ⋮⋮ grip + the title; the cursor becomes a “move” cross).
Drag it on top of another widget and drop.
Try to drag it off the left edge and off the top edge.

Expected result:

While dragging, the widget rises above the others (raised shadow + accent border) and snaps to the 12-column grid.
On drop, any widget it landed on is pushed down, and the rest compact up to fill gaps — no two widgets ever overlap.
It stops at the left/top edges (it cannot go to a negative position).

TC-9.2.2 Clicking a header button does NOT start a drag (negative)

Preconditions: Any widget on the canvas.

Test data: none.

Steps:

On a widget’s header, single-click the 📌 pin button (click, do not drag).

Expected result:

The pin toggles on/off; the widget does not begin moving. (Buttons, inputs, dropdowns and links inside the header never start a drag.)

TC-9.2.3 Resize a widget — minimum size, neighbours reflow

Preconditions: A widget with space around it.

Test data: none.

Steps:

Point at the resize handle at the widget’s bottom-right corner (a diagonal hatch; the cursor becomes a two-headed diagonal arrow; tooltip “Drag to resize”).
Drag it to make the widget much larger, then drag it to make the widget as small as possible.

Expected result:

Width/height change in whole grid steps; charts inside re-render live to fill the new size; any widget the larger size now covers is pushed out of the way — nothing overlaps.
It will not shrink below 2 columns × 2 rows — there is a hard minimum size.

TC-9.2.4 Pin locks a widget; others flow around it; unpin

Preconditions: At least two widgets.

Test data: none.

Steps:

Click 📌 on a widget (tooltip “Pin — lock this widget’s position & size”).
Try to drag it, and try to resize it.
Drag another widget onto its area.
Click 📌 again.

Expected result:

The pinned widget gets an accent border, its 📌 button is highlighted, and its resize handle disappears.
It cannot be moved or resized.
Other widgets flow around it as a fixed obstacle without overlapping it.
The second click unpins it (tooltip now “Unpin — allow this widget to move & resize”) and it can move again.

TC 9.3

Workspaces & persistence

US9.3 As a user, I can keep multiple workspaces and have everything persist and reset.

TC-9.3.1 Create, switch, rename & close a workspace

Preconditions: Overview 2 open on “Workspace 1”.

Test data: new workspace name = Repo desk.

Steps:

Click the ＋ next to the workspace tabs at the top (tooltip “New workspace”).
Click back to the “Workspace 1” tab, then back to the new tab.
Double-click the new tab’s name, type Repo desk and press Enter.
Click the new tab’s ✕ (tooltip “Close workspace”).

Expected result:

A new workspace tab opens and becomes active.
Switching tabs swaps in each workspace’s own widgets and layout.
The tab’s name changes to Repo desk and stays after you click away.
The ✕ closes it and moves you to a neighbouring workspace.

TC-9.3.2 A new workspace opens empty (empty state)

Preconditions: Overview 2 open.

Test data: none.

Steps:

Click ＋ to add a workspace and look at its canvas.

Expected result:

The canvas is empty — no widgets. You build it up from the palette. (Widgets are per-workspace; they are not shared between workspaces.)

TC-9.3.3 There is always at least one workspace (boundary)

Preconditions: Two or more workspaces.

Test data: none.

Steps:

Close workspaces one by one with their ✕ until only one remains.
Look at the last remaining tab.

Expected result:

The last remaining workspace tab has no ✕ button — you cannot close the final workspace; there is always at least one.

TC-9.3.4 Everything persists across a refresh

Preconditions: Overview 2 open.

Test data: 2nd workspace name = Repo desk.

Steps:

Add a Collateral charts widget, move it, resize it, then 📌 pin it.
Add a 2nd workspace and rename it Repo desk.
Refresh the browser (F5) and re-open the Overview 2 tab.

Expected result:

Every workspace, each widget (its type, position, size, pinned state, colour link, and the chosen chart), and the workspace you were on all re-open exactly as you left them. (Saved in the browser under collat-workspaces-v2.)

TC-9.3.5 Reset layout (lives on the Agreements widget)

Preconditions: A workspace whose widgets you have moved / resized / pinned, including the Agreements widget.

Test data: none.

Steps:

On the Agreements widget’s filter panel (at its top), find and click “⟲ Reset layout” (it sits next to “✕ Clear”; tooltip “Reset this workspace’s layout”).

Expected result:

The ⟲ Reset layout button is on the Agreements widget, not in the top toolbar. Clicking it unpins every widget and re-tiles the current workspace’s widgets into a tidy stack at their default sizes. Widgets are kept (not deleted) and their colour links are kept.

TC 9.4

The Agreements widget — select, drill & shared filters

US9.5 · US9.6 The Agreements widget (Emitter ⬆) — Requirements 2 US9.5 “Select & drill agreements” (verified by TC-9.4.1, TC-9.4.2, TC-9.4.3, and the per-type sub-filters by TC-9.4.6, TC-9.4.7, TC-9.4.8) and US9.6 “Set the shared filters & broadcast them” (verified by TC-9.4.4, TC-9.4.5).

TC-9.4.1 Row content, column legend & drill

Preconditions: Fresh state; look at the Agreements widget.

Test data: drill into GMRA.

Steps:

Read the single legend row at the top of the list.
Read the “All agreements” row and one type row.
Click the GMRA type row (it has a › chevron).
Click “← Summary”.

Expected result:

One legend row labels the money columns exactly once: Agreement · Posted · Allocated · Unallocated.
Below it: All agreements plus one row per agreement type — Bilateral CSA IM, Bilateral CSA VM, GMRA, GMSLA, CCP, Futures, Triparty — each with a colour dot, the name, an orange (N) badge, then three right-aligned values Posted / Allocated / Unallocated and a › chevron. The column labels appear only in the legend, not on every row.
Clicking GMRA highlights it and drills into its individual agreements (e.g. GMRA-001, GMRA-002, …) with the same Posted / Allocated / Unallocated columns.
“← Summary” returns to the type list.

TC-9.4.2 Unallocated = Posted − Allocated (calculation & colour)

Preconditions: Agreements widget visible.

Test data: read the three numbers off any one type row.

Steps:

On one type row, read Posted = A, Allocated = B and Unallocated = C.
Subtract: does C = A − B?

Expected result:

C equals A − B (to the displayed rounding) — Unallocated = Total Posted minus Total Allocated. It shows green (“unallocated”) when zero or positive and red (“deficit”) when negative. Worked example: if a row shows Posted $520mm and Allocated $500mm, Unallocated must read $20mm (520 − 500 = 20).

TC-9.4.3 The (N) active-agreements badge

Preconditions: Agreements widget visible.

Test data: none.

Steps:

Hover the orange (N) badge next to a type name and note the number N.
Open a fresh window (private/incognito), return to Overview 2 and read the same badge again.

Expected result:

A tooltip reads “N agreement(s) with margin calls in the last 14 days”.
N is the same on every fresh load (it is a fixed count, not random). Known limitation to raise (a gap): the individual-agreement drill rows do not show a per-agreement margin-call flag, so N cannot be independently re-counted anywhere on screen — its per-agreement basis is not surfaced. Verify the badge by its tooltip and its consistency across reloads; note the un-recomputable count as a gap for the Business Analyst.

TC-9.4.4 Filter panel drives the receivers + Reference chip; every dropdown option

Preconditions: Fresh state — the default workspace (Agreements = blue Emitter; Collateral charts = blue Receiver, showing data).

Test data: Granularity values to try: Daily, Monthly (the default), Yearly. Quick range presets to try: 1M, 3M, 6M, 1Y (the default), 2Y.

Steps:

In the Agreements filter panel, click Granularity = Yearly, then Daily, then back to Monthly.
Click each Quick range preset in turn: 1M, 3M, 6M, 1Y, 2Y.
Edit the From and To date boxes to a custom window.
Read the Reference chip.

Expected result:

The chosen Granularity button highlights, and the blue Collateral charts widget (and its Key figures strip) re-renders bucketed at that granularity.
Each Quick range preset highlights and re-renders the blue receivers over that window.
The From/To window is applied to the blue receivers.
The Reference chip shows the as-at date plus a green ● latest tag (or an amber historical tag when the window’s as-at date is before today).

TC-9.4.5 ✕ Clear resets the selection & reference (reset)

Preconditions: Agreements widget with a type selected and a non-latest reference date.

Test data: none.

Steps:

Pick a type in the list and change the reference date (e.g. click a bar on the Over-time chart of a linked receiver).
Click “✕ Clear” (tooltip “Reset the agreement selection and reference date for this group”).

Expected result:

The agreement selection returns to All and the reference date returns to latest (green ● latest). Only this colour group is affected — other colour groups keep their own selection.
If a sub-filter was in use, it is cleared too: re-select the type and every book button is back on with “Zero-interest only” off.

TC-9.4.6 Each agreement type shows its own sub-filter buttons

Preconditions: Fresh state; the Agreements widget visible, nothing selected.

Test data: the expected sets — Bilateral CSA IM → Euroclear, Clearstream · Bilateral CSA VM → Zero-interest only · CCP → IM, VM · Triparty → Euroclear, Clearstream, BNY Mellon · GMRA, GMSLA, Futures → none.

Steps:

Before selecting anything, look under every row in the list.
Click CCP; read the buttons that appear under it.
Click “← Summary” and check the buttons are still there under the CCP row.
Repeat for Bilateral CSA IM, Bilateral CSA VM, Triparty, then GMRA and GMSLA.

Expected result:

With nothing selected, no sub-filter buttons are shown anywhere.
The buttons appear only under the type you selected, and they are exactly the set listed in the test data for that type — no other type’s buttons appear.
They are shown in both places: under the type row in the summary list, and above the individual agreements after drilling in.
The book buttons (Euroclear / Clearstream / BNY Mellon / IM / VM) all start on (filled); “Zero-interest only” starts off.
GMRA, GMSLA and Futures show no buttons at all (they are single-book types).

TC-9.4.7 A sub-filter re-works the figures and the parts add back to the whole

Preconditions: Default workspace (Agreements = blue Emitter; Collateral charts = blue Receiver, showing data). Reference chip on ● latest.

Test data: CCP, at the latest reference date (18 Jun 2026), reads Posted $514M with both books on; $218M with IM only; $295M with VM only.

Steps:

Click the CCP row and write down its Posted figure with both buttons on.
Click IM to switch it off (VM only) and write the new Posted figure down.
Click IM back on and VM off (IM only); write that figure down.
Add the two single-book figures together and compare with step 1.
With one book off, read the Total posting card on the blue Collateral charts widget.
Try to switch the last remaining book off.

Expected result:

Switching a book off dims that button and immediately re-works the row: CCP reads $295M with VM only and $218M with IM only.
The parts add back to the whole: $218M + $295M = $513M, which is step 1’s $514M to within the displayed rounding. The cards show whole millions. The unrounded books are $218.3M and $295.2M, so $513.5M.
Allocated and Unallocated on that row, and the individual agreements after drilling in, are re-worked on the same narrower book — Unallocated is still Posted minus Allocated.
The blue Collateral charts widget follows: its Total posting card equals the Agreements row you filtered to ($295M for VM only). Widgets on another colour, or standalone, do not move.
The last remaining book cannot be switched off — the click is ignored and at least one book always stays on.

TC-9.4.8 CSA VM “Zero-interest only”, and a new type starts fresh

Preconditions: Agreements widget visible.

Test data: Bilateral CSA VM has 2 individual agreements, BVM-001 and BVM-002. Before starting, tag BVM-001 as Zero-interest CSA on User maintenance → Special agreements. Nothing is zero-interest until it is tagged there.

Steps:

Click Bilateral CSA VM to drill into its individual agreements and count them.
Click “Zero-interest only” and read the list again.
Click it a second time.
Click “← Summary”, select CCP, switch IM off, then select Bilateral CSA IM and read its buttons.
Go back to CCP.

Expected result:

The full list is 2 individual agreements.
With “Zero-interest only” on (button filled) the list narrows to the tagged agreement only — BVM-001. The money figures on the “All Bilateral CSA VM” row stay on the full CSA VM book.
Clicking again restores both rows.
Selecting a different type starts it fresh: Bilateral CSA IM shows Euroclear and Clearstream both on — CCP’s filter has not leaked across.
Going back to CCP also starts fresh — IM and VM both on again. Only one agreement type is filtered at a time, and moving away clears it.

TC 9.5

Link widgets by colour (emitter / receiver)

US9.4 Requirements 2 US9.4 — As a user, I can link widgets into colour groups where an Emitter broadcasts to same-colour Receivers, with roles fixed by widget type. (Verified by TC-9.5.1 → TC-9.5.6.)

TC-9.5.1 Chain popover — role is read-only; pick a colour or Standalone

Preconditions: Default workspace.

Test data: none.

Steps:

Click the chain icon (top-right) on the Agreements widget.
Close it, then click the chain icon on the Collateral charts widget.

Expected result:

The Agreements popover shows a Role row as a read-only label reading “Emitter ⬆” — there are no Emitter/Receiver buttons to choose. Below it are the Group colour swatches and a “Standalone (unlink)” button.
The Collateral charts popover shows the read-only role “Receiver ⬇” (same for Bond postings) — again no role buttons, only colour swatches and Standalone.

TC-9.5.2 Emitter broadcasts to same-colour receivers (happy)

Preconditions: Default workspace (Agreements = blue Emitter, Collateral charts = blue Receiver).

Test data: select GMRA.

Steps:

In the Agreements widget, click the GMRA type row.

Expected result:

The blue Collateral charts widget (and its Key figures strip) re-render for GMRA. A standalone widget, or a widget on a different colour, is not affected.

TC-9.5.3 Receiver on an emitter-less colour shows no data + reverts to standalone look (negative)

Preconditions: Default workspace (blue Emitter + blue Receiver, receiver showing data).

Test data: none.

Steps:

Confirm the blue Collateral charts widget is showing data.
Close the Agreements (blue Emitter) widget with its ✕.

Expected result:

The blue charts receiver immediately drops to its placeholder (“This is a Receiver — link it to an Agreements Emitter …”) and its Key figures strip hides.
Its blue outline and ⬇ chain icon revert to the standalone 🔗 look (the now-orphaned blue colour is cleared) — a widget never shows as linked to an emitter that isn’t there. No “phantom” data appears.

TC-9.5.4 A new Agreements widget auto-takes the next unused colour

Preconditions: Default workspace (one blue Agreements Emitter present).

Test data: none.

Steps:

Click ＋ on the “Agreements” palette row.
Open the new Agreements widget’s chain popover.

Expected result:

The new Agreements widget arrives as an Emitter on the next unused colour (blue is taken by the first one, so the second becomes green). Two emitters never share a colour.
Its chain popover offers only colours not already used by another emitter (plus its own).

TC-9.5.5 Receiver colour picker only offers colours that have an emitter (empty state)

Preconditions: Overview 2 open.

Test data: none.

Steps:

Add a new workspace (it is empty).
Add only a Collateral charts widget (no Agreements).
Open its chain popover’s Group row.
Now add an Agreements widget, re-open the charts popover and pick the emitter’s colour.

Expected result:

With no emitter present, the Group row reads “No emitter groups yet — add an Agreements widget (it becomes an Emitter) first.” and offers no colour.
After adding the Agreements widget, the charts popover now offers that emitter’s colour; picking it makes the charts render under that emitter.

TC-9.5.6 Independent colour groups don’t cross-affect

Preconditions: A workspace you will build up.

Test data: blue group shows GMRA; green group shows CCP.

Steps:

Build a blue pair (Agreements + Collateral charts on blue) and a green pair (a 2nd Agreements + a 2nd Collateral charts on green).
Pick GMRA in the blue Agreements and CCP in the green Agreements.

Expected result:

The blue charts show GMRA and the green charts show CCP — the two colour groups are independent and do not affect each other.

TC 9.6

Palette, toolbar & default workspace

US9.1 · US9.4 Canvas essentials — the palette that adds widgets and the toolbar hint trace to Requirements 2 US9.1 “Add, add again & close widgets” (TC-9.6.1, TC-9.6.2); the pre-linked-on-blue default workspace traces to US9.4 “Link widgets into colour groups” (TC-9.6.3).

TC-9.6.1 The palette lists exactly five widgets

Preconditions: Overview 2 open.

Test data: none.

Steps:

Read the “Add widgets” palette down the left.

Expected result:

The palette has exactly five rows and no others, in this order: Agreements, Collateral charts, Bond postings (single), Rules engine (single) and Inventory Manager (single).
The three rows marked (single) allow only one copy each: once one is on the canvas its palette row greys out and clicking ＋ again adds nothing. Agreements and Collateral charts carry no such mark and can be added as many times as you like.

TC-9.6.2 Toolbar hint text

Preconditions: Overview 2 open.

Test data: none.

Steps:

Read the hint line in the top toolbar (beside the workspace tabs).

Expected result:

The toolbar shows the workspace tabs and no hint or instruction text — the how-to-use sentence that used to sit there was removed on 04 Aug 2026. The ⟲ Reset layout button is not in the toolbar either (it is on the Agreements widget — see TC-9.3.5).

TC-9.6.3 Default workspace on first load (fresh state)

Preconditions: Truly fresh state — a private window or cleared storage.

Test data: none.

Steps:

Open Overview 2 for the first time.

Expected result:

There is one workspace named “Workspace 1” with exactly three widgets: Agreements (blue Emitter, on the left), Collateral charts (blue Receiver, on the right, already showing data), and Bond postings (standalone Receiver, across the bottom, showing all postings). The charts render immediately because the workspace ships pre-linked on blue.

TC 9.7

Data model & determinism

US9.15 Requirements 2 US9.15 (Developer build detail) — reproduce the exact demo data model and how it loads: the figures are deterministic on every fresh load and the seven agreement types are present. (Verified by TC-9.7.1, TC-9.7.2.)

TC-9.7.1 The figures are deterministic (identical on every fresh load)

Preconditions: Ability to open two fresh private windows.

Test data: the All agreements → Posted number.

Steps:

In a fresh private window open Overview 2; on the Agreements widget read the “All agreements” Posted value and write it down.
Close that window entirely; open a new fresh private window; open Overview 2 and read the same value.

Expected result:

The value is identical both times. (The demo data is generated from fixed seeds, so it never changes between fresh loads.)

TC-9.7.2 The seven agreement types are present

Preconditions: Agreements widget visible.

Test data: none.

Steps:

Read the Agreements list below the “All agreements” row.

Expected result:

There are exactly seven type rows: Bilateral CSA IM, Bilateral CSA VM, GMRA, GMSLA, CCP, Futures, Triparty. (Triparty is its own world — it is excluded from the “All agreements” cross-category total.)

TC 9.8

Posted / Allocated / Unallocated computations

US9.16 Requirements 2 US9.16 (Developer build detail) — reproduce the per-book generation and every core figure: Posted / Allocated / Unallocated, the individual-agreement split (shares add back to the type), and the “All agreements” roll-up (Σ of the types except Triparty). (Verified by TC-9.8.1, TC-9.8.2, TC-9.8.3.)

TC-9.8.1 Allocated = the smaller of Posting and Exposure; Unallocated = Posting − Allocated

Preconditions: Default workspace; the Collateral charts widget’s Key figures strip is visible.

Test data: read four cards off the strip.

Steps:

Read Total exposure = E, Total posting = P, Total allocated = U and Unallocated = S.
Check: is U the smaller of P and E? Is S = P − U?

Expected result:

U = min(P, E) and S = P − U (to the displayed rounding). Unallocated shows green (“unallocated”) when it is zero or positive and red (“deficit”) when it is negative. Worked example: if P = $500mm and E = $470mm, then U = $470mm and S = $30mm. If P = $450mm and E = $470mm, then U = $450mm and S = $0mm.

TC-9.8.2 An individual agreement is a share of its type — and the shares add back to the whole

Preconditions: Agreements widget visible.

Test data: drill into GMRA.

Steps:

Read the GMRA type row’s Posted value (call it the type total).
Click GMRA to drill in; read a few individual agreements’ (e.g. GMRA-001, GMRA-002…) Posted values.

Expected result:

Each individual agreement’s Posted is a fraction of (less than) the whole GMRA type’s Posted, and the drill shows the same Posted / Allocated / Unallocated columns.
The individual agreements are shares of the type — their shares add up to the whole type (100%), so the individual Posted figures sum back to the type total you read in step 1. Spot-check by adding the visible individual Posted values; they must reconcile to the type total (allow for the displayed rounding). If they do not add back, that is a defect.

TC-9.8.3 The type rows reconcile to “All agreements” (grand total)

Preconditions: Agreements widget visible, on the type-summary list (not drilled in).

Test data: the Posted, Allocated and Unallocated columns down the list.

Steps:

Read the All agreements row’s Posted value at the top.
Add up the Posted values of the individual type rows below it — Bilateral CSA IM, Bilateral CSA VM, GMRA, GMSLA, CCP, Futures — but leave out Triparty (Triparty is deliberately excluded from the All-agreements cross-category total).
Repeat for the Allocated column: add the same six type rows’ Allocated values and compare with the All-agreements row’s Allocated.
Repeat for the Unallocated column, and check that on every row Unallocated equals that row’s Posted minus its Allocated.

Expected result:

The sum of the six type rows (excluding Triparty) equals the All-agreements Posted figure (allow for the displayed rounding). The grand total is a real roll-up of the parts — it does not include Triparty. If the parts don’t add to the total, that is a defect.
Allocated adds up the same way: the six type rows’ Allocated equals the All-agreements Allocated (about $2,040m at the latest reference date), and Unallocated likewise (about $80m). Note that this is less than the smaller of the two grand totals (Posted about $2,121m against Exposure about $2,095m would give $2,095m) — that is correct and is the point of the check: rows where the type posted less than it owes (GMRA and Futures at the latest date) use only what they posted, and their shortfall is not made up by another type’s unallocated.
The same $2,040m / $80m must appear on the Total allocated and Unallocated key-figures cards and as the Total allocated footer of the Bond postings table.

TC-9.8.4 Drilling Triparty lists counterparties under their agent, never “TRI-001” codes

Preconditions: Agreements widget visible, on the type-summary list.

Test data: the Triparty row and its three agent buttons — Euroclear, Clearstream, BNY Mellon.

Steps:

Click the Triparty row to drill in.
Read the note above the list, then read the row names.
Read the All Triparty Posted figure at the top of the list (call it T), then note the number of rows below it and one row’s name and Posted (call them C and P).
Switch Clearstream and BNY Mellon off, leaving only Euroclear on, and read the list again.

Expected result:

The note reads “Triparty — counterparties handled by the selected triparty agent · posting / allocated / unallocated shown”.
Every row is a counterparty name — e.g. Brackwater Bank, Upperby Bank, Verdance Capital. No row may read “TRI-001”, “TRI-002” or any TRI-nnn code; triparty collateral is held by an agent on behalf of counterparties, so an agreement code is the wrong thing to show. Seeing one is a defect.
With all three agents on, 111 counterparties are listed and their Posted figures add back to T (allow for the displayed rounding).
With only Euroclear on, the list shrinks to just the counterparties Euroclear handles (about a third of them), All Triparty drops to Euroclear’s own Posted, and the shorter list adds back to that smaller figure.
If counterparty C is one Euroclear handles, its Posted is still P — an individual counterparty’s figure must not move when a different agent is switched on or off. If C is handled by another agent it must have disappeared from the list.

TC-9.8.5 Exposure = what’s owed plus the threshold cushion (calculation)

Preconditions: Default workspace; the Bond postings widget visible and switched to the Summary view.

Test data: the threshold cushion for each agreement type — GMRA $12m, GMSLA $18m, Triparty $25m, and $0 for Bilateral CSA IM, Bilateral CSA VM, CCP and Futures.

Steps:

On the Summary view find the three columns Total exposure, Call/obligation and Threshold.
For each row, subtract: Total exposure minus Call/obligation.
Compare each answer with that row’s Threshold column.

Expected result:

For every row the difference equals that row’s Threshold exactly: $12m for GMRA, $18m for GMSLA, $25m for Triparty, and $0 for Bilateral CSA IM, Bilateral CSA VM, CCP and Futures — those four show Total exposure equal to Call/obligation.
Worked example: if GMRA’s Call/obligation reads $635.9m, its Total exposure must read $647.9m. Any other gap is a defect.

TC-9.8.6 Bonds (Allocated) on the GMRA row, traced end to end (calculation)

Preconditions: Default workspace; the Bond postings widget visible and switched to the Summary view.

Test data: the GMRA row. From it read six figures: Total exposure, Total posting, Bonds (Posted), Cash (Posted), Total allocated and Bonds (Allocated).

Steps:

Check that Total allocated is the smaller of Total posting and Total exposure.
Work out the bond share of the posting: divide Bonds (Posted) by Total posting.
Multiply Total allocated by that share. Compare the answer with Bonds (Allocated).
Read the Unallocated column on the same row.

Expected result:

Bonds (Allocated) equals Total allocated multiplied by the bond share of the posting, to the displayed rounding. Worked example: Total posting $600m of which Bonds (Posted) $594m, Total allocated $600m → bond share 99%, so Bonds (Allocated) must read about $594m.
GMRA is deliberately set up to post less than it owes, so Total posting is below Total exposure. That means Total allocated equals Total posting and Unallocated reads $0m.
Because GMRA is posted almost entirely in bonds, Bonds (Allocated) is within rounding of Bonds (Posted). A GMRA row where Total allocated is below Total posting, or where Unallocated is not zero, is a defect.

TC 9.9

Key figures, four charts & blotter

US9.8–US9.14 · US9.17 The Collateral charts, Bond postings & Key figures widgets. Per case: US9.14 what the strip shows (TC-9.9.1); US9.17 strip/chart reproduction & checks (TC-9.9.2 KPI arithmetic, TC-9.9.8 charts↔strip reconcile, TC-9.9.9 W/W pill); US9.8 switch the four charts (TC-9.9.3); US9.9 chart drill / cross-filter (TC-9.9.4); US9.10 what the Collateral charts widget shows — receiver placeholder (TC-9.9.5); US9.11 switch the blotter view (TC-9.9.6, which also exercises US9.12 maturing filter & column config — see Gap Log); US9.13 what the Bond postings widget shows — scoping (TC-9.9.7).

TC-9.9.1 Two Key-figures strips, nine cards in order

Preconditions: Default workspace (Collateral charts + Bond postings both present).

Test data: none.

Steps:

Look at the top of the Collateral charts widget and the top of the Bond postings widget.
Read the cards left-to-right.

Expected result:

There is no standalone “Key figures” widget — one KPI strip rides across the top of the Collateral charts widget and one across the top of the Bond postings widget.
Each strip has nine cards in this exact order: Total exposure, Total posting, Bonds posted, Cash posted, Total allocated, Bonds allocated, Cash allocated, Unallocated, Received (inbound). Every card except Unallocated shows a small week-on-week delta pill; Unallocated shows the word “unallocated” (green) or “deficit” (red) instead.

TC-9.9.2 Key-figures arithmetic identities (calculation)

Preconditions: A Key figures strip visible.

Test data: read six cards.

Steps:

Read Bonds posted, Cash posted and Total posting.
Read Bonds allocated, Cash allocated and Total allocated.
Divide Bonds allocated by Total allocated, and divide Bonds posted by Total posting. Compare the two answers.

Expected result:

Bonds posted + Cash posted = Total posting (to the displayed rounding).
Bonds allocated + Cash allocated = Total allocated (to the displayed rounding).
The two ratios in step 3 match. Allocated is split into bonds and cash in the same proportion as the posting was, so the bond share of Allocated must equal the bond share of the posting. Worked example: Total posting $2,120m of which Bonds posted $1,490m (70%), and Total allocated $2,095m → Bonds allocated must read about $1,473m, i.e. 70% of Allocated.
A strip where Allocated is below Posted but Bonds allocated still equals Bonds posted is a defect — that would mean the cash side absorbed the whole reduction instead of the two sharing it proportionally.

TC-9.9.3 Chart toggle — four dimensions, remembered

Preconditions: A linked Collateral charts widget showing data.

Test data: the four toggle buttons.

Steps:

On the Collateral charts widget click each segmented button in turn: Over time (default), By agreement, By source, By bond type.
Leave it on By source, refresh the page and re-open Overview 2.

Expected result:

Over time = stacked Bonds (allocated)+Cash (allocated) bars with a Total posted line and an Exposure line; By agreement = stacked bars, one per selected agreement; By source = horizontal bars per funding source, sorted largest-first; By bond type = a doughnut by G7 group with a legend of label + $ + %.
After refresh the widget re-opens still on By source — the chosen chart is remembered per widget.

TC-9.9.4 Chart clicks drill / cross-filter

Preconditions: A linked Collateral charts widget.

Test data: none.

Steps:

On Over time, click one of the bars.
On By source, click one bar.
On By bond type, click one doughnut slice.
On By agreement, click one bar.

Expected result:

Clicking an Over-time bar sets the reference date to that period’s end.
Clicking a By-source bar toggles that funding-source cross-filter (the bar dims when it is excluded).
Clicking a By-bond-type slice toggles that G7 cross-filter.
Clicking a By-agreement bar toggles that agreement’s filter and reveals the postings table.

TC-9.9.5 Unlinked Collateral charts → placeholder, strip hidden (empty state)

Preconditions: A linked Collateral charts widget showing data.

Test data: none.

Steps:

Open the Collateral charts widget’s chain popover and click “Standalone (unlink)”.

Expected result:

The widget shows the placeholder “This is a Receiver — link it to an Agreements Emitter: open the chain icon (🔗, top-right) and pick a colour group that has an Emitter. Without one, it shows no data.” and its Key figures strip is hidden.

TC-9.9.6 Bond postings blotter — views, maturing presets & column ⚙

Preconditions: A Bond postings widget on the canvas.

Test data: maturing presets to try: 7d, 30d, 90d, 180d, 1Y.

Steps:

Use the segmented controls: Summary / Detailed; Postings / Postings by bonds / Bonds Maturing; Margin Calls. (Postings by bonds needs one agreement, or one triparty agent, selected before it has rows — TC-9.9.10 covers that.)
Turn on “Maturing only ≤ N days” and try each preset (7d, 30d, 90d, 180d, 1Y).
Open the column ⚙ and hide, reorder and pin a column.

Expected result:

Each control switches the table to the matching view.
The maturing toggle filters the list to bonds maturing within the chosen number of days.
The column ⚙ lets you show/hide, reorder and pin columns. (A T+N Ladder view appears only when Triparty is the selected agreement.)

TC-9.9.7 Bond postings scoping (standalone vs linked)

Preconditions: Default workspace (Bond postings starts standalone; a blue Agreements Emitter is present).

Test data: link Bond postings to blue; select GMRA.

Steps:

With Bond postings standalone, note what the blotter shows.
Open its chain popover and link it to the blue group; then in the Agreements widget pick GMRA.

Expected result:

Standalone, the blotter shows the workspace’s global selection = all postings.
Linked to blue, it filters to the emitter’s selection (GMRA), and its Key figures strip scopes to what the table shows. (Bond postings is never an emitter — it does not broadcast to anything.)

TC-9.9.8 The charts reconcile to the Key-figures strip (calculation)

Preconditions: A linked Collateral charts widget showing data, with its Key-figures strip visible.

Test data: compare the charts against the strip cards above them.

Steps:

On Over time, look at the most recent stacked bar (Bonds (allocated) + Cash (allocated)) and read the Total allocated, Total posting and Unallocated cards on the strip.
Switch to By bond type; read the doughnut slice labels (each shows a value and a %) and the Bonds posted card.
Switch to By source; read the funding-source bars and the Bonds posted card.

Expected result:

On Over time the height of the latest stacked bar (Bonds (allocated) + Cash (allocated)) equals the Total allocated card, and its two segments equal the Bonds allocated and Cash allocated cards — but only with Granularity set to Daily. At Monthly or Yearly each bar is the average across that whole period while the card is the figure as at the reference date, so the two legitimately differ (on the default Monthly view by around 1–3%); that difference is not a defect. Set Granularity to Daily on the Agreements panel before comparing. The same Daily bar must also equal the Total allocated / Bonds (Allocated) / Cash (Allocated) footer totals on the Bond postings table for the same selection.
The Total posted line runs above the stacked bars, and the vertical gap between the line and the bar tops equals the Unallocated card — the collateral posted but not used. The line is drawn in the ordinary text colour (white on the dark theme), not green. A line dipping below the bar tops is a defect (nothing can use more than was posted); the line meeting the bars exactly means the whole posting is being used and Unallocated is zero.
On By bond type the doughnut slice values add up to the Bonds posted card, and the slice percentages add up to 100%.
On By source the funding-source bars add up to the Bonds posted card (this chart shows bonds only, not cash). Every chart ties back to a number on the strip — none shows a figure that can’t be reconciled.

TC-9.9.9 The Week/Week delta pill is checkable (calculation)

Preconditions: A linked Collateral charts widget and its Agreements control panel. Note the reference-date chip is a read-out, not a control — the To date picker is what moves the reference date.

Test data: the Total posting card and its W/W pill.

Steps:

Read the Total posting card’s value now (call it Now) and the small Week/Week pill under it (an amount and a %).
On the Agreements panel set the To date back 7 days, and read the Total posting card again (call it Then).

Expected result:

The pill’s amount equals Now minus Then, and the pill’s % equals that change divided by Then (allow for the displayed rounding). Up-moves show green with an up arrow, down-moves red with a down arrow. Every card except Unallocated has such a pill; the pill is a real comparison you can reproduce, not a decoration.

TC-9.9.10 Postings by bonds — always visible, empty with a prompt until one agreement or one triparty agent is picked

Preconditions: Default workspace with a blue Agreements Emitter; the Bond postings widget linked to blue (chain icon 🔗 → blue).

Test data: agreement type GMRA and individual agreement GMRA-002; triparty agent BNY Mellon. Write down, from the Agreements widget: All GMRA’s Posted figure and GMRA-002’s Posted figure. Also note the Posted (USD) column total in the blotter footer where there is one. For the aggregation check, the bond posted twice under BNY Mellon is SGTAEZ1GFSY0 (MAS BILL 4% 05/27): $19.7M from 29 Sept 2025 and $16.0M from 19 Mar 2026.

Steps:

With All agreements showing, click Postings by bonds. Read the title and whatever appears where the table would be.
Click the GMRA row (the type) — the whole agreement type, no individual agreement. Look again.
In the drilled list click GMRA-002. Read the title, then read down the Agreement Name and ISIN columns, and read the Posted (USD) footer total. Switch to Postings, note its footer total for the same selection, and switch back.
Click the GMRA type row again to widen the pick, and watch the panel.
Go ← Summary → click Triparty with all three agents on, and look at the panel. Then switch off Euroclear and Clearstream so only BNY Mellon is on. Read the title, the Custodian column and the Posted (USD) footer total, and compare that total with the Postings view’s under the same selection. Switch Euroclear back on.

Expected result:

The Postings by bonds button is present at every step — it is never hidden, so the view is always findable. So are the other view buttons and the column ⚙.
For All agreements and for the whole GMRA type there are no rows. In place of the table you read “Select an agreement to see the bonds posted to it”, with the two lines telling you to click an agreement name (for example GMRA-002) or, for Triparty, to pick one agent — Euroclear, Clearstream or BNY Mellon — because triparty collateral is held with the agent, not under an agreement code. The title is plain “Postings by bonds”. It must NOT list every agreement’s bonds instead.
Picking GMRA-002 replaces the message with rows: the title becomes “Postings by bonds — GMRA-002”, every row’s Agreement Name is GMRA-002, no ISIN appears twice (postings of one bond on several dates are added into a single row whose Start date is the earliest), and each row reads across as Unallocated (USD) = Posted (USD) − Allocated (USD).
GMRA-002’s Posted (USD) total is much smaller than the Postings view’s for the same selection: it is that total multiplied by GMRA-002’s share of GMRA. Check it — GMRA-002’s Posted ÷ All GMRA’s Posted (from the Agreements widget) is that share (allow the displayed rounding).
Widening back to the GMRA type brings the “Select an agreement…” message straight back, with no rows.
Triparty with all three agents on shows the same message — an agent has not been named yet. With only BNY Mellon on, the title reads “Postings by bonds — Triparty BNY Mellon”, every Custodian cell reads BNY Mellon, there is no Agreement Name or Trade # column (the Counterparty column keeps whose collateral each bond is), and the Posted (USD) total equals the Postings view’s for the same selection — for an agent the view only groups the same postings, so no money moves. Switching Euroclear back on returns the message.
The aggregation is visible. Under BNY Mellon the Postings view lists 4 lines but Postings by bonds lists 3 bonds (the ISIN footer says “3 bonds”), because bond SGTAEZ1GFSY0 was posted twice: $19.7M from 29 Sept 2025 and $16.0M from 19 Mar 2026. Its single row here reads $35.7M — the two added together — with Start date 29 Sept 2025, the earlier of the two. Add the two Postings lines by hand and they must equal that row.

TC-9.9.11 The blotter’s Agreement column follows the agreement picked in the Agreements widget

Preconditions: Default workspace with a blue Agreements Emitter; the Bond postings widget linked to blue (chain icon 🔗 → blue).

Test data: agreement type Triparty, counterparty Fernhollow Bank (any counterparty in the list will do — just use the same one throughout). Write down Fernhollow Bank’s Posted, Allocated and Unallocated as the Agreements widget shows them.

Steps:

In the Agreements widget click Triparty to drill in, then click the Fernhollow Bank row.
On the Bond postings widget click Detailed. Count the rows and read the Agreement column.
Compare that row’s Total posting with the Posted you wrote down, and compare the row across to the Key figures cards above the table.
Click Margin Calls, then click Postings.
Go back to the Agreements widget and click the All Triparty row.

Expected result:

The Fernhollow Bank row is highlighted in the Agreements widget.
The Detailed table shows exactly one row and its Agreement column reads Fernhollow Bank — the same counterparty picked in the Agreements widget. The line under the panel title names it: “Summary by individual agreement — Fernhollow Bank, as at …”.
The row’s Total posting equals the Posted you wrote down, and the Key figures cards equal that single row figure for figure (allow the displayed rounding — the cards show whole millions): Total exposure ↔ Total exposure, Total posting ↔ Total posting, Bonds posted ↔ Bonds (Posted), Cash posted ↔ Cash (Posted), Total allocated ↔ Total allocated, Unallocated ↔ Unallocated.
Margin Calls also lists Fernhollow Bank alone. Postings lists the whole of Triparty’s bond lines — that is correct and expected: collateral is posted at agreement-type level, so there is no per-counterparty posting line, and the Key figures go back to the Triparty totals to match what that table shows.
Back on the type row the Detailed table widens again to every Triparty counterparty and the Key figures return to the type totals. A table still listing every counterparty while one counterparty is highlighted in the Agreements widget is a defect.

TC-9.9.12 Received (inbound) is scoped and repeatable (calculation)

Preconditions: Default workspace with a blue Agreements Emitter and a blue Collateral charts widget.

Test data: the Received (inbound) card, the right-hand card on the Key figures strip.

Steps:

With All agreements selected, write down the Received figure.
In the Agreements widget click GMRA. Write the Received figure down again.
Click CCP instead and write it down a third time.
Open Overview 2 again in a brand-new browser window and read the All-agreements Received figure.

Expected result:

Received changes with each selection — it is scoped to whatever the Agreements widget is broadcasting, exactly like the other cards. A figure that never moves is a defect.
Unlike the other cards it does not add up with them: it is inbound collateral counterparties posted to us, while the rest are outbound. Do not expect it to equal Posted minus Allocated or any other combination.
The fresh window shows the identical All-agreements figure — the demo figures are the same on every load.

DATA

Data lineage matrix — widget → data set & logic

Overview 2 is fed by a fixed master list of data sets (the “Data source catalog” on the Requirements 2 · Overview 2 tab) — the 15 top-level sets, with the user-maintained set (7) broken out into its eight datasets 7.1 Cost of funds · 7.2 G7 industry group · 7.3 Source of collateral · 7.4 Exclude CSA · 7.5 Adjusting exposures · 7.6 Adjusting inventory · 7.7 Tags & highlights · 7.8 G7 by bond. This matrix shows, for a tester, which widget uses which data set and what it does with it, so you can trace any number on screen back to its source. Numbers in the Data sets column refer to that catalog. A tester does not need to verify the catalog itself — use this to understand where each widget’s figures come from, and to run the lineage checks below. The two lineage cases trace to the “what this widget shows” stories on Requirements 2: TC-DL.1 → US9.10 (Collateral charts) and TC-DL.2 → US9.13 (Bond postings).

Widget	Data sets used (catalog #)	What the widget does with them
Agreements (control panel, Emitter)	6 Agreements static · 1 Counterparty static (Triparty drill) · 10 Exposures & margin calls · 14 Collateral used data · 8 FX	Lists the 7 agreement types + drill to individual agreements; shows Posted / Allocated / Unallocated and the (N) margin-call badge; broadcasts its pick + filters to linked widgets. Drilling Triparty lists the counterparties the selected triparty agent(s) handle (Counterparty static, set 1) rather than agreement codes, because triparty collateral is held by an agent on a counterparty’s behalf.
Collateral charts (Receiver)	14 Collateral used data · 10 Exposures · 6 Agreements static · 7.3 Source of collateral · 7.2 G7 industry group · 2 Bond/securities static · 8 FX	Draws Over time / By agreement / By source / By bond type. On Over time the bars are the collateral allocated (set 14 capped, agreement by agreement, by that agreement’s exposure from sets 10 + 6) and the Total-posted line is the posting from set 14 uncapped, so the gap between them is the unallocated. The By-source bars use the user’s Source-of-collateral rules and the By-bond-type doughnut uses the user’s G7 mapping (the collateral line's Asset Class) — every bond is matched to a row of that mapping table on its Issuer Industry, and a bond that matches no row is grouped under the table's last row, the catch-all where every column is the default, so no slice ever carries a group that is not in the table.
Bond postings (Receiver, single)	15 Inventory data · 2 Bond/securities static · 1 Counterparty static · 7.3 Source of collateral · 14 Collateral used data · 10 Exposures & margin calls · 6 Agreements static · 5/8 Currency / FX	The postings blotter (Summary / Detailed / Postings / Postings by bonds / Bonds Maturing / Margin Calls); the Counterparty column comes from counterparty data, the Source column from the user’s rules, the Margin Calls view from exposures & calls, and each posting line's own fields (Position, Par, Market/Collateral Value, FX Rate) from Collateral used data (set 14 · the collateral-used column dictionary). The Unallocated (USD) column derives posted-minus-used per line entirely from set 14 (posted & used amounts; coverage from sets 10 + 6), and the Postings by bonds view only narrows those same lines to one agreement (or one triparty agent) and groups them by bond — neither introduces a new data source. When the Agreements widget broadcasts one individual agreement, the per-agreement views (Detailed, and Margin Calls at individual level) list that agreement alone — its figures being the type’s figures scaled by that agreement’s share of the type (sets 10 + 14 + 6); the bond-level views Postings and Bonds Maturing stay on the whole type, since set 14 holds the postings at agreement-type level, while Postings by bonds shows that agreement’s share of them.
Rules engine (standalone)	15 Inventory data · 10 Exposures & margin calls · 6 Agreements static · 2 Bond / securities static · 4 Portfolios static · 11 Optimization rules · 12 Optimization outputs · 13 Optimization exclusions & exceptions · 14 Collateral used data (Delivered rows — only when Sweep the deck is off)	Embeds the full rules studio as a widget. It neither emits nor receives an agreement selection, so it never joins a colour group and never follows the Agreements widget. One copy per workspace.
Optimization Results (standalone screen, five views)	None of its own — it reads the Rules engine’s published result, which is built from 15 Inventory data · 10 Exposures & margin calls · 6 Agreements static	Presents ONE run five ways — approval blotter, benefits scorecard, scenario board, movement map, shortfall board. It never recomputes a figure: every number is read from the answer the optimiser published, so a view cannot disagree with the run that produced it. The scenario board is the one exception to “one run”: it runs each OTHER saved run through the same optimiser to fill its columns, then restores the active run.
Inventory Manager (Standalone, single)	15 Inventory data · 2 Bond/securities static · 8 FX	Embeds the standalone Inventory Manager (the `/j-inventory` page) as a widget — the holdings summary bar by category, the “Snapshot as-at” date picker, the View toggle and the transaction-level bond-trade table. It is the same tool as the top-level Inventory Manager tab; it never joins a colour group.
Key figures strips (on charts & postings)	14 Collateral used data · 10 Exposures · 2 Bond/securities static	The nine KPI cards (Total exposure, Total/Bonds/Cash posted, Total/Bonds/Cash allocated, Unallocated, Received), each computed for the host widget’s own scope. The three allocated cards are worked out one agreement at a time (each capped at its own posting) and then added up, so they tie to the Bond postings table’s used columns and to the Over time chart’s bars.

Not used by any widget yet (a deliberate gap): data sets 3 Holiday calendars and 9 Benchmark interest rates only. (Sets 4, 11, 12 and 13 were on this list until the Rules engine became an Overview 2 widget — it reads all four, so they are now consumed. This list must match the “Gap highlight” line in the Requirements 2 data model section.) If a new widget appears that shows data outside the 15-set list, that is a defect — raise it.

TC-DL.1 The “By source” chart follows the user’s Source-of-collateral rules (set 7.3)

Preconditions: Default workspace; a linked Collateral charts widget showing data.

Test data: the funding-source names on the chart.

Steps:

On the Collateral charts widget click By source.
Read the funding-source labels down the bars.

Expected result:

The bars are grouped by funding source (e.g. Interbank Repo, HQLA, MI, CT, LMM, LRP), sorted largest-first. These labels come from the Source of collateral user-maintained data (set 7.3); changing those rules in User maintenance changes what appears here.

TC-DL.2 The Bond postings blotter columns trace to their data sets

Preconditions: A Bond postings widget on the canvas, on the Postings view.

Test data: one posting row.

Steps:

Read one row’s ISIN / Security / Maturity, its Counterparty, its Source, and its five amount fields — Original Ccy, Original Amount, Posted (USD), Allocated (USD) and Unallocated (USD).

Expected result:

ISIN / Security / Maturity come from Bond/securities static (set 2) and Inventory data (set 15); Counterparty from Counterparty static (set 1); Source from the user’s Source-of-collateral rules (set 7.3); Original Ccy and Original Amount are the posting line itself (Collateral used data · set 14); Posted (USD) is that amount converted with the line’s FX Rate (set 8); Allocated (USD) is what TMO used — Posted (USD) scaled by the agreement’s used-versus-posted coverage (exposure from set 10 + thresholds from set 6); Unallocated (USD) is Posted minus Allocated. Every visible column maps to a set on the 15-set catalog.

TC-DL.3 The five amount fields on the Postings view tie out

Preconditions: A Bond postings widget on the canvas, on the Postings view.

Test data: the rows on the Postings view, plus the exchange rates the app uses — USD 1.00 · EUR 1.08 · GBP 1.27 · SGD 0.74 · JPY 0.0064 (US dollars per 1 unit of the currency). Every amount column is shown in millions to one decimal place, so a row reads “27.4”, never “27,400,000”. (There is no separate Unallocated view — the figure is a column here.)

Steps:

Confirm the last five columns are Original Ccy, Original Amount, Posted (USD), Allocated (USD), Unallocated (USD), and that no Unallocated view toggle exists any more.
Pick any row and read those five figures.
Multiply its Original Amount by the exchange rate for its Original Ccy and compare with Posted (USD).
Subtract its Allocated (USD) from its Posted (USD) and compare with Unallocated (USD).
Read the footer totals of the Posted (USD), Allocated (USD) and Unallocated (USD) columns.
Link the widget to blue and pick Bilateral CSA IM in the Agreements widget. Switch to Summary, note that row’s Bonds (Posted) and Bonds (Allocated), then switch back to Postings and read the Posted (USD) and Allocated (USD) footer totals.
Repeat step 6 with GMRA selected.

Expected result:

The five amount columns appear in that order at the end of the row, and the Unallocated view toggle is gone.
Original Amount times the currency’s rate equals Posted (USD) (worked example: an Original Amount of 27.4 in SGD at a rate of 0.74 gives 27.4 × 0.74 = $20.3m in the Posted (USD) column).
Posted (USD) minus Allocated (USD) equals Unallocated (USD) on every row, and it is never negative (worked example: $20.3m posted, $14.5m allocated, $5.8m unallocated).
A line whose agreement is fully used (its total posting is at or below its exposure) shows 0 unallocated; only over-posted agreements show a positive figure.
The footer total of Posted (USD) minus the footer total of Allocated (USD) equals the footer total of Unallocated (USD). The Original Amount column has no footer total, because its rows are in different currencies and cannot be added together.
Bilateral CSA IM ties out across the two views: the Posted (USD) footer total equals that row’s Bonds (Posted), and the Allocated (USD) footer total equals its Bonds (Allocated) (allow the displayed rounding). This is the check that proves the blotter and the summary describe the same money.
Known defect (open, raised 31 Jul 2026) — expect step 7 to fail for GMRA. The build normalises every posting of a book, including ones that have already matured, up to the day’s bond figure and only then hides the matured ones, so the totals fall short whenever a book holds matured postings. At the latest reference date GMRA shows about $448m of postings against a $588m Bonds (Posted) figure, and GMSLA about $296m against $374m. Bilateral CSA IM and VM, CCP, Futures and Triparty all tie out because none of their postings have matured. Record what you read and mark step 7 Fail — known defect for GMRA; do not raise it as a new one.
All figures trace to Collateral used data (set 14), the FX rates (set 8) and the coverage from sets 10 and 6 — no data outside the 15-set catalog.

TRACE

Traceability matrix — test case → user story

Every test case traces to exactly one user story on the Requirements 2 · Overview 2 tab, whose stories are now grouped by widget and numbered US9.1–US9.17. The left column is the current Requirements 2 story; the right column lists the cases that verify it. Coverage is complete when every user-facing story (US9.1–US9.14) has at least one Passed case. This is a pure re-alignment to the re-grouped spec — no test’s steps, data or expected result changed, and no TC id was renumbered.

Gap Log — user-facing stories with no dedicated test case (raised to the BA)

Gap	Req 2 story	What’s missing	Impact if shipped	Raised to
G1	US9.7 What the Agreements widget shows (field table)	No standalone field-inventory case. This is a “what this widget shows” reference story; its individual fields/figures are exercised by TC-9.4.1 (row content, legend & drill), TC-9.4.2 (Unallocated = Posted − Allocated) and TC-9.4.3 ((N) badge), which trace to US9.5. There is no case that walks the full field table row by row.	Low — the displayed fields are covered by the US9.5 operate cases; only the exhaustive field-by-field inventory is unwritten.	BA — confirm whether the field-table stories need their own UAT case or are considered covered by the operate-story cases.
G2	US9.12 Filter maturing & configure columns	No dedicated case. The behaviours (Maturing ≤ N days presets 7d / 30d / 90d / 180d / 1Y, and the column ⚙ show/hide / reorder / pin) are exercised as steps 2–3 of TC-9.9.6, which is mapped primarily to US9.11 (switch the blotter view). US9.12 therefore has no case of its own.	Low — the behaviour is tested inside TC-9.9.6; only the traceability is bundled, not the coverage.	BA — consider splitting a dedicated TC for the maturing filter + column configuration so US9.12 has its own case.
G3	US9.5 — the (N) margin-call badge (carried forward)	Not a coverage gap but an app/spec gap already flagged in TC-9.4.3: the individual-agreement drill rows do not show a per-agreement margin-call flag, so the orange (N) count cannot be independently re-counted anywhere on screen.	Medium — a tester/auditor cannot prove (N) from the screen; it can only be checked by tooltip + consistency across reloads.	BA — surface the per-agreement margin-call flag in the drill, or accept (N) as un-recomputable.
G4	US9.5 — the All-agreements row (Allocated & Unallocated)	Closed 04 Aug 2026. Was a spec-versus-build disagreement: the requirements say the All-agreements row’s Allocated and Unallocated are the type rows added together; the build worked Allocated out as the smaller of the two grand totals. The build now adds the type rows, and the same per-agreement basis was applied to the Allocated key figures and to the Over time chart’s bars. Covered by TC-9.8.3, which now passes.	Was: the grand-total row understated Unallocated and overstated Allocated — about $2,095m / $25m against the $2,040m / $80m the parts add to. It now reads $2,040m / $80m and reconciles to the parts.	BA · 31 Jul 2026 — product owner ruled the requirement correct; build corrected 04 Aug 2026.
G5	US9.13 — postings do not tie back to the Bonds figures	Another spec-versus-build disagreement. The requirements say a book’s Posted and Allocated footer totals equal its Bonds (Posted) and Bonds (Allocated). The build scales matured postings into the total and then hides them, so books holding matured postings fall short. Now covered by TC-DL.3 step 7, expected to fail for GMRA and GMSLA.	The blotter and the summary appear to describe different amounts of money for the same agreement — GMRA about $448m against $588m. Testers cannot reconcile the two views, and a real reconciliation control built on this would break.	BA · 31 Jul 2026 — product owner ruled the requirement correct; the build is to be changed.
G6	US9.9 — chart clicks on a linked widget	Clicking an Over time or By agreement bar has no visible effect on a linked chart, because the control panel’s broadcast overrides it. The two cross-filter charts (By source, By bond type) do work, but apply page-wide rather than to one colour group.	A documented interaction does nothing, so users may believe a filter has been applied when it has not.	BA · 31 Jul 2026 — open question: should a bar click drive its own colour group?
G7	US9.13 — the T+N Ladder’s figures have no data source	The T+N Ladder is now documented and covered, but its amounts are a fixed illustrative table in the demo rather than being worked out from the collateral lines, so they reconcile to nothing else on the screen.	The view cannot be built for real until its source data set is named and added to the data model list.	BA · 31 Jul 2026 — needs a data set on the master list.

No orphan cases: every test case below (including TC-DL.1, TC-DL.2 and TC-DL.3) traces to exactly one current story. TC-9.9.11 is listed under US9.11 (switching the blotter view); it also exercises US9.13’s Agreement-column rule, which US9.13’s own cases cover. The developer stories US9.15–US9.17 are not required to carry UAT cases, but do — the deterministic-data and computation checks live there.

User story (Requirements 2, current)	Test cases
US9.1 Add, add again & close widgets	TC-9.1.1, TC-9.1.2, TC-9.1.3, TC-9.1.4, TC-9.1.5, TC-9.6.1, TC-9.6.2
US9.2 Move, resize, pin & reflow	TC-9.2.1, TC-9.2.2, TC-9.2.3, TC-9.2.4
US9.3 Keep multiple workspaces — persist & reset	TC-9.3.1, TC-9.3.2, TC-9.3.3, TC-9.3.4, TC-9.3.5
US9.4 Link widgets into colour groups	TC-9.5.1, TC-9.5.2, TC-9.5.3, TC-9.5.4, TC-9.5.5, TC-9.5.6, TC-9.6.3
US9.5 Select & drill agreements	TC-9.4.1, TC-9.4.2, TC-9.4.3, TC-9.4.6, TC-9.4.7, TC-9.4.8
US9.6 Set the shared filters & broadcast them	TC-9.4.4, TC-9.4.5
US9.7 What the Agreements widget shows	— no dedicated case (see Gap Log G1); fields exercised by TC-9.4.1 / 9.4.2 / 9.4.3 under US9.5
US9.8 Switch between the four charts	TC-9.9.3
US9.9 Click a chart to drill / cross-filter	TC-9.9.4
US9.10 What the Collateral charts widget shows	TC-9.9.5, TC-DL.1
US9.11 Switch the blotter view	TC-9.9.6, TC-9.9.10, TC-9.9.11
US9.12 Filter maturing & configure columns	— no dedicated case (see Gap Log G2); exercised within TC-9.9.6
US9.13 What the Bond postings widget shows	TC-9.9.7, TC-9.9.11, TC-DL.2, TC-DL.3
US9.14 What the Key figures strip shows	TC-9.9.1, TC-9.9.2, TC-9.9.12
US9.15 (developer) Data model, loading & determinism	TC-9.7.1, TC-9.7.2
US9.16 (developer) Generation & core computations	TC-9.8.1, TC-9.8.2, TC-9.8.3, TC-9.8.5, TC-9.8.6
US9.17 (developer) Key-figures strip, four charts & blotter	TC-9.9.2, TC-9.9.8, TC-9.9.9

RESULTS

Results summary sheet

Fill one row per test case as you run it. Mark Pass or Fail; for any Fail, write what you saw and attach a screenshot. Select-all → copy this whole pack into your spreadsheet to fill it in there.

Test ID	Title	Pass / Fail	Notes (what you saw if Fail)
TC-9.1.1	Add a widget from the palette
TC-9.1.2	Add the same widget several times
TC-9.1.3	Bond postings is single
TC-9.1.4	Close a widget — others compact up
TC-9.2.1	Move a widget — no overlap
TC-9.2.2	Header button does not start a drag
TC-9.2.3	Resize a widget — minimum size
TC-9.2.4	Pin locks a widget; unpin
TC-9.3.1	Create / switch / rename / close workspace
TC-9.3.2	New workspace opens empty
TC-9.3.3	Always at least one workspace
TC-9.3.4	Everything persists across refresh
TC-9.3.5	Reset layout on the Agreements widget
TC-9.4.1	Row content, legend & drill
TC-9.4.2	Unallocated = Posted − Allocated
TC-9.4.3	The (N) badge
TC-9.4.4	Filter panel drives receivers
TC-9.4.5	✕ Clear resets selection & reference
TC-9.4.6	Per-type sub-filter buttons
TC-9.4.7	Sub-filter re-works figures; parts add back
TC-9.4.8	Zero-interest only; new type starts fresh
TC-9.5.1	Chain popover — role read-only
TC-9.5.2	Emitter broadcasts to receivers
TC-9.5.3	Emitter-less receiver shows no data
TC-9.5.4	New Agreements auto-takes a colour
TC-9.5.5	Receiver picker offers only emitter colours
TC-9.5.6	Independent colour groups
TC-9.6.1	Palette lists exactly five widgets
TC-9.6.2	Toolbar hint text
TC-9.6.3	Default workspace on first load
TC-9.7.1	Figures are deterministic
TC-9.7.2	Seven agreement types present
TC-9.8.1	Allocated = min(Posting, Exposure); Unallocated
TC-9.8.2	Individual agreement is a share; shares add back to the whole
TC-9.8.3	Type rows reconcile to “All agreements” (grand total)
TC-9.9.1	Two KPI strips, nine cards in order
TC-9.9.2	KPI arithmetic identities
TC-9.9.3	Chart toggle — four dimensions
TC-9.9.4	Chart clicks drill / cross-filter
TC-9.9.5	Unlinked charts → placeholder
TC-9.9.6	Blotter views, maturing presets, ⚙
TC-9.9.7	Bond postings scoping
TC-9.9.8	Charts reconcile to the KPI strip
TC-9.9.9	Week/Week delta pill is checkable
TC-9.9.10	Postings by bonds — always visible, prompts until one agreement / agent is picked
TC-9.9.11	Blotter Agreement column follows the picked agreement
TC-9.1.5	Rules engine & Inventory Manager — single-copy standalone widgets
TC-9.8.5	Exposure = what’s owed plus the threshold cushion
TC-9.8.6	Bonds (Allocated) on the GMRA row, traced end to end
TC-9.9.12	Received (inbound) is scoped and repeatable
TC-DL.1	“By source” chart follows the Source-of-collateral rules
TC-DL.2	Bond postings blotter columns trace to their data sets
TC-DL.3	The five amount fields on the Postings view tie out

❓ Open questions — pending decisions & clarifications

One consolidated register of every open question across the collateral demo — items still waiting on a decision or an answer from the Business Analyst, the Product Owner, a Developer or the Tester. Anyone can raise a question here. Each row says what is unclear, where it shows up, who raised it, who it is pending on, and its status. This is the single place to see everything outstanding; the underlying detail lives in Requirements 1 · §E.14 (data-lineage gaps) and the UAT test cases for Overview 2.

Scope: whole app (/j-collateraldemo) — Overview, Inventory Manager, Rules engine, Optimization Results, Agreement detail. Overview 2 is retired (20 Aug 2026) and is not being built. · Last updated: 26 Aug 2026.

How an item closes: the owner it is pending on makes the decision or supplies the data → the source is added to the Data source catalog or the spec is updated → the row is marked Resolved (with the answer) and drops off the open list. Nothing here has been invented — every item is a real gap already flagged in the spec or found during testing. Status key: Open = needs a source / a build decision · To confirm = a mapping or an intended behaviour to sign off · Placeholder = a data set that is named but not yet detailed (a reserved slot).

A · Data-source gaps — a figure on screen with no home in the data catalog

These figures are shown, but there is no catalogued data set they can honestly be drawn from. A source must be agreed and added to the catalog before the field is built for real. See §E.14 for the field-level detail.

#	Open question	Where it shows up	Raised by	Pending on	Status
OQ-1	There is no derivative-trade data set. The individual trades behind an exposure (Trade ID, Product, Notional, Trade date, Maturity, Currency) have nowhere to come from — only their combined mark-to-market ties back to Exposures & margin calls (set 10). Which data set feeds the trades?	Exposure drill; Agreement detail → Trades tab	Data-lineage audit	Product Owner	Open — add a “Trades / derivative positions” set to the catalog
OQ-2	There is no security-price / valuation data set. Market value (mark-to-market) needs a price per security, but the catalog only has FX rates (8) and benchmark rates (9). Where do security prices come from?	Inventory Manager; Agreement Exposure card (MTM / IA); the ITM / OTM split	Data-lineage audit	Product Owner	Open — add a security-price data set (or add a price to Bond static · 2)
OQ-3	The T+N settlement ladder has no source. The T+0…T+5 settlement-availability amounts and the country breakdown are demo placeholder numbers, not drawn from Collateral used (14) or Inventory (15).	Triparty T+N ladder	Data-lineage audit	Product Owner / BA	Open — confirm a settlement-availability source (by agent, country and settlement horizon)

B · Data mappings to confirm — a figure that is mapped, but to the wrong or an unclear set

#	Open question	Where it shows up	Raised by	Pending on	Status
OQ-4	The “Clearer” (settlement / custody location) could be a holding attribute (Inventory · 15) or the security’s settlement instructions (Bond static · 2). Which set owns it?	Inventory Manager	Data-lineage audit	BA	To confirm
OQ-5	“Business Line” is mapped to Portfolios static (4), but that set’s description does not name business line explicitly. Confirm it is a Portfolios-static attribute.	Inventory Manager	Data-lineage audit	BA	To confirm
OQ-6	The issuer-classification columns (Classification Level 4 / BICS Level 2 Industry Group / Issuer Industry) are mapped to Bond static (2) but could belong to Counterparty / issuer static (1). Which set owns issuer classification?	User maintenance → G7 industry group	Data-lineage audit	BA	To confirm

C · Data sets not yet built, or not yet shown on Overview 2

Two kinds of item here. Genuine placeholders (Holiday calendars · 3 and Benchmark rates · 9) are named in the 15-set catalog with Status = Placeholder and no invented fields — they need the Product Owner / BA to supply the detail before the feature that uses them is built. Separately, a few sets are catalogued and (partly or fully) built elsewhere but not yet surfaced on Overview 2 — the only open question there is whether they should appear on Overview 2 at all.

#	Open question	Where it shows up	Raised by	Pending on	Status
OQ-7	Holiday calendars (set 3) are not yet built — today the holiday centre shows as free text on the agreement. What are the calendars, and how do they drive call-date working days?	Agreement detail → Call schedule	Data catalog	Product Owner / BA	Placeholder — supply the calendar detail
OQ-8	Benchmark interest rates (set 9) are a placeholder — only the rate name (e.g. SOFR) is shown; no rate value is modelled. What is the rate feed?	Agreement detail → Benchmark rate	Data catalog	Product Owner	Placeholder — supply the rate feed
OQ-9	Some catalogued sets are not yet shown in any Overview 2 widget: Optimization rules (11) and outputs (12) are already built on the Rules-engine tab (catalog Status = Modeled), and Portfolios static (4) and exclusions & exceptions (13) are partly built (Status = Partial). They are catalogued, not undetailed — the only open question is whether any of them should also surface on Overview 2.	Data source catalog; Rules engine	Data-lineage audit	BA	To confirm — Overview 2 coverage

D · Demo-modelled figures — a real number is faked for the demo; replace with the real value when building

#	Open question	Where it shows up	Raised by	Pending on	Status
OQ-10	Resolved (08 Aug 2026): the green “Total posted” line on the utilisation-over-time chart used to be the posted total lifted by a fixed 10% over-collateralisation buffer — a demo modelling choice, not a data feed. The buffer has been removed. The line is now the posted total itself, read straight off the record. It therefore lands exactly on top of the Bonds + Cash bars, and agrees with the Total posting card and the Agreement summary table. A line drawn above the bars is now a defect.	Overview / Overview 2 → utilisation-over-time chart	Data-lineage audit / Tester	Developer	Closed (08 Aug 2026)
OQ-41	On the agreement detail pop-up, Remaining Posting Capacity → “Headroom to capacity limit (est.)” assumes the capacity limit is 130% of the obligation, for every agreement type. No agreement carries that term, and nothing in the agreement data sets it. The figure is shown in green or red, so it tells a user they are near a limit that cannot be checked against anything. What is the posting capacity limit, and where does it come from?	Agreement detail → Remaining Posting Capacity	Hard-coded-figure audit (08 Aug 2026)	Product Owner / BA	Closed (21 Aug 2026) — the line is gone. The Remaining Posting Capacity card was built in the code but never put on screen, so nothing ever showed the 130% figure. The whole card was deleted; if a real posting capacity limit exists, it comes back as a new request with its source named.
OQ-11	The ITM / OTM / Net-Alternative split and the STD / Counterparty / Agreed / Dispute amounts are modelled close to the call amount, not fed from a real mark-to-market or a real dispute record.	Agreement summary; Margin Calls (Daily Exposure Report)	Data-lineage audit	Developer	Open — wire to the real feeds (depends on OQ-2)
OQ-12	On the Agreement detail, the Asset-Holdings Delivery / Market-Value / Collateral-Value factors and several Corp eligibility rows are the same fixed demo wording for every agreement, rather than per-agreement / per-line values.	Agreement detail → Asset Holdings & Eligibility schedule	Data-lineage audit	Developer	Open — source per-agreement / per-line values
OQ-13	The Instrument modal shows several fields as “to be provided” — Coupon frequency, Country of risk, Day count, Settlement (T+), Haircut, Accrued interest. Which of these come from Bond static (2) / Collateral used (14), and which need a new source?	Instrument modal (Inventory / postings)	Data-lineage audit	BA / Developer	Open — surface the existing fields; source the rest

#	Open question	Where it shows up	Raised by	Pending on	Status
OQ-39	The optimiser's funding cost does not come from the maintained Cost of funds table. This now reaches further: the Cost column on the Optimization Results approval blotter, and the annual carry, blended funding cost and saved this year figures on the benefits scorecard, are all priced off that same built-in table, so the saving the screen reports is only as right as those buckets are. The Cost (bps) figure on every Rules-engine holding — and the Annual cost and posting-cost figures worked out from it — comes from a small built-in table of four buckets by asset class and credit rating (government AAA/AA, government A, investment-grade corporate, high-yield corporate), each with a fixed internal and external number. Meanwhile the team maintains a real cost of funds table by Security Type × currency (§13) that nothing reads, and the agreed exception handling (no matching security type → the Others row; currency not found → 0) is implemented but not yet called by the optimiser. So the number on screen does not move when the maintained rates change, which the “never hard-code a displayed figure” rule forbids. Wiring it up is a real behaviour change and needs a decision: the demo's Security Types are not priced out of the box, so on today's data every holding would fall to the Others row and price at 0, and the “cheapest first” ranking rule would stop discriminating until the table is populated. Should the optimiser be switched to the maintained table (and the demo table seeded with starting rates), or should the built-in buckets stay until real rates are loaded?	Rules engine → Inventory input, Allocation table (Cost (bps), Annual cost), run log; User maintenance → Cost of funds	BA — cost-of-funds file requirement, 07 Aug 2026	Product Owner / BA	Open — decide whether to wire the optimiser to the maintained rates
OQ-40	What should happen if the same row appears twice in an uploaded cost-of-funds file? The agreed file rules cover a row on screen that the file leaves out, and a row in the file the system does not recognise — but not a file that carries the same Security Type and Currency on two lines with different rates. Today the later line simply wins and nothing is said, which means a user can load a rate they did not intend without being told. Decided (user, 07 Aug 2026): reject it and flag it out. A file carrying the same Security Type and Currency twice is now rejected outright and the repeat is named line by line, so neither rate pair is saved and the user fixes the file instead of loading a rate they did not intend. Built the same day — test case COF-12.	User maintenance → Cost of funds (upload)	BA — cost-of-funds file requirement, 07 Aug 2026	—	Closed (07 Aug 2026) — reject and flag out; built.

E · Business decisions pending the Product Owner

#	Open question	Where it shows up	Raised by	Pending on	Status
OQ-42	What does “Release” actually do? The approval blotter lets a user accept, hold or reject each proposed movement and then press Release. In the demo that only confirms on screen. For the real system: where do accepted movements go (a settlement instruction, the triparty agent, a file to operations)? Who is allowed to release, and does it need a second pair of eyes? Can a released set be recalled before it settles, and what is the cut-off?	Optimization Results → 01 Approval blotter	BA (build of the new screen)	Product Owner	Open
OQ-43	Are the accept / hold / reject decisions kept, and is an audit trail required? Today they live in the browser for the run on screen and are lost when the optimiser is re-run, because a re-run proposes a different set of postings. Does the real system need to record who decided what, when, and why a line was rejected? And does a line put on hold carry forward to the next run, or start again?	Optimization Results → 01 Approval blotter	BA (build of the new screen)	Product Owner	Open
OQ-44	The movement map can show where collateral goes, but not what MOVED. A before-and-after view needs what is already posted — Collateral used data (set 14, Delivered rows) — and no such data is loaded, so a run with Sweep the deck OFF currently retains $0.0mm and behaves exactly like a sweep-on run. Confirm set 14 will be supplied, and whether the map should then show recalls and substitutions alongside new postings.	Optimization Results → 04 Movement map; Rules engine → Sweep the deck	BA (build of the new screen)	Product Owner / BA	Open
OQ-45	The generated field check does not cover the Rules engine or the Optimization Results screens. The Data tab’s “Every field on the screens” card is produced from the Overview and Inventory Manager screens only, so no field on either Rules-engine screen is checked against the data you can supply. This is a pre-existing gap the new screen inherits, not a regression. Should both screens be added to the check? Expect the field count to rise well above 159 and to raise new call-outs to work through.	Data tab → Every field on the screens	BA (build of the new screen)	Product Owner	Open
OQ-14	The exact business meaning of “Valuation Date” is not yet defined (flagged ⚑ on 20 Jul). What does it represent, and how does it differ from Date of Posting?	Collateral used data (set 14) → the collateral-used column dictionary column dictionary	BA	Product Owner	Open
OQ-46	Which optimisation model should the engine itself run? The Optimization Model Research by AI panel now runs the same run through six different algorithms and shows what each proposes. The engine itself still runs the first one — a greedy, cheapest-to-deliver heuristic that never revisits a decision. That was never a decision anybody took; it is simply what was built first. The panel makes the alternatives comparable, and on today’s demo book it also shows that the choice does not yet matter: every model lands within a cent of the others, because the concentration cap and the eligibility schedules bind long before cost does. Two things need deciding. First, whether the engine should keep the greedy heuristic, or move to the lot-constrained optimisation, which is the only model that carries a provable bound and still settles in whole lots. Second, if it moves, whether the desk accepts an answer it cannot explain one posting at a time — an optimiser’s answer is justified by the model, not by a reason per row, and that is a governance question rather than a technical one. Building the chosen model for real also means a solver (open-source or commercial) to licence, host and support, with a time limit and a fallback for a book that will not solve in time.	Optimization Results → Optimisation model; the Rules engine’s own run	BA — optimisation model review, 16 Sep 2026	Product Owner / BA	Open — decide whether the engine keeps the greedy heuristic or moves to the lot-constrained optimisation
OQ-15	Feature relabelling — several existing feature labels are being kept as-is until the product owner supplies the agreed relabelling list. Which labels change, and to what?	Whole app (feature labels)	BA	Product Owner	Open — awaiting the relabelling list

F · Tester / UAT findings — raised while running the Overview 2 figure-traceability review

#	Open question	Where it shows up	Raised by	Pending on	Status
OQ-16	The orange (N) margin-call badge is a count of a type’s agreements with a recent margin call, but N cannot be re-counted on screen — the individual-agreement drill rows do not show a per-agreement margin-call flag. Should the per-agreement flag be surfaced so a tester can verify N?	Overview 2 Agreements widget; Overview Margin Calls	Tester — UAT review	BA / Developer	Open — decide whether to surface the per-agreement flag
OQ-17	Unallocated definition. Decided (Product Owner, 21 Jul 2026): Unallocated is simply Total Posted minus Total Allocated — shown green (“unallocated”) when zero or positive and red (“deficit”) when negative. There is no “always zero-or-positive / always green” rule; the earlier claim that a red Unallocated could not occur on Overview 2 was never a stated requirement and has been removed. (The app already has a live red/deficit render path.) (Test pack Gap Log · GAP-03.)	Overview 2 Key figures; Agreements widget	Tester — UAT review	—	Decided — this figure = Total Posted − Total Allocated. Renamed 07 Aug 2026: it is now called Unallocated; “Surplus” is a different figure (Total allocated − Margin call).
OQ-18	“Unallocated” is defined two different ways in our own documents. The on-screen note says unallocated is the posted collateral left over after covering what is used; an older appendix says it is what was received minus what was utilised — two definitions, two different numbers. Which one is correct to build?	Overview / Overview 2 — Agreement summary → Unallocated	Tester — figure-traceability (Gap Log GAP-01)	BA	Closed (07 Aug 2026) — the posted-minus-used definition wins, and the figure is renamed Unallocated = Total posting − Total allocated, on Overview and Overview 2 alike. The received-based definition is retired: Received (in) is information only and never feeds any worked-out figure. Surplus is now a separate figure — Total allocated − Margin call (see OQ-26, closed 07 Aug 2026).
OQ-19	The “collateral value after haircut” estimate and the detailed haircut schedule don’t match up. The headline estimate trims every bond by a flat three percent, but each agreement also shows a detailed haircut table that varies the trim by credit rating and time to maturity. Should the headline figure use the flat three percent, or be driven by the detailed schedule?	Overview → collateral value after haircut; Agreement detail → haircut schedule	Tester — figure-traceability (Gap Log GAP-02)	BA	Open
OQ-20	The “change since” indicators don’t mean the same thing on every screen. The day-on-day, week-on-week and month-on-month change pills compare against different look-back periods and are shown in different units on different screens. Should these be made consistent across screens, or clearly labelled on each screen so a reader knows which comparison they are looking at?	Overview KPI pills; Agreement summary; Overview 2	Tester — figure-traceability (Gap Log GAP-04)	BA	To confirm
OQ-29	The Asset Holdings Summary card works its values out from fixed percentages, not from the agreement’s own haircut schedule. On the agreement detail popup, Market value (est.) is the bonds figure cut by a flat 1.5%, Collateral value after haircut (est.) by a flat 3%, and the mini-table’s Delivery column is a flat 28% of the amount held — the same three percentages for every agreement, every rating and every maturity. Meanwhile each agreement already carries a real haircut schedule in its own terms (for example “AAA / up to 1 year: 0.5% · AAA / 1–5 years: 1.5% · AA / 1–5 years: 2% · A / 1–5 years: 4%”), which is what those figures ought to be worked out from, bond by bond, using each holding’s credit rating and time to maturity. The Delivery column has no source at all — it is not clear what business figure it is meant to be. These numbers therefore do not move when the book changes, which the 04 Aug standing rule (“never hard-code a displayed figure”) forbids. What should each of the three be derived from?	Overview & Overview 2 → agreement detail popup, Asset Holdings Summary	Hard-coded-figure audit, 04 Aug 2026	Product Owner / BA	Open
OQ-28	The “Base Total Exp.” and “Base Call Amt” totals add different currencies together. Both columns are stated in each agreement’s own base currency, and the demo book holds three (US dollars for most types, euros for GMSLA, Singapore dollars for Triparty). On any selection spanning more than one, the total row adds those amounts as if they were the same currency. The total row now shows an amber “Mixed” under Base CCY so the reader is warned, but the two amount totals are still shown as single numbers. Should they be suppressed on a mixed selection, split per currency, or converted to a reporting currency first?	Overview & Overview 2 → agreement summary table, Detailed view	Raised while filling in the blank totals, 04 Aug 2026	Product Owner	Open
OQ-25	The “All agreements” row does not add up for Allocated and Unallocated. The requirements say that row is the agreement-type rows added together. The build worked its Allocated out as the smaller of the two grand totals, so the row read about $2,095m Allocated / $25m Unallocated while the six type rows added to about $2,040m / $80m. Posted always added up correctly. Decided (Product Owner, 31 Jul 2026): the requirement is correct — the build to be changed so the row adds the type rows. Fixed 04 Aug 2026: the row now adds the type rows, and the same per-agreement basis was carried into the Allocated key figures and the Over time chart’s bars, so all four surfaces now agree at $2,040m / $80m. TC-9.8.3 passes.	Overview 2 → Agreements widget, the All agreements row	UAT figure-traceability review	Developer (build fix)	Closed — fixed 04 Aug 2026
OQ-26	The Surplus figure came out large and negative on every agreement. It had been specified the wrong way round, as Margin call minus Total allocated, which gave every row that agreement’s own posting with a minus sign in front of it — GMRA read −$562.0m and Bilateral CSA VM −$259.4m, on a row where $34.1m was in fact spare.	Overview / Overview 2 — Agreement summary and Agreement summary — detailed → Surplus	BA — figure provenance check, 07 Aug 2026	Product Owner	Closed (07 Aug 2026) — the two figures were the wrong way round. Surplus is Total allocated minus Margin call: what is left of the collateral allocated once the call has been met. The margin call is signed positive when we have to post, so allocating $100m against a call of $50m to post leaves $50m spare. A negative margin call means nothing has to go out and it can be collected back, so subtracting it adds to the surplus — Bilateral CSA VM now reads $225.2m − (−$34.1m) = $259.3m.
OQ-26	The bond postings on screen add up to less than the Bonds posted figure. The build scales every posting of a book — including ones that have already matured — up to the day’s bond figure, and only then hides the matured ones, so a book holding matured postings falls short. At the latest reference date GMRA shows about $448m of postings against a $588m Bonds (Posted) figure, and GMSLA about $296m against $374m; the other five types tie out because none of their postings have matured. Decided (Product Owner, 31 Jul 2026): the postings are meant to tie out — the build is to be changed. Until then TC-DL.3 step 7 is expected to fail for GMRA and GMSLA.	Overview 2 → Bond postings (Postings view footer totals), the By source and By bond type charts	UAT figure-traceability review	Developer (build fix)	Open — decision made, fix pending
OQ-27	Clicking an Over time or By agreement bar does nothing on a linked chart. A linked widget always redraws from what its Agreements control panel is broadcasting, and that broadcast overrides the click. The two cross-filter charts (By source, By bond type) do respond, but they apply page-wide rather than to the one colour group. Should a bar click be able to drive its own colour group’s reference date or agreement pick?	Overview 2 → Collateral charts widget	UAT figure-traceability review	Product Owner	Open
OQ-34	Test coverage still missing after the 31 Jul review. The review found these gaps but they were not closed in that change, so they remain untested: (a) sub-filter memory per colour group — that a book choice such as CCP → VM-only is remembered per colour group, survives a reload, and does not leak into another group; (b) what a Bond postings widget does when its emitter disappears — closing or recolouring the Agreements widget it followed should drop it back to showing everything; (c) the column sets of the Summary, Detailed and Margin Calls views — no test reads the header row against the documented list, or checks that Detailed adds exactly the six extra columns, or hand-counts the five Margin-Calls tiles against the rows; (d) the Collateral charts strip when one individual agreement is picked — only the blotter strip is covered; (e) boundary cases — running out of emitter colours, cancelling a workspace rename with Escape, and the saved column layout. Decide whether these should be written up as test cases now or deliberately accepted as untested.	UAT test cases · Overview 2	UAT figure-traceability review	BA / Product Owner	Open — known gap, not yet closed
OQ-35	Does clicking a bar on the “By agreement” chart do anything inside a widget? On the top-level Overview this click reveals the postings table, but on Overview 2 the postings table is a separate widget. The review could not confirm what, if anything, happens without running the page, so the expected result cannot be written yet. Someone needs to click it and record what actually happens.	Overview 2 → Collateral charts widget → By agreement	UAT figure-traceability review	Tester (observe), then BA	Open — behaviour unconfirmed
OQ-36	Dates are shown in two different formats. The Detailed view heading writes the as-at date as 2026-06-18, while the requirements use 18 Jun 2026 throughout. One of the two should win. This is a presentation choice, not a calculation, so it is being raised rather than changed.	Overview 2 → Bond postings → Detailed heading (and the chart hints)	UAT figure-traceability review	Product Owner	Open
OQ-37	Is the T+N Ladder meant to be an Overview 2 view at all? It has now been documented because it is on screen, but it was never specified as an Overview 2 feature — it may have been intended only for the Triparty view on the top-level Overview. Confirm whether it stays as a seventh blotter view (in which case it also needs the data source in OQ-3 resolved) or is removed from the widget.	Overview 2 → Bond postings → T+N Ladder	UAT figure-traceability review	Product Owner	Open
OQ-38	Should each figure carry its “how to check it” right beside it? Every widget section lists its figures with what they show, how they are worked out and which data model they come from; the independent verification step for each currently sits in the “Checks that span more than one widget” section instead of next to the figure. Confirm whether to move each check up beside its own figure (a fifth column on every widget table) or leave the checks gathered together.	Requirements 2 · Overview 2 — every widget table	Requirements review	Product Owner / BA	Open — presentation decision

Overview 2 field-lineage completeness audit (22 Jul 2026). Every field, column, KPI card, chart series and label shown anywhere in Overview 2 — the Agreements control panel, the four Collateral charts (Over time / By agreement / By source / By bond type), the Bond-postings blotter in all five views (Summary / Detailed / Postings / Bonds Maturing / Margin Calls), and the Key-figures strips — was traced field-by-field to the data catalog. Result: every Overview 2 figure either traces to a modeled data set (6 Agreements static · 10 Exposures & margin calls · 14 Collateral used data, plus 1 · 2 · 5 · 7.2 · 7.3 · 8 for the blotter’s reference columns) or is already listed as an open question above — the modelled Total-posted buffer (OQ-10), the ITM/OTM/STD/Cpty split (OQ-11), the meaning of Valuation Date (OQ-14), and the (N) margin-call-badge verifiability (OQ-16). No new off-catalogue Overview 2 field was found. Category / Region / Credit Rating in the Detailed view were checked and trace to Agreements static · 6 (per §E.1), so they are not a gap. This applies the standing rule that everything shown in Overview 2 must be documented against an existing data model, else raised here as an outstanding question.

G · Business setup & scope — the standard discovery questions (pending the Product Owner)

The everyday questions a Business Analyst asks at the very start of a project that were never settled for this app. Until they are answered, the demo’s own shortcuts (a single user, no login, data made up in the browser) stand in — and those are demo-only, not how the real system should be built.

#	Open question	Where it shows up	Raised by	Pending on	Status
OQ-21	Who will use the real system, and is there more than one type of user? For example, is there a person who enters and confirms margin calls and a separate person who only reviews or approves them, and are there read-only viewers? The demo runs as a single user with no login, so the real roles — and what each is allowed to see and do — need to be confirmed.	Whole app — sign-in & roles	BA — discovery	Product Owner	Open — decides whether the build needs sign-in, separate roles and “who may do what” rules
OQ-22	Roughly how much data will the real system hold and change each day? About how many agreements, margin calls, collateral postings and inventory rows, and how often do they update? An order of magnitude is enough (hundreds, thousands, tens of thousands).	Whole app — tables, filters, totals, charts	BA — discovery	Product Owner	Open — changes how screens must be built to stay fast and readable
OQ-23	What are the expectations for how the real system must behave? Specifically: how fast screens should load, what security is required, whether there must be an audit trail (a record of who changed what and when), how long data must be kept, and which devices and browsers must be supported. None of these have been specified yet.	Whole app — non-functional requirements	BA — discovery	Product Owner	Open — the demo’s single-user, in-browser, no-login setup is demo-only
OQ-24	Which systems feed this app, and which systems use what it produces? Where do the agreements, exposures, margin calls, collateral postings and inventory actually come from (the systems upstream), and which teams or systems consume the results downstream? The demo makes up its own sample data in the browser, so the real sources and consumers need to be named.	Whole app — data in / data out	BA — discovery	Product Owner	Open — names the real sources behind every figure and completes the data-source catalog

H · Rules-engine input fields — filters the engine offers that the data sets don’t yet carry

The Rules engine lets you filter and rank your collateral, margin calls and agreements on a set of fields. Tracing each of those fields back to the data catalog shows that several of them have nowhere to be stored yet — the data set the engine reads doesn’t hold that attribute, so it cannot be uploaded and mapped on the Data tab. Each needs a source decision before it is built for real. (Detail: the “Field → data model → Data tab” trace, Rules-engine screen.)

#	Open question	Where it shows up	Raised by	Pending on	Status
OQ-25	The engine can filter inventory by Asset type (Cash / Govt / Corp), but the Inventory data set (15) does not hold an asset-type field — it holds Sector, Industry and Bond type instead. Should Asset type be worked out from those, or added as its own field?	Rules engine → Inventory scoping	Field → data-model trace (Rules engine)	BA	Open
OQ-26	The engine can filter inventory by Holding (our own holdings / held elsewhere / collateral we have received), but the Inventory data set (15) has no holding-status field. The nearest is the Delivered / Held marker on Collateral used (14). Add a holding-status field to inventory, or read it from Collateral used?	Rules engine → Inventory scoping	Field → data-model trace (Rules engine)	BA	Open
OQ-27	The engine can filter inventory by Haircut %, but the Inventory data set (15) carries no haircut. A haircut normally comes from the eligibility / haircut schedule (Bond static · 2 / Agreement · 6) or is captured on the posted line (Collateral used · 14). Where should the per-line haircut come from? (Relates to OQ-19.)	Rules engine → Inventory scoping	Field → data-model trace (Rules engine)	BA	Open
OQ-28	The engine can filter inventory by Book (the desk / book that owns the line), which is a Portfolios-static (4) attribute — but Portfolios static is still a placeholder with no fields defined, so Book cannot be uploaded / mapped yet. Detail Portfolios static and join Book to each inventory line.	Rules engine → Inventory scoping	Field → data-model trace (Rules engine)	Product Owner / BA	Placeholder
OQ-29	The engine ranks (and can filter) inventory by Cost of funds (bps), which is not held on the inventory line — it comes from the user-maintained Cost of funds table (7), matched to each line by G7 industry group × currency. Confirm those are the correct match keys.	Rules engine → Ranking / Inventory scoping	Field → data-model trace (Rules engine)	BA	To confirm
OQ-30	The engine filters on a single Rating, but each inventory line holds two ratings — Issuer Rating and Bond Rating. Which one should the rating rule use?	Rules engine → Inventory scoping	Field → data-model trace (Rules engine)	BA	To confirm
OQ-31	The engine filters on Custodian (e.g. Euroclear, an internal custody account), while the Inventory data set (15) calls its settlement / custody location Clearer. Are “Custodian” and “Clearer” the same attribute? (Ties to OQ-4.)	Rules engine → Inventory scoping	Field → data-model trace (Rules engine)	BA	To confirm
OQ-32	The engine scopes on individual margin calls (by Currency, Call size and MTA), but the catalogued “Exposures & margin calls” set (10) is modelled per agreement type per day, not per individual call — so those call-level fields have no home. Add call-level fields to set 10, or add a separate individual-margin-calls set.	Rules engine → Margin-obligations scoping	Field → data-model trace (Rules engine)	Product Owner / BA	Open
OQ-33	Resolved (23 Jul 2026): Agreements static (6) now carries the full set of agreement-level terms shown on the agreement detail pop-up — identity/admin, margin-call summary, valuation & call schedule and collateral rules — and the Rules engine can scope agreements on any of them (plus the eligibility Rating floor and Settlement delay it already had). Concentration limits and the eligibility rating floor remain modelled as optimisation boundaries, not scoping rules (a deliberate business decision), so they are not offered as agreement scoping conditions.	Rules engine → Agreement scoping / Limits	Field → data-model trace (Rules engine)	Product Owner / BA	Closed

✏ Edit Rule

Name

Group

Value / criteria

Note (ℹ tooltip)

Enabled

Asset Optimization Engine (AOE)

Collateral posted vs exposurestacked bonds + cash, exposure overlaid

Coverage ratio by agreementposted ÷ exposure over time

Posted by agreementtotal collateral, end of period

Change vs prior period

Agreement breakdown

Period comparison

Run orderrules fire top-down in this sequence

Run parameters

Allocation by agreement

vs All-cash baselineannual carry cost

Full posting detail

Optimization Model Research by AI

Adjusting inventory Add inventory rows using the same fields as the Inventory Manager “Bond Inventory” table. Added inventory is reflected in all areas of the app that use inventory data.

What the Optimization Results screen reads added 26 Aug 2026 · data sets 12 & 13 detailed 9 Sep 2026

Every field on the screens generated from the app — traced to your data, or called out

📋 Requirements & Test Pack

📑 Contents — jump to an epic

Open questions & decisions

Global shell & navigation

Overview — collateral management dashboard

Margin Calls panel

Bonds Maturing & Triparty AOE

Static Data reference screens

Agreement detail popup

Exposure drill panel

Instrument detail modal

Inventory Manager

Rules engine (opened from the Overview sidebar)

User maintenance — shared contract (eight datasets)

User maintenance — Cost of funds

User maintenance — G7 industry group

User maintenance — G7 by bond

User maintenance — Source of collateral

User maintenance — Special agreements

User maintenance — Adjusting exposures

User maintenance — Adjusting inventory

User maintenance — Tags & highlights

Data — upload production data & switch dummy ↔ production

Data model & conventions (build reference)

Glossary & data sources

Table controls (sort · filter · columns) — shared by every table

Tooltips, hovers & dynamic text

Field → data model lineage — every displayed field mapped to its exact data set & field

Field check sheet generated — do not hand-edit

📋 Requirements 2 · Overview 2 — workspace builder

⚠ Overview 2 is retired — do not build the workspace builder

📑 Contents — what’s on this page

Overview 2 — workspace builder (widget dashboard)

🧪 UAT test cases · Overview 2 — workspace builder

⚠ Do not run this pack — Overview 2 is retired

📑 Contents — Overview 2 test scenarios

About Overview 2 & Glossary

Add, add again & close widgets

Move, resize, pin & reflow

Workspaces & persistence

The Agreements widget — select, drill & shared filters

Link widgets by colour (emitter / receiver)

Palette, toolbar & default workspace

Data model & determinism

Posted / Allocated / Unallocated computations

Key figures, four charts & blotter

Data lineage matrix — widget → data set & logic

Traceability matrix — test case → user story

Results summary sheet

❓ Open questions — pending decisions & clarifications

🛠️ Tools — replica export

📦 Full prototype code every page, including Rules setup, Optimisation results and Triparty AOE

💻 Offline standalone app — no server, no internet locked-down laptop: download seven files into one folder → open the first

Overview 2 + Data — standalone rebuild message paste as the FIRST chat message

Source files (Overview 2 + Data) 2 files, copy & paste or download

✏ Edit Rule