Pratik Bang
IN DEVELOPMENTTrading Infrastructure · Portfolio Construction

Multi-Broker Trading Analytics and Risk Dashboard

Reconstructing and monitoring portfolio-level performance and risk across multiple brokerage accounts.

Started 2025-11Sample Ongoing, from account inceptionPython · pandas · SQL · Broker APIs · Dashboard development
02

Research question

Can positions, trades, cash flows, and account values from several brokerage accounts be consolidated into one auditable daily NAV series and a consistent set of portfolio performance and risk metrics?

03

Why this matters

Performance measured from account balances is contaminated by deposits and withdrawals, and exposure measured per broker hides the true portfolio. Consolidation is a prerequisite for any honest statement about risk, correlation between strategies, or capital allocation.

04

Hypotheses

  1. 01Design assumption: a daily NAV series reconstructed from trades and cash flows can be reconciled to broker-reported account values within a small tolerance.
  2. 02Design assumption: strategy-level attribution requires trade tagging at entry, not reconstruction after the fact.
05

Methodology

Planned functionality

  • Broker API integration
  • Historical report import
  • Daily NAV reconstruction
  • Deposit and withdrawal separation
  • Real-time positions
  • Holdings and exposure
  • Realized and unrealized P&L
  • Sharpe ratio
  • CAGR
  • Maximum drawdown
  • Drawdown recovery time
  • Turnover
  • Asset and strategy correlations
  • Capital allocation
  • Broker reconciliation
  • Data-quality checks
  • Audit logs

Accounting approach

Every metric is derived from an immutable ledger of trades and cash flows rather than from reported balances, so any number on the dashboard can be traced to source records.

Privacy and security

Public repository code runs on mock or synthetic data only. No API keys, account numbers, trading records, or private financial data are committed or displayed. Credentials are supplied through environment variables and never reach client-side code.

Daily NAV reconstructionTime-weighted return constructionCash-flow separationBroker reconciliation and break reportingData-quality checks and audit logging
06

Data

Sources

Broker APIs and historical statement exports for the connected accounts.

Validation

  • Trade-to-position consistency checks
  • Cash-flow ledger balancing
  • Reconciliation of reconstructed NAV against broker-reported values
  • Duplicate-import detection

Redistribution

Personal trading records are never published. Demonstrations use synthetic data generated to the same schema.

07

Key results

No results published yet

This is a software project rather than an empirical study, so no research results are reported. Screenshots will use synthetic data. [SCREENSHOTS TO SUPPLY]

Accounts supported

—

Awaiting confirmation

Reconciliation tolerance

—

Awaiting confirmation

Metrics implemented

—

In development

Planned exhibits

  • Consolidated NAV and drawdown view (synthetic data)
  • Exposure by asset class and strategy
  • Reconciliation break report
  • Data-quality dashboard

Every published chart will carry a descriptive title, axis labels, units, legend where needed, its sample period, a gross or net label, a short written interpretation, and accessible colors with tooltips.

08

Interpretation

Scope

The system measures and monitors; it does not generate signals or make allocation decisions automatically.

09

Robustness checks

  • Reconciliation against broker statements across periods
  • Idempotent import replay tests
  • Corporate-action handling tests
  • Timezone and settlement-date edge cases
10

Limitations

  • Broker API coverage and field semantics differ across providers.
  • Historical statement formats change over time and require per-format parsers.
  • Derived metrics inherit any error in source records.
  • Private data means external verification is not possible.
11

Conclusion

In development. The measure of success is whether every published portfolio number reconciles to broker records within a stated tolerance.

12

Reproducibility

Repository structure

[REPOSITORY LAYOUT TO CONFIRM] Connectors, ledger, metrics, reconciliation, and dashboard layers.

Environment

A dependency file plus an .env.example listing variable names only, with no secrets.

Data requirements

Synthetic fixtures ship with the repository so the pipeline runs end to end without private data.

13

Downloads and links

Read Full ReportpendingView CodependingOpen NotebookpendingDownload FigurespendingMethodology AppendixpendingData DictionarypendingOpen Demopending

Related research

14

Citation

This is working research, not a peer-reviewed publication. If you refer to it, please cite it as work in progress and note the status shown above.

BibTeX

@misc{bang_multi_broker_analytics,
  author = {Bang, Pratik},
  title  = {Multi-Broker Trading Analytics and Risk Dashboard},
  year   = {2026},
  note   = {Status: In Development. Working research, subject to revision.},
  url    = {[PROJECT URL TO ADD]}
}

Plain text

Bang, P. (2026). Multi-Broker Trading Analytics and Risk Dashboard. Working research (In Development). [PROJECT URL TO ADD]