What Is USSD? The Complete Technical Architecture

The SS7 Signaling Path

USSD (Unstructured Supplementary Service Data) is a real-time, session-based protocol that runs on the GSM signaling channel, not the voice or data channel. When a user dials *123#, the request never touches the internet. It travels through the SS7 (Signaling System 7) network:

1. Handset: The phone encodes the USSD string and sends it as a signaling message over the radio interface
2. BTS (Base Transceiver Station): The cell tower forwards the signaling message to the BSC (Base Station Controller)
3. MSC/VLR (Mobile Switching Centre / Visitor Location Register): The MSC identifies the subscriber via IMSI lookup on the VLR and routes the USSD request
4. HLR (Home Location Register): The HLR checks the subscriber's profile and determines which USSD gateway should handle the shortcode
5. USSD Gateway: The telco's gateway terminates the SS7 signaling and converts the request into an HTTP callback (webhook) to the application server
6. Application Server: Your code receives an HTTP POST, processes the request, and returns a text response with a CON (continue session) or END (terminate session) flag

The entire round trip happens inside the GSM signaling layer. The user's phone doesn't need a data connection, a SIM with an active data plan, or even airtime balance in most markets. The protocol predates mobile internet by over a decade.

MAP Protocol: The Wire Format

USSD messages are carried inside MAP (Mobile Application Part) operations over TCAP (Transaction Capabilities Application Part). The key operations:

• ProcessUnstructuredSS-Request: Initiated by the handset when the user dials a USSD string. Carries the dialed code and subscriber identity (MSISDN/IMSI)
• UnstructuredSS-Request: Sent from the network to the handset to display a menu and collect input (the "continue" response)
• UnstructuredSS-Notify: Sends a one-way notification to the handset with no input expected (the "end" response)

These MAP operations ride on TCAP transaction primitives:

• TC-BEGIN — Opens a new USSD dialogue
• TC-CONTINUE — Extends the dialogue (each menu interaction)
• TC-END — Closes the dialogue gracefully
• TC-ABORT — Terminates the dialogue abnormally (timeout, network error)

Developers never interact with MAP or TCAP directly. Aggregators like Africa's Talking, Infobip, and Arkesel abstract all of this behind a simple HTTP API. But understanding the wire format explains why USSD behaves the way it does: the 180-second session limit, the 160-character payload ceiling, and the binary CON/END response model are all constraints inherited from MAP.

The Stateless Paradox

USSD is session-based at the network level but stateless at the application level. The SS7 network maintains the dialogue (TC-CONTINUE keeps the session open), but the HTTP webhook to your application server is a fresh POST request every time the user responds. Your server receives:

• sessionId — Unique identifier for this USSD session
• phoneNumber — The subscriber's MSISDN
• serviceCode — The shortcode dialed (e.g., *644#)
• text — The user's cumulative input, concatenated with asterisks

On first dial, text is empty. After the user selects option 1, text becomes "1". After they then enter an amount, text becomes "1*500". Each asterisk-delimited segment represents one interaction step.

The network doesn't remember what menu the user is on. Your application must reconstruct the entire journey state from the concatenated text string or from a server-side session store. This is the fundamental architectural challenge of USSD development.

The CON/END Developer Interface

Aggregators bridge the SS7 protocol to HTTP using a simple convention:

• CON (Continue): Your response starts with CON followed by the menu text. The network keeps the session open and waits for user input. Maps to MAP UnstructuredSS-Request.
• END (End): Your response starts with END followed by a final message. The network terminates the session. Maps to MAP UnstructuredSS-Notify.

Africa's Talking uses this exact convention. A minimal USSD handler:

Every CON response must fit within 160 characters (GSM-7 encoding) or 70 characters (UCS-2 for non-Latin scripts). Every response must return within 10-15 seconds or the gateway times out.

Redis-Backed Session Management

The text-concatenation approach works for simple menus but breaks on complex journeys. When a user is 6 screens deep and enters invalid input, the concatenated string is polluted. Production USSD platforms use server-side session stores.

Redis is the standard choice because relational databases are too slow for the 10-second response budget. Redis delivers sub-millisecond reads. The pattern:

• Key: ussd:session:{sessionId}
• Value: JSON object containing menu_level, temp_data (partial inputs like bet amount, match selection), last_activity timestamp
• TTL: 180 seconds, matching the maximum USSD session duration. Redis automatically expires stale sessions.

On each webhook callback, the handler loads the session from Redis, determines the current state, processes the input, updates the state, and returns the next screen. The entire cycle must complete in under 10 seconds.

USSD vs STK: Why Safaricom Chose Differently

SIM Toolkit (STK) is often confused with USSD. They serve overlapping use cases but the architectures are fundamentally different.

Safaricom chose STK for M-Pesa because they are the carrier. They control the SIM. They can push applet updates over-the-air. STK gives them a faster, more reliable UX with fewer network round-trips.

Every other operator in Africa that doesn't control the SIM uses USSD. Betting operators, fintechs, and third-party services cannot deploy STK applets without a carrier partnership that most will never get. USSD is the only channel that any developer can access through an aggregator API.

SS7 Security: The Plaintext Problem

SS7 was designed in the 1980s when the only entities on the signaling network were trusted telcos. It has no encryption, no authentication, and no integrity checking. USSD payloads travel in plaintext across every node in the SS7 path.

This creates real vulnerabilities:

• Eavesdropping: Any entity with SS7 network access can intercept USSD sessions, including the one-time PINs used for mobile money authentication
• SIM swap fraud: An attacker convinces the carrier to transfer a victim's number to a new SIM. All USSD sessions (including mobile money) now route to the attacker's device. This is the #1 fraud vector in African mobile financial services
• Session hijacking: Malicious SS7 nodes can inject responses into active USSD sessions

The industry response is shifting to API-based verification. GSMA's CAMARA initiative provides:

• SIM Swap API: Check if a subscriber's SIM was recently changed before authorising a transaction. If the SIM was swapped in the last 24-72 hours, flag the transaction for additional verification
• Number Verification API: Silently verify that the device making a request is actually using the claimed phone number, without sending an OTP over the vulnerable SS7 channel

Network-Initiated USSD (Push USSD)

Standard USSD is mobile-initiated: the user dials a code. But the protocol also supports network-initiated sessions where the server pushes a USSD menu to the handset without the user dialing anything.

The MAP operations for push USSD are:

• UnstructuredSS-Request (USSR) — Push a menu to the handset and wait for input
• UnstructuredSS-Notify (USSN) — Push a one-way notification (no input expected)

Push USSD is used for balance alerts, promotional messages, and transaction confirmations. In betting, it enables real-time win notifications: the platform pushes a USSD notification when a bet settles, and the user can immediately trigger a withdrawal from within the same session.

Carrier support for push USSD varies. Not all aggregators offer it, and some MNOs restrict it to approved enterprise partners.