
Marnie journal / Privacy
Are Budgeting Apps Safe? Local Storage, Open Banking and Cloud AI
A budgeting app can be safe enough for one person's needs and still be a poor fit for another. Do not rely only on labels such as "local," "encrypted," or "powered by Open Banking." Ask what data the app receives, where it is processed and stored, which features send it elsewhere, how long it remains, and which choices you can change. A local-first app can still require an account, cloud backup, or cloud AI, while manual entry can minimise collection but leave records incomplete.
Privacy expectations are high in Australia. In the OAIC's 2026 survey, 93% of respondents agreed that settings should be most protective by default, 88% preferred sharing the minimum information needed, and only 24% thought most organisations were transparent about how they used personal information (OAIC, Australian Community Attitudes to Privacy Survey 2026). A trustworthy product should make the trade-offs inspectable before the user has to guess.
Quick comparison of five common data flows
The options below are not a ranking from safest to least safe. Each changes data coverage, effort, and exposure in a different way.
| Data flow | Data involved | Where processing can occur | Main convenience | Main question to ask |
|---|---|---|---|---|
| Local records and manual entry | Transactions and plans you enter | Primarily on the device | Narrow, intentional collection | What still leaves the device for accounts, diagnostics, or support? |
| Open Banking through CDR | Banking data you consent to share | Bank, accredited recipient, and its disclosed providers | Broad, ongoing account coverage | What data, accounts, duration, storage, and deletion did I approve? |
| Wallet or notification capture | Particular payment events or notification details | Device, operating-system flow, and any app service the feature uses | Low-friction capture without a full bank feed | Which events are supported, what is missed, and what raw content is retained? |
| Cloud backup | A copy of records selected for backup | Device and cloud storage service | Recovery and migration | Is it optional, what is excluded, and how is the backup removed? |
| Cloud AI | Prompts and relevant context for an AI task | App, AI provider, and disclosed subprocessors | Features that may not run locally | Exactly what context is sent, when can it run, and what are the provider's terms? |
One app may use several rows, and each path deserves its own explanation.
Offline-only, local-first, optional sync, and cloud-first are different
These labels describe where the primary working copy lives and when data can leave the device. They are useful starting points, not guarantees, so verify the product's actual settings and policy.
| Model | Where core records usually live | What internet features can change | Main question to ask |
|---|---|---|---|
| Offline-only | On the device, with core use designed to work without a service connection | Updates or operating-system services may still use the internet, but the app should not need a cloud copy of core records | How are records exported, recovered, and deleted? |
| Local-first | The primary working copy is on the device | Accounts, diagnostics, AI, learning, or other optional services may still send selected data online | Which features are exceptions to local processing? |
| Local-first with optional backup or sync | A local working copy plus a cloud copy only when the named feature is enabled | Backup adds recovery; sync may add multi-device access and ongoing transfers | Is the feature off by default, what is copied, and how is the cloud copy removed? |
| Cloud-first | The service normally holds the primary copy, while the device may keep a cache | Sign-in, availability, retention, provider access, and cross-device use depend on the service | Can the data be exported and deleted, and what happens if the service is unavailable? |
"Optional backup" and "optional sync" are not interchangeable. Backup generally creates a recovery copy, while sync keeps copies aligned across devices or sessions. Neither label explains notification permissions or AI processing by itself. Review notification access safety for the capture boundary, and use the AI spending insights guide to separate processing location from answer quality.
What local-first means, and what it does not mean
Local-first is best treated as an architectural description, not a complete safety verdict. In a personal finance app, it usually means the device holds the primary working copy of core records and can perform important operations against that local data.
That design can reduce routine dependence on a central financial database. It does not remove every risk. A compromised phone, weak passcode, unsafe screen sharing, malicious software, or incomplete backup plan can still expose data or cause loss.
Local-first also does not answer these questions on its own:
- Is an account required, and can diagnostics or support include financial details?
- Is backup local, cloud-based, optional, or automatic?
- Can AI send transactions, images, audio, or prompts to a provider?
- Does the app contribute merchant corrections to a shared service?
- What remains after account deletion or app removal?
An app can describe itself accurately as local-first while still using online services. The responsible version of that claim names the exceptions and exposes controls. Marnie's Privacy Policy, for example, separates on-device records from account services, optional backup, AI modes, and merchant learning.
How Australia's Consumer Data Right and Open Banking work
Open Banking is the banking sector's implementation of Australia's Consumer Data Right, commonly called CDR. The ACCC explains that CDR gives consumers the right to choose whether to share data, including what data is shared, with whom, and for how long. Budgeting and saving services are among the intended uses (ACCC, The Consumer Data Right).
In a CDR flow, the consumer authorises the bank to share selected data with an accredited data recipient or another permitted participant. This differs from giving a budgeting app an internet-banking password. CDR rules and privacy safeguards do not make every use case identical or eliminate operational risk.
Before connecting an account, inspect:
- which accounts and data types the consent covers;
- whether access is one-time or ongoing, how long it lasts, and how to withdraw it;
- who the accredited recipient is and which providers it uses; and
- how received and derived data are stored, retained, corrected, and deleted.
Open Banking can provide broader account coverage with less manual entry, but shares more banking information with another participant. A no-bank-sync approach narrows that flow but usually requires the user to reconcile missing cash, transfers, fees, and unsupported purchases. Neither model is automatically superior.
Open Banking is not a verified Marnie feature. Its verified choices are Apple Pay Shortcuts on iOS, supported payment notifications on Android, and typed or spoken entry. See the Marnie money flow.
What wallet and payment-notification capture can expose
A Wallet transaction event and Android notification access have different boundaries. A Wallet automation supplies a selected event. Android listener access can expose notifications from other apps, with platform restrictions, even when an expense tracker chooses to process only payment sources. This workflow provides less account-history coverage than a bank feed, but that does not mean its operating-system permission is narrower in every respect.
Apple documents a Wallet transaction trigger in Shortcuts (Apple, Transaction triggers in Shortcuts). It also says Wallet history can differ by issuer and the issuer's statement is most accurate (Apple, View Apple Pay transaction history). A Shortcut can support timely capture without becoming the final record.
Google likewise cautions that Wallet details may be incomplete, so the bank statement or full receipt remains authoritative (Google Wallet transaction history). Capture also depends on permissions, notification wording, and feature support.
For any wallet or notification workflow, ask:
- What can the operating-system permission expose, and which source apps does the product actually process?
- Does the app keep raw content, parsed transaction fields, or both?
- Can you review uncertain matches and resolve duplicates or refunds?
- Does backup include raw content, and can access be revoked in phone settings?
Treat system access, app filtering, and retention as three separate answers. For example, selecting one bank app inside a tracker can limit the product's processing without turning Android listener access into a permission that exposes only that bank's payments. The notification-access guide covers that distinction and Android's sensitive-content restrictions.
What optional cloud backup changes
Cloud backup creates another copy for recovery or migration. It can improve resilience, but moves selected data outside the primary device and introduces a storage service, access controls, and a deletion process.
A clear backup explanation should state:
- whether backup is on or off by default;
- which records, settings, attachments, and raw fields are included;
- how access, restore, and encryption are handled; and
- what disabling backup does to an existing copy and how to remove it.
For Marnie, Cloud Backup is optional and off by default. It uploads a private account backup when enabled, with raw notification bodies and payloads removed. Users can create and restore backups when moving or recovering data. Parsed financial records can still form part of the copy, so this remains a genuine cloud data flow.
Local AI and cloud AI involve different boundaries
An AI label does not reveal where a model runs. Local AI can process supported tasks on the device, while cloud AI sends relevant input to a provider. An Automatic mode may choose between them. Privacy depends on the path used and context attached.
Useful questions include:
- Which mode is active, and can a local choice fall back to cloud processing?
- What transaction, plan, image, text, or audio context can be attached?
- Can processing run after data changes or only after a direct request?
- Which provider receives the data, and what are its retention and training terms?
- Can cloud processing be disabled without losing core records?
Marnie offers Local, Automatic, and Cloud AI modes. Local is the privacy-preserving default, but on a device without a usable local model an unavailable Local choice can resolve to Automatic. Cloud AI can receive text, image, audio, or financial context needed for an enabled feature. Insight refreshes can run after financial data changes, not only when Insights is opened.
That caveat is important. "Local by default" should not be paraphrased as "all AI always stays on this phone." The second statement is not supported by Marnie's verified product behaviour.
Community merchant learning is another distinct flow
Shared merchant learning can improve transaction names or categories without sharing an entire ledger. Its privacy impact depends on the submitted fields, default, and deletion behaviour.
Marnie's community merchant learning is disclosed as on by default and can be disabled in Settings. When enabled, it submits a normalised merchant name, confirmed category, country, and general source type. It excludes amounts, dates, account details, transaction IDs, and raw transaction text. Turning the feature off prevents future participation, while Marnie's verified account-deletion flow removes contributor-level merchant learning records.
This is narrower than a full transaction record, but it is still an online contribution.
A practical budgeting-app privacy checklist
Use this checklist before adding a complete financial history:
- Map the inputs. List bank feeds, wallet events, notifications, manual entries, microphone, files, and support attachments.
- Separate storage paths. Identify the device database, account service, backup, analytics, support, AI, and shared-learning services.
- Read each default. Check whether backup, cloud AI, analytics, and community features begin on or off.
- Test the controls. Confirm that permissions can be denied or revoked and that the resulting loss of function is explained.
- Inspect uncertainty. Look for source labels, review states, corrections, and duplicate handling before data is shared or backed up.
- Find the retention rule. Identify which data is removed, from which systems, after which action.
- Check the exit. Review export, backup removal, account deletion, subscription cancellation, and what uninstalling does.
- Protect the device. Use a strong passcode, current updates, and appropriate account security.
If an app's explanation cannot answer these questions, delay importing broad financial data until it can. A privacy policy should be specific enough to match visible features and current settings.
How Marnie maps to the checklist
Marnie is coming soon to iOS and Android. This table summarises verified product facts, not a security certification.
| Area | Marnie's verified behaviour | User choice or limit |
|---|---|---|
| Core financial records | Stored locally on the device | Device access and local data still need protection |
| Account | Required for authentication and account-linked services | Local-first does not mean account-free |
| Capture | Apple Pay Shortcuts on iOS; supported Google Pay and bank-app notifications on Android; typed or spoken entry | Coverage varies, and users classify Android apps as transaction-related or not |
| Cloud Backup | Optional, off by default, with raw notification bodies and payloads removed | Enabling it uploads a private account backup |
| AI | Local, Automatic, and Cloud modes; Local is the privacy-preserving default | A device without a usable local model can resolve to Automatic; cloud AI can receive relevant context |
| Merchant learning | On by default and can be disabled; limited confirmed merchant fields are submitted | It remains an online contribution even though listed transaction fields are excluded |
| Deletion | In-app deletion removes the remote account and account-linked records, cloud backup objects, contributor-level learning records, and local Marnie financial storage | It requires a signed-in user to type DELETE and does not cancel store billing |
Read the current Marnie Privacy Policy for implementation-level wording. The Delete Account page explains the available paths. Product and policy details can change before launch, so check the displayed reviewed date.
Frequently asked questions
Is Open Banking safe?
Australia's CDR gives consumers choices about what banking data is shared, with whom, and for how long, with rules and privacy safeguards for participants. It does not eliminate every risk. Check the recipient, consent, storage, provider chain, and deletion process.
Is manual tracking always more private?
Manual tracking reduces automated access because you choose each entry, but records can still be backed up, sent to cloud AI, or exposed on the device. Incomplete entries also reduce the reliability of figures such as Safe to Spend.
Does local-first mean no account is required?
No. Local-first describes where core working data is primarily held, not whether authentication exists. Marnie stores core financial records on the device but requires an account for authentication and account-linked services.
Can cloud AI see transactions?
It can if transaction or financial context is relevant to the requested or enabled feature and the app sends that context. In Marnie, Cloud and eligible Automatic processing can receive relevant text, image, audio, or financial context. Review the active mode and feature before assuming processing is local.
What should happen when an account is deleted?
The product should state what is removed or retained. Marnie's in-app flow removes the remote account and account-linked records, cloud backup objects, contributor-level learning records, and local Marnie financial storage. It does not cancel App Store or Google Play billing.
Choose the trade-off you can explain
Choose a data flow you understand and deliberately accept. Compare what a method collects with the value it provides, then verify the defaults, provider boundaries, and exit path. For Marnie, start with the product flow, current Privacy Policy, and bills guide.
Coming soon · iPhone and Android
Track expenses without linking your bank.
Marnie brings supported payment capture, text and voice entry, and Safe to Spend planning together. Join the list for launch news and first-access details.

Marnie Editorial
Practical explanations for a calmer relationship with everyday money. Marnie provides informational guidance, not financial advice. Read our research and corrections policy.