01

(1) When asking a CDR consumer to authorise the disclosure of CDR data, or amend a current authorisation, a data holder must give the CDR consumer the following information about the authorisation or amendment: (a) subject to subrule (2), the name of the accredited person that made the request;

CDR Rule 4.23(1)(a)

3AU.00.01

02

When asking a CDR consumer to authorise the disclosure of CDR data or to amend a current authorisation, the data holder must not do any of the following: (a) add any requirements to the authorisation process beyond those specified in the data standards and these rules; (b) provide or request additional information during the authorisation process beyond that specified in the data standards and these rules; (c) offer additional or alternative services as part of the authorisation process; (d) include or refer to other documents.

CDR Rule 4.24

3AU.00.02

03

(1) When asking a CDR consumer to authorise the disclosure of CDR data, or amend a current authorisation, a data holder must give the CDR consumer the following information about the authorisation or amendment: (c) the types of CDR data for which the data holder is seeking an authorisation to disclose;

CDR Rule 4.23(1)(c)

3AU.02.03

04

(1) When asking a CDR consumer to authorise the disclosure of CDR data, or amend a current authorisation, a data holder must give the CDR consumer the following information about the authorisation or amendment: (b) the period of time to which the CDR data that was the subject of the request relates;

CDR Rule 4.23(1)(b)

3AU.02.04

05

(1) When asking a CDR consumer to authorise the disclosure of CDR data, or amend a current authorisation, a data holder must give the CDR consumer the following information about the authorisation or amendment: (e) if authorisation is being sought for disclosure over a period of time―what that period is;

CDR Rule 4.23(1)(e)

3AU.02.05

06

(1) When asking a CDR consumer to authorise the disclosure of CDR data, or amend a current authorisation, a data holder must give the CDR consumer the following information about the authorisation or amendment: (d) whether the authorisation is being sought for: (i) disclosure of CDR data on a single occasion; or (ii) disclosure of CDR data over a period of time of not more than 12 months; Note: While certain consents by a CDR business consumer can have a period of 7 years, a corresponding authorisation cannot be for more than 12 months before renewal under subparagraph (1)(d)(ii).

CDR Rule 4.23(1)(d)

3AU.02.06

07

(1) When asking a CDR consumer to authorise the disclosure of CDR data, or amend a current authorisation, a data holder must give the CDR consumer the following information about the authorisation or amendment: (f) a statement that, at any time, the authorisation can be withdrawn;

CDR Rule 4.23(1)(f) | CX Research 30, 32

3AU.02.07

08

(1) When asking a CDR consumer to authorise the disclosure of CDR data, or amend a current authorisation, a data holder must give the CDR consumer the following information about the authorisation or amendment: (g) instructions for how the authorisation can be withdrawn.

CDR Rule 4.23(1)(g) | CX Research 30, 32

3AU.02.08

09

(1) A CDR consumer who has given an authorisation to a data holder to disclose particular CDR data to an accredited person may withdraw the authorisation at any time: (a) by using the data holder’s consumer dashboard; or (b) by using a simple alternative method of communication to be made available by the data holder for that purpose.

CDR Rule 4.25(1) | CX Research 30, 32

3AU.02.09

10

(2) If the withdrawal was in accordance with paragraph (1)(b), the data holder must give effect to the withdrawal as soon as practicable, and in any case within 2 business days after receiving the communication. Note: This subrule is a civil penalty provision (see rule 9.8).

CDR Rule 4.25(2)

3AU.02.10

11

For paragraph 56ED(7)(b) of the Act, the CDR entity must make its CDR policy readily available through each online service by means of which the CDR entity, or a CDR representative of the CDR entity, ordinarily deals with CDR consumers.

CDR Rule 7.2(8)

3AU.02.11

12

Data holders MUST allow the consumer to select which of their accounts to share data from if the data request includes account-specific data and if there are multiple accounts available. The Data holder MAY omit this step if none of the data being requested is specific to an account (e.g. Saved Payees).

Authorisation Standards, Authorisation: Account selection | CX Research 9

3AU.01.12

13

Data holders MUST show which accounts the data is being shared from prior to confirming authorisation if the data request includes account-specific data. The data holder MAY omit this information if none of the data being requested is specific to an account (e.g. Saved Payees).

