Brazil Portaria SPA/MF 2.579/2025: The Centralised Self-Exclusion Register and Mandatory Autolimits Decoded

Portaria SPA/MF 2.579/2025 established Brazil’s centralised self-exclusion architecture on 10 December 2025, replacing a patchwork of operator-level self-exclusion tools with a single federal register queried through the Sigap API. For operators authorised under Law No. 14,790/2023, the transition was not optional: the Portaria set a hard 10 December implementation deadline and simultaneously introduced mandatory autolimit tools that must be configured at the point of account registration. Compliance teams that have not yet mapped every Sigap verification trigger and every autolimit deployment requirement against their technical stack face direct licence risk.

Regulatory Architecture: How Portaria 2.579 Fits the Lei das Bets Framework

Brazil’s fixed-odds betting and online gaming market operates under a federal statutory framework anchored in Law No. 14,790 of 29 December 2023. The Bets Act, as it is commonly known, granted the Ministry of Finance (MF) and its executing body the Secretaria de Prêmios e Apostas (SPA) exclusive authority to authorise and supervise all apostas de quota fixa and online gaming nationally. Portaria MF 1,330/2024 provided the primary operational detail on application procedures, technical requirements, and financial obligations.

Portaria 2.579/2025 sits within that stack as the primary responsible gambling instrument. Where the Bets Act established the legal obligation to protect bettors from harm, and Portaria 1,330/2024 set out the structural licensing conditions, Portaria 2.579 specifies the precise technical and procedural architecture through which player protection must be operationalised. The SPA labelled implementation of the centralised self-exclusion system as the “most important” priority in its 2025-26 regulatory agenda, published in April 2025, a signal that the SPA was prepared to treat non-compliance with the same seriousness as financial or KYC breaches.

The system was built by the Serviço Federal de Processamento de Dados (SERPRO), Brazil’s Federal Data Processing Service, and is integrated with Sigap (the Sistema de Gestão de Apostas), the centralised Betting Management System that serves as the API backbone for all operator-level compliance reporting and verification in Brazil. SPA Secretary Regis Dudena described the architecture as placing Brazil “among the global leaders” in centralised betting protection at launch, a claim that is architecturally defensible when compared with comparable regimes such as Spain’s RGIAJ, France’s Interdiction Volontaire, or Germany’s OASIS.

What the Centralised Register Actually Does

Before Portaria 2.579, authorised operators were required to offer players the option to self-exclude within their own platform. The structural weakness of that model is identical across all jurisdictions that have historically relied on it: a bettor who self-excludes on one platform can immediately register on a competitor’s site. The centralised model eliminates that vector by creating a single federal register keyed to each bettor’s Cadastro de Pessoas Físicas (CPF) number, Brazil’s individual taxpayer identification number, which all authorised platforms must query before allowing registration or continued account access.

Players can now voluntarily request the blocking of their access to all federally licensed betting sites simultaneously, while also opting out of receiving targeted advertising from any authorised operator, a scope that exceeds the self-exclusion perimeter of many mature European regimes that still permit residual marketing to self-excluded players.

The register is maintained within Sigap’s Módulo de Pessoas Inelegíveis (Ineligible Persons Module). A Sigap query against a CPF number returns one of two responses: “Blocked, Centralised Self-Exclusion” when the number appears in the module as a voluntary self-excluder, or “Not Blocked” when no restriction applies. Operators must act on the first response immediately, they have no discretion to override or delay the restriction. The same Sigap module also carries status flags for other ineligible person categories, described in the section below on scope expansion.

How Often Must Operators Verify Against the Sigap Register?

Portaria 2.579 does not permit operators to perform a single onboarding check and rely on it indefinitely. The regime imposes a structured, ongoing verification cadence across three mandatory touchpoints.

At account registration, the operator must query Sigap against the applicant’s CPF before the account can be opened. A “Blocked, Centralised Self-Exclusion” response must result in refusal of registration. The operator must communicate the refusal reason to the applicant and cannot register the individual under any circumstances while the block is active.

