Security & data handling
Process the job. Deliver the output. Delete the financial files.
The product architecture is built around a narrow promise: uploaded ledgers are temporary work material. They are not a dataset we want to keep.
What we never ask for
- Your Yardi Breeze username, password, session, or API access.
- Your bank username, password, connection, or aggregator authorization.
- Permission to scrape or automate either service.
Deletion timeline
| Data | Planned treatment |
|---|---|
| Uploaded financial files | Deleted at job completion; maximum 24-hour object-storage lifecycle backstop. |
| Intermediates | Deleted immediately after processing. |
| Generated PDFs and ZIPs | Deleted after download or 24 hours, whichever comes first. |
| Job metadata | Counts and status retained; no ledger rows or identity-linked amounts. |
| Owner mappings and branding | Retained until you delete them. |
| Owner closing balances | Optional, encrypted, and deletable in Settings. Turn storage off to re-enter opening balances each month. |
Limited use of models
The initial commentary workflow is deterministic. If an optional language-model feature is added later, it is designed to receive only aggregated variance rows such as category, amount, and delta — never owner names, tenant names, or account numbers. Your uploaded financial data is not intended as model-training data.
What still requires verification
This page describes the planned production architecture, not a certification. Production deletion behavior, encryption, access controls, logging, and vendor configuration must be tested before launch. Those launch checks are tracked explicitly rather than implied by marketing language.