By Gus Sekhon, VP Strategy at FINBOURNE Technology
Most asset managers believe they have an IBOR. Most of them do not, at least not in any meaningful sense.
Operations teams battle to manually post elections on their corporate actions or coordinate regional closes and reruns. Reconciliation teams switch between systems, batches, and Excel to match their start of day, while senior leaders wait hours, or even days, for a whole-of-book view of positions, risk or exposure. Around it all, the steady drumbeat of human errors leading to incidents, missed opportunities, P&L hits, restatements.
If a firm experiences these problems in their daily workflow, it should question whether it really has an IBOR.
The term IBOR was embraced by the market before many systems could deliver what it implied. Recent shifts in the technological landscape have given people awareness of the shortfall; but it’s too late to rectify this alone – the market has evolved, and a coordinated view of positions should now be the starting point, not the end state.
The long-lived problem with position data
For most of its history, position data in asset management have been a by-product of accounting. Accounting systems were built to produce accurate, auditable records of what a fund owns, at what cost. They are good at that job, but they were not built to provide the front office with a live, intraday view of positions across all asset classes, trading states, and time zones.
The structural consequence is familiar; portfolio managers start the day with positions that reflect the previous close. Intraday trades, corporate actions, collateral movements, and cash flows are invisible until a scheduled batch process incorporates them.
For a global, multi-asset fund, this is an organisational weak spot. It tends to lead to repeated outages, slow resolution, and sometimes delayed or incorrect investment decisions.
Over time, systems were added to improve visibility, but many continued to rely on starting snapshots and stored balances. The label changed; the underlying architecture often did not.
Displaying a position is not enough
A genuine IBOR should construct positions on demand from the full history of underlying transactions and cash movement, in any state and at any point in time.
Every trade execution, corporate action, cash movement and collateral call creates a position impact. The IBOR should capture that impact from the moment it first becomes available, track it through its full life cycle, and use it to construct position views on demand.
The position is therefore a derived output of that event history, not a stored record requiring periodic refresh.
This distinction is important for the simple reason that different users need different states. Portfolio managers, for instance, need estimated and committed positions for investment decisions, while compliance teams need contractual positions for pre-trade checks. Settlements teams, on the other hand, need physical positions to manage fails.
A genuine IBOR serves front, middle, and back-office teams from the same underlying data, without maintaining separate books for each function.
A diluted definition?
While the industry has allowed the definition of an IBOR to become more elastic, there are some defined capabilities that separate a genuine IBOR from a system that merely claims the label.
For one, users must be able to specify the timing, perspective, scope, status assumptions, and exclusions of any position extract, and to reconstruct positions for any scenario at any point in historical time. Every event and every correction must be retained in full.
What’s more, data quality management must be a core IBOR function, not something tacked on. The system should project the expected lifecycle of every event; validate that state transitions are within tolerance; suspend and flag anomalies when they are not; and generate alerts to data owners when position data quality is in question.
Reconciliation with an accounting or custodian feed also remains necessary. But an IBOR should be able to stand behind its positions independently, so reconciliation acts as a cross-check between two authoritative sources rather than the process by which the IBOR establishes what it holds.
Cutting through the marketing
The term IBOR was captured by marketing well before most vendors could deliver what it implies. The market filled with snapshot-based and rolling-balance systems carrying the IBOR label, and buyers had no reliable way to distinguish them from the real thing.
The simplest test is to ask how positions are constructed. If the answer involves a starting snapshot, an overnight process, or a stored balance, alarm bells should ring, regardless of what it is called.
Buyers should also ask how quickly an intraday event appears, whether any historical position can be reconstructed, and whether different users can obtain the views they need from the same underlying data.
Getting these fundamentals right is now the floor, not the ceiling; a genuine IBOR must also connect cleanly with the rest of the firm’s investment data architecture rather than becoming another platform to integrate, maintain and reconcile. The industry should, therefore, stop judging IBORs by the label and start examining the machinery beneath it.
