Privacy policy

We operate a public directory of Australian buyer's agents and the customer relationship software those agents use to run their practices. In this policy, we, us and our mean Buyers Agents Technologies Pty Ltd.

Two different kinds of people appear in this document and the difference matters throughout.

• Agents are our customers. They hold an account, may pay us a subscription, and use the platform to run their business.
• Clients are the buyers those agents act for. In most cases you have a relationship with your agent rather than with us, and your agent decides what to record about you. We hold that information on their behalf.

From agents and other people who create an account with us, we collect:

• name, email address, phone number and business address;
• login credentials, and authentication records such as sign-in times;
• professional profile information: licence details, service areas, fees, biography, profile photograph, portfolio and awards;
• subscription and billing information, which is processed by our payment processor rather than stored by us (see section 05);
• whether and when you open an email we send you, and which link in it you open;
• reviews, ratings and other content submitted to the directory; and
• technical information such as IP address, device and browser type, and pages viewed.

From clients and prospective clients who submit an enquiry, a buyer brief or an online form, we collect the contact details and property requirements you provide.

This section is about people who are not registered users of the platform. If you are the client of a buyer's agent who uses our software, we hold information about you even though you never created an account with us. Your agent collects it from the client directly in the course of acting for you, and records it here. We hold it on their behalf.

Depending on what your agent chooses to use, this may include:

• Contact and identity details: names, email addresses, phone numbers, postal addresses, and for a company or trust client, an ABN and the details of the people behind it.
• Financial position: the budget range you are searching in, your pre-approval status and the pre-approval amount, and your deposit and finance arrangements.
• Your circumstances and plans: whether you are a first home buyer, your purchase timeline, the areas and property types you are looking at, and your reasons for buying.
• Correspondence and appointments: emails your agent sends and receives about you through a mailbox they have connected, meetings, inspections and file notes.
• Calls: where your agent turns on transcription for a video call, a written transcript - a verbatim record of what was said. The platform does not record video or audio of a call; only the transcript is kept. Transcription will not start until your agent confirms that both of you have consented, and the platform stores that confirmation. It is your agent's confirmation rather than a consent you give to us directly, so it is your agent who must ask you.
• Documents and signatures: files you upload or are asked to sign, including any agreement signed electronically and the signature applied to it.
• Identity verification: the outcome of any check your agent is required to run under anti-money-laundering law, and the evidence that it was done. Section 07 covers this in full.

We do not decide what your agent records, and we do not market our own services to that client on the strength of it. Your relationship is with your agent.

If you are a client of an agent and you want to see or correct what is held about you, ask your agent first - they hold the record and can usually answer straight away.

Deletion works differently, and we would rather be plain about it. Your agent's software offers no control that erases a client's record. What it offers is archiving, which moves you out of their active lists and keeps everything already recorded about you. A record is only removed outright as a side effect of your agent undoing a bulk import, undoing something the built-in assistant did, or merging two duplicate entries. Individual notes and tasks are the exception - those your agent can delete outright. So if you want information erased, ask us as well as your agent. Section 14 explains what happens then, and what the law requires us to keep regardless.

We use personal information to:

• provide, maintain and improve the directory and the software;
• connect people looking for a buyer's agent with agents who serve their area;
• verify that reviews are genuine;
• process subscriptions and payments;
• send transactional messages about your account, and marketing you can opt out of;
• detect and prevent fraud, abuse and security incidents; and
• meet our legal obligations.

Running this platform means sending information to other companies. Each one below receives something, and we have said what. We describe each provider by the job it does for us rather than by name, because the companies we build on are part of how the platform is made. Some are named below, and in each case the name is the part you can act on: an account you connected yourself and can disconnect, a public register you can correct at the source, a data supplier whose own terms are attached to what we show you, or a company your own browser loads directly and you can block. PropDive is named for the opposite reason: it is not another company at all, it is one of our own business names. Section 19 says how to ask for the names of the rest. Where a provider is outside Australia, section 09 applies.

Database and file storage

