Betting Audit Standards in Africa: What Operators Should Check

An auditor’s request is usually concrete. Reconstruct this disputed bet. Retrieve the transactions for a reporting period two years ago. Confirm that the software running in production is the build the laboratory tested. Answering requests like these depends less on what an operator’s policies say than on what its systems can prove. For sportsbook operators in Africa, betting audit standards and the requirements behind those requests change from one jurisdiction to the next. Licensing conditions, technical standards and reporting obligations differ by country, and several regulatory frameworks are still developing. Compliance is an ongoing operational responsibility, not a milestone reached when a licence is granted. Technology cannot guarantee compliance, but it largely determines how much evidence an operator can produce, and how quickly. This guide explains how betting audits generally work, how frameworks such as GLI and ISO relate to national requirements, and which platform capabilities operators should examine before an assessment, or before choosing a technology provider.

In this article

• • • How Do Betting Audits Work?
    • Common Betting Audit Standards and Frameworks
    • Betting Audit Requirements Across African Markets
    • How Betting Audits Affect Sportsbook Operations
    • What Operators Should Check in Their Betting Platform
    • Business Continuity: Can Your Sportsbook Recover Without Losing Track of Bets?
    • Adapting Your Betting Platform to Local Audit Requirements
    • Betting Audit Readiness: A Practical Checklist for Operators
    • Preparing for a Betting Audit: Where to Start

 

How Do Betting Audits Work?

There is no single audit procedure for sportsbooks. Each gambling authority sets its own requirements, which may combine independent software testing, security assessments and reviews of internal procedures. Two kinds of assessment are worth keeping apart. Technical testing, usually carried out by an accredited independent laboratory, checks whether the sportsbook and its supporting systems meet a defined technical standard. It is performed on a specific version of the software. Operational audits look at how those systems are run in a live environment: how betting transactions and financial records are handled, how software changes are controlled and how sensitive information is protected.

Either may involve requests for technical documentation, software version records, transaction histories, security policies and evidence of backup and recovery procedures. Auditors may also inspect configurations, test specific functions or ask to see a control working. The outcome is typically a test report, a list of corrective actions and, where the jurisdiction requires it, certification or regulatory approval.  

Common Betting Audit Standards and Frameworks

A small number of international documents serve as reference points for technical testing, information security and operational controls in gambling. They cover different ground and are not interchangeable.

The most important distinction is between management-system certifications and technical assessments. An ISO/IEC 27001 certificate shows that an organisation runs a structured information security management system; it says nothing about whether a wagering engine records and settles bets correctly. A GLI test report covers a defined system and version against technical requirements, but it is not a licence, and a regulator may still require local testing or approvals. Neither substitutes for the other, and neither grants market access on its own.  

Betting Audit Requirements Across African Markets

Africa is not a single regulatory market. Meeting the requirements of one jurisdiction does not mean meeting those of the next: each authority sets its own rules on technical testing, documentation, reporting and approval, and the extent to which international test reports are recognised varies. South Africa illustrates the point. Gambling equipment and systems there are tested against the SANS 1718 series of South African National Standards, which includes requirements for wagering and record-keeping systems, by laboratories accredited for that purpose. Approval is overseen by the relevant gambling authorities. A test report issued against a GLI standard should therefore not be assumed to cover South African requirements. Before entering a new market, three questions are worth settling early: which parts of the platform fall within the local testing scope; whether existing test reports or certifications are recognised; and which additional requirements, such as reporting formats, data retention periods or data location, the regulator imposes. How a platform can absorb those differences is discussed later in this guide.  

How Betting Audits Affect Sportsbook Operations

Depending on the jurisdiction, assessments can recur at licence renewal, after significant software changes or whenever an authority asks for further evidence. The cost of being unprepared is measured mostly in time. Incomplete transaction records, undocumented software changes or missing documentation can lead to retesting, corrective work and delayed approvals. Where failures are serious, they can lead to restrictions or sanctions under the applicable rules. Some gaps cannot be closed quickly. If a platform was never built to track software versions or to retrieve historical bets efficiently, fixing it is a development project rather than a documentation exercise. Audit readiness is better treated as a property of the platform and of daily operations than as a task to schedule before an assessment.  

What Operators Should Check in Their Betting Platform

The six checks below focus on evidence: what a system can show, rather than what a policy says it does. Each ends with a question to put to your platform provider.

1. Can Every Bet Be Traced from Acceptance to Settlement?

