DEV Community: Sarthak Verma

Three Correlations Passed Validation. The Matrix Was Impossible.

Sarthak Verma — Wed, 04 Nov 2026 05:30:11 +0000

TL;DR: Checking that every correlation is between -1 and 1 is not enough. A complete correlation matrix must also be positive semidefinite. Below is a three-asset counterexample, a dependency-free JavaScript validator, and tests that make the result reproducible.

A risk dashboard can look completely convincing while displaying numbers from a model that should never have accepted its inputs.

Imagine a UI with three correlation sliders:

Asset A and asset B: +0.90
Asset A and asset C: +0.90
Asset B and asset C: -0.90

Every input fits the permitted range. The diagonal of the resulting matrix is 1. The matrix is symmetric. A naïve form validator gives it a green checkmark.

And yet no three random variables can have all three of those pairwise correlations at once.

This isn't a report of a production failure. It's a failure mode we explicitly designed against while building a browser-based portfolio-risk visualization. The surprising part is that the bug can live entirely in the inputs, before any rendering code runs.

The matrix that looks valid

Our three sliders produce:

    A      B      C
A [ 1.00,  0.90,  0.90 ]
B [ 0.90,  1.00, -0.90 ]
C [ 0.90, -0.90,  1.00 ]

The following check is necessary, but insufficient:

const correlations = [0.9, 0.9, -0.9];
const inRange = correlations.every(
  value => Number.isFinite(value) && value >= -1 && value <= 1
);

It returns true. That proves only that individual cells are in range.

A correlation matrix has to describe a jointly possible system. Its entries are constrained by one another.

There is a geometric intuition: if B closely follows A, and C also closely follows A, then B and C cannot simultaneously behave as almost exact opposites. The three statements conflict.

Why the determinant exposes the contradiction

For a symmetric three-asset correlation matrix with off-diagonal entries a, b, and c, its determinant is:

det(R) = 1 + 2abc - a² - b² - c²

In this example, a = 0.9, b = 0.9, and c = -0.9, so:

det(R) = 1 + 2(0.9)(0.9)(-0.9) - 3(0.9²)
       = -2.888

A real correlation matrix must be positive semidefinite (PSD): for every vector x, the quadratic form xᵀRx must be nonnegative. That is what makes it possible to interpret the matrix as correlations coming from a covariance matrix.

This particular matrix has eigenvalues -0.8, 1.9, and 1.9. A negative eigenvalue is enough to show it is not PSD.

Here's another way to see it. Take x = [-1, 1, 1]. Then xᵀRx = -2.4. If R were a covariance matrix of unit-variance variables, that would claim a linear combination has negative variance. That's impossible.

One nuance: a bad correlation matrix does not necessarily produce a negative variance for every long-only portfolio. It is invalid globally, even if one portfolio happens to produce a nonnegative result. That's why validating only the final variance is not enough.

You can also derive the allowable third correlation when the first two are fixed:

ab - sqrt((1 - a²)(1 - b²))
   ≤ c ≤
ab + sqrt((1 - a²)(1 - b²))

For a = b = 0.9, the range is 0.62 ≤ c ≤ 1.00. A value of -0.9 is nowhere near feasible.

Changing c to +0.8 creates a valid matrix with determinant +0.036. But an application should not silently change a user's assumption. Fixing or projecting a matrix is a modeling choice that deserves an explanation.

A tiny JavaScript engine you can run

The example below deliberately has three assets so the PSD test fits in one formula. It is a self-contained teaching implementation, not a copy of our production module and not a generic validator for matrices of any size.

It also demonstrates a second engineering invariant: the sum of Euler volatility contributions must equal portfolio volatility whenever that quantity is defined.

Create risk-matrix.mjs:

// Standalone educational example for the DEV article.
// Three assets, decimal inputs, no dependencies, no price feed.
import { fileURLToPath } from 'node:url';
import { resolve } from 'node:path';

const EPS = 1e-10;

export function validateCorrelation3(R) {
  if (!Array.isArray(R) || R.length !== 3 ||
      R.some(row => !Array.isArray(row) || row.length !== 3)) {
    throw new RangeError('Expected a 3 x 3 matrix');
  }

  for (let i = 0; i < 3; i++) {
    for (let j = 0; j < 3; j++) {
      const r = R[i][j];
      if (!Number.isFinite(r) || r < -1 || r > 1) {
        throw new RangeError('Correlations must be finite and in [-1, 1]');
      }
      if (i === j && Math.abs(r - 1) > EPS) {
        throw new RangeError('Diagonal entries must be 1');
      }
      if (Math.abs(r - R[j][i]) > EPS) {
        throw new RangeError('Matrix must be symmetric');
      }
    }
  }

  const a = R[0][1], b = R[0][2], c = R[1][2];
  // For a symmetric 3x3 unit-diagonal matrix, with |a|,|b|,|c| <= 1,
  // all principal minors are nonnegative iff this determinant is >= 0.
  const determinant = 1 + 2 * a * b * c - a*a - b*b - c*c;
  if (determinant < -EPS) {
    throw new RangeError(`Not positive semidefinite; det=${determinant.toFixed(3)}`);
  }
  return determinant;
}

