RBI required.bank.in trust domains. IDRBT’s leaked API allegedly exposed 5,576 bank employees

In 2025, the Reserve Bank of India leaned into a simple idea: make banking domains harder to fake. RBI created the.bank.in subdomain and required local banks to start using it for their online presences, so legitimate banks could operate with a recognizable domain format (bankname.bank.in). The goal, as framed by the rule itself, was to make life harder for phishers and fraudsters.

Now the problem: a security researcher alleges that the entity tasked with running the domain registration machinery, the Institute for Development and Research in Banking Technology (IDRBT), botched the job. In a report [PDF] and a post published yesterday by CashlessConsumer, Srikanth L claims the IDRBT Domain Registration Portal (registrar.idrbt.ac.in), the “exclusive registrar” for India’s.bank.in namespace, exposed its entire REST API via 33+ unauthenticated endpoints. The allegation is specific and ugly: anyone using curl could retrieve bcrypt password hashes, mobile numbers, email addresses, login IPs, and device fingerprints of all 5,576 bank employees trusted with managing India’s banking domains.

That is not just a data-leak headline. It is a credential and identity problem wrapped in an impersonation problem. The.bank.in requirement was designed to counter attacks like DNS spoofing and phishing by creating a trustworthy domain namespace banks must adopt. But if attackers can obtain password hashes and account-related metadata, they may be able to attempt credential attacks against registrars and privileged bank staff. Even if not every hash cracks instantly, hashes still reduce friction for guessing and targeted attempts, and the accompanying contact and device details can help tailor social engineering.

This is also an operational credibility test for the governance model behind the rule. IDRBT was selected as the sole registrar of the subdomains, turning a regulatory trust mechanism into a single choke point. The allegations say the portal exposed sensitive data through unauthenticated REST API endpoints, and also that it went live without a proper security audit and ran without secure APIs for 13 months. Srikanth L says IDRBT has since fixed the “gaping security flaws,” but the window matters. A misconfiguration that persists for more than a year gives attackers time to find, test, and weaponize data.

The researcher’s findings extend beyond raw API exposure. The post alleges evidence that some India banks host websites on shared servers in the United States, Singapore, and Lithuania. It also claims 80 percent of registered.bank.in domains do not use DNSSEC, 40 percent do not employ DMARC, and many domains use free Let’s Encrypt certificates. Those details are relevant because they describe a broader pattern: even if the domain namespace is regulated, the defensive posture across DNS and email authentication may still be inconsistent. DNSSEC and DMARC are not “security theater” when implemented well. They are concrete protections against spoofing and impersonation at protocol level. If many domains lack those guardrails, the trust story becomes harder to enforce end-to-end.

There is another second-order issue hiding in plain sight: information now appears to be partially public. Srikanth L disclosed findings in early June and says he used a GitHub repo to list information found by accessing the portal’s APIs, implying some data that was previously accessible via the open API is now also public. That changes the threat landscape from “a bug that can be patched” to “a dataset that may already have been copied.” Once data is in the wild, fixes can stop fresh access, but they cannot undo what others may already have collected.

For decision-makers, the strategic stake is clear. RBI is trying to increase trust in digital banking infrastructure by mandating a namespace that should be harder to counterfeit. But if the registrar portal becomes an attacker pathway, the trust mechanism can backfire, at least temporarily, by creating a high-value target. This is the kind of failure that boards notice because it undermines the regulator-backed control surface, not just one organization’s internal cybersecurity. At the same time, it is a reminder that implementation details, audit rigor, and API security practices often determine whether a policy becomes an actual shield or a new vulnerability.

At the time of writing, the IDRBT, Reserve Bank, and India’s government appear not to have made a public comment. In the meantime, the allegations outlined in the CashlessConsumer post and Srikanth L’s report put pressure on two fronts at once: patch the portal, and validate the trust chain across DNSSEC, DMARC, hosting practices, and operational security. For peers considering similar domain or identity requirements, the core lesson is blunt. Trust infrastructure is only as secure as the system that issues it, and attackers will always target the weakest link in the “trusted” path.