Le regole del Portogallo sulle slot: cosa deve dimostrare un gioco prima della certificazione

Il Portogallo è uno dei mercati in cui è il gioco stesso, non solo la piattaforma dell’operatore, a essere esaminato rispetto a un insieme scritto di requisiti prima di poter essere offerto. Il Servizio per la Regolazione e l’Ispezione dei Giochi (SRIJ) pubblica il percorso di certificazione e omologazione, e il regolamento tecnico consolidato che ne sta alla base, il Regulamento n.º 903-B/2015, contiene clausole che si leggono come un brief: come si scrivono le regole, in quale lingua, cosa deve vedere il giocatore nel momento della puntata, cosa il gioco non può fare al giocatore e cosa deve dimostrare il generatore di numeri casuali.

Tutto questo pesa soprattutto al momento della commessa. Uno studio che tratta il Portogallo come la traduzione di una build inglese già finita scopre la maggior parte di questi obblighi in fase di certificazione, quando cambiarli costa caro. Un brief che li porta già dentro trasforma la certificazione in una revisione.

Questo articolo riassume i requisiti pubblicati alla data del 10 novembre 2026 e indica cosa dovrebbe quindi chiedere un brief di commessa. È una sintesi di fonti primarie, non un parere legale, e il titolare della licenza resta responsabile della presentazione.

Due passaggi, e solo uno appartiene allo studio

Il SRIJ descrive l’omologazione come dipendente da tre elementi: la certificazione dimostrata del sistema tecnico di gioco, la conformità a ogni specifica richiesta e il pagamento della tassa di omologazione. La certificazione è svolta da organismi riconosciuti a questo scopo dalla Comissão de Jogos, e la pagina del SRIJ ne elenca attualmente nove, dai grandi laboratori internazionali a strutture di test europee più piccole.

La sequenza, quindi, non è “presenta il gioco, ricevi l’approvazione”. Un certificatore riconosciuto esamina il gioco e il sistema che lo circonda; il SRIJ omologa poi sulla base di quella certificazione, della propria verifica dei requisiti e — quando lo ritiene — di test propri. Il SRIJ dichiara apertamente di poter chiedere qualsiasi informazione utile ad analizzare la struttura del sistema e di poter eseguire i test necessari a verificare i requisiti.

La conseguenza pratica per una commessa è che il risultato da consegnare non è soltanto una build. È una build più le prove che un certificatore identificato accetterà, e nessuna delle due parti può essere improvvisata alla fine.

Il tipo di gioco si stabilisce prima dell’artwork

La legge portoghese non concede un permesso generale a offrire qualsiasi gioco uno studio inventi. Le pagine del SRIJ ripetono la stessa frase due volte, sia in quella sulla certificazione sia in quella sull’omologazione: un operatore può sfruttare solo i tipi di gioco d’azzardo indicati nell’articolo 12(1)(d) del Regime Jurídico dos Jogos e Apostas Online (RJO), e solo quando il sistema tecnico è stato certificato e omologato. La certificazione è richiesta ogni volta che un operatore intenda sfruttare un tipo di gioco non ancora certificato, e ogni tipo al di fuori dell’elenco di legge richiede l’autorizzazione della Comissão de Jogos prima ancora di poter essere preso in considerazione.

Per una commessa di slot questa è una questione di perimetro, non una nota legale a margine. Il quadro portoghese classifica una slot online tra le macchine da gioco — il SRIJ pubblica un’istruzione di rendicontazione specifica per le máquinas de jogo online — e un concept che durante lo sviluppo scivola fuori da quella categoria è una presentazione diversa, non una variante. Se il gioco commissionato porta una meccanica che un certificatore potrebbe leggere come un altro tipo, conviene risolverla nel documento di design invece che in una richiesta di chiarimento in certificazione.

Il testo delle regole fa parte della build

