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 Stripe rather than stored by us (see section 05);
• 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. Where a provider is outside Australia, section 09 applies.

Supabase

Our database, authentication and file storage. Holds effectively everything described in sections 02 and 03, including uploaded documents.

Vercel

Hosts and serves the application. Receives request data and technical information.

Stripe

Payment processing for agent subscriptions. Receives the account email address, our internal customer identifier and the information needed to take payment. Card numbers go to Stripe directly and are never held by us.

Didit

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

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.

OpenAI

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. Property data licensed from Cotality is deliberately excluded and is never sent.

Google (Gemini)

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.

OpenStreetMap Foundation

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

Daily

Video calls and live transcription. Receives the audio and video of a call while it is happening, and produces the transcript. Daily uses Deepgram to convert speech to text, so the audio of a transcribed call reaches Deepgram as well. The same pair also receives an agent's voice when they dictate a note into the software outside any call. Turning on background blur, or choosing one of our background images, involves one more company: Banuba, whose video engine Daily uses. The engine runs inside your own browser, and the call's video does not go to Banuba - its licensing service (pluot.blue) 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.

Documenso, hosted on Railway

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 Railway.

Resend

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.

Typesense

Powers directory search. Holds the public directory content that is already published.

Sentry

Error monitoring. Receives diagnostic information when something goes wrong. Personal information is stripped and page text is masked before an event is sent.

Cloudflare

Turnstile, which distinguishes people from bots on our public forms.

Sanity

Content management for 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.

Upstash

Rate limiting and caching. 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.

Storylane

The interactive product 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, Vercel Speed Insights, Ahrefs Analytics and the Meta pixel receive technical and usage information about the pages you visit. Section 11 explains where they run and how to refuse them.

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 OpenAI to do so. Google's Gemini service is used for the single narrow purpose described in section 05.

We do not have a contractual zero-retention or no-training arrangement with these providers. Under OpenAI's current API terms, content sent through the API is not used to train their models and is retained for a limited period for abuse monitoring, but that is their 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 Didit.

Depending on the check the agent runs, Didit 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. Didit holds the underlying documents and images under its own terms, which you can read directly: its privacy policy, its verification privacy notice (written for the person being verified) and its service level agreement.

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 named in section 05. Supabase holds it, because Supabase is our database. 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 OpenAI 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 OpenAI 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 OpenAI in one situation, and it 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.

Stored mail is not put into any search index we build for the assistant, and it is not sent anywhere in bulk. Nothing reaches OpenAI 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 Vercel, Stripe, OpenAI, Google, Daily, Deepgram, Resend, Sentry, Cloudflare, Microsoft and Sanity, and in the European Union by Didit. 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. Two we can be specific about: our electronic-signature service is software we run ourselves on hosting provided by Railway, and the fallback address lookup is operated by the OpenStreetMap Foundation. 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 every page of this site, including the signed-in dashboard - so opening a page inside the product is measured the same way as opening a public page. You can block them in your browser or with a content blocker; doing so does not affect your ability to use the platform.

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.