How Can Government Portals Stop Booking Bots Without Locking Out Citizens?

Short answer: A booking portal cannot out-CAPTCHA a bot forever, and in my view a public one should stop trying. Indian Railways deactivated 3.02 crore suspicious IRCTC user IDs during 2025, and announced that Aadhaar-based OTP would be mandatory for online Tatkal booking from 15 July 2025. A year later, Railway Minister Ashwini Vaishnaw told the Lok Sabha that bots made up 57.74% of the requests reaching the e-ticketing system in the first half of 2026, peaking at 65.95% in June. My reading is that tying a booking to a verified identity raised the cost of running a bot but not by enough, because a Tatkal seat resold at a premium still pays for the effort. In March 2025 the US Embassy in India cancelled about 2,000 visa appointments made by bots. A month later, agents told ThePrint that some agencies were running round-the-clock teams whose work had become more sophisticated "with the use of automated tools and artificial intelligence." I read neither story as an argument for a harder CAPTCHA. Both argue for binding the booking to something that costs the attacker money or accountability at the moment it matters, in a way that still works for a citizen who cannot see a distorted image or hear an audio clip. GIGW 3.0, the Government of India's guidelines for its websites and apps, requires any CAPTCHA to come with alternatives for people with different disabilities. A portal that gets this wrong has not stopped the bots. It has only stopped some of the citizens.

"Only Aadhaar authenticated user can book Tatkal tickets": what the Ministry ordered

On 11 June 2025, PIB Delhi published a Ministry of Railways release titled "Only Aadhaar authenticated user can book Tatkal tickets on IRCTC Website and App from July 1." Its stated aim was "to ensure fair and transparent access to Tatkal tickets and to safeguard the interests of genuine passengers." It set out three provisions. First: "Effective 1st July 2025, Tatkal tickets booked through IRCTC's official website and mobile app will be available only to users authenticated with Aadhaar," with Aadhaar-based OTP becoming mandatory for online Tatkal bookings from 15 July. Second, Tatkal tickets booked at computerised Passenger Reservation System counters and through authorised agents would need an OTP sent to the passenger's mobile number, also from 15 July. Third, authorised agents could not book opening-day Tatkal tickets in the first 30 minutes of the window: 10:00 to 10:30 AM for AC classes, 11:00 to 11:30 AM for non-AC.

I read those three provisions as one system. The first ties the booking to a government-verified identity. The second extends a check to the counter and agent channels a tout could otherwise use as a side door. The third removes a fast script's advantage over a human in the minutes when that advantage pays off.

Even with Aadhaar checks, bots still made 57.74% of the requests

By December 2025 the Ministry had numbers to show. In a written reply in the Lok Sabha on 11 December 2025, Vaishnaw said: "About 3.02 crore suspicious user IDs have been deactivated since January 2025." He said anti-bot solutions such as Akamai were deployed to filter non-genuine users. Aadhaar-based OTP for online Tatkal booking was then running on 322 trains, and at reservation counters on 211 trains. On those 322 trains, the time confirmed Tatkal tickets stayed available had gone up by about 65%, and it had gone up on about 95% of 96 popular trains. A February 2026 PIB release listing the same defences adds that IRCTC already runs a CAPTCHA "at multiple levels."

Then came the more telling number. Replying to a starred question in the Lok Sabha on 22 July 2026, Vaishnaw said that between January and June 2026, on average 8.88 billion of the 15.38 billion requests the e-ticketing system received each month were bot-generated, 57.74% of all traffic, and were blocked before reaching the reservation platform. By month: 58.78% in January, 45.50% in February, 45.90% in March, 61.39% in April, 60.18% in May and 65.95% in June. So the blocking works, but deactivating crores of accounts and adding Aadhaar checks did not make the attempts stop. Within a year of the rule taking effect, more than half the requests arriving at the system were still automated.

I don't read that as a failure of the Aadhaar rule. It shows what "raising the cost" buys you. A verified identity is harder to fake than a throwaway email, but not impossible, and a resold Tatkal seat is still worth the effort to someone. The Railway Protection Force's own numbers show touts have never been short of effort. An RTI response obtained by activist Anil Galgali from the RPF at Central Railway headquarters in Mumbai shows 1,676 touting cases registered between 2022 and June 2026, with e-tickets and counter tickets worth over ₹10.5 crore seized, 502 cases in the peak year of 2024, and 429 touts arrested in 2025. Booking software is not new either. In February 2020, the RPF cyber cell in Pune reported busting a racket built on illegal software named Red Mirchi, I-ball, ANMS, MAC and Jaguar, found 4,493 live tickets worth ₹1.30 crore on one seller's server, and drew up a list of 55 more "super sellers" of the software. What has changed since then is how cheap and capable that automation has become, which is the subject of this series (see the pillar post for the wider traffic evidence).

The US Embassy cancelled 2,000 bot-booked appointments. A month later, agents described AI tools

Indian Railways is not the only public booking system in this fight. On 26 March 2025, the US Embassy in India posted: "Consular Team India is canceling about 2000 visa appointments made by bots. We have zero tolerance for agents and fixers that violate our scheduling policies." It also suspended the scheduling privileges of the accounts involved.

Reporting by ThePrint on 28 April 2025 described how the trade works. Three authorised visa agents, speaking anonymously, said some agencies had built dedicated teams of 15 to 20 people that "operate round the clock, constantly scanning for cancellations that free up appointment slots," and that the practice had grown more sophisticated "with the use of automated tools and artificial intelligence." ThePrint also reported that for student visas, "dozens of such appointments are being cancelled on a daily basis." Right after the COVID-19 pandemic, some agents charged over ₹1 lakh for an earlier date; at the time of the report, agents were charging as much as ₹60,000 for "expedited dates," against visa fees of ₹15,000 to ₹26,000. The US response was not a harder CAPTCHA either. ThePrint reported that accounts linked to fraud could be blocked and that the US was informing the UK, Canada and Australia about individuals caught manipulating the appointment process.