Il regolamento richiede che ogni gioco abbia regole e istruzioni, vieta di modificarle durante il gioco e poi specifica il testo nel dettaglio. Le istruzioni devono essere scritte in portoghese, corrette dal punto di vista grammaticale e sintattico, e il portoghese è la lingua di base anche quando se ne offrono altre. Regole e istruzioni devono essere identiche in ogni lingua in cui il gioco viene distribuito, disponibili senza dover giocare e accessibili su ogni pagina della presenza internet legata al gioco.

Tre ulteriori obblighi stanno nella stessa clausola. Il nome del gioco deve essere visibile nel momento in cui il giocatore punta. Le regole devono indicare ogni premio potenziale e il premio massimo possibile per unità di puntata, il che rende la paytable e il testo delle regole un unico artefatto sottoposto a revisione invece di due. E ogni pulsante di azione deve riportare la propria funzione sull’etichetta del pulsante stesso.

È un percorso di produzione diverso dal solito, in cui l’interfaccia viene distribuita in inglese e il testo delle regole si redige dalla paytable finita. Qui il testo portoghese delle regole è un input di progettazione: deve descrivere la paytable che la build implementa davvero, nella lingua del mercato, prima che le stringhe dell’interfaccia siano congelate.

Le clausole di equità vincolano il design, non solo la matematica

La parte più citata del Regulamento n.º 903-B/2015 è la sezione sull’equità, ed è insolitamente specifica sulla presentazione. I giochi devono trasmettere informazioni accurate sulle possibilità di vincita ed esporre, con precisione, ogni esito possibile di ciascun gioco. Un gioco deve rendere chiaro se il giocatore può influire sul risultato, e un gioco il cui esito è casuale deve essere realmente in grado di produrre qualsiasi risultato a ogni partita.

Ne derivano due divieti che toccano l’artwork quanto il modello. Il regolamento stabilisce che i concetti di near-miss — qualsiasi azione del sistema che dia al giocatore l’impressione di essersi avvicinato a una vincita — non sono considerati equi e corretti. E i giochi che danno al giocatore la percezione di un controllo su un esito che non controlla non sono ammessi, a meno che il giocatore sia stato adeguatamente informato che la sua scelta non ha alcuna influenza.

Il regolamento chiude anche il cerchio sull’adattamento. Il ritorno al giocatore del gioco non può essere manipolato dal sistema né da interventi manuali per mantenere un ritorno costante, e i giochi non possono adattarsi al comportamento del giocatore — con una stretta eccezione per i giochi metamorfici in cui il giocatore sia stato adeguatamente informato. La stessa clausola richiede che i giochi funzionino indipendentemente dall’apparecchiatura e dal canale di comunicazione del giocatore, il che riguarda tanto il piano di prestazioni su mobile quanto il fascicolo di conformità.

Due clausole di supporto completano il quadro. I giochi dimostrativi devono avere le stesse caratteristiche del gioco con denaro reale e devono presentare la possibilità di vincere correttamente e in equilibrio, quindi una modalità di gioco gratuito non è il posto in cui far sembrare la vincita più facile. E il tempo concesso al giocatore per prendere una decisione è fissato dall’operatore ma non può essere inferiore a tre secondi, il che esclude le configurazioni di gioco automatico più rapide che alcuni mercati tollerano.

Lo schermo fa parte dell’insieme dei requisiti

Una sezione separata disciplina la presentazione e si legge come una specifica di interfaccia. Il nome del gioco deve essere visibile su tutte le pagine legate al gioco. Il saldo del giocatore deve essere mostrato o facilmente accessibile. La puntata in corso deve essere indicata insieme alla puntata unitaria e alla puntata totale. Quando il risultato può essere influenzato da fattori fuori dal controllo del giocatore, il sistema deve avvertirlo e rimandare alle informazioni che lo spiegano. Un orologio deve mostrare da quanto tempo il giocatore sta giocando, con un’eccezione per i giochi distribuiti tramite telefoni e dispositivi con capacità di visualizzazione altrettanto limitata.

Le clausole sulle azioni aggiungono la puntata corrente e le opzioni di puntata disponibili, tutti i premi possibili e le combinazioni di premi presentate graficamente, e la puntata massima e minima indicate con chiarezza. I risultati devono essere presentati in modo chiaro e inequivocabile e restare sullo schermo per un periodo adeguato, e i premi devono essere mostrati con la stessa chiarezza.

