iGaming Back Office: Permissions, Approvals and Audit Evidence

A support agent sees a missing credit. Finance wants to correct it. A supervisor approves the request, but the response disappears and the agent clicks again. If the back office cannot distinguish an approved correction from its retry, an ordinary service case can create money twice. If the approval was for a different amount, the activity log may look reassuring while recording the wrong outcome.

The design question is therefore more precise than “which screens do staff need?” It is: who may propose an action, against which records, who may authorise it, and which system commits the effect? This guide follows a balance correction through those decisions, then applies the same discipline to player investigation, exports and configuration. The amounts are illustrative; they are not recommended approval limits.

Keep the back office inside the platform’s authority boundaries

Use the back-office capability overview and platform capabilities overview to define the operating surface: support cases, account investigation, finance, risk, configuration and reporting. Then identify the service that owns each decision. The wallet or ledger service owns money movements; account services own account transitions; the verification process owns its review outcomes. A staff screen may bring those facts together without acquiring permission to edit every underlying record.

Prefer explicit business commands such as “request credit correction”, “approve correction” and “apply account restriction” over a generic “edit player” endpoint. Each command needs an identified actor, record scope, allowed transition, reason and result. A database update that simply replaces a balance bypasses the accounting explanation. Corrections should create authorised ledger entries with references to the case and the original issue; an error in a correction needs a separately authorised reversal, not deletion of history.

Keep authentication and business authority separate. Signing in confirms an identity; it does not grant unrestricted financial access. A service account executing approved work must preserve the requesting and approving staff identities as well as its own execution identity. Shared staff accounts make that distinction impossible to investigate reliably.

Define roles, record scope and separation of duties

Start with a permission list that operations can review, rather than a role called “admin” that gradually absorbs every exception. For each permission, specify the brand or tenant, relevant account or case, visible fields, permitted action and any policy conditions. These are suggested boundaries to refine with the teams that actually operate the platform:

• Support: inspect assigned player cases and a masked timeline; add notes and request a correction; do not approve or execute financial entries.
• Finance requester: investigate ledger references and propose a correction with an amount, currency and evidence; do not approve the same request.
• Finance approver: inspect the complete correction proposal and approve or reject it within assigned scope and limits; do not approve a proposal they created, even through another role.
• Risk reviewer: apply or remove specifically authorised restrictions with a reason; do not use that permission as a balance-edit or verification-bypass privilege.
• Access administrator: manage approved staff access grants; do not obtain financial powers simply by administering accounts. Protect the grant process itself against self-escalation.
• Auditor: inspect permitted evidence and investigate changes; do not alter the transactions or records being reviewed.

RBAC groups permissions by role. It still needs record-level constraints: a finance role for one brand must not reveal another brand’s players. OWASP’s authorization guidance calls for denial by default and permission checks on every request. Apply those checks on the server, including direct API calls; hiding a button is only a presentation choice.

NIST controls AC-5, AC-6, AU-3 and AU-9 cover separation of duties, least privilege, audit record content and audit protection. They are useful design references, not an iGaming licence or a claim of certification. Your role assignments must also work across connected systems; independent approval reduces error and abuse opportunities but does not defeat collusion.

Approve a specific correction, then execute it once

Consider a reviewed service case where a player is owed a credit of EUR 25.00. For this isolated example, the wallet has EUR 100.00 and no other movements occur. The correction is an additive credit, not a request to set the balance to a number displayed earlier. Use a workflow whose records can answer each of these questions:

