Privacy Policy

1 About This Policy

Lex Etheris (accessible at lexetheris.com.au) is a service operated by Lex Stratus Software Pty Ltd (ACN 633 861 275). In this Privacy Policy, "we", "us" and "our" refer to Lex Stratus Software Pty Ltd trading as Lex Etheris.

Lex Stratus Software Pty Ltd complies with the State and Commonwealth Privacy Laws, including the Privacy Act 1988 (Cth) and the Australian Privacy Principles ("Privacy Law"). Lex Stratus Software Pty Ltd is committed to your privacy and to continuing to provide services in a confidential and safe manner.

This Privacy Policy summarises how Lex Stratus Software Pty Ltd handles your personal information.

We handle all personal and sensitive information you provide in accordance with Privacy Law and the safeguards this Privacy Policy describes. This policy applies to everyone the platform serves — the law practices that subscribe to it, and the people who use it at a representative's invitation.

2 Personal Information

Personal information is defined by the Privacy Act 1988 (Cth) as "information or an opinion about an identified individual, or an individual who is reasonably identifiable: (a) whether the information or opinion is true or not; and (b) whether the information or opinion is recorded in a material form or not."

The information collected is required in order to provide our services — which include case and client management, forms automation, appointment booking, billing and, for law practices that use it, trust accounting — and to improve those services.

Generally, the only personal information Lex Stratus Software Pty Ltd collects about you is that which you choose to tell us, or which you authorise us to obtain. There is one significant exception. Where a law practice uses our platform, it gives us information about its own clients, and it records in its trust books the details of people it pays money to and receives money from — who may have no relationship with us and may never have dealt with us. We hold that information on the practice's behalf and only for the purposes described under trust accounting below.

The type of information we may collect includes:

• identity and contact details — name, postal and email address, telephone number, and the details of the organisation you act for;
• account and billing information — your login details, your subscription and, where you purchase services, payment information (card numbers are handled by our payment provider and are not stored by us);
• professional credentials, where you are a practitioner — including a practising certificate number and expiry date and whether that certificate authorises the receipt of trust money;
• information you or a law practice enters into a matter — which, depending on the service, may include date of birth, passport and travel-document details, country of birth and of passport, and information relevant to an application, including health-related declarations that some visa applications require;
• trust-accounting information, where a law practice uses that module — including client and matter details, amounts, and the bank details of payers and payees. This is described in detail under trust accounting below;
• bank transaction data, where a practice connects its account — described under bank connections below; and
• technical information about your use of the website, described under automatic information below.

Some of this is sensitive information as the Privacy Act defines it — in particular health information supplied as part of an application. We collect it only where it is reasonably necessary for a service you or your law practice has asked us to provide, and we handle it in accordance with Australian Privacy Principle 3.

Sensitive Information in Visa Matters

Visa and immigration matters routinely involve sensitive information beyond the health declarations mentioned above: a person's racial or ethnic origin, health information, criminal record and, where a protection claim makes them relevant, religious beliefs, political opinions or sexual orientation. We collect sensitive information with consent and handle it only for the purposes of the matter it belongs to; we do not use it for any secondary purpose of our own.

Much of this information is not typed in by the person it is about. It is entered by the practitioner acting on that person's behalf, from the instructions and documents the person has given the practice — a collection from a third party rather than from the individual. The practice is responsible for having its client's consent to record it; we hold what is recorded under the protections this policy describes.

3 How Lex Stratus Software Pty Ltd Collects and Holds Your Personal Information

Where possible, Lex Stratus Software Pty Ltd will collect your personal information directly from you.

Personal and sensitive information may be collected from you when you provide it to us directly.

Lex Stratus Software Pty Ltd has established appropriate physical, electronic and managerial procedures to safeguard any information we collect. This helps prevent unauthorised access, maintains data accuracy and ensures that the information is used correctly.

All data transferred to and from Lex Stratus Software Pty Ltd servers is encrypted, and a firewall is in place to prevent intrusion. All data stored within our systems is designed to be accessed only by authorised staff members and the hosting facility.

4 Automatic Information

Lex Stratus Software Pty Ltd receives and stores certain types of technical information whenever you interact with us. This section says what that information is, what it is used for and how long it is kept. None of it is used for advertising, and none of it is disclosed for marketing.

Signed-In Requests and Security Logs

On every authenticated request to our platform we derive, on our own servers, the client IP address and a hashed browser fingerprint computed from browser identity headers, platform and language. Together they bind your session token to the connection that requested it — so that a token presented from a different device or network is refused — and they power rate limiting and the temporary blocking of abusive request patterns.

These values are kept in access-security logs for 180 days. Authorised staff can review a per-account timeline of platform API activity — an activity and audit monitoring console — for security, abuse investigation and support. Access to that console is itself restricted to authorised staff and is used for those purposes only.

Cookies

We use a single strictly-necessary cookie: a refresh-token cookie, set with the Strict same-site attribute, that keeps you signed in. Your browser's session and local storage are used for sign-in state. We set no third-party analytics, advertising or social-media cookies, we use no tracking pixels, and open and click tracking is disabled on the email we send. The full detail is in our Cookie Policy.

5 Purpose for Collecting, Holding, Using and Disclosing Personal Information

Lex Stratus Software Pty Ltd collects personal information that we consider relevant, and which is provided to us when you or a law practice engages our services, for the purpose of providing those services. Sensitive information, in most cases, can only be disclosed with your written consent. Personal information will not be used or disclosed for direct marketing unless you have given Lex Stratus Software Pty Ltd consent to do so.

Some of the ways we use personal information include to:

• personalise your service
• communicate with you and others as part of our core business
• send you information regarding changes to our policies, other terms and conditions, online services and other administrative issues
• enable us to provide a product or service
• allow us to track your service history
• prevent, detect and investigate crime, including fraud and money laundering, and analyse and manage other commercial risks
• verify information you have given to us
• carry out market research and analysis, including satisfaction surveys
• resolve complaints, and handle requests for data access or correction
• comply with applicable laws and regulatory obligations (including laws outside your country of residence)
• comply with legal process and respond to requests from public and governmental authorities (including outside your country of residence)
• establish and defend legal rights, protect our operations, rights or property, you or others, and pursue available remedies or limit our damages
• keep, produce and preserve the trust records that legal profession legislation requires a law practice to keep, and make them available for external examination and regulator inspection
• reconcile a law practice's trust account against its bank records and identify a deficiency or irregularity
• comply with record-retention obligations that require us to keep specific information for a fixed period, even after you have asked us to delete it

6 Disclosure of Personal Information

Lex Stratus Software Pty Ltd may disclose your personal or sensitive information (as defined in the Privacy Act):

• to regulatory authorities;
• where the law requires us to do so;
• where you consent for us to do so;
• to the law practice that engaged us, where we hold the information on that practice's behalf;
• to an external examiner appointed to examine a law practice's trust records, and to the legal services regulator of the practice's jurisdiction (a Legal Services Commissioner or Law Society), where the records are required to be produced for examination or inspection. Trust records are kept precisely so that they can be examined, and a practice cannot decline to produce them; and
• to service providers that host or process information for us under contract and on our instructions — our cloud provider, our email provider and, for bank-transaction data, our accredited CDR data recipient. Each is described in the relevant section of this policy.

Overseas Disclosure

