One household, eleven asset classes, one set of figures.

The client is a wealth advisory firm. It manages portfolios for 100 to 200 high net-worth households, some of them resident abroad. A client is a household, not a person: family members hold the assets, and their holdings roll up into one view. That wealth is spread across eleven asset classes, from stocks and mutual funds to fixed deposits, property, gold and insurance.

How it ran before

Portfolio reporting to clients happened over WhatsApp. Statements and figures moved through messages and ad-hoc spreadsheets.

There was no structured record of a household, its investors and which of them was the primary. Statements were taken in with no reliable parse, validation or audit trail.

What we built

Jetbro built two things for the wealth firm on Phlo. The first is a panel for the operations staff, who set up households and accounts, upload statements, check what the system read, and commit it. The second is a customer app for phone and web, in which a household reads its own portfolio.

Stock prices, currency rates and mutual fund NAVs (net asset value, a fund’s daily unit price) are fetched on a schedule and stored. Every screen reads the stored values.

The system records holdings after the fact, from statements and files. It does not take instructions and it does not give advice.

How a statement becomes a portfolio

1. Household. Staff create the client with a risk profile and add its investors.
2. Accounts. An account is one real identifier in one asset class: a demat account, a folio (the account number a fund house gives an investor), a deposit, a property, a policy. Each has a currency and one or more holders.
3. Upload. Staff open the household, choose the asset class and pick the file: a PDF, a spreadsheet or a CSV, depending on the class.
4. Parse and stage. A parser written for that format reads the file. The result is staged. Nothing in the portfolio changes.
5. Preview. Staff see what the system understood and settle what it could not: a PAN (the tax identity number) that matches no investor, a folio with no account, a fund not seen before.
6. Commit. The commit is one event. The system then applies that asset class’s rule and records a holding update for each account affected. Cancelling is recorded too.
7. Roll-up. Each holding update refreshes the household’s net worth, its split by asset class and by investor, and its equity, debt and cash split.
8. The customer. Staff grant the household an app login. The customer signs in with a one-time code sent by email and reads the figures. The app cannot change them.

What the first build described

A first build is where an operation gets written down: the things it tracks, what can happen to each of them, and the cases that do not fit. For a wealth practice, that starts with who owns what.

The things the business tracks:

• A household. The client: one family, one risk profile, one view of its wealth.
• An investor. A member of the household. One is designated the primary investor, and the household takes that name.
• An account. One real identifier in one asset class, with a currency and its holders.
• A holding. What an account holds and what it is worth, as last stated or last priced.
• An upload. One file, parsed and staged, waiting for a person to commit or discard it.
• A market instrument. A stock, a fund or a currency pair whose price is fetched and stored.
• A net worth snapshot. The household’s total on one night.

What can happen to them, in the system’s own words:

• To a household: client created, risk profile set, investor added, primary investor designated, deactivated, reactivated.
• To an account: account created, investor linked, ownership split set, currency set.
• To an upload: upload parsed, upload discarded, and a commit event named for its asset class, such as MF upload committed. The commit has its own event for each asset class.
• To a holding: a holding updated event named for its asset class, such as MF holding updated, recorded after a commit and, for stocks and mutual funds, after a price refresh.
• To an instrument: registered, flagged, remediated.
• To a customer’s access: credential created, suspended, logged in.

The awkward cases were modelled, not worked around:

• Names on the statement that match nothing. When a statement carries an identity number, a folio or a fund the system has not seen, staff settle it in the preview. The new accounts, the updated investor and the newly registered fund are then recorded as consequences of that one commit.
• A fund seen for the first time. Staff enter its split between equity, debt and cash once. Later statements carry it over.
• One statement, a whole household. A mutual fund statement covers several people and folios at once, and each upload replaces the household’s mutual fund data.
• Many layouts. Statements for portfolio management services (professionally managed accounts) and alternative investment funds arrive in many layouts. Each layout has its own parser. One PDF can hold several accounts, so one upload becomes several commits.
• A fund with no price. A fund with no NAV yet is valued at cost. An instrument that fails to refresh is flagged. Its holding keeps the last known value, marked stale, until an administrator corrects the mapping.
• Joint holders. An account can have several holders, with ownership percentages that sum to 100.
• Several currencies. Currency is set once per account. Household totals are converted to a display currency. If a rate is missing, the total is marked partial and names the currency it could not convert.

Rules per asset class

Each class has its own rule at commit. Some uploads replace the previous snapshot. Some append transactions. Alternative investment funds do both: the snapshot is replaced and the dated cash flows are kept.

Return is not one formula. A managed account uses the IRR on its statement. A fixed deposit uses its stated rate. Property and gold use a simple return over the period. Other classes are measured in their own way. All appear in one Return column.

Insurance is recorded, but it is not counted in net worth.

No statement or file reaches the portfolio without a person’s commit. A parsed file changes no figure until staff have seen the preview and confirmed it, and a discarded upload is kept on the record as discarded.

Access is held the same way. The panel has its own users, roles and permissions. A household sees only its own portfolio, and staff can suspend its login.

What the record makes possible

Each account has a history: who did what, when, and from which source file. A holding leads back to the source file that produced it.

Scheduled work is on the same record. Scheduled work is on the same record. The revaluations that follow a price refresh and the nightly net worth snapshot are events, with the system as their actor. The snapshots are the household’s trend line.

The customer and the staff read the same stored figures. Every number in the app was produced by operations on the panel.

What the foundation carries forward

The description above is the lasting part of a first build. The household, the investor, the account and the holding are defined, with a commit rule for each of the eleven asset classes. Staff roles exist. Commits and nightly snapshots are kept in an append-only record, in order.

A further process for a practice like this would start from that, not from an empty page. A new statement layout is a parser beside the ones that exist, and a new asset class would add a commit rule of its own. The household, its investors and its history would stay as they are.