DEV Community: MarketDeck

Two Correct Revenue Figures, One Wrong Chart: Building Source-Aware Financial Data in Python

Sarthak Verma — Fri, 23 Oct 2026 06:16:20 +0000

Imagine a dashboard reporting that a company's revenue grew 75% in one year. The numbers came from financial statements. The arithmetic checks out. Nothing crashed.

There's just one problem: the dashboard compared standalone revenue from one year with consolidated revenue from the next. The resulting growth rate describes neither business consistently.

At MarketDeck, we're building a connected financial research workspace for Indian markets, including filing-backed company research, screening, interactive charts, and quantitative analysis. One design principle behind our company research is simple: a financial figure is not meaningful without its reporting context.

This article walks through a small, runnable Python example of that principle. It's a standalone teaching example using fictional numbers, not a copy of MarketDeck's production code or a claim about any real listed company.

The invisible data bug

Suppose a fictional company reports the following revenue figures (all in ₹ crore):

Reporting year	Accounting basis	Revenue (₹ crore)
FY2024	Standalone	800
FY2024	Consolidated	1,100
FY2025	Consolidated	1,400

Two tempting calculations produce completely different stories:

❌ Wrong comparison: 1,400 ÷ 800 − 1 = 75% growth
✅ Like-for-like comparison: 1,400 ÷ 1,100 − 1 = 27.27% growth

The first calculation mixes reporting bases; the second compares consolidated annual revenue with consolidated annual revenue. Even the second figure would need further review if the company's consolidation perimeter or accounting policies changed significantly.

This isn't an exotic edge case. Indian listed companies can file results in both standalone and consolidated formats. NSE also supports structured XBRL financial reporting, where units, periods and taxonomy elements matter. A dashboard that discards those fields loses information it needs to compare figures responsibly.

Treat every number as a record, not a float

The usual toy data model is something like:

revenue = 1400

That's fine for a one-line calculation. For a research application, it is under-specified.

We should be able to answer:

Which issuer and metric does this number belong to?
Which fiscal period does it represent: quarter, full year or trailing twelve months?
Is it standalone or consolidated?
Which currency and unit are being used?
When did the result become publicly available?
Which filing or record supports it?

Here's one deliberately minimal Python model that keeps those answers attached. It uses only the standard library and runs on Python 3.10+.

"""Standalone, synthetic demonstration for the MarketDeck DEV article.

Not production MarketDeck source code.
Python 3.10+; no external dependencies.
"""

from dataclasses import dataclass
from datetime import date, datetime
from decimal import Decimal


@dataclass(frozen=True)
class Fact:
    issuer: str
    metric: str
    period_end: date
    period_type: str
    basis: str
    units: str
    amount: Decimal
    published_at: datetime
    source_id: str


def find_fact(
    facts, *, issuer, metric,
    period_end, basis, as_of
):
    if as_of.tzinfo is None or as_of.utcoffset() is None:
        raise ValueError("as_of must have a timezone")

    eligible = [
        f for f in facts
        if f.issuer == issuer
        and f.metric == metric
        and f.period_end == period_end
        and f.period_type == "FY"
        and f.basis == basis
        and f.units == "INR crore"
        and f.published_at <= as_of
    ]

    if not eligible:
        raise LookupError(
            "No comparable fact known by this date"
        )

    # Real datasets need explicit revision handling.
    return max(eligible, key=lambda f: f.published_at)


facts = [
    Fact(
        "FictionalCo", "revenue",
        date(2024, 3, 31),
        "FY", "standalone",
        "INR crore", Decimal("800"),
        datetime.fromisoformat(
            "2024-05-10T18:00:00+05:30"
        ),
        "DEMO-2024-ST"
    ),
    Fact(
        "FictionalCo", "revenue",
        date(2024, 3, 31),
        "FY", "consolidated",
        "INR crore", Decimal("1100"),
        datetime.fromisoformat(
            "2024-05-15T18:00:00+05:30"
        ),
        "DEMO-2024-CON"
    ),
    Fact(
        "FictionalCo", "revenue",
        date(2025, 3, 31),
        "FY", "consolidated",
        "INR crore", Decimal("1400"),
        datetime.fromisoformat(
            "2025-05-20T18:00:00+05:30"
        ),
        "DEMO-2025-CON"
    )
]