Our database provider, which also runs sign-in and holds uploaded files. Holds effectively everything described in sections 02 and 03, including uploaded documents.

Hosting

Our hosting provider serves the application. Receives request data and technical information.

Payments

Our payment processor takes payment for agent subscriptions. Receives the account email address, our internal customer identifier and the information needed to take payment, and for a paid plan the names of the campaign and the ad that brought the account (section 11). Card numbers go to the payment processor directly and are never held by us.

Identity verification

Our identity verification provider. Receives identity documents, a photograph of the person being verified and the data needed for sanctions and politically-exposed-person screening. See section 07.

Mobile number verification

A text-message provider receives the mobile number an agent enters when creating an account or joining a team, and sends a one-time code to it. Receives the number and the message carrying the code.

Cotality (formerly CoreLogic)

Property data, valuations, comparable sales and suburb statistics. Receives the property address or locality being researched. Cotality's own terms are set out in our Cotality data terms, and its own privacy policy is at cotality.com/au/legal/privacy-policy.

AI assistant

Our AI provider runs the assistant built into the software, and several other features that read text. Receives what an agent asks the assistant and the CRM records needed to answer; the full transcript of a call, to write the summary and follow-up list; the text of a document an agent uploads as a template; and, when an agent imports a spreadsheet of contacts, a few example values from any column we cannot recognise, which can include real client details such as an address. When a new agent agrees to it while setting up their profile, it also receives the name and agency they typed, to search for their agency's website, and text and photographs from that site's public pages (section 06). Property data licensed from Cotality is deliberately excluded and is never sent.

Photo check

The same AI provider checks that an uploaded profile photograph is a photograph of a person rather than a logo or graphic. Receives the uploaded image.

Google (Maps and Places)

Address lookup and maps. Wherever this platform asks for an address - including an agent's public buyer-brief form, which a member of the public fills in - what has been typed so far is sent from your own browser to Google as you type, so that it can suggest matching addresses. An address saved against a property or a contact is also sent to Google to convert it into map coordinates and to draw a map. Separately, where an agency chooses to show its Google reviews on its page here, we ask Google for that business listing and store what it returns, which includes the rating, the review text and the display name Google publishes beside each review.

Fallback address lookup

A third-party address lookup service, used on the same forms when Google's does not load. Receives the address text that has been typed.

Video calls and transcription

Our video-call provider runs video calls and live transcription. Receives the audio and video of a call while it is happening, and produces the transcript. It uses a separate speech-to-text provider to convert speech to text, so the audio of a transcribed call reaches that provider as well. The same pair also receives an agent's voice when they dictate a note into the software outside any call. Every transcription we start tells the speech-to-text provider not to keep the audio or use it to train its models; under its published terms it then holds the audio only for as long as it takes to convert it. That audio is processed outside Australia, because our video-call provider cannot send it to the speech-to-text provider's Australian service. The video-call provider keeps a copy of each written transcript in its own storage, which is where we collect it from. The audio of an inspection clip an agent records goes to the same speech-to-text provider, is processed in Australia, and that provider does not keep it or use it to train its models. Turning on background blur, or choosing one of our background images, involves one more company: the video-effects provider whose engine our video-call provider uses. The engine runs inside your own browser, and the call's video does not go to that provider - its licensing service receives a licence check and your connection details at the moment the effect is switched on. We block its analytics service. The background images are files on this site: your browser loads them from us, and the engine places them behind you on your own machine. Deep blur uses a still of your own room instead: your browser takes it when a call starts and whenever blur is off, blurs it, and hands it to the same engine. The still never leaves your browser.

Electronic signature

Receives the document to be signed and the name and email address of each signer. We run this software ourselves rather than buying it as a service, so the underlying server is provided by a separate hosting provider.

Email delivery

Our email delivery provider sends and receives email on our behalf, including email agents send to their clients through the platform. Receives the address, subject and content of those messages.

Microsoft

