← Back to Insights Case Study

Consolidating four brokerage accounts into one live portfolio view

1 August 2026

Most portfolio problems aren't portfolio problems. They're data problems wearing a costume.

The situation behind this build is common enough among Australian investors that it barely registers as a problem until you try to answer a simple question. Holdings had accumulated across four separate accounts: a trust account, a personal share account, a trading account, and superannuation. Each one had its own login, its own reporting format, its own idea of what a "position" record looks like, and its own base currency.

Individually, every account worked fine. Collectively, there was no single place that could answer "what do I actually hold right now, and what is it worth in Australian dollars?" Answering it meant opening four interfaces, exporting four inconsistent files, and reconciling them by hand. The result was out of date the moment it finished.

Why the off-the-shelf answer didn't fit

Consolidated portfolio tools exist, and plenty of them are good. Two things ruled them out here.

• Account structures don't map cleanly. Most retail tools assume one person, one account. A trust, a personal account, a trading account and a super balance are legally and practically distinct, and they need to be viewable separately as well as in aggregate. Most tools make you pick one or the other.
• Multi-currency handling is usually an afterthought. Where five currencies are involved, the conversion rules matter more than the display. A tool that quietly applies one blanket exchange rate produces a number that looks authoritative and is wrong.

The build-versus-buy call wasn't about cost. It was the specific shape of the problem: heterogeneous account types, genuine multi-currency exposure, and a requirement to see both the parts and the whole. That combination sat just outside what the general-purpose tools were built for.

What we actually built

Apex Terminal is a portfolio interface, but the interface is the smallest part of it. Roughly three-quarters of the work sat underneath, in the layer nobody sees.

• A normalisation layer. Every source account gets translated into a single internal position record with a consistent schema, regardless of how the originating platform formats its data. Every downstream calculation reads from that one shape, not from four.
• Explicit currency handling. Each position carries its own native currency as a first-class field rather than an assumed default, and conversion happens at one defined point in the pipeline instead of being scattered through display logic.
• Instrument-type awareness. Listed equities, ETFs, options and cash balances don't share a data model. Forcing them into one generic "holding" row loses information. Giving each its own handling and aggregating at the top preserves it.
• Account-level and aggregate views. Each account stays individually inspectable, with a combined view sitting over the top, rather than a single flattened list that destroys the structure.

The part that was harder than expected

Building the view was straightforward. Trusting it was not.

The failure mode in a consolidation tool isn't a crash. It's a number that renders confidently and is subtly wrong. A missed currency conversion, a position counted twice because two accounts describe it differently, a cash balance in the wrong denomination. None of these announce themselves. They just quietly change the total.

We hit exactly this class of bug on another tool in the same family earlier this year: a currency-handling defect that stored records against the wrong denomination and overstated some values by roughly threefold. It looked completely plausible on screen. The lesson carried straight into this build. Every value that crosses a currency boundary needs an explicit, traceable conversion step, and any aggregate figure needs to be reconcilable back to its sources on demand.

That's the real engineering content of a consolidation tool. The dashboard is the easy half.

The transferable pattern

Very little of the above is specific to investing. The same structure shows up any time an operator's data lives in several systems that were never designed to talk to each other. A business running separate point-of-sale, rostering and accounting platforms has the identical problem in different clothes.

• Normalise into one internal shape early, and let everything downstream depend on that shape rather than on any individual source system.
• Make the assumptions that usually go implicit (currency, timezone, units, entity) explicit fields in the data model.
• Keep the source-level detail intact underneath the aggregate, so any headline figure can be traced back to what produced it.

Do that, and adding a fifth account later is a small job instead of a rewrite. Skip it, and every new source makes the system more fragile than the manual process it replaced.

This write-up describes a software engineering project and the design decisions behind it. It is not financial product advice, and it does not describe or recommend any investment approach.