as_of = datetime.fromisoformat(
    "2025-06-01T12:00:00+05:30"
)

prior = find_fact(
    facts,
    issuer="FictionalCo",
    metric="revenue",
    period_end=date(2024, 3, 31),
    basis="consolidated",
    as_of=as_of
)

current = find_fact(
    facts,
    issuer="FictionalCo",
    metric="revenue",
    period_end=date(2025, 3, 31),
    basis="consolidated",
    as_of=as_of
)

growth = (
    current.amount / prior.amount - Decimal("1")
) * Decimal("100")

print(f"Comparable revenue growth: {growth:.2f}%")
print(
    f"Sources: {prior.source_id} -> {current.source_id}"
)

# Check that unpublished information is excluded.
try:
    find_fact(
        facts,
        issuer="FictionalCo",
        metric="revenue",
        period_end=date(2025, 3, 31),
        basis="consolidated",
        as_of=datetime.fromisoformat(
            "2025-04-01T12:00:00+05:30"
        )
    )
except LookupError:
    print(
        "Early query: correctly rejected "
        "an unpublished figure"
    )
else:
    raise AssertionError("Look-ahead check failed")

naive_growth = (
    Decimal("1400") / Decimal("800") - 1
) * 100

assert naive_growth == Decimal("75")
assert growth.quantize(Decimal(".01")) == Decimal("27.27")

Expected output:

Comparable revenue growth: 27.27%
Sources: DEMO-2024-CON -> DEMO-2025-CON
Early query: correctly rejected an unpublished figure

All DEMO-* identifiers and numbers above are invented for this tutorial. They are not exchange filing identifiers or actual stock-market data.

What the code protects against

1. Mixed accounting bases

The selector requires the same basis for both years.

A standalone figure cannot quietly enter a consolidated comparison.

2. Mixed reporting periods

The code asks explicitly for an FY observation and matches a specified fiscal year-end.

In a production system, quarters, year-to-date amounts and trailing-twelve-month values need equally explicit period types and duration checks.

The same date alone is not sufficient to establish that two figures have the same reporting duration.

3. Mixed units

The example requires a declared unit.

A production implementation should also normalise values carefully because ₹ lakh, ₹ crore, INR and USD are not interchangeable.

The unit filter here is deliberately strict rather than performing conversions silently.

4. Look-ahead leakage

The condition:

f.published_at <= as_of

keeps figures unavailable at the simulated query time out of the result.

Fiscal year-end is not the same thing as publication date.

For event-driven simulations, the exact publication time and the next executable market session can both matter.

5. Untraceable output

The calculation returns source identifiers beside the result.

In a real application, those identifiers should resolve to specific original filings and, where possible, the relevant financial statements and accounting elements.

There's an important limitation here:

A source link is necessary, but not enough.

A restatement, changed consolidation perimeter, incorrect taxonomy mapping or missing filing could still make a number economically non-comparable.

If your system ingests amendments, it needs explicit revision and supersession handling.

Simply choosing the latest available record works only if your dataset models and validates that policy.

How that changes the UI

A trustworthy financial dashboard shouldn't make readers reverse-engineer a headline metric.

Alongside a growth percentage, I'd want to display something like this:

Field	Research UI should explain
Value	27.27% (illustrative)
Comparison	FY2025 vs FY2024
Basis	Consolidated → Consolidated
Inputs	₹1,400 crore and ₹1,100 crore
Availability	Dates both records were first public
Evidence	Original filings and financial-statement elements
Exceptions	Missing data, revisions or comparability warnings

This isn't about making interfaces unnecessarily complicated.

It's about giving users a clean headline and a way to inspect the evidence when the detail matters.

At MarketDeck, our existing Research Terminal connects financial history with reporting context, valuation, peer research and source tracing.

Our company research also includes Source Trace ratio cards designed to show formulas, periods and missing-input explanations.

The example in this post is intentionally simplified. It illustrates the design reasoning rather than documenting our internal implementation line-for-line.

Three test cases I'd add before shipping

The script already tests one incorrect accounting comparison and one too-early query.

A production financial data pipeline needs more checks.

1. Restatement test

A later amended filing must not overwrite the earlier as-of history retroactively.

2. Context test

Annual, quarterly, year-to-date and trailing values must not become substitutes simply because their end dates align.

3. Provenance test

Missing source records, mismatched currencies or incompatible reporting bases must produce a visible missing or uncertain result—not a fabricated zero or silent fallback.

