Insights

Your collateral optimiser is only as good as the data beneath it

Banks and asset managers have spent heavily on collateral optimisation, and much of it underperforms. The reason is rarely the algorithm. The optimiser is fed a fragmented, stale, point-in-time view of inventory, and it can only ever be as good as the picture beneath it. The unsolved part of collateral is the data layer.

By Antony Coppellotti, founder and fractional CTO, Gordion Solutions

Collateral used to be a back-office function. It is now a front-office cost centre, and the cost of getting it wrong has risen sharply.

Since the post-crisis reforms, the financial weight of every collateral decision has climbed: expanding uncleared margin rules, capital and risk-weighted-asset pressure, higher funding costs, intraday liquidity demands, and now the move toward mandatory US Treasury clearing. The slack that used to absorb inefficiency has gone. In a low-rate world a firm could hold a comfortable buffer of excess collateral and barely feel it. That era has ended, and even small inefficiencies in how collateral is sourced and allocated now translate directly into funding cost and liquidity strain.

So firms have invested in optimisation tooling. And yet many still over-post, hold larger buffers than they need, and scramble when a margin call lands. The question worth asking is why the tools have not closed the gap.

01The optimiser is not the bottleneck

The optimisation itself is a solved problem. Choosing the cheapest eligible asset to satisfy a requirement, while preserving liquidity flexibility elsewhere in the book, is a constrained optimisation that the established platforms handle well. The maths is not where firms are losing money.

An optimiser is only as good as the picture it optimises over, and the picture is where the trouble sits. Ask the people who run collateral what slows them down and the answer is rarely the algorithm. It is knowing what they hold, where it sits, what it is eligible for and what it is already pledged against, accurately and in time to act on it.

Industry commentary heading into 2026 is blunt about this. Sourcing collateral information is still too often done by email and phone, across fragmented systems and siloed teams. EY’s prescription is a consolidated, near real-time, enterprise-wide view of collateral with clear asset traceability. Deutsche Bank frames the precondition as interoperability built on common data models. None of that is a call for a better optimiser. It is a call for a better data layer.

A working collateral system has two parts: a connected data layer that holds the full picture, and an optimiser that acts on it. Most firms bought the second and never built the first.

02Why the data layer is the hard part

The data layer is hard because collateral is not one table. It is a web. Legal entities hold accounts at custodians and tri-party agents. Assets sit in those accounts. Each asset is eligible under some agreements and not others, subject to haircuts and concentration limits that differ by counterparty. Obligations pull against that inventory. Movement between locations follows legal pathways with their own costs and timings.

The questions that matter cut across all of it, and they are multi-hop. Where can I source eligible high-quality collateral to meet this call. What substitution frees up this specific bond without breaching another agreement. If I move this asset, which obligations and which downstream eligibilities are affected.

These are traversals, not row lookups, and they are exactly the kind of query where a relationship-first data model earns its place, and where deeply nested joins in a conventional schema turn slow and brittle. The point is not which database product a firm should buy. The point is that the problem is relationship-shaped, and a model that treats relationships as first-class answers these questions in ways a flat, table-centric one struggles to. Whether that lives in a dedicated graph engine or a graph encoded over an existing stack is an implementation choice, driven by query patterns, latency and scale.

And the value here is federation, not replacement. The vendor platforms already carry a data layer inside their own silo. The gap is the connected view across silos, across desks, custodians, internal funding and product lines, that no single point solution sees. A relationship-first layer is good at exactly that: unifying fragmented sources into one queryable picture without ripping out what is already there.

03The part most models miss is time

There is a second dimension that a relationship model alone still misses, and in collateral it is not optional. Collateral is not a static network. It is a temporal one. Inventory changes through the day. Eligibility schedules, haircuts and rates are effective-dated and move. A margin call lands at a point in time. A settlement cut-off is a deadline. The problem is intrinsically about state evolving over time.

That makes the questions that matter time bound. What was my available, eligible inventory at 11:00, what is it now, and what will it be at the cut-off. Those are as-of and intraday questions, and a view that only knows the present cannot answer them.

The sharper case is reconstruction. After a margin dispute or a stress event, a regulator does not only ask what the state was. It asks what you knew, and when. Answering that faithfully needs both axes of time: when a fact was true, and when you recorded it. A system that carries only current state can show you the corrected record. It cannot show you the picture as you understood it at the moment you acted.

So, a data layer that is relationship-aware, but time-blind is still modelling half the problem. Where time is part of the question, and in collateral it always is, the data layer needs to be temporal as well as connected.

Two qualifications, so this is not overstated. The optimiser still runs on a snapshot, so the value of time sits in producing correct as-of views, in projecting positions forward, and in reconstruction and audit, not in the optimisation step itself. And building time in natively is not the only route to these things: effective-dated schemas, temporal tables and event-sourced logs can all reconstruct as-of state. The advantage of native time is correctness and efficiency where time is central. It removes the bolt-on filtering, the timestamp logic scattered through application code, and the slow temporal joins that make point-in-time queries fragile. In a domain this time-bound, that is worth having.

04What good looks like

Put together, a collateral platform that performs has two halves that are too often discussed as one.

The optimiser is only the second half. It acts on a point-in-time projection of the connected, time-aware view beneath it.

A connected, time-aware data layer federates the fragmented sources into a single queryable view, one that can answer as-of and what-if questions across the whole inventory. The optimiser consumes a projection of that view and decides what to post. Both halves are needed. Most discussions of collateral optimisation only name the second.

The practical implication is an order of work. Fix the data layer first. The optimiser most firms already own will start earning its keep the moment it is fed an accurate, timely, complete picture, and not before. The instinct to buy a better optimiser is usually solving the wrong half of the problem.

None of this is a rip-and-replace. It is a layer above the existing point solutions, connecting what each of them sees into a view that none of them holds alone.

05Sources and further reading

1. Collateral optimization: capabilities that drive financial resource efficiency (EY). ey.com
2. Banks should optimise collateral in 2026 (A-Team Insight). a-teaminsight.com
3. How tokenised assets transform liquidity management (Deutsche Bank flow). flow.db.com
4. Collateral and Liquidity Efficiency in the Derivatives Market (ISDA). isda.org
5. Margin management and collateral optimization technology (TS Imagine). tsimagine.com