Read-only by design

Security at Mozaic — read-only, encrypted, calm.

Sharing your financial information is a big deal. Here is exactly what Mozaic can do, what it cannot do, and how we keep the picture small enough to defend. No buzzwords, no military-grade theatre — just the architectural choices that make the next paragraphs true.

7 commitments · 5 questions · Last reviewed 2026-05-24
01 · Connections

Bank-grade connections via Plaid and SnapTrade

Mozaic does not handle bank or brokerage credentials directly. When you connect an account, you sign in to your institution through Plaid (for Canadian and US banks) or SnapTrade (for brokerages), and the credentials go straight from you to the bank. Mozaic only ever receives an opaque access token that can be used to read balances, holdings, and transactions — never to authenticate as you, never to retrieve your password.

Both Plaid and SnapTrade are SOC 2 Type II audited, transport everything over 256-bit TLS, and use OAuth or its bank-specific equivalents wherever institutions support it. We chose them precisely because their security posture is the one financial-data infrastructure they sell — every other consumer app you have ever connected to your bank (Venmo, Robinhood, Chime, Wealthsimple's tax import) sits on the same rails. When you revoke a connection in Mozaic, the underlying Plaid or SnapTrade token is revoked at the source — the institution stops trusting it immediately.

02 · Permissions

Read-only by design — and not by promise

The tokens Mozaic holds permit reads only. They cannot initiate a transfer, place a trade, change a position, or alter a beneficiary. This is not a self-imposed policy that could be relaxed in a future release; it is the permission scope our integrations request when you connect an account, and it is what your bank's authorization screen confirms to you in plain English before it issues the token.

The reason this matters is simple: a security model is only as strong as its weakest possible failure. If Mozaic were ever compromised — by an external attacker, by a rogue employee, by a bug in our code — the worst-case outcome is that someone could see the same numbers you see. They could not move funds, they could not trade, they could not change your address with your bank. Read-only shrinks the blast radius of any incident to "exposure," not "loss."

03 · Jurisdiction

Canadian data residency, PIPEDA and Quebec Law 25 compliant

Your data lives in Google Cloud's northamerica-northeast1 region — the Montreal data centre. Nothing about your account information is replicated to US-based or EU-based regions. We chose Canadian residency because it lines up with the two privacy regimes that apply to most of our users: PIPEDA federally, and Quebec's Law 25 for residents of Quebec.

PIPEDA and Law 25 are referenced by their proper names here because the legal terms do not translate — they grant you specific rights: the right to know what we hold, the right to correct it, the right to withdraw consent, and the right to have your data deleted. The operative endpoints for those rights exist in the app, not just in the privacy policy: data export and deletion are self-serve from Settings, not a ticket queue.

04 · Deletion

30-day grace window — or immediate, synchronous deletion

When you delete your account in Settings, you choose between two paths. The default is a 30-day grace window: your data is locked from sync and access, but kept recoverable, so if you change your mind within the month you can cancel the deletion and pick up where you left off. After 30 days, the deletion runs and your data is permanently erased.

The second path is delete immediately: same destination, no grace window — the wipe runs synchronously inside the request, so your data is gone before the response returns. Either way you can export your full history as CSV first, and either way there is no retention loophole — backups roll over on a schedule that aligns with the deletion windows, so a recovered backup cannot be used to resurrect a deleted account beyond its window.

05 · Encryption

Encryption in transit and at rest

Every byte that moves between your browser and Mozaic is transported over HTTPS with TLS 1.2 or higher. HTTP requests are redirected to HTTPS at the edge, and an HSTS header with a one-year max-age tells browsers to refuse a downgrade attempt for the next year, so a hostile network cannot strip TLS off the connection.

At rest, sensitive fields — the Plaid access tokens, SnapTrade user secrets, MFA recovery material, and the most revealing parts of your transaction history (merchant names, descriptions, locations, and account names) — are encrypted at the application layer with Fernet (AES-128-CBC plus an HMAC-SHA256 authentication tag) before they ever reach the database. The underlying Cloud SQL storage is independently encrypted by Google with their managed keys. The practical effect: even direct read access to the database returns ciphertext, not credentials or spending detail. We deliberately keep the specific key-management details out of public copy — general architecture is healthy to share; exact derivation parameters help no one but an attacker.

06 · Data use

We do not sell your data

Not to advertisers, not to data brokers, not to research firms, not to anyone. Mozaic does not run an ad network, does not sell aggregated or anonymised datasets, and does not participate in the consumer-finance data resale industry. The reason we can commit to this durably rather than aspirationally is the revenue model: a subscription business gets paid by users, so the moment a user becomes a product instead of a customer the model breaks.

The same applies inside the company. Engineering access to production data is limited to a small founding team, all access is audited, and the sensitive integration tokens described above are encrypted before they are written — so even legitimate database reads during incident response return ciphertext rather than usable credentials.

07 · Sign-in

Sign-in via Identity Platform, with optional MFA and trusted devices

Authentication is handled by Google Cloud Identity Platform (the managed product behind Firebase Authentication). When you sign in, your browser receives a short-lived ID token (RS256, signed by Google) that the Mozaic backend verifies against Google's public keys on every request. Session lifetime, refresh, and revocation are managed by Identity Platform — which means a hard sign-out on one device propagates cleanly, and a compromised session can be killed centrally.

You can enable time-based one-time password (TOTP) two-factor authentication from Settings using any authenticator app — Google Authenticator, Authy, 1Password, the built-in iOS Passwords app. Trusted-device tokens let you skip the second factor on devices you have already used, without weakening the protection on a new sign-in from an unfamiliar machine. Account recovery and email verification use Google's infrastructure, which is the same chain billions of people already rely on for their primary email.

The short version.

Five questions we get most often. Answers are matched verbatim to the FAQPage schema above, so what you read here is what Google reads.

No. Our connections to your banks and brokerages are read-only, meaning we receive balances and transactions but have no permission to transfer funds, place trades, or change positions. Even if our systems were compromised, an attacker could not move a cent out of your accounts through Mozaic — the permission to do so simply does not exist on the integration tokens we hold.
Sign-in is handled by Google Identity Platform, so account recovery and session revocation use Google's infrastructure. You can enable optional time-based one-time password (TOTP) two-factor authentication in Settings. Because every bank and brokerage connection is read-only, even worst-case account access still cannot result in funds being moved — an attacker would only see, not act.
Your data lives in Google Cloud's northamerica-northeast1 region (Montreal). Mozaic complies with Canada's PIPEDA and Quebec's Law 25. Sensitive fields like Plaid and SnapTrade access tokens — and sensitive transaction details such as merchant names, descriptions, and locations — are encrypted at the application layer with Fernet before they reach the database, and the underlying database storage is itself encrypted by Google Cloud SQL.
Engineering access to production is limited to a small founding team and is audited. Sensitive integration tokens are encrypted before they are written, so even direct database reads return ciphertext rather than usable credentials. We do not sell, rent, or share your data with advertisers or data brokers — our revenue model is subscriptions, which is what makes that commitment durable rather than aspirational.
Our commitments to read-only connections, no data sales, and Canadian data residency are written into the product architecture, not just the privacy policy — which means they would survive an acquisition the same way the codebase would. In the event of a material change in ownership or terms, we would notify you by email in advance and give you the option to export your data and delete your account before any new terms apply.

Ready when you are.

See pricing