Research · 30 September 2026

4 of 49 Indian payment aggregators publish a security.txt

A security.txt is a small text file, standardised as RFC 9116, that tells someone who has found a flaw in your systems where to report it. It is the first place a security researcher looks. We checked every payment aggregator on the Reserve Bank of India's authorised list for one.

What we found

Of the nine files that exist, three have passed their own expiry date, one of them in 2022. RFC 9116 requires an Expires field precisely so that a stale contact is not trusted, so an expired file tells a careful reporter to look elsewhere. Seven of the nine link to a written policy, and one is cryptographically signed.

What this does not mean

A missing security.txt does not mean a company has no way to receive a vulnerability report. Several of the companies in this list run a responsible disclosure page or a bug bounty programme elsewhere on their site or on a third-party platform. This check measures one thing only: the standard, machine-readable file in the place the standard says to put it.

That one thing still matters. A person who finds a flaw in a payout, refund or settlement flow is deciding, there and then, what to do with it. If the route is not where they look first, some give up and some post about it publicly. Neither outcome reaches the company's own queue first.

Method

• Sample. The payment aggregators (online, physical and cross-border) in RBI's list of entities holding a certificate of authorisation under the Payment and Settlement Systems Act, 2007, as on 30 September 2026: 70 entities.
• Websites. Each entity was mapped to the public website of the brand RBI names, confirmed by the site's own title or redirect. Five could not be mapped to a single working website and were left out. Three sites refused automated requests, and we did not work around that, so they were left out too. That leaves 62.
• Requests. For each site, at most two requests, to /.well-known/security.txt and then the older /security.txt, plus one to the home page to confirm the domain. Nothing else was requested, scanned or probed. Every request identified itself as ExceptionSecurity-DisclosureStudy/1.0 with a link to our method.
• What counts. A response counts as a security.txt only if it returned HTTP 200, as plain text, with at least one Contact: line. Many sites return their home page for any address, which would otherwise look like a file that exists.
• Grouping. "Global group" means an Indian entity of a company headquartered outside India. Those often publish at the parent company's domain as well.
• No names. We publish aggregates only. The per-company results are available to each company on request.

Publishing one takes about ten minutes

The whole file can be three lines, served as plain text at /.well-known/security.txt:

Contact: mailto:security@example.com
Expires: 2027-09-30T00:00:00.000Z
Policy: https://example.com/security/

The contact must be read by someone who can act, the expiry should be less than a year away, and the policy should say what a reporter may and may not do and how quickly they will hear back.

If you work at one of these companies and want to know exactly what we saw on your domain, write to founder@exceptionsecurity.com and we will send it, whether or not anything follows. If you would rather not run the inbox behind the file yourself, our disclosure programme is free: reports come to us, we reproduce what is real, and your team sees only that. Our own security.txt is here.