Geolocation compliance for DFS

Every paid entry, checked against the state it came from.

Daily fantasy runs on a map that changes. BoundsCheck gives DFS operators state and county boundaries, rules per contest format, spoofing detection, and an audit row for every entry, deposit and withdrawal.

Built by a DFS operator. It gates our own paid contests before it gates yours.

POST /v1/check9 ms
decision   ALLOW
region     US-TX · Travis County
activity   contest_entry · paid
format     pickem
policy     v2026.10.02
signals    gps ✓  accuracy 25 m  mocked ✗  vpn ✗
check_id   chk_7f3a…e91c
The problem

A state list in a config file is not a compliance program.

Most DFS products start the same way: an IP lookup at signup, an array of two-letter state codes compiled into the app, and a release every time the list changes. It works until someone asks you to prove where a specific entry came from.

01

IP is not location

Carrier IPs resolve to the wrong state routinely, and a VPN moves a player anywhere in a click. IP alone can neither block reliably nor prove anything later.

02

Formats differ by state

Pick'em and salary-cap contests are not treated the same everywhere. A single allow-list per state cannot express "this format here, that one there."

03

Opening a state needs a release

When the eligible-states list lives in the app, every change waits on an app-store review. Policy should be data, not code.

04

No record per entry

A processor or regulator will ask about one entry, not your policy in general. Without a check ID stored on the entry, you can show a rule existed but not that it was applied.

What BoundsCheck does for DFS

One check on each paid action. Policy you can change tonight.

  • Paid entry, deposit and withdrawal gatingYour backend calls BoundsCheck before money moves. Each call returns allow or block, the reasons, and a check ID to store with the transaction.
  • Rules per state, county and formatAllow pick'em and salary cap in one state, salary cap only in another, and carve out a county where needed. Rules are versioned with the admin who changed them.
  • Eligible-states endpointYour app's onboarding screens read the live list from BoundsCheck instead of a compiled array, with ETags so it only re-downloads on change. Opening a state becomes a policy edit, not a release.
  • State minimum age RoadmapWhere a state's minimum age differs from your own, enforce it against the resolved state on entries and deposits.
  • Spoofing and VPN signalsThe fake-GPS flag, VPN and hosting ranges, IP-versus-GPS distance, impossible travel, stale locations and timezone mismatches. An untrusted location is never approved.
  • Block by defaultA mocked or border-ambiguous location is never approved, and a missing or stale one prompts the player to share their location. Errors answer BLOCK. Nobody is guessed in.
  • Monitor before you enforceRun checks on real traffic without acting on them, and see in the decision log what would have been blocked. Then enforce web, then mobile once your new build has adoption.
  • Flat pricing by active playersUnlimited checks. Check on every paid action without watching a per-ping meter.
Integration

Two middleware lines on the server, one payload from the client.

Your paid-entry and withdrawal routes call BoundsCheck with the device fix the client sent. On web, the browser's location API supplies the fix; a ready-made web script is on our roadmap Roadmap. Mobile adds the location permission and a small object on the same calls.

geo_fix sent with a paid entryJSON
{
  "lat": 30.2672, "lng": -97.7431,
  "accuracyM": 25,
  "capturedAt": "2026-10-06T18:00:00Z",
  "timezone": "America/Chicago",
  "platform": "ios", "mocked": false
}

The contest format comes from your contest record, never from the request body. A player who can set the field can pick the policy they are judged by.

FAQ

Questions DFS operators ask.

Do I need geolocation for daily fantasy sports?

If you take paid entries from players in more than one state, you need a defensible way to show each entry came from a state where that contest is allowed. Most operators start with IP geolocation and a hand-maintained state list. BoundsCheck replaces that with a device fix checked against real boundaries and a versioned policy, plus an audit row for every decision.

Can I allow pick'em in some states and salary cap in others?

Yes. Policy rules are keyed on jurisdiction and contest format, paid or free. You can allow one format and block another in the same state, and change the rule without an app release.

What happens when a player is near a state border?

The device's accuracy radius is considered. If the location's accuracy circle, plus a safety buffer, reaches into a state where that contest isn't allowed, the entry is not approved. The player is asked to try again rather than being guessed in.

Does this require a mobile app release?

Enforcing on mobile does, because the app has to request location permission and send a device fix with each paid entry. On web, the browser's location API supplies the fix. Most operators run checks without enforcing first, then enforce on web, then on mobile once the new build has adoption.

Running paid DFS contests across states?

Tell us which states you operate in and roughly how many active players. We'll set up a walkthrough and show you what the decisions would look like on your traffic.