Nulla di tutto ciò è esotico, ma ogni riga è un componente di interfaccia con un costo di localizzazione e un caso di test. Un brief che li elenca come criteri di accettazione li fa costruire una volta sola, nel posto giusto, invece di aggiungerli a posteriori su quattro schermate.

Stato, interruzione e disattivazione

Il regolamento dà per scontato che i giocatori vengano interrotti. Il sistema deve poter attivare e disattivare un singolo gioco, tutti i giochi e l’attività di gioco di un singolo giocatore, e ogni attivazione e disattivazione deve essere registrata. Un gioco disattivato non deve essere mostrato, e un giocatore con una partita in corso deve poterla terminare; quando un gioco a più stati non può essere concluso, il giocatore deve poterlo completare al login successivo, oppure deve essergli spiegato perché no.

La clausola sui giochi incompleti elenca i casi che devono essere recuperabili: perdita delle comunicazioni, riavvio del sistema, spegnimento e riaccensione dei giochi, riavvio del dispositivo del giocatore e chiusura anomala del client o del server. Dopo la riconnessione il sistema deve mostrare i giochi incompleti e consentire al giocatore di completarli, e deve tenerne conto.

Per una slot commissionata questo è un requisito architetturale sul gioco, non solo sulla piattaforma: lo stato del gioco deve essere abbastanza durevole da poter essere ripreso dal lato client di un guasto di socket, e le prove di garanzia devono mostrare che ciò accade, non limitarsi ad affermarlo.

Jackpot e generatore di numeri casuali

Quando un jackpot fa parte del design, gli obblighi di rendicontazione sono precisi. Il valore visualizzato deve essere aggiornato sul dispositivo di ogni giocatore partecipante almeno ogni 30 secondi. Un vincitore deve essere avvisato immediatamente, e ogni giocatore partecipante deve essere informato del valore una volta che il jackpot è stato attivato. Il sistema deve conservare un registro di controllo dettagliato di ciascun jackpot con data e ora, configurazione, contributi, attivazioni, premi e identità del personale che ha avuto accesso al sistema, su uno storage ridondante e tollerante ai guasti, e deve essere possibile ricostruire valori e premi a partire dai contributi dei giocatori. Un jackpot discontinuo deve essere mostrato chiaramente come non disponibile, e le informazioni sul ritorno al giocatore devono restare corrette indipendentemente dal fatto che il jackpot sia disponibile o meno per quel giocatore.

I requisiti sul generatore di numeri casuali sono la parte che a uno studio viene più spesso chiesto di dimostrare dall’esterno. I risultati dei giochi d’azzardo devono basarsi su un RNG insieme alle sue funzioni di supporto — seed, mappatura, mescolamento. Il generatore deve essere riconoscibilmente una fonte crittograficamente sicura. Il suo output deve superare la suite DIEHARD, la suite di test statistici NIST o un equivalente, produrre risultati statisticamente indipendenti con una deviazione standard statisticamente rilevante ed essere imprevedibile per chiunque non conosca l’algoritmo, l’implementazione e il seed corrente.

Uno studio che ha sempre e solo descritto il proprio RNG come “provably fair” qui non ha nulla da consegnare a un certificatore. La prova è un rapporto di test rispetto a una suite identificata, su una build identificata.

Cosa deve chiedere il brief

I requisiti si traducono in un elenco di consegne che può essere scritto in una commessa prima del primo sprint: il testo portoghese delle regole e le stringhe dell’interfaccia come sorgente revisionato, non come attività di traduzione; la paytable che il testo delle regole descrive, con il premio massimo per unità di puntata indicato; le etichette delle funzioni dei pulsanti e i componenti di visualizzazione richiesti dalle clausole sulla presentazione; una dichiarazione di design su near-miss, percezione di controllo e adattamento comportamentale; il design del recupero dello stato con le relative prove di test per i casi di interruzione elencati dal regolamento; il rapporto di test dell’RNG rispetto a DIEHARD, NIST o un equivalente; e, quando un jackpot rientra nel perimetro, il design della rendicontazione e della ricostruzione con il suo aggiornamento ogni 30 secondi.

