Building the UKGC Net Position and Session Clock

The UKGC net position display and the session clock are two small features: show the player's net position for the session in the currency of their account or product, and show elapsed time for the whole session, on every casino game except peer-to-peer poker. Both have applied to all casino games, not just slots, since 17 January 2025, so most teams are fixing a live lobby, not planning new work. Luminbrane wrote this as a build guide because the rules are short and the ambiguity around them is where sprints get lost.

• Short answer: Build one session-level net position and one timer, owned at the wallet and shell level, and write down every session decision before anyone opens a ticket.
• First step: Put the two requirements on one page and send your open questions to your test house and game suppliers this week.
• The goal: One number and one clock that behave the same in every game in the lobby, with a written decision behind each edge case.

Tips: Write the session definition as a one-paragraph decision record before you design anything. Every later argument with a studio, a test house or your own QA team becomes a question of whether the build matches the paragraph.

Key takeaways

Net position and the session clock are small features with expensive ambiguity. The cheapest compliant build is a single session-level number and a single timer, owned at the wallet and shell level, and agreed with certification and suppliers before the work is ticketed.

Point	Detail
Scope	Both displays apply to all casino games except peer-to-peer poker and have done since 17 January 2025 (slots were covered earlier), so most teams are fixing live products.
Session	A session begins when real-money play starts and ends when the player exits, and every edge case (reconnects, game switching, idle tabs) needs a written decision.
Where the text is open	RTS 13C lets the timer start when the game opens or when play begins, so the choice is yours and should be made once, in writing.
Ownership	Whoever holds the wallet and the session should own the number, which pushes the build towards the operator or platform layer rather than each studio's client.
Sequencing	Questions to certification and game suppliers cost a day now and a sprint later, so ask them before the build starts.

Contents

• Step 1: Turn the two rules into a one-page spec
• Step 2: Decide what a session is
• Step 3: Define what net position counts, and keep it at wallet level
• Step 4: Place the display and set its update behaviour
• Step 5: Settle who owns it: operator, aggregator or studio
• Step 6: Ask certification and your suppliers before the sprint
• Step 7: Test it live and keep it from drifting
• Frequently asked questions
• Sources

Step 1: Turn the two rules into a one-page spec

The two rules reduce to this: show net position from the start of the session, in the currency of the player's account or product, and show elapsed time for the entire gaming session. Both cover all casino games except peer-to-peer poker. Net position is RTS 2E, the clock is RTS 13C, and they are separate requirements with separate triggers and units.

The Gambling Commission changes took effect on 17 January 2025, as one of six game design changes, and the summaries we found state no grace period. The related changes sit in the same package: spin stop (14E), the 5-second minimum (14G), autoplay (RTS 8), win effects (14F) and simultaneous play (14C). Treat them as neighbours. Your net position figure will sit right next to the things those rules govern.

There is a head start for some teams. Net position and elapsed time already applied to slots before the extension to other casino products. If your slots already show both, you are extending a pattern to table games, instant games and live products, not inventing one. If your slots show them only inside each studio's client, expect the extension to expose the cost of that choice.

The poker exclusion is worth a sentence. CMS's summary of the consultation says peer-to-peer poker is out because Patterns of Play research found it a lower-cost activity over time than slots and other casino products. For your estimate, that means a poker room on the same platform needs no display, but a banked casino table next door does.

The spec fits on a page:

	Net position (RTS 2E)	Elapsed time (RTS 13C)
What is shown	The player's net position for the session	Time elapsed in the gaming session
Currency or unit	Currency of the account or product	Seconds, minutes and hours
Runs from	The start of the session	Game open or start of play, your choice
Shown for	The session, through play	The entire gaming session
Scope	All casino games	All casino games
Out of scope	Peer-to-peer poker	Peer-to-peer poker

Estimate from this table, not from the legal summaries. The table makes the work visible: a stored session start, a running total, a currency, a formatter, and a place on screen.

Step 2: Decide what a session is