Your data is stored in Australia: our compute and data stores run on Amazon Web Services in the Asia Pacific (Sydney) region. A small number of specific functions involve disclosure to providers that operate overseas. For the purposes of Australian Privacy Principles 1.4(f)–(g) and 8, the recipients and the countries in which they are likely to be located are set out below. Before disclosing personal information to an overseas recipient we take reasonable steps — including contractual safeguards — to ensure the recipient does not breach the Australian Privacy Principles in relation to it.

In addition: Zoho processes inbound email sent to our support and privacy mailboxes, and may process it in the United States, India and Australia, the countries in which its data centres and support operations are located; and Google and Microsoft process mailbox and calendar data only where a practitioner has chosen to connect a Gmail or Google Calendar account, or an Outlook mail or calendar account — both are United States providers, and that data may be processed in the United States and in the other countries where they operate infrastructure. Trust records and CDR data are not disclosed outside Australia.

Electronic Signing and Message Recall

Two features disclose information in ways worth stating separately, because the recipients are the other parties to your own documents and conversations.

• Electronic signing. When an e-signature envelope is completed, an audit page is appended to the final PDF recording each signer's name, email address, the time they signed and the IP address they signed from. The completed PDF, including that audit page, is provided to the practitioner and to every signer — so in an envelope with more than one signer, each signer can see the others' IP addresses. The signing browser's technical details are stored for the audit trail but are never printed on the document.
• Message recall. Recalling or unsending a chat message hides it from all participants, but the original text and any attachments are retained for legal audit and record-keeping purposes. Recall changes what is displayed; it does not erase the record.

7 How We Use Artificial Intelligence

Parts of our platform are assisted by artificial intelligence, and every one of them is identified as AI in the product where you use it. The AI features are: an assistant that answers questions over Australian legal materials; drafting and action suggestions for practitioners; and document and news summaries. Platform fees for these features are charged to law practices as software fees; a visa applicant is never charged for them.

AI inputs are processed by third-party model providers:

• OpenAI (United States) — question answering, intent extraction and the embeddings used to search legal materials; and
• Anthropic models via AWS Bedrock (Asia Pacific inference profile — Australia, Japan, Singapore and India; inference may route across these regions) — internal analysis of error diagnostics, which can include captured request data, and summaries of public news for our practitioner digest.

Under those providers' published API terms, API inputs and outputs are not used to train their models. We do not send trust records or CDR data to any AI system, and a practice can ask us to disable AI features for its account.

AI output can be wrong. It is not legal advice and is not a substitute for it. A qualified practitioner must review AI output before any reliance is placed on it — the platform performs clerical, administrative and technical functions, and the professional judgement in a matter is always the practitioner's.

8 Google User Data (Gmail and Calendar Integration)

Lex Stratus Software Pty Ltd offers two optional Google integrations for a lawyer using our platform: an email feature, which lets a lawyer connect their own Google account (a Google Workspace account or a personal Gmail account) so that client correspondence can be read and managed directly within the relevant matter; and a calendar feature, which lets a lawyer connect their Google Calendar so that appointments booked through our platform stay in sync with their own calendar. Each integration is entirely optional, is connected separately, requires the lawyer's explicit consent through Google's secure OAuth sign-in, and can be revoked at any time. This section explains how we access, use, store and protect Google user data, and applies in addition to the rest of this Privacy Policy.

Google Account Access We Request

When a lawyer chooses to connect a Google account, we request only the access strictly necessary to provide the feature being connected. Depending on which integration the lawyer connects, we request the following OAuth scopes:

• https://www.googleapis.com/auth/gmail.modify (email feature) — to read the lawyer's messages (including subject, sender, snippet, body content and attachments) and to update the state of those messages, such as marking them read or unread, starring them, flagging them as important, archiving them, marking them as spam, and moving them to or restoring them from the Trash;
• https://www.googleapis.com/auth/calendar.events (calendar feature) — to view and edit the events on the lawyer's calendars: to read the lawyer's existing events and to create, update and delete events on the lawyer's behalf, so that appointments booked through our platform can be written to the lawyer's calendar and kept in sync, and so that the lawyer's existing events can be used to calculate available appointment slots and detect scheduling conflicts;
• openid and https://www.googleapis.com/auth/userinfo.email — to identify the email address of the connected Google account so that the lawyer can distinguish between multiple connected accounts.

We do not request any broader access than this. We never receive or store your Google account password, as authentication is handled entirely by Google.

How We Use Google User Data

Google user data accessed through these scopes is used solely to provide and operate the integration that the authenticated lawyer connected. For the email feature, we use Google user data only to:

• retrieve and display the lawyer's email messages, message bodies and attachments within our platform;
• mark messages as read or unread;
• add or remove stars and "important" markers;
• archive messages (remove them from the Inbox) and mark messages as spam;
• move messages to the Trash and restore messages from the Trash.

For the calendar feature, we use Google Calendar data only to:

• retrieve and display the lawyer's calendar events within our platform's calendar view;
• create, update and delete events on the connected calendar — in particular, to write appointments booked through our platform into the lawyer's calendar and keep them in sync; and
• read the lawyer's existing calendar events to calculate available appointment slots and to detect and prevent double-booking.

When an appointment is booked through our platform, the calendar event we create, and the booking record it is based on, may include the client's name, email address, any note added to the booking, meeting details (such as a video-call link or phone number) and fee information. This information is written to the connected calendar and, depending on the booking, is used to email the client a confirmation, rejection, cancellation or reschedule notice.

We do not use Google user data for any other purpose.

Limited Use Disclosure

Lex Stratus Software Pty Ltd's use and transfer of information received from Google APIs to any other application will adhere to the Google API Services User Data Policy, including the Limited Use requirements. In particular:

• we only use Google user data to provide and improve the user-facing email and calendar features described above;
• we do not transfer or sell Google user data to third parties, except as necessary to provide or improve these features, to comply with applicable law, or as part of a merger, acquisition or sale of assets with notice to users;
• we do not use Google user data for serving advertisements;
• we do not allow humans to read Google user data unless we first obtain your affirmative agreement to view specific messages, it is necessary for security purposes (such as investigating abuse), it is necessary to comply with applicable law, or the data has been aggregated and anonymised; and
• we do not use Google user data to develop, improve or train generalised or non-personalised artificial intelligence or machine learning models.

How We Store and Protect Google User Data

When you connect a Google account, Google issues us a long-lived authorisation credential (a "refresh token"). This token is encrypted using a managed key service and stored securely in our database; it is never exposed to the browser or to any client-side code. Email content and attachments, and calendar events, are retrieved from Google on demand to be displayed to the lawyer and are not retained beyond what is necessary to provide the feature; the exception is that appointments booked through our platform are stored as part of the booking record so that they can be managed and kept in sync. All data transmitted between your browser, our servers and Google is encrypted in transit.

What We Do Not Do

To keep our access to the minimum required, our Google integrations deliberately do not include certain capabilities. We do not:

• send, compose, draft or reply to email on your behalf;
• permanently delete email — messages can only be moved to the Trash, from which they can be restored, and they continue to follow Gmail's normal Trash retention;
• change your Gmail settings, filters or forwarding; or
• access any Google data outside the scopes listed above.

Revoking Access and Deleting Google User Data

You may disconnect a connected Google account (email or calendar) at any time from within our platform. When you do, we attempt to revoke the authorisation with Google and delete the stored credential for that account from our systems. You may also review or revoke our access directly from your Google Account at myaccount.google.com/permissions. Once access is revoked, we can no longer retrieve any data from the affected Google account.

9 Microsoft and Outlook Integration

