Security | Vault

1. The strongest part of the security model is also its main limit

Vault's main security decision is to keep portfolio data on the device. That can reduce central database exposure, but it does not guarantee security on its own. Real security still depends on the device, the operating system, and how the user handles access.

Local storage can reduce some risks but does not remove all risks.
With cloud sync inactive, central exposure is narrower.
If the device is exposed, unlocked, or shared, the data can still be affected.

2. In-app protections are limited helper layers

Features such as Privacy Mode and Simple Mode can reduce what is shown on screen, but they are not a substitute for strong access control, full encryption guarantees, or device-level security. They help with visibility, not with every form of compromise.

Privacy Mode only applies if the user turns it on.
Simple Mode reduces visible detail but does not remove the underlying data.
Anyone with direct screen access may still see what is currently visible.

3. Diagnostics infrastructure creates an additional risk surface

Vault may use third-party analytics and crash-reporting infrastructure. Even if the purpose is product quality, this still means the system is not fully closed and some technical data may leave the device. That outside dependency should be acknowledged plainly.

Anonymous usage metrics may be enabled by default.
Anonymous crash reports may be enabled by default.
Outages or policy changes in third-party services are not fully under our control.

4. There is no full continuity guarantee for price feeds or reminders

Price data depends on outside sources and in-app processing. Reminders depend on device permissions, operating-system behavior, local scheduling, and notification delivery rules. Because of that, the product should not promise that pricing will always be current or that reminders will always arrive on time.

Market data may be delayed, incomplete, or unavailable.
Reminder delivery may fail or arrive late on some devices.
Battery optimization, silent hours, and notification settings can affect delivery.

5. A large part of security still stays with the user

An unlocked phone, shared-device usage, malicious software, screenshots, automatic device backups, or physical theft are not risks the app can fully control. A user-first security page should say this directly instead of overstating what the app can prevent.

Using a device lock remains the user's responsibility.
Keeping the operating system updated remains the user's responsibility.
Anyone with physical access to the device may still have a visibility risk.

6. We do not guarantee data recovery

A local-first model also means data-loss risk sits closer to the device. If the phone is damaged, reset, replaced, or the app is removed, records may be lost. Vault does not currently promise automatic restore from a developer-side secure backup.

Data loss remains a real practical risk.
Without an active cloud recovery path, support cannot always restore records.
That limit is a direct consequence of the local-first architecture.

7. Security claims should stay limited and measured

Vault should not be described as 'fully secure,' 'unhackable,' 'never loses data,' or 'bank-grade.' The correct and user-favoring approach is to describe only the protections that actually exist and to state the remaining risks plainly.

This product is not a bank or custodial infrastructure.
This product is not a financial-advice or execution service.
This page should be revised as the technical architecture changes.