Consumer Experience (CX) Guidelines

Authorisation to disclose

Updated @February 22, 2024

These guidelines provide examples for how to implement the authorisation flow for common scenarios.

On this page

Overview

This example of the authorisation process covers account selection and confirmation for individual accounts.

A high level example of Authorisation to disclose, including Account selection and Confirmation.
A high level example of Authorisation to disclose, including Account selection and Confirmation.

Wireframes and guidelines

icon
Note: The wireframes shown are examples of how to implement key rules, standards, and guidelines. Use the on-screen functions to adjust zoom level or expand the wireframes to be viewed at full screen.

Default example

The following wireframes show a basic example of the authorisation process. Variations can be found in the below sections.

‣
See key requirements and guidelines
Wireframe refTypeRequirement levelStatementReferenceChecklist refFocus area
01
CDR Rule
MUST
(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
CDR Rule
MUST NOT
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
CDR Rule
MUST
(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
CDR Rule
MUST
(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
CDR Rule
MUST
(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
CDR Rule
MUST
(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
CDR Rule
MUST
(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
CDR Rule
MUST
(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
CDR Rule
MUST
(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
CDR Rule
MUST
(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
CDR Rule
MUST
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
CX Standard
MUST
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
CX Standard
MUST
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
CX Standard
MUST
Data Recipients and Data Holders MUST use data language standards to describe data clusters and permissions in consumer-facing interactions. See the Banking Language section for language to be used when requesting banking 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
CX Guideline
MAY
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)
3AU.02.15
16
CX Guideline
MAY
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
CX Guideline
MAY
For the purposes of CDR Rule 4.23(1)(b), data holders could refer to: • the earliest holding day as specified in the designation instrument; • a more recent date where the data has a shorter historical range. Note 1: For banking sector details on historical data access, refer to Schedule 3, Rules 3.2 (4) and (5), noting the earliest holding day specified in the Authorised Deposit-Taking Institutions designation instrument being 1 January 2017. Note 2: For energy sector details on historical data access, refer to Schedule 4 Rule 3.2(2)(b)(iii), noting the earliest holding day specified in the Energy Sector designation instrument of 1 July 2018. Note 3: A generic date may not be meaningful to a consumer whose data has a shorter historical range. For example, if a consumer only opened an account with a Data Holder on 10 February 2021, a Data Holder may wish to present this more precise and meaningful date for the purposes of 4.23(1)(b).
3AU.02.17
18
CX Guideline
MAY
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
CX Guideline
MAY
In addition to providing withdrawal instructions, data holders should provide instructions for how to review sharing arrangements.
CX Research 20
3AU.02.19
20
CX Guideline
MAY
Data holders should include their CDR policy in the Authorisation flow.
3AU.02.20
21
CX Guideline
MAY
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
CX Guideline
MAY
Data holders should redirect the consumer back to the data recipient following the final affirmative action.
3AU.02.22
23
CX Guideline
MAY
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
CX Standard
MUST
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 Language section for banking 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
CX Guideline
MAY
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
CDR Rule
MUST
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
‣
See prototype

Note: Some interactions and screens have been omitted for simplicity.

Unavailable accounts

An account may be considered unavailable for various reasons. Unavailable accounts may include eligible accounts that cannot be shared, such as where

  • a data holder deems it necessary to prevent financial harm or abuse, or
  • account users do not have sharing rights.

Unavailable accounts may also include ineligible accounts which data holders may show to mitigate confusion, such as where a consumer expects to see their accounts but cannot select them because they are ineligible for CDR.

The following wireframes show examples of the account selection step when a consumer has accounts unavailable for data sharing.

All accounts can be shown

‣
See wireframes, key requirements and guidelines
Wireframe refTypeRequirement levelStatementReferenceChecklist refFocus area
01
CX Standard
MUST
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
CX Standard
MUST
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
CX Guideline
MAY
Data holders may list specific accounts that are unavailable to share, or a generic explanation for unspecified accounts. Unavailable accounts may include eligible accounts that cannot be shared, such as where a data holder deems it necessary to prevent financial harm or abuse. Unavailable accounts may also include ineligible accounts which data holders may show to mitigate confusion, such as where a consumer expects to see their accounts but cannot select them because they are ineligible for CDR sharing.
3AU.03.03
04
CX Standard
MAY
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
05
CX Standard
MAY
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.03.05
06
CX Standard
MAY
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
CX Guideline
MAY
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
CX Guideline
MAY
The request function is optional but permitted in the standards. This functionality could be presented in the authorisation flow or elsewhere at the DH's discretion. The purpose of this concept would be to allow non-nominated persons and/or secondary users without sharing rights to send a request to the account owner(s) or administrators of the account. This request could alert the account owner(s) or administrators of the steps they need to take to provide those users with sharing rights. This could then lead the account owner or administrator to their respective services for secondary user instructions and nominated representatives.
3AU.03.08

Unavailable accounts cannot be shown

‣
See wireframes, key requirements and guidelines
Wireframe refTypeRequirement levelStatementReferenceChecklist refFocus area
01
CX Standard
MUST
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
CX Standard
MAY
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
CX Guideline
MAY
Data holders may list specific accounts that are unavailable to share, or a generic explanation for unspecified accounts. Unavailable accounts may include eligible accounts that cannot be shared, such as where a data holder deems it necessary to prevent financial harm or abuse. Unavailable accounts may also include ineligible accounts which data holders may show to mitigate confusion, such as where a consumer expects to see their accounts but cannot select them because they are ineligible for CDR sharing.
3AU.03a.03

No accounts can be shown

‣
See wireframes, key requirements and guidelines
Wireframe refTypeRequirement levelStatementReferenceChecklist refFocus area
01
CX Standard
MAY
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
CX Standard
MAY
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
CX Standard
MAY
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
CX Guideline
MAY
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
CX Guideline
MAY
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
CX Guideline
MAY
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
CX Guideline
MAY
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
CX Guideline
MAY
The request function is optional but permitted in the standards. This functionality could be presented in the authorisation flow or elsewhere at the DH's discretion. The purpose of this concept would be to allow non-nominated persons and/or secondary users without sharing rights to send a request to the account owner(s) or administrators of the account. This request could alert the account owner(s) or administrators of the steps they need to take to provide those users with sharing rights. This could then lead the account owner or administrator to their respective services for secondary user instructions and nominated representatives.
3AU.03b.08
09
CX Guideline
MAY
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

Data related to one or no accounts

The following wireframes show an example of authorisation when the consumer only has one account and an example of when data does not relate to any accounts (e.g. saved payees).

‣
See wireframes, key requirements and guidelines
Wireframe refTypeRequirement levelStatementReferenceChecklist refFocus area
01
CX Standard
MUST
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
CX Standard
MUST
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
CX Guideline
MAY
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

Profile selection

The following wireframes show an example of adding a profile selection step in authorisation.

‣
See wireframes, key requirements and guidelines
Wireframe refTypeRequirement levelStatementReferenceChecklist refFocus area
01
CX Standard
MAY
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

Duration

The following wireframes show examples where authorisation is being sought for disclosure on a single occasion and for ongoing collection.

‣
See wireframes, key requirements and guidelines
Wireframe refTypeRequirement levelStatementReferenceChecklist refFocus area
01
CDR Rule
MUST
(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
CDR Rule
MUST
(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
CX Guideline
MAY
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
CX Guideline
MAY
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

Layout variation

The CX Guidelines demonstrate extensive requirements for completeness. CX research suggests that breaking content into several steps facilitates comprehension and usability.

The following wireframes suggest alternative patterns for the authorisation.

‣
See wireframes, key requirements and guidelines
Wireframe refTypeRequirement levelStatementReferenceChecklist refFocus area
01
CX Guideline
MAY
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
‣
See prototype

Note: Some interactions and screens have been omitted for simplicity.

Cancellation

The following wireframes show an example of cancelling authorisation.

‣
See wireframes, key requirements and guidelines
Wireframe refTypeRequirement levelStatementReferenceChecklist refFocus area
01
CX Guideline
MAY
Data holders should outline the consequences of choosing to cancel throughout the authentication and authorisation process.
3AU.08.01
02
CX Guideline
MAY
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 of Error Handling Workshop
3AU.08.02

Download open source asset

Open sources design assets are created in Figma for the purposes of assisting implementation. This Figma file contain annotated wireframes and working prototypes for Authorisation to disclose, including:

  • Default example
  • Unavailable accounts
    • All accounts can be shown
    • Unavailable accounts cannot be shown
    • No accounts can be shown
  • Data related to one or no accounts
  • Profile selection
  • Duration
  • Layout variation
  • Cancellation

icon
Download design asset

For past versions, refer to

.

‣
About open source assets

Open sources design assets are provided in the form of version-controlled Figma files. These assets contain the annotated wireframe and working prototype published on this page, and have been reviewed for accessibility compliance. Assets are partially conformant to Web Content Accessibility Guidelines (WCAG) 2.1 level AA. These assets do not tend to accessible code and instead focus on visual presentation and readability.

The assets use the GOLD Design System; component rationale, accessibility support, and code documentation is available in the GOLD Design System website.

For more details, see

.

References

These CX Guidelines were informed by consultations and research conducted in 2019 to 2021, including the following:

  1. Consultations
    1. DSB 2020, Decision Proposal 127 - CX Guidelines for Enhanced Error Handling and CX Workshop: Error handling
    2. DSB 2021, Noting Paper 157 - CX Standards Arising from v2 Rules
    3. DSB 2021, Decision Proposal 160 - CX Standards | Non-individuals | Partnerships | Secondary users (see concepts 1.1 Accounts not shown | Generic message, 1.2 Sharing rights request, 1.3 Accounts shown | Generic message - overlay)
  2. CX research
    1. Tobias 2019, Phase 1 CX report
    2. GippsTech 2019, Phase 2, Stream 1 report
    3. Greater than X 2019, Phase 2, Stream 2 report
    4. Tobias 2019, Phase 2, Stream 3 report
  3. Other
    1. DSB, Technical Standards: Request Object
    2. Nielsen Norman Group 2019, 10 Usability Heuristics for User Interface Design (Error prevention)
    3. Nielsen Norman Group 2019, 10 Usability Heuristics for User Interface Design (Visibility of system status)

icon
The Consumer Data Standards Program is part of Treasury. Copyright © Commonwealth of Australia 2023. The information provided on this website is licensed for re-distribution and re-use in accordance with Creative Commons Attribution 4.0 International (CC-BY 4.0) Licence.

Overview

Consent

Authenticate

Authorise

Consent Management

Accessibility Statement

DSB Newsletter

The Consumer Data Standards Program is part of Treasury. Copyright © Commonwealth of Australia 2024. The information provided on this website is licensed for re-distribution and re-use in accordance with Creative Commons Attribution 4.0 International (CC-BY 4.0) Licence.