This document provides implementation guidance for the nationwide revenue collection system designed for Nigeria’s gaming industry, referred to as Revenue Pulse. Revenue Pulse is a centralized compliance framework that enables regulators to track and validate gaming transactions across all licensed operators in Nigeria. Its purpose is to ensure transparency, accountability, and accurate reporting of revenue generated within the industry.

As part of your compliance obligations, operators are required to expose compliance API endpoints that will make user betting and operational data available for ingestion by Revenue Pulse. These endpoints must provide collated data on a daily basis—or in exceptional circumstances, on a weekly basis as approved. This document outlines the technical specifications, data models, and integration requirements necessary for successful implementation, ensuring that your systems remain fully compliant with national regulatory standards.

Assumptions

In order to achieve compliance with the Revenue Pulse system, the following baseline assumptions must hold true for all operators. If your internal systems do not currently meet these assumptions, they must be implemented before integration.

  1. Public IP Address Capture – All online interactions with your gaming service must capture the user’s public IP This information is required as part of the compliance data set.
  2. Unique Wallet Identifier – Every user account must be associated with a unique wallet identifier. This ensures accurate tracking and prevents data duplication.
  3. User Resident State – Each user’s state of residence must be captured and reported using the official state codes listed in the Annex.
  4. User Full Name – If full names are captured in your system, they must be included in compliance data. Where names are not captured, a consistent placeholder must be used (e.g., “John Doe” or “Jane Doe”). The placeholder must remain constant across all compliance windows to avoid ambiguity.

Failure to implement these assumptions will prevent compliance integration. Operators are therefore mandated to meet these requirements as the first step in their compliance journey.

Scope & Audience

This document is intended for the technical teams of licensed gaming operators in Nigeria who are responsible for system integration, data management, and regulatory compliance. It provides

the detailed requirements for exposing compliance API endpoints, structuring data payloads, and ensuring secure, verifiable transmission of betting and operational records.

The scope of this document is limited to the technical implementation of compliance endpoints for integration with the Revenue Pulse system. It does not cover business processes, financial reporting methodologies, or legal interpretations of compliance obligations. Instead, it focuses exclusively on the data model, API structure, validation rules, and operational standards required to meet regulatory expectations.

The following are the key stages to understand

  1. Data aggregation
  2. Data integrity and Verifiability (operations tag)
  3. Data Windowing (daily or weekly)
  4. Data Check
  5. Data Model

Data Collation

Operators are required to collate all user betting activities on a daily basis, covering the period from 00:00 to 23:59 for each calendar day. The aggregated data must be made available via the compliance API endpoint to be pulled by our systems.

Required Data Points

The data payload must include the following fields for each bet record:

Field Name

Type

Required

Description

wallet_id

String

Yes

Unique identifier for the user’s betting

   

wallet.

user_fulname

String

Yes

User’s full name as registered with the

   

operator.

user_country

String

Yes

Two-letter country code (NG).

user_state

String

Yes

Two-letter state code (see Annex).

user_mobile

String

Yes

User’s phone number in E.164 format (e.g.,

   

+2348012345678).

event_id

String

Yes

Identifier for the gaming event (as defined in

   

the Data Model section).

event_type

String

Yes

The type of gaming event e.g. football, golf, etc.

event

Model

Yes

The JSON data object containing additional

   

information about the game event.

total_odds

Float

Yes

Total odds associated with the bet.

total_stake

Float

Yes

Amount wagered by the user.

total_payout

Float

Yes

Payout amount for the event (0 if none).

ip_address

String

Yes

Public IPv4/IPv6 address at time of bet.

season

String

Yes

The year the gaming session took place.

bet_status

String

Yes

Must be either WON or LOST.

created_on

Date Time

Yes

Date and time of the event in ISO 8601 format.

Data Format
Data Integrity & Verification (Operations Tag)

To guarantee the integrity and verifiability of submitted data, each collated batch of bets must be signed and tagged. This ensures that the data received from your compliance API endpoint is complete, untampered, and independently verifiable by external systems.

Process Overview
  1. Hashing
    • The entire bets JSON payload only must be serialized in a canonical form:
      • UTF-8 encoding
      • Sorted by creation data and time
      • No extra whitespace beyond standard JSON formatting
      • A SHA-256 hash is generated over this canonical JSON
  1. Encoding
    • The resulting 32-byte SHA-256 hash must be encoded as a Base32z string

