I keep a running Pixel bench — half a dozen Android handsets, a notebook with timestamp columns, and a growing library of screen recordings. For most of 2025 and 2026 the thing I've been quietly measuring is not table liquidity or RNG claims, but something duller and more revealing: how real-money app operators in India have actually implemented the two tax regimes that landed on them in April 2023 — Section 194BA (30% TDS at withdrawal) and Section 115BBJ (player-side 30% flat tax on net winnings). Three years in, the compliance UX is a surprisingly clean diagnostic of which products are built to last.

This isn't a tax guide. For that, there are two better sources than a blog: the five-cluster India Online Gaming Taxation 2026 pillar at Entertain Monitor covers the full regulatory framework (194BA, 115BBJ, 28% GST on deposits, OIDAR, and the GST input credit Supreme Court dispute), and the PG7 player-side ITR filing guide walks through Schedule OS the way a chartered accountant would. This post sits where neither of those does — on the UX surface, from an observer's bench, measuring how operators actually render those obligations to a player at the moment of a withdrawal.

The compliance UX hypothesis

Here's the frame I've been working from. A tax regime like 194BA/115BBJ creates two kinds of operator work. The first is back-end work — filing Form 26Q quarterly, remitting withheld TDS to the government, keeping books that reconcile. That part is invisible to the player and I can't audit it from a Pixel. The second is front-end work — showing the TDS at withdrawal, exposing the operator TAN for Form 26AS reconciliation, generating annual tax statements the player can download for their ITR, flagging the Section 206AA higher-rate consequence of a missing PAN, surfacing the 31 March deemed-withdrawal event. That part I can measure, and it turns out to be strongly predictive.

The hypothesis: an operator who invests in the player-facing compliance UX is almost always an operator who has also invested in the back-end plumbing, because the UX surfaces are downstream of the plumbing. The reverse is also usually true — operators who skimp on the UX tend to be the ones with reconciliation problems when their players actually try to file. Over 18 months of casual observation, this hypothesis has survived more test cases than I expected.

Six observable signals I now log per app

I don't score apps the way a comparison site does, but I do log six observable signals per app when I open an account:

  1. Per-withdrawal 194BA receipt clarity. Does the withdrawal confirmation page itself render the TDS deducted, the net-winnings basis of the computation (ideally with the CBDT Circular 5/2023 formula shown), and the operator TAN? Or does the receipt just show "amount received: ₹X" with the TDS implied?
  2. Form 26AS reconciliation hooks. Is the operator TAN prominently discoverable in the account dashboard, not buried in a FAQ? When I pull my 26AS from the income-tax portal and the operator's filed Form 26Q doesn't match my per-withdrawal receipt sum (which happens 1-2% of the time in my sample), is there an in-app correction request flow, or do I have to call support?
  3. Dashboard tax statement export. Is there a dashboard page that will export my annual Section 194BA statement — net winnings per quarter, TDS withheld per quarter, operator TAN — in a format a chartered accountant can use directly? Or do I have to screenshot per-withdrawal receipts and sum them manually?
  4. PAN capture flow. Does the PAN get captured at KYC during signup, with Aadhaar-linkage verification? Or does the operator let me deposit and play for weeks and only ask for PAN at my first withdrawal? The latter is a red flag for two reasons: it suggests weaker compliance diligence, and it exposes me to Section 206AA's 20%-higher TDS rate if my PAN ends up inoperative (unlinked from Aadhaar).
  5. 31 March deemed-withdrawal messaging. Section 194BA treats the balance in a user's account at the end of a financial year as a deemed withdrawal for TDS purposes. Do operators proactively message this to the player in late March, with a clear explainer? Or does the TDS entry just show up in the player's 26AS six weeks later with no in-app notice?
  6. GST transparency on the deposit side. The 28% GST on deposits (post Rule 31B of the CGST Rules, from October 2023) is a separate line item from the deposit value. Does the deposit confirmation show the 28% component broken out separately? Or is it folded into "platform fee" with no breakdown?

These signals are deliberately simple — they're what a player can observe without expertise. A compliance team can quibble about whether, say, operator TAN discoverability on the account page is a load-bearing signal, but I've found it is: operators who hide it tend to be the same ones who are slow to resolve reconciliation requests. Discoverability is correlation, not cause, but it's a reliable correlation.