Lex Stratus Software Pty Ltd offers two optional Microsoft integrations for a lawyer using our platform: an email feature, which lets a lawyer connect one or more of their own Outlook.com or Microsoft 365 mailboxes so that client correspondence can be read and managed directly within the relevant matter; and a calendar feature, which lets a lawyer connect their Outlook calendar so that appointments booked through our platform stay in sync with their own calendar. Each integration is entirely optional, is connected separately, requires the lawyer's explicit consent through Microsoft's secure OAuth sign-in, and can be revoked at any time. This section explains how we access, use, store and protect Microsoft user data, and applies in addition to the rest of this Privacy Policy.

Microsoft Account Access We Request

When a lawyer chooses to connect a Microsoft account, we request, through Microsoft Graph, only the access strictly necessary to provide the feature being connected:

• Mail.ReadWrite (email feature) — to read the lawyer's messages (including subject, sender, snippet, body content and attachments) and to update the state of those messages, such as marking them read or unread, flagging them, marking them as important, archiving them, and moving them to or restoring them from the Deleted Items or Junk Email folders;
• Calendars.ReadWrite (calendar feature) — to view the lawyer's calendar events, and to create, update and delete events on the lawyer's behalf, so that appointments booked through our platform can be written to the lawyer's calendar and kept in sync, and so that the lawyer's existing events and free/busy times can be used to calculate available appointment slots and detect scheduling conflicts;
• offline_access — to obtain a refresh token so that the connection continues to work without asking the lawyer to sign in again each time; and
• openid, email, profile and User.Read — to identify the connected account so that the lawyer can distinguish between multiple connected accounts.

We do not request any broader access than this. In particular, we do not request permission to send email on your behalf. We never receive or store your Microsoft account password, as authentication is handled entirely by Microsoft. The permissions actually presented on Microsoft's consent screen at sign-in govern where they differ from those listed here.

How We Use Microsoft User Data

Microsoft user data is used solely to provide and operate the integration that the authenticated lawyer connected. For the email feature, we use it only to retrieve and display the lawyer's messages, message bodies and attachments within our platform, and to mark messages as read or unread, flag or unflag them, mark them as important, archive them, and move them to or restore them from the Deleted Items or Junk Email folders. For the calendar feature, we use it only to display the lawyer's calendar events, to create, update and delete events (in particular, to write appointments booked through our platform and keep them in sync), and to read free/busy times to calculate available appointment slots and prevent double-booking.

When an appointment is booked through our platform, the calendar event we create, and the booking record it is based on, may include the client's name, email address, any note added to the booking, meeting details (such as a video-call link or phone number) and fee information. This information is written to the connected calendar and, depending on the booking, is used to email the client a confirmation, rejection, cancellation or reschedule notice.

We do not use Microsoft user data for any other purpose. We do not sell or rent it, we do not use it to serve advertising, and we do not use it to develop, improve or train generalised or non-personalised artificial intelligence or machine-learning models.

How We Store and Protect Microsoft User Data

When you connect a Microsoft account, Microsoft issues us a long-lived authorisation credential (a "refresh token"). This token is encrypted using a managed key service and stored securely in our database; it is never exposed to the browser or to any client-side code. Email content and attachments, and calendar events, are retrieved from Microsoft on demand to be displayed to the lawyer and are not retained beyond what is necessary to provide the feature; the exception is that appointments booked through our platform are stored as part of the booking record so that they can be managed and kept in sync. All data transmitted between your browser, our servers and Microsoft is encrypted in transit.

What We Do Not Do

To keep our access to the minimum required, our Microsoft integrations deliberately do not include certain capabilities. We do not:

• send, compose, draft or reply to email on your behalf;
• permanently delete email — messages can only be moved to the Deleted Items folder, from which they can be restored;
• change your mailbox settings, rules or forwarding; or
• access any Microsoft data outside the permissions listed above.

Revoking Access and Deleting Microsoft User Data

You may disconnect a connected Microsoft account (email or calendar) at any time from within our platform. When you do, we delete the stored credential for that account from our systems, after which we can no longer retrieve any data from that account. Because Microsoft does not provide a way for us to revoke our own authorisation on your behalf, to fully remove our application's access you should also remove it from your Microsoft account directly: for personal Outlook.com or Microsoft accounts at account.microsoft.com, and for work or school (Microsoft 365) accounts at myapps.microsoft.com.

10 Lex Stratus Forms Manager Browser Extension

Lex Stratus Software Pty Ltd offers an optional Google Chrome browser extension, "Lex Stratus Forms Manager", that helps a lawyer or registered migration agent using our platform auto-fill Australian Department of Home Affairs online forms (ImmiAccount, at online.immi.gov.au) and run VEVO visa-entitlement checks, using client data already held in their Lex Stratus account. Installing and using the extension is entirely optional. This section explains how the extension accesses, uses, stores and protects data, and applies in addition to the rest of this Privacy Policy.

Data the Extension Accesses

To perform its function, and only when you choose to start a form-fill or a VEVO check, the extension accesses:

• Authentication data — the secure session cookie that lexetheris.com.au sets when you log in, which the extension exchanges with our backend for a short-lived access token;
• client application data from your Lex Stratus account — retrieved from our backend on your instruction. This may include personal and sensitive information about your clients, such as names, dates of birth, passport and travel-document numbers, country of birth and country of passport, health-related declarations that some visa applications require (for example whether the applicant has a particular medical condition), and other visa-application field values; and
• the content of the ImmiAccount / VEVO web pages you are working on, so the extension can locate the correct fields and enter the data.

The extension only operates on lexetheris.com.au and online.immi.gov.au. It does not read your browsing history, does not track your activity, and does not access any other website.

How the Extension Uses Data

The data accessed by the extension is used solely to authenticate you to our backend, to retrieve the specific forms and client data you choose to work on, and to enter that data into the corresponding ImmiAccount form fields and VEVO enquiry fields in your browser. The extension acts only on your explicit action.

How the Extension Stores and Protects Data

Only the short-lived access token and the auto-fill progress (which field is next and which fields are completed) are stored locally in your own browser profile, so that you stay signed in and a fill can resume across the page navigations the forms trigger. Client personal data is not retained by the extension — it is held in memory only for the duration of an active session and is discarded when the session ends or the extension window is closed. All communication is encrypted in transit (HTTPS). The extension contains no advertising, analytics or tracking, and we do not sell or rent this data.

Who the Data Is Shared With

The extension transmits data only between your browser, our Lex Stratus backend (lexetheris.com.au), and the Australian Government system you are submitting to (online.immi.gov.au). Beyond those flows, nothing is sent anywhere: the extension contains no telemetry or analytics and reports nothing back to us or to any third party.

Your Control

You can stop the extension from accessing your data at any time by logging out from within the extension — which clears the data it has stored locally — or by removing the extension from your browser. Once you do, the extension can no longer access your Lex Stratus account or any client data.

11 Trust Accounting and Client Money

Our platform includes a trust-accounting module that an Australian law practice can use to keep the trust records that legal profession legislation requires it to keep. Where a practice uses that module, we hold the records of money the practice holds on behalf of other people — receipts, payments, a separate ledger account for each client for each matter, the statutory books of first entry, monthly reconciliations, and the documents produced from them. Those records necessarily contain personal information about people who are not themselves our customers: the practice's clients, and the people the practice pays money to and receives money from. This section explains whose information it is, why we hold it, who can see it, how long it is kept, and why some of it cannot be deleted on request. It applies in addition to the rest of this Privacy Policy and is read together with the Consumer Data Right, Information Security and Data Retention and Deletion sections below.

