Forced action · Australia

Forced registration

Forced registration is a working label for this design mechanism: The user must create an account, or is led to believe one is required, to complete a goal that could plausibly be provided without it. This is editorial implementation guidance for Australian journeys, not a finding of unlawfulness. From 1 July 2027, a similar interface is relevant to ACL section 28B only if the complete consumer-connection, manipulation or unreasonable-distortion and actual-or-likely-detriment test is met. Current ACL rules require a separate assessment.

Commences 1 July 2027
Also known as
  • forced enrolment
  • forced enrollment
  • account required for purchase
  • registration presented as technically necessary
  • guest path withheld
  • forced registration
  • account wall
  • data gate
  • forced data disclosure
  • unnecessary sign-up
  • Forced registration and data disclosure
Journey stages

Definition

What is this pattern?

The user must create an account, or is led to believe one is required, to complete a goal that could plausibly be provided without it. This is a design and research taxonomy for learning and evidence review, not a statutory offence label or an automatic finding that an interface is unlawful.

How it works

The user must create an account, or is led to believe one is required, to complete a goal that could plausibly be provided without it. The gate converts an otherwise available task into account creation, so the user must create a persistent identity record before reaching the requested outcome.

Warning signs

  • A desired goal is gated by account creation.
  • No equivalent guest or bypass route is available or discoverable.
  • Registration is not evidently necessary for the specific function.

Potential harms

  • A shopper may surrender unnecessary information or abandon a purchase after investing time in the basket.
  • People cannot compare the offer without creating an identity record and may receive communications they did not seek.

Learn by comparison

What does this look like?

These fictional examples make the design mechanism easier to recognise. They do not depict a real company and do not establish that an individual interface is unlawful.

Illustrative example 1 · Account wall at guest checkout

A fictional retailer removes guest checkout after an item is added and requires a full account, date of birth and saved password before payment can continue.

Potential consumer harm: A shopper may surrender unnecessary information or abandon a purchase after investing time in the basket.

Illustrative example 2 · Profile required before price estimate

A fictional repair service asks visitors to create a profile and verify a phone number before it reveals even an indicative service price.

Potential consumer harm: People cannot compare the offer without creating an identity record and may receive communications they did not seek.

What is a fairer alternative?

Provide a clearly visible guest or no-account path unless registration is genuinely necessary, and explain necessity before collecting data.

Context matters

Context and boundary cases

  • A desired goal is gated by account creation.
  • No equivalent guest or bypass route is available or discoverable.
  • Registration is not evidently necessary for the specific function.
  • Boundary to test: Account creation that is inherently necessary for persistent account functionality
  • Boundary to test: legally or operationally necessary identity verification with clear explanation
  • Why is an account or each requested field operationally necessary?
  • Can the transaction be completed as a guest?
  • Is the gate imposed before the consumer can see price or material terms?
  • Does a registration step enrol the consumer in anything beyond the requested transaction?
  • Can support, returns or cancellation be accessed without creating a new account?
  • What non-financial detriment or abandoned effort could result?

When a similar design can serve a legitimate purpose

  • Account creation that is inherently necessary for persistent account functionality
  • legally or operationally necessary identity verification with clear explanation

Operational review

What teams should review

Teams
  • Product
  • Design
  • Engineering
  • Privacy
  • Legal
  • Customer Support
  • Marketing
  1. What functional need makes “Register and save my details” necessary for the online retail checkout goal, and can that need be met with less disclosure or commitment?
  2. Which fields or permissions are required, what happens on refusal, and does the resulting state support this criterion: “A desired goal is gated by account creation”?
  3. Could the stated purpose make this dependency genuinely necessary under the boundary “Account creation that is inherently necessary for persistent account functionality”, and what product evidence would demonstrate that necessity?
  4. What functional need makes “Create profile” necessary for the home-services quote goal, and can that need be met with less disclosure or commitment?
  5. Which fields or permissions are required, what happens on refusal, and does the resulting state support this criterion: “No equivalent guest or bypass route is available or discoverable”?
  6. Could the stated purpose make this dependency genuinely necessary under the boundary “legally or operationally necessary identity verification with clear explanation”, and what product evidence would demonstrate that necessity?
  7. Can the operational owner explain why every required field is needed at this exact stage?
  8. What material information is unavailable until after registration?
  9. Are marketing choices genuinely optional and separate?
  10. Can a guest purchaser obtain support, return or cancel without creating an account?
  11. Does the same outcome require fewer steps through another channel?

Evidence to retain

  • field-by-field necessity register
  • journey map for guest and account users
  • consent and copy approvals
  • data-flow diagram and retention decision
  • support and cancellation test scripts
  • abandonment and complaint analysis
  • Annotated checkout and pricing screenshots at each responsive breakpoint
  • The complete state sequence before, during and after the consumer decision
  • Design-system component, content, default and configuration records for the reviewed release
  • Operational records substantiating price, availability, timing and eligibility claims
  • Usability, accessibility, reversal, complaint and support evidence relevant to consumer impact
  • A dated product and legal review record identifying evidence, uncertainties and release decisions

Legal map and implementation tools

Evidence base

Sources

  1. Dark commercial patternsOrganisation for Economic Co-operation and Development · Secondary · checked 2026-09-14 · OECD Digital Economy Papers No. 336
  2. Competition and Consumer Amendment (Unfair Trading Practices) Act 2026Federal Register of Legislation · Primary · checked 2026-09-14 · C2026A00064
  3. Competition and Consumer Act 2010, including Schedule 2: Australian Consumer LawFederal Register of Legislation · Primary · checked 2026-09-14 · C2004A00109
  4. Manipulative conduct in the digital economy, pricing claims and competition in essential services among ACCC priorities for year aheadAustralian Competition and Consumer Commission · Primary · checked 2026-08-09
  5. Unfair trading tricks and traps to be bannedTreasury Ministers · Primary · checked 2026-09-14
  6. Inquiry into the Competition and Consumer Amendment (Unfair Trading Practices) Bill 2026Senate Economics Legislation Committee · Primary · checked 2026-08-09