Also worth testing:

Fiscal-year changes
Mergers and acquisitions
Revised taxonomy mappings
Stale observation windows
Timezone handling around market close

The aim is not to promise that every financial number can be made perfectly comparable.

It is to make the conditions under which it is comparable inspectable.

The bigger lesson for developers

It's easy to spend most of our time polishing the front end of a financial dashboard: chart animations, filters and fast search.

Those things matter.

But a chart can be beautifully rendered and still answer the wrong question.

Once a system tracks what was reported, for which period, on which basis, when it became known and where it came from, the product becomes more useful for far more than charts.

The same structured evidence can support:

Human financial research
Company screening
Reproducible quantitative experiments
Historical comparisons
AI-assisted interfaces grounded in verifiable financial information

That's the direction we're building toward at MarketDeck: accessible quantitative research, with the context needed to question the output.

Our broader AI-connected experimentation and data-access vision remains future work, not something this tutorial claims is already live.

Explore MarketDeck — Financial Research Beyond the Numbers

If you're interested in financial markets, quantitative analysis or building data-driven applications, take a look at MarketDeck.

We're building an India-first quantitative financial research platform that brings together company fundamentals, stock screening, advanced charting, derivatives research, portfolio analytics and interactive mathematical tools.

Instead of switching between disconnected websites, spreadsheets and analytical tools, our goal is to make financial research more connected, transparent and accessible.

What you can explore today

🔍 MarketDeck Screener

Explore Indian listed companies, financial metrics, research filters and company fundamentals.

📊 Research Terminal

Investigate financial history, reporting periods, valuation context, peer comparisons and source-linked research.

📈 MarketDeck

Explore charting, derivatives research, portfolio analytics and interactive learning experiences from one connected platform.

📚 Research Standards

Learn more about our approach to methodology, source transparency, research limitations and financial data quality.

Where we're going next

Our long-term vision is to build an integrated quantitative research workspace with AI-assisted research, programmable computation and permissioned financial data services.

These broader capabilities are part of our development direction and are not all available as a finished end-to-end workflow today.

MarketDeck is currently free to use.

👉 Explore MarketDeck — https://marketdeck.in/

One question for fellow developers

If you build data-heavy products, what's the most subtle "valid data, wrong interpretation" bug you've encountered?

I'd love to hear how other developers deal with source tracking, data revisions and inconsistent reporting formats.

References and further reading

NSE: XBRL filing information — Financial-report taxonomy, period and unit context.
NSE: Corporate filings announcements — Filing and dissemination timestamps.
NSE: Integrated Financial Filing circular (April 2025) — Evolving PDF and XBRL filing processes.
MarketDeck Research Terminal — Company research with sources and reporting context.

Educational and software-engineering content only. No investment recommendations. All demonstration amounts are fictional.

10 Stocks, One Hidden Risk: Build a Portfolio Correlation Lab in Python

Sarthak Verma — Sat, 10 Oct 2026 18:13:53 +0000

Ten stocks can still behave like one crowded trade. The number of positions in your portfolio does not tell you how much risk they share.

Picture a portfolio containing a bank, an IT company, an automaker, a consumer brand, and six other businesses. Ten tickers. Several industries. It feels diversified.

Now imagine a broad market selloff in which most of those stocks fall together. You diversified the company names, but did you diversify the forces moving their prices?

That's the problem we'll investigate. We'll start with a simple experiment you can run in MarketDeck's interactive learning lab, rebuild the mathematics in Python, and finish with a more useful way to question portfolio concentration.

What you'll learn: why correlations matter, how to calculate portfolio volatility from a covariance matrix, and what an "effective number of exposures" really means. Everything below uses hypothetical numbers; you won't need a brokerage account or market-data API.

1. Two stocks, one question

Suppose you hold two fictional stocks, A and B. Each has an assumed annual volatility of 20%, and each receives 50% of your portfolio.

Only one thing changes between experiments: correlation.

Correlation describes how two return series tend to move relative to each other, on a scale from -1 to +1. A value near +1 indicates strong positive co-movement; a value near 0 means little linear relationship. It does not mean the assets are risk-free or genuinely independent in every statistical sense.

Before reading the results, make a prediction: if A and B move perfectly together, does holding both reduce your risk?

