Encryption is the part everyone asks about and the smaller half of the answer. Ciphers protect data from someone outside the system; what protects a resident from the flat next door is who the database will answer at all. Both are below, named, so your CA or your IT-literate committee member can check them rather than take a badge on trust.
TLS 1.3 between the app and our servers, and between our services. Older protocol versions are refused rather than downgraded to. TLS 1.3
AES-256, and the word that matters is including: the database, its backups, and the gate photographs. A backup encrypted to a weaker standard than the live database is the usual gap, and it is the one worth asking every vendor about. AES-256
A voucher scan or a gate photograph is served through a short-lived signed link, generated for one viewer and expiring on its own. Never a public URL — the kind that keeps working after it has been forwarded out of a WhatsApp group.
Passwords are stored only as salted one-way hashes; nobody at Zwangu can read one, including when you ask us to. A session ends with the role — when the committee revokes access, the open session goes with it rather than lasting until the token expires.
Money moves through RBI-regulated payment partners. Zwangu never stores card numbers or bank credentials — only the reference and status of each transaction, attached to its receipt. There is no vault of society bank details here to breach.
Most systems decide what you may see in the application, then ask the database for everything and filter it on the way out. One missed filter, in one place, and a screen shows a neighbour's arrears. Zwangu pushes the rule down to the rows.
A ledger line, a gate entry, a resident record — each carries the society it belongs to as part of the row itself, not as a column the query is trusted to check.
The connection knows which society and which role is asking, established at authentication rather than passed along by the code that happens to be running.
Row-level security policies mean the database returns only the rows that identity is entitled to. A query written without a filter still comes back scoped.
A forgotten WHERE in a new report is a bug that returns too little, not a bug that shows another society's books. That is the point of putting it there.
Today's gate: who is expected, who is inside, the passes issued to them. Not the ledger, not a resident's dues, not last month's entries.
Their own flat — receipts, passes, complaints, the notices addressed to them. Not their neighbour's arrears, and not the member register.
The books: statements, journal, vouchers, trial balance. Read-only, and without resident phone numbers — an audit does not need them.
The helpdesk, approvals and defaulter list the committee granted. They raise purchase requests; they never approve, authorise or move money.
Nothing, standing. Support access exists only for the duration of a request you raised, and every access is written to the log you can read. How the committee grants and revokes →
Indian regions only — primary in Mumbai, replica in Hyderabad. No society data, backup or log leaves India. That includes residents' phone numbers, gate photographs and vehicle records.
Continuous replication with 30 days of point-in-time recovery, tested by restore drill each quarter — a backup nobody has restored is a hypothesis, not a backup. RPO 5 min · RTO 4 hrs
Every financial write records who, when, from where and what changed, including the value before the change. Append-only: entries are added, never rewritten, and they outlive the person who made them.
A closed month cannot be edited by anyone, including us. Corrections post as dated adjustment entries so the trail stays continuous rather than tidy.
Full export — members, ledger, vouchers, attachments, gate logs — available from day one, in XLSX, PDF and Tally-readable formats. On termination we delete your data within 30 days and confirm it in writing.