Authorisation Standards, Authorisation: Account confirm

3AU.02.13

14

Data Recipients and Data Holders MUST use data language standards to describe data clusters and permissions in consumer-facing interactions. See the Banking and Non-Bank Lending Language section for language to be used when requesting banking and non-bank lending data; and the Energy Language section for language to be used when requesting energy data. Data language standards MUST be used when CDR data is being requested, reviewed, or access to such data is withdrawn. Data Recipients and Data Holders MUST use the appropriate data standards language for business consumers as denoted with an '*' for the relevant data. Data Recipients and Data Holders SHOULD expand on the proposed language where appropriate to communicate further details of what is being shared. Additional details MAY include additional information in context, such as in-line help or tool tips, and/or additional permissions where they may exist. Examples of permission details that MAY be used and provided as in-line help are denoted with an '†' for the relevant data.

Data Language Standards: Common, Data Language Standards: Language to be used

3AU.02.14

15

CDR Rules 4.23(1)(a) and (2) require data holders to refer to the accredited person's name using the legal entity name held in the Register during Authorisation.

CDR Rule 4.23(1)(a) and (2) | 10 Usability Heuristics for User Interface Design: Match Between the System and the Real World (Nielsen)

3AU.02.15

16

Data holders can meet CX Standard on Authorisation: Account confirm with the account selection step only. The selected accounts do not need to be displayed again on the final confirmation page.

3AU.02.16

17

CDR Rule 4.23(1)(b) requires data holders to give consumers information about the historical range of data that may be accessed under the authorisation. The historical range of consumer data a data holder may disclose can be: • up to 2 years, as required by the rules; • a shorter historical period, for example, if the consumer became a customer more recently or if the account was opened more recently (except in the energy sector, where LCCD requirements apply. See Energy sector information below); or • a longer historical period, such as the earliest holding date or a more recent date, which may be applicable if the data holder chooses to provide additional historical data voluntarily. Note 1: If historical ranges differ across datasets — for example, if one dataset goes back to 1 April 2023 and another dataset goes back to 30 August 2023 — then the data holder may consider either: • showing the specific historical range for each dataset, as demonstrated in the CX Guidelines, or • displaying the earliest historical date across all datasets (in this example, 1 April 2023). Note 2: The technical standards allow data recipients to limit how much historic data is collected when calling the relevant APIs using the oldest-time or oldest-date fields. Data holders must use these fields to constrain the data that they disclose. Data holders should be mindful of the fact that data recipients may wish to collect more or less historical data than the data holder makes available when developing wording to meet the requirements of rule 4.23(1)(b). The precise wording is at the data holder's discretion, but may consider, for example: This may include historical data that dates back [n years / to date], depending on your agreement with [ADR]. Banking and Non-Bank Lender sector Data holders must also refer to Subclauses 3.2(6) and (7) of Schedule 3. For open accounts, data holders must share a historical range of up to 2 years before the request date for transaction data, and up to 13 months for account data related to an authorisation for direct debit data. Data holders may voluntarily share older data. For closed accounts, if the relevant account is closed on the request date, CDR data, including historical data, related to that account is not considered required consumer data but can be shared voluntarily by the data holders. Energy sector Data holders must also refer to Subclauses 3.2(2)(b)(iii), (6) and (7) of Schedule 4. The last 2 years of billing data for a relevant account is required consumer data. 'Electricity usage’ energy data language data cluster — which pertains to metering data held by AEMO, as per clause 1.2–1.3(4) of Schedule 4 — is available for up to 2 years before the request date. This includes usage data for the duration that a customer has been the account holder for the given NMI, including any time before they became a customer of their current retailer.

CDR Rule 4.23(1)(b); Subclauses 3.2(6) and (7) of Schedule 3; Subclauses 3.2(2)(b)(iii), (6) and (7) of Schedule 4 | Technical Standards: Banking APIs, oldest-time field; Energy APIs, oldest-date field | CDR Support Portal: Historical transaction data: Earliest Holding Day; Guidance on Energy Last Consumer Change Date (LCCD)

3AU.02.17

18

Data holders should use plain language phrases such as 'stop sharing' to refer to how a consumer can withdraw authorisation.

