Portugal is one of the markets where the game itself, not just the operator’s platform, is examined against a written set of requirements before it can be offered. The Service for Regulation and Inspection of Games (SRIJ) publishes the certification and homologation route, and the consolidated technical regulation behind it, Regulamento n.º 903-B/2015, contains clauses that read like a brief: how rules are written, which language they use, what the player must see at the moment of betting, what the game may not do to the player, and what the random number generator has to demonstrate.
That matters most at commissioning time. A studio that treats Portugal as a translation of a finished English build discovers most of these obligations at certification, when changing them is expensive. A brief that already carries them turns certification into a review.
This article summarises the published requirements as of 10 November 2026 and sets out what a commissioning brief should therefore ask for. It is a summary of primary sources, not legal advice, and the licence holder remains responsible for the submission.
Two gates, and only one of them belongs to the studio
The SRIJ describes homologation as depending on three things: demonstrated certification of the technical gaming system, compliance with every required specification, and payment of the homologation fee. Certification is performed by bodies recognised for the purpose by the Comissão de Jogos, and the SRIJ page currently lists nine of them, from the large international labs to smaller European test houses.
So the sequence is not “submit the game, receive approval”. A recognised certifier examines the game and the system around it; SRIJ then homologates on the strength of that certification, its own review of the requirements, and — where it chooses — tests of its own. The SRIJ states plainly that it may request any information relevant to analysing the system’s structure and may carry out the tests needed to verify the requirements.
The practical consequence for a commission is that the deliverable is not a build alone. It is a build plus the evidence a named certifier will accept, and neither part can be improvised at the end.
The game type is settled before the art is
Portuguese law does not license a general permission to offer any game a studio invents. The SRIJ’s pages repeat the same sentence twice, on both the certification and homologation pages: an operator may only exploit the types of game of chance set out in article 12(1)(d) of the Regime Jurídico dos Jogos e Apostas Online (RJO), and only where the technical system has been certified and homologated. Certification is required whenever an operator intends to exploit a game type that has not yet been certified, and any type outside the statutory list needs authorisation from the Comissão de Jogos before it can be considered at all.
For a slot commission this is a scoping question, not a legal footnote. The Portuguese framework files an online slot under machine games — the SRIJ publishes a reporting instruction specifically for máquinas de jogo online — and a concept that drifts outside that category during development is a different submission, not a variation. If the commissioned game carries a mechanic that a certifier could read as a different type, that is worth resolving in the design document rather than in a certification query.
The rule text is part of the build
The regulation requires every game to have rules and instructions, forbids changing them during play, and then specifies the text in detail. Instructions must be written in Portuguese, grammatically and syntactically correct, and Portuguese is the base language even when other languages are offered. Rules and instructions must be the same in every language the game ships, available without playing, and accessible on every page of the internet presence related to the game.
Three further obligations sit inside the same clause. The game’s name has to be visible at the moment the player is betting. The rules must state every potential prize and the largest possible prize per unit bet, which makes the paytable and the rule text a single reviewed artefact rather than two. And every action button has to be labelled with its function on the button itself.
That is a different production path from the usual one, where the interface ships in English and the rule text is drafted from the finished paytable. Here the Portuguese rule text is a design input: it has to describe the paytable the build actually implements, in the language of the market, before the interface strings are frozen.
The fairness clauses constrain design, not just maths
The most quoted part of Regulamento n.º 903-B/2015 is the fairness section, and it is unusually specific about presentation. Games must convey accurate information about the possibilities of winning and set out, precisely, every possible outcome of each game. A game must make it clear whether the player can influence the result, and a game whose outcome is random must genuinely be capable of producing any result each time it is played.
Two prohibitions follow that touch the art as much as the model. The regulation states that near-miss concepts — any action by the system that gives the player the impression of having come close to a win — are not considered fair and correct. And games that give the player the perception of control over an outcome they do not control are not permitted unless the player has been properly informed that their choice has no influence.
It also closes the loop on adaptation. The game’s return to the player may not be manipulated by the system or by manual interference to hold a constant return, and games may not adapt to the player’s behaviour — with a narrow exception for metamorphic games where the player has been properly informed. The same clause requires that the games work independently of the player’s equipment and communication channel, which reaches the mobile performance plan as well as the compliance file.
Two supporting clauses complete the picture. Demonstration games must have the same characteristics as the real-money game and must present the chance of winning correctly and in balance, so a free-play mode is not a place to make winning look easier. And the time a player is given to take a decision is set by the operator but may not be less than three seconds, which rules out the fastest auto-play configurations that some markets tolerate.
The screen is in the requirement set
A separate section governs presentation, and it reads like an interface specification. The game’s name must be visible on all game-related pages. The player’s balance must be displayed or easily accessible. The bet being placed must be shown along with the unit bet and the total bet. Where the result can be affected by factors outside the player’s control, the system must warn the player and link to the information that explains it. A clock must show how long the player has been playing, with an exception for games delivered through phones and devices with similarly limited display capacity.
The action clauses add the current bet and the available bet options, all possible prizes and prize combinations presented graphically, and the maximum and minimum bet stated clearly. Results must be presented clearly and unambiguously and held on screen for an adequate period, and prizes must be shown with the same clarity.
None of this is exotic, but each line is a UI component with a localisation cost and a test case. A brief that lists them as acceptance criteria gets them built once, in the right place, instead of retrofitted across four screens.
State, interruption and deactivation
The regulation assumes players will be interrupted. The system must be able to activate and deactivate an individual game, all games, and a single player’s game activity, and every activation and deactivation must be logged. A deactivated game must not be shown, and a player with a game in progress must be able to finish it; where a multi-state game cannot be finished, the player must be able to complete it at the next login, or be told why not.
The incomplete-game clause lists the cases that must be recoverable: loss of communications, a system restart, games switched off and on, a restart of the player’s device, and an abnormal shutdown of the client or server. After reconnection the system must show the incomplete games and let the player complete them, and it must account for them.
For a commissioned slot this is an architecture requirement on the game, not only on the platform: the game’s state has to be durable enough to be resumed from the client side of a socket failure, and the assurance evidence has to show it happening rather than assert it.
Jackpots and the random number generator
Where a jackpot is part of the design, the reporting obligations are precise. The displayed value must be updated on every participating player’s device at least every 30 seconds. A winner must be notified immediately, and every participating player must be told the value once it has been triggered. The system must keep a detailed audit record of each jackpot covering date and time, configuration, contributions, triggers, prizes, and the identity of staff who accessed the system, held on redundant fault-tolerant storage, and it must be possible to reconstruct values and prizes from player contributions. A discontinued jackpot must be shown clearly as unavailable, and the return-to-player information must stay correct whether or not the jackpot is available to that player.
The random number generator requirements are the part a studio is most often asked to prove from outside. Results of games of chance must be based on an RNG together with its supporting functions — seed, mapping, shuffling. The generator must be recognisably a cryptographically secure source. Its output must pass the DIEHARD suite, the NIST statistical test suite or an equivalent, produce statistically independent results with a statistically relevant standard deviation, and be unpredictable to anyone without knowledge of the algorithm, the implementation and the current seed.
A studio that has only ever described its RNG as “provably fair” has nothing to hand a certifier here. The evidence is a test report against a named suite, on a named build.
What the brief should ask for
The requirements translate into a delivery list that can be written into a commission before the first sprint: the Portuguese rule text and interface strings as reviewed source, not a translation task; the paytable the rule text describes, with the maximum prize per unit bet stated; the button-function labels and the display components the presentation clauses require; a design statement on near-miss, control perception and behavioural adaptation; the state-recovery design and its test evidence for the interruption cases the regulation lists; the RNG test report against DIEHARD, NIST or an equivalent; and, where a jackpot is in scope, the reporting and reconstruction design with its 30-second refresh.
Two things are worth saying plainly to a buyer. The first is that this is a Portuguese requirement set, and a game built for four markets has to satisfy each market’s own text — the localised build argument is made at length in our guide to localised game certification evidence, and the sequencing of a multi-market release in our release plan for several jurisdictions. The second is that the certification route is not a formality that follows a finished build: the evidence has to exist, in a reviewable form, while the build is still changeable. Our certification submission guide sets out how that dossier is assembled, and the jackpot platform architecture guide covers the reporting loop on the platform side.
If you are commissioning an Engine game for a regulated market and want the build and its evidence planned together, request a project quote — the brief can carry the market’s requirement set from the first page.
Questions buyers ask
Is translating a certified English build into Portuguese enough?
No. The regulation requires the game’s rules and instructions to be written in Portuguese, grammatically and syntactically correct, with Portuguese as the base language even when other languages are offered, and the rules must be identical in every language the game ships. It also requires the rules to state every potential prize and the largest possible prize per unit bet, so the text has to describe the paytable the Portuguese build actually implements rather than the one it was translated from.
Does certifying one game cover the next slot from the same studio?
No. Certification attaches to the technical system and to the game types being exploited: the SRIJ requires certification whenever an operator intends to exploit a game type that has not yet been certified or homologated, and any type outside the statutory list needs authorisation from the Comissão de Jogos first. A new title is a new submission, even when it shares an engine.
Are anticipation animations allowed?
The regulation prohibits near-miss concepts — any action by the system that gives the player the impression of having come close to a win — and treats them as neither fair nor correct. An animation that is merely anticipation of a resolved outcome is not the same thing as one built to simulate a near-miss, but the distinction has to be defensible in the design document and visible in the build, not argued after a certifier raises it.
Who can certify a game for Portugal?
Certification is carried out by bodies recognised for the purpose by the Comissão de Jogos, and the SRIJ publishes the current list on its certification page — nine bodies at the time of writing, including the large international laboratories and several European test houses. Demonstrating that certification is one of the requirements for homologation, which the SRIJ then grants after its own review of the requirements and any tests it decides to run.
Can an RNG certificate from another market be reused?
Not as a substitute for the evidence this framework asks for. The regulation requires results to be based on a cryptographically secure generator, tested against the DIEHARD suite, the NIST statistical test suite or an equivalent, with statistically independent output, a statistically relevant standard deviation, and unpredictability without the algorithm, implementation and current seed. Whether an existing report satisfies that depends on the suite, the build it covers and the certifier’s judgement — which is why the report belongs in the brief, not in a folder discovered at submission.