Take a player who disputes the settlement of a football bet. To resolve it, the operator needs to establish when the wager was accepted, at what odds, on which event and market, which result was confirmed, how the bet was settled and which account movements followed. If the market was suspended, the odds moved or the bet was later voided or resettled, that history must be available too, along with who made the change and why. Those records usually sit in different places: the sportsbook engine, the odds and results feeds, the backoffice, the settlement process and the player wallet. They have to agree with one another and with the corresponding debits, payouts and payment records. A bet settled correctly in the sportsbook is weak evidence if the wallet shows a different amount. GLI-33 sets detailed requirements for wager and market records, including timestamps, event identifiers, amounts, results and wager status. The practical test is whether those fields can be assembled into one consistent history for a single bet. What to ask your provider: “Can you produce the complete history of one wager, from acceptance and odds through result, settlement and account movements, including any adjustments or cancellations and the reasons recorded for them?”

2. Can Historical Records Be Retrieved, Not Just Retained?

Retention and retrieval are different capabilities. A platform can store years of betting data and still struggle to find a specific transaction when an auditor asks for it. Poorly indexed archives turn a routine information request into an investigation, and the same weakness shows up when a dispute involves an older player account. Archived data must stay searchable, readable and exportable in the format the regulator expects. Retention periods, access arrangements and permitted storage locations must also satisfy local requirements, which differ between jurisdictions. This is easy to test rather than take on trust. Pick a transaction from an earlier reporting period and ask for its betting, settlement and financial records. How long it takes, and how many people need to be involved, says more than a stated retention policy. What to ask your provider: “How are historical records indexed, retrieved and exported for audits and regulatory reporting?”

3. Can the Provider Prove Which Software Version Is in Production?

Sportsbook platforms change constantly through new features, bug fixes and infrastructure updates. A technical assessment, by contrast, applies to a fixed point. The laboratory evaluates a specific build, and its findings only hold if the provider can show that the software running in production corresponds to the authorised version. That requires controlled releases, version records for each critical component and a way to verify those components independently. Cryptographic hashes are a common method: they show whether a file has been altered since it was authorised. GLI-33 addresses software integrity and change control, including verification of authorised production versions. What must happen after an update, whether notification, retesting or prior approval, depends on each jurisdiction’s change-management rules. For any change, the provider should be able to say what changed, who authorised it and whether it required further testing or approval. A provider that cannot separate changes to tested components from other releases makes routine updates harder to manage without raising retesting questions. What to ask your provider: “How do you identify production software versions, and how do you control changes to components covered by technical testing?”

4. Are Timestamps Consistent Across Systems?

Bet placement, market suspension, event results, settlement and payment processing may run on different components or external services, each recording its own time. When they record it differently, the order of events becomes hard to reconstruct. A typical case: one service stores timestamps in UTC while another records local time and mishandles daylight saving changes, a risk whenever feeds or suppliers operate from regions that observe them. Each record may be valid on its own, yet the reports built from them disagree. The discrepancy often goes unnoticed in daily operations and surfaces only when an auditor compares records side by side. In a sportsbook, sequence carries weight. Whether a bet was accepted before or after a market suspension can decide whether it should stand. GLI-33 requires a system clock for timestamping transactions and events, together with a mechanism for synchronising time across components. What to ask your provider: “How are timestamps synchronised between the sportsbook, betting feeds, player accounts and financial reporting systems?”

5. Can Security and Player Protection Controls Be Demonstrated?

Audits may also cover access to sensitive systems and the operator’s player protection obligations: user permissions, authentication, administrative activity logs, identity verification, transaction monitoring and responsible gambling tools. Which controls are mandatory, and how they must be evidenced, depends on the jurisdiction and the type of assessment. A policy document rarely suffices on its own. Auditors may want to see that a control operates: logs of administrative access, a documented account restriction, a record of how a flagged transaction was reviewed. A monitoring feature only works as a control if its alerts are reviewed, escalated and documented. That applies in particular to AML and KYC, where software capabilities must be backed by monitoring, escalation and record-keeping processes. These are covered in more detail in our guide to AML compliance for iGaming platforms. What to ask your provider: “Which security and player protection controls are built into the platform, and what evidence can it produce to show they operate?”

6. Which Third-Party Integrations Fall Within the Testing Scope?

Odds feeds, payment services, identity verification tools and casino content usually come from external suppliers. Testing a third-party product and testing its integration with the platform are separate questions. A casino game may have been certified by an independent laboratory on behalf of its developer. That certification covers the game. It does not automatically cover how the platform launches it, how the player wallet handles its debits and credits, or how its transactions appear in the operator’s records. The same logic applies to sportsbook feeds and payment integrations. An inventory of critical components, listing their versions, interfaces and who is responsible for testing each one, makes scoping questions much easier to answer. It also clarifies who is accountable when something goes wrong. What to ask your provider: “Which components are included in the platform’s testing scope, and which certifications or technical evidence must third parties supply separately?”  