Where an agent connects their own Outlook mailbox, we hold an access token that lets us read and send mail in that mailbox, so correspondence between an agent and their clients is synchronised into the platform. An agent can separately connect an Outlook calendar, which lets us read and write events on it.

Google (Calendar)

Where an agent connects their own Google Calendar, we hold an access token that lets us read the events on it, create and change events on it, read the times it is marked busy, and see the email address of the connected Google Account. Connecting a calendar gives us no access to that person's mail. Section 08 sets out what we receive from a Google Account and what we do with it.

Google (Gmail)

Where an agent separately connects their own Gmail mailbox, we hold an access token that lets us read the mail in it and send mail from it, so correspondence between an agent and their clients is synchronised into the platform and a reply an agent writes here leaves from their own address. We store only the messages that involve one of that agent's own contacts; everything else is discarded without being stored. Section 08 sets out what we receive and what we do with it.

Xero

Where an agent connects their own Xero organisation, we hold an access token, encrypted at rest, that lets us read and create contacts and invoices in it and gives us access to its accounting settings, which we use only to read the chart of accounts and the organisation's short code. When an agent raises an invoice here, we look for the client in that organisation by our own reference, their email address or their name, and if none matches we create a contact from what the agent holds on file: the client's name, email address, phone number, street address and ABN. Each invoice we create carries the client's Xero contact reference, the line description, the amount, the due date, a reference and a link back to the record here, and an agent can ask Xero to email it to the client. Xero sends us the invoice's number, status, total, the amount still owing, whether Xero has emailed it, and its dates, so the record here stays in step. An agent can disconnect Xero at any time from their integration settings.

Directory search

Our search index provider powers directory search. Holds the public directory content that is already published.

Error monitoring

Our error monitoring provider receives diagnostic information when something goes wrong. Personal information is stripped and page text is masked before an event is sent.

Internal notifications

Our team messaging provider receives a short notice when someone creates an account or sends an enquiry to an agent, so our staff can respond. An account notice carries the person's name, email address, phone number, whether they said they are a registered buyer's agent, and our internal account identifier. An enquiry notice carries the enquirer's name, email address and phone number, the name of the agent it was sent to, and the first part of the message.

Business register lookup

When an agent types a business name or an ABN into a contact or licence form here, what they typed is sent to the Australian Business Register, a government service, to find the registered business details. Receives the business name or ABN typed.

Search demand data

A search-volume data provider receives location keywords - a suburb or city name paired with the words "buyers agent" - when our own staff research demand in an area. No personal information is sent.

Bot detection

A bot-detection service distinguishes people from bots on our public forms.

Content management

Our content management provider holds news articles and guides.

PropDive

Property due-diligence reports. PropDive is not a third party: it is a registered business name of Buyers Agents Technologies Pty Ltd, run as a separate service by the same company, and this policy applies to it. Receives the property address being researched.

Rate limiting and caching

Our rate limiting and caching provider receives the IP address or account identifier making a request, so that we can stop the same source flooding a form or a login, and holds short-lived copies of account records.

Product demo

A product demo service runs the interactive demo on our public product pages. Loads its own code in your browser and sets its own storage when you open one of those pages.

YouTube (Google)

Video on the home page and on agent profiles and posts. Nothing is sent until you press play; when you do, the player loads from Google, which receives your IP address and sets its own storage in your browser.

Analytics and advertising

