The Trust Architecture Behind SolaNest
How SolaNest connects your accounts in the United States, the rules that gate every reward, and the engineering commitments that keep your data isolated and auditable.
How Account Linking Works
In the US, SolaNest connects checking, savings, credit, and loan accounts through Plaid -- the same secure aggregator trusted by thousands of US fintech apps. We never see or store your bank password.
Every linked account normalizes into the same internal shape before any spending-intelligence logic runs, so your monthly categorization and savings target are computed by identical rules -- denominated correctly in USD.
The Financial Vitality Ruleset
Your $25 reward is reserved for members with a genuine, active financial footprint -- this keeps the reward pool sustainable for everyone building real savings habits. Three gates, all disclosed here, all must pass:
Every reward-eligible profile must show a verified recurring income signal, or -- when the aggregator's income product isn't available -- a rent or utility payment pattern as a life-indicator proxy. No income anchor, no reward eligibility, full stop.
When you link an institution, we track every account under that credential as one unit. Hiding or unlinking any single account under a linked institution invalidates reward eligibility for every account under that same institution token -- selective disclosure isn't rewarded.
An account needs at least 12 distinct debit transactions totaling $300 in the trailing 30 days to count as an active, reward-eligible account. Dormant or barely-used accounts don't qualify.
Data Security Commitments
US and India customer data live in separate Postgres schemas with dedicated, non-overlapping service roles. A US-scoped connection has no GRANT to read a single row of India data, and vice versa -- enforced by the database engine, not application logic alone.
Every regional table carries FORCE ROW LEVEL SECURITY, filtering rows against the authenticated request's region context inside the same database transaction. If that context is ever missing, the policy fails closed -- zero rows, not an error swallowed silently.
Authentication events, account linking, and reward-ledger transitions are written to a partitioned, UTC-anchored audit log. UPDATE and DELETE are rejected by trigger for every role, including table owners -- the ledger only ever grows.
Fraud & Anomaly Monitoring
Every transaction is checked against your own historical spending pattern the moment it posts. If a purchase in a category runs more than 3x your typical amount for that category, it's flagged on your dashboard immediately -- not buried in a monthly statement.
This is deliberately explainable, rule-based detection rather than an opaque model: you can always see exactly why a transaction was flagged. Behavioral-baseline machine learning is a natural next step once there's enough labeled data to train against responsibly -- we'd rather ship something transparent today than something impressive-sounding but unaccountable.