G. Mobile money and agents

Mobile money is the main way many people in Ghana and West Africa send and keep money, through wallets such as MTN MoMo, Telecel Cash and AT Money, and a large network of agents who turn cash into e-money (cash-in) and back again (cash-out).

That makes it a target. Agents can be complicit or careless; SIM cards can be hijacked; wallets can be used to collect and sweep fraud proceeds. These rules are designed for those risks and ship in the gh-psp pack for Ghanaian PSPs and mobile money operators.

Values here are examples

Values on this page illustrate how the rules behave; see Tuning and calibration.

Rules in this category

ID	Rule	Mode	Status
G1	Agent cash-in volume anomaly vs peer agents	SCH	Ships (gh-psp, scheduled daily)
G2	Agent cash-out immediately after cash-in for same wallet	PE	Ships (gh-psp, post-event)
G3	SIM swap or recent number change, then high-value transfer	RT	Ships (gh-psp 1.1.0, real-time)
G4	Wallet-to-bank sweep after many inbound P2P	PE	Ships (gh-psp, post-event)
G5	Reversal or refund abuse	PE/SCH	Ships (gh-psp, post-event)
G6	Large mobile money transfer at night	PE	Ships (gh-psp, post-event)

---

G1 Agent cash-in volume anomaly vs peer agents

Ships today: gh.agent_peer_anomaly in the gh-psp pack

Scheduled, every day at 05:00. Fires on an agent whose customers cashed in at least GHS 50,000 at it over the last 7 days, at least 3 standard deviations above the average of at least 10 other agents in the same region. The alert is about the agent: its account when the agent is one of your own accounts, otherwise the agent as a counterparty. Exact defaults and logic: Pack contents.

What it looks for: an agent whose cash-in volume is far out of line with similar agents: agents in the same region or of the same tier. An agent processing several times more cash than its neighbours may be placing cash for someone, or splitting a large customer’s deposits.

Example

With the defaults (window_days 7, zscore 3, min_peers 10, min_volume 50,000, peer_group region):

• ✅ Fires: an agent in Techiman takes GHS 900,000 of cash-ins in a week, when the 24 other agents in the Bono East region average GHS 150,000 with a standard deviation of GHS 60,000: that is 12.5 standard deviations above its peers.
• ❌ Does not fire: the same agent in a region with only 6 other agents (fewer than min_peers): the comparison isn’t reliable.

Parameters

Parameter	Meaning	How to tune
window_days	The period, in days (1 to 90)	A week evens out market days
zscore	Standard deviations above the peers, at least (1 to 20)	3 is a common starting point; lower catches more
min_peers	Other agents in the peer group, at least	Small groups give unstable averages
min_volume	The agent’s cash-in volume at or above (base currency)	Keeps quiet agents in quiet regions out
peer_group	The attribute that names an agent’s peer group, for example region or tier	Pick groups that really are comparable: a market-town agent and a rural agent are not

How agents and peer groups are found. An agent is the counterparty of your customers’ cash_in transactions. Its peer group is read from the attribute named in peer_group, looked for in this order: on the agent’s own account (when the agent’s account number is one of your accounts), then on that account’s customer, then on the cash-in itself. Agents with none are compared with all agents together. Each agent’s average and spread are worked out without that agent, so one very large agent can’t hide inside its own average.

Mode and pack: scheduled, every day at 05:00 (daily 05:00), in gh-psp 1.2.0. See Scheduled rules. Once it has flagged an agent, it doesn’t flag it again until a whole window has passed.

False positives: agents in markets or transport hubs, and super-agents. Put them in their own peer group with the attribute.

Data it needs: cash_in transactions with the agent as the counterparty, and a peer-group attribute (for example "region": "Bono East") on the agent’s account, its customer or each cash-in.

---

G2 Agent cash-out immediately after cash-in for same wallet

Ships today: gh.cash_out_after_cash_in in the gh-psp pack

Looks at the same wallet over 2 hours: cash-in of at least min_amount (GHS 3,000), then cash-out of at least ratio (0.8) of it. It doesn’t check whether the same agent handled both. Exact defaults and logic: Pack contents.

What it looks for: money cashed in to a wallet and cashed out again at an agent shortly afterwards. Legitimate customers rarely do this. It is used to convert stolen e-money into cash, or to disguise where cash came from.

Example

With window 2 hours and min_amount GHS 2,000:

• ✅ Fires: a wallet receives GHS 4,000 cash-in at 14:10 and GHS 3,900 is cashed out at a different agent at 14:45.
• ❌ Does not fire: cash-in in the morning, spent on bills and airtime.

Parameters

Parameter	Meaning	How to tune
window	Time between cash-in and cash-out	Minutes to hours
min_amount	Minimum amount	Keep small everyday amounts out

Mode and pack: post-event.

Same agent or different agent?

Cash-in and cash-out at the same agent within minutes can be a sign of agent-side fraud (fake transactions to earn commission). At different agents it looks more like cashing out proceeds. Both are worth reviewing; look at which agents were involved.

Data it needs: agent for each cash-in and cash-out, amount, timestamps.

---

G3 SIM swap or recent number change, then high-value transfer

Ships today: gh.sim_swap_payout in the gh-psp pack, from version 1.1.0