1. What was requested? Store the player and brand, the amount and currency, the ledger account, case and evidence references, reason, requester and proposal version. Allocate a stable correction identifier before executing money movement.
2. What was approved? Present the actual proposal to a different authorised person. Bind their decision to that version and its significant fields. Changing the credit to EUR 250.00, the recipient or the currency invalidates the approval; it is a new proposal for review.
3. What may execute now? Recheck the actor’s current authority, approval validity, relevant account restrictions and the policy that applies to execution. Enforce the permitted transition atomically with claiming the command, so parallel requests cannot both consume it. Define which changes invalidate approval, how long it remains valid and whether revoking a requester’s or approver’s access cancels pending work; never leave those decisions to a cached screen.
4. What actually happened? The responsible money service records one committed credit and its ledger reference. In this example the balance becomes EUR 125.00. If the response is lost, retrieve the result by the stable identifier or retry the same command. The balance remains EUR 125.00; the retry is not a new correction.

OWASP’s transaction authorization guidance addresses server-side enforcement, protection of approved transaction data and a final authorization check before execution. The staff proposal-and-approval workflow above is an architectural application of those principles, not a claim that the guide mandates this exact business process.

A disabled submit button cannot enforce this workflow. Persist the command identity, approved version and execution result. In the owning money service, enforce uniqueness of the correction reference and commit that reference with the ledger effect and durable result. A claim recorded in another service is not enough: a crash between the posting and recording success must not permit a second posting. Stripe’s idempotency documentation illustrates one provider’s retry contract: its API v1 compares parameters when a key is reused. Your correction service needs its own documented contract and retention policy; provider key expiry must not make an old staff correction executable again.

For work spanning services, distinguish “approved”, “execution pending”, “committed”, “rejected” and “outcome unknown”. A timeout is not proof of failure. Investigate the original command and ledger evidence before creating a replacement. Also check whether a newly allocated identifier is a second correction for the same underlying issue; idempotency alone cannot identify every duplicate business request.

Make player timelines, search and exports trustworthy

A player timeline is a view for investigation, not a substitute for the systems that own the events. Show the event source and reference, the business event time, the time it reached the view, and the view’s freshness. A payment reported by its provider, a wallet posting and a bonus award are separate facts. Link them by their recorded relationships instead of merging them into an unexplained green “completed” status.

When events arrive late, preserve their causal relationships and source identifiers; sorting solely by receipt time can tell the wrong story. Before a sensitive command, obtain the current record from its owning service and enforce that service’s rules. A stale support timeline may remain useful if it is clearly labelled and does not silently authorise a write. Notes should identify their author and case; corrections to notes need a traceable history rather than invisible overwrites.

Search needs precise filters for player, brand, case, internal transaction and provider reference. Scope the query, returned fields, totals and autocomplete suggestions. An empty results page is not sufficient protection if a hidden cross-brand record appears in a count or an export. Distinguish “not found in this view” from “the transaction never existed”; delayed indexing and restricted access are possible explanations.

Treat an export as a separate data-access action. Check authority when it is requested, when the job reads records and when the file is downloaded. Apply field masking, protect delivery, record the filter and actual exported scope, and expire stored files under the agreed retention policy. Handle revoked access during a running job explicitly. A file already downloaded cannot be recalled by revoking a role, so minimising fields and controlling distribution matter as much as download permissions.

Record the outcome durably and protect the evidence

For a correction, retain the requester and approver identities, case, proposal version, amount and currency, decision and policy context, execution identity, command identifier, ledger reference, timestamps and outcome. Record a rejection or an uncertain outcome as such; neither is a successful posting. A case note saying “approved” is not proof that the money service committed anything.

Choose the durability boundary deliberately. Where the command outcome, ledger entry and audit event belong to one transactional store, commit them together. Where services are separate, the owning service can commit its local outcome and a durable event for later delivery; a delivery failure must leave recoverable work, not an invisible gap. Retrying delivery must not post the money again. A central log collector may be unavailable while local evidence remains durable. If the required local evidence cannot be saved, the proposed policy here is to reject the sensitive change rather than execute it without a record.

OWASP’s logging guidance recommends protecting logs, detecting tampering and restricting log access. It also identifies sensitive data to exclude. Keep passwords, access tokens and raw identity documents out of routine logs; use controlled evidence references instead.