export function portfolioRisk3({ weights, vols, correlations }) {
  validateCorrelation3(correlations);
  if (!Array.isArray(weights) || weights.length !== 3 ||
      weights.some(w => !Number.isFinite(w) || w < 0 || w > 1) ||
      Math.abs(weights.reduce((a, b) => a + b, 0) - 1) > EPS) {
    throw new RangeError('Long-only weights must sum to 1');
  }
  if (!Array.isArray(vols) || vols.length !== 3 ||
      vols.some(v => !Number.isFinite(v) || v < 0)) {
    throw new RangeError('Volatilities must be nonnegative decimals');
  }

  const cov = correlations.map((row, i) =>
    row.map((rho, j) => vols[i] * rho * vols[j]));
  const sigmaW = cov.map(row =>
    row.reduce((sum, element, j) => sum + element * weights[j], 0));
  const variance = weights.reduce((sum, w, i) => sum + w * sigmaW[i], 0);
  if (variance < -EPS) throw new RangeError('Negative portfolio variance');

  const volatility = Math.sqrt(Math.max(0, variance));
  // The Euler attribution is undefined at zero volatility; don't fake shares.
  const contributions = volatility > 0
    ? weights.map((w, i) => w * sigmaW[i] / volatility)
    : null;
  return { volatility, contributions };
}

export const IMPOSSIBLE = [
  [ 1,   0.9,  0.9 ],
  [ 0.9, 1,   -0.9 ],
  [ 0.9,-0.9,  1   ],
];

export const POSSIBLE = [
  [ 1,   0.9, 0.9 ],
  [ 0.9, 1,   0.8 ],
  [ 0.9, 0.8, 1   ],
];

if (process.argv[1] && fileURLToPath(import.meta.url) === resolve(process.argv[1])) {
  try {
    validateCorrelation3(IMPOSSIBLE);
  } catch (error) {
    console.log('Rejected:', error.message);
  }
  const out = portfolioRisk3({
    weights: [0.4, 0.35, 0.25],
    vols: [0.3, 0.2, 0.15],
    correlations: POSSIBLE,
  });
  console.log('Portfolio volatility:', `${(100 * out.volatility).toFixed(3)}%`);
  console.log('Risk contributions:', out.contributions.map(x => `${(100 * x).toFixed(3)}pp`));
  console.log('Sum:', `${(100 * out.contributions.reduce((s, x) => s + x, 0)).toFixed(3)}pp`);
}

Run it with Node.js (tested with Node 22.16.0):

node risk-matrix.mjs

Expected output (rounded for display):

Rejected: Not positive semidefinite; det=-2.888
Portfolio volatility: 21.938%
Risk contributions: [ '11.856pp', '6.637pp', '3.444pp' ]
Sum: 21.938pp

Nothing here calls an API or downloads price data. The weights, volatilities, and correlations are hypothetical decimals, not historical estimates or investment recommendations.

The important part is what we test

For risk software, a nice-looking result isn't an acceptance test. We want a handful of invariants that can fail loudly:

The impossible matrix is rejected before pricing or rendering.
A valid matrix is accepted with its determinant unchanged.
Risk contributions sum to the same volatility computed by the covariance model.
Singular PSD matrices can be valid, but zero-volatility risk shares are undefined rather than an invented 0% / 0% / 0% chart.
Unnormalized long-only portfolio weights are rejected.
A negative individual Euler risk contribution can be legitimate when an asset hedges the rest. Don't automatically clip it to zero.

Create risk-matrix.test.mjs:

import test from 'node:test';
import assert from 'node:assert/strict';
import {
  validateCorrelation3, portfolioRisk3, IMPOSSIBLE, POSSIBLE,
} from './risk-matrix.mjs';

const close = (actual, expected, tolerance = 1e-12) =>
  assert.ok(Math.abs(actual - expected) < tolerance,
    `Expected ${actual} ≈ ${expected}`);

test('rejects pairwise-valid but jointly impossible correlations', () => {
  assert.throws(() => validateCorrelation3(IMPOSSIBLE), /Not positive semidefinite/);
});

test('accepts a valid 3-asset correlation matrix', () => {
  close(validateCorrelation3(POSSIBLE), 0.036);
});

test('risk contributions add up to portfolio volatility', () => {
  const out = portfolioRisk3({
    weights: [0.4, 0.35, 0.25],
    vols: [0.3, 0.2, 0.15],
    correlations: POSSIBLE,
  });
  close(out.volatility, 0.2193769586807147);
  close(out.contributions.reduce((s, x) => s + x, 0), out.volatility);
});

