01

(1) If a data holder has received a notice under rule 4.18C or 4.20S, the data holder must, in accordance with this Division, invite the CDR consumer to amend the authorisation to disclose CDR data accordingly.

CDR Rule 4.22A(1)

3AU1.00.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: (a) subject to subrule (2), the name of the accredited person that made the request;

CDR Rule 4.23(1)(a)

3AU1.00.02

03

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

3AU1.00.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: (c) the types of CDR data for which the data holder is seeking an authorisation to disclose;

CDR Rule 4.23(1)(c)

3AU1.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: (b) the period of time to which the CDR data that was the subject of the request relates;

CDR Rule 4.23(1)(b)

3AU1.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: (e) if authorisation is being sought for disclosure over a period of time―what that period is;

CDR Rule 4.23(1)(e)

3AU1.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: (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)

3AU1.02.07

08

(1) An authorisation to disclose particular CDR data to an accredited person expires at the earliest of the following: (g) if the authorisation was for disclosure of CDR data over a specified period—the end of: (ii) if the period of the authorisation has been amended in accordance with this Division―that period as last amended;

CDR Rule 4.26(1)(g)(ii)

3AU1.02.08

09

(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)

3AU1.02.09

10

(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)

3AU1.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)

3AU1.02.11

12

Where account selection applies, Data Holders MUST pre-select accounts that were associated with the previous authorisation provided these accounts remain eligible and available to share. Data Holders MAY allow these accounts to be amended, and MAY provide information regarding the pre-selection of accounts.

Amending Authorisation Standards, Authorisation: Account Selection

3AU1.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

3AU1.01.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

3AU1.02.14

15

Data Holders MUST indicate where a dataset is being added to an authorisation or a disclosure duration is being amended. Data Holders MAY apply this standard to other changing attributes, but this MUST ONLY apply where the attribute in the new authorisation differs to that of the previous authorisation. How a changed attributed is signified is at the Data Holder’s discretion.

Amending Authorisation Standards, Authorisation: Changing Attributes

3AU1.02.15

16

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)

3AU1.00.16

17

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.

3AU1.02.17

18

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)

3AU1.02.18

19

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

CX Research 29

3AU1.02.19

20

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

CX Research 20

3AU1.02.20

21

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

3AU1.02.21

22

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)

3AU1.02.22

23

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

3AU1.02.23

24

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 and highlight changes to the authorisation. The CDR receipt should be given in writing and available through the data holder consumer dashboard.

CX Research 20

3AU1.02.24

25

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

3AU1.02.25

26

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.

3AU1.01.26

27

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

3AU1.00.27

28

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)

CDR Rule 4.23(1)(e)

3AU1.02.28

29

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

3AU1.00.29

01

Where customer profile selection applies, Data Holders  SHOULD omit the profile selection step and assume the customer profile associated with the existing authorisation. Data Holders MAY indicate which profile the authorisation relates to during the authorisation process.

Amending Authorisation Standards, Authorisation: Customer Profile

3AU1.03.01

01

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

3AU1.04.01

01

Where account selection applies, Data Holders MUST pre-select accounts that were associated with the previous authorisation provided these accounts remain eligible and available to share. Data Holders MAY allow these accounts to be amended, and MAY provide information regarding the pre-selection of accounts.

Amending Authorisation Standards, Authorisation: Account Selection

3AU1.05.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

3AU1.05.02

03

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

3AU1.05.03

04

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

3AU1.05.04

05

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

3AU1.05.05

06

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.

3AU1.05.06

07

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

3AU1.05.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. The purpose would be to 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

3AU1.05.08