A mid-sized bookmaker licensed by the Tankwa Gambling and Betting Board, the fictional provincial regulator in this series, counted its contact points with the board. It found one email address for licence applications, another for key-employee licences, another for monthly returns and another for gambling-tax returns. Incident reports went to the compliance manager's address, and complaints were handled by phone. Device approvals came in on a separate form, and original certified documents were still sent by courier. Each channel had its own reference number. None of them could tell the bookmaker where its renewal stood.
From the board's side the picture was the same in reverse. Information about one licensee was spread across mailboxes, shared drives and spreadsheets, and officials spent much of their time matching documents to files.
This final part of the opening sequence describes one digital front door for licensing and regulatory services: what it serves, what sits behind it, and how to build it without turning a paper process into an online one. It brings together Part 2 (the case file as the unit of work), Part 3 (structured evidence for risk-based supervision) and Part 4 (the public services zone of the landing zone). As throughout the series, legal references are general information, not legal advice.
A front door is not a portal
A portal is a website with forms. A front door is a service. The difference shows in what happens after the user clicks submit.
- A portal turns a form into an email or a PDF in a shared folder. Someone still has to find it, read it, match it to a licensee and type parts of it into another system.
- A front door creates or updates a case record, validates the submission against rules on arrival, tells the user what happens next and when, and routes the case to the right team with its evidence attached.
Digitising bureaucracy is not transformation sets out a step-treatment test: for each step, ask why it exists, then remove, merge, automate or assist it. Run that test before designing a single screen. At the Tankwa board, it removed two steps from the renewal process outright. These were a covering letter repeating information already in the form and a second certified copy of documents the board already held and that had not changed.
Who comes through the door
A gambling regulator serves more than licensees. The Tankwa board identified five groups, each with different needs.
| Who | What they need | Identity level |
|---|---|---|
| Applicants for a licence | Apply, upload evidence, pay fees, track status, respond to queries | Verified individual or company representative |
| Licensees | Renewals, returns, tax returns, incident notifications, device and site changes, key-employee licences | Verified, with a licensee administrator who manages its own users |
| Key employees | Apply for and renew an employee licence, update disclosures | Verified individual |
| Members of the public | Check whether an operator is licensed, complain, report unlicensed gambling, find help for problem gambling | Anonymous or lightly identified, by choice |
| Other authorities | Exchange information with the National Gambling Board, the FIC and other provinces where the law provides for it | System-to-system, under agreement |
The public licence check matters more than it looks. The National Gambling Board's enforcement page tells the public to check for an operator's licence before gambling. A board that publishes its register as a searchable, current list makes that advice easy to follow. Public reporting of unlicensed sites also feeds the enforcement work described in Part 1.
What sits behind the door
The front door is the visible part of a larger design. Behind it are five shared capabilities that every service uses.
- Identity. One sign-in for each person, linked to the licensees they represent and the roles they hold. A licensee's administrator adds and removes its own users, and remains accountable for them.
- The case record. Every application, return, incident and complaint is a case with one identifier, a status, an owner and a history. This is the case file from Part 2, and it is what makes status tracking possible.
- Rules. Validation and routing rules, such as required fields, fee calculations, which team handles which case and when a reminder is due, are kept as versioned configuration. When the law or a fee changes, the rule changes and the version is recorded. The rule must be authoritative before the agent can help explains why this comes first.
- Documents and evidence. Uploaded documents are stored once, classified and linked to the cases that use them. A company registration document submitted for a licence application is reused at renewal rather than requested again.
- Notifications and payments. Users are told what is needed and what has happened through the channel they choose. Fees are paid online and reconciled against the case.
Large licensees also need a machine door. A bookmaker that produces its monthly return from its own systems should be able to submit it through an API, in the same structured format the form produces. Both routes create the same case record and run the same validation.
One application, end to end
The renewal of a bookmaker's licence shows how the parts fit together.
Three things in this journey are different from the paper process.
- The applicant always knows the status. Each stage is visible, with the date it started and what it is waiting for.
- Missing information is caught at submission. The validation rules reject an incomplete application before it enters the queue, so officials do not spend weeks chasing it.
- The decision stays with an official, and the reasons are recorded. The system assembles the evidence and may highlight concerns, for example an unresolved inspection finding. The official decides, records the reasons and the decision is sent to the applicant with those reasons and information on how to seek review.
That last point is the boundary this series has held throughout. How the Promotion of Administrative Justice Act applies to each kind of licensing decision is a question for the regulator's legal advisers, but the design should assume that reasons and a review route are needed. Human-in-the-loop is not administrative justice and An appeal is a reassessment, not a second opinion describe what the system must make possible: evidence, authority, time for real consideration and a working review route.
Fit with national digital government
The front door should not be designed in isolation. Government's Roadmap for the Digital Transformation of Government, published in May 2025, describes MyMzansi as a single platform for government services and sets the principle "Tell us once", under which people and businesses provide their information once and government reuses it. It also plans a digital identity and a data exchange. These were plans with target dates when we checked on 7 November 2026, and their delivery status should be confirmed before a regulator depends on them. Can South Africa build machine-readable government? covers the roadmap's pillars in more detail.
For a provincial regulator, the practical implications are modest but real.
- Design identity so it can be federated. Use open standards for sign-in, so that a national digital identity can be accepted when it is available, without rebuilding the service.
- Treat data exchange as an interface. Information that the regulator receives from, or shares with, national bodies should pass through defined interfaces with agreements and logs, not through spreadsheets attached to emails.
- Follow the "tell us once" principle internally first. If the board asks a licensee for the same information in three different forms, no national platform will fix that.
Where to start
The Tankwa board did not build every service at once. It ranked candidate services by volume, pain and dependence on other work.
| Service | Volume | Current pain | Dependencies | Priority |
|---|---|---|---|---|
| Public licence register and verification | High | Public cannot easily check operators | Clean licence data | First |
| Monthly returns, form and API | High | Retyping and late detection | Agreed return schema | First |
| Key-employee licence applications and renewals | High | Paper, couriers, no status | Identity, case record | First |
| Licence renewals | Medium | Repeated documents, long cycle | Case record, documents store | Second |
| Incident notifications | Low, but urgent | Arrive by email, unstructured | Case record, notification rules | Second |
| Complaints and reports of unlicensed gambling | Medium | Phone and email, hard to analyse | Case record, public identity option | Second |
| New licence applications | Low | Complex, many documents | Everything above | Third |
The pattern is deliberate. The first wave builds the shared capabilities (identity, the case record, structured data and clean licence data) with high-volume services that are relatively simple. The complex, low-volume new-licence process comes last, when the foundation has been tested. The 90-day government MVP describes how to scope a first release that is small enough to deliver and real enough to learn from.
What the front door makes possible
Once the front door is running, the earlier parts of this series become practical. Structured returns arriving through it are the evidence for the risk model in Part 3. Case records give the board the consistency and defensibility described in Part 2. The landing zone in Part 4 keeps the public-facing service separate from the intelligence that supervision depends on. The industry's activity has moved online, and with a front door the regulator's work moves online too, without moving its decisions away from accountable officials.
Key points
- A portal turns forms into emails. A front door turns submissions into validated case records with status, owner and history.
- Serve five groups: applicants, licensees, key employees, the public and other authorities, each with an appropriate level of identity.
- Behind the door, build five shared capabilities: identity, the case record, versioned rules, a documents and evidence store, and notifications and payments. Give large licensees an API that produces the same case record.
- Licensing decisions stay with officials, who record reasons and give the applicant a route to review. How administrative-justice law applies to each decision is a matter for legal advice.
- Design for national digital government by using federated identity, interface-based data exchange and "tell us once" inside the regulator first. Start with high-volume, simpler services that build the shared foundation.
This is part 5 of Regulating a Digital Gambling Economy. Previous: A cloud landing zone for a public regulator. More parts will follow in this series. In the meantime, see Public-sector AI workflows: from citizen request to service action and the Rewiring Government series.
Background reading: South Africa's Roadmap for the Digital Transformation of Government (May 2025); National Gambling Act 7 of 2004; National Gambling Board enforcement guidance. Checked on 7 November 2026. This article is general information, not legal advice.
How CloudNala can help
CloudNala designs and builds digital front doors for public bodies that license and regulate. We start by mapping every way applicants, licensees and the public currently reach you, run the step-treatment test on the highest-volume journeys, and design the shared identity, case record and rules capabilities that every service will use. We then deliver a first release of two or three high-volume services, with an API for large licensees, and set up the measures that show whether status enquiries, retyping and incomplete submissions are actually falling.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book a Regulatory Technology Review or write to us at consult@cloudnala.co.za