Most of a real-money iGaming platform survives a move to non-wagering products: player accounts, identity checks, the ledger infrastructure, responsible-play tooling, analytics and most integrations carry over with changes. What does not survive is everything built around the operator taking a position on an outcome: the odds engine, trading desk, casino game integrations, house-banked settlement and wagering bonuses. The wallet, cashier and KYC flow sit in between, and how much they change depends on which product you convert to. This guide maps ten platform components against four target products, shows what drives the engineering effort, and lists what a conversion does not change.
This article describes the legal framework for engineering planning. It is not legal advice; confirm how it applies to your product with qualified Brazilian counsel.
Status on 21 October 2026
| Item | Status | Source, date checked |
|---|---|---|
| MP 1.394/2026 | In force since 25 Sep 2026. Art. 1 prohibits the exploration, offer, intermediation and advertising of fixed-odds betting lotteries, including offers from abroad. Art. 4 ends existing betting authorisations on the thirtieth day after publication (25 Oct 2026). No amendment, suspension or conversion annotated | Planalto, 21 Oct 2026 |
| Congress | Joint Committee members designated 30 Sep 2026. The amendment period closed on 13 Oct 2026, with more than 90 amendments listed. Urgency regime from 9 Nov 2026; the first deliberation period ends 23 Nov 2026 and can be extended once | Congresso Nacional, MPV 1394/2026, 21 Oct 2026 |
| STF | ADI 8024, ADI 8027 and related requests are before Minister Luiz Fux. The Attorney General’s Office (AGU) defended the MP on 6 Oct 2026. No injunction reported as of 21 Oct 2026; press reports say a decision is expected after the second round of the elections | Press reports, 19-21 Oct 2026 |
Primary sources: MP 1.394/2026 (Planalto), MPV 1394/2026 (Congresso Nacional).
In this article, a non-wagering product is one in which the operator never holds a position on an outcome and no one stakes money on fixed odds. We use four target products:
- A single-player skill game: a player pays to enter and plays against a published score target or a leaderboard; prizes come from a fixed table.
- PvP duels and tournaments: players pay entry fees into an escrow, compete against each other, and the winner receives a prize from the pooled fees minus a disclosed fee.
- Fantasy sports: users build virtual teams of real athletes and score points from those athletes’ statistics in real competitions.
- A free-to-play (F2P) social casino: casino-style games played with a virtual currency that can be bought but never cashed out, with no prizes of real-world value.
Sitting outside MP 1.394/2026 does not make any of these lawful in Brazil. Each is governed by other rules, listed in the next table. Sweepstakes with dual currencies, prediction markets, crypto products and offshore offers are not covered here because they are not options for the Brazilian market.
Product change or market change?
There are two different conversions, and they reuse different parts of the stack.
A market change keeps the product (a casino, a sportsbook) and moves it to another regulated market. The outcome engines stay; licensing, payments, localisation and certification change. Our operator exit guide covers which components move with a redeployment and how to wind down Brazilian operations.
A product change keeps the market (or the audience) and changes what the platform does. The outcome engines go; the account, identity and ledger layers stay and are reshaped. This guide covers the product change. If you are still choosing between the two paths, our overview of formats and markets after the ban compares them.
The four target products at a glance
| Target product | What decides the result | Where the money sits | Operator revenue | New core subsystem | Rules to check in Brazil (regimes, not outcomes) |
|---|---|---|---|---|---|
| Single-player skill game | The player’s own performance, validated by the server | Entry fees in a player cash balance; prizes from a fixed, published table | Entry fees minus prizes paid | Server-side score validation and replay store | LCP Art. 50 §3(a); Civil Code Art. 814; CDC; ECA Digital; store and payment-partner policies |
| PvP duels and tournaments | Inputs of the competing players, resolved by an authoritative game server | Segregated match escrow, locked until a signed result | A disclosed fee that does not change with the result | Escrow state machine, matchmaking and rating, anti-cheat | LCP Art. 50 §3(a) and §3(c); Civil Code Art. 814; CDC; ECA Digital; store and payment-partner policies |
| Fantasy sports | Official statistics of real athletes, aggregated across a lineup | Entry-fee accounts and prize reserves booked before entries open | Entry fees minus prizes and data costs | Sports data ingestion, scoring engine, contest and rules engine | Art. 49 of Law 14.790/2023 (not revoked by MP Art. 29, as read on Planalto on 21 Oct 2026); CDC; ECA Digital; store and payment-partner policies |
| F2P social casino | Game mechanics played with virtual currency only | Store billing; a closed-loop virtual-currency ledger with no redemption | Sales of virtual currency and in-game items | Store billing and receipt validation, virtual economy | CDC; ECA Digital; LGPD; store policies; no prize of real-world value |
The rules for each format are set out in more detail in our guides to skill games and PvP duels in Brazil and fantasy sports under Art. 49. ECA Digital is the Digital Statute of Children and Adolescents, Law 15.211/2025.
Component conversion matrix
The matrix below is the core of a conversion plan. Each cell uses one of four labels:
- REUSE: keep the component with configuration changes only.
- ADAPT: keep the component and change its data model or flows.
- REPLACE: the job still exists, but the component that does it is rebuilt or swapped.
- REMOVE: the job disappears, and the code paths should be deleted, not hidden behind flags.
| Component | Single-player skill game | PvP duels and tournaments | Fantasy sports | F2P social casino |
|---|---|---|---|---|
| PAM and accounts | REUSE: accounts, sessions, limits and account history | ADAPT: add rating, match history and device links per account | ADAPT: add team and league preferences, lineup-lock notifications | ADAPT: add social or guest sign-in next to existing login; separate account terms for the new product |
| KYC and age assurance | ADAPT: age and identity checks before the first paid entry; payout checks before prizes are paid | ADAPT: as for skill games, plus duplicate-account and device checks | ADAPT: as for PvP, plus checks on linked accounts entering the same contests | ADAPT: age assurance at onboarding sized to child-protection rules; no payout KYC, because nothing is paid out |
| Wallet and ledger | ADAPT: one cash balance; entry fees and prizes in separate ledger accounts | REPLACE: house balance becomes a match escrow with LOCKED, SETTLED and CANCELLED_REFUND states | ADAPT: entry-fee accounts plus prize reserves booked when a contest is created | REPLACE: fiat wallet removed; virtual-currency ledger in a separate schema with no conversion path to money |
| Cashier and payments | ADAPT: deposits and prize payouts; payment descriptors match the new product | ADAPT: as for skill games, plus automatic refunds on cancelled matches | ADAPT: as for skill games, plus refunds for cancelled or under-filled contests | REPLACE: web cashier gives way to store billing for in-app currency; withdrawals removed |
| Bonus and promotions engine | REMOVE: deposit matches, free bets and wagering requirements | REMOVE: as for skill games; tournament tickets only within published prize rules | REMOVE: free bets and boosts; any free entry that leads to a prize is a promotion question for counsel | ADAPT: timed coin grants, login rewards and events in virtual currency only |
| CRM and affiliate tracking | ADAPT: new triggers (score targets, leaderboards); new consent base | ADAPT: triggers on tournament schedules and rating milestones; commission models rebuilt | ADAPT: triggers on fixtures and lineup locks; commission models rebuilt | ADAPT: triggers on coin balance and events; acquisition tracked by install and purchase |
| Casino game integrations (RGS, aggregators) | REMOVE: replaced by server-validated game logic | REMOVE: replaced by an authoritative match server | REMOVE | ADAPT: casino-style content rebuilt or relicensed for virtual-currency play; game maths tuned for play time, not return to player |
| Sportsbook (odds, trading, bet slip, cash-out) | REMOVE | REMOVE | REPLACE: keep sports data ingestion, remove odds and trading, add a scoring engine | REMOVE |
| Settlement | REPLACE: settle on validated scores against a fixed prize table | REPLACE: escrow settlement on a signed server result; idempotent refunds | REPLACE: event-driven scoring, stat-correction window, contest settlement | REMOVE: no monetary settlement; game results change virtual balances only |
| Responsible-play tooling | REUSE: deposit and entry limits, cooling-off, self-exclusion flags | REUSE: as for skill games, plus session limits | REUSE: as for skill games, plus entry limits per contest | ADAPT: purchase limits, session reminders, parental controls; odds disclosure if randomised items are sold |
Reading the matrix: three patterns
Identity and records survive; outcome engines do not. Across all four targets, the PAM, the identity layer, responsible-play flags and the analytics infrastructure are kept and extended. Every component whose job was to price, trade or settle a wager is removed or replaced. That boundary is a useful first cut for a dependency map: anything that calls the odds engine, the trading desk or the RGS needs a new owner or must be deleted.
The wallet is the hardest swap. In a betting stack the wallet is a house balance: the operator is the counterparty to every stake. In PvP the same balance has to become an escrow that the operator never draws from. In fantasy, prizes must be reserved before entries open. In F2P, cash disappears completely. Each change touches the ledger schema, reconciliation jobs and reporting, and bonus logic is often wired into the wallet, so removing it is rarely a clean cut.
F2P splits the platform in two. Apple’s App Store Review Guideline 3.1.1 states that apps selling in-game currencies “must use in-app purchase” and requires odds disclosure before the purchase of randomised items. Guideline 5.3.3 (as read on 11 October 2026) does not allow in-app purchase to be used for credit or currency used with real-money gaming. Google Play’s real-money gambling, games and contests policy treats games that accept money and offer prizes of real-world value as violations unless the app meets its gambling-app requirements, and approved gambling apps must not use Google Play’s In-app Billing. In engineering terms: a store-billed virtual currency and a cash entry-fee balance cannot share a ledger, and there must be no conversion path between them. If you plan to run F2P next to a paid-entry product, design two wallets from the start.
OmiSoft works on these layers through iGaming software development: player account management, wallets and ledgers, payments and PSP integration, KYC and onboarding, bonus and CRM, API integrations, and the migration and modernisation of legacy platforms.
Effort drivers: what makes a conversion heavier
The same target can be a contained project on one stack and a rebuild on another. The table compares common starting points. The load rating is qualitative and relative; it is not an estimate.
| Starting stack | Target | Main engineering work | Critical dependencies | Relative load |
|---|---|---|---|---|
| Casino platform, owned code | F2P social casino | Store billing and server-side receipt validation; virtual-currency ledger; game maths retuned for play time; removal of the cashier and withdrawal flows | Store review; whether game provider licences cover non-cash play | Lighter |
| Casino or PAM platform, owned code | Single-player skill game | Server-side score validation, replay store, fixed prize tables, payout flow | Game design in which performance drives the result; counsel’s view on the format | Moderate |
| Casino or PAM platform, owned code | PvP duels and tournaments | Authoritative game servers, matchmaking and rating, anti-cheat and integrity telemetry, escrow state machine | Real-time networking; integrity monitoring from day one | Heavy |
| Sportsbook, owned code | Fantasy sports | Scoring engine, contest and rules engine, lineup validator, prize-reserve ledger; removal of odds, trading and bet slip | Whether sports data licences cover fantasy use; stat-correction handling | Heavy |
| Combined PAM, casino and sportsbook | Several targets on one platform | Splitting a monolith into product domains; one shared PAM with separate wallets per product; isolating betting data | Clear product boundaries; separate ledgers for store-billed and cash products | Heaviest |
| White-label platform, no source code | Any target | New services built around what the contract lets you extract and integrate | Vendor contract terms on data, APIs and exit | Set by the contract |
Five factors move a project up or down within its row:
- Code ownership and modularity. A platform whose wallet, bonus engine and game integrations are separate services can be changed one service at a time. A monolith has to be split first.
- Ledger design. A double-entry ledger with explicit account types can take escrow and prize-reserve accounts. A balance table with bonus columns usually has to be rebuilt.
- Bonus coupling. The more wagering-requirement logic lives inside the wallet, the more work it takes to remove without breaking balances.
- Third-party licences. Game content, sports data and some PAM modules are often licensed for real-money use in named markets. Check whether the terms cover the new product before planning around them.
- Number of clients. Web, iOS and Android each need their own changes, and store builds add review cycles.
For the backend work in the PvP and skill rows, see our backend game development services. The fantasy row maps to fantasy sports app development. For the F2P row, social casino development covers the game layer, and game economy design covers sinks and sources, in-app purchase strategy and LiveOps balancing.
What a conversion does not change
- Removing the house or the RNG does not make a product lawful. It removes the features closest to the MP’s definition of a fixed-odds bet, but the format is still tested under the rules in the table above. Treat engineering changes as evidence for counsel, not as a conclusion.
- F2P still needs age assurance and store compliance. No cash-out does not mean no rules: child-protection law, consumer law and store policies still apply, including odds disclosure for randomised items.
- PvP and fantasy carry integrity risk. Bots, collusion and multi-accounting replace house risk as the main operational threat. Integrity monitoring is part of the minimum product, not a later phase.
- Payment partners classify the product themselves. Describe the product accurately in descriptors, contracts and APIs, and let each acquirer or payment institution classify it. We do not recommend choosing a merchant category to avoid blocking.
- Certifications stay with the certified system. GLI-19 is the GLI standard for interactive gaming systems; version 3.0 is the current published version, and a version 4.0 draft dated 7 July 2026 is on the GLI website. A certificate covers a specific system for a specific jurisdiction. The controls behind it (change management, logging, access control) remain good engineering practice, but they say nothing about the legal status of a new product.
Data from the betting product
The code and the infrastructure can be reused; the Brazilian player records cannot simply move with them. Player data, balances, transaction history and CRM lists from the betting product stay in its compliance archive for the retention period that applies after the ban, and they are not imported into the new product. The new product acquires users on its own legal basis under the LGPD, with its own terms and consent records. The exit guide linked above covers the retention obligations themselves.
In practice, this means building the new product’s database as a separate schema from the start, even if it runs on the same PAM codebase, and making sure no job, report or CRM trigger reads from the archived betting tables.
A conversion sequence that can stop cleanly
MP 1.394/2026 is still pending conversion, and counsel’s view on a format can change the plan. A staged sequence keeps each step useful even if the project stops:
- Inventory and dependency map. List every service and integration, and mark which ones call the odds engine, trading desk, RGS or bonus engine.
- Separate and archive betting data. Freeze the betting product’s records in the compliance archive before any new schema is created.
- Choose the target with counsel’s view in hand. Use the “Rules to check” column as the agenda for that conversation.
- Rebuild the ledger first. Escrow, prize-reserve or virtual-currency accounts, reconciliation and reporting, tested behind feature flags.
- Delete what the target does not use. Remove odds, trading, RGS and wagering-bonus code paths rather than disabling them. Deleted code is easier to explain to stores, payment partners and auditors than a flag.
- Add the new outcome services. Server-side validation, matchmaking, scoring or store billing, depending on the target.
- Review with stores and payment partners. Share accurate descriptions of the mechanics and the money flow before launch.
- Launch in stages with stop points. Tie each stage to the MP timeline (9 Nov and 23 Nov 2026, and any conversion bill) so a change in the rules stops the next stage, not a live product.