test('accepts singular PSD matrices but does not invent zero-risk shares', () => {
  const perfectOpposites = [
    [1, -1, 0],
    [-1, 1, 0],
    [0, 0, 1],
  ];
  const out = portfolioRisk3({
    weights: [0.5, 0.5, 0],
    vols: [0.2, 0.2, 0.2],
    correlations: perfectOpposites,
  });
  close(out.volatility, 0);
  assert.equal(out.contributions, null);
});

test('invalid weights never reach the model', () => {
  assert.throws(() => portfolioRisk3({
    weights: [0.5, 0.5, 0.5],
    vols: [0.2, 0.2, 0.2],
    correlations: POSSIBLE,
  }), /weights must sum to 1/);
});

test('negative Euler contributions can be legitimate', () => {
  const hedge = [
    [1, -0.9, 0],
    [-0.9, 1, 0],
    [0, 0, 1],
  ];
  const out = portfolioRisk3({
    weights: [0.05, 0.8, 0.15],
    vols: [0.2, 0.2, 0.2],
    correlations: hedge,
  });
  assert.ok(out.contributions[0] < 0);
  close(out.contributions.reduce((s, x) => s + x, 0), out.volatility);
});

Then run:

node --test risk-matrix.test.mjs

Test result: all six tests pass on the code above. The valid example uses weights 40% / 35% / 25%, individual annualized volatilities 30% / 20% / 15%, and pairwise correlations 0.9 / 0.9 / 0.8. It calculates 21.938% modeled portfolio volatility. Its contributions are 11.856, 6.637, and 3.444 volatility percentage points—not three independent asset volatilities.

The units matter: 0.20 means 20% annualized volatility; 0.20 is not 0.20 percentage points. Errors here can be just as misleading as a bad matrix.

Rounding note: Each contribution is displayed to three decimal places. The rounded display values may sum to 21.937pp, while the full-precision sum rounds to 21.938pp. The test checks the unrounded identity, not the displayed strings.

This is a UI architecture problem, too

In MarketDeck's Risk Constellation, the live public educational lab models four fictional assets. It calculates covariance, portfolio volatility, and Euler risk contributions in a numerical engine rather than inferring them from how far a line stretches on screen. Its public equal-correlation slider is constrained to a safe 0...1 range; you cannot paste the impossible three-asset matrix into that public UI.

The engineering lesson is still useful for any application that accepts independently edited pairwise assumptions:

Validate the complete mathematical object, not individual form fields. For bigger matrices, use a tested PSD eigenvalue or factorization method, with an explicit numerical tolerance.
Don't let a renderer own the answer. The chart, table, tooltip, and accessible text should all read the same verified result.
Reject or explain invalid edits. If you choose a nearest-correlation-matrix repair, show the changed assumptions. Don't silently manufacture a different experiment.
Make undefined states explicit. Zero portfolio volatility doesn't produce meaningful proportional risk shares.
Test identities, not screenshots alone. The equality sum(risk contributions) ≈ portfolio volatility is a stronger regression check than a beautiful SVG.

The nearest-correlation-matrix problem is a serious numerical-analysis problem in its own right; Nicholas Higham's paper is a good starting point if you want to investigate careful projection algorithms rather than simply rejecting an input.

One last challenge

Try replacing the valid matrix's third correlation, 0.8, with 0.61. The entry is still between -1 and 1, yet the complete matrix should fail the PSD test. Then try 0.62, the singular boundary, and see why a zero determinant does not automatically mean an invalid correlation matrix.

It's a small experiment, but it carries a general engineering lesson:

A set of individually plausible inputs is not necessarily a mathematically possible system.

That's true in finance, numerical simulation, ML feature engineering, and many applications where relationships are entered pair by pair.

Try the real interactive experiment: The public MarketDeck Risk Constellation models four hypothetical assets; you can also explore MarketDeck's other interactive finance labs. The three-asset code in this article is a separate, self-contained teaching example.

References: Higham, Computing the Nearest Correlation Matrix, Node.js built-in test runner.

Disclosure: This article and its illustrative code were drafted with substantial AI assistance. The mathematics were checked against the documented MarketDeck model, and the JavaScript example and six tests were executed using Node.js. All numbers are hypothetical and educational, not investment advice.

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.

Dabbling in Monte Carlo or quant finance? I built a little interactive lab to tweak volatility, drift and time horizon, then watch how possible outcomes spread. Hypothetical, not forecasts. https://marketdeck.in/interactive/monte-carlo-uncertainty/

Sarthak Verma — Wed, 14 Oct 2026 07:39:37 +0000

Monte Carlo Uncertainty Lab — MarketDeck Interactive

Explore reproducible hypothetical Monte Carlo compounding paths, volatility drag, tail outcomes and sampling uncertainty in an interactive financial learning lab.

marketdeck.in

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.