Bank alerts look like free, complete, instant spending data sitting on the phone already. On Android reading them is possible and explicitly permitted — but hard to actually get approved. On iPhone it is not possible at all. And the UAE central bank appears to have ruled against the whole approach, which would settle it regardless.
"SMS-based money management" is a named exception, verified on Google's own policy page. No need to become the default messaging app.
No API exists, so there is no permission to grant. Roughly half our market, and the higher-spending half.
CBUAE's Open Finance rules are reported to forbid "data extraction" — pending counsel reading the primary text.
UAE banks are widely reported to alert on essentially every card swipe, so the raw signal looks richer here than in most markets. We have not verified the per-bank behaviour against live accounts. Three separate authorities get a say in whether we may use it.
Yes, technically. Google's rulebook names budgeting apps as an allowed exception — but grants it case by case, and reviewers routinely refuse this exact use.
No. Not with permission, not ever. Apple has never built a way for an app to read messages. There is no prompt to grant because there is nothing to grant.
Its Open Finance regulation is reported to forbid data scraping, defined broadly enough to cover copying transactions out of a customer's messages. Primary text unread — see slide 06.
Policies can be argued and exceptions can be requested. There is nothing here to appeal against — the capability was never built.
Apple lets an app plug into SMS spam filtering. That extension is handed the sender and the message body for texts from unknown numbers.
UAE bank alerts arrive from named senders — ENBD, ADCB, FAB — which can never be saved as a contact, so they always count as unknown and always pass through it.
That extension runs in a sealed box. Apple forbids it from reaching the network and from writing anything the app can later read.
The text is visible for an instant, in a room with no doors. It cannot reach our app and it cannot be stored. The technicality that it sees the message changes nothing.
Most write-ups get this wrong in both directions. The policy is friendlier than its reputation — it loosened after the 2019 purge that the folklore still describes. The review desk is harsher — though the only public first-person account we could verify is a single paraphrased rejection, so the base rate is genuinely unknown.
The exceptions table carries a literal row — "SMS-based money management · apps that track and manage budget" — and it does not require becoming the phone's default messaging app.
The exception applies only where "there's currently no alternative method" to deliver the feature. Reviewers hold that typing expenses in by hand is an alternative.
Usually they declare the wrong thing. FinVantage argued "SMS is our core feature" generically and was told manual entry is an alternative. The recurring rejection string is "store listing information does not match the core functionality for your declared use case" — about proving the declaration, not about the feature itself.
Obba and FinArt both publish that they parse bank messages in MENA — read from their own sites. We could not verify any app's live Play permissions or approval: store listings resisted automated reading, so treat "competitors have it" as indicated, not established.
This is not a store rule. It is built into the operating system, so distributing outside Google does not escape it. It began shipping in December 2025.
Android 16 QPR2 withholds any message carrying a verification-code signature from other apps for three hours — and hides it from the message database too, not just the live alert.
Android 17 widens this to any message that appears to contain a one-time code, for apps built against the newest tools.
A spending alert is not a one-time code. "AED 240 spent at Carrefour" should pass straight through — on the documented behaviour.
While we were asking whether the phone permits it, the regulator was answering whether we may. If this reading holds, it outranks everything on the previous five slides.
Pinsent Masons, summarising the CBUAE Open Finance Regulation · Circular 7 of 2023, amended by Circular 3 of 2025
Copying a customer's transactions out of their messages into our database is the activity being described. Reading it otherwise takes an optimistic lawyer.
That wording is a law firm's summary, not the rulebook itself — the CBUAE site blocks automated access, so we have not read the primary text. It is the most load-bearing claim in this document and counsel must confirm it against the rulebook before it decides anything.
Judged on coverage, on whether they survive store review, and on whether they work at all on an iPhone.
| Route | Both phones | Past spending | Survives review | Regulator |
|---|---|---|---|---|
| Read the texts | Android only | Yes | Often refused | Likely prohibited |
| Read the notifications | Android only | From today onward only | Usually passes | Same prohibition may apply |
| Upload the statement | Both | Months at once | No permission needed | Clean |
| Open Finance | Both | Authoritative | No permission needed | The sanctioned route |
Only the first is automated, cross-platform and sanctioned all at once. The rest are supplements, not a spine.
Categorised data straight from the bank, on both platforms — RN and Flutter SDKs both refreshed June 2026. Consent expires within a year, history caps near 12 months, their store purges at 30 days: we own the database regardless. Needs mTLS, so never mobile-only.
Near-real-time, Android only. Store bar genuinely lower — no approved-use list, no declaration form. Flutter tooling is healthy; React Native's has been stale since 2023. Carries the same CBUAE question as SMS.
Apple Vision and Android ML Kit ship with the OS and run entirely on the device. Not a ledger — but it closes the hole every automated route leaves open: cash.
Gmail is a trap — read access needs an annual paid security assessment and personal finance is not on its approved list. Microsoft Graph has no such gate. Thin signal regardless: only Citibank was confirmed to email every transaction.
Parsing is 70–90% accurate at best. A confirmation step is the human half of the reconciliation gate — and it changes how the whole feature reads, to the user and possibly to a regulator.
A captured transaction is a proposal, not a record. It shows the amount, merchant and category we read, and it does not touch a total until the customer confirms, edits or discards it.
UAE banks alert on essentially every swipe. A prompt per transaction is dozens of interruptions a day and will be switched off within a week. Captured items queue in a review inbox with a badge — same consent, same preview, no fatigue.
High confidence files quietly and stays reversible. Reserve the actual prompt for low confidence — unrecognised merchant, anomalous amount, failed currency detection. Asking about everything teaches people to dismiss without reading.
It does not open the SMS route. We still need the permission to read the message before we can preview it — and a manual confirm step is evidence that an alternative method exists, which is the exact clause reviewers reject on. Android's own permissionless version of this idea, SMS User Consent, only matches OTP-shaped messages, so it cannot see transaction alerts.
The statement pipeline is in the codebase today, and it was built with the privacy posture the regulator asks for — before we knew the regulator asked for it.
A PDF or CSV becomes dated rows with an amount, a merchant and a category — refunds netted off, card repayments ignored, so paying the bill never counts as spending.
Merchant and description are encrypted in the database, not merely access-controlled. They cannot be searched or sorted in SQL — a trade-off taken deliberately.
What leaves the device for the card engine is a monthly total per category — never the individual transactions — and consent is recorded with a timestamp.
The single most important decision here: nothing downstream may know or care where a transaction came from.
Every transaction records how it arrived, and everything downstream behaves identically whichever it says. Each feeder sits behind its own flag, so a refused permission or a changed rule disables a source in config — not a release.
A coffee arrives as a notification today and on the statement next month. Match on amount, date and merchant; keep the more authoritative one.
A parsed alert is a guess; a statement line is a record. Each row carries how sure we are, and the screen must never present a guess as a fact.
Opening balance plus credits minus debits must equal the closing balance, or the import is rejected. Realistic extraction accuracy is 70–90%, not the 99% vendors advertise — this check is what turns silent corruption into a visible failure.
UAE statements are bilingual and show foreign spend twice. Every row needs the dirham amount and the original amount and currency — retrofitting means re-parsing everything.
This one rule resolves most of the legal exposure, and it is cheap to hold — provided we hold it from the first line of code rather than retrofitting it.
Messages and notifications are parsed on the phone. What uploads is the amount, date, merchant and category — never the original text.
Google's policy bans budgeting apps from taking personal message history. Anything that is not a bank alert is dropped in memory — never written down, never counted, never sent.
The federal law has no approved-country list and no standard export contract for the mainland. Hosting onshore means the question is never asked.
Each source is consented separately, with what it reads stated plainly before the system prompt appears, and every grant and withdrawal written to the audit trail.
Carried over from the market-data brief unchanged, because the failure they prevent is exactly the same one.
If a message cannot be parsed, the transaction is missing and the screen says so. A plausible guess presented as a reading is worse than a gap, because the customer cannot tell it is wrong.
Notification capture starts the day it is switched on. A month that began before then is partial, and its total is labelled partial — not quietly shown as though it were whole.
Every total carries the age of its oldest input, exactly as the portfolio screen carries the age of its stalest price.
From Obba's published privacy policy: allowlist bank sender IDs, exclude one-time codes, discard raw text once parsed, and ship the reader with no internet permission. Whether that design was ever approved by Google we do not know — but it is the most defensible posture we found written down.
An Open Finance licence explicitly does not permit advising or arranging. We say what happened to someone's money. We do not tell them what to do next.
Each stage ships on its own, none blocks the next, and nothing built here is thrown away later.
Already built. Reads months of history at once, works on both phones, needs nothing from Google or Apple, and is the only route unambiguously clean with the regulator.
Same bank alerts, and the store bar is far lower — no approved-use list, no declaration form. But the CBUAE wording reaches notification capture on its face, so this stage is gated on the same legal question as Stage D.
The only authoritative route. Coverage is identical across licensed partners — the UAE runs one central hub, so vendors compete on SDKs and price, not on bank reach.
Android only, an undocumented three-hour clock arriving, unmaintained libraries, and a regulator who may have written against it.
Engineering time is the small number in every row below.
| Path | Build | Standing cost | What gates it |
|---|---|---|---|
| Statements | Already built | AI extraction per document | Nothing |
| Notifications | 3–5 weeks | None | Play review · usually passes |
| Open Finance via partner | 4–8 weeks | Scheme calls free to 15 pages/customer/day, then 2.5 fils · plus partner margin | The re-sharing question |
| Open Finance, licensed ourselves | 16–28 weeks | AED 20k–100k / year at scale | AED 1m capital + indemnity cover |
| Reading texts | 6–10 weeks | Maintaining abandoned libraries | Refusal · OS clock · regulator |
The build is understood. The sequence is safe only as far as Stage A. What is unresolved is legal, and each answer is cheap to obtain and expensive to guess. Nothing in Stage A or B waits on them — but Stage C cannot start, and Stage D cannot be reconsidered, until they are settled. Two more sit alongside it: does per-item customer confirmation change the extraction analysis? — and one engineering test, do real UAE bank alerts survive Android 17's three-hour filter? A day on a beta device answers the second.
Both work today, both work on iPhone, neither needs anyone's permission.
If it does, Stage B falls with Stage D and statements are the only route. Ask before building, not after.
Lean's homepage says "fully licensed by CBUAE"; its own About page says in-principle approval, Aug 2025. Settle it before contracting — and note Apple requires finance apps to ship under a company, not an individual account.