(Crockford’s human-friendly Base32 variant).

  • This encoded value is referred to as the Operations
  1. Inclusion
    • The Operations Tag must be included in the submission:
      • As a top-level field (opt_tag) in the JSON payload, and
  1. Verification
    • Regulators or external systems can reproduce the hash from the received payload and compare it against the supplied Operations Tag. A mismatch indicates data tampering or an invalid payload.

Field Definition

Field Name Type Required Description

opt_tag String Yes Base32z-encoded SHA-256 hash of the payload, used for verification

				
					Step 1: Payload Serialization
Only the top-level JSON ‘bets’ array data (green color) is to be serialized
{
...
"bets": [
    {
    "wallet_id": "USR987654", "full_name": "John Doe", "state_code": "LA", "stake_amount": 1000.00,
    "payout_amount": 3500.00
    }
    ]
}
Data Windowing

The default data collation window is daily. Operators must submit data covering 00:00 to 23:59 for each day. In exceptional circumstances where daily data cannot be generated (e.g., system downtime, force majeure), a weekly window may be temporarily allowed. This means that, by default, all operators must make daily user betting data available for compliance API collection.

Field Name

Type

Required           Description

 

opt_date

 

Date Time

The date and time of the operation (i.e., when

Yes                     data was collated). Must use ISO 8601 format

(e.g., 2025-09-05T23:59:59Z).

 

 

The window index:

window

Integer

Yes                     • For daily windows: day of year (1–365/366).

•  For weekly windows: week of year (1–52,

 

 

ISO 8601 standard).

window_class

String

Yes                     Must be “daily” or “weekly”, depending on the

				
					Example (Daily Window)

{
...
"opt_date": "2025-09-05T23:59:59Z",
"window": 248, "window_class": "daily", "bets": [
{
"wallet_id": "USR987654", "event_id": "EVT20250905-001",
"total_stake": 1000.00,
"total_payout": 3500.00
}
]
}
Compliance Notes
  • The daily window is mandatory unless explicit approval is granted for weekly
  • Weekly collation is a temporary exception and must revert to daily as soon as the exceptional condition ends.
  • Operators must ensure that opt_date, window, and window_class are populated correctly for every collation.
  • Incorrect or missing window metadata will result in an annulled
Data Check

Operators must expose two compliance API endpoints to allow regulators to validate and pull collated betting data. These endpoints extend the operator’s existing API structure.

Endpoints

1.  Meta Check Endpoint

URL Structure

				
					https://{baseApiUrl}/compliance/metacheck/{nuance}

Call Frequency: Every 8 hours (3 times per day). Expected Response:

  • Must return the Operations Tag of the most recent collated
  • This enables regulators to verify whether new data is available without pulling the full
Example Response:
				
					{
"nuance": 10245,
"opt_tag": "9h4z6t1r5p8k0w7x2y..."
}

2. User Betting Data Endpoint

URL Structure:

				
					https://{baseApiUrl}/compliance/userbetings/{nuance}

Call Frequency: Once for every collated dataset.

Expected Response:
  • Must return a valid JSON data object containing the full dataset in the format outlined in the Data Model

Example Response (truncated):

				
					{
" nuance": 10245,
"opt_tag": "9h4z6t1r5p8k0w7x2y...", "opt_date": "2025-09-05T23:59:59Z",
"window": 248, "window_class": "daily", "bets": [
{
"wallet_id": "USR987654", "user_fulname": "John Doe", "user_state": "LA", "total_stake": 1000.00,
"total_payout": 3500.00
}
...
]
}

Nuance Handling

Nuance Definition:

A constant numeric value uniquely associated with each operator.

Purpose:

Used as a lightweight validation mechanism to confirm request authenticity.

Implementation:
  • Operators must include the same nuance value as a URL parameter and as a top- level JSON field in every response.
  • The operator may choose to validate the nuance before returning a
Assignment:

The regulator will assign a unique nuance value to each operator.

Compliance Notes
  • The Meta Check endpoint must be available and respond within 700 milliseconds to ensure timely verification.
  • The User Betting Data endpoint must return the most recent collated dataset from the last completed window within 6000 milliseconds. If an operator’s system cannot meet this time requirement, the data collation may be split into 2–3 batches, ensuring no

