Privacy Policy

Vincent Caesar Alcantara (sole trader; shown as 'ALCANTARA, VINCENT CAESAR' on the ABN register) trading as StrataSync (ABN 94 284 349 791) holds the personal information described in this policy.

Privacy officer: Vincent Alcantara, vincent@stratasync.au.

Contact: admin@stratasync.au. There is no postal address for privacy requests.

We collect personal information that is reasonably necessary for StrataSync. The main kinds are:

• Account details. Your name, email address, and a hash of your password. We do not store the password itself. If you use Google sign-in, we receive what Google sends to identify the account, usually your name, email address, and whether Google has verified the email.
• Strata records. Scheme and plan details, addresses, lots, unit entitlements, levies, meetings, votes, proxies, repairs, messages, and the other records the scheme enters.
• Uploaded documents. Files a user uploads, such as by-laws, minutes, insurance, and plans. Those files may contain personal information.
• Owner, resident, and tenant information. Names, contact details, lot details, and other information the scheme stores about those people, including people who do not have their own login.
• Payment data. If a card is used, Stripe collects the card details. We receive a status and a reference. We do not store the full card number, the expiry date, or the card security code.

We collect this from you, from other users in the scheme who are allowed to enter it, and from Google if you choose Google sign-in. We collect it to provide accounts, records, notices, and payments. If you do not give the account details, we cannot create the account. The product holds the scheme records the scheme chooses to enter.

This section is our notice of collection under APP 5 for information we collect ourselves. If the scheme collects information from an owner or resident and then types it in, the scheme gives that person its own notice.

We use personal information to:

• provide the service and decide who in the scheme can see which records
• host documents and show them to people the scheme has authorised
• keep notices the scheme asks us to record
• bill the subscription and any AI usage fee, once those charges exist
• investigate misuse and keep the service reliable
• meet a legal requirement, including a notifiable data breach assessment

We do not sell personal information. We disclose it to the processors named below, to other users in the same scheme according to the role the scheme set, and where the law requires it.

We do not use personal information for a new purpose you would not reasonably expect, unless the law allows it or you consent. A document is sent to an AI provider only for extraction you ask for, and only once that feature exists.

The list below is what this repository actually does. Where a processor is named because it is the intended provider, and the code does not call it, the entry says so.

• Supabase, database. The hosted database is Supabase Postgres. It holds account records, strata records, and the email log. This repository does not use Supabase Auth. Sessions are Auth.js JSON Web Tokens, and the user row lives in that database. File bytes are not stored in Supabase Storage. They are written to the server disk (STORAGE_PATH, default ./storage).
• Vercel, hosting. Vercel runs the application. Requests, and files on that instance’s disk, pass through the hosting region. On Vercel the local disk is wiped when a new deployment replaces the instance, so uploaded files are not durable there.
• Stripe, payments. Stripe receives the card details the payer types into Stripe Checkout, plus the amount, currency (AUD), a description, and the return URLs. We store the Checkout Session id, the status, and the amount. We do not store the full card details. The default provider is a mock checkout that does not call Stripe. A Stripe call happens only when the deployment sets the Stripe provider and a secret key. That adapter creates a one-off Checkout Session for a levy notice. It does not create the monthly subscription described in the terms.
• Google, optional sign-in. If Google sign-in is turned on and you use it, Google receives the sign-in and we receive the identity details described above. If the buttons are hidden, Google is not called.
• Vercel AI Gateway and model providers, document extraction. AI features may be processed via Vercel AI Gateway by third-party model providers such as xAI (Grok), OpenAI and Anthropic. A provider may receive the uploaded document, which can contain owner, resident, and tenant information, so it can extract data. We may change providers, including to an Australian-hosted model, and we will update this policy when we do. Providers are not permitted to use customer personal information to train their models.
• Postmark, transactional email. Postmark is the intended provider for email the scheme asks us to send. It is not connected. Notices are written to the server log and to an email log in the database (recipient name, email address, subject, and body). Postmark receives nothing. If it is connected later, it would receive that name, address, and message, and this policy will say so before that happens.
• PostHog, product analytics, in the United States (us.i.posthog.com). When a deployment turns analytics on, the server sends anonymous usage events to that host. The browser does not contact posthog.com. It sends those events to this site at /r, and this site forwards that path to us.i.posthog.com after removing cookies and the client IP. If analytics is not turned on, PostHog is not called and it receives nothing. An event can include the page path, the kind of action (a sign-up, a scheme being created, a document upload, a meeting, or a notice), an anonymous id that stays in memory for that browser tab, and, after you sign in, your account id and the scheme id. Those are the internal ids already stored for the account. An event does not include your name, email address, street address, lot number, or a levy amount. Session recording is off. Autocapture, heatmaps, and surveys are off.

The product is intended to let a scheme send an uploaded document to an AI provider so the provider can extract data from it. The document may contain personal information about owners, residents, and tenants. Sending it would be a disclosure for that purpose.

AI features may be processed via Vercel AI Gateway by third-party model providers such as xAI (Grok), OpenAI and Anthropic. We may change providers, including to an Australian-hosted model, and we will update this policy when we do. Those providers may process personal information outside Australia, including in the United States. Providers are not permitted to use customer personal information to train their models.

You must still check any extraction against the source. It is not legal or financial advice. That limit is also in the Terms of Service.