Google Analytics, the Meta pixel and two further analytics services receive technical and usage information about the pages you visit. When you send an enquiry or a message through one of our forms, Google Analytics and the Meta pixel are told that a form was sent and which one, and nothing you typed in it. Section 11 explains where they run and how to refuse them. Google Analytics also sends a copy of each page visit to Google's advertising service (Google signals), which Google can link to a Google account you are signed in to if you have turned on ads personalisation in that account. Two acts are also reported to Meta from our own server, not your browser: booking a walkthrough of BuyersagentsOS with us, and creating an account. For those two we send Meta your email address and phone number as one-way hashes, your IP address and browser type, the two Meta cookies your browser holds (or the copies our own campaign cookie kept, section 11), and an id for the act, so Meta can match it to an ad you saw and count it once. A content blocker does not stop that copy. It is never sent for a booking you make with a buyers agent through their own booking page. Two more acts are reported the same way. The first payment for a Pro Profile or BuyersagentsOS plan, as a purchase, with the plan and the amount before GST. And the start of a Pro Profile free trial you give a card for, as a trial, with the plan and the price before GST it will charge. Renewals are not reported. For each we send your email address and phone number as one-way hashes, the two Meta cookies (or the copies written onto your account when it was created), an id for the payment or the subscription, and your browser type. Because both are confirmed by our payment processor and not by your browser, when you open checkout for one of those plans we save your browser type and the two Meta cookies on your account. We delete them once your first payment has been reported to Meta, replace them if you open checkout again, and never use them once they are 30 days old. If no payment follows, they stay on your account, unused, until you next open checkout.

We also disclose personal information to our professional advisers, and to regulators or law enforcement where the law requires it. We do not sell personal information.

The platform includes an assistant that agents can ask questions about their own records, and it uses a third-party AI provider to do so. The same provider runs the profile photo check described in section 05. Where an agent turns on reply drafts, it also writes a draft reply to a client's email for the agent to check and send themselves; section 08 sets out what that sends.

When a new agent sets up their profile, and only after they agree to it on screen, the same provider uses the name and agency they typed as a web search to find their agency's own site. We then read pages on that site, and send the provider the text of up to five of them and photographs from the pages that name the agent, so that it can suggest profile details: a headline, a short bio, their titles, the suburbs, specialties and languages those pages mention, and a photo. Nothing else about the agent is sent. Each suggestion is shown with the page it came from, nothing goes on the profile until the agent approves it, and we keep the suggestions for seven days so the setup can be picked up again. We never suggest years of experience, licence details or sales results.

We do not have a contractual zero-retention or no-training arrangement with that provider. Under its current API terms, content sent through the API is not used to train its models and is retained for a limited period for abuse monitoring, but that is its standing policy rather than a term we have negotiated.

Because of that, do not type information into the assistant that is not necessary for the task. Property data licensed from Cotality is blocked from reaching any AI provider as a matter of licence, and that restriction is enforced in the software rather than left to judgement.

Output from an AI feature can be wrong. It does not change the underlying source of any information, and anything that matters to a property, financial or legal decision should be verified independently.

Australian anti-money-laundering law requires buyer's agents to verify who their clients are. Where an agent uses the verification built into the platform, that check is performed by our identity verification provider.

Depending on the check the agent runs, that provider may receive:

• images of an identity document, such as a passport or driver licence;
• a photograph or short video of your face, used to confirm a real person is present and that the face matches the document; and
• your name and date of birth, for sanctions and politically-exposed-person screening.

A facial image used for verification of this kind is sensitive information under the Privacy Act. We collect it only with your consent, only for the verification your agent is legally required to perform, and for no other purpose.

The platform stores the outcome of each check and the evidence needed to show the check was done. Our identity verification provider holds the underlying documents and images under its own terms: a privacy policy, a verification privacy notice written for the person being verified, and a service level agreement. We will name the provider and send you those three documents on request to security@buyersagents.com.au.

An agent can connect their own Google Calendar so that the appointments they keep in this platform and the events in that calendar stay in step. They can separately connect their own Gmail mailbox so that email between them and their clients appears on the client's file, and so that a reply they write here leaves from their own address. Nobody is connected by default. These are two separate choices: an agent can make neither, either, or both, and Google asks them to approve each one before anything happens. This section sets out everything we receive from a Google Account, what we do with it, who else sees it, how long we keep it and how to stop it.

We ask for access to Gmail only when an agent connects Gmail. Connecting a calendar gives us no access to mail, and an agent who never connects Gmail has no mailbox permission held for them at all. There is no "Sign in with Google" on this platform.

When an agent connects a calendar, we ask Google for these permissions and no others.