A session begins when real-money play starts and ends when the player exits. That is the whole definition in the published summary, and everything else is a decision your team has to make and record. The only choice the regulator hands you explicitly is the clock start: RTS 13C allows it at game open or when play begins.

Our default is to start both the clock and the net position at the first real-money wager, so one start timestamp serves both. The cost is honest: a player who opens a game and watches the lobby sees no clock yet. The rule allows it, and one timestamp is much cheaper to test than two.

Work through these in order and write each answer down:

1. Pick the clock start. Game open or first real-money bet. Choose once, use the same one in every game, and record why.
2. Treat demo as outside the session. Demo play is not real-money play, so the session starts on the first real-money wager. Decide what the display shows when a player moves from demo to real money mid-game: the clock and net position should both start at zero at that moment.
3. Decide whether a session spans games. The guidance reads per game: the clock starts when a game is opened. One session across your lobby is cheaper to build, but it is an interpretation, so agree it with your test house before you build it (see Step 3).
4. Survive reconnects. If the connection drops and the player returns to the same wallet session within your timeout, continue the same session. Store the start time server-side so a refresh cannot reset it.
5. Count idle tabs by timestamp. Compute elapsed time from the stored start, not from a counter in the browser. Backgrounded tabs throttle timers, and a clock that stops while a tab sleeps will show the wrong time on return.
6. Define exit. Explicit logout, closing the game, and a server-side inactivity timeout should all end the session. Pick the timeout number with your compliance lead and write it down.

None of items 2 to 6 is settled by the text we have read, so confirm them with your test house in Step 6. The point of writing them down now is that a defensible default beats a different guess in each studio's client.

Step 3: Define what net position counts, and keep it at wallet level

Net position must be shown from the start of the session, in the currency of the account or product, and it has to survive many game cycles and, on a multi-game platform, many games. The cheapest way to get that is to compute it from wallet movements for the session, not inside each game. The wallet already sees every debit and credit, in one currency, in order.

Be clear about which part is interpretation. The Commission does not define a gaming session, and its guidance points to one per game: RTS 13C starts the clock when the game is opened, and the Wiggin summary says a session ends when the player exits the game. In the 2021 consultation, operators proposed a session spanning the whole site, and the Commission did not adopt it.

Per game is the reading the guidance supports. One figure across games is our proposed interpretation: cheaper to build, but something to confirm with your test house, not to assume.

If your test house accepts a cross-game session, it has a real advantage for players. Per-game figures create a trap. A player who moves between three games would see three numbers and have to add them up, which defeats the point of a display meant to show where they stand. One figure, visible everywhere, is easier to explain and easier to test.

The harder part is what feeds the number. The text does not walk through every product's money flows, so list the inputs and settle each one with certification. We wrote about what a single wallet costs for casino and sportsbook.

Input	Question to settle	Cheap default	Confirm with
Wagers and wins	Net of stake and return, per round?	Wallet debits minus credits for the session	Test house
Bonus funds	Do bonus-funded wagers and wins count?	Count all real-money-equivalent movements	Test house
Voided or refunded rounds	Reverse the entry or show the refund?	Follow the wallet ledger	Test house and studio
Jackpot and feature wins	Counted when credited or when triggered?	When credited to the wallet	Studio
Currency conversion	Is any game played in a different currency?	Show account currency only	Platform team

Every row in the "Cheap default" column is a proposal, not a ruling. The point of the table is that each default has a named person to check it with.

What goes wrong if you skip this: two games report the same round differently, the net position drifts from the wallet balance, and the first person to notice is a player with a screenshot.

Step 4: Place the display and set its update behaviour

Both figures have to be visible through the session, so placement is a layout problem inside every game's chrome. Draw them in the shell, outside the game canvas, in a fixed strip that does not move with game content. Then decide when the net position changes relative to the round outcome, and test that decision with real players.

The shell approach matters because games arrive with their own layouts. If each studio places the display, you get as many positions as you have suppliers, and a regression in any client breaks the rule for that game. A shell strip is one component, one design, one test.

