SASFA

The standard

SANS 1718, explained

The South African National Standard for gambling systems, published by the SABS. It is what a regulator means when it asks whether a bookmaker's software has been tested.

Who does what

  1. 01 The SABS publishes SANS 1718 is a family of parts, each covering a kind of gambling system, bought from the SABS part by part.
  2. 02 An accredited laboratory tests A SANAS-accredited laboratory tests against the applicable parts and issues a test report. In this region, principally GLI Africa and BMM Testlabs.
  3. 03 The NRCS certifies The National Regulator for Compulsory Specifications issues a letter of certification on the laboratory report.
  4. 04 The provincial board authorises The licensing authority reviews the certification and the integration plan, usually inspects, and gives written authority to deploy under a licensed bookmaker.

SASFA sits before the laboratory: it tests to the same standard so a product arrives there with its evidence in order. A SASFA report is not a certificate or a licence.

The parts that govern betting software

The standard is modular. A product complies with the clauses of the parts that match its shape; the chapters written for physical machines do not apply. Editions change, so the edition is recorded on every report.

SANS 1718 Part 4 2018, Ed. 3.00

Wagering record-keeping software

The betting part. Accounts and passwords, the particulars of each bet, the wallet, settlement, reports and returns, security, clocks, significant events, communications.

SANS 1718 Part 10 2009, Ed. 1.00

Server-based systems

Products whose outcome is generated on a server: software control, submission, the certified-build verification, parameter changes, reporting, recovery.

SANS 1718 Part 2 2016, Ed. 4.00

Outcome fairness

The generator, result determination, maximum prize and stake, significant events, and the submission guidelines in its first annex.

SANS 1718 Parts 3 and 9 2023 and 2021

Monitoring and control

Logging, backups, encryption, master resets, metering and message authentication, reused as the control checklist for any system that reports centrally.

What a laboratory tests

The bet record

Every bet stored with type, stake, odds, potential win, event, selection and time. Entering a result triggers settlement, tax and the database update together.

Outcome generation

Where the software decides the result, the generator must be unpredictable, uniform and independent, documented, and tested in isolation.

Meters and records

Money in, money out, wagered and won on meters nobody can edit or roll back, and append-only transaction records retained for the periods the standard sets.

Significant events

Things the system must detect and act on: verification failures, data corruption, lost communication, limits exceeded, privileged actions. Classed by the response required, from log-only to disable until cleared.

The certified build

Proof that the software in production is the software that was certified: every file hashed, the manifest signed, verified at boot and on demand.

Recovery

Bet state survives a crash. A bet interrupted mid-placement completes or is refunded, never stranded or duplicated.

Reading it as an engineer

  • Start each part at its first annex: the submission guidelines are the checklist of what the laboratory will ask for.
  • One row per requirement clause, graded met, partial or missing, each grade tied to evidence that exists.
  • Mark the clauses that belong to the licensed operator rather than the software.
  • Treat the certified build as the centre: every other grade is only true of the build whose hash it names.

That is the method behind a SASFA conformance matrix. Request a test.