• Calendar events (the permission Google calls calendar.events): to read the events on the calendar they connect, and to create, change and delete events on it.
• Free and busy times (calendar.freebusy): the periods that calendar is marked busy, with no event details attached.
• The email address of the Google Account (openid and email): so the platform can show the agent which account is connected. We store that address and nothing else from the sign-in.

When an agent connects Gmail, we ask Google for these two permissions and no others.

• Read your Gmail (the permission Google calls gmail.readonly): to read the messages in that mailbox, so that email between the agent and one of their own clients can be put on that client's file. We ask for the read-only permission rather than the one that also modifies mail, because we never change, label, archive or delete anything in an agent's mailbox. We also read the address of the connected mailbox through this permission, so the agent can see which account is connected.
• Send mail as you (gmail.send): so that a reply an agent writes in this platform leaves from their own mailbox and lands in their own Sent folder, on the same conversation. This permission can only send. It cannot read, list or delete anything.

Most of the mail in a connected mailbox is never stored. We look at a message only to decide whether it involves one of that agent's own contacts. If it does not, it is discarded and no part of it is written down, including in our logs. That test is the whole purpose of the read permission: a mailbox holds an agent's personal and unrelated business correspondence too, and none of that belongs here.

We do not ask for a person's Google contacts, their Google profile, their photos or their files.

We use those permissions for three purposes.

• Bringing events in. We read the events on the connected calendar and keep a copy of each one in the agent's diary here: its title, its start and finish times, whether it runs all day, its time zone, its location where one is set, and its description, which we store as the appointment's notes. We also keep the identifiers Google gives an event, including the one that links a repeating series, so that we recognise the same event next time rather than duplicating it. We keep a short record of each synchronisation so we can investigate one that goes wrong. We do not receive the guest list of an event in your calendar, and we do not store one. When we ask Google for your events we name the fields we need, and the guest list is not among them, so it is never sent to us.
• Writing events back. When an agent creates, moves or cancels an appointment in the platform, we create, change or delete the matching event on their Google Calendar, carrying its title, notes and location. Almost all of these events are created with no guests on them, so Google sends nobody an invitation. The one exception is our older consultation booking flow: there the person who booked is added to the Google event as a guest by their email address, and Google emails them the invitation, and any later change or cancellation, on the agent's behalf.
• Offering times. We read busy periods so that an agent's booking page does not offer a time they are already committed. This read happens when someone opens that agent's public booking page, so a member of the public looking at it causes us to ask Google which periods are busy. No event titles or details are involved and none are shown to the visitor.

That is the whole of what we do with it. We do not use Google Calendar data to build a profile of anyone, it never appears in the public directory, and it is visible only inside the account of the agent whose calendar it is.

What we do with mail from a connected Gmail mailbox. A message that involves one of the agent's own contacts is stored against that contact's file so the agent can see the conversation in one place, and a reply the agent writes here is sent from their mailbox onto the same conversation. That is all of it. We do not use mail to build a profile of anyone, it never appears in the public directory, and it is visible only inside the account of the agent whose mailbox it is.

Who else receives it. Two of the providers listed in section 05. Our database provider holds it, because that is where everything we store lives. And where an agent asks the assistant built into the software about their own diary, the title, times and notes of the appointments in the answer are sent to our AI provider so that it can write the reply.

Before that text leaves, the platform replaces the parts it holds as separate fields: the client's name where an appointment is linked to a contact, the appointment's location, and any email address or phone number it finds written in the text. A person's name or a street address typed into the event's own title or notes is not detected, and is sent as written. An event called "Coffee with Jane Smith at 12 Smith Street" reaches the AI provider with that name and that address in it. Events brought in from a connected Google Calendar are not linked to a contact, so for those there is no separate client-name field to replace at all. If an agent would rather a detail not reach an AI provider, the place to control that is what they type into the calendar entry.