Some practical rules for the layout:

• Keep both figures in one strip. Net position and clock side by side, same typography, same baseline, so players learn where to look once.
• Design for the smallest phone first. A compact strip with a currency symbol, a signed amount and a time in hours, minutes and seconds has to stay legible in landscape and portrait, and must not cover the stake controls or the spin button.
• Show the clock in a readable unit. RTS 13C gives seconds, minutes and hours, so a single h:mm:ss format covers it.
• Update net position when the outcome is revealed. Changing it before the reels stop would spoil the result and invite a slam stop. 14E bans turbo, quick spin and slam stop, so the number should never beat the animation.
• Do not celebrate the number. 14F covers win effects at or below stake. A flash, a bounce or a colour pulse on the net position when a return is below stake could read as a win effect. Our reading is to keep it static and neutral. Confirm it with your test house.
• Respect the minimum round times. 14D sets 2.5 seconds for slots and 14G sets 5 seconds for other casino games. The display should not make a round feel shorter or longer than those timings allow.

Tips: Test update timing with a clickable prototype and five players before you build. Sequence and animation timing are the cheapest things to change in a prototype and the most expensive to change after certification.

Ship the strip behind a switch if you must, but remember that a flag does not make a change minor in the eyes of the regulator. We covered that in why feature flags do not make an update minor.

Step 5: Settle who owns it: operator, aggregator or studio

The party that holds the wallet and the session should own the number. In practice that means the operator or the platform layer, because they see every game and every movement. An aggregator can own it for its own catalogue. A studio can own it only for its own games, which is the weakest option for a multi-supplier lobby.

Model	Who builds it	Cost	Certification risk	Best for
Operator or platform	Your shell and wallet service	One build, one test pass	Lowest: one implementation to certify	Multi-supplier lobbies
Aggregator	The aggregator's wrapper	Low if the contract covers it	Medium: you depend on their release cycle	Lobbies that mostly use one aggregator
Studio	Each game's client	Highest: one build per game	Highest: many implementations, many drift points	Single-studio operators or own-brand games

The operator model costs you a build, but it is the only one where a change to the rule is a change in one place. With the studio model, a rule change means waiting on every supplier's roadmap.

There are honest exceptions. A studio with its own client may still need to expose session data, such as round results and round identifiers, or accept a figure from your shell. An aggregator may already pass a session wrapper and handle part of this. Ask what each supplier can send and receive before you decide that the shell can do it alone.

If you are the studio, the position is different: your operators will increasingly expect you to accept or expose session data, and a client that cannot do that is a harder sell.

Luminbrane is a small Stockholm product and UX consultancy, and we announced a strategic partnership with the Derivco Group. Platform-level features like this one tend to be decided between product, wallet and shell teams, and the design work is mostly about agreeing where the number lives. For a multi-supplier operator, our advice is the same as the table's: build it once, in your own layer.

Step 6: Ask certification and your suppliers before the sprint

Rework comes from assumptions nobody checked, so ask the test house, your aggregator and each studio a short list of questions before the sprint starts. Order them by how much rework a wrong answer causes. An answer costs a day now, and a wrong guess costs a sprint later.

Send these, in this order:

1. Test house: is one session-level net position acceptable across games? This is the biggest architecture question. A no here changes the whole plan.
2. Test house: which events feed the figure? Bonus funds, voids, refunds, jackpots and promotional wins from the Step 3 table, with an answer for each.
3. Test house: is our session definition acceptable? Send the decision record from Step 2, including the clock start, reconnect rule and exit rule.
4. Test house: how do you want to see the display tested? Ask for the evidence they expect, so your staging tests produce it.
5. Aggregator: who builds the display for your games, and what can you pass us? Get it in writing, with a release date.
6. Each studio: can your client accept an external figure, or expose round data? Ask this per game family, because answers differ.
7. Each studio: how do your win effects interact with an external net position strip? This ties back to 14F and the spin timings in 14D, 14E and 14G.

