Data model
Aleta's domain is wealth, and the platform models it in six tiers. Understanding how they relate is the single most useful piece of context for building on the API — every endpoint creates, returns, or links between these objects.
The six primary objects
- Name
Client- Type
- tenant
- Description
The top-level scope. A family office, a wealth manager, or a multi-family platform runs one client per household served. Everything else in the model lives inside a client.
- Name
Legal entity- Type
- owner
- Description
A legal or beneficial owner of wealth — a trust, a holding company, a foundation, or an individual. Legal entities form a tree inside a client; the tree mirrors the real-world ownership structure.
- Name
Depository- Type
- custody relationship
- Description
The platform's handle on a specific custody relationship — "our Nordea private-banking agreement," "our Saxo brokerage." Sits between a legal entity and the accounts it holds at that custodian.
- Name
Account- Type
- container
- Description
A single account number at a custodian, held by one legal entity through one depository. Positions and transactions hang off the account.
- Name
Reporting entity- Type
- projection
- Description
How the client wants to see the portfolio. Reporting entities form a separate tree from legal entities and group accounts into buckets that make sense for analysis — liquid vs illiquid, vintage, operating company vs family wealth, whatever the client's IPS says.
- Name
Portfolio- Type
- sub-bucket
- Description
A named subset inside a reporting entity. An account can belong to multiple portfolios (it might appear in "Total liquid" and in "Equities only" at the same time).
Two trees, not one
The most important idea in the model is that there are two separate trees over the same underlying accounts:
- The legal tree (Client → Legal Entity → Depository → Account) captures ownership for regulatory, tax, and succession purposes. It's messy by nature — holding companies get incorporated for tax reasons that don't care about reporting ergonomics.
- The reporting tree (Client → Reporting Entity → Portfolio → Account) captures analytical views. It's curated for how the family reviews results.
Keeping them separate means neither constrains the other. The legal structure is free to evolve (new vehicle incorporated, old trust wound up) without invalidating historical reports, and the reporting view can be reshaped around a new analytical question without rewriting the ownership graph.
How data flows
From custodian to report
Custodian ── authority ──▶ Depository ── Account ──┐
│
Custodian ── authority ──▶ Depository ── Account ──┼── transactions
│
Custodian ── authority ──▶ Depository ── Account ──┘ │
│
reporting entity (portfolio groupings) ▼
holdings + performance
- Aleta connects to each custodian through a consented authority.
- Daily (or intraday) ingestions pull transactions into each account.
- Accounts roll up into portfolios, portfolios into reporting entities.
- The holdings endpoint reconstructs positions from the ledger; performance computes TWR; both are queried per reporting entity.
Identifiers
Every object carries a stable, prefixed, URL-safe identifier. IDs are opaque strings — don't try to parse structure out of them.
| Object | Looks like |
|---|---|
| Client | client_01J8A2RX… |
| Legal entity | 24-char hex (legacy compat) |
| Depository | 24-char hex (legacy compat) |
| Account | 24-char hex (legacy compat) |
| Reporting entity | 24-char hex (legacy compat) |
| Portfolio | 24-char hex (legacy compat) |
| Instrument | inst_… with an asset-class slug |
| Transaction | 24-char hex (legacy compat) |
The 24-char hex format is a historical convention — treat every ID as opaque and don't rely on format checks in your code.
What's next
- Walk the ownership graph on the entities page.
- Understand how holdings are reconstructed from the ledger.
- Jump to the API reference for endpoint docs.