Why I read your SMS.

Last updated · 11 May 2026

Your M-Pesa and bank send you an SMS every time money moves. I read those messages on your phone so I can see your money the way you do — and so you don't have to keep track yourself. This page is exactly how that works, and how I make sure nothing leaves the phone.

The short version

In Kenya, your bank and M-Pesa tell you about transactions by SMS. That's the data source.
I read those SMS messages on your phone and extract transaction details (amount, who, when, what).
Nothing leaves your phone. Not the SMS. Not the transactions. Not your money picture.
This is enforced in our code, not just promised — see how I prove it.

Why SMS, specifically.

Kenya runs on M-Pesa. M-Pesa runs on SMS. Every time you send money, pay a bill, buy airtime, or receive a payment — Safaricom sends you a confirmation text. The same is true for KCB, Equity, Stanbic, Co-op, NCBA, and the other banks: every transaction generates an SMS. Loan apps like Tala and Branch do too.

That SMS is the only consistent record an ordinary user can access of their own day-to-day money. Mini-statements at an ATM cost airtime. M-Pesa's USSD statement is short, expensive, and frustrating to read on a phone screen. Bank apps show the last few transactions but rarely the longer story. SMS is what we all already have.

For me to help you see your money — to spot the pattern, the unusual spend, the bill you forgot you set up two years ago — I need to read those SMS. There is no other source that covers your real activity across all the institutions you use.

What I read — and what I don't.

In plain language

I only read SMS from senders that look like financial institutions. The rest of your inbox is none of my business and I don't touch it.

Specifically:

I read SMS from M-Pesa, KCB, Equity, Stanbic, Co-op, NCBA, Tala, Branch, and Airtel Money — the eight banks plus M-Pesa plus the two licensed digital lenders that send most Kenyans' transaction confirmations. The list is updated through a remote configuration as new institutions land.
I read the SMS body well enough to identify whether it's a transaction (someone sent or received money), a statement (your balance), a notice (your bill is due), or something else (an OTP, a promo) — and extract the structured information from it.
I don't read SMS from people in your contacts. Your "did you reach home safe" texts are not Nudgey's business.
I don't read messages from work, school, or any sender that isn't on the financial-institutions list.
I don't read group chats — those don't come through SMS anyway.
I don't change your default SMS app. You keep using whichever messaging app you already use.
I don't send SMS to other people. The only outbound SMS Nudgey ever triggers is the one verification code you receive when you sign in.

Where the data lives.

In plain language

Everything I read and everything I figure out from it stays on your phone, in an encrypted database. Not on our servers. Not on anyone else's servers. On your phone.

When an SMS arrives:

It hits Android's standard SMS system as normal — you see it in your messaging app exactly like before.
Nudgey reads it through the SMS permission you granted me, processes it through a small AI model that ships inside the Nudgey app (it's about 600 megabytes — that's why the app download is larger than a typical app), and extracts what's in it.
The extracted transaction is written to a local database on your phone. That database is encrypted with a key your phone's hardware keeps — even if someone copied the database file off your phone, they couldn't read it without the key.
Patterns, insights, the weekly summary, the pre-spend pause — all of this is computed on your phone, by reading the local database.

None of that goes anywhere. The on-device AI doesn't make a network call. There's no "we'll send a copy to our servers for backup" path. There's no "we'll aggregate this anonymously for research" path. The data stays where it started.

Our privacy policy goes into the cloud-side of the picture — things like the phone number you sign in with, optional emails, the chat thread when you ask me a question. Those are bounded and disclosed. The SMS data and the transactions extracted from it are not part of any cloud path. Ever.

Why I couldn't use something less invasive.

Reading SMS is a sensitive permission and I didn't take the decision lightly. Three alternatives looked appealing on paper. Here's why each one doesn't work for the Kenyan reality:

Alternative	The pitch	Why it fails for Nudgey in Kenya
Android Notification Listener API	"Read the bank notification when it pops up, not the SMS itself."	Many Kenyan banks send transaction SMS but not push notifications. Security-aware users disable notification previews for banking apps. Notification Listener also can't read history — only what arrives after the user grants permission, leaving the Onboarding Reveal experience empty.
Bank APIs / aggregators (Plaid-style)	"Connect your bank directly with OAuth — Plaid does this in the US."	Retail-customer banking APIs don't exist in Kenya the way they do in the EU (PSD2) or the US (Plaid/Teller/Tink). M-Pesa's consumer API is restricted to registered merchants. There is no equivalent of an aggregator that lets a consumer app see their own transactions through a sanctioned API. This is the central reason SMS is the only path.
Be the default SMS app	"Replace the user's messaging app and read everything through Android's default-handler privilege."	This is over-scope: a default SMS app sees ALL SMS, including personal messages I have no business reading. It also forces users to abandon their preferred messaging app — a hostile UX trade. The bank-SMS-only path through the standard SMS permission is the narrower, more privacy-preserving option.

The SMS permission as I use it — with the institution allowlist, with the on-device processing, with the no-cross-boundary guarantee — is the least invasive route that actually works for Kenyan retail money.

How I prove it.

"Trust us" isn't enough. The privacy posture above is not a marketing promise — it's enforced by the way the Nudgey app is built. Here's the technical evidence:

What's baked into the code

An on-device AI model (Gemma 3 1B, quantized to int4, about 600 MB) ships inside the Android APK. It runs entirely on your phone's hardware. It has no networking code path. Static analysis of the APK confirms this — there are no API endpoints, no SDK calls, no hidden uploads associated with the SMS pipeline.
A type-system rule called NoLocalOnlyToRemoteRepository classifies all SMS, transaction, conversation, and identity types as Local-only. Any attempt in the code to send a Local-only type to anywhere that could leave the device fails the build at compile time. Engineers can't ship a release that violates this even if they tried.
An anonymize() audit point guards every piece of data that does cross from the phone to our cloud (for things like the chat thread you opt into when you talk to me). It strips raw values — amounts, merchant names, dates — and replaces them with typed buckets (spentMoreOn: TRANSPORT, magnitude: SIGNIFICANT). Tests confirm no raw value can slip through.
SQLCipher database encryption at AES-256 secures the local transaction store, with the key held in the Android Keystore. Even with physical access to the device's storage, the database is unreadable without device unlock.
App-open security requires biometric or PIN on every launch. Your money picture stays yours, even if someone borrows your phone.

These aren't claims we make in marketing copy and don't back up. They are review-able mechanisms that anyone with security expertise (or Google's Play review team, or Kenya's Office of the Data Protection Commissioner) can verify on request.

The trust isn't promised in copy — it's built into how Nudgey is made.

Who's behind this.

Nudgey is owned and operated by Riverbank Solutions Ltd, a private limited company registered in Kenya since 2010 (Companies Registry no. CPR/2010/18968). Riverbank is registered with Kenya's Office of the Data Protection Commissioner as a Data Controller (Serial No. 07560), under the Kenya Data Protection Act, 2019.

Our registered office is in Hurlingham, Nairobi. We have responsibilities under Kenyan data-protection law to handle your personal data lawfully, transparently, and proportionately — and we welcome regulator scrutiny of how we do so.

What you can do.

Read the full privacy policy — the bulleted disclosure of every data category, every sub-processor, every retention window, every right you have under Kenya's DPA, and how to exercise each.
Ask us anything at privacy@thenudgey.com. Real responses from a real person, usually within a business day.
Uninstall the app to remove the local database entirely. That removes the on-device store. There is no cloud copy of your transactions to delete.
Delete your account from inside the app (Profile → Account → Delete my account). This removes the cloud-side account data we hold (phone number, name, subscription record) on top of the local uninstall — see privacy policy §6 for the procedure.

If you have concerns about anything described on this page — anything that doesn't match the actual behaviour you observe, or anything that reads as inconsistent with our privacy policy — we want to hear about it before anyone else. Email privacy@thenudgey.com.