Tips: Send the question list as a single numbered document, not as scattered emails. Suppliers answer a numbered list; they lose a thread.

Then fit the answers into the plan. We wrote about why certification needs its own lane on your roadmap. Put the questions at the start of the lane, the build in the middle, and the evidence pack at the end. If a supplier will not answer by a date, record that as a risk, not as silence.

Step 7: Test it live and keep it from drifting

A correct build can break the next time a game, a wallet call or a reality check changes. Test the behaviours below in staging and again in production, and automate the ones that can be automated so a change to anything nearby fails a check before it fails a player.

The clock has a close relative. RTS 13B reality checks also show elapsed time since session start. They let the customer set the interval and require acknowledgement, should link to account history, and block new funds or autoplay until acknowledged, with an exception partway through multi-state games such as blackjack. They are not the same feature, but they must agree. If the always-on clock says 47 minutes and the reality check says 52, you have a defect and a compliance question.

Regression checks worth keeping:

• One start, two readers. The clock and the reality check should read the same stored session start. Add a test that fails if they diverge by more than a second.
• Net position equals the ledger. At the end of a scripted session, the displayed figure should equal wallet credits minus debits. Run this in staging on every release.
• Reconnect and refresh. Drop the connection, refresh the page and switch devices if you support it. The clock should continue and the net position should hold.
• Game switching. Move between games from different suppliers mid-session. The figure should carry across without a reset.
• Backgrounded tabs. Leave a tab idle for several minutes and return. The clock should show true elapsed time.
• Demo to real money. Start in demo, switch to real money, and check that both displays start at that moment.
• Reality check overlay. Trigger one and confirm the strip stays visible or returns correctly after acknowledgement.
• Neighbouring rules. Re-test spin stop, autoplay and win effects after any shell change, because the strip sits beside them.
• New game onboarding. Add the display check to the checklist for every new supplier game before it goes live.

The same discipline applies to money-adjacent checks elsewhere in the flow. We wrote about where the FRA check belongs in your deposit flow.

Frequently asked questions

Which casino games need a net position and session clock? All casino games except peer-to-peer poker. That covers slots, table games and other casino products, whichever supplier provides them. Slots were already covered by RTS 2E and RTS 13C before the extension.

When did the net position and elapsed time requirements start to apply? They took effect on 17 January 2025, as part of six remote game design changes. The summary we read states no grace period, so a live product that lacks them is already behind.

Does the session timer start when the game opens or when the first bet is placed? Either. RTS 13C allows the timer to start when the game opens or when play begins. Pick one, apply it to every game, and record the reason. We suggest the first real-money bet, so the clock and net position share a start.

Does peer-to-peer poker need a net position display? No. Peer-to-peer poker is excluded from both requirements. CMS's summary of the consultation says Patterns of Play research found it a lower-cost activity over time than slots and other casino products.

Who is responsible for the display when games come from an aggregator? The licensee is the one who answers to the regulator, so settle the split in writing. The cheapest build for a multi-supplier lobby is at the operator or platform layer, where the wallet and session live. Ask the aggregator what it already provides before you decide.

Is the session clock the same thing as the reality check? No. The clock under RTS 13C is a continuous display of elapsed time. Reality checks under RTS 13B are periodic prompts that the player sets, acknowledges and can follow to account history. Both show elapsed time since session start, so they should read from the same session start.

Sources

• Wiggin: Remote game design changes: taking effect 17 January 2025
• UK Gambling Commission: RTS 13 Time requirements and reality checks
• UK Gambling Commission: RTS 14 Responsible product design
• CMS: Gambling White Paper Consultations: Remote Game Design

Recommended

• Single Wallet for Casino and Sportsbook: What It Costs
• Certification Needs Its Own Lane on Your Roadmap
• Feature Flags Don't Make an Update Minor
• Where the UKGC's FRA Check Belongs in Your Deposit Flow