Designing the Layer Between Raw Data and Business Decisions
Portfolio mapping system for a crypto hedge fund
saved per operations manager
double-counted balances
inherited by every page in the product
How the data gets in
Hedge fund portfolio managers and operations managers hold crypto assets through keys — wallet addresses that point to balances recorded on the blockchain, scattered across exchanges, networks, and protocols. Those keys need to be linked to the system via API connections. This case study picks up right after — once the data is in, and the question becomes: how does a trading desk make sense of it?
Connected data that didn't represent the business meaning
Wallet balances were live and connected. To trade, allocate, or report, managers needed that balance attributed to an entity — a desk, a strategy, a fund. Before this system, that attribution was done by hand in Excel.
Complication: the same account can belong to more than one entity — a desk's book and a firm-wide risk view. If both are counted at once, the balance is counted twice.
Question: how do you organize the entity logic behind a portfolio so users can see its accurate state — and make decisions on it — even when the underlying structure might be interconnected?
Business entities, account overlap and a hierarchy that isn't strict
Portfolios represent real business entities. Each group of accounts stands for something the business already operates by — a desk, a strategy, a fund — and these structures can change over time as the business does.
The same account can legitimately belong to more than one entity. A single account can fund a desk's trading strategy and also roll up into a firm-wide risk view.
"Sometimes we need to map one account to multiple portfolios for different business scenarios."
— Portfolio Manager, Hedge Fund
Portfolios aren't organized in a single hierarchy - Every portfolio is built from accounts. At each level, a portfolio directly contains one type — accounts, or other portfolios. A portfolio can also have two parents, each in its own separate chain.
Portfolio as filter, controlled overlap, and a lean table solution
The portfolio becomes the lens all data is filtered through — positions, balances, and finance analytics all resolve through it, not through raw accounts.
An account can be mapped to more than one portfolio, but never viewed through two at once — allowing the business need, while preventing double-counted, misleading data.
Portfolio structure was represented inside the existing table, in the simplest form that fit it. A "Mapped" column shows what type of data the portfolio contains. The "Member Of" column then shows its parents as chips, since a portfolio can have more than one. Extending the existing table with these two columns was the leanest solution: no new structural view was needed, just two columns doing distinct jobs.
Representing portfolio structure and status
Two clear stages: Create (name + entity type) and Map (assign accounts or sub-portfolios). Three decisions shaped the table itself.
Resolving the overlap at the point of mapping
The resolution meets the user at two different moments: at mapping, and at filtering. Multi-account mapping can be done, but with a disclaimer.
Resolving the overlap at the point of selection
Error prevention: disabling the overlap at the point of selection — selecting a portfolio disables any other portfolio that shares an account with it, so a balance can never be counted twice. Unlike the warning at mapping, this is enforced directly — a short message explains why the option is unavailable.
What shipped, and what it changed
Saved per operations manager in manual reconciliation.
Unlocked with the design partner, by proving the technical precision the partnership needed.
The object-mapping system every page in the product now runs on, reusing the same hierarchy and filtering logic.