“Append-only” in an application does not mean nobody can alter the database. Protect evidence with separate access rights, monitored administrative access, retention controls and protected copies or storage appropriate to the threat model. Make alteration detectable and investigate gaps in event delivery. Separate operational transaction evidence from security diagnostics where their readers and retention requirements differ. Test retrieval and interpretation, not just whether a log line exists.

Treat configuration and emergency access as controlled changes

A configuration change can affect more players than a manual correction. Treat money, eligibility, verification and risk settings as versioned proposals with a scoped diff, owner, reviewer, activation conditions and an explicit rollback decision. Show whether the change applies only to new decisions or also to work already in progress. “Restore the old configuration” does not automatically reverse credits or provider instructions issued under the new one.

Avoid one universal approval rule for everything. Correcting a spelling mistake in a support note and changing a financial limit carry different consequences. Classify actions, assign review requirements and define emergency exceptions before an incident. The operator and relevant specialists determine market-specific rules, player-protection restrictions and retention obligations; the software must enforce the agreed boundaries without inventing a bypass for convenience.

Emergency access should name the incident, granted capabilities, scope, approver where feasible, expiry and review owner. It needs a traceable activation and subsequent review, not a permanently available “super admin”. If a small team cannot staff independent approval around the clock, make that operational limitation explicit and choose a documented restricted escalation process. Giving the same person two role names does not create independent review. Expiry must stop new privileged actions and be enforced for running jobs at their next controlled step.

Accept the design with adversarial operational scenarios

Start delivery with a complete investigation-and-correction slice: scoped search, evidence, proposal, independent approval, owning-service execution and an inspectable result. Demonstrate it using real service contracts, not only a screen prototype. The core-module walkthrough helps identify the boundaries crossed by a staff action; the verification-workflow article provides adjacent context when a case involves identity review. A correction permission must not silently become permission to release an account restriction.

• Scope attack: substitute another brand’s player identifier in an API call and export request. The server denies the operation without revealing the other record.
• Approval attack: let a requester acquire an approver role and try self-approval, then alter an approved proposal’s amount. Both attempts are rejected and explainable.
• Race and lost response: submit the same approved correction concurrently and lose the acknowledgement. Inspect the actual ledger and durable command result; there is one effect, not merely one success message.
• Changed authority: revoke a staff permission or activate a relevant account restriction before execution. Apply the documented current-policy decision; do not execute using yesterday’s authorization.
• Evidence failure: stop event delivery, restore it and check complete recovery without another posting. Separately make local evidence persistence fail and verify that the sensitive change is refused under the chosen policy.
• Export exposure: revoke access during generation, test expired links and inspect masking, row scope and totals. Retain evidence of what the checks actually returned.

Have support, finance, risk and engineering read the resulting case history independently. If they cannot agree on what was requested, approved and committed, improve the evidence before adding more screens. Monitor pending and uncertain corrections, approval age, unexpected permission denials and evidence-delivery lag with named response owners. A back office succeeds when staff can resolve a case without bypassing controls and another person can reconstruct the decision afterward.

For related boundaries, use the bonus-engine article when configuring eligibility and awards, the payment-orchestration article when investigating routing and payment uncertainty, and the player-account article when defining account states and action permissions. Keep ownership explicit as these workflows meet in the staff interface.

• Permission specification: roles, per-record and per-field scope, permitted commands, conflicting duties, access-grant controls and examples of denied requests.
• Correction contract: proposal and approval versions, significant fields, execution checks, stable identifiers, retry behaviour, duplicate-case review and reversal procedure.
• Evidence contract: recorded decisions and outcomes, ledger references, local durability, event recovery, access controls, masking and approved retention rules.
• Acceptance record: observed results for scope attacks, self-approval, payload changes, concurrency, revoked permissions, uncertain outcomes and export restrictions; remaining exceptions with owners.