Most investment book of record (IBOR) initiatives begin in the same place —with platform selection. Firms evaluate vendors, compare capabilities, debate buy vs. build, and quickly get drawn into questions of Order Management System (OMS) and Execution Management System (EMS) integration.
That sequence, while understandable, is also where many IBOR programs begin to go wrong.
As firms expand into private credit, structured products, and multi-manager operating models, maintaining a consistent view of positions, transactions, cash flows, and risk becomes increasingly difficult. Data arrives from different sources, follows different conventions, and is often defined or reported differently across managers. IBOR is no longer a reporting construct — it’s a real-time representation of the investment book and the operational backbone that supports trading, risk, finance, and client reporting. That means success depends less on the platform itself and more on the underlying investment data model.
The core problem? IBOR is fundamentally a data problem before it is a technology problem.
When firms invert that order, implementations that look good on paper often disappoint in production. The platform is live, but the IBOR is not trusted, operations teams are overwhelmed by exceptions, and every change feels risky. The difference between an IBOR that exists and one that is trusted almost always traces back to the quality of the data model, not the brand of the platform.
What IBOR actually requires
At its core, an IBOR answers three questions:
- What do we own?
- What is it worth?
- What risks are we taking?
Those three questions sound simple, but getting consensus across a modern portfolio is anything but, and establishing that consistency across asset classes, managers, and time horizons requires a well-defined data model. Many firms assume the platform will do this work. In practice, platforms impose structure, but they do not resolve ambiguity. If the underlying data model is unclear or inconsistent, the IBOR reflects those inconsistencies — just faster and at scale. For Operations, that translates directly into recurring breaks, noisy exception queues, and manual overrides that never quite go away.
These problems do not emerge during integration but surface earlier, when firms try to reconcile different representations of the same position, transaction, or lifecycle event. In our work, the implementations that disappoint are rarely “bad builds”; they are usually good builds sitting on top of ambiguous or conflicting data definitions.
Where tech-first strategies break down
When platform selection comes first, firms end up fitting their data into the constraints of the system rather than designing the system around their data. This becomes especially costly in complex environments.
- In private credit: Positions are not standardized instruments. Cash flows, accruals, and valuations are often model-driven and manager-specific. Forcing these into a rigid schema leads to loss of transparency or inconsistent valuation logic.
- In structured products: Lifecycle events like factor changes, amortization, or paydowns must be tracked with precision over time. If the data model does not support this granularity, downstream analytics will diverge.
- In multi-manager setups: Each manager delivers data in different formats with different assumptions. Normalizing at the platform layer without a clear canonical model introduces translation risk.
The result is familiar: reconciliation breaks, inconsistent P&L, manual overrides, and growing operational overhead, as what started as a technology initiative becomes a data remediation exercise. Operations teams respond by adding controls, spreadsheets, and “shadow” processes to catch issues — but those fixes are often local and manual, making the operating model brittle and difficult to scale.
The platform is configured correctly, but the data it consumes is noisy and inconsistently modeled, so the IBOR never becomes the single source of truth the business expects. In many cases, remediation efforts focus not on replacing the platform, but on unwinding the data issues that the platform simply made more visible.
What a data-first IBOR strategy looks like
A data-first IBOR approach starts by defining how the investment book should be represented independent of any platform. At the heart of that approach is a shared data model that establishes a consistent representation of investment data across systems and teams.
Consider a multi-manager private credit scenario. Each manager provides position and cash flow data at different levels of granularity, some at the loan level, others at aggregated facility level, with varying approaches to accruals and fees.
In a tech-first model normalization occurs within the platform itself, but a data-first approach takes a different path. It defines a canonical representation of the investment —how a position is constructed, how cash flows are categorized, how accruals are calculated — before any platform is involved. Manager data is then translated into that model upstream, preserving meaning and ensuring consistency. Only after that foundation is established does the IBOR platform come into play as a consumer of clean, standardized data.
When the canonical model is owned outside the platform, exception management becomes more effective because teams can address issues at the source rather than repeatedly patching them downstream. New managers and instruments plug into an existing framework instead of requiring bespoke workflows each time.
Why data architecture must come first
When firms define their data model first, several things follow naturally. Platform evaluation becomes more objective and focused on alignment rather than feature breadth. Integration becomes simpler because interfaces are built against a stable, well-defined model. Reconciliation is reduced by design rather than managed through exception handling, and new asset classes and strategies can be incorporated without reworking core structures.
It also enables a more flexible operating model. Data can be sourced, validated, and transformed independently of the IBOR engine, allowing firms to adapt as their investment strategies evolve without being constrained by platform limitations. For operations teams, that means a clearer ownership model for data quality, fewer “mystery breaks,” and the ability to automate corrections and late-arriving data once at the source instead of maintaining multiple overlapping fixes across systems.
Firms that invest early in data architecture gain greater flexibility over time. They can switch platforms, add new front-office tools, or adjust their operating model without re-architecting the IBOR from scratch because the data foundation remains stable.
The risk of designing around a platform
When the operating model is built around a vendor platform, that platform’s constraints become the firm’s constraints. Platforms evolve, business requirements change, and edge cases emerge, especially in private markets and structured products. Tightly coupling the operating model to platform logic means that even small changes can trigger significant rework.
This is where firms feel locked in — not just to a vendor, but to a way of representing their own data. When the data model is clearly owned and defined, the platform becomes interchangeable. It serves the operating model rather than dictating it.
We commonly see two paths emerge. In one, firms reshape their data and processes to fit the platform, creating workarounds each time a new product, manager, or strategy is introduced. In the other, firms establish the data model first and select technology that aligns to it, allowing new strategies and data sources to be incorporated without redesigning the core IBOR framework.
The difference is not the technology itself but whether the firm designed around the platform or around the data. The risk of getting this wrong is not theoretical — it shows up as delayed launches, persistent breaks, and programs that burn political capital because they never quite deliver the promised reliability.
What to define before evaluating IBOR platforms
Before beginning platform selection, firms should have clear answers to these foundational questions:
- What is the canonical definition of a position across all asset classes?
- How are lifecycle events represented and tracked over time?
- What level of intraday accuracy and timeliness is required?
- How will data from multiple managers or sources be standardized?
- What are the rules for valuation, accruals, and adjustments?
Without clear answers to these questions, platform evaluation becomes subjective and implementation risk increases. The goal is to account for corrections, overrides, partial updates, and multi-source conflicts before they become operational issues.
Start with the foundation
An IBOR is only as reliable as the data model behind it. Technology can accelerate, scale, and operationalize, but it cannot compensate for unclear or inconsistent data definitions. The firms that get IBOR right start by defining the data model and operating framework they need, then select technology that supports it. Those that start with the platform often spend years addressing issues that could have been resolved much earlier in the process.
To learn more about real-world IBOR implementations, read about our recent work helping a financial services organization with a multi-manager investment model. Whether you’re evaluating IBOR platforms, struggling with data consistency across risk and finance, or finding that your current implementation isn’t delivering the reliability your firm needs — let’s talk. The data foundation is fixable. And getting it right unlocks far more than better reporting.
Reach out to Mark Cunningham with questions or contact us to schedule a conversation.