CX Research 29

3AU.02.18

19

In addition to providing withdrawal instructions, data holders should provide instructions for how to review sharing arrangements.

CX Research 20

3AU.02.19

20

Data holders should include their CDR policy in the Authorisation flow.

3AU.02.20

21

Data holders should use terms that align with equivalent authorisation actions already in use in their digital experiences. The chosen language should clearly communicate a final affirmative action to mitigate user error. CX research suggests that terms like 'confirm' and 'authorise' successfully and meaningfully communicate the final affirmative action.

10 Usability Heuristics for User Interface Design: Error prevention (Nielsen)

3AU.02.21

22

Data holders should redirect the consumer back to the data recipient following the final affirmative action.

3AU.02.22

23

Data holders should provide a CDR receipt to the consumer after they have authorised to share data. The receipt should provide the consumer with a record of their sharing arrangement, including details that relate to the authorisation. The CDR receipt should be given in writing and available through the data holder consumer dashboard.

CX Research 20

3AU.02.23

24

If a scenario requires it, Data Holders and Data Recipients MUST merge and amend Basic and Detailed data cluster and permission language to show that Detailed scopes include Basic data. Data Holders and Data Recipients MUST use the alternative language denoted with an '‡' for the relevant scope(s). See the Banking and Non-Bank Lending Language section for banking and non-bank lending data and the Energy Language section for energy data. Example: A Data Recipient presents the Detailed data cluster in a data request to a consumer but does not present the Basic data cluster. The Detailed scope includes Basic data, but this is not apparent to the consumer based on the data cluster language and permissions used for the Detailed scope.

Data Language Standards: Common, Data Language Standards: Detailed scope requests

3AU.02.24

25

Data holders can refer to accounts using recognised nicknames, icons, account numbers, and account type. They can also include information on other elements the account may refer to such as any related plans, services, properties, numbers, and products.

3AU.01.25

26

If an authorisation to disclose particular CDR data to an accredited person is withdrawn or otherwise expires, the data holder must notify the accredited person in accordance with the data standards. Note: This rule is a civil penalty provision (see rule 9.8).

CDR Rule 4.26A

3AU.02.26

27

Data holders MAY include additional functionality to support account discovery and selection where further navigation or interaction is required to view all accounts. This may, for example, include search, sort, filter, scroll, grouping, and pagination, or other controls in line with existing consumer experiences. Any such functionality MUST NOT introduce unwarranted friction. Note: Unwarranted friction should have regard to CDR Rule 4.24 and is considered to include the addition of any requirements beyond normal data holder practices for an equivalent account selection process.

Authorisation Standards, Authorisation: Account selection functionality

3AU.01.27

28

Data holders and data recipients MUST state in consumer-facing interactions and communications that third parties do not need consumer passwords to access CDR data. The exact phrasing of this is at the discretion of the data holder and data recipient. Note: In this context, 'third parties' refers to entities on the ADR-side and does not include any third parties that the data holder may engage.

Authentication Standards, Common Authentication Standards, Authentication: Passwords

3AU.00.28

29

CDR Rule 4.23(1)(e) requires data holders to state the forward-looking time period where the authorisation is sought for the disclosure of CDR data. This cannot be more than 12 months.

CDR Rule 4.23(1)(e)

3AU.02.29

30

Data holders should display the name of the brand receiving the consumer data request. This should match the specified brandName value on the register.

CDR Support Portal: Brands in the CDR ecosystem

3AU.00.30

01

Data holders MUST allow the consumer to select which of their accounts to share data from if the data request includes account-specific data and if there are multiple accounts available. The Data holder MAY omit this step if none of the data being requested is specific to an account (e.g. Saved Payees).

Authorisation Standards, Authorisation: Account selection | CX Research 9

3AU.03.01

02

If certain accounts are unavailable to share, data holders SHOULD show these unavailable accounts in the account-selection step. Data holders SHOULD communicate why these accounts cannot be selected, and this SHOULD be communicated as in-line help or as a modal to reduce on-screen content. Data holders MAY provide instructions on how to make these accounts available to share, and this SHOULD be communicated as in-line help or as a modal to reduce on-screen content. Note: Unavailable accounts are to be interpreted in accordance with the rules on eligible consumers and required consumer data.