Due cose vale la pena dirle chiaramente a chi acquista. La prima è che questo è un insieme di requisiti portoghese, e un gioco costruito per quattro mercati deve soddisfare il testo di ciascuno — l’argomento della build localizzata è sviluppato nella nostra guida alle prove di certificazione per un gioco localizzato, e la sequenza di un lancio multi-mercato nel nostro piano di lancio per più giurisdizioni. La seconda è che il percorso di certificazione non è una formalità che segue una build finita: le prove devono esistere, in una forma verificabile, mentre la build è ancora modificabile. La nostra guida alla presentazione della certificazione spiega come si compone quel dossier, e la guida all’architettura di una piattaforma jackpot tratta il ciclo di rendicontazione dal lato piattaforma.

Se stai commissionando un gioco Engine per un mercato regolamentato e vuoi che la build e le sue prove siano pianificate insieme, richiedi un preventivo di progetto: il brief può portare con sé l’insieme di requisiti del mercato fin dalla prima pagina.

Le domande che fanno gli acquirenti

Basta tradurre in portoghese una build inglese già certificata?

No. Il regolamento richiede che le regole e le istruzioni del gioco siano scritte in portoghese, corrette dal punto di vista grammaticale e sintattico, con il portoghese come lingua di base anche quando se ne offrono altre, e che le regole siano identiche in ogni lingua in cui il gioco viene distribuito. Richiede inoltre che le regole indichino ogni premio potenziale e il premio massimo possibile per unità di puntata, quindi il testo deve descrivere la paytable che la build portoghese implementa davvero, non quella da cui è stata tradotta.

Certificare un gioco copre anche la slot successiva dello stesso studio?

No. La certificazione si riferisce al sistema tecnico e ai tipi di gioco sfruttati: il SRIJ richiede la certificazione ogni volta che un operatore intenda sfruttare un tipo di gioco non ancora certificato o omologato, e ogni tipo al di fuori dell’elenco di legge richiede prima l’autorizzazione della Comissão de Jogos. Un nuovo titolo è una nuova presentazione, anche quando condivide il motore.

Le animazioni di anticipazione sono ammesse?

Il regolamento vieta i concetti di near-miss — qualsiasi azione del sistema che dia al giocatore l’impressione di essersi avvicinato a una vincita — e li considera né equi né corretti. Un’animazione che si limita ad anticipare un esito già determinato non è la stessa cosa di una costruita per simulare un near-miss, ma la distinzione deve essere difendibile nel documento di design e visibile nella build, non argomentata dopo che un certificatore l’ha sollevata.

Chi può certificare un gioco per il Portogallo?

La certificazione è svolta da organismi riconosciuti a questo scopo dalla Comissão de Jogos, e il SRIJ pubblica l’elenco aggiornato nella propria pagina sulla certificazione — nove organismi al momento della stesura, tra cui i grandi laboratori internazionali e diverse strutture di test europee. Dimostrare quella certificazione è uno dei requisiti per l’omologazione, che il SRIJ concede poi dopo la propria verifica dei requisiti e gli eventuali test che decide di eseguire.

Si può riutilizzare un certificato RNG ottenuto in un altro mercato?

Non come sostituto delle prove richieste da questo quadro. Il regolamento richiede che i risultati si basino su un generatore crittograficamente sicuro, testato rispetto alla suite DIEHARD, alla suite di test statistici NIST o a un equivalente, con output statisticamente indipendente, una deviazione standard statisticamente rilevante e imprevedibilità senza l’algoritmo, l’implementazione e il seed corrente. Se un rapporto esistente soddisfi tutto ciò dipende dalla suite, dalla build che copre e dal giudizio del certificatore: per questo il rapporto appartiene al brief, non a una cartella scoperta al momento della presentazione.