B2C vs B2B Lottery Licences: Functions, Scope and Responsibilities
A function-led preparation guide for B2C and B2B lottery licensing scope, distinguishing operator responsibilities, supplier roles and market-access dependencies.
B2C and B2B licence scope should follow what a lottery business actually does, not the label in its sales deck. An operator-facing role and a supplier-facing role can involve different permissions and responsibilities. Map customer contracts, funds, product control, technology and entity roles before asking qualified advisers to determine the applicable route.
B2C and B2B are useful commercial shorthand, not universal legal definitions. Categories, exclusions, supplier requirements and mixed-model treatment vary by product and jurisdiction. A counterparty’s licence is not, by itself, evidence that your activities or target markets are covered.
Start from the service, not the brand name
Describe the lottery service from the customer’s perspective. Is the business conducting a draw, selling tickets, acting as an intermediary, offering instant games or supporting wagering on external outcomes? Who owes the prize, accepts the transaction and resolves a customer complaint? Different models can share a similar website while raising different legal questions.
Then map each function to the responsible entity, contract and system. The lottery operator operating model provides a useful starting structure. The phrase “white label” does not answer these questions; use the white-label versus turnkey comparison to clarify the implementation model without treating it as a legal conclusion.
Use a function-to-responsibility matrix
This is an editorial perimeter-mapping template. Its rows do not establish legal licence categories.
| Function | Question to answer | Evidence for scope analysis |
|---|---|---|
| Customer relationship | Which entity contracts with and admits customers? | Terms, onboarding flow and complaints responsibility |
| Product control | Who sets the rules and controls the service or prize obligation? | Product description, rules, supplier contracts and decision rights |
| Money movement | Who collects, records, holds or pays out value? | Funds flow, account ownership, ledger and settlement arrangements |
| Critical technology | Which entity supplies or controls essential platform functions? | Architecture, hosting, access rights and outsourced-function scope |
| Domains and promotion | Who presents the brand and targets each market? | Domain inventory, commercial agreements and market restrictions |
| Mixed activity | Does the group both serve customers and supply other operators? | Separate contract, system, responsibility and revenue maps |
Understand the distinction without overgeneralising
An operator-facing model typically involves the business delivering the service to customers. A supplier-facing model may involve providing technology, games or other critical functions to operators. Those observations help formulate questions; the current law and the authority’s definitions decide whether a particular activity needs permission and what that permission covers.
As one framework example, the Curaçao Gaming Authority’s licence information distinguishes online-gaming licences from supplier licences for gambling-related critical services and goods. That distinction does not prove that every lottery product or platform arrangement fits either category. The UK Gambling Commission’s operating-licence guidance uses its own framework and activities. Do not transplant one authority’s category names into another market.
Keep licensing scope separate from market and partner acceptance
Even a confirmed licence category does not settle customer-location restrictions, payment acceptance or supplier onboarding. Record what each market and critical counterparty needs to evaluate. Preliminary commercial feedback is not regulatory permission or a bank’s final approval.
The payment-stack guide helps expose entity and settlement dependencies. The launch partner map helps separate the operator, platform supplier, payment providers and professional advisers. Their responsibilities should be explicit in the implementation and commercial plan.
Test a mixed or changing model before expansion
Suppose one group wants to run a consumer lottery brand and later offer its platform to other operators. Produce two activity maps: the customer-facing operation and the supplier relationship. Identify shared staff, system access, contracts, control decisions and conflicts. Ask the qualified advisers to establish whether additional permissions, entity arrangements or technical separation are necessary.
If the initial scope only supports the customer-facing product, do not begin supplying third-party operators on the assumption that future permission will follow. Keep proposed expansion separate from approved activities and set the event that reopens the scope decision. Product demos, managed services and sales promises can change the factual model even before the team calls it a new business line.
Write a usable perimeter statement
The approved scope note should list entities, products, markets, included functions, excluded functions, critical suppliers and unresolved dependencies. Record the basis and appropriate specialist input for the decision. Give commercial and product teams a practical version so they do not expand the model informally through contracts or configuration.
Connect the statement to the planned turnkey implementation or open lottery platform workstream. Neither implementation label establishes a licence, a sublicence or the supplier’s regulatory status.
Scope checklist
- Define the actual product and customer service.
- Map customer, funds, prize, data and technology responsibilities.
- Identify the contracting entity for each relationship.
- Compare actual functions with current official definitions.
- Separate present activity from proposed expansion.
- Resolve partner and market dependencies without treating them as equivalent approvals.
- Record qualified advice, commercial limits and change triggers.
Frequently asked questions
Does a software supplier always need a B2B licence?
There is no universal answer. The service, control rights, product and applicable framework determine the analysis. Ask appropriately qualified advisers to assess the actual supplier scope.
Can one group have operator and supplier activities?
Potentially, but do not infer the required permissions or structure from the group label. Map the two roles separately and establish the applicable requirements before carrying out either activity.
Does a white-label contract remove the brand’s responsibilities?
No contract label proves that. Examine the exact entity, customer relationship, authorisation scope, controls and target-market position. Responsibilities must be evidenced, not assumed.
Source history and scope
This guide gives no licence fees, processing times, market-access guarantee or conclusion that a proposed entity qualifies. For the regional context behind the example, consult the CGA online-gaming regulation page and current official instructions.
Discuss the implementation responsibilities
Bring the function map and confirmed scope to a platform discussion. Keep legal classification, licensing and official representations with the appropriate authorised specialists.
Discuss the lottery platform model