Mail from a connected Gmail mailbox reaches our AI provider in two situations. The first is the same one: where an agent asks the assistant which clients are still waiting on a reply. The answer carries the client's name, the subject line, a short extract of the last thing that person wrote, how long they have been waiting, and the number of unread messages in that conversation. It is an extract and not the whole message, but it is the client's own words, so it is set out here plainly rather than left to be inferred from the sentence about the diary above.

As with the diary above, the platform replaces the parts it holds as separate fields before that text leaves: the client's name becomes a stable placeholder, so the AI provider receives a label rather than the person, and the real name is put back only when the answer is shown to the agent. Email addresses and phone numbers are replaced even where they appear in ordinary text. A person's name or a street address written inside the subject line, or inside the client's own words, is not detected, and is sent as written.

The second is reply drafts, which are off unless the agent turns them on. When an agent who has turned them on presses Draft a reply on a conversation, the newest email that client sent on it goes to our AI provider so that it can write a draft reply. The earlier messages it quotes are removed first, and if they cannot be separated from what the client wrote, nothing is sent, and nothing is sent unless the email came from the client's own address. The client's name, and any email address or phone number in the text, are replaced in the same way. A name is only replaced as it is stored on the client's record, so a shortened form is sent as written, as is a name of one letter or one that is also a common word, such as May. Any other person's name, or a street address, written in the email is not detected, and is sent as written. The provider is told whether the agent has free time in their calendar, never the times or the events. The draft opens in the agent's own composer, and nothing is sent to anyone until the agent presses Send. We keep a fingerprint of each draft so we can count how many are sent unchanged, sent edited or discarded, and never its text.

Stored mail is not put into any search index we build for the assistant, and it is not sent anywhere in bulk. Nothing reaches the AI provider unless an agent asks a question that needs it, and section 06 explains what we can and cannot promise about that provider's own terms. We disclose Google Calendar and Gmail data to nobody else and we do not sell it.

How we protect it. The access and refresh tokens Google issues, for the calendar and for the mailbox alike, are encrypted before they are stored and are decrypted only in order to make a request to Google. The calendar records and the stored messages sit in our database in the Sydney region under the same access rules as the rest of an agent's data, reachable only through that agent's own signed-in account. Section 12 describes the controls in full.

How long we keep it. An event copied from a connected calendar is kept as an appointment for as long as the agent keeps it, on the same footing as one they typed in themselves. A message stored from a connected mailbox is kept on the client's file on the same footing, for as long as the agent keeps it. Section 10 sets out our retention position and is honest about its limits.

Our use of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. In plain terms: we do not sell Google user data; we do not use it or transfer it for advertising of any kind; we do not use it to assess anyone for credit or to make a lending decision; we do not use it, and we do not pass it to anyone in order for them to use it, to develop, improve or train any general artificial intelligence or machine learning model; and nobody here reads it except where an agent asks us to help with a problem, where we must in order to keep the platform secure or to investigate abuse, or where the law requires it.

How to disconnect. An agent can disconnect Google Calendar at any time from Integrations under Settings in their dashboard, or from the calendar screen. Disconnecting stops the platform receiving further changes and removes the stored Google tokens from our database, so we can no longer reach the calendar. Two things survive it and we would rather say so plainly: events already copied into the diary here remain as ordinary appointments, and events we have already written into the Google Calendar remain in Google. Removing either is a separate step, and section 14 covers a request to us.

Gmail is disconnected separately, from the same Integrations screen, and disconnecting it likewise stops any further sync and removes the stored tokens so we can no longer reach the mailbox. The agent is asked at that moment whether to keep or delete the messages already stored here; nothing in the mailbox at Google is ever changed or deleted either way, because we hold no permission that could do it.

How to withdraw the permission at Google. Disconnecting here removes our copy of the tokens; it does not ask Google to cancel the permission you granted. To do that, whether or not you disconnect here, go to myaccount.google.com/permissions and remove this platform's access. After that, any request we make to Google on your behalf fails.

Our database and file storage are hosted in Australia, in the Sydney region. Most of the providers listed in section 05 are not.