Three app-level patterns I've measured

Without naming operators here (the dedicated comparison site I keep bookmarking does that in detail — see RankMyGame's tax-transparency scorecard which scores five India-facing operators on exactly these six signals and provides a composite), I can describe three archetypes I've observed on my bench.

Pattern A — the "compliance-as-UX" operator

Per-withdrawal receipt renders the net winnings, the deducted TDS, and the operator TAN in the confirmation screen itself. Dashboard has a dedicated "Tax" tab that exports an annual statement reconcilable one-to-one with 26AS Part A entries. PAN is captured at KYC with Aadhaar-linkage check in the signup flow. Late March brings a push notification about the deemed-withdrawal event. Deposit confirmations show the 28% GST component separately. This is the operator profile where I've seen zero reconciliation incidents across ~30 sessions of my own measurement over a year.

Pattern B — the "receipts-but-opaque" operator

Per-withdrawal receipt shows the TDS amount but not the CBDT formula basis. Dashboard has a tax statement export but with formatting quirks that make direct 26AS line-matching harder than it should be. PAN is captured at KYC but the Aadhaar-linkage status isn't surfaced to the player. No 31 March messaging. GST transparency on deposits is absent — the deposit confirmation is a single-line total. Reconciliation works most of the time, but when it doesn't the resolution path is longer because the player is pattern-matching against statements that don't quite line up to the income-tax portal format.

Pattern C — the "checkbox compliance" operator

Per-withdrawal receipt shows "TDS deducted: ₹X" with no breakdown or TAN. No dashboard tax statement export — the player is told to "contact support" if a statement is needed, and the support response delivers a PDF two days later. PAN is deferred to first withdrawal, not at KYC. No deemed-withdrawal messaging. No GST transparency on deposits. These are usually smaller operators or newer entrants; occasionally they're larger operators that haven't invested in the compliance UX because the operational team views it as a non-priority. The reconciliation incident rate I've measured in this archetype is 5-10× Pattern A.

The industry-side numbers that back up this archetype pattern are in the EM Section 194BA cluster, which reports top-20 operator compliance at roughly 95% in Q3 2026 but notes that the operator long tail — the smaller operators below the top-20 cut — drops to approximately 60%. That number lines up with what I see on my bench: the long tail is where the Pattern C concentration lives.

Where the operator long tail is still breaking

Three specific failure modes I've logged in the last six months, in roughly decreasing frequency:

26AS mismatch without a correction flow. Player's per-withdrawal receipts sum to ₹X; operator's filed Form 26Q as reflected in TRACES data shows ₹Y, where Y < X by ₹500-5,000. The operator has an inconsistent back-office — the UX reported the correct number per withdrawal, but the quarterly aggregation to Form 26Q under-reported. There's no in-app correction flow, so the player raises it with support, support says "we'll check," two weeks pass, resolution is uneven. For a mid-stakes player this manifests as a defective-return notice from CPC in September because the player claimed TDS credit the operator didn't actually file.

31 March deemed-withdrawal "surprise." Player sees a sudden TDS line in their 26AS in April that doesn't correspond to any actual withdrawal they made. They raise it as an error; it isn't an error — it's the Section 194BA deemed-withdrawal mechanic the operator never messaged. Resolution is just explanation, but it burns the player's trust and the operator's support bandwidth, both avoidable with a push notification in late March.

PAN inoperative — surprise Section 206AA higher rate. Player's Aadhaar-PAN linkage expires without re-verification; operator keeps processing withdrawals without alerting; TDS is quietly withheld at 30% + 20% penalty rate = effectively 50%. Player notices only when the first affected withdrawal confirmation shows a materially smaller net amount. Mature operators run a periodic Aadhaar-linkage re-verification against the Protean (ex-NSDL) API; checkbox-compliance operators don't.

Each of these is an operator-side engineering problem with a clean fix. The ones I've seen fix it are the operators who already had the Pattern A compliance UX; the ones who haven't are the Pattern C operators who are still treating tax compliance as a quarterly accounting back-office function rather than a product-engineering function.

What this says about which products are built to last

I've been doing this long enough to see a few cycles. The pattern that keeps repeating: operators who treat compliance UX as a product-engineering investment are also the operators who survive regulatory tightening cycles. The Pattern A operators have an incident-free reconciliation record because the engineering team owns the full stack — the per-withdrawal receipt renderer talks to the TDS computation module which talks to the Form 26Q quarterly batch job which talks to the TRACES filing — all built as a coherent product, not three disconnected teams.

Pattern C operators, by contrast, are the ones most exposed when the regulator cycles something new in. If the operator can't render the current regime cleanly on the player surface, they're going to be slower to adapt when, say, the GST Council revises the Rule 31B valuation methodology, or when CBDT issues a clarifying circular that changes the net-winnings formula edge cases. The compliance UX is a leading indicator of operational durability.

This is downstream of a larger observation I've been chewing on for a year: the real-money app category in India is bifurcating. One tier is becoming genuinely product-engineered — compliance UX, matchmaking liquidity, withdrawal reliability, responsible-gaming controls — all treated as first-class product work. The other tier is becoming a thin acquisition-funnel operation with increasingly weak back-office. The tax-compliance UX is one of the cleanest ways to tell the two tiers apart from the player surface, which is also where the regulator and the ITR system start to tell them apart.

What I'd want to see in 2027

Three things I think the top-tier operators will converge on by H1 2027, if the trajectory I've measured continues:

  1. Real-time 26AS reconciliation API. TRACES has an API for taxpayer-side 26AS access. A top-tier operator could offer a one-click "verify my 26AS matches my dashboard" check inside the app, which would eliminate most defective-return incidents at source. I haven't seen anyone ship this yet.
  2. Pre-filled Schedule OS data export. ITR-2 has a specific row for 115BBJ net winnings. A top-tier operator could export a JSON/CSV in the exact format the income-tax e-filing portal's pre-fill endpoint consumes. That would eliminate the manual data entry step for the player and the per-operator segmentation ambiguity (where losses on operator B don't offset wins on operator A).
  3. GST transparency escalation. The 28% GST breakdown on deposits is the dimension where I see the biggest spread between Pattern A and Pattern C right now. Top-tier operators will probably escalate from "breakdown on confirmation" to "breakdown on the deposit modal before the player confirms," making the full economics of a ₹1,000 deposit visible before the money moves.