For existing active accounts, operators must run a Sigap query on the first login of each day for every active user. This daily check means that a bettor who self-excludes via the federal portal during the day will be blocked from further access on their next login, even if they are already registered on the platform. The check is automated through the Sigap API and must be executed before any wagering session is permitted to begin.

The third verification cadence requires operators to run a rolling Sigap check across their entire active account base every 15 days. This periodic sweep serves as a backstop for accounts that may not log in frequently: a bettor who self-excludes and then does not log in for several weeks will still be flagged and their account actioned within the 15-day cycle.

What Must Operators Do When a Bettor Is Flagged as Self-Excluded?

When any Sigap query returns a “Blocked, Centralised Self-Exclusion” status for an existing account, the operator must suspend that account within three calendar days of the date of the query. The three-day window is an outer limit, not a target, operators whose systems are fully integrated with Sigap should implement automated flagging that initiates the suspension workflow on the same day the query returns the blocked status.

Before suspension, the operator must notify the user of the reason for the block and provide an opportunity to withdraw any funds held in the account. If the bettor does not voluntarily withdraw the balance, the operator must return the funds within two calendar days of the suspension, transferring to one of the deposit or payment accounts registered by the customer on the platform. Any unsettled bets at the time of suspension must be settled and the resulting funds returned in the same manner, as confirmed in the Portaria’s account-closure provisions.

Following suspension, operators are prohibited from sending active communications, targeted advertising, or direct notifications to blocked users. Critically, this prohibition extends to messages about the possibility of returning to the betting platform in the future. The ban on re-engagement communications is explicit in the Portaria and represents a stricter standard than, for example, the UKGC Licence Conditions and Codes of Practice (LCCP), which requires licensees to take all reasonable steps to prevent marketing material reaching self-excluded customers but does not contain an equivalent explicit prohibition on return-invitation messaging timed relative to exclusion expiry.

All communications with the user, from the initial block notification through the fund return process, must be documented by the operator, recording the date, time, channel used, and the content of each message. This documentation must be retained for a minimum of five years. In the event that fund transfer is not possible due to payment account issues or the bettor’s refusal to provide account details, operators must escalate through a documented fallback procedure and record the inability to transfer alongside all attempts made.

The Ineligible Persons Module: Scope Beyond Voluntary Self-Exclusion

Operators working solely from the voluntary self-exclusion framing of Portaria 2.579 risk a material compliance gap. The Sigap Ineligible Persons Module carries multiple status categories beyond the voluntary “Blocked, Centralised Self-Exclusion” flag, and the obligation to query and act on all of them applies equally to all authorised operators.

Current Sigap ineligibility categories include: voluntary self-exclusion requestors under Portaria 2.579, recipients of the Bolsa Família Programme and the Continuous Cash Transfer Benefit (Benefício de Prestação Continuada), following restrictions introduced in parallel with the Bets Act rollout, persons barred from betting by a specific administrative or judicial decision, upon formal notification to the SPA, and, added through SPA Portaria 1,237/2026 and Normativa No. 3/2026, beneficiaries of the Novo Desenrola Brasil debt renegotiation programme under Provisional Measure No. 1,355/2026.

The Desenrola Brasil addition is operationally significant because it extended the Sigap verification logic to a dynamic population: individuals join the programme on an ongoing basis through their banks, Banco do Brasil centralises the list, and CPF numbers are forwarded to the SPA for inclusion in the Ineligible Persons Module in near real-time. This means the population of ineligible persons is not static and reinforces why the daily and 15-day verification cadences are structurally necessary rather than precautionary. Operators who designed their integration assuming a largely stable ineligible-persons list will need to revisit that assumption.

The Sigap module’s expanding ineligibility categories, from voluntary self-exclusion to welfare recipients to debt-relief programme beneficiaries, mean operators must treat the API as a live compliance gate, not a historical reference lookup.

Mandatory Autolimits: The Structural Departure from European Models