In New South Wales, Victoria and Western Australia the requirements referred to in this section come from the Legal Profession Uniform Law and the Legal Profession Uniform General Rules 2015. In Queensland, South Australia, Tasmania, the Australian Capital Territory and the Northern Territory they come from that jurisdiction's own legal profession legislation. The section references below are to the Uniform Law and the Uniform General Rules; where a practice is in another jurisdiction, the equivalent local provision applies.

Who Is Responsible for Trust Information

Two organisations are involved, and they are responsible for different things.

• The law practice operates the trust account. It collects the information from its own client, it decides what each record says, it is responsible to its client under its own privacy policy and its professional obligations, and the books are its books. Only the practice can authorise a change to a trust record.
• We supply and operate the software the books are kept in. We hold the information on the practice's instructions and for the purpose of running the module. We do not decide what a practice records, we do not use trust information for our own purposes, and we do not act on a request to alter a trust record from anyone other than the practice.

We describe this as holding information on a practice's behalf rather than as a “controller and processor” arrangement, because Australian privacy law does not draw that distinction and using it would understate our own obligations. Under the Privacy Act 1988 (Cth) an entity holds personal information if it has possession or control of a record containing it, and an entity that holds personal information is answerable for it under the Australian Privacy Principles in its own right. We are accountable for how this information is secured, retained, disclosed and destroyed. The practice is accountable for what it records and for its own relationship with its client. Both accountabilities apply at once; neither displaces the other.

What Trust Information We Hold

Where a practice uses the trust module, the records we hold on its behalf may include:

• the trust account itself — the account name in the form the rules require (UGR r 35(1)), the practice name and ABN, the jurisdiction, the name of the authorised deposit-taking institution, the BSB, and the account number, which is recorded in masked form;
• the people authorised to deal with trust money — name, practising certificate number and expiry date, whether that certificate authorises the receipt of trust money, whether the person is a principal of the practice, and which account of ours recorded the attestation;
• each client and matter — client name, address, contact email and, where supplied, telephone number; the matter reference and description; the ledger account number; the current balance; and the two dates that determine how long the record must be kept;
• each movement of money — amount, direction, effective date, purpose, counterparty, particulars, document reference, the running balance after the entry, and which user recorded it;
• the statutory books of first entry — in the receipts cash book, the receipt number, who the money was received from, on whose behalf, the purpose, whether it was cash, cheque or electronic transfer, who issued the receipt, and, where the practitioner records them for the printed receipt, the payer's account name, institution, BSB, account number and address; in the payments cash book, the payee, the person receiving the benefit of the payment, the payment reference or cheque number, the instrument, and the recipient's BSB and account number; in the transfer journal, the journal number, who authorised the transfer, the client's written authority reference, the principal's authorisation reference, and the counterparty's name and account number;
• the controlled money register — account name, institution, BSB, masked account number, the beneficiary's name and address (UGR r 64(3)), and the reference to the written direction under which the money is held;
• bills, invoices and receipts — the client, the recipient's name and email address, line items, amounts and notes, together with the practice's own letterhead as it stood at the moment the document was made out, which may include the practice's bank account name, BSB and account number;
• bank transactions imported from the practice's own bank — transaction date, value date, execution date, amount, description, reference, merchant name and category, BPAY biller code and customer reference number, APCA number, currency, and the complete unaltered transaction record exactly as the practice's bank supplied it; and
• a record of what was done — audit entries recording who made each change, when, what the record said before and after, and why; and a separate chronological log of every change to the five items UGR r 39 names.

Several of these are free-text fields that a practitioner completes: the purpose of a receipt or payment, the particulars of an entry, the description of a matter, the note on an invoice, and the reason given for a change. We do not require sensitive information (as the Privacy Act defines it) in any of them, and nothing in our system asks for it. What those fields contain is determined by the practice, and in some areas of practice a purpose or particulars line can reveal something a person would regard as sensitive. We use them only to produce the record and the documents made from it.

Bank Details of People Other Than the Practice's Client

The statutory books require a practice to record where money came from and where it went. A trust record can therefore contain the bank details of someone who has no relationship with us at all — the other side of a transaction, counsel, an expert, a landlord, a government agency. In particular:

• a payment out of trust records the recipient's BSB and account number, the payee's name, and, where the payment is made to an authorised deposit-taking institution, the name of the person receiving the benefit of the payment (UGR r 43(4));
• a receipt may record the payer's account name, institution, BSB, account number and address, so that the receipt can be reproduced years later exactly as it was issued (UGR r 36); and
• a transfer journal entry records the counterparty's name and account number (UGR r 46).

These details are held in full rather than masked. That is deliberate and it is the reason the record exists: a masked account number does not identify the account the money went to, and identifying it is the whole point of a payments record that an external examiner may later have to trace. We collect them because the statutory record is incomplete without them, and for no other reason.

A practice can also see a list of the accounts it has previously paid, so that a repeat payment does not have to be re-keyed. That list is derived entirely from the practice's own payments cash book, is visible only to that practice, and contains nothing the practice did not itself record. It is a history of accounts actually paid, not a list of accounts anyone has approved.

Why We Hold Trust Information

We hold trust information for one purpose: so that a law practice can keep, and produce, the records the law requires it to keep. Concretely, that means to:

• maintain a separate ledger account for each client for each matter, and the receipts cash book, payments cash book and transfer journal (UGR rr 36, 43, 46, 47);
• produce receipts, bills, trust account statements, trial balances and monthly reconciliations, and keep them in permanent form for the period the law sets (LPUL s 147);
• detect and surface a deficiency in trust money, an overdrawn ledger account, or an irregularity a practice is required to report (LPUL ss 148, 154);
• keep trust money separate from the practice's own money, and prevent a withdrawal that is not properly authorised (LPUL ss 146, 144(2)(b); UGR r 42);
• support an itemised bill and the disclosure a practice must make where a client disputes an amount (LPUL ss 187, 192); and
• make the records available to the practice for external examination and for inspection by its regulator.

We do not use trust information to provide any other feature of the platform, to develop or improve unrelated features, or for any commercial purpose of our own.

How Trust Information Reaches Us

Trust information reaches us in three ways.

• A practitioner enters it. Most of it — a receipt, a payment, a journal transfer, a client's details, the particulars of an entry — is typed by someone at the practice at the time the money moves.
• A practice imports an existing ledger. A practice moving from another system can upload a file listing its open matters. That file carries a matter name, client name, client email, client address and opening balance for each matter, and may also carry a telephone number, matter reference, matter description, evidence reference and the date the ledger last moved in the old system. It is sent with the request and checked before any of it is applied; a file that fails any check is refused whole rather than partly imported, and its contents are verified against a checksum so that what was validated is what was applied. Information imported this way is information about a practice's clients that we receive from the practice rather than from the client. The practice is responsible for telling its clients that it uses our platform.
• The practice's bank sends it. Where a practice connects its trust account, transactions are imported from the practice's own bank under the Consumer Data Right. See section 12.

Who Can See Trust Information

Trust records belong to the practice, not to an individual login. Every request — read or write — is checked against the practice's own trust account before any record is touched. A request naming another practice's trust account is answered as though that account did not exist, so a caller cannot even learn that it is there.

Within a practice, three authorities are deliberately kept separate and are not interchangeable:

• administering the subscription — paying for the service and managing users. This carries no authority over trust money whatsoever;
• being a trust signatory — which requires a current practising certificate that authorises the receipt of trust money. The certificate is checked at the moment the authority is used, not merely when it was first recorded; and
• being a principal of the practice — which is required to authorise a transfer between ledger accounts and to effect a withdrawal from trust.

Our own personnel access trust information only where it is necessary to operate and support the service, on a least-privilege basis, and never for any other purpose.

A client of a law practice has no access of any kind to a trust record through our platform. There is no client-facing view of a trust ledger, no client login into the trust module, and no function through which a client can query one. Every trust function in our system is available only to the practice. A client receives trust information only as the documents described next, sent to them by their practice.

What a Client Receives

A person whose money a practice holds receives three kinds of document from that practice through our platform: a trust receipt when money is received (UGR r 36), a bill or invoice, and a trust account statement (UGR r 52).

The statement is deliberately narrow. It carries exactly six columns — Date, Particulars, Reference, Received, Paid and Balance. That is what moved, when, why and what remained. It does not carry our internal sequence numbers, our internal identifiers, or the bank-transaction references we use to reconcile the practice's account, because none of those is information about the client and none of them belongs on a document sent outside the practice.

A trust receipt shows the practice's own trust account details. Whether the practice's own account number is printed in full or masked on that receipt is the practice's choice; the default is masked.

Trust Documents, Storage and Delivery

Every trust document is produced in two forms only: a canonical machine-readable record, and a PDF/A file. Spreadsheet, word-processing and rich-text formats are refused by construction, because a format that anyone can silently edit is not an appropriate form in which to keep a statutory record.

Documents are stored in Australia, in a private store, under a path scoped to the individual practice and its trust account. The store blocks all public access, keeps previous versions, and encrypts objects at rest using our cloud provider's server-side encryption. Nothing in it is reachable by an anonymous request.

When a document is opened or downloaded, we issue a link that stops working after five minutes. The link is not a permanent address for the document, cannot be shared usefully once it has expired, and is generated fresh each time.

Where a receipt, invoice or statement is emailed, our trust module does not copy the document into the message it hands to our email service — it passes a reference to the stored document instead, so the file is not duplicated through our internal systems. Only two trust events also generate an internal email to the practice: a deficiency in trust money, and an approaching reconciliation deadline. Both have a statutory consequence, and an in-app notice a principal never opens is not sufficient notice of either.

Records That Cannot Be Amended or Deleted

Trust records are append-only. There is no function anywhere in our system that edits or removes a posted trust entry. A correction is made by posting a further entry that explains it, not by altering the original.

The same applies to cancellation. A cancelled receipt, a voided invoice and a cancelled controlled-money receipt are all retained and still appear in the book, keeping their number and marked as cancelled (UGR r 36(6)). A removed row is indistinguishable from a record that never existed, and an unexplained gap in a numbered series is precisely the problem consecutive numbering exists to prevent.

At the end of each month a closed period is sealed: the statutory copies are rendered, each is hashed, and the manifest is linked to the previous month's, so that a later alteration to any of them is detectable. Once a period is closed it cannot be reopened.

Trust records are kept for seven years from the later of the last transaction entry in the record and the finalisation of the matter it relates to (LPUL s 147(2)(d), (5)). Both dates are stored, because either can move and neither alone gives the answer; the retention date only ever moves forward. Nothing in our system deletes a trust record on a timer. When a retention period expires, the record becomes eligible for the practice to review, not for automatic destruction, and a ledger account that still holds a balance or whose matter has not been finalised cannot be destroyed at all.

The consequence is that we cannot honour a request to delete personal information from a trust record, and we will not pretend otherwise. Australian Privacy Principle 11.2 requires us to destroy or de-identify personal information once we no longer need it, but it does not apply where we are required by or under an Australian law, or by a court or tribunal order, to retain that information. Trust records are required to be retained. A request to erase a name, an address or a bank account number from a trust ledger, a cash book or a sealed statutory copy is a request we are not permitted to grant, and granting it would itself be the breach. Where a practice has been told to preserve records — a costs assessment, an investigation, a subpoena — any disposal is suspended for exactly that data until the obligation ends.

What we can do instead:

• correct inaccurate information. A change to a client's name, a client's address, a matter reference, a matter description or a ledger account number is made through the record UGR r 39 requires for that purpose, which preserves the old value, the new value, who made the change and when. A correction adds to the record; it does not overwrite it;
• delete the bank feed. Transaction data imported from a practice's bank is held in a separate layer that is separately deletable, and deleting it destroys no statutory record, because every particular the books require is copied into the trust record when the entry is posted. See “Retention and Deletion of CDR Data” below; and
• destroy the record when the period ends. Once the seven years have run, the matter has been finalised and the balance is nil, the practice may direct that the record be destroyed.

Our Record of Who Did What, and Its Limits

Every change to a trust record is logged: who made it, for which practice, when, what the record said before and after, and the reason given. Changes to the five items UGR r 39 names — client name, client address, matter reference, matter description and ledger account number — are additionally recorded in their own chronological log that can be produced on its own.

Two limits are worth stating plainly.

• We do not attach an IP address, browser identifier or location to a trust audit entry. The entry records the account that acted and what it did. We consider that sufficient for a financial record and we have not collected more.
• We do not log read access to a trust record. The trust audit trail records changes and the delivery of documents. Someone at a practice opening a client's ledger and reading it leaves no entry in it. If you need to know who has looked at a record, our trust audit trail cannot tell you.

What We Do Not Do With Trust Information

• We do not send trust information to any artificial-intelligence or machine-learning system, ours or anyone else's, for any purpose, including training, evaluation or summarisation. No feature of our platform passes a trust record to a language model.
• We do not use trust information for direct marketing, and we do not market to a practice's clients.
• We do not sell, rent, licence or trade trust information.
• Our payment processor does not receive trust information. Paying a bill through our platform runs through a separate payment path (see section 16); no card processor is given a ledger, a book entry or a bank transaction.
• We do not scan, read or extract text from images or scans of bank statements, and we do not ask for them. Bank data reaches us as structured records from the practice's own bank.
• We do not disclose trust information outside Australia.

Trust Enquiries and Complaints

If you are a client of a law practice and your question is about an amount, a receipt, a statement or what a record says, raise it with the practice first. The practice keeps the books and only the practice can authorise a change to them. If your question is about how we, as the practice's software provider, store, secure, retain or disclose that information, contact our Privacy Officer. You may also complain to the Office of the Australian Information Commissioner at oaic.gov.au.

A complaint about how a law practice has handled trust money is a different matter and goes to a different place: the legal services regulator in the practice's jurisdiction — the Legal Services Commissioner or the Law Society, depending on the State or Territory. A practice's trust records are also subject to examination by an external examiner and to inspection by that regulator; see section 6.

12 Consumer Data Right (CDR) Data

Where a law firm using our platform connects a bank or trust account so that its transactions can be imported for bookkeeping, ledger and reconciliation, we handle that transaction data under Australia's Consumer Data Right (CDR). We access CDR data through Skript — an accredited data recipient under the CDR — acting as its CDR representative under a written arrangement. For CDR data, the CDR Privacy Safeguards under Part IVD of the Competition and Consumer Act 2010 (Cth) apply, and where they do they take precedence over the Australian Privacy Principles. This section supplements the rest of this Privacy Policy and governs CDR data specifically.

Consent

