USSD Security Requirements for Banks and Fintechs in Ghana
USSD cannot be secured end to end, and no provider can sell you a version that is. So the useful question for a licensed institution is narrower: which legs of the path do you control, what does your regulator expect you to do about the leg you don’t, and can you evidence both?
This guide sets out the USSD security requirements for banks in Ghana from the deployer’s chair — the head of digital channels who signs the launch off, and the engineering lead who has to build it. If you are a customer rather than a deployer, read how to protect your mobile transactions from USSD fraud instead — it also answers whether USSD codes are safe to use. If you want the channel itself explained first, start with what USSD is and how it works.
Is USSD encrypted between the handset and the network?
No, and the precise version of that answer matters more than the folklore version. The Alliance for Financial Inclusion, in Guideline Note No.37 on cybersecurity for financial inclusion, records that there is no security from the customer’s handset right through to a mobile operator’s back office systems, which lets attackers eavesdrop on account details and PINs.
CGAP describes what that means in practice: USSD is the most common form of access to mobile money services in developing countries, and it does not offer much protection for those credentials. In CGAP’s 2018 analysis, someone using a laptop in a coffee shop can capture all of the USSD sessions (including PINs) for everyone using a nearby cell tower, and an insider with access to the operator’s network can quietly log credentials as customers enter them.
That leg is not yours. It runs across MTN, Telecel and AirtelTigo infrastructure, and nothing you configure changes its properties.
The leg you do own begins at the gateway. Every hop from your USSD gateway to your core banking or wallet application is your engineering decision and your regulatory exposure — and Bank of Ghana’s Cyber and Information Security Directive requires strong encryption standards and key management controls to secure the transmission of sensitive data through APIs, with information transferred over a wide area network or the internet encrypted at the highest level.
Separating those two legs is the entire discipline. One you compensate for. The other you engineer and document.
Can a USSD session be hijacked?
Two answers, and they point in opposite directions.
Not during a live session. 3GPP TS 23.090, published by ETSI as TS 123 090, at clause 5.2.5 on handling an unstructured SS operation at the handset, is explicit: if the handset receives a USSD transaction while another USSD transaction is already in progress, the handset shall reject the new transaction. An attacker cannot slide a competing menu into a session your customer already has open.
But yes, between sessions. The same specification, at clause 5.1 on handling network-initiated USSD, states that the network can at any time send a USSD operation towards a handset, and no prior provision of USSD is required. AFI documents exactly what that capability buys an attacker: they push a USSD session to the customer in a way that looks like the financial service provider is contacting them, use it to ask the customer to change their PIN, capture the new PIN, and take the account.
So your real exposure is impersonation between sessions, not interception inside one. Your customer has no way to tell a genuine prompt from a pushed one, which means the control has to sit in your systems rather than in the session.
How long does a USSD session stay open?
There is no standard USSD session timeout, and the specification sets no fixed length. ETSI TS 123 090, at clause 5.2.1 on invoking an unstructured SS operation from the HLR, makes the controlling network entity — the operator’s subscriber database, the HLR — responsible for the transaction: it normally releases the session once it receives a response, and may release it earlier if an application timer expires. No number of seconds appears anywhere in the document.
In practice the window is set by the mobile network operator and by your gateway configuration. Ask your provider for the value their platform applies, record it, and design your menu depth around it.
What actually binds you is different, and more useful. At Section 52, ‘Access Control’, paragraph 9, Bank of Ghana requires the institution to define session time-out criteria based on risk and technological considerations after a specified period of inactivity. The obligation is a documented, risk-based policy you can defend to an examiner — not a number somebody else picked.
Does Bank of Ghana regulate USSD security?
Not in the Cyber and Information Security Directive, which does not mention USSD anywhere in its text. That directive (March 2026) binds the institution rather than the channel, and every channel you launch inherits its obligations.
Section 2 of the directive, ‘Applicability’, extends it to institutions licensed or registered under the Banks and Specialised Deposit-Taking Institutions Act, 2016 (Act 930), institutions licensed under the Payment Systems and Services Act, 2019 (Act 987), and any other institution licensed or regulated by Bank of Ghana — collectively defined in the directive as Regulated Financial Institutions.
Read that scope closely, because it decides who answers for the channel. The obligation sits on the licensed bank, deposit-taking institution, payment service provider or electronic money issuer. It does not transfer to your USSD aggregator, and it does not reach a business running a shortcode outside the licensed perimeter. An aggregator that holds its own licence under Act 987 is bound in its own right, which still does not answer for yours. Your provider makes compliance easier or harder; it never holds your licence for you.
One connection worth knowing: Bank of Ghana is named among the AFI member countries that contributed to Guideline Note No.37. The USSD guidance quoted above was shaped in part by your own regulator, though contributing to a guideline note is not the same as adopting it as a directive.
The pre-launch USSD security checklist
The USSD security requirements for banks in Ghana come down to seven controls, six of them carrying a published obligation. Every row names the clause behind the control, so it can go into your control matrix and your next audit conversation as it stands.
| Control | What it means for a USSD deployment | Where the obligation comes from |
|---|---|---|
| Encrypt the API leg | Encrypt every hop between the USSD gateway and your core application. This is the segment of the path you control, and it is the one an examiner can test. | Bank of Ghana, encryption and cryptographic controls (Data in Transit) and Section 62, ‘Data Transfer Between Sites and Organisations’: strong encryption standards and key management controls to secure the transmission of sensitive data through APIs, and information carried over a wide area network or the internet encrypted at the highest level. |
| Document a risk-based session time-out policy | Write down your inactivity window, the risk reasoning behind it, and the gateway setting that implements it. Publish no number you cannot trace to your own configuration. | Bank of Ghana, Section 52, ‘Access Control’, paragraph 9: the institution must define session time-out criteria based on risk and technological considerations. |
| Log every transaction at application level | Capture each menu step, each authorisation decision and each failure in logs an investigator can read months later and a fraudster cannot edit. | Bank of Ghana, Section 43, ‘Auditing’, paragraphs 1-3: logging that is tamper-proof, with an audit log covering all activities carried out in the system at application level. |
| Lock out repeated failed attempts | Cap consecutive PIN failures on a shortcode and lock the account temporarily, then handle the session state cleanly on re-entry. | Bank of Ghana, Section 41, ‘Software Information Security’, paragraph 3: software must address session management and a mechanism for temporary access lockout after consecutive failed login attempts. |
| Apply multi-factor authentication to your own system access | This covers your staff, administrators and integrators reaching critical systems over the internet. It is not a rule that customers must add a second factor to a USSD menu. | Bank of Ghana, Section 42, ‘Application Programming Interface (API)’, paragraph 3(b), ‘Strong Authentication’: multi-factor authentication is mandated for access to critical systems and sensitive information via the internet. |
| Run active transaction monitoring centrally | Score transactions in your own systems in real time — velocity, value, device and beneficiary patterns — and stop the ones that fail. This is the compensating control for a channel you cannot secure end to end. | AFI Guideline Note No.37, Recommendation S-2, which carries two limbs: first, that detailed, active transaction monitoring is put in place in the provider’s central systems to identify and stop fraudulent transactions; second, that a strategy should be put in place to manage migration away from these exposed services. |
| Design PIN entry into the menu, not around it | Keep credential steps to the fewest screens, never echo entered digits back into a confirmation screen, and never carry a PIN in a menu string you later log. | An implementation and design decision rather than a directive clause — see our USSD menu design best practices. |
Engineering leads building the service itself will want our developer guide to creating a USSD code alongside this list. To see how session handling, timeouts and callbacks are configured in practice, work through the Arkesel USSD API documentation.
What you cannot engineer away
Three exposures survive everything on that checklist, and a compliance pack that pretends otherwise will not survive contact with an incident.
The handset-to-operator leg. AFI’s finding stands: no security exists across that stretch, and it belongs to the mobile network, not to you.
Proximity and insider capture. CGAP’s two scenarios — capture near a cell tower, and an insider on the operator’s network — sit outside your perimeter entirely.
SIM swap. A SIM swap transfers a mobile number from its original SIM to a new one, which is a legitimate service until someone misuses it to move a customer’s number without their knowledge. We cover the mechanics and the customer-side warning signs in our guide to protecting mobile transactions from USSD fraud.
The answer to all three is the same, and it is the first of the two limbs of AFI’s Recommendation S-2: active monitoring inside your own central systems. You cannot stop the credential being captured on a leg you do not own. You can stop the transaction that uses it.
S-2 does not stop there, and the second limb belongs in the record as AFI wrote it: a strategy should be put in place to manage migration away from these exposed services. Read together, the two limbs make central monitoring the control you run the channel with, not a permanent answer to what the channel exposes.
You are not buying an unbreakable channel. You are building the detection layer that makes a stolen credential worthless, and documenting it well enough for your auditor and your board.
Choosing a USSD partner that does not become your compliance gap
The directive binds you, but your provider decides how much of it you can actually evidence. Three things to test before you sign. If you have not secured the code itself yet, start with how to get a USSD shortcode for your business in Ghana.
Network connectivity. Arkesel connects directly to MTN, Telecel and AirtelTigo in Ghana, so session behaviour and delivery are handled on one platform rather than brokered through another aggregator’s stack. The Arkesel USSD platform is what runs underneath.
Certification you can put in a vendor file. Arkesel is ISO 27001 certified, which gives your third-party risk assessment a recognised control framework to reference instead of a questionnaire response.
Availability commitments in writing. Arkesel operates to a high-availability commitment. Treat that as an availability assurance, not a security control — a channel that is up is not automatically a channel that is safe, and your board will ask about both.
Run every shortlisted provider against our buyer’s checklist for choosing a USSD shortcode provider in Ghana, and ask each of them for the certificate and the network confirmations in writing before you commit. Ask Arkesel for ours and we will send them with a named contact for your third-party risk team. Current commercial terms sit on the Arkesel pricing page.
Frequently asked questions
What security controls does a bank need before launching a USSD service in Ghana?
Encryption of the API leg, a documented risk-based session time-out policy, tamper-proof application-level audit logging, lockout after consecutive failed attempts, multi-factor authentication on your own system access, and active transaction monitoring in your central systems. The first five map to Bank of Ghana’s Cyber and Information Security Directive; the sixth is AFI’s Recommendation S-2 for USSD, which pairs that monitoring with a second recommendation — a strategy to manage migration away from these exposed services.
Does the Bank of Ghana directive contain USSD-specific rules?
No. It never mentions USSD. It sets obligations on the institution, and those obligations follow whatever channel you deploy — USSD, app, web or branch.
Who is bound by the directive — us or our aggregator?
You are, if you hold a licence under Act 930 or Act 987 or are otherwise licensed or regulated by Bank of Ghana. Section 2 of the directive, ‘Applicability’, defines that group as Regulated Financial Institutions. Your aggregator is a third party you must manage, not a party the directive binds in your place.
What does a USSD audit trail need to include?
Bank of Ghana’s standard, at Section 43, ‘Auditing’, is application-level logging that covers all activities carried out in the system, held in a tamper-proof form. For a USSD channel that means each session, each menu step, each authorisation outcome and each failure — enough to reconstruct a disputed transaction without asking the mobile operator for help.
Is USSD too insecure for regulated financial services?
No. It is the channel most customers can actually reach, and its weaknesses are documented rather than mysterious. The institutions that deploy it well accept the exposure on the handset-to-operator leg, close everything from the gateway inwards, and monitor hard in the middle. For the wider deployment picture, see our guide to USSD payments and mobile money in Africa and the full guide to USSD for business in Africa.
Take the checklist into your next review
USSD security is not a feature you buy. Secure USSD transactions rest on three things: controls on the legs you own, a monitoring layer that catches what the other leg lets through, and a paper trail that proves both to Bank of Ghana.
Working through that list for a live or planned deployment? Talk to the Arkesel team about a regulated USSD deployment in Ghana and bring your control matrix — we will walk it clause by clause with your engineering and compliance leads.
5 SMS Campaigns Ghanaian Businesses Should Run This Easter
5 SMS Campaigns Ghanaian Businesses Should Run This EasterBusiness Tips/SMS MarketingJOJosephine OwusuaMarch 17, 20263 min readEaster…
WhatsApp Business API in Africa: Setup, BSPs & Pricing (2026)
WhatsApp Business API Africa: 2026 integration guide. Meta verification, BSP selection for MTN, Vodafone, AirtelTigo, templates,…
TechnologyTop 21 AI Prompts for Email to Boost Productivity
Top 21 AI Prompts for Email to Boost ProductivityTechnology/Business TipsATAbisola TanzakoOctober 30, 20258 min readAI prompts…
