SimCorp Data Model: Understanding the Core Object Structure Before You Build

Every SimCorp implementation begins, knowingly or not, with a set of assumptions about how data is structured in the platform. The assumptions that are made explicit and understood early produce implementations that scale cleanly and reconcile reliably. The assumptions that remain implicit surface later as data breaks, reporting inconsistencies, and performance bottlenecks that require expensive remediation.

Understanding SimCorp’s core object structure before a single workflow is configured is not a theoretical exercise. It is the practical foundation on which every other design decision rests, and getting it right matters as much as any individual functional configuration.

The Unified Data Model as a Design Philosophy

SimCorp One is built on a single unified data model that treats all assets, all transactions, and all analytical outputs through the shared core structures and governance rules. This is philosophically different from platforms that aggregate data from multiple underlying systems: in SimCorp, equities, fixed income, derivatives, private markets, alternatives, and ESG data all conform to the same data standards and validation rules. SimCorp’s architecture documentation points out that many platforms claim to offer a single IBOR, but in reality, they provide a patchwork of integrated data stores. SimCorp’s IBOR gives a full instrument lifecycle covering both current and expected holdings, intraday cash management, and a complete backstory of how every position and valuation was created.

AXA, the global insurer, selected SimCorp One specifically because it offered the market’s only solution integrating a front-to-back and multi-asset class system built on a unified data structure. The platform’s unified data model for investment management helps organisations align portfolio management with accounting requirements, enabling consistent risk oversight, investment governance, and regulatory compliance across global operations.

The Core Object Hierarchy in SimCorp

The SimCorp data model organises information through a clear object hierarchy that runs from the most granular level of individual security attributes through to the aggregate level of total portfolio views. Understanding this hierarchy is what allows implementation teams to configure data correctly at each level without creating inconsistencies that propagate upward to reporting and analytics outputs.

The Instrument Object

The instrument is the foundational data object in SimCorp. Every security, derivative, or financial contract that can be held in a portfolio must first exist as a correctly configured instrument record. The instrument object captures static reference data including identifiers such as ISIN, CUSIP, and SEDOL, security type, maturity date, coupon structure, pricing methodology, day count convention, and settlement convention. Instrument data management is consequently one of the highest-impact configuration areas in any SimCorp implementation. Errors at the instrument level affect every portfolio that holds the security, every analytics output that references it, and every accounting entry it generates throughout its lifetime.

The Portfolio Object

The portfolio object defines the investment mandate and the rules governing how positions within it are managed. Key attributes of the portfolio include the base currency, the benchmark, the accounting standard and fund domicile, the compliance rule set applicable to the mandate, and the pricing source hierarchy. The portfolio object is also where the relationship between the investment book and the accounting book is defined, establishing whether the portfolio operates on a trade-date or settlement-date basis for each type of reporting output.

The Position Object

Positions are the dynamic records created as instruments are bought and sold within portfolios. The SimCorp IBOR maintains positions in real time, updating the moment a trade is captured rather than waiting for settlement confirmation. The position object carries current quantity, average cost, unrealised gain or loss, accrued income, and exposure data derived from the underlying instrument attributes. The implication of financial system implementation is that the position object must be correctly linked to both the instrument and the portfolio objects to produce accurate analytics and accounting outputs.

The Transaction Object

Every trade, corporate action, income event, and valuation adjustment generates a transaction object that records the economic event in the platform. Transaction objects carry the full detail of each event, including counterparty, price, quantity, settlement date, and the accounting entries generated by the event. SimCorp’s transaction architecture ensures a complete backstory of how every position was created, meaning that the current position can be reconstructed by replaying its transaction history. This is critical for audit purposes and for resolving reconciliation breaks where a custodian’s position record differs from the internal book.

The Cash Object

Cash positions are managed as first-class objects within SimCorp’s data model rather than as derived outputs. The platform manages cash balances intraday, updating balances and forecasts as trades and settlement events are processed. This real-time cash visibility supports treasury operations, compliance monitoring of cash limits, and NAV calculation accuracy without requiring a separate cash management system.

The Data Management Layer

Above the individual objects sits a unified data management layer that governs how data is ingested, validated, and distributed across SimCorp’s workflows. SimCorp One’s financial data modeling layer captures data from multiple sources, including market feeds, reference databases, financial counterparties, and proprietary datasets. The platform’s flexible architecture accommodates different data types and formats, making information accessible through APIs, file transfers, or direct connections to analytics platforms. This open data architecture is what enables the IBOR to serve as the foundation for analytics, compliance, accounting, and reporting without requiring data duplication across separate systems.

Build a strong foundation for your SimCorp implementation with Ascenteum. Our experts help investment managers design scalable data model architectures, strengthen data governance, optimise integration design, and support automation and streaming valuations, reducing complexity and avoiding costly rework from the outset.