Information is processed in the United States by our hosting, payment, AI, video-call, speech-to-text, email delivery, error monitoring, bot-detection, advertising measurement and content management providers, and by Google and Microsoft, and in the European Union by our identity verification provider. Some providers operate in further countries and may move processing between their regions.

For some of these we do not state a country, and we would rather leave that blank than name one we have not confirmed. Our electronic-signature service is software we run ourselves on a separate hosting provider, and the fallback address lookup is run by an organisation outside our control. Neither country is settled in anything we can point at, so neither is claimed here.

Where information is processed overseas it may be subject to the laws of that country, and the privacy protections there may differ from those in Australia. Overseas processing is an inherent part of how this platform works. If you do not want your information processed outside Australia, do not use the platform.

Property data licensed from Cotality is subject to a 30-day limit under our licence. Most records of it carry an expiry date, set at the moment we save it, and once that date has passed the platform filters the record out rather than showing it. A few kinds - the alerts, the activity feed, and the records of properties matched against a buyer brief - carry only the date they arrived, and we do not currently filter those by age when we read them.

Erasing an expired record from storage is a separate step from stopping its use, and it is not one we can currently promise happens on the thirtieth day. An expired record can remain in our database after the platform has stopped relying on it.

We do not operate a retention schedule for the records an agent keeps about their clients. Account records, CRM records, uploaded documents and call transcripts are kept until someone removes them or until we are asked to remove them. Two narrow housekeeping jobs do delete on a timer: a file that is uploaded but never submitted is discarded after 24 hours, and the bookkeeping records behind a contact import are removed after 30 days.

Removing a record through the interface usually does not erase it. A contact is archived, which keeps everything already recorded about them; a document is marked void and the file itself stays; and there is no control anywhere that removes a call transcript. Some transcripts go when the contact they belong to is removed and others survive it, because a call record can outlive its link to a contact. Notes and tasks are genuinely deleted. Where a record is erased, copies may still exist for a period in backups, in server logs, or in the systems of the providers listed in section 05, each of which applies its own deletion timetable.

There is no self-service account deletion today. Section 14 explains how to ask us, and what happens next.

We use cookies and browser storage to keep you signed in, remember preferences and measure how the site is used. Our Cookies policy describes them by category rather than naming each one individually.

The analytics and advertising services in section 05 set their own cookies, and they load on the public pages of this site. They are not loaded on signed-in pages - the dashboard, the CRM, the admin console and a client's portal - nor on pages reached through a private link, such as a signing, review or invitation link. If you move from a public page into the product without the page reloading, a service already loaded on the public page is still running and may count that move. You can block them in your browser or with a content blocker; doing so does not affect your ability to use the platform. The one thing a blocker does not reach is the server-side copy of four acts described in section 05 (a walkthrough booked with us, an account created, a Pro Profile trial started with a card, a first payment for a plan), which we send to Meta ourselves.

When you open a public page of this site through a link that names a campaign, or one carrying Facebook's click id (Facebook adds it to links opened from its apps, ads included), our server sets one cookie of its own for 30 days. It records the campaign and the ad, the page you landed on, and Meta's click and browser ids. It is read only if you do one of these in that time. If you book a walkthrough with us or create an account, we write the campaign and those Meta ids onto that booking or account, and send the ids with the copy of that act described in section 05. On an account we delete the Meta ids 30 days after the account was created, or sooner, once a first payment for one of the plans in section 05 has been processed. If that account then starts a paid plan, we also write the names of the campaign and the ad onto the plan's record with our payment provider. If you send an enquiry to a buyers agent, book a consultation with one, we write the campaign, the page you landed on and when onto that enquiry. If you ask us to recommend agents or send us a message, we put the campaign and the page you landed on into our team's email about it. The Meta ids are not read for any of these, and nothing from the cookie is sent to Meta. It is never set on signed-in pages or on a buyers agent's own booking page. A content blocker does not stop this cookie; blocking cookies for this site in your browser does.

