Your money data, and what we can — and can't — do with it.
Most apps tell you they take security seriously. This page tells you something more useful: exactly what we hold, exactly what we can read, and exactly where that protection stops. It's the public half of a documented information security programme that governs how My Money Concierge is built and run.
Ledger encrypted on your device · We hold no bank credentials · No advertising or tracking SDKs
The short version
Four sentences that decide everything else on this page.
Your ledger lives on your phone
Every transaction, balance, merchant, note, budget and goal is stored in an encrypted database on your own device — not in an account on our servers. The key is generated on your phone and held in its secure hardware. We don't have it.
We never hold your bank login
Bank connections go through a regulated aggregator. Your banking username, password and two-factor codes are never seen, transmitted or stored by us — not on our servers, not on your device, not in a log. There is nothing of that kind to steal from us.
The AI can't touch your books
The assistant has no code path that can write to your ledger. It proposes; tested, deterministic code decides; you confirm anything that matters. That's a structural limit in how the app is built, not an instruction we hope a model follows.
You can always leave with everything
Export your complete history at any time, in a file you control. That stays true if your subscription lapses, if we have an outage, and if you cancel. Losing access to your own financial records is something we treat as a security failure.
What we hold, and what we don't
The strongest protection over a piece of information is not to possess it. This is the list — not a summary of it.
We never hold this
Not encrypted, not briefly, not in a log. It isn't in the design.
- ✕Your bank username or password — the aggregator holds the banking relationship, never us
- ✕Your two-factor codes or security answers
- ✕Your card numbers — we move no money and store no payment instrument
- ✕Your ledger in readable form — transactions, balances, merchants, notes and attachments
- ✕The key to your device database — it is created on your phone and never leaves it
- ✕Government ID or documents — we don't ask for them
We do hold this
The minimum needed to run a subscription and keep a connection alive.
- ✓An anonymous subscription identifier, so the app knows your plan is active
- ✓Bank connection tokens, encrypted — stored as ciphertext under a separate key, useless on their own
- ✓Operational metadata — error codes, app version, timing. Never the values behind them
- ✓What you send us directly, such as a support email you choose to write
- ✓A count of AI requests, so your monthly allowance is metered — the count, not the content
Transaction data from your bank passes through our edge service on its way to your phone and is never written down along the way. It exists in memory for the length of the request and then it's gone.
How it's protected, layer by layer
Each layer assumes the one outside it has already failed.
The database on your phone is encrypted
Your ledger is stored in an encrypted database (SQLCipher, AES-256) with per-page integrity checking, so a modified file is detectable rather than silently wrong. The key is random, generated on your device, kept in the iOS Keychain or Android Keystore, available only while your phone is unlocked, and excluded from phone backups — so a copied backup or a forensic image is an unreadable file with no key attached.
A passphrase you set, and a lock that means something
You set an app passphrase, and can add Face ID or fingerprint on top of it as a convenience. We're precise about what that means: biometrics unlock a key, they don't prove who you are — so unlocking with a face or finger alone never authorises something destructive like an export or an account deletion. Those always ask for the passphrase. The app also locks itself on a timer and wipes the key out of memory when it does.
Everything in transit is modern TLS, and pinned
TLS 1.3 with AEAD ciphers only, certificate pinning to our own service, and no plaintext fallback anywhere. On Android we trust only the operating system's own certificate authorities — which defeats the most realistic interception attack against an app like this: a monitoring certificate quietly installed on a phone by someone who has access to it.
Bank tokens are split so no single breach opens them
Where a connection token has to be stored, it's stored as ciphertext under a key kept somewhere else. Our database alone gives an attacker nothing. Our key alone gives an attacker nothing. It takes both, at the same time, and our internal incident procedure is written around telling you precisely which of those two situations occurred rather than blurring them together.
Nothing sensitive reaches a log, and a robot checks
Financial values are typed in our code in a way that makes them impossible to pass to the logger — it's a compile error, not a code-review note. On top of that, every build runs a scripted session over a fake ledger seeded with unique marker strings and asserts those markers appear in zero log lines, analytics events, crash reports, notifications and network requests. One appearance fails the build.
Notifications say nothing on a lock screen
A push notification we send contains an opaque identifier and a category — no amount, no merchant, no account name. The words you actually read are assembled on your phone after it's unlocked. Someone glancing at your lock screen learns that something needs review, and nothing else.
The AI is fenced in by construction
The assistant has no write path to your ledger, no network tool, no file tool, no export tool. Text that came from outside — a merchant description, a scanned receipt — is passed to the model inside a channel explicitly marked as untrusted, and the model's reply is parsed against a strict schema; anything that doesn't fit is discarded. If you turn on the cloud tier, what leaves is checked against an allowlist of permitted fields and rejected on anything unrecognised. Account numbers, names, balances and raw notes are on the permanent never-send list, consent or no consent.
What we install is as controlled as what we write
Most real-world compromises of apps like this arrive through a dependency, not a hacker. So: pinned versions with integrity hashes, install scripts blocked by default, new package versions quarantined for seven days, a bill of materials generated for every release and rescanned daily, signing keys held in hardware rather than in the build system, and over-the-air updates that are code-signed and roll out gradually with automatic rollback.
Who else is involved, and what each one sees
We assume every company on this list can be breached, so what each can see is decided deliberately rather than left to a default.
| Service | Why it's there | What it can see |
|---|---|---|
| Plaid | Connecting your bank accounts | Your institution and the accounts you link. It holds the banking relationship — we never receive your banking credentials. |
| Cloudflare | Our edge services and protection | Request metadata, and encrypted bank-token ciphertext at rest. Transaction data passes through memory and is never stored. |
| Anthropic / OpenAI | The optional AI features | Only the minimised, allowlisted content of a request you consented to — totals, category names, date ranges. Never a dump of your transactions. Contractually zero-retention and no model training. |
| RevenueCat | Managing your subscription | An anonymous subscriber ID and purchase details. No financial data. |
| Sentry | Diagnosing crashes | Scrubbed stack traces and error codes. A report that still carries a sensitive marker after scrubbing is thrown away rather than sent. |
| Apple & Google | Distribution and payment | Purchase and subscription details under their own terms. No financial data. |
Not on this list, deliberately: advertising SDKs, attribution SDKs, cross-app trackers, session-replay tools, and third-party analytics. Adding any of them would create exactly the data flow this architecture exists to avoid.
What we can see — including on a bad day
The most honest question to ask any app company is what its own staff can reach. Here's ours.
We built away the capability rather than promising not to use it
- There is no "log in as this user" mode, and we won't build one. Support sees account state and error codes — never your transactions.
- Support cannot add a device, move a key, change your email, or alter your permissions. Those are exactly what a convincing impostor on the phone would ask for, so they don't exist as capabilities.
- Nobody has standing access to production data. Access is temporary, tied to a stated reason, and written to a log that no part of our own system is allowed to delete from.
- If you want hands-on help, you can grant a read-only assist session: it expires in an hour, shows a banner the entire time, is limited to one area, is revocable instantly, and afterwards you're shown exactly what was looked at.
If something goes wrong
Incident plans are easy to write and easy to leave untested. Ours is rehearsed on a schedule, against a clock.
The clock starts at suspicion
Not at confirmation. The moment something looks wrong, containment begins and the notification clock is already running. Our binding deadline to notify our banking partner is 12 hours; we rehearse to be done inside two.
Contain first, investigate second
We revoke a suspect credential before we know whether it was used, because rotation is cheap and a live stolen credential isn't. Nothing gets deleted or "cleaned up" — evidence we destroy is evidence we'd be asked for.
You keep working throughout
Our containment measures are allowed to restrict us, never your access to your own records. Reading, logging and exporting on your device keep working during an incident, by design and by written rule.
Told plainly, including what we don't know
What happened, what data, what we've done, what you should do, and a named human to reply to. No reassurance that runs ahead of the evidence, and no burying it in a release note. An honest unknown now costs less trust than a correction later.
We also record every incident in a register, including the ones that turn out to be nothing and the ones that never reach a legal notification threshold. A register that only contains the embarrassing ones isn't a register.
What we don't claim
Every security page lists strengths. This is the part that makes the rest of it worth reading: the places where our protection genuinely stops.
A rooted or jailbroken phone defeats on-device protection.
If the operating system's own isolation is broken, our encryption is being handed the key by a compromised platform. We detect what we can, and rather than pretending, the app warns you, disables cloud AI, and refuses to share keys with other devices. We don't block you from your own data — that would punish you without protecting you.
Someone who has your passphrase can see what your passphrase unlocks.
No app can engineer away a person standing next to you demanding you open it. What we can do, and have: keep chosen accounts genuinely private rather than merely locked, provide a quiet mode that produces no notification or badge, and document a clear "separating from someone" flow you can run yourself without contacting us.
We can see that activity happened, even though we can't see what it was.
Timing, volume, and the existence of an account are metadata we necessarily process to authorise and sequence anything at all. We minimise it and we don't log values — but we won't claim it's encrypted away, because it isn't.
We hold no security certification yet.
Our programme is written and run against ISO/IEC 27001:2022 and the SOC 2 criteria, with every control mapped. That is not the same as an audit, and we won't imply that it is. Independent penetration testing is a gate we've committed to before public release, and a formal attestation is a decision we revisit quarterly.
Losing your passphrase means losing an encrypted export.
We hold no recovery key for the files you export — that's the whole point of them being yours. The consequence is real: a forgotten export passphrase cannot be recovered by us or by anyone. We'd rather tell you that plainly than quietly keep a master key we could be compelled to use.
Who can reach what
Access is granted to a named identity, for a stated reason, for as long as that reason holds — and revoked the day it ends.
Roles, not favours
Permissions attach to defined roles; roles attach to people. Granting a permission to an individual outside a role is prohibited, because those grants are invisible to review and quietly accumulate. Every role is catalogued, and a role that isn't in the catalogue doesn't exist.
Phishing-resistant MFA, everywhere
Hardware-backed security keys are mandatory on every company account, including the founder's. SMS and voice codes are never used as a factor — SIM-swap is a real attack against exactly this kind of company.
Nothing is permanent
Nobody holds standing access to production. Access is requested, time-boxed and self-expiring, written to a log that no part of our own system can delete from, and re-reviewed every quarter — including the reviewer's own access.
Machines authenticate too
Automation never borrows a person's credentials. Services use short-lived identity federation, mutual TLS, or scoped OAuth tokens, each with its own identity and a named owner. Long-lived static cloud keys are banned outright — they're the usual way a build system becomes a breach.
Every account belongs to exactly one person. Shared and generic logins are prohibited, so every action traces to someone. And the permissions that would matter most if abused — reading your finances, impersonating you — don't exist to be granted.
How long we keep things
Data kept past its purpose is pure liability — it can be breached or subpoenaed, and it earns nothing. So we keep little, briefly, and on a published schedule.
Most of it, we never have
Your ledger lives on your device under a key we don't hold, so there's no server-side retention period for it — there's no server-side copy. Transaction data from your bank passes through memory in transit and is never written down. Cloud AI requests are zero-retention by contract, with caching deliberately disabled.
What we do keep has a number on it
Application logs 30 days. Operational logs 90. Security and audit logs 400, append-only. Crash reports 90. Backups roll off within 35. Support email 24 months. Every category has a period, a trigger and a stated reason — the full table is in the privacy policy.
Deletion means the key is destroyed
Wherever data is encrypted, we dispose of it by destroying the key rather than by chasing copies. It's the only method that reliably reaches replicas, snapshots and device backups — copies nobody can reliably enumerate.
And we're straight about backups
Immutable snapshots can't be surgically edited — that immutability is exactly what makes them survive a ransomware attack. So deleted records become unreadable at once where key destruction applies, and otherwise age out within the backup window. A backup is never restored into service without re-applying the deletion queue. We won't claim instant global erasure, because it isn't achievable and you'd be right not to believe it.
The programme behind this page
This page is the public summary of internal, versioned documents that govern how the app is built, released, monitored and recovered.
| Document | Covers | Status |
|---|---|---|
| Information Security Program | The governing programme for this app: security policy, fifteen operational procedures, incident response, the running control calendar, and the evidence that proves each control ran | v1.0 · reviewed annually |
| Access Control Policy | Identity, role-based access, authentication for people and machines, privileged access, quarterly recertification, and the capabilities we deliberately don't build | v1.0 · reviewed annually |
| Data Retention & Disposal Policy | A retention period, trigger and stated basis for every category of data; secure disposal; cryptographic erasure; legal hold; and how deletion interacts with backups | v1.0 · reviewed annually |
Each is mapped control-by-control to ISO/IEC 27001:2022 Annex A and the SOC 2 Trust Services Criteria. If you're evaluating MyMoneyConcierge for a business purpose and need the documents themselves, ask us and say which you need.
ISO/IEC 27001:2022
All 93 Annex A controls assessed, with every exclusion justified and a stated condition under which it stops applying.
SOC 2 Trust Services Criteria
Mapped across Security, Availability, Confidentiality, Processing Integrity and Privacy — because a finance app that shows a wrong number has failed as surely as one that leaks.
OWASP MASVS
Mobile verification against the storage, cryptography, authentication, network and platform control groups, tested on real devices each release.
Canadian privacy law
Built to PIPEDA and Quebec's Law 25, with data residency and breach-notification obligations designed in rather than retrofitted.
The internal programme covers the policy, fifteen operational procedures, a security calendar, a control register, and the evidence that proves each control actually ran. If you're evaluating us for a business purpose and need detail beyond this page, write to us and say what you need.
Found something? Tell us.
We'd genuinely rather hear it from you than read about it later. Report a vulnerability to support@smartharmonyai.com with "Security" in the subject. We acknowledge within two business days, we won't pursue anyone acting in good faith, and we'll credit you if you'd like us to.
Please don't test against other people's accounts or run denial-of-service attempts — everything else is fair game.
Last reviewed 14 August 2026 · Public summary of internal programme SHAI-ISP-MMC-001 v1.0 · This page describes My Money Concierge only; each SmartHarmony AI app has its own programme. See also the Privacy Policy and Terms.