Who provides NiyaJar
NiyaJar is provided by Dyno Automate LTD., operating from British Columbia, Canada. Business notice address: 601-9320 Parksville Drive, Richmond, BC, V7E 4W2, Canada. Contact support@niyajar.com for privacy questions, requests or complaints.
This notice covers the web, Android and iOS apps and their account, subscription, storage and sharing services. Browsing the public website does not accept app terms or enable app reports. The website's separate privacy notice covers its hosting, language preference and optional website analytics.
Information you keep in the planner
Your working records are encrypted on your device. Depending on your chosen tools, they can include balances, transactions, debts, goals, giving or religious assessments, receipts, notes, places, clients, invoices, suppliers, trips, property, equipment and other household or bookkeeping records. Unfinished task drafts are encrypted separately. Records may contain information about others; enter and share only information you are entitled to use, and avoid unnecessary sensitive details.
The app does not connect to a bank or move money. Sign-in and purchasing do not, by themselves, upload financial records. A release configured with account services requires sign-in for the real planner and access verification; it can then work offline within its verified access period. Requiring an account is different from permission to upload a budget.
Storage can be lost when cleared, an app is uninstalled, a device fails or a decryption secret is lost. Local deletion and account deletion are different actions. We cannot erase downloaded copies from another person's device or reconstruct an unavailable passphrase or recovery key.
Backups, exports and destinations you choose
Complete encrypted manual backups can include books, private records, receipts, places and pending captures. Private records restore as offline books. Unfinished forms, sign-in identity and household connection secrets are excluded. Review the scope and successful completion before relying on a copy.
Readable JSON, CSV, PDF and accountant-package exports are not encrypted. Raw exports can contain receipts, places and pending widget entries. A file you save, email or share can be read or retained by its destination. Creating it does not itself send it to NiyaJar. Deleting a current record does not rewrite older copies; recoverable Trash can remain in complete backups until permanently deleted.
You can explicitly send password-encrypted backups to your own HTTPS WebDAV/Nextcloud folder or a system file/share destination. Transfer credentials are used for that operation and not saved as task drafts. Your selected provider has its own privacy and retention practices. Operating-system backup and native temporary-file handling require platform verification; this candidate does not promise that every operating-system copy is excluded.
Accounts, trial access and purchases
Supabase processes sign-in email, account identifiers, login verification, sessions and service information. A session is stored on your device. Authentication email and support mail also involve the configured email providers. Service-provider details will be confirmed before app release.
Stripe handles direct-web checkout and subscription management. Apple and Google handle store purchases. NiyaJar verifies purchases and stores account associations, purchase identifiers, product, renewal and paid-access information. The payment service handles card entry. Plaintext ledger records are not sent to authentication or billing services. Payment services can retain records under their own legal responsibilities.
The service keeps a secret-key hash of a normalized email and the trial-start date to limit repeat trials. The hash is pseudonymous: the operator can match an email using the service's secret. The source retention policy approved by the owner on 4 November 2026 keeps this identity for 24 months after the most recent validated trial-eligibility check, including after account deletion. A later validated check refreshes that period. The existing account keeps its original trial start; deleting an identity hash does not restart that account's trial. After 24 months without such a check, a newly created account can qualify again. The trial itself remains 14 days.
Older identity rows did not record a last-check time. The migration initializes those rows to the date it is applied, so their first 24-month cutoff runs from migration rather than an invented past activity date. Eligibility checks disregard expired identity matches even before scheduled physical cleanup. The source migration and schedule still need deployment and verification; owner approval is not proof that production data has already been cleaned. Provider backups and necessary legal exceptions have separate handling. This record is not anonymous.
Optional cloud backup and personal sync
Cloud backup needs a separate choice. Encrypted copies leave the device for Supabase storage. The service also holds account identity, opaque vault/object identifiers, revisions, sizes, timestamps and access/retention metadata. Encryption does not make this metadata anonymous.
Receipt photographs and saved inbox records need an additional choice. Their notes, links and images are encrypted before upload. Images are resized and source location metadata is removed. Turning this option off stops future inclusion; existing copies keep their content until normal deletion. Remembered places and unfinished task drafts are outside this cloud scope.
When available, separately enabled personal sync checks for changes while the app is open, unlocked and online. It can synchronize books and private ledgers within your account and include those private records in later ordinary recovery snapshots. Receipts still need the separate receipt choice. Current sync copies, merge state and protected conflicts have lifecycles separate from ordinary snapshots. Sync can require conflict review and is not continuous closed-app protection.
The server is not given your passphrase or recovery key to decrypt these records. A person with usable encrypted data and its decryption secret may be able to read it. Email access and purchase restoration do not replace that secret.
Household sharing and nearby transfers
Creating or joining a household uploads an encrypted projection of records selected for sharing. Current members can read shared records and retained shared history; only editors can change them. Removing someone stops future authorized service access but cannot erase downloaded copies. Shared history is limited to ten versions available for thirty days, pruned on access/write, rather than a permanent audit trail.
Supabase stores household administration metadata outside the encrypted budget: owner/member identifiers, user-chosen member display names, roles, invitation hashes and expiry, revision/subscription timestamps, ownership offers, successor appointments, recovery votes, payment handovers and backup allowance grants. Chosen names are visible to current members. Do not put secrets or financial details in a member display name.
Household-private ledgers use separate keys and stay out of shared totals/history. Their household-private cloud-copy action is manual. Optional account-private personal sync is different and can include those private records in personal copies. Membership removal ends access to the household-private cloud row; that row can remain until household or member-account deletion. Keep a suitable personal export before leaving.
Owner-account deletion preserves the household for surviving members; accepted succession or unanimous recovery can restore ownership. It does not erase another member's records. Household deletion is a separate process. Sponsorship does not permit the payer to read members' private copies. Every current member must receive the required notice before expiry/deletion cleanup of the household.
Nearby sharing sends an encrypted shared projection directly to a manually paired local-network device and requires recipient confirmation. There is no cloud relay or background discovery. Optional foreground native discovery broadcasts a random session name through Bonjour and exchanges encrypted connection descriptions with the chosen device. Receipts, places and private records stay out of nearby shared projections. Participants control their copies and connection secrets.
Permissions and speech recognition
Camera/photo selection, location and microphone use start from your action and the relevant permission prompt. Remembered-place matching is local. Location is requested through location actions; disabling learned places deletes the learned places. Coordinates are not sent to authentication or billing services.
Voice entry needs a separate confirmation before listening and produces editable text for your review. Depending on device, language and browser, an operating-system or browser speech service may process expense audio, including information you say about an expense, on its servers. Internet may be needed. On-device recognition is used when supported but is not guaranteed. Provider handling and retention follow that service's applicable notices. Check the speech service notices for your platform. You can type instead. Stopping listening or closing the flow stops the app's request; it cannot undo provider processing already performed.
Native reminders and widgets use device services. Widgets keep encrypted pending captures with a separate capture key and import them after unlock. Permissions and store declarations must match the released native binaries.
Reports, acceptance receipts and service operations
Error/crash reports, performance reports and aggregate usage counts are separate, initially off choices. Legal acknowledgment alone does not enable them. You can turn each off in the app. Sentry receives allowed technical error codes, platform/build information and code locations for crash reporting. Separately chosen performance reports contain fixed operation/outcome names, rounded durations and sampled timings. PostHog receives fixed screen/action counts with platform/release information.
App report payloads exclude financial records and amounts, entered text, account or persistent device identifiers, credentials, screenshots, recordings and replay. Providers nevertheless receive network metadata such as IP addresses. Native crash SDKs can temporarily cache sanitized reports while enabled; revocation gates transport and clears the dedicated cache. Reports are not guaranteed anonymous.
When enabled, the signed-in account receipt service stores document acceptance and the three report choices in Supabase. A receipt contains exact document URLs/versions, disclosure version, interface language, client timestamps, a random event identifier and a server receipt time bound to the verified account. It contains no ledger or credentials and cannot enable reports on another device. Local-only use keeps it on the device. Offline changes may be combined before upload. Superseded receipt history is retained for 24 months after server receipt; the most recently server-received receipt is retained while the account exists. Live receipt rows cascade on account deletion; provider backups are separate. These owner-approved source controls require the retention migration and scheduler to be deployed and verified before production handling is claimed.
Backend requests create rate-limit/security counters and can create fixed operational records. Quota rows become eligible for removal after 48 hours; user-specific quota subjects are removed when verified account deletion completes. An hourly scheduled sweep removes eligible trial identities, receipt history and quota rows in bounded batches of up to 10,000 per category. Backlogs or failed runs can extend physical cleanup beyond the eligibility cutoff; the operator must monitor and clear them. This schedule is implemented in source but not activated on a production service by this document.
Configured app-controlled service logs contain a service, response category and rounded duration, rather than request bodies, identities or raw exceptions. Hosting providers can separately process IP addresses, headers and access/security logs. These operations do not observe an offline ledger.
Support receives your email and content you choose to send. A technical summary can be reviewed and sent only through your explicit copy/email action. Do not send financial files, passphrases, recovery keys or sign-in codes. Routine support and request evidence need the approved category-specific retention schedule.
Locations, purposes and safeguards
Service information supports accounts and verified access, service protection, your optional storage/sharing/reporting choices, requests and legal obligations. Optional reporting consent is separate from contract acceptance. New purposes require assessment and any consent required by applicable law.
Service-provider roles, locations, retention and safeguards are under review before app release. Processing may occur outside your country under the laws there. Our BC address does not establish Canadian-only storage.
Retention and deletion
You control local deletion. Turning an upload/reporting option off stops future optional collection and does not itself remove earlier copies. Unfinished drafts are excluded from backups; readable exports and downloaded copies remain with their destinations.
Cloud copies follow the disclosed quota and recovery-point rotation. After paid access ends, uploads stop while existing copies remain downloadable for at least 90 days. Expiry cleanup also waits at least 30 days after confirmed notice delivery and never precedes the date in that notice. Delivery failure can extend retention. Every current household member must be notified. Renewal cannot restore files whose deletion was committed after the deadline.
Verified account deletion removes account-owned cloud copies before identity deletion without that expiry wait. Successful deletion stops direct-web Stripe renewal; Apple/Google subscriptions need separate cancellation. Deletion itself does not request a refund. Surviving members' shared household records and separately controlled platform transaction records are not erased with one account.
The owner-approved metadata retention policy is implemented in prepared source changes. Production activation, jurisdiction review, provider log/backup handling and necessary tax, request or incident exceptions still require verification. These metadata limits do not shorten the cloud-copy protections above. This candidate does not establish that production cleanup has been activated.
Requests, eligibility and changes
Use in-app account deletion or the public /account-deletion resource on the app host. You can email support@niyajar.com without reinstalling or unlocking. Account control is verified proportionately; decryption secrets are never needed. An email request does not itself complete deletion.
You can ask about handling, access/correction of service information, applicable deletion rights, withdrawal of optional consent or complaints through the same contact. Applicable deadlines and exceptions depend on the request. We cannot decrypt financial records for you. Rights and complaint routes depend on applicable law, including BC PIPA and PIPEDA where applicable. This draft does not set one worldwide request deadline.
The intended launch audience is adults who are at least 18 and have reached local majority, including 19 in BC. Identify material notice changes and provide required notice or choices before a materially different use. A policy edit alone does not authorize new processing.