Authorisation Standards, Unavailable Accounts: Displaying accounts | CX Research 9

3AU.03.02

03

In accordance with the Unavailable Accounts: Displaying accounts standard, data holders should display unavailable accounts as part of the account selection step, with an explanation of why these are unable to be shared. Where data holders are unable to display unavailable accounts, they may instead provide a generic explanation for unspecified accounts, in accordance with the Unavailable Accounts: No accounts can be shown standard. Unavailable accounts may include accounts that are not in scope for data sharing under CDR, accounts for which data sharing is voluntary, or where a data holder deems it necessary to prevent financial harm or abuse. Despite being unavailable, data holders are recommended to show these accounts to avoid confusion and align with consumer expectations. For further detail about covered products and required and voluntary CDR data, refer to the ACCC Compliance guide for data holders in the banking and non-bank lender sectors.

CDR Rules Clause 3.2 of Schedule 3; Clause 3.2 of Schedule 4 | Authorisation Standards, Unavailable Accounts: Displaying accounts; Authorisation Standards, Unavailable Accounts: No accounts can be shown | ACCC Compliance guide for data holders in the banking and non-bank lender sectors

3AU.03.03

04

If unavailable accounts cannot be shown in the account selection step, data holders MAY display a generic explanation and instructions.

Authorisation Standards, Unavailable Accounts: No accounts can be shown

3AU.03.04

06

If a user does not have sharing rights for a particular account or set of accounts, data holders MAY invite the user to request sharing rights from the authorisation flow. The presentation of this mechanism MUST NOT introduce unwarranted friction as defined in rule 4.24 on restrictions.

Authorisation Standards, Unavailable Accounts: Request sharing rights

3AU.03.06

07

If an account holder has not given a secondary user instruction for an account with a secondary user, that account will appear as unavailable to the secondary user.

3AU.03.07

08

The request function is optional but permitted under the standards. It can be presented within the authorisation flow or elsewhere, at the data holder’s discretion. This functionality would allow non-nominated persons or secondary users without sharing rights to request access. This could alert the account owner(s) or administrator(s) of the steps required to grant sharing rights, leading them to the relevant services for managing secondary users or nominated representatives.

Authorisation Standards, Unavailable Accounts: Request sharing rights

3AU.03.08

09

Data holders should provide clear explanations to consumer about why their accounts are unavailable. These explanations should only reference account types that the consumer holds, and should be contextually shown in relation to the account where possible. Data holders should use appropriate interventions to mitigate cognitive overload, facilitate comprehension, and provide transparency and consumer control. This can be done in a variety of ways, including through the use of design patterns like progressive disclosure, micro and/or descriptive copy, and with the use of microinteractions.

CX Research 8, 19

3AU.03.09

01

Data holders MUST allow the consumer to select which of their accounts to share data from if the data request includes account-specific data and if there are multiple accounts available. The Data holder MAY omit this step if none of the data being requested is specific to an account (e.g. Saved Payees).

Authorisation Standards, Authorisation: Account selection | CX Research 9

3AU.03a.01

02

If unavailable accounts cannot be shown in the account selection step, data holders MAY display a generic explanation and instructions.

Authorisation Standards, Unavailable Accounts: No accounts can be shown

3AU.03a.02

03

In accordance with the Unavailable Accounts: Displaying accounts standard, data holders should display unavailable accounts as part of the account selection step, with an explanation of why these are unable to be shared. Where data holders are unable to display unavailable accounts, they may instead provide a generic explanation for unspecified accounts, in accordance with the Unavailable Accounts: No accounts can be shown standard. Unavailable accounts may include accounts that are not in scope for data sharing under CDR, accounts for which data sharing is voluntary, or where a data holder deems it necessary to prevent financial harm or abuse. Despite being unavailable, data holders are recommended to show these accounts to avoid confusion and align with consumer expectations. For further detail about covered products and required and voluntary CDR data, refer to the ACCC Compliance guide for data holders in the banking and non-bank lender sectors.

CDR Rules Clause 3.2 of Schedule 3; Clause 3.2 of Schedule 4 | Authorisation Standards, Unavailable Accounts: Displaying accounts; Authorisation Standards, Unavailable Accounts: No accounts can be shown | ACCC Compliance guide for data holders in the banking and non-bank lender sectors