We collect and use CDR data only with the consumer's consent, which is voluntary, express, informed, specific as to purpose, time-limited and easily withdrawn. Consent is never bundled or pre-selected, and is never a condition of supply. A consent period cannot exceed the maximum the CDR Rules allow, and its duration is shown to the consumer before the consent is given. A consumer may withdraw consent at any time — immediately through the consumer dashboard, or by contacting us, in which case we give effect to the withdrawal as soon as practicable and within 2 business days.

How We Use CDR Data

We use CDR data solely to provide the service the consumer has requested — importing and reconciling the firm's bank or trust-account transactions into per-matter ledgers and invoices. We do not use CDR data for credit assessment, profiling, scoring, direct marketing or on-selling, and we do not pass CDR data to any artificial-intelligence or machine-learning system. We collect only the accounts, fields and date range reasonably needed for these features, and never more transaction history than required (data minimisation).

When a firm authorises a connection, we ask the firm's bank for up to 24 months of transaction history. That window is chosen because a trust reconciliation and an external examination look back across completed financial years, and re-authorising a connection every quarter in order to reach last year's transactions would be worse for the consumer, not better. A firm can ask for a shorter window; we do not ask for a longer one.

The only personal information we send to our accredited data recipient in order to establish a connection is the firm's own contact details — its practice name, contact email address, contact mobile number and ABN — which the recipient requires in order to operate the consumer dashboard through which consent is reviewed and withdrawn. We do not send any of the firm's clients' personal information to the accredited data recipient at any point.

The CDR Privacy Safeguards

We comply with the 13 CDR Privacy Safeguards as if we were the accredited principal. In summary:

• PS1 — Open and transparent management: we publish and maintain this CDR policy and a process for CDR enquiries and complaints.
• PS2 — Anonymity and pseudonymity: we do not require identification beyond what is reasonably necessary to provide the service and satisfy CDR consent.
• PS3 — Collecting CDR data: we collect only through the accredited channel described above, under a valid consent, and only what is reasonably needed.
• PS4 — Unsolicited CDR data: CDR data we did not seek and could not have collected is destroyed or de-identified as soon as practicable.
• PS5 — Notifying collection: the consumer can view the data collected, its uses and dates via the consumer dashboard.
• PS6 — Use or disclosure: we use CDR data only for the consented purpose and do not disclose it outside the permitted CDR framework.
• PS7 — Direct marketing: we do not use or disclose CDR data for direct marketing.
• PS8 — Overseas disclosure: we do not disclose CDR data overseas; it stays in Australia.
• PS9 — Government identifiers: we do not adopt a government related identifier as our own identifier of a consumer.
• PS10 — Notifying disclosure: CDR data is disclosed only to our cloud host for hosting under the CDR rules, and any disclosure is reflected on the dashboard as required.
• PS11 — Quality: we use CDR data as received from the data holder and do not alter source transaction records.
• PS12 — Security and destruction of redundant data: CDR data is protected by the controls described under “Information Security” below, and redundant CDR data is deleted or de-identified.
• PS13 — Correction: a consumer may ask us to correct CDR data, and we action or appropriately refer such requests.

Your CDR Rights

• view, through the consumer dashboard, each consent's data scope, uses and dates;
• withdraw consent at any time (immediately via the dashboard);
• elect at any time that your CDR data be deleted once it is redundant — this election overrides de-identification and survives withdrawal or expiry of consent;
• request correction of your CDR data; and
• ask us questions or make a complaint about how your CDR data is handled.

Where CDR Data Is Stored

All CDR data is stored and processed exclusively within Australia, on Amazon Web Services in the Asia Pacific (Sydney) region. CDR data is not disclosed to, stored in, or processed in any location outside Australia.

Retention and Deletion of CDR Data

We keep CDR data only for as long as it is needed to provide the service. When CDR data becomes redundant — for example on consent expiry or withdrawal, on your election to delete it, on a direction from our accredited data recipient, as our CDR principal, to delete or de-identify it, on account disconnection, or on account closure — our disposal process deletes or de-identifies it to the extent reasonably practicable. That process is deliberately explicit rather than a silent expiry timer: it is bounded, it writes a record of what it is about to dispose of and under what authority before it acts, and it refuses to remove a transaction whose corresponding entry has not yet reached the books. A privacy obligation that cannot be evidenced has not been discharged. Where specific records must be retained under Australian law, only those records are retained under the CDR retention exception, archived with restricted access. These CDR deletion obligations arise under CDR Rules 7.12, 7.13 and 1.10AA(4)(e) and Privacy Safeguard 12.

Bank-feed data is held in stores that are entirely separate from the statutory trust records described in section 11, and deleting it destroys no trust record: every particular the statutory books require is copied into the trust record at the moment an entry is posted. It also means the reverse — that the seven-year retention on a trust record does not keep a consumer's bank feed alive.

CDR Enquiries and Complaints

Questions or complaints about our handling of CDR data can be directed to our Privacy Officer (contact details below). You may also escalate to the Office of the Australian Information Commissioner (OAIC) at oaic.gov.au, or contact Skript as the accredited data recipient.

13 Automated Decision-Making

This section sets out, ahead of time, the disclosures about automated decisions that the Privacy and Other Legislation Amendment Act 2024 (Cth) will require of privacy policies when its transparency requirements commence on 10 December 2026.

• Kinds of personal information our automated systems use: account and usage data; the IP address and derived browser fingerprint described under automatic information; matter metadata; and message and form content where AI features are used.
• Decisions made solely by automated means: none that produce legal or similarly significant effects, with one exception — automated security measures. Rate limiting and temporary access blocking operate on request patterns without a human in the loop, because they have to act in seconds. A block can be reviewed by contacting support.
• Automated functions substantially and directly related to decisions a human makes: AI-assisted suggestions, document classification and document summaries, all of which a qualified practitioner reviews before reliance; and account-abuse flags, which our staff review before any action beyond the automated measures above is taken.

14 Information Security

Lex Stratus Software Pty Ltd protects personal information with technical and organisational measures proportionate to its sensitivity. The measures below are the ones we actually run. We hold no security certification — no ISO 27001, no SOC 2 — and this policy claims none; what follows is what we do, not a badge.

• Encryption — data is encrypted in transit using TLS and encrypted at rest on our AWS data stores. OAuth tokens for connected Google and Microsoft accounts are encrypted with AWS Key Management Service.
• Authentication — TOTP two-factor authentication is available on all accounts and required for practitioner accounts.
• Access control — role-based access on a least-privilege, need-to-know basis; application requests are authenticated and authorised server-side against the record owner; and each practice's data is logically separated from every other practice's.
• Audit logging — administrative actions are logged, and changes to financial and ledger records are captured in an append-only audit trail that records who changed what, when and why. That trail records changes; it does not record who has read a record.
• Security monitoring — the request fingerprinting, rate limiting and 180-day access-security logs described under automatic information.
• Backup and recovery — our databases have continuous point-in-time restore enabled, allowing recovery to any second within a rolling 35-day window. All restore data remains within Australia, under the same access controls and encryption as the live store.
• Hosting — our server-side systems and data stores run on Amazon Web Services in the Asia Pacific (Sydney) region. Personal information is stored in Australia; the specific overseas processing this policy discloses is listed under overseas disclosure.
• Subsystem separation — our payment processor and our AI features are architecturally separate from the trust and CDR subsystems and receive neither CDR data nor any trust record.
• Separation of deletable and non-deletable records — bank-feed data, which a consumer may have asked us to delete, and statutory trust records, which we are required to retain, are held in physically separate stores with separate permissions. Exactly one scheduled process in the entire system holds any deletion permission, it holds it on the bank-feed stores only, and it has no read or write access to any trust record. Honouring a deletion request therefore cannot damage a statutory record, and a fault in the deletion process cannot reach one.
• Data-breach response — described under data breaches below.

