You bought an IBOR, but did you get one?
What an IBOR should do, why most IBORs still fall short, how realisation of the true gap has suddenly set in, and why getting it right is only the beginning.
Most firms in asset management believe they have an IBOR. Most of them do not, at least not in any meaningful sense.
We know this because we sell and implement our IBOR and as part of the sales or implementation process, we have some pretty frank conversations with clients and prospects about what they have now as an operating model and technology stack and what they wish to have.
From recent conversations, we can state that we regularly meet front office teams working from stale positions, operations teams battling to manually post elections on their corporate actions or coordinating regional closes and reruns. We hear of reconciliation teams switching between systems, batches and Excel to match their start of day, and the executive waiting for hours or days for whole of book positions, risk, collateral or exposure. Around it all, the steady drumbeat of human errors leading to incidents, missed opportunities, P&L hits, restatements.
We at FINBOURNE have been making the same argument for a while now – If you experience any of the above issues on even a semi-frequent basis, you don’t have an IBOR.
Over time, as we’ve made this argument, attitudes in the industry have changed. Where once we saw acceptance of the status quo, or polite disbelief that there could be something better, it feels like recent shifts in the technological landscape have given people the awareness of the gap, and the audacity to expect better than the dismal outcomes of the past.
In other words, we are no longer educating the market on gaps to what is acceptable in IBOR space.
However, why should anyone settle for acceptable? The market has moved on, demands have moved on. A single coordinated real-time global view of positions is no longer enough.
Let us show you where we think you should set your expectations in 2026 and beyond…
Why position data has been a problem for so long
For most of its history, positions 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, for regulatory and reporting purposes. 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, all trading states, and all time zones.
The structural consequence is familiar to anyone who has worked in investment operations. 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 (visible or not to the user) incorporates them. For a global, multi-asset fund, this is at best a coordination challenge and organisational weak spot., The weak spot tends to lead to repeated outages, slow resolution and sometimes delayed or incorrect investment decisions.
If you have separate data stores for your investment processes, (IBOR, ABOR, orders, transactions, corporate actions etc), and you operate globally, you likely need to open and close several time zones a day and you have plural admin data (your start of day positions,, performance record), plural market data vendors and corporate action and loan admin sources, and you are copying ABOR -> IBOR many times a day; you can see where fault lines appear.
In an event-driven live extract, positions are built on demand from the full history of underlying transactions and cash movements, in any state, at any point in time. No snapshots. No batch dependency. The coordination exercise from the above state is a rules-based, desk-specific, granular position build that is core operating system rather than SQL-based data transport.
Only this third approach solves the problem fully.
Non-negotiable IBOR requirements (for last year’s IBOR)
What separates a genuine IBOR from a system that claims the label is more demanding than most vendor summaries suggest. There are four areas where the difference shows up: how positions are constructed, how position states are managed across the investment lifecycle, how users extract and reconstruct position views, and how data quality is governed independently.
Event-driven position construction
Positions should be extractable in close to real time, incorporating the impact of all known events up to the moment of the request. Every event generates one or more discrete position impacts — a trade execution, a corporate action, a cash movement, a collateral call — each of which a genuine IBOR captures from the moment it first becomes available, tracks through its full life cycle, and uses to construct position views on demand. The position is a derived output of that event history, not a stored record requiring periodic refresh.
State management
Four states define the lifecycle of any position impact: estimated, committed, contractual, and physical. Different users need different states: portfolio managers need estimated and committed positions for investment decisions; compliance teams need contractual positions for pre-trade checks; settlements teams need physical positions to manage fails. A genuine IBOR tracks each impact through every state, allows users to specify which states to include in any given extract, and makes the certainty of the resulting position data explicit. This is the mechanism that allows a single IBOR to serve front, middle, and back office from the same underlying data, without maintaining separate books for each function.
View-on-demand and historical reconstruction
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. This matters not just for performance attribution and regulatory reporting, but for operational integrity: a late-arriving corporate action or corrected settlement can be applied retrospectively, and the position record updated consistently across all time points, without corrupting downstream data.
Data quality management as a core, not a feature
Data quality management is a core IBOR function, not a frontier feature. A genuine IBOR projects the expected lifecycle of every event, validates that state transitions are within tolerance, suspends and flags anomalies when they are not, and generates alerts to data owners when position data quality is in question. Critically, a genuine IBOR derives its integrity from its own quality management process, not from an external source. A system that validates itself against a custodian or accounting feed each night is not independent. It is dependent, and that dependence is a design flaw, not an acceptable trade-off. This does not mean reconciliation between the IBOR and the accounting system is unnecessary. It means the IBOR should be able to stand behind its positions independently, so that reconciliation functions as a cross-check between two authoritative sources rather than the process by which the IBOR establishes what it holds.
Most claimed IBORs still do not meet this standard (and we’re still on last year’s standard) – but how can you tell?
The term IBOR was captured by marketing well before most vendors could actually deliver what it implies. The event-driven architecture a genuine IBOR requires is technically demanding and takes years for any vendor to build. In the intervening period 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 practical consequences are familiar. Front office teams work with positions that may be hours out of date. Intraday events require manual intervention to incorporate. Reconciliation between the claimed IBOR and the accounting system requires constant management. Regulatory reporting that requires intraday granularity relies on workarounds.
The test is simple. Ask the vendor how positions are constructed. If the answer involves a starting snapshot, an overnight process, or a stored balance, the system is not a genuine IBOR, regardless of what it is called. The five questions at the end of this article make this evaluation straightforward.
Getting the IBOR right is the floor, not the ceiling
The requirements above establish the latency and quality requirements. This section moves on to where next. That is a question most IBOR conversations never reach.
The market has moved on and demands of the system have too. Solving the position visibility, latency and quality problems is no longer the whole answer.
Firms are now managing multi-asset, global portfolios with private market exposure alongside public markets (private credit AUM alone is forecast to grow from $2.3 trillion in 2025 to $4.5 trillion by 2030, according to Preqin). They are navigating regulatory regimes that require position-level data at granularity and frequency that the 2014 IBOR Standards Working Group paper was never designed to anticipate. They are trying to apply AI and machine learning to investment data that remains fragmented across systems – a 2026 Mercer survey of 131 asset managers found 69% cite data quality or access as the primary barrier to AI adoption. And they are doing all of this while trying to reduce, not increase, the number of platforms they operate.
A standalone IBOR, however well-built, does not solve all of these challenges: neither the broader demands on investment data infrastructure nor the operational complexity of acting on it. It solves one piece: the position visibility problem. And it adds another: a new system to integrate, maintain, and reconcile. The firms that are getting the most from their investment data are not those that have the best IBOR. They are those that have built, or are building, a unified investment data foundation on which the IBOR is one capability among many.
The FINBOURNE platform was built from the ground up as an event-driven, live-extract system. Positions are constructed on demand from the full history of underlying transactions and cash movements, in any state, at any point in time. There is no batch dependency, no start-of-day snapshot, no overnight process. A trade confirmed at 2pm is visible at 2pm.
But the platform was designed to do more than that. Because it stores the full, immutable history of every event and transaction, it is also the foundation for regulatory reporting, AI-driven analytics, and whole-of-firm data consolidation. The same event history that powers the IBOR also powers everything downstream of it. That is not a coincidence of product design. It is the point. As are these:
Bi-temporality: every transaction is recorded against both the date it occurred and the date it was known to the system, which means late-arriving data, corrections, and amendments do not overwrite history. They are appended to it. This makes regulatory reconstruction, audit, and as-of reporting genuinely reliable rather than a best-effort approximation.
Data virtualisation: FINBOURNE’s data virtualisation layer sits on top of that history and allows any team: investment, operations, risk, finance, technology, to query the same underlying data in the form they need, at the time they need it, without a separate extract, a data warehouse, or a bespoke integration. It is not a reporting layer: it does not move or copy data. It virtualises access to the event history itself, so every query reflects the current state of the record.
API-first architecture: Every capability is exposed through an open API and a published SDK, which means the investment teams and technology functions that want to build on top of it can do so directly, rather than waiting for a vendor roadmap to catch up with their requirements. There are 8500+ endpoints ripe to be explored in natural language using client tools or FINBOURNE tools with full traceability of the decisions made, whether system or human-in-the-loop originated.
This also means FINBOURNE can be deployed as a standalone IBOR without requiring firms to rip out existing platforms. The architecture is additive: the platform integrates with incumbents, masters and quality-checks data from all sources, and generates outputs back into existing systems for execution. Firms get the IBOR capability immediately, with a clear path to consolidate further as their needs and confidence grow. The case study below shows how this worked in practice for one of the world’s largest pension funds.
What this looks like in practice
One of the world’s largest pension funds — managing a multi-asset portfolio spanning public equities, fixed income, private markets, and alternatives across multiple time zones came to FINBOURNE with a challenge that illustrates both problems: a position visibility problem preventing intraday decisions, and an investment data infrastructure problem preventing the firm from operating at the scale it needed. The fund had announced plans to significantly expand its international footprint: tripling headcount in one major financial centre, substantially growing operations in another, and targeting 70% of capital invested outside its home market. The incumbent system ran on batch processing. Start-of-day positions were the default. Intraday activity was invisible until the overnight cycle completed. Private market data could not be integrated alongside public market data. Client reporting required slow, manual processes with no real-time data access.
For a fund of this scale, operating across multiple time zones with 70 per cent of capital offshore, those were not manageable inefficiencies. They were a direct constraint on the planned expansion. The fund needed intraday positions across all asset classes, visible to investment teams in every location, without a system that reset each morning.
The fund did not want to replace its existing platform. It needed a system that could augment what it had: integrating cleanly, mastering data from all sources, and generating outputs back into the incumbent for execution. FINBOURNE was selected. The platform ingests data from all sources, masters it, and performs continuous data quality checks. The data virtualisation layer presents real-time position views to investment teams and downstream systems. FINBOURNE generates rebalancing orders for execution back in the incumbent platform. One thing about the evaluation is worth dwelling on. The strongest advocates for change were the investment teams, not operations or technology. The front office pushed for FINBOURNE because they felt the data limitations most directly. They were the ones making investment decisions from stale positions. The fund selected FINBOURNE because an API-first design and an extensible data model made the platform materially easier to fit into existing investment workflows than the alternatives evaluated. The IBOR was the immediate need. The broader data foundation was the longer-term value.
The fund can now rebalance across its whole-of-fund structure, sleeve by sleeve, in real time, with positions that reflect what is actually happening in the portfolio rather than what happened yesterday. That is what a genuine IBOR delivers: the position visibility problem, solved. And because FINBOURNE’s architecture goes beyond position visibility: mastering data across sources, virtualising access firm-wide, integrating without replacing the incumbent, the fund now has the foundation for what comes next: unified investment data that supports multi-asset decision-making, regulatory reporting, and AI — from a single infrastructure rather than a patchwork of systems.
Five questions to ask any IBOR vendor
The following five questions cut through the marketing around IBOR quickly. A vendor with a genuine, event-driven IBOR will answer them without hesitation. A vendor with a snapshot-based or rolling-balance system will not.
1. How are positions constructed?
The answer should be: on demand, from underlying transactions. If the answer involves a starting snapshot, a stored balance, or an overnight process, the system is not a genuine IBOR.
2. How quickly does an intraday event appear in position views?
Immediately, or within seconds. If the answer is ‘at the next refresh cycle’ or ‘after the overnight batch’, the system is operating on snapshot-based or rolling-balance logic.
3. Can the system reconstruct positions as of any point in historical time?
A genuine IBOR retains the full event and transaction history and can reconstruct any position view at any historical moment. This is essential for regulatory reporting, audit, and performance attribution. If the answer requires exporting to a data warehouse first, that is a workaround, not a capability.
4. Can different users get different position views from the same underlying data?
A portfolio manager, a compliance team, and a settlements team all need different views of the same portfolio. A standard-compliant system constructs each from the same transaction data with different state and timing parameters. If the answer requires maintaining separate data sets for each function, that is a red flag.
5. How does IBOR connect to the rest of your data architecture?
Most IBOR evaluations focus entirely on position construction and never reach this question. A standalone IBOR, however capable, creates a new integration point in your architecture. Ask the vendor how the IBOR connects to your data warehouse, your risk system, your regulatory reporting, and your AI initiatives. Ask whether downstream systems query the IBOR directly or whether data must be extracted and moved first. Ask what happens when your operating model changes and you need the IBOR to serve a new use case. The firms building the most resilient investment data infrastructure are the ones treating the IBOR as a component of a larger data architecture, not as a destination.