3AU.03a.03

01

If unavailable accounts cannot be shown in the account selection step, data holders MAY display a generic explanation and instructions.

Authorisation Standards, Unavailable Accounts: No accounts can be shown

3AU.03b.01

02

If a successfully authenticated user cannot proceed to establish an authorisation in accordance with the rules on eligible consumers and required consumer data, data holders MAY provide the option of concluding the authorisation process.

Authorisation Standards, Unavailable Accounts: Authorisation not permitted

3AU.03b.02

03

If a user does not have sharing rights for a particular account or set of accounts, data holders MAY invite the user to request sharing rights from the authorisation flow. The presentation of this mechanism MUST NOT introduce unwarranted friction as defined in rule 4.24 on restrictions.

Authorisation Standards, Unavailable Accounts: Request sharing rights

3AU.03b.03

04

Some scenarios may result in a user without sharing rights not seeing any accounts in the account selection step. Data holders may provide a generic explanation and instructions in place of the account selection step and/or unavailable account pattern.

3AU.03b.04

05

Data holders should provide additional information to help users without sharing rights understand how they might gain sharing rights. This may, for example, state that the account owner has to grant them sharing rights before data sharing can occur. Similarly, data holders may include instructions for how to request sharing rights from the account owner(s) or administrator if that functionality is provided by the data holder.

3AU.03b.05

06

If no accounts can be shown, data holders should provide a message to consumers confirming that data will not be shared during this process.

3AU.03b.06

07

Some scenarios may result in a user without sharing rights not seeing any accounts in the account selection step. A data holder may choose to provide optional functionality to allow a user without sharing rights to send a request to the account owner(s) or administrators from the authorisation flow.

3AU.03b.07

08

The request function is optional but permitted under the standards. It can be presented within the authorisation flow or elsewhere, at the data holder’s discretion. This functionality would allow non-nominated persons or secondary users without sharing rights to request access. This could alert the account owner(s) or administrator(s) of the steps required to grant sharing rights, leading them to the relevant services for managing secondary users or nominated representatives.

Authorisation Standards, Unavailable Accounts: Request sharing rights

3AU.03b.08

09

If a data holder provides the optional request functionality and a user acts upon it, the data holder should provide a message to confirm that the request has been sent. This message should be clearly visible and shown as soon as the action has taken place.

10 Usability Heuristics for User Interface Design: Visibility of system status (Nielsen)

3AU.03b.09

01

Data holders MUST allow the consumer to select which of their accounts to share data from if the data request includes account-specific data and if there are multiple accounts available. The Data holder MAY omit this step if none of the data being requested is specific to an account (e.g. Saved Payees).

Authorisation Standards, Authorisation: Account selection | CX Research 9

3AU.04.01

02

Data holders MUST show which accounts the data is being shared from prior to confirming authorisation if the data request includes account-specific data. The data holder MAY omit this information if none of the data being requested is specific to an account (e.g. Saved Payees).

Authorisation Standards, Authorisation: Account confirm

3AU.04.02

03

Where a consumer only has one account, data holders can meet CX Standards for Authorisation by omitting the account selection step and only displaying the account on the final confirmation page.

3AU.04.03

01

Data holders MAY add a 'profile selection' step or equivalent prior to the account selection step if a single identifier provides access to different customer accounts. For example, one customer ID may give access to business customer and individual customer accounts. The 'profile selection' step SHOULD only be considered if it is an existing customer experience, and SHOULD be as minimal as possible to avoid introducing unwarranted friction (having regard to CDR Rule 4.24).

Authorisation Standards, Authorisation: Profile selection

3AU.05.01

02

Data holders MAY include additional functionality to support account discovery and selection where further navigation or interaction is required to view all accounts. This may, for example, include search, sort, filter, scroll, grouping, and pagination, or other controls in line with existing consumer experiences. Any such functionality MUST NOT introduce unwarranted friction. Note: Unwarranted friction should have regard to CDR Rule 4.24 and is considered to include the addition of any requirements beyond normal data holder practices for an equivalent account selection process.

Authorisation Standards, Authorisation: Account selection functionality

