Architecting for Total Portfolio Approach

“Architecture is about the important stuff. Whatever that is.” – Ralph Jophnson.

While Strategic Asset Allocation (SAA) and Total Portfolio Approach (TPA) are both investment philosophies, they require fundamentally different architectures to support them. Most asset owners do not struggle because of the allocation approach they choose. They struggle because the systems, data structures, and design decisions that support that approach often fail to align with how investment decisions need to be made operationally. Architecture ultimately determines execution efficiency.

In the previous chapter, we discussed how TPA changes how asset owner executives evaluate trade-offs across liquidity, leverage, risk, and return. Infrastructure must support that shift in mindset.

For Chief Investment Officers (CIOs), risk leaders, and operations teams, the practical question becomes clear: does the current architecture allow the organization to see, model, and act at the total portfolio level, or do fragmented asset-class views still limit decision-making?

This chapter focuses on three practical architectural questions:

• What does architecture mean for asset owners, and which parts of the market have reached an inflection point?
• Why SAA-native architectures struggle to support TPA?
• Which characteristics define TPA-enabled architecture?

What Architecture Means for Asset Owners

We define architecture as the set of choices firms make across data management, vendor platforms, technology, and integration mechanisms to enable portfolio insights for board reporting and ongoing investment monitoring.

In our experience, most asset owners operate within a multi-vendor ecosystem, often combining platforms such as Simcorp, Blackrock, FactSet, Eagle, Ortec, and MSCI, etc. Expecting one platform to satisfy the needs of Accounting, Performance, Risk, and the CIO office – particularly given the complexity of CIO use cases – is ambitious.

That does not mean firms cannot establish an effective architecture. It means they must pick the right tool for the right purpose, while accepting that some intentional redundancy may be necessary.

Over the past decade, asset owner landscape has expanded through the addition of modules, broader asset-class coverage, stronger reporting interfaces, and faster calculation engines. On-the-fly calculation engines have reduced many of the scalability issues that once constrained reporting. Yet the underlying data model remains largely unchanged: security master-centric, functionally siloed, and built around traditional reporting workflows.

That is where the next inflection point is emerging.

Capabilities that once felt aspirational – such as ex-post scenario modeling and ad-hoc analytical requests supported by agentic workflows – are becoming realistic operating expectations. Firms that adopt these capabilities early will create meaningful operational advantage.

The organizations that navigate this technological transition most effectively are those that understand which architectural decisions they make today will foundationally define what capabilities they can support tomorrow.

Why SAA-Native Architectures Struggle to Support TPA

SAA-native architecture centers on a security master and accounting-driven paradigm. Reference data, positions, transactions, valuations, performance, and risk analytics all anchor to a tightly coupled investment structure. In this model, the portfolio is a collection of security positions valued relative to  market benchmarks.

That structure remains highly effective for maintaining a book of record and producing asset-class-specific performance and risk analytics. But it creates limitations when firms need portfolio intelligence that cuts across traditional asset boundaries.

1.Cross-Asset Views Are Expensive

Most SAA native systems rely on tree-based hierarchies where the portfolio serves as a primary entity and benchmarks attach to those portfolios. The structure usually follows:

Asset → Portfolio → Asset Class → Total Fund

This model supports clear ownership and scalable reporting for predictable workflows. But once firms need cross-asset views, the structure becomes cumbersome to handle.

Teams often consolidate asset-class views, apply manual adjustments, and reclassify exposures before analytics become usable. Each additional data layer introduces more controls, more operational effort, and more strain. As a result, reports arrive less frequently and are often too late to support active decision-making.

2.Rebalancing and Overlays Sit Uncomfortably in Static Structures

Firms often configure rebalancing programs and overlays as notional portfolios assign to specific positions in the hierarchy.

That works until decision rights are split across levels – for example, when the CIO controls total fund rebalancing while asset-class teams control underlying implementation. Static portfolio buckets struggle to reflect those shifting relationships cleanly.

3.Ex-Post What-If Analysis Remains Difficult

As we alluded to in the first chapter, market volatility and macroeconomic events have a significant impact on the asset owner’s global portfolios. These events drive questions from CIO offices, such as:

• What would my portfolio return look like today if we had sold beta exposures in 2018?
• What would be my liability stream if we had invested more in inflation-adjusted bonds a year ago?”

Demand for ex-post scenario modelling continues to increase, yet SAA-native architectures still handle these requests poorly.

In practice, firms often revert to spreadsheet-based calculations because existing systems cannot flex fast enough.

SAA architecture provides greater clarity in governance than analytical flexibility.

Characteristics of a TPA-Enabled Architecture

A TPA-enabled architecture starts from a different premise: it treats the portfolio holistically.

That means the architecture must generate a Total Portfolio view even when data arrives at different times. From different resources, and with varying levels of completeness.

Rather than waiting for perfect data, TPA architecture layers calculated assumptions and reasonable models that sit on top of a book of record. That allows firms to answer most portfolio questions across both asset and liability dimensions in real time and retrospectively.

1.Best-Efforts Metrics Matter

An asset owner’s investment team rarely works with perfectly synchronized data.

• Equity positions may reflect internal IBOR values from 9:00 AM.
• Private equity valuations may still reflect month-end figures.
• Infrastructure values may come from the prior quarter.
• Currency hedge ratios may reflect last week’s overlay adjustment.

A TPA-enabled architecture selects the best available inputs, fills gaps intelligently, and constructs an approximate total portfolio view.

An 80% directionally correct portfolio view at 9:00 AM often provides more value than a 99% precise view delivered later in the day.

2.Adaptive Structures Matter

TPA architecture treats rebalancing programs, overlays, and notional constructs as flexible positions in the hierarchy.

A network-oriented architecture enables seamless relationships, constraints, and dependencies to evolve. Firms can implement this through graph constructs or through relational models enhanced with additional abstraction layers.

The operational benefit is significant: teams spend less time assembling views and more time explaining implications.

3.Top-Down Calculation Mechanisms Matter

Most market systems calculate from the bottom up.

TPA also requires firms to introduce top-down logic.

Many asset owners use reference portfolios, and policy portfolios to capture strategic decisions. Those decisions often require adjustments that bottom-up models do not naturally capture – such as allocating operational expenses across asset classes or distributing due diligence costs across externally managed mandates.

Top-down adjustments make performance analysis more representative of how value is created across the organization.

TPA architecture supports real-time aggregation, apportioning and decomposition.

Mini Case Study: Architectural Impact on Board Reporting

A national pension fund moving from a long-only mix of equities, fixed income, and private equity into a broader TPA approach that includes private credit has not simply added another asset class. It has multiplied data and process complexity by a significant order of magnitude. This has important implications for board reporting, because executives require decision-grade data, not reporting-grade data.

In this example, private credit exposure introduces borrower financials, covenant metrics, collateral valuation, payment waterfall, FX exposure, counterparty risk, and liquidity horizon.

Each input affects another:

• Covenant metrics indicate financial health assessment.
• Exchange-rate assumptions alter FX exposure.
• Payment waterfalls reshape liquidity projections .

Complexity does not rise linearly. It compounds.

If architecture cannot harmonize data challenges to present a total portfolio view, board reporting quickly becomes inconsistent — and in some cases internally contradictory.

Executives need decision-grade data, not simply reporting-grade data.

Conclusion

Architectural evolution rarely starts with a blank sheet. Most asset owners operate within layered environments shaped by years of incremental decisions, platform additions, and practical compromises. The challenge is not replacing systems. It is understanding which structural choices constrain total portfolio thinking and which enable it.

Across our work with asset owners in the U.S. and Canada, we consistently have seen that firms who approach architecture deliberately – aligning data models, calculation engines, and integration patterns to strategic intent – place themselves in a better position to operationalize TPA.

Upcoming Conversations

Our Total Portfolio Approach series continues to focus on specific elements of Total Portfolio View. The next chapter explores the importance of investment data, making the case for an Investment Book of Record and detailing what it should include. Moving on, we outline the use of notional portfolios and real-time analytics to facilitate a Total Portfolio View. Our final piece includes asset owner journeys that demonstrate different paths to the same destination, based on a firm’s distinctive operating structure.

Download Thought Leadership ArticleServices: Process Design and Change, Solution DesignExpertises: All MeradiaClients: Asset OwnerAuthors: Jose Michaelraj