No system is absolutely secure, and we do not promise that ours is. What we promise is the measures above, honestly described, and candid notification if they fail in a way that affects you.

15 Data Retention and Deletion

We keep data only for as long as it is needed for the purpose for which it was collected, and we take reasonable steps to destroy or de-identify it once it is no longer needed and we are not required to keep it. We apply data minimisation at collection. Some records — trust-accounting records, e-signature audit trails, chat records, support tickets, invoices and financial records among them — are required by law to be kept, or are kept long-term as legal records, and cannot be deleted on request; the strictest case is set out under “Trust Records: A Statutory Retention Exception” below. This section applies to CDR data, to trust records and to other personal information, and is read together with the Trust Accounting, Consumer Data Right and Information Security sections above.

How Long We Keep Data

• Application and system logs are kept for 180 days.
• Access-security logs — the IP address and hashed browser fingerprint records described under automatic information — are kept for 180 days.
• Error diagnostics, which can include captured request data, are kept for up to 180 days; reports derived from them are kept for up to about 400 days.
• Financial and payment records are kept for seven years, consistent with section 286 of the Corporations Act 2001 (Cth).
• Matter and practice records are retained in accordance with the instructing law practice's instructions and its statutory duties — commonly seven years, under rule 14.2 of the Australian Solicitors' Conduct Rules, section 56(5) of the Migration Agents Code of Conduct 2022 and, for trust records, section 147 of the Legal Profession Uniform Law.
• Long-term legal records — e-signature audit trails, chat records (including recalled messages), support tickets, invoices and trust and audit records — are retained long-term as legal records and are not deleted on request.
• CDR transaction data is kept only while the relevant consent is active and the data is needed to provide the service; data derived from it (such as ledger entries, balances and invoices) is kept while it is needed to provide the service.
• Trust-accounting records are kept for seven years from the later of the last transaction entry in the record and the finalisation of the matter, as the legal profession legislation requires. They are not deleted automatically at the end of that period; they become eligible for the law practice to review and direct.
• Account and personal information is kept while your account is active. There is no self-service deletion or export: requests are made in writing to the Privacy Officer, and we take reasonable steps to destroy or de-identify the information once it is no longer required and is not subject to a retention obligation.

Trust Records: A Statutory Retention Exception

Where a law practice uses our trust-accounting module, the records of that trust account are subject to a statutory retention obligation and to a statutory prohibition on alteration. Australian Privacy Principle 11.2 requires us to destroy or de-identify personal information once we no longer need it, but it does not apply where we are required by or under an Australian law, or by a court or tribunal order, to retain that information. Trust records fall squarely inside that exception.

In practical terms: a request to delete personal information from a trust ledger, a statutory book or a sealed monthly copy cannot be granted. Those records are append-only — there is no function in our system that edits or removes a posted entry — and they must be kept for seven years from the later of the last entry and the finalisation of the matter. A cancelled receipt or a voided invoice is retained and still appears in the book, marked as cancelled, because a removed record is indistinguishable from one that never existed.

What we can do instead is correct inaccurate information through the change record the rules require for that purpose, which preserves the old value alongside the new one; delete the separately-held bank-feed data, which destroys no statutory record; and destroy the trust record itself once the retention period has run, the matter has been finalised and the balance is nil. This is set out in full in the trust-records section above.

When We Delete Data

Data is treated as no longer needed — and enters our deletion or de-identification process — when a consent expires or is withdrawn, when a connected account is disconnected or an account is closed, when you request deletion, when the law practice that gave a CDR consent elects that redundant CDR data be deleted, when our accredited data recipient, as our CDR principal, directs us to delete or de-identify CDR data, or when the data is otherwise no longer needed for a permitted purpose. In each case, deletion applies to everything except data we are required by or under an Australian law, or by a court or tribunal order, to retain, and data subject to a preservation direction — which is isolated, restricted, and destroyed when the obligation ends.

CDR-Specific Deletion Obligations

As a CDR representative, we delete or de-identify CDR data in each of these cases: on withdrawal or expiry of the consent the law practice gave; where the practice elects that its CDR data be deleted once it is redundant (an election that overrides de-identification and continues to apply after the consent is withdrawn or expires); and where our accredited data recipient, as our CDR principal, directs us to do so. These obligations arise under CDR Rules 7.12, 7.13 and 1.10AA(4)(e) and Privacy Safeguard 12.

How We Delete Data and Verify Deletion

• Deletion is our default for CDR transaction data. Redundant CDR data is deleted or de-identified to the extent reasonably practicable, consistent with the CDR Rules.
• Where the law practice that gave a CDR consent has elected that its CDR data be deleted once it is redundant, that election overrides de-identification and continues to apply even after the consent is withdrawn or expires.
• Our file storage keeps previous versions of objects and our databases keep rolling backups, so a deleted file can remain internally recoverable for a period after deletion. Where data cannot be irretrievably destroyed immediately, it is isolated and not used or disclosed, and is destroyed as backups and version history cycle. For that reason we promise reasonable steps to destroy or de-identify — never instant or irreversible destruction.
• Each deletion or de-identification is recorded so that we keep an auditable record that it was carried out, and where a service provider holds copies we direct it to delete them.

Records We Must Keep by Law

Where we are required to keep specific records under Australian law, or the data relates to current or anticipated legal proceedings, we suppress automatic deletion for exactly that data, archive it with restricted access, and delete it once the obligation ends.

16 Credit Card Details

Lex Stratus Software Pty Ltd does not store credit-card numbers in its systems. Your credit-card details will be passed to the payment gateway as soon as they have been collected.

Two kinds of payment run through Stripe, our payment provider. For platform subscription fees, which are charged to law practices, Lex Stratus Software Pty Ltd is the merchant and Stripe processes the card; we never store card numbers.

Where you pay a law firm's invoice through the System, your card details are collected and processed by our third-party payment provider, Stripe, and settle into the law firm's own connected payment account. Lex Stratus Software Pty Ltd acts only as a technical provider: it does not hold or receive the funds, is not a party to the payment, and the law firm is the merchant of record. Any payment you make is also subject to Stripe's privacy policy and terms.

17 Direct Marketing

We distinguish between two kinds of message, and the distinction decides what you can opt out of.

• Service and transactional messages — security notices, receipts, appointment and matter notifications, and messages about your account or changes to our terms. These are part of operating the service and cannot be opted out of while an account is active.
• Marketing messages — currently limited to practitioner-facing material such as our immigration digest email. Marketing is strictly opt-in, confirmed by double opt-in, and every message carries a working one-click unsubscribe, which we honour within 5 business days, consistent with the Spam Act 2003 (Cth).

We do not market to visa applicants. We do not use Applicant information for our own marketing, and we do not send marketing to Applicants — at all, not merely on an opt-out basis.

You may ask us where we obtained your details, and we will tell you. Requests go to the Privacy Officer.

18 Data Breaches

We maintain a data-breach response plan. When we suspect a data breach that may be an eligible data breach, we assess it promptly and in any case within 30 days. Where the Notifiable Data Breaches scheme under the Privacy Act 1988 (Cth) requires it, we notify the Office of the Australian Information Commissioner and the affected individuals as soon as practicable, and our notice says what happened, what information was involved and what we recommend you do.