Portaria 2.579 pairs the centralised self-exclusion register with a mandatory autolimit framework that sets Brazil apart from the dominant European model for responsible gambling tools. Under the Brazilian regime, operators must implement self-limit tools covering both time and wagering amounts as part of the account registration process. These limits are not optional add-ons presented after registration, they must be configured at registration.

Players can opt to receive alerts or session blocks based on the duration of their betting activity, and they have the option to temporarily pause their accounts during a defined period. During a pause, the account remains accessible but no wagers may be placed. Operators were given a 90-day implementation period from the Portaria’s operative date to alter their betting systems to support these mandatory self-limit tools, with the implication that any operator going live after that transition window must deploy registration-time autolimits from day one.

This model contrasts with the approach under the Malta Gaming Authority’s Player Protection Directive (Directive 2 of 2018), which requires B2C licensees to ask players whether they wish to set deposit or wagering limits following the registration process and before first deposit, but does not mandate that a limit be set at registration. The MGA model is opt-in at registration, Brazil’s is mandatory-at-registration. The UKGC’s LCCP similarly requires licensees to offer limit-setting tools, and post-White-Paper affordability reforms have moved the UK closer to mandatory engagement with those tools for higher-risk accounts, but the UK has not imposed a blanket mandatory-at-registration autolimit requirement equivalent to Brazil’s.

For operators entering the Brazilian market from European licensing backgrounds, the practical implication is a product change, not a configuration toggle. Registration flows that treat limit-setting as a post-onboarding responsible gambling feature must be re-engineered so that time and wagering limit configuration is built into the KYC and account creation sequence. Platform providers supplying technology to the Brazilian market should confirm whether their RG tooling supports this architecture before operators attempt to satisfy Sigap integration requirements.

How Portaria 2.579 Compares to Global Centralised Self-Exclusion Models

Brazil’s centralised architecture places it in a select group of jurisdictions that have built federal or national-level self-exclusion registers rather than relying on operators to maintain individual lists. The closest comparators are Spain’s Registro General de Interdicciones de Acceso al Juego (RGIAJ), France’s Interdiction Volontaire administered by the Autorité Nationale des Jeux (ANJ), Germany’s OASIS cross-operator exclusion system, and Sweden’s Spelpaus.

The Spanish RGIAJ, operational since 2015 under Ley 13/2011, requires operators to verify against the register at registration and periodically thereafter, structurally analogous to Portaria 2.579’s approach. France’s Interdiction Volontaire carries over 85,000 active registrants and prohibits licensed operators from allowing registered individuals to wager, with obligations flowing through the ANJ licensing conditions. The ANJ model, like Brazil’s, covers advertising restrictions for self-excluded players, though France’s regime applies across sports betting and poker rather than the broader games portfolio covered by Brazil’s lei das bets framework.

Germany’s OASIS system, operated by the gambling authorities of the Länder, carries mandatory cross-operator exclusion and underpins a KYC-at-registration obligation tied to the national identity database. Sweden’s Spelpaus, mandated by Spelinspektionen and now subject to a formalised API connection requirement under SIFS 2026:3, requires real-time API verification rather than manual batch processing, a model that Brazil’s Sigap API structure mirrors closely.

Where Brazil’s model is architecturally distinctive is in its combination of a federal centralised register with the mandatory autolimit obligation at registration. None of the European comparators impose autolimits as a mandatory registration-step requirement of equivalent breadth. The closest European analogue is the UK’s post-White-Paper trajectory under UKGC LCCP reforms, which is moving toward mandatory engagement with financial limits for higher-risk customers, but even that reform stops short of the universal mandatory-at-registration standard that Portaria 2.579 establishes for all Brazilian bettors.

Colombia’s Coljuegos regime, Brazil’s closest Latin American comparator, maintains a single CPF-equivalent centralised player register linked to each bettor’s national identification number. That register functions primarily as an identity and eligibility verification database rather than a self-exclusion engine with the real-time query cadences that Portaria 2.579 mandates through Sigap, and it does not carry the expanding ineligibility categories that the SPA has progressively added to the Módulo de Pessoas Inelegíveis.

