How We Protect Your Financial Data at MyFam360

A finance app that you don’t trust is just a risk. You know this — it’s probably why you haven’t started tracking your expenses yet, or why you limit what you enter. The #1 reason people don’t adopt finance apps isn’t friction or design. It’s the quiet fear that their financial life is now visible to someone they didn’t choose.

This post explains exactly what protects your data in MyFam360. Not in legal language. In plain terms — the kind a technically minded friend would use over coffee.

---

What we’re protecting

Before the protections make sense, it helps to name what’s at stake. MyFam360 stores:

• Your name and email address
• Financial amounts you enter (expenses, income, account balances, savings goals, settlements)
• Spending patterns and category distribution
• Family member connections
• Payment subscription records (processed via Razorpay)

Financial data combined with behavioral data — knowing what you earn, spend, and save — is among the most sensitive data a company can hold. It can enable identity fraud, targeted scams, and discriminatory credit decisions if mishandled. We’re aware of this weight.

---

Layer 1 — Your password is never stored

When you create a MyFam360 account, your password is run through bcrypt before it ever touches our database. bcrypt is a one-way function: there’s no way to reverse it back to your original password. What’s stored is a mathematical hash.

What this means in practice: if someone somehow accessed our entire database, they could not extract your password from it. The only way to “crack” a bcrypt hash is to guess the original password and hash each guess — computationally expensive by design.

We also support Google OAuth and Passkeys (WebAuthn) as login options. These are phishing-resistant: a passkey is a cryptographic key pair where the private key never leaves your device, and Google OAuth removes passwords from our system entirely for those users.

OTP verification: When you sign up, we verify your email with a 6-digit one-time password. OTPs expire in 10 minutes, are limited to 5 attempts per challenge, and have a 60-second resend cooldown — standard protections against brute-force attacks.

---

Layer 2 — All traffic is encrypted in transit

Every API request and response between your browser and MyFam360 travels over TLS 1.2+ (the protocol behind the padlock icon in your browser). HTTP is redirected to HTTPS automatically at our nginx server layer. This means your financial data — the amounts you enter, the reports you view — cannot be read by someone intercepting the connection.

This is table stakes for any modern web app. We mention it because some apps say “encrypted” and mean only this. We mean more than this.

---

Layer 3 — Financial amounts are encrypted at rest

This is the one most apps skip because it’s difficult to implement.

The gap in most finance apps: Even with TLS, if someone gained direct access to the database (a cloud breach, a rogue hosting employee, a misconfigured backup), they could read every amount in every table as plain numbers. ₹9,200 food delivery. ₹75,000 salary. ₹14,000 home loan EMI.

What MyFam360 does instead: Financial amount columns are encrypted using Fernet (AES-128-CBC + HMAC-SHA256) before being written to the database. The following fields are encrypted at rest:

Table	Encrypted Fields
expenses	amount
incomes	amount
accounts	current_balance
savings_goals	target_amount, current_amount
settlements	amount
users	email

A direct database breach yields ciphertext — unreadable without the encryption key, which is stored separately from the data and never in the same place.

The practical cost: SQL-level SUM() queries don’t work on encrypted columns, so we sum amounts in the application layer instead. We chose this trade-off deliberately.

---

Layer 4 — Your family’s data is structurally isolated from everyone else’s

This is the most important protection for an app where multiple families use the same system.

Every piece of data in MyFam360 — expenses, incomes, budgets, accounts, goals — is tagged with a family_group_id. Every database query includes a WHERE family_group_id = ? filter. This isn’t just a UI restriction. At the database query level, a user in Family A cannot read a single row belonging to Family B — even if they bypassed the frontend entirely and sent raw API requests.

Cross-family data access is structurally impossible, not just policy-prohibited.

---

Layer 5 — Record IDs are encrypted in transit

When you open an expense in MyFam360, the URL doesn’t contain a predictable integer like /expenses/1234. We use UUID primary keys (128-bit random IDs) throughout — these cannot be enumerated by incrementing a number.

Additionally, our API encrypts UUID values in responses using a transport layer, so raw record IDs are never exposed over the wire. An attacker who intercepted an API response would see encrypted identifiers, not guessable IDs.

---

Layer 6 — Error monitoring is scrubbed before leaving our servers

We use Sentry for error monitoring — it captures stack traces and context when something goes wrong, which helps us fix bugs quickly. The risk: error payloads can inadvertently contain financial amounts from stack traces or request bodies.

We address this with a before_send hook that strips all request body data and minimizes user context to just an anonymous ID before any event is sent to Sentry. Financial amounts from stack frames are also stripped. Error reports help us fix bugs; they don’t contain your financial data.

---

Layer 7 — Sessions expire automatically

JWT session tokens are signed with a secret key, have a built-in expiry, and are validated on every API request. There’s also an inactivity timeout — if you leave the app open but idle, you’re automatically logged out after 5 minutes (with a 1-minute warning prompt). This protects against someone accessing your open session on a shared device.

---

Layer 8 — Every admin action is logged permanently

Our internal admin panel is protected by strict access controls and logs every action with the full before/after state, the admin’s email, and their IP address. No admin can quietly change a user’s data without it being permanently recorded. This audit trail is essential for forensics in the unlikely event of an incident — and it’s a check on our own team.

---

What we don’t do

Just as important as what we do:

• ❌ We do not sell your data to advertisers or data brokers
• ❌ We do not use tracking cookies or third-party analytics scripts
• ❌ We do not share transaction-level data with AI providers — aggregate summaries only, never individual transactions (see our Privacy Policy for the full data minimization policy)
• ❌ We do not store your bank account number, net banking credentials, or card details
• ❌ We do not connect to your bank — all data entry is manual

---

Where to go from here

Your complete data rights are documented in our Privacy Policy — including how to download all your data, how to delete your account, and how to file a privacy grievance.

Related reading:

• Your data rights under India’s DPDP Act 2023 — the 6 enforceable rights you have as an Indian user
• Why we moved our servers to an India-compliant region — where your data physically lives and why it matters
• The right to delete: how to erase all your data — exactly what gets deleted vs anonymized

Privacy protection isn’t a feature we bolt on. It’s the foundation the product is built on.