Where a breach affects information we hold for a law practice — matter data, trust records or client files — we notify that practice without undue delay and cooperate with it so that it can meet its own obligations and inform its clients.

19 External Links

Lex Stratus Software Pty Ltd's website may contain links to other websites. When you access these links we recommend that you read the website owner's privacy statement before disclosing your personal information. Another website's handling of your personal information is governed by that website's own privacy policy, not by this one, and Lex Stratus Software Pty Ltd does not accept responsibility, to the extent permitted by law, for personal information collected outside our website. Nothing in this policy excludes any guarantee or right you have under the Australian Consumer Law.

20 Access to Personal Information

You may request access to the personal information we hold about you. There is no self-service export: requests are made in writing to our Privacy Officer, we take reasonable steps to verify your identity before releasing anything, and we respond within 30 days. Personal information is released directly to you unless you give us a written, signed authority to provide it to a third party.

Where the information you ask about is matter data — information held in a law practice's matter about its client — we route the request through the instructing practice, which holds the client relationship and any legal professional privilege in the material, and we assist the practice to respond. That is not a refusal; it is the practice's file, and privilege in it is the client's to claim and the practice's to assert.

If we refuse access, in whole or in part, we will give you written reasons and the complaint options described under “How a Privacy Complaint Is Handled” below.

21 Updating Your Personal Information

You may ask Lex Stratus Software Pty Ltd to update, correct or delete the personal information we hold about you at any time by writing to the Privacy Officer as specified below. There is no self-service deletion; every request is handled by a person. We take reasonable steps to verify your identity first, and we respond within 30 days. Requests about matter data are routed through the instructing practice, as described under access to personal information above.

Lex Stratus Software Pty Ltd also has obligations to take reasonable steps to correct personal information we hold when satisfied that it is inaccurate, out-of-date, incomplete, irrelevant or misleading for the purpose for which it is held.

Some information cannot be deleted on request because we are required by law to retain it, or because it is kept long-term as a legal record — trust-accounting records, e-signature audit trails, chat records, support tickets and invoices among them. Where that applies we will tell you, tell you why, and tell you when the obligation ends. If we refuse a request we give written reasons and the complaint options described below. See “Trust Records: A Statutory Retention Exception” above.

22 Anonymity and Pseudonymity

Australian Privacy Principle 2 gives you the option of dealing with us anonymously or under a pseudonym where that is lawful and practicable. On this platform it is not practicable, and we would rather say so than pretend otherwise. A visa application is made in a real identity — the identity is the subject matter of the application — and an account is bound to a verified email address and to the security measures described in this policy, which exist to keep other people out of your information. You can read our public pages and make a general enquiry without identifying yourself beyond a reply address, but you cannot hold an account or participate in a matter anonymously or pseudonymously.

23 Children

Accounts on this platform are for adults: you must be at least 18 years old to hold one. Visa applications, however, often contain information about children — as applicants, dependants or family members — and that information is entered by the law practice or by a parent or guardian, not by the child. We handle information about children with the same protections as all other matter information and, as with all Applicant information, we never use it for marketing.

24 Visitors from the EU and UK

Most people this policy applies to are in Australia, but a visa applicant often is not. If you are in the European Union or the United Kingdom, the GDPR or UK GDPR may give you additional rights over your personal data: access, rectification, erasure (subject to the legal holds and statutory retention described in this policy), restriction of processing, data portability and objection. Where those laws apply, we rely on performance of a contract, our legitimate interests and consent as our legal bases, and transfers of your data to Australia are protected by contractual safeguards. You may exercise these rights through the Privacy Officer, and you may complain to your local supervisory authority as well as to the OAIC.

25 Contacting Lex Stratus Software Pty Ltd Regarding Privacy

If you would like to make further enquiries, complain about a breach of the Australian Privacy Principles, or complain about a registered Australian Privacy Principles code (if any) that may relate to Lex Stratus Software Pty Ltd's business, please contact our Privacy Officer at:

Or email privacy@lexstratus.com.au.

How a Privacy Complaint Is Handled

Complain to our Privacy Officer first. We acknowledge a privacy complaint within 7 days and respond substantively within 30 days. If you are not satisfied with our response, or we fail to give one, you may complain to the Office of the Australian Information Commissioner:

• Phone: 1300 363 992
• Email: enquiries@oaic.gov.au
• Post: GPO Box 5288, Sydney NSW 2001
• Web: www.oaic.gov.au

26 Policy Changes

Lex Stratus Software Pty Ltd may revise this Privacy Policy from time to time by updating this page. Where a revision corrects, clarifies or discloses more about what we already do, it takes effect when it is posted. Where a revision broadens how we use or disclose personal information, we will post it at least 14 days before it takes effect and will show both the posting date and the effective date at the top of this page. We suggest you review this Privacy Policy regularly.

What Changed in This Revision

Version 4.0, 17 August 2026. This revision discloses more about what we already do and corrects two overstatements; it does not broaden any use or disclosure, and so takes effect on posting. In summary:

• new sections on artificial intelligence and automated decision-making, ahead of the transparency requirements commencing 10 December 2026;
• an overseas disclosure table naming each overseas provider and its location. The previous statement that we operate no offshore infrastructure was true of hosting but overstated the position on processing, and has been corrected;
• “Automatic Information” now discloses the IP address and hashed browser fingerprint derived on every signed-in request, the security uses they serve and the 180-day retention of access-security logs;
• e-signature audit pages and chat message recall are now disclosed under disclosure;
• new sections on direct marketing, data breaches, anonymity, children and EU and UK visitors;
• “Data Retention and Deletion” now states the retention periods we actually run — 180-day logs, seven-year financial records, practice-directed matter retention — and the legal records that are kept long-term;
• cookie disclosures have moved to a dedicated Cookie Policy; and
• our contact details are unchanged.

Version 3.0, 5 August 2026. This revision adds disclosures about our trust-accounting module and corrects several statements that were incomplete or inaccurate. It describes what we already do; it does not broaden any use or disclosure, and so takes effect on posting. In summary:

• a new section on trust accounting and client money, describing what we hold on a law practice's behalf when it uses the trust module, whose information it is, who can see it, how long it is kept, and why trust records cannot be deleted on request;
• “Personal Information” now lists the categories of information we actually collect, including trust-accounting and bank-transaction data and the bank details of people who pay money to, or are paid money by, a law practice. The previous description was materially incomplete;
• “Disclosure of Personal Information” now discloses that a law practice's trust records are subject to examination by an external examiner and to inspection by the legal services regulator;
• “Data Retention and Deletion” now states the seven-year statutory retention that applies to trust records and the limits it places on a deletion request. The previous statement that account and personal information is deleted on request was wrong as applied to trust records;
• “Information Security” now describes our encryption at rest accurately — our cloud provider's server-side encryption using keys that provider manages, rather than a customer-managed key service — states that our audit trail records changes rather than reads, and describes the separation between deletable bank-feed data and non-deletable statutory records; and
• the “Consumer Data Right” section now names Skript as our accredited data recipient, correcting an earlier reference; states the 24-month transaction-history window we request and why; and discloses that the only personal information we send to that recipient is the law practice's own contact details.

Version 2.0, 14 July 2026. Added sections on the Google and Microsoft integrations, the Forms Manager browser extension, Consumer Data Right data, information security, and data retention and deletion.