RCTP Live
Receiver-Consent Transaction Protocol: mobile money that asks the receiver first.
Overview
A message arrives from a friend’s hijacked WhatsApp: “My phone is broken, send the money to this number instead.” The sender approves the payment themselves, so every check passes. The money is gone, and the one person who could have stopped it, the real receiver, was never asked.
RCTP holds every credit until the rightful receiver approves it from their own SIM.
How it works
- 1
Destination logged first
The number the sender was told to pay is written to the permanent record before anything else. A redirect identifies itself in the act.
- 2
Funds held in escrow
The money leaves the sender's wallet but is not credited to anyone yet.
- 3
Real receiver alerted
An SMS goes to the SIM the sender named as the rightful receiver, not to whoever asked for the money.
- 4
Receiver consents or refuses
From their own SIM, with their PIN. A correct PIN from any other SIM is rejected.
- 5
Credit lands, or money returns
Confirmed: the credit completes. Denied or ignored: the money goes back. Every step is hash-chained.
Fraud scenarios
Source: the paper’s Table 4| Scenario | The attack | How RCTP responds | Result |
|---|---|---|---|
| WhatsApp hijack and redirection | “Kofi's phone is broken, send it to this number instead.” | The mismatch between the real receiver and the destination is flagged before the escrow exists, and the real Kofi denies it. | Covered |
| Stolen PIN or prize scam | The fraudster knows the receiver's PIN. | Knowing the PIN is not enough: only the certified SIM can consent. Attempts from any other SIM are rejected and logged. | Covered |
| Fake reversal or deposit scam | “I sent you money by mistake, please send it back.” | No RCTP challenge means no legitimate incoming credit, and the menu says so. | Covered |
| Ignored challenge | The receiver never responds. | The escrow times out and the money returns to the sender. Nothing is lost in limbo. | Covered |
| History rewrite by an insider | Someone edits a transaction record after the fact. | The log is hash-chained: the dashboard shows the chain broken at the exact record that was altered. | Covered |
Run the experiment
About 5 minutes- 1Open the phone simulator. The cast: Ama (sender), Kofi (the real receiver), Esi (another wallet), and Yaw, the fraudster's “WhatsApp number”.
- 2On Ama's phone, switch to Legacy MoMo and send money to Yaw. It goes through instantly: no consent, no evidence. That is today's gap.
- 3Switch Ama back to RCTP. From Yaw's attack console, lure Ama, then send from Ama naming Kofi as the receiver and Yaw's number as the destination.
- 4Open the live dashboard: the mismatch is already flagged. On Kofi's phone, deny the challenge. Ama gets her money back.
- 5Press Reset demo when you're done, so the next visitor starts clean.
Live dashboard
Wallet balances, attack coverage, every transaction, and the hash-chained audit log, updating as you run the scenarios.
Method and limits
What this prototype does not claim.
- Consent is pull-based here. The prototype's USSD provider can't start a session on the receiver's phone, so the receiver gets an SMS and dials in. On a live network, the carrier would push the prompt directly.
- PINs are checked by the application. In production, PIN checks belong in the carrier's secure hardware path.
- Money is simulated. Escrow in production is a regulated trust-account arrangement under Bank of Ghana e-money rules, which is why the path forward runs through a regulatory sandbox.
Cite this prototype
Amponsah, R. (2026). RCTP: Receiver-Consent Transaction Protocol [Interactive prototype]. The Trust Lab. https://raphaelamponsah.com/lab/tools/rctp
Questions about the paper? Ask a question.
Pilot RCTP on a real network
Mobile network operators, mobile money providers, and regulators: RCTP is ready for a sandbox conversation.