Real-time, answers block. Fires on a payout of at least threshold (default GHS 200) when the customer’s latest SIM swap was less than sim_change_hours (default 48) hours earlier. It reads sim_swap account events; a phone-number change on its own is covered by H5. The explanation gives the real hours since the swap, for example SIM swapped 2.33 hours before this payout of GHS 6,000 (rule window: 48 hours) (from gh-psp 1.1.1; see Pack contents if you installed earlier). Workspaces that installed gh-psp 1.0.0 get the rule by upgrading the pack. Exact defaults and logic: Pack contents.

What it looks for: a large transfer shortly after the wallet’s SIM card was replaced or its phone number changed. SIM swap fraud works by convincing the mobile network to move a victim’s number to a new SIM, then using it to receive OTPs and empty the wallet.

Example

With sim_change_hours 48 and threshold_amount GHS 1,500:

• ✅ Fires: the SIM was replaced at 09:00; at 11:20 a GHS 6,000 transfer to a new recipient is attempted.
• ❌ Does not fire: a GHS 1,500 transfer a week after a SIM replacement.

Parameters

Parameter	Meaning	How to tune
sim_change_hours	How long after a SIM change the rule is watching	24–72 hours are common
threshold_amount	Transfer amount that triggers it	Relatively low — victims are often emptied completely

Mode and pack: real-time, so the transfer can be blocked, held or stepped up before it happens. Ships in gh-psp 1.1.0.

G3 needs SIM-swap events

SpeculaPro can’t know about a SIM swap unless you tell it. Send a sim_swap account event as soon as the mobile network reports one, with the time the swap happened. Without them, G3 never fires.

Data it needs: sim_swap account events, and payouts sent through a real-time decision.

---

G4 Wallet-to-bank sweep after many inbound P2P

Ships today: gh.wallet_sweep_to_bank in the gh-psp pack

Defaults: min_senders 10 over 7 days and sweep_ratio 0.7. Counts outflows by bank_transfer or instant_payment. Exact defaults and logic: Pack contents.

What it looks for: a wallet that receives many person-to-person transfers and then sweeps most of the balance to a bank account in one go — moving collected money out of mobile money into the banking system.

Example

With min_inbound 15, window 7 days and sweep_pct 80%:

• ✅ Fires: 22 incoming P2P transfers (GHS 11,000) during the week, then GHS 10,000 transferred to a bank account over GhIPSS.

Parameters

Parameter	Meaning	How to tune
min_inbound	Number of incoming P2P transfers	Higher for traders who are paid by mobile money
window	The period	Days to weeks
sweep_pct	Share of the inbound total swept to a bank	70–90% are typical values to test

Mode and pack: post-event, in gh-psp.

False positives: small businesses moving their takings to the bank. Compare with I3.

Data it needs: channel (P2P vs wallet-to-bank), counterparties, amounts.

---

G5 Reversal or refund abuse

Ships today: gh.reversal_abuse in the gh-psp pack

Counts reversals only (not refunds or chargebacks), per customer over 30 days. It fires at max_reversals (default 5). Exact defaults and logic: Pack contents.

What it looks for: an unusual number of reversals or refunds on one wallet or merchant. Some scams depend on reversals (“I sent it to you by mistake, please send it back”), and some insiders abuse the reversal process.

Example

With max_reversals 3 and window 30 days:

• ✅ Fires: five reversal requests on one wallet in a month.

Parameters

Parameter	Meaning	How to tune
max_reversals	Reversals allowed in the window	Low for consumers; higher for busy merchants
window	The period	Weeks

Mode and pack: post-event, in gh-psp.

Data it needs: reversal and refund transactions identified as such, linked to the original transaction where possible.

G6 Large mobile money transfer at night

Ships today: gh.night_large_momo in the gh-psp pack

Exact defaults and logic: Pack contents.

What it looks for: a large mobile money transfer out of a wallet in the small hours. Account-takeover and social-engineering fraud often happens at night: the fraudster has the victim’s PIN or SIM, and the victim is asleep and won’t notice the SMS until morning.

Example

With threshold GHS 5,000, from_hour 0 and to_hour 5 (midnight to 05:59, workspace time):

• ✅ Fires: GHS 6,500 sent by MoMo at 02:14 to a wallet the customer has never paid.
• ❌ Does not fire: the same transfer at 07:30.
• ❌ Does not fire: GHS 800 at 02:14 (below the threshold).

Parameters

Parameter	Meaning	How to tune
threshold	Smallest transfer that counts	Above most customers’ normal night-time payments
from_hour	First hour of the night period (0–23)	Must not be later than to_hour. The period can’t cross midnight
to_hour	Last hour of the night period, inclusive	5 means “until 05:59”

Mode and pack: post-event, gh-psp pack. Ships today. As a post-event rule it alerts after the money has left. To stop such a transfer before it happens, a rule author can build a real-time version in the rule builder.

False positives: night-shift workers, traders who settle with suppliers before dawn, and customers abroad. Look at the customer’s history: someone who regularly sends money at night is different from a first-time 2 a.m. transfer to a new payee.

Data it needs: channel (momo), direction, amount, and the transaction time. The hour is read in your workspace’s time zone.

---

Related

• B. Structuring and smurfing — B2 split cash-in across agents
• D. Mule and network patterns
• H. Card and online fraud — H5 profile change then payout
• Account takeover and SIM swap
• I. Business and merchant
• Tuning and calibration