Dating apps

Fake profiles and banned users on dating apps: Australia

· 8 min read

Applies to
Dating services signed up to the voluntary Online Safety Code for dating services, and any dating service expected to meet it
In force
Code in force since 1 October 2024, enforced since 1 April 2025
What to do
Tie each ban to a signal about the person, not the account, so a returning user can actually be recognised

Romance scams cost Australians $139.9 million in 2025, the third-largest scam category by loss, according to the National Anti-Scam Centre's Targeting Scams Report, published on 30 March 2026. Two months later, the instrument that switched on Australia's new scam regime for digital platforms mentioned dating apps by name. It did so to leave them out.

The Scams Prevention Framework—Regulated Sectors Designation 2026, dated 22 May 2026, designates digital platforms as a regulated sector of the Scams Prevention Framework, with social media services among them. Section 7(3)(j) then excludes any service with "a significant purpose of enabling end-users to interact with other end-users for the purpose of initiating a romantic relationship". The example underneath leaves no room for doubt: "Dating, matchmaking, matrimonial and companionship websites and applications."

So the obvious place to look for an Australian rule on fake dating profiles is the wrong one. The rule that does exist sits in a voluntary industry code, and it is framed around a different problem: the user who has already been thrown out and comes back.

Where a dating service sits

The document that governs Australian dating services on this question is the Online Safety Code for dating services, dated July 2024. It was written by an industry working group at the government's request. The Department of Infrastructure announced on 3 October 2024 that it had commenced on 1 October, with "enforcement to begin from 1 April 2025".

The code applies only to providers that sign up to it. The eSafety Commissioner lists Match Group (Tinder, Hinge, OKCupid, Plenty of Fish, Match.com), Bumble, Grindr, Spark and the ParshipMeet Group among the signatories, and is explicit about its own position: "eSafety has no role in enforcing the code and has no legislative powers relating to its operation." Enforcement belongs to an independent Code Compliance Committee, whose sanctions run from formal warnings to removal from the code.

The code is also narrower than its reputation. Its central term, online enabled harm, covers sexual misconduct, serious non-sexual harm, and attempts to reach children through another user. Section 2.1(13) then adds that "serious harm excludes purely financial harm". A romance scam that ends in an emptied bank account, with no other harm, is outside the code's definition. It is outside the Scams Prevention Framework too.

The duty is about people who come back

Inside that scope, the code's most specific demand concerns banned users. Section 5.4(1)(d) requires each signatory to have systems that allow it "to identify whether an end-user who has been banned from, or whose account has been terminated by, a dating service, is creating new accounts for that dating service and if so, take reasonable steps to delete or otherwise block that end-user".

Section 5.4(3) widens the net across a corporate group. Where a provider terminates an account for a serious violation, and it or a related body corporate runs other dating services, it "must take the same action against that end-user's accounts and profiles on all other dating services" in the group, "to the extent possible".

The wording repays a close reading. The obligation attaches to the end-user — "a natural person who is registered with a dating service" — and not to the account. A ban that removes an account but cannot recognise the person behind it when they register again falls short of what section 5.4(1)(d) describes. It has only closed a login.

That is where most ban systems are weakest. An email address takes a minute to replace; a phone number, not much longer. A new profile photo costs nothing. Signals tied to the account are exactly the ones a removed user changes first. To recognise a returning person, a service needs a signal tied to the person that survives a fresh sign-up: a verified document, or a face matched against the faces of users it has already removed.

The code does not say which. It never mentions identity verification, and its standard for every measure is "appropriate", defined in section 2.1(1) to take into account "the function, purpose, size/scale and maturity as well as the capacity and capabilities" of the provider. A small service is not held to a large one's tooling. It is held to a result it can defend.

What the code makes you keep, and count

Recognising a returning user requires holding something about the user who left. Section 5.5 anticipates that. It requires signatories to retain the information in a terminated account "for an appropriate period of time" before permanent deletion, and its note gives an example: up to 90 days after a user's own deletion request, and "a longer period if the end-user has been banned or their violation of the online safety policies is of a very serious nature".

The code also turns bans into published numbers. Section 8.4 requires an annual transparency report, the first due by 31 August 2025, giving "the number of Australian end-users whose accounts have been terminated" broken out by the policy basis for termination. Section 8.2(2) requires records of the compliance measures adopted to be kept for two years.

The retention has an outer limit, and the code points to it. Section 3.4 provides that a signatory is not in breach where another Australian law requires it to act differently, and the note names the Privacy Act 1988. Under Australian Privacy Principle 11, as the Office of the Australian Information Commissioner (OAIC) summarises it, an entity "has obligations to destroy or de-identify personal information in certain circumstances". A blocklist kept to stop banned users returning has a purpose. A copy of every removed user's documents, kept indefinitely and used for nothing else, is harder to justify.

The practical answer is to keep the minimum that does the job: a reference to the ban, the reason, and a match signal for the person, held in a store that exists for that purpose alone.

What is still moving

Three things qualify all of this.

Photo verification is not identity. eSafety tells users that when an app verifies photos by matching them against a live camera image, "this does not mean that their identity has been verified, only that the photo matches the user." A selfie match stops one kind of fake profile, the stolen photo. It does not recognise a banned user who signs up again under their own face unless the service compares that face with its removed users.

Scammers still use dating apps, whatever the instrument says. The Scamwatch guidance on relationship scams says scammers "use social media and dating or gaming apps and websites to find people looking for love" and "create fake profiles". The National Anti-Scam Centre's romance scam fusion cell, reported on 6 March 2026, brought dating and social media platforms together with banks and law enforcement from July to December 2025. Exclusion from the Scams Prevention Framework removes a statutory duty. It does not remove the fraud.

The voluntary model may not last. On 8 September 2026 the government published an exposure draft of the Online Safety Amendment (Digital Duty of Care) Bill 2026, with feedback due by 22 September 2026. When the dating code commenced, the department said eSafety would assess it after nine months and advise "whether further regulatory action is required". A statutory duty would change who enforces these expectations, if not what they are.

The age side of a dating app's obligations is a separate regime with its own limits on what a check may collect, covered in Australia's age verification rules for dating apps.

What this looks like in practice

  • Treat section 5.4(1)(d) as a test of your ban system, not your moderation. Remove a test account, sign up again with a new email and phone, and see whether anything notices.
  • Tie each ban to the person. Account-level signals are the first thing a removed user replaces; a verified document or a face match against removed users is not.
  • Apply serious bans across every dating service in your group. Section 5.4(3) requires it "to the extent possible", which presumes the services can share a ban signal.
  • Keep what the blocklist needs and nothing more. Hold a match reference and the reason for the ban in a dedicated store, and decide its retention period against APP 11 before you need to explain it.
  • Count terminations by policy basis from the start. The section 8.4 transparency report asks for exactly that number every year.
  • Do not wait for the Scams Prevention Framework to reach you. Dating is excluded by name; the fake profiles are not.

An Australian dating service is not asked to know who every user is. It is asked to know when someone it has already removed comes back.

Keep reading

ProofAge for Dating Apps — Stop Fake Profiles Before They Kill Trust

ProofAge helps dating platforms reduce fake profiles, speed up review, and verify real users — without the heavy friction of enterprise KYC.

See how it works