If your prediction market platform has EU-facing users, the compliance conversation changed in 2026. MiCA enforcement is live, its grandfathering period has ended, and the Travel Rule obligations that come with it are no longer a future problem to plan around. They're a current requirement.
What MiCA actually requires
MiCA, the EU's Markets in Crypto-Assets Regulation, sets out the licensing and operating framework for crypto-asset service providers operating in the EU. Platforms that serve EU users without the right authorization are operating outside the framework, not ahead of it.
Alongside MiCA sits the Transfer of Funds Regulation (TFR), specifically Article 14, which extends the EU's Travel Rule to crypto-asset transfers. In practice, this means originator and beneficiary information has to travel with a transaction, the same principle that's applied to traditional bank transfers for years, now applied to crypto transfers as well. ESMA guidance has continued to clarify how this applies in practice as enforcement has ramped up.
For a prediction market, this isn't an abstract policy detail. It's a requirement that touches every deposit and payout a platform processes for an EU user.
Where platforms get caught out
The Travel Rule requirement is straightforward to describe and genuinely difficult to retrofit. It requires:
- Originator and beneficiary data captured and attached to transfers, not just logged separately after the fact.
- Transaction screening against sanctions lists, ideally before funds settle, not after.
- Geoblocking and jurisdiction controls at the point of connection, so a platform can actually enforce which users are eligible for which products.
Platforms that built their deposit and payout flow before thinking about compliance typically have to bolt these requirements on as a separate system: a screening vendor here, a data capture step there, none of it native to the payment flow itself. That patchwork approach is slower to build, harder to maintain, and more likely to have gaps that only surface during an audit or a regulator's inquiry.
Why the grandfathering period ending changes the risk calculation
For the first phase of MiCA rollout, platforms with an existing user base in the EU had a grace period to bring their operations into compliance without facing the full weight of enforcement. That grandfathering period ended on July 1, 2026, and the numbers make the shift concrete: of the 1,200+ crypto firms that previously held national VASP registrations across the EU, only around 210 secured full CASP authorization under MiCA by the deadline, roughly 17% of the field (Cryptonomist, CryptoBriefing). The other 83% are either mid-process with no legal standing to keep serving EU users, or have already wound down their EU operations entirely (crypto.news). What that means practically is that the cost of being unprepared has shifted: it's no longer a matter of "we'll get to it before the deadline." The deadline has passed. A platform found out of step with Travel Rule requirements today is dealing with active non-compliance, alongside the large majority of the market that's in the same position, not a project that's slightly behind schedule.
Building compliance into the payment layer itself
The alternative is infrastructure where Travel Rule data, screening, and jurisdiction controls are part of the deposit and payout flow from the start, not a separate system layered on top of it.
This is exactly the model Coinbase and Sumsub use. WalletConnect handles the wallet interaction layer, while Sumsub manages the confirmations and compliance prompts, with Travel Rule data fields, transaction screening, and geoblocking built into WalletConnect Payment Products itself, fully white-labelled for the platforms that rely on it. Sumsub built WalletConnect directly into its Travel Rule solution for exactly this reason: it's easier to make compliance native to the payment layer than to bolt it on afterward.
Why this matters beyond the EU
Even for platforms without a large EU user base today, the direction of travel is clear. MiCA has become a reference point other jurisdictions are watching as they build their own frameworks, and Travel Rule-style requirements are becoming more common globally, not less. A platform that builds Travel Rule compliance into its payment infrastructure now isn't just solving for the EU. It's building the muscle it will need as similar requirements land elsewhere, and avoiding a second, separate compliance build the next time a new jurisdiction catches up.
What this looks like in practice for a growing platform
For a platform that's scaling internationally, the pragmatic path is to treat MiCA and Travel Rule compliance as a template rather than a one-off obligation. The same data fields, screening logic, and jurisdiction controls that satisfy EU requirements today are largely reusable as other regions introduce similar rules. Building that capability once, into the payment layer itself, is a far more efficient approach than standing up a new compliance workstream every time a new region tightens its own regulatory framework.
MiCA enforcement being live changes the calculation for any prediction market with EU-facing users: this isn't a "when we get to it" item anymore. It's an operating requirement, and the platforms that treated it as infrastructure rather than paperwork are the ones that are already compliant.