India processes more real-time digital payments than any other country on earth. UPI made instant, interoperable payment a default civic utility — which means the cryptography underneath it is not one bank's problem but a piece of national infrastructure. That is exactly the profile the DST report flags as highest-priority: a system whose failure cascades across the economy.
What secures a payment, cryptographically
Strip a real-time payment down to its trust mechanics and you find three jobs, each done by public-key cryptography:
- Transport encryption — TLS protects each hop between app, payment service provider, the central rail and the destination bank. Its key exchange typically rests on elliptic-curve Diffie–Hellman.
- Digital signatures — payment messages are signed for integrity and non-repudiation, so a transfer instruction can be proven authentic and unaltered. These signatures are commonly RSA or ECDSA.
- Public-key infrastructure — certificates establish that each participant is who it claims to be, anchored to certificate authorities and root keys.
All three sit in the family of algorithms a cryptographically relevant quantum computer is expected to break. The payment rail is not incidentally exposed; its core trust mechanisms are the exposure.
Why payments concentrate both quantum threats
Most systems lean toward one of the two clocks from N° 01. Payments carry both, intensely.
HNDL applies to the transport layer: an adversary capturing encrypted payment traffic today can, after Q-Day, decrypt transcripts revealing account relationships, transaction patterns and amounts at population scale. Payment metadata is sensitive even when individual amounts are small, because the graph of who pays whom is itself intelligence.
TNFL applies to the signing layer, and this is the more alarming of the two for payments. If signing keys can be recovered, an attacker can forge authorisations — manufacture payment instructions or settlement messages that verify as genuine. In a system clearing billions of transactions, the integrity of the signature is the system. A break there is not data leakage; it is the ability to mint trust.
For payments, the signature isn't a feature of the system. The signature is the system. TNFL aims directly at it.
What makes the Indian payment context distinctive
- Scale and centralisation. A small number of national rails carry an enormous share of transactions. That concentrates risk — but it also means a coordinated migration of a few critical systems protects a disproportionate share of the economy. The leverage cuts both ways.
- Latency intolerance. The report explicitly warns that PQC overhead is manageable in millisecond systems but problematic at microsecond scale. Payment switches are latency-sensitive; larger PQC signatures and handshakes must be engineered in, not dropped in. This is a textbook case for piloting before migrating.
- Long-lived trust anchors. The root keys and participant certificates behind a payment network are exactly the long-shelf-life signing material TNFL targets — and the slowest to rotate.
- Ecosystem coordination. No single participant can migrate the rail alone. Apps, PSPs, the central switch and destination banks must move in step, which is precisely why the report mandates CBOMs and crypto-agility clauses across the supply chain.
The framing for a board
Quantum risk to payments is not best argued as "our data might leak." It is best argued as "the integrity of authorisation — the thing that makes a payment a payment — has a known expiry date, and the systems that carry it are national, latency-sensitive, and slow to change." That framing tends to land with audit committees in a way that abstract cryptography does not, because it speaks to settlement integrity and systemic risk rather than to algorithms.
For a payments-exposed institution, KavachQ's SCORE separates the two clocks explicitly: it flags HNDL-exposed transport paths distinctly from the signing and PKI assets that carry TNFL risk, mapped to the data class and the regulated framework each touches. That distinction is what lets a board see settlement-integrity exposure as its own line item rather than buried inside a generic "RSA in use" finding.
→ The two clocks need separate treatment; the assessment keeps them separate.