Written by: Kacper Osiewalski, Lead Backend Engineer, Digital Colliers
The New York Attorney General is suing Kalshi, alleging its sports event contracts are unlicensed gambling. The CFTC filed an emergency motion to block the state, arguing exclusive federal jurisdiction over designated contract markets. Whichever way that fight lands, the operational lesson for anyone offering prediction-adjacent products is already clear. Jurisdictional eligibility can no longer live as scattered if statements in your product code.
If you run a book, an exchange, or anything shaped like an event contract, you now have to answer a harder question at wager time: is this specific market legal for this specific user, under this specific state or country's current rules, right now. And you have to be able to prove the answer six months later when a regulator asks.
Why product-side rules stop working
Most operators started with jurisdiction logic embedded in the checkout or bet-slip service. One flag for US, one for UK, a lookup table for restricted states. That works until the rules stop being binary.
UK operators already live in that world. RCI guidance came into force on 31 August 2022 and was expanded in 2024, layering behavioural triggers on top of licensing rules. Affordability signals kick in at £150 net deposits per rolling 30 days. About one in four UK-licensed operators fails to achieve a satisfactory AML rating on first assessment, and the penalty ceiling for the most serious AML breaches is 15% of gross gaming yield. Those are not numbers you want to defend with grep across a monorepo.
Prediction markets are heading into the same complexity, faster. The Kalshi situation means a single market like a sports event contract may be legal federally, contested in New York, silently tolerated in a third state, and explicitly banned in a fourth. Product code cannot carry that.
Rules as data, not code
The pattern that holds up under audit has four moving parts. None of them are exotic. What matters is that they are separate, versioned, and queried at decision time.
- Jurisdiction registry. One row per jurisdiction, with effective-dated rule sets. Each rule set encodes what market classes are permitted, what KYC level is required, what deposit and behavioural thresholds apply. Rules have a
valid_fromandvalid_to. Nothing is ever mutated in place. - Market classification. Every tradable market gets tagged with structural attributes: underlying event type, settlement source, whether it references a sporting outcome, whether it is peer-to-peer or house-banked. Classification is independent of jurisdiction. You classify once, then let jurisdictions decide.
- User residency and status. Residency, verified documents, self-exclusion flags, affordability posture. Treated as a slowly changing dimension so you can reconstruct what you knew about a user at any past moment.
- Wager-time decision log. For every accepted or rejected wager, you write an immutable record: user snapshot ID, market classification ID, jurisdiction rule set ID, decision, reason codes. This is the artefact you hand to a regulator.
The decision itself becomes a pure function. Given a market, a user, and a jurisdiction rule set at time T, return allow or deny with reasons. That function should be callable from anywhere in your stack and should never reach into a live database for policy.
What the log buys you
The decision log is the part teams underinvest in and later regret. Kindred Group publicly reported a £14M compliance-team cost in 2023. A meaningful chunk of that spend on any large operator is people reconstructing what happened, from logs that were never designed to be reconstructed.
If your wager-time log carries the rule set version, the classification version, and the user snapshot, then answering a regulator's question is a query, not an investigation. You can also replay: take last quarter's wagers, apply this quarter's proposed rules, and see what would have been rejected. That is how you cost a rule change before you ship it.
The near deadline
The honest read on the Kalshi situation is that clarity is not coming soon. States will keep filing. The CFTC will keep pushing back. Operators cannot wait for the courts.
The practical deadline is your next material product change: a new market type, a new state launch, a new partner integration. If jurisdictional rules are still living in product services when that ships, you are compounding the cleanup. And GDPR still sits in the background at up to 4% of global turnover on the personal-data side, so the user snapshot piece is not optional either. Pull the rules out into data now, while the surface area is small.