Cybersecurity Investigation
A mobile money account is drained in a matter of minutes. The account holder gave their password to no one. They clicked on no link. Their phone never left their pocket.
So why did the money disappear?
For a long time, the instinctive answer came down to one word: hacking.
The word is almost as reassuring as it is alarming. It conjures the image of an attacker behind a screen, a software flaw, a compromised server, or an infiltrated app. It also implicitly suggests the solution: harden the servers, patch the code, install new protections.
But in the cases publicly reported in Côte d'Ivoire, that picture doesn't match what has actually been documented.
No compromise of an Ivorian telecom operator's or mobile money provider's IT systems is publicly established in the document reviewed. The reported mechanisms lie elsewhere: in the psychological manipulation of the victim, or in the takeover of their SIM card. In other words, the problem is not necessarily that an IT system was "broken." It may be that an identity was hijacked.
The Message Arrives Before the Call
The most disorienting part of the scene often begins with something perfectly legitimate.
An SMS arrives on the phone. A code has been sent.
A few seconds later, the phone rings.
On the other end, a caller introduces themselves as a customer service agent. They talk about security, an unusual transaction, a mandatory verification, or sometimes a transfer made by mistake.
The detail that makes the scam particularly effective is exactly the one the victim takes as proof.
The scammer knows the code that just arrived.
The SMS is genuine. It really does come from the service in question. The code is genuinely generated by the system. So this isn't a fake message fabricated by the attacker.
The fraudster simply triggered its issuance.
The victim then receives two simultaneous signals: an official message and a call that seems to confirm it. The brain naturally makes the connection: if he knows I just received this code, he must work for the service.
That's where the attack succeeds.
The technical system works. The app works. The server works. The code is valid.
It's the user's trust that gets hijacked.
VISUAL: The Social Engineering Chain
The key point in this pattern: the attacker doesn't necessarily manufacture the authentication factor; they push the victim into handing it over.
The Problem Sometimes Starts Before the First Call
To attack a system, you first need to know who to attack.
In the cases described, this phase can be surprisingly simple.
Fraudsters can test phone numbers within an app to identify which ones correspond to active accounts. That gives them a first, valuable piece of information: behind a given number, an account really does exist.
This is a form of account enumeration, a classic design flaw in consumer applications.
From there, the attack is no longer blind.
It can become targeted.
A known number.
An identified account.
A selected target.
Then a prepared psychological script.
In this setup, the attacker doesn't even need to penetrate deep into the system. Sometimes it's enough to understand how the system reacts and how the user interprets that reaction.
This is a fundamental difference.
In a classic cyberattack, the goal is often to deceive a machine.
Here, the goal is to make the human being unknowingly cooperate with the machine.
The Second Scenario Is Even More Concerning
There is an attack that doesn't even require the victim to disclose their code.
It's called SIM swapping.
The principle is simple: the attacker obtains a new SIM card matching the victim's number. Once the line is transferred to this new SIM, the legitimate phone can lose network access while the attacker starts receiving the communications meant for that number.
At that moment, the phone is no longer just a phone.
It becomes the gateway to a digital and financial identity.
The reported attack chains follow several steps: identifying a target, gathering information, using fake documents, having the SIM reissued at a point of sale, then taking control of the services tied to the number. In some reported cases, internal complicity is also mentioned.
The most important detail is this:
the victim may have done absolutely nothing wrong.
They didn't share their OTP.
They didn't click on a link.
They didn't lose their phone.
Yet their account can still be compromised.
This is why SIM swapping is a far deeper architectural problem than a simple phone scam.
VISUAL :
The Mobile Money Paradox: Finance Depends on the Telecom Network
This is where things get interesting for cybersecurity architects.
An e-money institution can be subject to strong obligations around security, customer protection, and compliance. But the trust mechanism that lets a user prove they control their account rests largely on something external: their phone number.
Yet that number belongs, technically and operationally, to the telecom world.
The fintech can protect its app.
It can encrypt its communications.
It can harden its APIs.
It can multiply its anti-fraud controls.
But if a third party manages to get the number reassigned to another SIM card, part of that trust architecture collapses.
This is what the document describes as an externalized root of trust: the security of the financial account depends on an actor outside the financial system, on its procedures, its points of sale, its identity checks, and even the behavior of its agents.
In other words, the weak link isn't necessarily in the server.
It can be at the counter.
The Real Problem With the OTP
In many architectures, the OTP sent by SMS is still presented as an authentication factor.
Yet the term deserves scrutiny.
An SMS code has one fundamental characteristic: the user can read it and repeat it.
As soon as an attacker manages to convince the person on the other end to hand over that code, the mechanism offers no resistance whatsoever to voice phishing.
The document goes further: in this context, the SMS OTP functions more like a notification channel repurposed into an authentication factor.
The distinction may sound semantic. It isn't.
A genuine authentication mechanism must provide proof that is hard to hand off to a third party.
A code that can be read on screen and then recited over the phone doesn't have that property.
VISUAL: Two Trust Models
So the change isn't purely technological.
It means replacing proof that's easy to hand over with proof tied to the device and the context of the transaction.
The Control That Could Change Everything: Detecting a SIM Change
For cybersecurity teams, one approach emerges with almost obvious logic: before authorizing a sensitive transaction, check whether the SIM has just been replaced.
The document proposes monitoring, in particular, changes associated with the number's IMSI and ICCID.
The principle is simple.
If a SIM has just been reissued, the risk of fraudulent takeover rises sharply.
This information can be provided by the operator through a dedicated service such as a SIM Swap API, or approximated indirectly by combining other behavioral signals when operator data isn't available.
But the most interesting control may not be the detection itself.
It's what comes next.
The cooling-off period.
After a SIM reissue, why allow an unusually large transfer immediately?
The proposed principle is to suspend or heavily restrict certain financial operations for a period of 24 to 72 hours.
This delay turns a telecom incident into a window of defense.
The victim who has just lost network access then has time to notice the anomaly, contact their operator, and secure their accounts.
Without this delay, the two events SIM reissue and wallet drain can happen back-to-back within minutes.
When Weak Signals Tell the Whole Story
An anti-fraud architecture doesn't need to wait for the perfect fraudulent transaction.
It can watch for a combination of several anomalies.
A very recent SIM change.
A new device.
An exceptionally high amount.
Several new beneficiaries created within minutes.
A wallet almost entirely drained.
Taken separately, each of these events can be legitimate.
Taken together, they tell a different story.
This is exactly where behavioral detection comes in.
The document proposes a scoring approach where several signals are combined before triggering a block or step-up authentication. The most discriminating signals identified include a recent SIM change, near-total balance drainage, a rapid increase in beneficiaries, and a recently created beneficiary.
VISUAL: Risk Heat Map
Low risk
Usual device + unchanged SIM + known beneficiary + usual amount
↓↓↓
Intermediate risk
New device + unusual amount
↓↓↓
High risk
Recently replaced SIM + new device + new beneficiary + massive fund outflow
↓↓↓
Action
Block / out-of-band verification / independent confirmation
The Breaking Point May Lie With the Operator
This is probably the least visible part of the problem.
Public discussion often focuses on the fintech, its app, its servers, and its authentication mechanisms.
But in the case of SIM swapping, a decisive part of security plays out elsewhere: in the SIM reissue process.
Who requested the new card?
Which agent processed the request?
At which point of sale?
At what time?
What document was presented?
What verification was performed?
These events must be traceable.
The document specifically stresses the need for strong authentication at the counter, named logging of every reissue, and detection of atypical behavior across the distribution network. A point of sale whose reissue volume diverges sharply from its peers becomes a risk indicator in itself.
Cybersecurity, then, is no longer limited to code.
It extends all the way down to the counter.
And Yet the Phenomenon Remains Poorly Measured
This may be the most serious problem of all.
You can protect a system.
You can audit a system.
You can invest in a system.
But if incidents aren't measured properly, there's no way to know whether the measures taken are actually working.
The document notes that the general cybercrime statistics available in Côte d'Ivoire are improving: complaints, processed cases, and overall damages are documented.
But this data lumps together very different categories: online scams, fake transfer orders, identity theft, cyberstalking, and other offenses.
Mobile money fraud, and within it the share attributable to SIM swapping, is therefore not isolated with enough granularity in the public statistics cited.
This is as much an engineering problem as a governance one.
Without sufficiently precise data, it's impossible to answer questions that are nonetheless basic:
What proportion of losses comes from SIM swapping?
How many incidents could have been prevented by a cooling-off period?
How many cases involve social engineering?
How many are linked to internal fraud within distribution networks?
And above all: who pays when the victim did nothing wrong?
This last question goes straight to how risk is shared between the user, the e-money institution, the telecom operator, and the distributors. The document notes that this allocation is not publicly established with sufficient precision.
The Detail Users Often Overlook
Imagine a user whose phone suddenly loses network signal.
No outage has been announced.
The people around them have normal reception.
They don't.
In many cases, the first reaction is to wait.
Restart the phone.
Move to another room.
Check the settings.
Wait a bit longer.
But in a SIM swap scenario, that lost minute can carry a real financial cost.
The document specifically recommends treating an unexplained loss of network signal as a financial emergency signal, not just a technical glitch. The call to the operator and to the mobile money service should then be made from another phone.
In the end, this recommendation sums up the whole issue.
Mobile money isn't just a wallet on a phone.
It's a financial identity attached to telecom infrastructure.
West Africa Has Won Financial Inclusion. It Now Needs to Win Identity Assurance.
The strength of mobile money lies precisely in its simplicity.
No bank counter.
No complex paperwork.
A phone.
A number.
A code.
A few seconds.
It's exactly this simplicity that fueled the explosion in usage.
But it also creates a structural constraint: reducing friction sometimes means reducing the evidence the system has to know who is actually behind a transaction.
A phone number is public. It circulates. It can be shared. It can be reassigned. Its ownership can be transferred by the operator.
Making it the central proof of financial identity therefore means accepting that the wallet's security depends on something the user doesn't fully control the lifecycle of.
The real challenge, then, isn't making mobile money more complicated.
It's making sure security stays strong enough without shifting all the responsibility onto the user.
This is where device binding, in-app validation, behavioral detection, SIM swap detection, and cooling-off periods start to make sense.
The False Debate Over "Hacking"
Let's finally come back to the word we started with: hacking.
In everyday usage, it means almost anything that happens when an account is drained without authorization.
In the language of cybersecurity, that vagueness becomes dangerous.
Because if you picture a server intrusion when the real attack runs through identity, you end up looking for the solution in the wrong place.
You harden the wrong perimeter.
You fund the wrong controls.
You measure the wrong risk.
And meanwhile, the attack will keep running through the phone, the SIM, the point of sale, the code, and human trust.
The document reviewed therefore puts forward a central thesis worth remembering well beyond the Ivorian case:
a phone number should be treated as an identifier, not as sufficient proof of authentication.
And when a financial system turns that number into the control key for a wallet, it must own the architectural consequence that follows.
The next battle for mobile money may not be fought over servers.
It will be fought over identity.
And on that battlefield, the question is no longer simply how to stop someone from hacking a system.
The question is much simpler, and much harder:
how can you be certain that the person who controls the number is still truly the one who owns the money?
Don't forget to contact us if you need IT solutions to manage your business.