Geo-location checks in 200ms; the appeal form takes 3 weeks
A geolocation check on a betting site resolves in under 200ms while the appeal against its block takes three weeks, exposing a striking asymmetry
A geolocation check on a modern betting site resolves in under 200 milliseconds. The appeal against the block it triggers routinely takes three weeks. That gap — between a decision made faster than a blink and a redress process measured in working days — is one of the stranger asymmetries in regulated iGaming, and it's worth looking at what actually happens in each half.
What the 200ms check actually does
The geolocation lookup most operators run isn't a single test. It's a stack: an IP-to-location database query, a device GPS or Wi-Fi triangulation check where the platform has permission, and often a carrier or ISP signal confirming the connection's origin. The result gets matched against a licensed jurisdiction list, and the session is allowed, blocked, or flagged.
The speed comes from caching and pre-computation. IP ranges are mapped to regions in advance; the browser-side component does its own local check and reports back. When everything lines up, the user never notices. When it doesn't — a VPN, a border town, a mobile carrier routing traffic through a neighbouring country, a corporate proxy — the system has to make a call, and it usually makes it conservatively.
That conservatism is the point. Regulators expect operators to demonstrate that a customer in a prohibited jurisdiction can't place a bet, and the cheapest way to demonstrate that is to block anything ambiguous. Under the UK Gambling Commission's remote technical standards, for instance, licensees must use geolocation to prevent access from outside Great Britain — and the compliance evidence is a log showing the block fired, not a log showing someone thought carefully about a marginal case.
So the 200ms figure is real but slightly misleading. The check is fast. The policy baked into it was written months earlier, by people who had to choose between false positives and regulatory risk, and they chose false positives nearly every time.
Where the false positives come from
Three recurring sources:
- Carrier-grade NAT and mobile routing. A customer in Belfast on a certain MVNO can present as being in the Republic of Ireland. The reverse happens too.
- VPN and privacy tooling. Increasingly default-on in some browsers and security suites. A user may not know they're tunnelling.
- Shared IP space. Hotels, student halls, co-working spaces, and public Wi-Fi frequently egress through a single address registered somewhere unhelpful.
None of these are edge cases in the way operators sometimes imply. Mobile traffic in particular produces a steady trickle, and the customers affected are usually the least equipped to navigate an appeal — they just see a screen telling them they can't play, with a reference number and an email address.
The appeal: three weeks, if you're lucky
Now the other half. A customer who believes the block is wrong submits a support ticket, or fills in a form, or emails. What happens next varies enormously by operator, but a common shape looks like this:
- Front-line support acknowledges within a day or two and escalates, because they can't override a geolocation flag.
- The compliance or fraud team picks it up. This is a queue, not a dedicated function at most mid-sized operators.
- The customer is asked for evidence — a utility bill, a screenshot of their IP, sometimes a video call or a notarised document depending on the jurisdiction.
- The evidence is reviewed, often against the original geolocation log, and a decision is issued.
Three weeks is not a worst case. It's a plausible median for a case that requires document review at an operator with a few hundred thousand active customers and a compliance team of a dozen people. Some resolve in 48 hours. Some take six weeks because the customer got frustrated and stopped replying, and the ticket went dormant.
The asymmetry has a structural cause: the block is automated and the appeal is manual. Automating the block is cheap and scales infinitely. Automating the appeal is hard, because the whole reason a human is involved is that the automated system got it wrong. You can't easily build a fast lane for "the machine was mistaken" without also building a fast lane for people who are lying about where they are, which defeats the purpose.
The evidence problem
There's a second asymmetry inside the appeal itself. To prove you're in a permitted jurisdiction, you're often asked to hand over documents that reveal considerably more than your postcode — a utility bill shows your name and address, sometimes your account numbers. Customers who are privacy-conscious enough to be running a VPN are, almost by definition, the customers least comfortable with that request.
Some operators have started accepting lighter evidence: a fresh geolocation check run with the customer's consent, a bank card issuer country match, a short video showing the device's location settings. It's faster and less intrusive. It's also less convincing to a regulator if the case is ever audited, which is why adoption is uneven.
Why the gap persists
You might expect competitive pressure to close it. It hasn't, for a few reasons.
First, the customers affected are a minority, and a minority that skews toward people who travel, use privacy tools, or live near borders. They're not a loud enough constituency to move a product roadmap.
Second, the cost of a slow appeal is borne by the customer, not the operator. A blocked player who gives up is a lost deposit, but a small one, and the compliance team's time is expensive. The maths often favours the queue.
Third, and most importantly, the regulator's incentive and the customer's incentive point in different directions. The regulator wants demonstrable blocking. The customer wants access. The operator sits between them and gets criticised from both sides, so it defaults to the position that's easier to defend in an audit.
There are signs of movement. A handful of jurisdictions now publish expectations around appeal timelines — not binding in most cases, but a nudge. Some operators have built dedicated geolocation dispute queues with service-level targets of five working days. That's still 2,000 times slower than the block, but it's an improvement on three weeks.
The question nobody has answered
Here's the thing worth sitting with. The 200ms check and the three-week appeal are both doing compliance work, and only one of them is measured. Operators can tell you their block rate to two decimal places. Almost none can tell you their median appeal resolution time, or what proportion of appeals succeed, or how many customers give up before filing one.
That last number is the interesting one. If a meaningful share of geolocation blocks are false positives — and the mobile-routing evidence suggests it's not trivial — then the appeal system isn't a safety net. It's a filter that quietly converts a compliance error into customer churn, and nobody is counting the conversions.
The open question is whether regulators will start asking for that number. If they do, the three-week appeal becomes a metric with a target attached, and the gap between 200ms and three weeks stops being an architectural accident and becomes something someone is accountable for closing. Until then, the fast decision keeps being made by a machine that never has to explain itself, and the slow correction keeps being made by a person who does — eventually, and only if the customer waits.
If you're the one staring at a blocked screen, the practical advice is unglamorous: file the appeal the same day, keep the reference number, and don't assume the first reply is the decision. And if you're betting regularly from a mobile connection near a border, it's worth checking your connection's apparent location before you deposit, not after.