overlaps, as overlaps may count double against the operator.

  • Any mismatch between the Operations Tag reported by /metacheck and the data returned by /userbetings will be flagged as a compliance violation.
Data Model

Operators must implement and maintain the following JSON data model. This schema represents the exact structure regulators will pull through the compliance API.

Compliance Requirement:
  • Any deviation (e.g., malformed JSON, missing required fields, invalid types) will be treated as non-compliance for the respective reporting window.
  • An email notification will be sent to the operator specifying the ingestion
  • Operators must fix and resubmit within the compliance window. Persistent failures will be deemed a deliberate attempt to avoid compliance.

JSON Structure

				
					{
"nuance": 2025609812398610000,
"operator": "Naija CollBet", "domain": "www.naijacoolbet.com", "year": 2025,
"opt_tag": "bw4ogkry58ikqc4tgnjeg54hp466zii5xeyanu7aezxniw9gh9ho", "opt_date": "2025-09-05T12:02:09.5958659Z",
"window": 5, "window_class": "daily", "bets": [
{
"wallet_id": "BTX8900", "user_country": "NG", "user_state": "LA", "user_fullname": "Joey Jacs", "user_mobile": "07035401400",
"ip_address": "102.88.114.7",
"season": "2025", "event_id": "ED3209993", "event_type": "football", "event": {
"league": "Professional Development League", "fixture": "Ipswich U23 vs Coventry City U23", "location": "London"
},
"ticket": "7E9-162F6887",
"total_odds": 14.03,
"total_stake": 120,
"total_payout": 1700.436, "bet_status": "Won",
"created_on": "2025-07-28T17:12:13.163837Z"
}
]
}

Field Specifications 

Field

Type

Required

Description

nounce

Number (int64)

⬛

Unique constant numeric identifier per operator (assigned by regulator)

operator

String

⬛

Registered operator name

domain

String

⬛

Primary domain used by the operator

year

Integer

⬛

Reporting year

opt_tag

String

⬛

Operations tag (SHA-256 → Base32z encoded; see Data Integrity)

opt_date

DateTime

⬛

Timestamp of data collation (UTC recommended, ISO 8601 format)

window

Integer

⬛

Time window: Daily → day of year (1–365/366); Weekly → week of year (1–52)

window_class

String

⬛

Window classification (daily, weekly)

bets

Array

⬛

Collection of user bets

Bet Object

Field

Type

Required

Description

wallet_id

String

⬛

User’s wallet/account identifier

user_country

String

⬛

User’s country code (ISO 3166-1 alpha-2)

user_state

String

⬛

User’s state of residence (state code per Annex)

user_fullname

String

⬛

User’s full legal name

user_mobile

String

⬛

User’s mobile number (MSISDN format recommended)

ip_address

String

⬛

Public IP address tied to the event (required for all online activities)

season

Integer

⬛

Season or gaming year

event_id

String

⬛

Unique identifier of the gaming event

event_type

String

⬛

Type of event (e.g., football, casino)

event

Object

⬛

Event details (league, fixture, location)

ticket

String

⬛

Unique bet/ticket identifier

total_odds

Float

⬛

Total odds of the bet

total_stake

Float

⬛

Amount wagered

total_payout

Float

⬛

Total payout (0 if lost)

bet_status

String

⬛

Outcome of the bet (Won, Lost)

created_on

DateTime

⬛

Bet creation timestamp (ISO 8601)

Annex

The following annexes provide reference information to support consistent implementation of the compliance endpoints. Operators should strictly adhere to these specifications when preparing and submitting data.

Annex A: Nigerian State Codes

Operators must use the official two-letter state codes offered by the Nigerian Federal Government when populating the user_state field. The table below is only a sample.

State

Code

State

Code

Abia

AB

Kebbi

KE

Adamawa

AD

Kogi

KO

Akwa Ibom

AK

Kwara

KW

Anambra

AN

Lagos

LA

Bauchi

BA

Nasarawa

NA

Bayelsa

BY

Niger

NI

Benue

BE

Ogun

OG

Borno

BO

Ondo

ON

Cross River

CR

Osun

OS

Delta

DE

Oyo

OY

Ebonyi

EB

Plateau

PL

Enugu

EN

Rivers

RI

Edo

ED

Sokoto

SO

Ekiti

EK

Taraba

TA

Federal Capital

FC

Yobe

YO

Gombe

GO

Zamfara

ZA