Assumed correlation	Portfolio volatility
-0.50	10.00%
0.00	14.14%
+0.25	15.81%
+0.80	18.97%
+1.00	20.00%

At +1, the portfolio is just as volatile as either constituent. Splitting your money across two names hasn't lowered this particular measure of risk.

At 0, volatility falls to about 14.14%, not 10%. Diversification helps, but risk doesn't shrink in a simple one-for-one proportion to the number of holdings.

Try the experiment on MarketDeck

Open the Expected Returns interactive guide and find the exercise about adding holdings versus changing risks.

Set both assumed volatilities to 20% and the weights to 50% / 50%.
Set correlation to +1. Predict the answer before running the experiment.
Repeat with 0 and -0.5. Check your results against the table.
Try changing only the weights to 70% / 30%. What happens, and why?

This exercise is an assumption-driven calculator, not a backtest or a stock recommendation. That is its strength: you can isolate one idea instead of confusing it with changing market prices.

2. The mathematical reason

For two assets, portfolio variance is:

portfolio_variance = wA² × σA² + wB² × σB² + 2 × wA × wB × σA × σB × correlation

Here, w is the asset weight and σ is the standard deviation of returns. Take the square root of the resulting variance to get portfolio volatility.

Notice the final term. It connects the two assets. Ignoring that term amounts to ignoring how the stocks move together.

For a larger portfolio, linear algebra gives us a cleaner expression:

portfolio_variance = weights.T @ covariance_matrix @ weights

The covariance matrix contains individual asset variances along its diagonal and pairwise covariances elsewhere. The matrix is not just a technical convenience: its off-diagonal entries are part of the portfolio's risk.

3. The ten-stock illusion

Now imagine ten hypothetical stocks, each weighted at 10%, each with assumed annual volatility of 20%.

To make the mechanism easy to see, let's assume every distinct pair has exactly the same correlation, which we'll call rho. Real portfolios don't work this neatly. We're creating a controlled experiment, not modelling ten actual NSE-listed companies.

With n equal-weighted, equally volatile assets, the formula simplifies to:

portfolio_volatility = asset_volatility × sqrt((1 + (n - 1) × rho) / n)

Watch what happens as common correlation rises:

Correlation between every pair	Portfolio volatility
0.00	6.32%
0.25	11.40%
0.50	14.83%
0.75	17.61%
1.00	20.00%

The portfolio always contains ten stocks. Its weights and each stock's assumed volatility are unchanged. Only the relationships between them are different.

That one change takes the estimated portfolio volatility from 6.32% to 17.61% when correlation goes from 0 to 0.75.

Key insight: Diversification is not only about owning different businesses. It's also about whether the risks driving those businesses are sufficiently different.

An important constraint on negative correlations: When every pair of assets shares the same correlation, the correlation matrix is only valid when −1/(n − 1) ≤ ρ ≤ 1.

For ten assets, the minimum common correlation is approximately −0.111. So although −0.50 is a valid correlation between two assets, it cannot be the common correlation across all ten assets.

The Python example checks the matrix's eigenvalues to reject invalid assumptions.

4. Build the correlation lab in Python

Let's reproduce these numbers with NumPy. This is standalone code: it does not use a MarketDeck API or download real stock prices.

Install NumPy if needed with pip install numpy, save the following as portfolio_correlation.py, and run it with Python 3.

import numpy as np

N = 10
ASSET_VOL = 0.20  # assumed annualised volatility
weights = np.full(N, 1.0 / N)


def portfolio_lab(rho: float):
    # Correlation matrix: 1 on the diagonal, rho elsewhere
    corr = (1 - rho) * np.eye(N) + rho * np.ones((N, N))

    # Reject invalid correlation matrices
    assert np.linalg.eigvalsh(corr).min() > -1e-10

    covariance = (ASSET_VOL ** 2) * corr
    variance = float(weights @ covariance @ weights)
    volatility = np.sqrt(variance)

    # Variance-equivalent count; equal individual volatilities
    effective_count = (
        ASSET_VOL ** 2 / variance
        if variance > 0
        else float("inf")
    )

    return volatility, effective_count


print("rho     volatility     effective_count")
for rho in (0.00, 0.25, 0.50, 0.75, 1.00):
    vol, count = portfolio_lab(rho)
    print(f"{rho:4.2f}       {vol:6.2%}          {count:5.2f}")