Before personal information is disclosed overseas, we take steps so the recipient handles it in line with the APPs, or we disclose only where APP 8 otherwise allows. This repository does not pin every region in code. Read the regions below against the deployment you are using.

• Supabase. No Supabase region is committed. A note in the repository describes the app as a Vercel function in Sydney (syd1) calling Supabase. Test fixtures include a Sydney pooler host (ap-southeast-2) and also generic hosts. Those fixtures are not the live project. The database is processed in the region of the Supabase project that is connected. If that region is outside Australia, personal information in the database is processed outside Australia.
• Vercel. No region file is committed. The same note describes the function region as Sydney (syd1). The Vercel project setting is what applies. If that setting is not Sydney, hosting may be outside Australia. Vercel may also process platform metadata, such as deployment logs, outside Australia even when the function region is Sydney.
• Stripe. Stripe processes payment information outside Australia, including in the United States. That happens when a deployment actually calls Stripe. The mock provider does not.
• Google. If you use Google sign-in, Google may process that sign-in outside Australia, including in the United States.
• AI providers. Model providers reached through Vercel AI Gateway, such as xAI (Grok), OpenAI and Anthropic, may process personal information outside Australia, including in the United States. Under Australian Privacy Principle 8, before we disclose personal information overseas we take reasonable steps to ensure the recipient handles it in line with the APPs, unless a permitted exception applies. An exception includes where you consent, or where we reasonably believe the recipient is subject to a law or binding scheme that is substantially similar to the APPs and that you can enforce. Where we rely on those reasonable steps, we can remain accountable under the Privacy Act if the recipient mishandles the information. We may change providers, including to an Australian-hosted model, and we will update this policy when we do.
• Postmark. Not connected, so there is no overseas disclosure to Postmark. The countries where it processes mail will be named here before it is turned on.
• PostHog. When analytics is turned on, the usage events described above are processed in the United States at us.i.posthog.com. They do not include your name, email address, street address, lot number, or a levy amount. If analytics is not turned on, there is no disclosure to PostHog.

Product analytics uses PostHog only when a deployment turns it on, and then only as described under Processors. Checked against the code in this repository:

• The analytics id is kept in memory for the tab. The app does not set a PostHog cookie.
• A browser that sends Do Not Track, or Global Privacy Control, does not get analytics.
• Session recording is disabled. If a PostHog project setting turned it on, text, inputs, and element attributes would be masked.
• Autocapture, heatmaps, and surveys are off.

Cookies the app does use, none of them for advertising:

• A signed session cookie from Auth.js, so you stay signed in. Auth.js also uses a cookie to protect the sign-in form from cross-site requests.
• ss_scheme, an httpOnly cookie with the active scheme id, once you belong to a scheme.
• ss_signup, a short-lived httpOnly cookie set only when you start Google sign-up, then cleared. It records that the sign-in was started from the sign-up page. It does not store the terms version.
• brand-theme and appearance, which remember display choices in the browser. They are set from the theme controls and can be read by the page. They are not analytics.
• ss_ask_interest, an httpOnly cookie set when a signed-in person asks to be told when Ask AI opens. It stores that person’s account id on this browser. It is not sent to PostHog.

The marketing header asks the session endpoint after the page loads, so a signed-in person can be shown a link to the dashboard. That request is not an analytics call.

We protect personal information with role checks on the server, a hashed password, signed session cookies, and httpOnly cookies for the session, the active scheme, and the short-lived Google sign-up flag. When the database host is Supabase, the connection asks for TLS. No method of storage is perfectly secure. This repository does not encrypt uploaded files at rest.

We keep personal information for as long as the account and the scheme need it for the service, and for any longer period the law requires, such as a tax record of a software fee.

When an account or scheme is cancelled, you can ask for a copy of the records for 30 days after cancellation. After those 30 days, we delete the data, except where retention is required by law. Copies in backups are removed as those backups age out. On Vercel, files on the local disk do not survive the next deployment.

You can ask for access to the personal information we hold about you, and you can ask us to correct it. A person the scheme has authorised can also correct scheme records inside the product.

We will respond within a reasonable period. If we refuse, we will tell you why, unless the law says we should not, and we will tell you how to complain. There is no charge for a straightforward request. If a request is large, we will tell you before we charge a cost-recovery fee the Privacy Act allows.

Send requests to Vincent Alcantara at vincent@stratasync.au.

If we have reasonable grounds to believe an eligible data breach has happened, we will contain it, assess it, and follow the Notifiable Data Breaches scheme in Part IIIC of the Privacy Act 1988 (Cth). Where that scheme requires notification, we will notify the Office of the Australian Information Commissioner and the people at likely risk of serious harm.

Contact Vincent Alcantara at vincent@stratasync.au first. You can also use admin@stratasync.au. We will acknowledge the complaint and tell you the outcome.

If you are not satisfied, you can complain to the Office of the Australian Information Commissioner (OAIC). The OAIC is the national privacy regulator. Its public contact details are: Office of the Australian Information Commissioner, GPO Box 5288, Sydney NSW 2001, phone 1300 363 992, oaic.gov.au/privacy/privacy-complaints. That address is the regulator’s address, not ours.

We will post changes on this page and update the version and the “Last updated” date. The version of this policy is 2026-10-20.3, last updated 20 October 2026.