What is aggregation?
Aggregation has two common meanings in finance.
– In derivatives trading, aggregation means adding together all futures positions that one trader (or a related group) controls to report a single net position. This helps exchanges and regulators monitor concentration and compliance.
– In personal financial planning, account aggregation means combining data from multiple bank, brokerage, retirement, and credit accounts into one consolidated view. Aggregation tools collect balances, positions, transactions, and sometimes liabilities so an advisor or investor can see a client’s overall financial picture without logging into each account separately.
Definitions (first use)
– Custodian: a financial firm that holds securities and cash on behalf of an investor or advisor.
– API (application programming interface): a technical method that lets systems exchange data directly and securely.
– Screen‑scraping: a technique where a service logs into a consumer website using the user’s credentials to extract data; generally less secure than direct API links.
– Managed account: an account the advisor actively manages through a custodian under an agreement.
– Non‑managed account: an account the client owns and controls but that still matters for planning (401(k), bank account, pension, credit card).
– Net worth: total assets minus total liabilities.
– Asset allocation: the percentage of total assets in each asset class (cash, equities, bonds, etc.).
How account aggregation works (high level)
1. The client or advisor chooses an aggregation service or software.
2. The client authorizes access to external accounts. Authorization can be explicit (consent screen, OAuth token) or by giving credentials used for screen‑scraping.
3. The aggregator collects account balances, positions, and transaction history either through direct API connections (preferred) or by accessing web pages.
4. The aggregator standardizes and updates the data, then presents dashboards, reports, or feeds into portfolio-management software.
5. Advisors reconcile and interpret the aggregated data for planning, reporting, and risk assessment.
Why aggregation matters
– Comple
plete picture of a client’s financial life. Aggregation lets an advisor or individual see holdings, cash flows, liabilities, and performance across custodians and account types without logging into each account separately. That single view supports planning, tax management, risk measurement, and more efficient reporting.
Why aggregation matters (continued)
– Holistic planning: Shows how retirement accounts, taxable brokerage, and credit obligations interact.
– Efficiency: Reduces time spent collecting statements and reconciling positions.
– Improved advice: Enables asset‑level attribution, rebalancing suggestions, and cash‑flow forecasting.
– Client engagement: Dashboard views and alerts help clients track progress and stay informed.
Common benefits (practical)
– Faster net‑worth updates: One refresh pulls balances across accounts.
– Simpler asset allocation checks: Compute percentages for each asset class automatically.
– Consolidated performance reporting: Compare total portfolio return vs. benchmarks.
– Better cash management: Detect idle cash across accounts for potential use.
Key limitations and risks
– Data accuracy: Not all aggregators can access all fields (e.g., tax lots, cost basis, or retirement plan employer contributions). Screen‑scraped data can break if a provider changes its website.
– Latency: Some connections update more frequently than others. Real‑time data is rare except via direct API integrations.
– Security and privacy: Sharing credentials (vs. tokenized access) increases exposure. Also consider how long a third party retains historical data.
– Legal and liability issues: Aggregators are typically not fiduciaries; errors in aggregation are not the same as errors in trading or custody.
– Incomplete asset coverage: Alternative assets (private equity, crypto on self‑custody wallets, physical assets) often require manual entry.
How account data is typically accessed (brief)
1. Direct API (preferred): Tokenized, standardized access (
…tokens are issued to the aggregator by the account provider and can be scoped and revoked. Tokenized access (sometimes implemented using OAuth, an open standard for delegated authorization) lets the aggregator request only the minimum permissions needed, avoids sharing raw login credentials, and usually supports automated token refresh so connections stay active without repeated password entry.
2. Screen scraping / credential-based access: the aggregator stores user credentials (username/password) and programmatically logs into the provider’s website to read the same HTML a human would. This method can give broad access when no API exists, but it has higher security and reliability risks: site layout changes can break parsing, and storing credentials increases breach exposure.
3. File-based imports: many aggregators accept user-uploaded files (CSV, OFX, QFX, MT940) exported from brokerages, banks, or crypto exchanges. This is lower-risk (no credential sharing) but manual and prone to stale data unless users regularly upload new files.
4. Manual entry and tagging: for illiquid or private assets (private equity, collectibles, cash in a safe), users enter values and metadata themselves. Aggregators may allow attaching documents or custom cost bases to these entries.
Data normalization (brief)
Once raw data arrives, aggregators normalize it—mapping different field names and formats into a consistent internal model. Key normalization tasks:
– Security identification: map tickers, CUSIPs, ISINs, or contract addresses (for crypto) to a canonical identifier.
– Currency conversion: convert foreign-currency holdings to the account’s reporting currency using a sourced exchange rate and timestamp.
– Cost-basis and tax lots: reconcile reported lot-level cost bases, detect missing lots, and apply consistent accounting method (FIFO, LIFO, or specific identification) if needed.
– Transaction canonicalization: turn provider-specific transaction types into a standard set (buy, sell, dividend, fee, transfer, interest).
– De-duplication and reconciliation: merge duplicate records where the same account appears via multiple feeds.
Security, privacy, and compliance considerations (practical checklist)
For end users:
– Prefer tokenized API access (OAuth) over credential sharing.
– Enable multi-factor authentication (MFA) on all linked accounts.
– Review the aggregator’s data-retention policy: how long they keep historical credentials and transactions?
– Check whether connections are read-only and whether trading powers are granted.
– Periodically reconcile the aggregator’s balances vs. official statements (monthly or after material activity).
For aggregators or integrators:
– Obtain SOC 2 or equivalent third-party audit and publish it.
– Implement least-privilege scopes for tokens and refresh tokens securely.
– Log access and provide customers a way to revoke tokens or disconnect providers.
– Maintain a documented change-management process when provider site changes require parser updates.
– Disclose limits of liability and make clear you are not a custodian or fiduciary (unless you are).
Step-by-step user verification workflow (how to check an aggregator’s accuracy)
1. Pick a recent statement date (e.g., last statement).
2. For each linked account, compare the aggregator’s reported balance with the statement closing balance.
3. For a sample security in each account, verify quantity, price, and cost basis against the statement.
4. Reconcile transaction history for the past 30–90 days: look for missing dividends, corporate actions, or transfers.
5. Confirm currency conversions by checking the exchange rate and timestamp used for foreign holdings.
6. For tax lots, verify that the lot acquisition dates and bases match your broker’s lots; note any discrepancies.
7. If differences remain, take screenshots and contact both the aggregator and the account provider with specific examples.
Worked numeric example — aggregation, allocation, and percent change
Assume three accounts at time T0:
– Taxable brokerage: $50,000
– Traditional IRA: $30,000
– Self‑custody crypto wallet: $5,000
Total portfolio value T0 = 50,000 + 30,000 + 5,000 = $85,000
Weights (allocation) at T0:
– Brokerage weight = 50,000 / 85,000 = 58.82%
– IRA weight = 30,000 / 85,000 = 35.29%
– Crypto weight = 5,000 / 85,000 = 5.88%
One week later (T1) balances change:
– Brokerage = $51,500
– IRA = $29,200
– Crypto = $4,700
Total portfolio value T1 = 51,500 + 29,200 + 4,700 = $85,400
Aggregate percent change (portfolio-level):
Percent change = (T1 – T0) / T0 * 100 = (85,400 – 85,000) / 85,000 * 100 = 0.47%
Individual percent changes:
– Brokerage: (51,500 – 50,000)/50,000 = 3.0%
– IRA: (29,200 – 30,000)/30,000 = -2.67%
– Crypto: (4,700 – 5,000)/5,000 = -6.0%
Recomputed weights at T1:
– Brokerage = 51,500 / 85,400 = 60.30%
– IRA = 29,200 / 85
= 85,400 = 34.19% – Crypto = 4,700 / 85,400 = 5.51%
Now show why the portfolio-level percent change equals the weighted average of individual percent changes when you use beginning-of-period weights.
Step 1 — individual returns (already computed)
– Brokerage return r_b = (51,500 − 50,000) / 50,000 = 0.0300 = 3.00%
– IRA return r_i = (29,200 − 30,000) / 30,000 = −0.026667 = −2.6667% (rounded −2.67%)
– Crypto return r_c = (4,700 − 5,000) / 5,000 = −0.0600 = −6.00%
Step 2 — beginning-of-period weights (T0)
– w_b0 = 50,000 / 85,000 = 0.588235 = 58.82%
– w_i0 = 30,000 / 85,000 = 0.352941 = 35.29%
– w_c0 = 5,000 / 85,000 = 0.058824 = 5.88%
Step 3 — weighted average of individual returns
Compute sum(w_i0 * r_i):
– Brokerage: 0.588235 * 0.03 = 0.0176471 = 1.76471%
– IRA: 0.352941 * (−0.0266667) = −0.0094259 = −0.94259%
– Crypto: 0.058824 * (−0.06) = −0.0035294 = −0.35294%
Sum = 0.0176471 − 0.0094259 − 0.0035294 = 0.0046918 = 0.46918% ≈ 0.47%
This matches the aggregate percent change computed directly:
(T1 − T0) / T0 = (85,400 − 85,000) / 85,000 = 0.0047059 = 0.47059% (small differences due to rounding).
Why beginning weights? Portfolio return R_p over a fixed period (no external flows) equals the value-weighted average of component returns measured over the same period using the start-of-period weights:
R_p = sum_i (w_i0 * r_i)
where w_i0 = V_i0 / V_0 and r_i = (V_i1 − V_i0) / V_i0.
Quick numeric identity check (value form)
R_p = (sum_i V_i1 − sum_i V_i0) / sum_i V_i0
= sum_i [(V_i1 − V_i0) / V_0]
= sum_i [ (V_i0 / V_0) * ((V_i1 − V_i0) / V_i0) ]
= sum_i [ w_i0 * r_i ].
Common pitfall — using ending weights
If you instead use ending-of-period weights w_i1 to compute sum(w_i1 * r_i), you get a different number (here ≈ 0.57%), because the weights themselves changed as a result of returns. That weighted sum is not the correct portfolio return for the period; it mixes end-period composition with period returns and double-counts the effect of larger gains increasing weight.
Practical checklist for correct aggregation
1. Use prices/values from the same two points in time (start and end).
2. Use start-of-period (beginning) weights when aggregating returns for that period.
3. If there were external cash flows (contributions/withdrawals) during the period, simple aggregation is invalid — use a time-weighted return (TWR) or money-weighted return (MWR) method instead.
4. When reporting subperiod returns and then aggregating, ensure subperiod weights are defined consistently (e.g., daily TWR requires geometrically linking subperiod returns).
5. Keep rounding minimal until the final result to avoid small discrepancies.
Worked numeric reminder (summary)
– Start value: 85,000; End value: 85,400 → portfolio return = 0.4706%.
– Weighted start-of-period returns: 58.82%*3.00% + 35.29%*(−2.67%) + 5.88%*(−6.00%) = 0.4692
Why the small mismatch (0.4706% vs 0.4692%)
– The portfolio return computed from start and end values is exact: (85,400 − 85,000) / 85,000 = 400 / 85,000 = 0.00470588235 = 0.4705882353%.
– The weighted-sum approach is exact only when you use exact (unrounded) start-of-period weights and exact sub-asset returns. Using rounded weights or rounded sub-asset returns produces a slight difference.
Worked exact weighted calculation (no rounding)
1. Exact start-of-period weights:
– Asset A: 50,000 / 85,000 = 50/85 = 10/17 = 0.5882352941176471
– Asset B: 30,000 / 85,000 = 30/85 = 6/17 = 0.35294117647058826
– Asset C: 5,000 / 85,000 = 5/85 = 1/17 = 0.058823529411764705
2. Exact simple returns (decimal form):
– rA = 3.00% = 0.03
– rB = −2.666666…% = −0.02666666666666667
– rC = −6.00% = −0.06
3. Weighted sum:
– Portfolio return = wA·rA + wB·rB + wC·rC
– = (10/17)·0.03 + (6/17)·(−0.0266666667) + (1/17)·(−0.06)
– = 0.004705882352941176 = 0.4705882352941176% (matches the start/end result)
Key practical rules (continuing and expanding the earlier checklist)
– Always carry full-precision numbers through calculations; round only the final reported figure.
– Use start-of-period market-value weights when aggregating simple returns across assets for a single period.
– If weights change during the period because of trades or external cash flows, do not use a single start-of-period weighted sum — use an appropriate method (see below).
– When aggregating returns over time, link subperiod returns geometrically: for subperiod returns r1, r2, …, rn, combined return = (1+r1)(1+r2)…(1+rn) − 1.
– For aggregating across assets with different subperiod returns and changing weights, compute each asset’s time-weighted (geometrically linked) return and then use the weight at the overall period start (or use TWR aggregation across time intervals).
Brief definitions and when to use each (non-exhaustive)
– Time-weighted return (TWR): A method that isolates investment performance from the timing and size of external cash flows (contributions/withdrawals). Compute returns for subperiods between cash flows, chain them geometrically to get the portfolio TWR. Use when you want to
want to isolate manager skill (performance per dollar