Whether any of these ship depends on whether the regulator pushes, whether the top-tier operators see competitive value in it, or whether a third-party aggregator (like RankMyGame's scorecard) makes the UX gap costly enough to drive investment. My bet is on the third mechanism, which is why I keep logging the metrics.

A note on method and the limits of this notebook

This post is observational, from one Pixel bench, with casual methodology. I've been measuring these six signals since Q3 2024, roughly one new operator sample per month, with repeat visits to a dozen operators I've kept active accounts on. I don't have access to operator-side filing data, I'm not a tax lawyer, and I don't operate anything in this space. The patterns above are what I've seen; they're not what a formal audit would conclude.

For readers who want the proper regulatory primer, the EM five-cluster taxation pillar is the explainer I'd point to. For the player-side ITR filing workflow with worked examples, the PG7 India player tax filing guide covers it with the care a chartered accountant would. For the operator-side comparison across six observable signals, the RankMyGame tax-transparency scorecard publishes the composite with per-dimension breakdowns across five India-facing operators.

And for the broader structural picture — how 194BA/115BBJ sits alongside the 28% GST deposit regime, the OIDAR extension for cross-border operators, and the pending Supreme Court matter on GST input credit — those are the four other clusters in the EM pillar linked above. The point of this notebook is the UX observation, which is one small corner of a much bigger regulatory system.

I'll keep logging. If the Pattern A/B/C distribution shifts in a meaningful way in Q4 or into 2027, I'll write a follow-up. The pattern I'd watch for is whether the Pattern C long tail shrinks (which would be a signal of either regulatory pressure or acquisition/consolidation at the lower end of the market) or whether it stays stable (which would suggest the two-tier bifurcation is becoming structural).

Find me on X / @arunwatches if you want the running notebook as it evolves.