The India Points Devaluation Index · v1.0

The method, frozen

An index is only worth citing if somebody else can recompute it. Both inputs are public files in the open repository, every rule below was fixed before the first edition came out, and the version number moves the day any of them changes.

why each rule is the rule fold that back up

Inputs: data/changelog.yaml (376 events, 1961-01-01 → 2026-09-30 in force, 2026-11-15 incl. announced) · data/valuation-history.yaml (164 currencies, 241 marks, 19 dated steps)

the formula · the five decisions · what it cannot see · reproduce it · back to the index

The formula

cutShare  =  cutLoad ÷ (cutLoad + gainLoad)   × 100

  cutLoad   =  Σ severityWeight(e)  over events in the window that went AGAINST the reader
  gainLoad  =  Σ severityWeight(e)  over events in the window that went FOR the reader

  severityWeight:  major 3  ·  moderate 1.5  ·  minor 0.6

  direction:  devaluation, fee hike, lounge cut and hostile partner event  →  CUT
              buff, launch, additive partner news                          →  GAIN
              (src/lib/risk.ts eventDirection — the tracker seismograph's own classifier)

basketDelta =  Σ ( value(currency, close) − value(currency, open) ) × 10000

  over every currency this desk could value on the day the window OPENED.
  value(currency, day) is the step function over data/valuation-history.yaml.

Cadence: Indian financial year, and its four quarters
Window bound: Effective dates; start exclusive, end inclusive
Weighting: Unweighted across currencies; severity-weighted across events
Basket: 10,000 points per currency, fixed at the open
Edition floor: 10 dated changes, and the period must be closed
Superlative floor: 20 dated changes
Version: v1.0 — it moves the day a rule does

Worked, on the current edition: FY2026 logged 52 changes — 40 cuts worth 71.7 severity points and 12 gains worth 19.2. 71.7 ÷ (71.7 + 19.2) = 78.9%.

The five decisions, and the arguments behind them

1 · The headline is a SHARE, not a count

The obvious headline was "N devaluations this year". It is the wrong number, and the reason is disqualifying: a count of logged events measures this desk's own collection effort as much as it measures the market. This archive holds one event for 1961 and over a hundred for the current financial year, and most of that difference is that the desk exists now. A ratio is robust to it — logging twice as much of a period does not push the share up unless the period really was more hostile.

The severity weights are not new here either. They are the same published weights the nerf-risk grade and the tracker's seismograph already run on. Inventing a second scale for this index would have let two public surfaces tell different stories about the same events.

2 · The window is the Indian financial year

1 April to 31 March. FY2026 means April 2025 to March 2026, and every label spells the months out, because a bare "2026" is ambiguous between the calendar and financial year and that ambiguity is exactly how a number gets quoted against the wrong window. FY is also the frame the audience already uses: RBI, every listed issuer and every Indian business story report in it. Quarterly editions run on the FY quarters — Q1 April–June through Q4 January–March.

Announced versus effective. An edition is bounded by EFFECTIVE dates, the day a reader's points actually changed value. That is also the only field every row carries: the desk records an announcement date only where a document states one, which is a minority of rows, and a guessed announcement date is a fabricated fact. So a change announced in August and effective in October counts in the October edition — and the August edition lists it under "announced here, landed later", so the gap is visible instead of silent.

Only a closed period gets a page. A URL whose number changes under someone's citation is worse than no URL. A period still running shows as a live line on the index landing page, marked as running, with no permanent address.

3 · Every currency counts once — and here is what that costs

The index is unweighted across currencies. Both of the weighting schemes that look obvious are worse, and it is worth writing down why, because "weighted" reads as more rigorous than "unweighted" and here it is the opposite.

Weighted by the cards that earn a currency. Refused, and not on a judgement call. Marriott Bonvoy and Avios are transfer TARGETS — no Indian card earns either directly — so a cards-earned weight scores the two largest devaluations in this entire archive at exactly zero. A weight that deletes the headline events is not a weight.
Weighted by cardholders. We do not have it. Nobody publishes Indian membership by loyalty programme, and a proxy built from card counts measures product supply rather than readers. An invented weight is worse than no weight, because a reader cannot check it.

So each edition prints EXPOSURE beside every move — how many cards earn that currency, how many transfer routes lead into it — as context you can re-weight by hand, never as a weight applied behind your back. And the honest consequence, stated: this is a statement about PROGRAMMES, not about the rupees in an average Indian wallet.

4 · What counts, and where fees go

Net of buffs, both directions published. Cuts and gains are counted, shown separately and then netted. An index that counted only the cuts could only ever go one way, which makes it propaganda rather than measurement — and the tracker already publishes the gains, so hiding them here would have made two surfaces disagree.

Fee hikes are in the share and out of the rupees. A fee hike destroys real value, so it counts as a cut. It is not a ₹-per-point move, and pricing one into rupees needs a spend assumption this desk does not have — so it never touches the basket. Lounge cuts are treated the same way and for the same reason.

The rupee line is a floor. The valuation archive carries a dated historical mark only where a change was QUANTIFIED against a source. A programme that devalued without anyone being able to price the move reads as flat in the rupee column and counts in full in the share. The rupee number can only understate, never overstate, and every edition says so on its face.

An FX re-mark is a real move and is labelled as one. Several programmes are pegged to a foreign currency; when the rupee moves against the peg, a point really is worth less in rupees even though no issuer did anything. Those show in the table as re-mark rather than event, and every edition prints how many of its movers were which.

5 · Two denominators, never mixed

Events. Cut share, cut and gain counts, severity loads and days-per-cut all count EVENTS. One change is one event however many currencies it moves.
Currency-moves. The rupee line counts currency-moves against a fixed basket. One event that re-prices three currencies is three currency-moves and still one event.
The basket is fixed at the open. 10,000 points of every currency this desk could value on the period's first day. A currency indexed mid-period is excluded from that edition, counted, and named — never interpolated. Otherwise a coverage expansion would move a number that is supposed to measure the market.

What this index cannot see

The classifier is inherited, edge cases included. Direction comes from the site's own event classifier, unchanged. It reads a hostile verb in a partner event's title to decide whether a partner change was a purge or a gift, and it scores card launches as neutral-to-positive. That means a small number of rows land on a side a human might argue with — a regulator freezing an issuer's card sales reads as a partner event with no hostile verb, so it counts on the gain side. We publish the classifier rather than quietly patching it for this one page: a second classifier would be a second story, and the shipped one drives the risk grades on every programme hub.

A thin period gets no headline. A period is published as an edition only with at least 10 dated changes, and no superlative — "the most hostile year on record" — is claimed for a year carrying fewer than 20. A very high share over nine events is true arithmetic and a false sentence. Thin years keep their real numbers in the series table; what they lose is the claim.

Editions are restatable. Every edition is recomputed from the archive on every build. Back-dated coverage — a currency indexed today whose history reaches 2015 — can change a past edition's basket, exactly as a real index restates when its source data is revised. What never changes is the URL and, without a version bump, the method.

It is not a forecast. The forward-looking nerf-risk grade per programme is a different instrument with a different formula, published at /methodology#risk. This index is a backward statement about a closed period.

Reproduce it

Both inputs are curated YAML in the public repository, and every figure the site prints is computed in one module from them:

data/changelog.yaml — 376 dated, sourced events, 1961-01-01 to 2026-09-30 in force — the newest effective date in the file is 2026-11-15, because the desk logs announced-but-not-yet-live changes too.
data/valuation-history.yaml — 164 currencies, 241 dated ₹-per-point marks, 19 of which are steps between two different values.
src/lib/devaluation-index.ts — the arithmetic above, and the only place on this site that does it.
src/lib/risk.ts — the severity weights and the cut/gain classifier, shared with the tracker.

The whole series is served as machine-readable JSON at /d/devaluation-index.json — one object per edition, chart-ready, no scraping required. Cite it, chart it, check us.

The build checks itself. Two gates run on every commit. A data audit asserts that each currency's dated series lands exactly on that currency's live house value — if a series and its own currency disagreed about what a point is worth today, every edition computed from it would be quoting a number the rest of the site does not. And a unit group asserts that the editions tile the calendar with no event counted twice or missed, that the two denominators never mix, and that the index and the tracker's seismograph reduce the same events to the same severity loads.