Operator Integration Steps and Ongoing Compliance

Operators who have not yet completed full Sigap integration face the most immediate compliance risk, as the platform has been live since 10 December 2025. For operators in the initial authorised cohort who were already integrated at launch, the primary ongoing obligation is maintaining API connectivity and ensuring that the verification cadence, covering registration, daily first-login, and 15-day rolling sweep, continues to function within their production environment.

Compliance teams should conduct a structured review across four areas. The Sigap API integration must be tested end-to-end to confirm that all three verification touchpoints return responses that trigger the correct platform actions: registration refusal, account suspension workflow initiation, or no action where the bettor is not flagged. The account suspension workflow must include automated user notification, balance segregation, and transfer initiation within the two-day window, with exception handling for cases where transfer is not possible. The communications suppression logic must apply the prohibition on targeted advertising and direct notifications immediately on flag receipt, without requiring manual intervention. The five-year documentation archive must be configured to capture the date, time, channel, and content of all user communications associated with ineligible persons actions.

The Novo Desenrola Brasil integration, implemented through Portaria 1,237/2026 and Normativa No. 3/2026, added a new Sigap query response code, “Ineligible, Novo Desenrola Brasil Programme,” to the existing “Blocked, Centralised Self-Exclusion” and welfare-recipient flags. Operators whose Sigap integration was completed before this code was added must verify that their API response-handling logic recognises and correctly processes the new code. A system that only routes known ineligible status codes and passes unrecognised codes to a default “eligible” path represents a material compliance vulnerability.

In practice, operators should structure their Sigap integration as a dedicated compliance middleware layer rather than embedding API calls directly into registration or login flow logic. A middleware approach allows new ineligible status codes to be added to the routing table without requiring platform-level code changes, and it creates a single audit point for all Sigap query records. Given the documented pattern of the SPA expanding the Ineligible Persons Module over successive Portarias, that architectural flexibility is operationally valuable.

For operators licensing the Brazilian market for the first time, particularly those with compliance infrastructure already aligned to Brazil’s federal licensing requirements under the Bets Act, the Sigap responsible gambling integration sits alongside, and in several places intersects with, the same API used for KYC and payment verification. Teams building their initial Sigap integration should map all regulatory query requirements in parallel rather than treating responsible gambling and KYC as separate workstreams, both to avoid duplicate API calls and to ensure that the registration flow sequencing satisfies all obligations simultaneously.

Operators and legal counsel navigating Brazil’s evolving responsible gambling framework should monitor the SPA’s official Federal Gazette publications and the Sigap integration documentation issued by SERPRO. The SPA’s 2026-27 regulatory agenda, currently under consultation, is expected to include further expansion of the Ineligible Persons Module and potentially enhanced reporting requirements tied to Sigap data. Review the SPA’s official website and consult qualified Brazilian legal counsel for jurisdiction-specific application of the Portaria’s obligations, particularly for operators with complex corporate structures involving multiple authorised entities under the same ultimate beneficial owner.

Key Resources

Law No. 14,790 of 29 December 2023 (Lei das Bets), the primary federal statute authorising fixed-odds betting and online gaming and establishing the SPA’s supervisory mandate. Available at planalto.gov.br.

MF Portaria No. 1,330 of 23 August 2024, the primary implementing ordinance covering application procedures, fit-and-proper standards, technical requirements, and financial obligations for authorised operators. Available via the SPA section of gov.br/mf.

SPA/MF Portaria 2.579/2025, the primary responsible gambling instrument establishing the centralised self-exclusion register, Sigap verification cadences, mandatory autolimits, and account suspension obligations. Published in the Diário Oficial da União.

SPA/MF Portaria No. 1,237 of 5 May 2026 and Normativa No. 3 of 5 May 2026, the Desenrola Brasil amendments adding the new Sigap ineligibility category and prescribing operator obligations for Novo Desenrola Brasil programme beneficiaries. Available at in.gov.br.