# Two quick sanity checks
assert np.isclose(portfolio_lab(0)[0], ASSET_VOL / np.sqrt(N))
assert np.isclose(portfolio_lab(1)[0], ASSET_VOL)
print("Sanity checks passed.")

The expected output is:

rho     volatility     effective_count
0.00        6.32%          10.00
0.25       11.40%           3.08
0.50       14.83%           1.82
0.75       17.61%           1.29
1.00       20.00%           1.00
Sanity checks passed.

Try modifying N, the common correlation, or the weights. The volatility calculation works with unequal weights, and the revised effective-count calculation also accommodates unequal weights as long as the individual asset volatilities remain equal. It remains a variance-equivalent comparison, not a literal count of independent economic risks.

5. What does “1.29 effective stocks” actually mean?

At a common correlation of 0.75, the code prints 1.29. It sounds dramatic. It also needs a careful definition.

Under our specific assumptions, we can ask: How many equally weighted, equally volatile, mutually uncorrelated assets would produce the same portfolio variance?

That variance-equivalent number is:

effective_count = n / (1 + (n - 1) × rho)

For ten assets with rho = 0.75, it is about 1.29.

It does not mean the portfolio contains literally 1.29 companies, that we have identified its true economic factors, or that its future losses can be predicted with precision. It is a comparison within an unusually simple model.

Other measures, including eigenvalue-based estimates of the dimensionality of a correlation matrix, answer different questions and can produce different results. Don't combine them under the label "independent bets" without explaining which definition you used.

6. Where real portfolio research gets harder

In a classroom example, we pick correlations. In a real portfolio, we must estimate them from returns—and those estimates may be unstable.

A few practical questions become essential:

Which period? Correlations based on the past three months may disagree with those based on three years.
Which returns? Closing prices, total returns, currency conversions, and corporate actions must be handled consistently.
Which observations? Holidays, missing prices, and securities with short histories can distort the matrix.
Which risks are missing? Liquidity shocks, options payoffs, concentrated factors, and extreme market events may not be described well by ordinary correlation.
What changed? A historically diversified portfolio can become more correlated precisely when diversification matters most.

MarketDeck's Portfolio Analysis is designed for this broader research process. Its public overview describes connected lenses covering performance, core risk, tail risk, return distributions, factor exposures, diversification, risk–return analysis, and implied returns. Analysing your own holdings requires signing in.

The two-asset learning lab is the place to understand the mechanics first. The portfolio workspace is where more of the real research questions can be considered together.

Our goal isn't to turn covariance into a “buy” or “sell” score. It's to make the assumptions behind a result easier to inspect.

Try a rolling-correlation sensitivity check.

Instead of estimating correlations once, repeat the calculation using rolling windows of 60 daily returns.

With ten assets, each window contains 45 distinct pairwise correlation estimates. Short-window estimates can be noisy, so one effective-count figure may give a misleading impression of precision.

Under the equal-weight, equal-volatility assumptions, an average pairwise correlation of 0.65 corresponds to approximately 1.46 variance-equivalent positions. At 0.85, the count drops to approximately 1.16.

These are illustrative sensitivity calculations, not observed market results. They show why diversification estimates should be examined across different windows and assumptions rather than treated as permanent characteristics of a portfolio.

7. Three challenges before you close the notebook

Challenge 1 — Unequal risk: Return to MarketDeck's two-asset experiment. Keep 50/50 weights and zero correlation, but give the second asset 30% volatility instead of 20%. Predict the new combined volatility. (Check: approximately 18.03%.)

Challenge 2 — Concentrated weights: In Python, change the ten weights so the first stock receives 50% and the remaining nine share the other 50%. Keep the common correlation at 0.75. Compare the result with the original 17.61%. (Check: approximately 18.10%.)

Challenge 3 — Explain it simply: A friend tells you, “I own ten stocks, so I'm diversified.” Ask two follow-up questions that would help establish whether that's actually true.

You don't need to memorise every equation. If you remember one habit, make it this:

Don't stop at “How many stocks do I own?” Ask “What makes these stocks move together, and how reliable is my estimate?”

Explore and verify

About MarketDeck: We're building an India-focused financial research workspace spanning screening, charts, portfolio analysis, and quantitative learning. I am part of the team behind MarketDeck. All numerical cases in this article are hypothetical educational examples, not historical backtests or personalised investment advice.