That is accountability doing work that detection cannot: once an identity is known to be bad, it stays known, and can be shared with other systems. The same idea runs through this series' post on whether websites should block or admit AI agents (see should my website block AI agents or let them in): the useful question is less "human or bot?" than "accountable or anonymous?"

GIGW 3.0: the CAPTCHA has to work for a citizen who cannot see it

Whatever a portal does to raise the attacker's cost, it still has to let a real citizen through, and GIGW 3.0 makes that a requirement. Its accessibility chapter says: "CAPTCHA: If the purpose of non-text content is to confirm that content is being accessed by a person rather than a computer, then text alternatives that identify and describe the purpose of the non-text content are provided and alternative forms of CAPTCHA using output modes for different types of sensory perception are provided to accommodate different disabilities." GIGW 3.0 targets conformance with WCAG 2.1 Level AA, and it added a chapter on cybersecurity formulated by CERT-In, covering websites, web portals, web applications and mobile apps.

CAPTCHA's own track record should also limit how much weight a portal puts on it. The evidence on solve rates, and why that contest tends to favour the attacker over time, is covered in is CAPTCHA still enough to stop bots. My advice for a public portal: treat a CAPTCHA as a speed bump that you owe an accessible alternative for, and don't count on it to hold back a swarm.

What actually raises the cost, without locking out citizens

These cases point to one idea that runs through this series: the fix that works makes the attacker pay more per action instead of making a human squint harder. Here is how I would apply it.

• Bind the booking to a verified identity, not a session. Aadhaar OTP is India's version of this; a passport number, a company's GST registration or another government ID can serve the same purpose. The identity does not need to be Aadhaar. It needs to be something the attacker cannot mint in bulk for free.
• Rate-limit and flag by identity, since IP addresses are cheap to rotate. A verified identity that has already booked, or has been flagged, costs the attacker a fresh account or a stolen one, and both cost more than a proxy list.
• Check identity at the moment the booking is confirmed, the step that actually matters. The Railway notice's OTP requirement and its agent restriction both sit at the booking step, and the restriction covers only the 30 minutes that matter. None of it slows down someone checking seat availability.
• Keep logs by identity that can answer an RTI request. The RPF's touting numbers exist because Anil Galgali could ask for them and get a year-by-year answer. A portal that can produce that kind of record can also show an auditor or a court that its rate limits work and are not quietly blocking a group of legitimate users.
• Treat the accessible path as part of the security design, not an add-on after launch. GIGW 3.0 puts CAPTCHA accessibility and cybersecurity in the same set of guidelines. Build the audio or alternate-channel path before the visual one ships, and test it yourself the way a blind citizen would have to.

For officials and vendors: questions to ask before you sign off on a portal

If you are the official approving a build, or the vendor pitching one, these are the questions I would ask, in order. What is the CAPTCHA's non-visual fallback, and has anyone on the team actually tried it? Does the identity check happen at booking or confirmation, or only at account creation, where it does nothing against someone who already has ten accounts? Is the rate limit keyed to a verified identity, or only to an IP address a bot operator can rotate in seconds? What happens on the tenth suspicious attempt from one identity, compared with the tenth from one IP? And can the system produce a log that would answer a Parliament question or an RTI request, the way IRCTC's and the RPF's numbers did here? A vendor who cannot answer the first two questions is selling you a CAPTCHA and calling it a defence.

Ready Bytes has not built a government booking portal or a citizen-facing verification system, and nothing above is a case study of one. We build web apps, back-office automation and integrations for owner-led businesses, the pattern behind what actually works in small-business back-office automation. This post is a reading of public notices, Parliament replies, news reports and one accessibility clause, checked against the pages that published them. If you are a private company or an empanelled vendor building or maintaining a citizen-facing booking system, and you want a second set of eyes on the identity, rate-limiting and accessibility design before you ship it, here is the ladder:

• A free AI opportunity audit: about five minutes, no cost, a written response within two business days.
• A $500 full audit if the free one surfaces something worth a closer look: read-only access, the top opportunities ranked, credited against a pilot if you proceed.
• A fixed-quote pilot, typically $3,000 to $8,000 over 2 to 6 weeks, scoped to one piece. Here that most likely means auditing an existing booking flow's identity binding, rate limits and accessible-CAPTCHA path against the questions above, or building the accessible alternative a portal lacks.
• Ongoing work once a pilot has proved itself.

Sometimes the most useful outcome of the audit is a recommendation to spend nothing, because the fix is a configuration change to a rate limiter you already own.

Start here

Do one exercise this week, on your own portal's logs, before buying anything.

Pull the busiest single minute of the week, the moment your Tatkal-style window opens or your appointment slots release. Count how many successful bookings in that minute came from an identity, device or IP that had already booked, attempted, or failed in the same window moments earlier. That number tells you more than any CAPTCHA solve-rate benchmark about whether you have a bot problem or a capacity problem. Then try your own CAPTCHA the way a citizen who cannot see it would have to: turn off the screen, or find the audio option, and see if it works at all. If neither test turns up anything, you may not need to spend a rupee. If either one does, you know which of the five steps above to start with.

---

Shyam Verma founded Ready Bytes in 2009 and has been building software since 2005. He writes about back-office automation, legacy modernization and applied AI at readybytes.in/blog.