3AU.05.02

03

These artefacts show an example implementation of selection functionality, which may or may not be suitable in every situation. Data holders should use their discretion and implement the most appropriate options for their use cases.

3AU.05.03

04

Data holders should allow consumers to search, sort, filter and select their accounts in a way that is aligned to the outcomes consumers are seeking. For example, a consumer may want to search, sort, and filter by nicknames, account numbers, account type, or other elements the account may refer to such as any related plans, services, properties, numbers, and products.

10 Usability Heuristics for User Interface Design: Flexibility and efficiency of use (Nielsen)

3AU.05.04

05

If enhanced selection functionality is implemented alongside pagination, filter or search, data holders should consider consumer expectations, technical feasibility and their existing user experiences. Data holders should provide feedback to users to: • Prevent errors- This ensures the system aligns with user expectations. For example, if “Select all” applies only to the current page, this limitation should be clearly communicated to avoid misunderstandings. • Minimise cognitive load- Users shouldn’t have to manually track selections across multiple pages. Offering selection options like “Select all [n] accounts on this page,” “Select all [n] accounts on all pages,” and “Select none” helps ensure clarity and simplifies bulk actions.

10 Usability Heuristics for User Interface Design: Match Between the System and the Real World, Error Prevention, Flexibility and efficiency of use (Nielsen)

3AU.05.05

06

If scrolling is required to view the total number of accounts, data holders should allow consumers to search and filter their accounts in a way that is aligned to the outcomes consumers are seeking.

10 Usability Heuristics for User Interface Design: Flexibility and efficiency of use (Nielsen)

3AU.05.06

07

When the authorisation flow is presented to the consumer in a data holder app, the data holder MUST provide consumers with the ability to switch or add user profiles based on the profiles supported by that app.

Authorisation Standards, Authorisation: Add or Switch Profiles

3AU.05.07

08

In line with existing practices, a data holder may provide functionality that allows a consumer to add, register, or switch profiles prior to, or after, authentication.

3AU.05.08

09

Data holders may present the profile selection step at different points in the authorisation process, depending on the authentication flow. For example, it may occur after authentication for Redirect to Web flows, or when switching or adding users for in-app authorisation flows.

3AU.05.09

01

(1) When asking a CDR consumer to authorise the disclosure of CDR data, or amend a current authorisation, a data holder must give the CDR consumer the following information about the authorisation or amendment: (e) if authorisation is being sought for disclosure over a period of time―what that period is;

CDR Rule 4.23(1)(e)

3AU.06.01

02

(1) When asking a CDR consumer to authorise the disclosure of CDR data, or amend a current authorisation, a data holder must give the CDR consumer the following information about the authorisation or amendment: (d) whether the authorisation is being sought for: (i) disclosure of CDR data on a single occasion; or (ii) disclosure of CDR data over a period of time of not more than 12 months; Note: While certain consents by a CDR business consumer can have a period of 7 years, a corresponding authorisation cannot be for more than 12 months before renewal under subparagraph (1)(d)(ii).

CDR Rule 4.23(1)(d)

3AU.06.02

03

If the duration of an authorisation request is absent or 0, data holders are to assume that the ADR is collecting the data on a 'single occasion' as per CDR Rule 4.23(1)(d). Data holders may consider communicating the sharing period as a single disclosure instance, but the phrasing is at the discretion of the data holder.

Technical Standards: Request Object

3AU.06.03

04

If the duration of an authorisation request is greater than 0 but less than 24 hours, data holders are to assume that the ADR is collecting the data on a 'single occasion' as per CDR Rule 4.23(1)(d). Data holders may consider communicating the sharing period as a single disclosure instance occurring within a specific timeframe, but the phrasing is at the discretion of the data holder.

Technical Standards: Request Object

3AU.06.04

01

Data holders should align the authorisation flow to their design systems and/or experience languages to facilitate familiar, intuitive, and trustworthy authorisations

3AU.07.01

01

Data holders should outline the consequences of choosing to cancel throughout the authentication and authorisation process.

3AU.08.01

02

If a consumer cancels at some point in the Consent Flow, CDR participants should confirm that data was not or will not be shared. The CDR receipt should be given in writing.

CX Workshop: Error handling

3AU.08.02