While we test versions of the top of our Pro Profile page, opening that page also sets one cookie of our own for 30 days. It holds a single letter that says which version you were shown, so you see the same one each time. It is sent with the steps of signing up that we count, and written onto your account if you create one, so we can tell which version led to it. It holds nothing about you.

While we test two versions of the first screen of our sign-up page, opening that page sets a second cookie of the same kind for 30 days, holding one letter for the version you were shown. It is used the same way and holds nothing about you.

Our Data security page describes the specific controls we operate, and our Information security and Security & cybersecurity policies describe how we govern them.

If information we hold is lost or accessed without authorisation, our Data breach response policy sets out what we do and when you would hear from us.

No system is perfectly secure. We cannot guarantee the security of information transmitted to us over the internet.

• We do not sell personal information.
• We do not send Cotality-licensed property data to any AI provider.
• We do not use a client's information for our own marketing. A client's relationship is with their agent.

You may ask for access to the personal information we hold about you, ask us to correct it, or ask us to delete it. Write to support@buyersagents.com.au and we will respond within a reasonable period, and in any case within 30 days.

If you are the client of an agent, ask your agent first - they hold the record. As section 03 explains, they can correct it and archive it but cannot erase it, so send a deletion request to us as well. We will act on a request that reaches us either way.

We may need to keep some information where the law requires it - identity verification records, for example, must be kept for seven years under anti-money-laundering law - and some information cannot be removed from backups immediately. We will tell you if either applies to your request.

If you think we have mishandled your personal information, write to support@buyersagents.com.au with the details. We will acknowledge your complaint and tell you the outcome of our investigation.

If you are not satisfied with our response, you can complain to the Office of the Australian Information Commissioner at oaic.gov.au.

The platform links to websites we do not operate, including agents' own sites and government and property information sources. This policy does not apply to them, and we are not responsible for how they handle your information.

We may disclose personal information where we are required to by law, or where it is reasonably necessary to protect our rights or the safety of others.

If our business is sold or reorganised, personal information may be transferred to the acquiring party as part of that transaction, subject to this policy.

We update this policy when what we do changes. The effective date at the top tells you which version you are reading. Where a change is significant we will tell account holders directly rather than relying on you to re-read this page.

Buyers Agents Technologies Pty Ltd (ABN 95 695 266 150), trading as Buyersagents.com.au, BuyersagentsOS and PropDive.

Privacy enquiries, access requests and complaints: support@buyersagents.com.au.

For more information about the specific providers behind the roles described in section 05, please put a request in with security@buyersagents.com.au.

The Save to BuyersagentsOS extension for Chrome puts two buttons, Add to Folio and View in BuyersagentsOS, on single property listings on realestate.com.au and domain.com.au.

Until you press one of those buttons, or the extension's own button in the Chrome toolbar, it reads no text from the page and sends nothing. It looks at the page's web address, to tell whether it is a listing, and at where the heading and the row of icons under it are drawn, to place its buttons.

When you press, it reads the page's web address, its main heading and its page title, and keeps only a street address from them. It opens BuyersagentsOS in a new tab, with that address and the button you pressed in the tab's web address. Nothing else is sent: no photographs, price, description or agent details. The extension stores nothing in your browser, holds no login, and sends nothing to us or anyone else except by opening that tab.

If you are signed in, the property opens, or the property search with the address filled in. The address is in that page's web address, as it would be after a search you typed. Where your plan includes property data and your RP Data login is connected, the address is sent to Cotality to find the property, the same as an address you type into the property search (section 05). The analytics and advertising services in section 05 are not loaded on those pages (section 11). Nothing is added to your Folio until you press Add to Folio on our page.

If you are not signed in, our site sends you to the free trial sign-up and keeps the address and the button you pressed in a cookie in your browser for up to an hour. Scripts on the page cannot read that cookie, so the analytics and advertising services on the sign-up page do not receive the address. The next time this browser loads the dashboard signed in within that hour, we open the property and delete the cookie. On a shared computer, that is whoever signs in next on this browser.

To stop it, remove the extension from Chrome's extensions page.