Business Continuity: Can Your Sportsbook Recover Without Losing Track of Bets?

An outage can stop betting, payments and account access at once. Bringing services back online is only part of recovery. The sportsbook also has to resume without losing, duplicating or leaving unresolved the bets and transactions caught by the interruption. The existence of a backup answers very little. More useful questions are whether the platform can restore the data needed to resume wagering, what happens to bets accepted moments before the failure, how outstanding bets and financial movements are reconciled once services return, and when recovery procedures were last tested. GLI-33 includes requirements on backup, recovery and continuity, including protection of wagering data and procedures for restoring operations when the production environment becomes unavailable. ISO 22301 provides a broader framework for business continuity management. Neither should be confused with an SLA, which sets an availability target but does not explain how data and operations are protected during an incident. What to ask your provider: “Which recovery procedures have been tested, and how do you verify the integrity of outstanding bets and financial transactions after an incident?”  

Adapting Your Betting Platform to Local Audit Requirements

When one sportsbook infrastructure serves several markets, every new requirement raises the same question: can it be met through configuration, or does it need development? Regulatory reporting shows the difference. One authority may ask for a particular combination of transaction fields, reporting periods and time conventions; another may want a different format or additional data. A configurable reporting layer can absorb many of these variations without changes to the underlying software. The same can apply to KYC document rules, responsible gambling limits or transaction monitoring thresholds. Configuration has limits. If a regulator requires a capability the platform does not have, new development is needed, and if the change touches tested components it may also need further testing before deployment. For an operator assessing a new market, that difference translates directly into cost and time to launch. Asking whether a provider “supports” a country tells you little. A better question is which of that country’s requirements the platform meets today through configuration, which would need development and which would trigger retesting. Testing scope and operator approvals still have to be confirmed with the local authority: a configurable platform does not discharge jurisdiction-specific obligations.  

Betting Audit Readiness: A Practical Checklist for Operators

Before an assessment, ask your teams and suppliers to show the evidence behind each answer, not simply confirm that a feature exists.

• Applicable standards: Have we established which technical standards, tests and approvals the relevant authority requires?
• System scope: Do we know which sportsbook, backoffice, player account and third-party components fall within the assessment?
• Transaction traceability: Can we reconstruct individual wagers, settlements, cancellations and the related financial movements, with consistent timestamps across systems?
• Data access: Can historical records and regulatory reports be retrieved and exported when requested, within a reasonable time?
• Software integrity: Can the provider identify authorised production versions and show how changes to critical components are controlled?
• Security and recovery: Do we have evidence that access controls, backups and recovery procedures work as intended?
• Local adaptability: Which requirements can be configured, and which would need development or further testing?

An open question is not a finding of non-compliance. It marks an area to investigate before relying on the platform in an audit.  

Preparing for a Betting Audit: Where to Start

A sportsbook can run smoothly for months before someone asks for a detailed transaction history, questions a software change or wants to see the last recovery test. If answering requires an emergency development project, the gap was there all along. Operators preparing for a regulated market should involve their technology provider early, agree the testing scope and close gaps while there is still time. Planning a new sportsbook operation or reviewing your current platform? Talk to PlaylogiQ about your technical and operational requirements.  

Sources

• Gaming Laboratories International – GLI Standards Series, including GLI-33 Event Wagering Systems, GLI-19 Interactive Gaming Systems and the GLI Gaming Security Framework
• ISO/IEC 27001 – Information security management systems
• ISO 22301:2019 – Security and resilience, business continuity management systems
• National Gambling Board (South Africa) – Technical standards, SANS 1718

Information reviewed: October 2026.  

Frequently Asked Questions About Betting Audits in Africa

1. What technical standards does my sportsbook need to meet?

The applicable standards depend on the jurisdiction and the type of betting operation. GLI-33 provides technical requirements for event wagering systems, including bet recording, settlement, software integrity and security. However, regulators may require additional national testing, certification or approval. Operators should confirm which standards apply to their platform before entering a regulated market.

2. What do auditors check when assessing a sportsbook platform?

Auditors may examine transaction records, bet settlement accuracy, software versions, security controls, change management and business continuity procedures. Technical testing assesses whether a specific software version meets defined standards, while operational audits evaluate how systems and controls function in practice. Depending on the jurisdiction, both types of assessment may be required.

3. Can I use the same sportsbook certification across different African markets?

Not necessarily. African jurisdictions have different technical testing and regulatory approval requirements. For example, South Africa uses the SANS 1718 series of national standards. An existing GLI test report may provide supporting evidence, but it does not automatically replace local testing or approval. Operators should confirm recognition requirements with the relevant authority.