Securities Lending and Repo Platform With Collateral Optimization
Knowing What You Have, What It Can Cover, and What It Costs
Collateral optimisation is usually presented as an algorithm problem, and the algorithm is the easy part. Linear programming over a set of eligible assets and obligations is well understood. What makes securities financing platforms hard is that the inputs are wrong: the inventory does not reflect what is genuinely available, the eligibility schedules exist as PDF annexes interpreted inconsistently, and the position moves during the day while the optimisation ran overnight.
A securities lending repo platform earns its return by fixing those inputs. Get inventory and eligibility right and a simple allocation rule captures most of the available benefit. Get them wrong and a sophisticated optimiser produces allocations that fail on delivery.
What does the platform have to do?
Four functions, with inventory as the dependency for the other three.
| Function | Responsibility | Failure consequence |
|---|---|---|
| Inventory | What is held, what is available, what is encumbered | Failed deliveries, missed revenue, breached restrictions |
| Trading and matching | Availability, pricing, negotiation, confirmation | Lost opportunity, operational breaks |
| Collateral management | Eligibility, haircuts, allocation, substitution, margin | Over-collateralisation, failed calls, cost |
| Risk and reporting | Exposure, concentration, regulatory reporting | Regulatory findings, unmeasured risk |
Why is inventory the foundation?
Because availability is computed from many inputs, not stored in one place.
What is available to lend at a given moment depends on settled positions, pending settlements in both directions, positions already lent or pledged, assets in a triparty pool, holdings subject to client restrictions or ring-fencing, securities near a corporate action record date, entity and jurisdictional boundaries, and intraday activity. Any of those missing produces a number that is optimistic, and an optimistic availability figure becomes a delivery failure. Build availability as a real-time computed view with visible components, so an operations user can see why a security is unavailable rather than discovering it at delivery.
Can your platform explain why a given security is unavailable to lend right now?
What makes inventory hard in practice?
Encumbrance, restrictions, and timing, all of which change during the day.
| Input | Complication |
|---|---|
| Settled versus traded position | Availability differs by settlement convention and market |
| Already lent or pledged | Must net out, including triparty allocations |
| Client restrictions | Per-client and per-mandate lending permissions |
| Ring-fencing and entity boundaries | Assets in one entity may not serve another's obligation |
| Corporate action proximity | Record dates constrain lending and create manufactured payments |
| Recalls in flight | Position is returning but not yet available |
| Fails and pending buy-ins | Expected position may not arrive |
| Regulatory and internal limits | Concentration and counterparty limits reduce usable inventory |
The corporate action interaction deserves particular attention, since lending across a record date creates entitlement complexity and manufactured payment obligations, which is why the economic position view matters in corporate actions automation.
How does collateral optimisation actually work?
As constrained allocation, where the constraints do more work than the objective function.
The objective is usually to deliver the cheapest acceptable collateral against each obligation while respecting every constraint. The constraints are the difficult part: per-agreement eligibility schedules, haircuts varying by asset class, rating, and maturity, concentration limits by issuer, sector, and currency, wrong-way risk restrictions, minimum denominations and settlement feasibility, and substitution rights. Encoding those accurately from legal agreements is the real project, and it is frequently done once and left to drift as agreements are amended.
What is the objective actually?
Cost of collateral delivered, adjusted for operational cost and risk, rather than notional efficiency.
Optimising purely on the theoretical cheapest asset produces high substitution volumes, settlement failures on illiquid instruments, and operational cost that exceeds the funding saving. Include a movement cost so the optimiser prefers stability, exclude assets whose settlement reliability is poor regardless of their theoretical eligibility, and weight for the funding value of retaining high-quality liquid assets, since delivering them as collateral has a liquidity consequence the treasury cares about. The liquidity cost allocation logic sits alongside the supervisory expectation that liquidity costs, benefits, and risks be allocated to business activities, as set out in the Basel Committee's liquidity principles.
Why does the constraint set matter more than the algorithm?
Because a wrong constraint produces a confidently wrong allocation.
An eligibility schedule transcribed incorrectly means the optimiser proposes collateral the counterparty will reject, which surfaces as a failed call and an urgent manual scramble. Maintaining the constraint set is therefore an ongoing data governance task with a named owner: every agreement amendment must reach the platform, every schedule needs a version and an effective date, and discrepancies discovered at delivery must feed back as corrections. Collateral quality also drifts over time between agreement and delivery, which is the phenomenon examined in collateral quality drift.
Why must optimisation be real time?
Because intraday margin calls, recalls, and market moves change the answer within hours.
An overnight optimisation cannot respond to a call due at midday, a recall received at ten, or a market move that changes haircut-adjusted values. The practical requirement is not microseconds, it is the ability to recompute an allocation within minutes of a change and to answer availability queries interactively. Design for incremental recomputation rather than full re-optimisation, since recalculating the entire book for one new obligation is both slow and disruptive, producing unnecessary substitutions. Intraday visibility of positions and obligations is the same requirement as in real-time treasury platform design and connects directly to intraday liquidity monitoring.
How do you handle recalls and fails?
As tracked workflows with prioritisation, because the downside is a fail and potentially a buy-in.
A recall arrives because the beneficial owner needs the security, frequently to sell or to vote. Meeting it requires locating a return or a replacement borrow within the settlement window, and missing it creates a fail with cost and potentially a buy-in. Treat recalls as cases with a deadline, an owner, and escalation, prioritise by consequence rather than arrival order, and instrument the fail path so the cost is visible. Fails analysis is also a useful data quality signal, since repeated fails on the same counterparty or instrument usually indicate an inventory or settlement assumption that is wrong rather than bad luck.
Are recalls tracked as cases with deadlines, or handled by email and memory?
How do triparty arrangements change the design?
They move eligibility testing and substitution to an agent, and they replace one problem with a reconciliation obligation.
Under triparty, the agent holds the collateral pool, tests eligibility, and performs substitutions, which removes substantial operational load. What remains is your obligation to know what is in the pool, to reconcile the agent's view against your own inventory and exposure, and to understand the eligibility profile the agent is applying. The failure mode is assuming alignment: your platform believes an asset is available while it sits allocated in a triparty pool, and the discrepancy appears when you try to deliver it elsewhere. Reconcile continuously against the agent rather than periodically, which is the same discipline as in this guide to pledged asset reconciliation.
What regulatory expectations apply?
Reporting and transparency, haircut standards, and cash collateral reinvestment limits.
The FSB's Policy Framework for Addressing Shadow Banking Risks in Securities Lending and Repos, published in August 2013, sets out thirteen recommendations covering improvements in regulatory reporting and market transparency, minimum standards for haircut methodologies with proposed numerical haircut floors for certain financing transactions, minimum standards on cash collateral reinvestment, and recommendations on central clearing and market infrastructure. For a platform, that translates into concrete requirements: transaction-level reporting capability with the granularity supervisors expect, haircut calculation that follows a documented methodology rather than negotiated convention alone, and controls over how cash collateral is reinvested with limits enforced in the system rather than in policy documents. Where transactions clear centrally, the infrastructure standards in the CPMI-IOSCO Principles for financial market infrastructures apply, covering central counterparties among other systemically important infrastructures.
What does reporting require from the platform?
Transaction-level records with the attributes and lifecycle events supervisors expect, produced without reconstruction.
Build reporting from the transaction store rather than assembling it from downstream systems, capture lifecycle events including modifications, substitutions, and terminations rather than only inception, and retain the ability to reproduce a submitted report. Counterparty identification, collateral detail, haircut applied, and re-use status all need to be first-class fields rather than derived at reporting time, because deriving them later is where inconsistencies enter.
How do you handle counterparty risk in the platform?
By evaluating exposure continuously against limits, with collateral quality included.
Exposure is not notional, it is the difference between obligation and haircut-adjusted collateral value, and it moves with markets. Compute it continuously, evaluate against counterparty and concentration limits before allocating, and monitor collateral quality rather than only quantity, since a fully collateralised position secured by concentrated, correlated, or illiquid assets is not as safe as the coverage ratio suggests. Counterparty assessment needs to combine credit, collateral, and concentration in one view rather than three, which is the argument in monitoring credit, collateral and concentration together. Operational friction in collateral processes is itself a risk, as described in collateral friction operating controls.
How do you measure the benefit honestly?
Against a documented baseline and counterfactual, net of operational cost.
Optimisation benefit is easy to overstate, because the natural comparison is against a badly chosen baseline. Record what the previous allocation approach would have delivered for each obligation, value the difference using consistent funding assumptions, and subtract the operational cost of additional substitutions and settlements. Report the net figure with the assumptions stated. Then track realised versus projected benefit, since projections built on theoretical eligibility routinely exceed what the platform can actually deliver once settlement feasibility and counterparty behaviour are included.
How should delivery be sequenced?
Inventory, then eligibility, then simple allocation, then optimisation, then real time.
| Phase | Duration | Deliverable |
|---|---|---|
| Inventory and availability engine | 4 to 6 months | Computed availability with visible components and encumbrance |
| Agreement and eligibility digitisation | 3 to 5 months | Machine-readable schedules with versions and owners |
| Exposure and limit monitoring | 2 to 3 months | Continuous haircut-adjusted exposure against limits |
| Rules-based allocation | 2 to 3 months | Deterministic cheapest-eligible allocation, measurable baseline |
| Optimisation engine | 3 to 4 months | Constrained optimisation with movement cost |
| Intraday recomputation | 2 to 3 months | Incremental response to calls, recalls, and market moves |
| Recall, fails, and triparty reconciliation | 3 to 4 months | Case workflow, agent reconciliation, cost visibility |
| Regulatory reporting | 2 to 3 months | Transaction-level lifecycle reporting from the source store |
Rules-based allocation before optimisation is deliberate. It delivers a measurable baseline, it captures a large share of the benefit, and it exposes the data quality problems that would otherwise be blamed on the optimiser.
Which metrics matter?
Availability accuracy, eligibility exception rate, allocation cost versus baseline, substitution volume, fails and recall performance, and reconciliation breaks.
Report availability accuracy, meaning how often a security shown as available could actually be delivered, since that number is the platform's credibility. Track eligibility exceptions discovered at delivery, which measures the quality of your digitised schedules. Report allocation cost against the documented baseline, net of operational cost. Watch substitution volume, because excessive churn indicates an optimiser without a movement cost. Measure recall fulfilment within window and fails with their cost. And report reconciliation breaks against triparty agents and custody records with ageing, as those breaks are where inventory accuracy quietly erodes.
Collateral optimisation rewards data discipline over mathematics. The institutions that capture the benefit spent their first year making availability computable and eligibility machine-readable, then found that a straightforward allocation rule over correct inputs beat a sophisticated optimiser over wrong ones.
Frequently Asked Questions
What does a securities financing platform have to do?
Maintain accurate inventory, trade and match, manage collateral including optimisation and substitution, and produce risk and regulatory reporting. Inventory accuracy underpins all of it.
Why is inventory the foundation?
Because availability is a computed answer, not a stored one. It depends on settled and pending positions, restrictions, pledges, ring-fencing, and corporate action records.
What does collateral optimisation actually optimise?
The cost of collateral delivered, subject to eligibility schedules, haircuts, concentration limits, and operational feasibility. The constraint set matters more than the algorithm.
Why does it need to be real time?
Because intraday margin calls, recalls, and market moves change the answer within the day, and an overnight optimisation cannot respond to a call due in an hour.
What makes recalls operationally risky?
A recall that is not met on time can lead to a fail and potentially a buy-in, so recall workflow needs prioritisation, tracking, and escalation rather than email.
How do triparty arrangements change the design?
They move eligibility testing and substitution to an agent, which reduces operational load and requires your platform to reconcile against the agent rather than assume alignment.
What regulatory expectations apply?
The FSB's policy framework for securities lending and repos covers reporting and transparency, minimum haircut standards including proposed numerical floors, and cash collateral reinvestment standards.
How do you measure optimisation benefit honestly?
Against a documented baseline and counterfactual, valuing the collateral actually delivered versus what the previous approach would have delivered, net of operational cost.
