Decision Proposal 162 - CX Standards | Joint Accounts

[CDR-CX-Stream]

December 10 2021: Decision Made
This decision was approved on 10 December 2021. The decision record is attached below:
Decision 162 Joint Accounts.pdf

---

November 9 2021: Decision Proposal 162 Published
This decision proposal relates to CX Standards for joint accounts.

Data standards have been identified in relation to several areas, including for:

• Joint account notifications
• Notification alerts
• Vulnerable joint account holders
• Pending disclosures
• Ceasing joint account data sharing

The decision proposal for joint accounts is attached below:
DP162 - Joint Accounts.pdf

The following CX artefacts have been published to accompany this proposal:
For proposed standards relating to notification settings, see Miro | PDF
For proposed standards relating to the authorisation flow, see Miro | PDF
For proposed standards relating to ceasing joint account sharing, see Miro | PDF

NB: These designs are for illustrative purposes only. They are published to assist consultation and have not been assessed for rules compliance. These artefacts represent the initial scope of the joint account CX Guidelines, pending the outcome of consultation. Participants can use these as initial reference points, but achieving compliance remains the responsibility of the CDR participant.

Elements of this decision proposal have been consulted on extensively throughout 2020 and 2021. This decision proposal has been informed by the following:

• Noting Paper 207 consultation
• Noting Paper 157 consultation
• Draft v3 Rules consultation
• Design Paper: an opt-out data sharing model
• Public joint accounts workshop in March 2021. See public workshop Miro Board
• Phase 3 CX research – Rounds 1, 2, 3 and, 6
• Consumer Policy Research Centre (CPRC) report: Joint accounts & the Consumer Data Right

Given the extent of consultation that has already occurred on this topic, and the community request for significant implementation time for joint accounts, the Chair has approved a consultation window of 21 days rather than the typical 28 days. This will provide additional time to the 6-month lead time requested by the community to date. Requests for feedback extension may still be considered, but this will not necessarily result in a change to the obligation dates.

Feedback is now open for this proposal and will close on Tuesday 30 November 2021.

---

Edit 10.12.21: Decision Made
Edit 11.11.21: CX artefacts published to assist consultation; DP updated with artefact links
Edit 9.11.21: Decision proposal published
Edit: Placeholder updated to reflect the pending consultation on CX standards for the v3 Rules

[CDR-CX-Stream]

The recent announcement by the Treasury notes that the current joint account requirements that would have applied from November 2021 will be deferred.

Treasury is seeking views on a proposal to support an ‘opt‑out’ approach for joint accounts.

The CX Standards being developed for DP162 have been incorporated into this design paper and will be progressed accordingly. Any subsequent standards consultations on joint accounts will follow this program of work.

Feedback can be provided on these standards and the general 'opt-out' proposal in the new Design Paper: an ‘opt-out’ data sharing model for joint accounts GitHub issue.

[CDR-CX-Stream]

The original post has been updated to reflect the pending consultation on CX standards for the v3 Rules.

[CDR-CX-Stream]

The joint accounts decision proposal has been published and can be found in the original post.

Feedback is now open for this proposal and will close on Tuesday 30 November 2021.

[CDR-CX-Stream]

The following CX artefacts have been published to accompany this proposal:
For proposed standards relating to notification settings, see Miro | PDF
For proposed standards relating to the authorisation flow, see Miro | PDF
For proposed standards relating to ceasing joint account sharing, see Miro | PDF

NB: These designs are for illustrative purposes only. They are published to assist consultation and have not been assessed for rules compliance. These artefacts represent the initial scope of the joint account CX Guidelines, pending the outcome of consultation. Participants can use these as initial reference points, but achieving compliance remains the responsibility of the CDR participant.

[da-banking]

Following is our feedback:

1. Which options and obligation levels are supported?

• DA would support all options except Authorisation Alert (for Vulnerable JAH)

2. If no options are supported, what alternatives exist to address the identified issues?

• The Authorisation Alert assumes requester is abused. For Authorisation Alert, DA proposed solution would be to disable sharing for vulnerable joint accounts, where no DH will not ask for new authorisation, and data would not be disclosed for existing authorisation. This is in line with Part 4, Division 4.2 Section 4.7(1)(a) where a DH may refuse to ask for authorisation, and refuse disclosure if necessary to prevent harm. and From https://cdr-support.zendesk.com/hc/en-us/articles/900004849223-Alternative-channels-to-withdraw-authorisation

3. Are there additional standards that should be considered?

4A.6(8) indicate that DOMS to be provided in accordance with data standards. However, the Specified period (4A.8(f)) is up to each DH to decide. Would that be a consistent Consumer experience for consumer?
The rules, standards and CX guidelines do not indicate which consumer shared the Joint account. For a joint account that may have multiple CDR consumers (account holders , and secondary users) sharing it, is that information omitted on purpose by the Treasury and DSB?

Notification is assumed to be push notification from the PUBLIC | DP162 | Joint accounts, Online Whiteboard for Visual Collaboration (miro.com) (to-be CX guidelines).
For SMS notification, the amount of text required may not fit in a single SMS. SMS concatenation is dependent on Network support and end-user device.

For Data Holders (ADIs) who currently provide their Consumer Dashboard in both Internet Banking (browser) and the Banking App, is it ok for the following functionality to only be managed in Internet Banking (not in the App):

• Disclosure option management service (DOMS)
• Management of Joint Account Notifications

4. To support guidance on informed joint account management, how can the following be described to consumers in a comprehensible and meaningful way:

a. Disclosure option management service - A service for joint account holders to control the process of obtaining sharing approvals on a joint account.
b. Disclosure option(s) – The options available to the joint account holders for obtaining sharing approvals on a joint account.
c. Pre-approval – A sharing request to disclose data is approved in principle by all joint account holders, and would only require a single approval from the requester.
d. Co-approval - Any sharing request to disclose data will require approvals from all the joint account holders.
e. Removing an approval - Cease current sharing arrangement for divulging account data with an ADR service.

5. Where could CX Guidelines be developed to assist joint account implementation?

The CX guideline could include coverage for Rule 4A.7 and 4A.8.

[CDR-CX-Stream]

Thanks for these queries @da-banking

Q: [T]he Specified period (4A.8(f)) is up to each DH to decide. Would that be a consistent Consumer experience for consumer?
Our expectation has been that DHs will align the specified period to existing approval experiences. This allows for a consistent experience with the DH rather than making the specified period unique to CDR. We welcome alternative views and proposals on this.

Q: The rules, standards and CX guidelines do not indicate which consumer shared the Joint account. For a joint account that may have multiple CDR consumers (account holders , and secondary users) sharing it, is that information omitted on purpose by the Treasury and DSB?
Previous CX artefacts for joint accounts did specify the user, but this was highlighted as a potential privacy issue in past workshops and consultation. It is up to the DH to determine if the name of the user is shown, but the CX guidelines have not suggested the user's name be specified given the concerns, but also as a generic reference was suggested by the community to demonstrate a flexible approach.

Q: For Data Holders (ADIs) who currently provide their Consumer Dashboard in both Internet Banking (browser) and the Banking App, is it ok for the following functionality to only be managed in Internet Banking (not in the App):
- Disclosure option management service (DOMS)
- Management of Joint Account Notifications
The rules only require that the DOMS be online and neither the rules nor standards specify the channel, but the expectation signalled to date has been for the choice of channels to align with existing customer experiences/preferences. No specific channel requirements are outlined or proposed in relation to joint account notification management, however the rules state that this must be done in accordance with the data standards and DP216 contain options for this to be contextual and/or in line with existing experiences (p.4).

These points reflect the rules definition of 'ordinary means' (Division 1.3, rule 1.7(1)), which is used throughout the rules and is defined as follows:

ordinary means of contacting an account holder by a data holder means:
(a) if the data holder has agreed with the account holder on a particular means of contacting the account holder for the purposes of the relevant provision—that means; and
(b) otherwise—the default means by which the data holder contacts the account holder in relation to the account.

[CatrinaM]

DP 162 - HI please find attached our feedback on your Notification settings. Please let me know if you have any further questions or need to clarify anything
thanks
Catrina

1.1 JAH-A amends notifications

Indications are that the notifications are at account level rather than customer level - this mean that a customer may receive 10 notifications on their joint accounts (if they have split loans) for data sharing preferences. This feels like it should sit at customer level rather than account level - can you advise if this is the intention?
Granular level of notifications being event based, seems like overkill to us (but may work for bigger banks who have the capability)
Option 3 Granular control - does not seem to meet the rule that we MUST notify of the changes on their accounts (feels contradictory to the rule 4A.16 (3)
Option 2 Notification frequency- specify "should" however the rules again specify MUST, therefore feels contradictory
Option 5 + Confirmation screen- Consequences of amending the schedule - this is a must to notify, however, option 2 is should - therefore again feels contradictory to the rule.
1.2 JAH A = Amends notifications:

Option 6 - Means to Amend - Please confirm what the is required in relation to this - is there a requirement to provide a notification schedule for every event type to be switched on or off, or just to be able to turn off all notification types? the rule does not specify that the granular level of event type is a must

Option 3- Do we have to comply with granular control on joint account notification types?

Option 2 Notifications - the rule states that must provide alternative notification schedules including reducing the summary (4A.14) yet option 2 states "should" - can you confirm if ON and OFF are sufficient notification frequencies?, or if we have to provide another frequency type other than on/off?
If no to above;
Option 9 - why is ON or OFF not sufficient in terms of the frequency options

General question:

Is it OK to use first names on DOMS dashboard and notifications (as an example "Jon has stopped sharing his data") or should we remain generic to account holder 1, 2 etc?
Our assumption is that the CDR Notifications for Joint Accounts are to be delivered via electronic means only (Email/SMS NOT Paper) Could you please confirm that this is correct?

[anzbankau]

ANZ appreciates the opportunity to provide feedback for this decision proposal.

Re: Joint Account Notifications

Recommended Option 2: Notification Frequency

DHs SHOULD offer consumers the ability to receive their joint account notifications as a periodic summary

Considering the richness of authorisaton detail in the consumer dashboard we question the utility of bulk notifications after the fact. Further, bulk notifications outside of the dashboard may be unwieldy and impractical for easy consumption (for example via sms or email). We suggest that the notification requirements (and any subsequent standards) remain light touch and be left in the competitive space and aligned to existing organizational channel notification protocols.

Recommended Option 3: Granular Control

DHs SHOULD offer consumers the ability to specify which joint account notifications they do and do not want to receive

As per Option 2 feedback this option appears overly prescriptive. Our recommendation is that notification requirements and standards be kept to a minimum and align with existing DH notification protocols, i.e., left to the competitive space.

Recommended Option 6: Means to Amend Notifications – Contextual

DHs MUST provide a mechanism or entry point for a notification schedule to be amended from or in relation to the notification itself

We propose that this requirement is limited to providing a mechanism for amending notification schedule. Our understanding is that any link or entry mechanisms are only within the authenticated application experience, not out of band such as email or SMS in line with existing CX standards.

Recommended Option 7: Means to Amend Notifications – Channels

DHs SHOULD allow a consumer to amend their notification schedule in line with existing notification management channels and experiences

We propose that this requirement should not be overly prescriptive and it should be left to the competitive space to create an optimal CX experience for amending notification schedules.

[NationalAustraliaBank]

NAB welcomes the opportunity to provide feedback for the CX standards for joint accounts. The following are our recommendations based on the options proposed:

Joint Accounts Notifications - NAB supports Option 1 (at the discretion of the Data Holder).
Notification alerts - NAB supports Option 2: Contextual Alert.
Pending disclosures - NAB supports Option 2 Pending Status Provisions.
Ceasing joint account data sharing - NAB supports Option 2 Joint Account Withdrawal Standards.

NAB would like to take the opportunity to request that the final CX flows & checklist for DOMS be released as soon as possible, noting that the Summer holidays and shutdown period are fast approaching.

[WestpacOpenBanking]

Westpac welcomes the opportunity to comment on Decision Proposal 162. Our comments in relation to each part of the proposal are below.

Joint Account Notifications

Our core remarks are that:

• Data Holders should be able to leverage existing pattens that have been established within their brands, including existing patterns which allow customers to manage consent holistically when they stop data sharing (rather than at individual account level). This provides customers with a clear on or off approach, which reduces cognitive load, keeps the process simple and easy to understand, and reduces the risk of the customer not identifying all impacted Joint Accounts.
• Notification settings are closely linked to the Disclosure Options Management Service (DOMS) and therefore contextually it may not be best to include them in wider banking notifications. We instead recommend that notification settings should be managed in a way familiar to the customer based on their dealings with the data holder.

Options 1, 2, 3 and 4

• We recommend Option 1 no change – consistency of experience in managing notifications for each participant is more important than consistency across participants in the CDR. This is because customers would necessarily already be familiar with managing other settings with each participant. We recommend that the standards outline minimum approach rather than constraining participants and preventing them from delivering innovative experiences. We also recommend that non-normative examples are kept from the data standards (i.e. the ‘MAY’ in ‘MAY, for example’ is non-normative and uppercase MAY shouldn’t be used).

• We note that Option 2 and Option 3 create risk of cognitive overload for customers - the additional customer benefit is not commensurate with the complexity of the required build, and there is a lack of granular detail around edge cases. If included we recommend that it be stated that data holders should consider the additional cognitive load this would place on the customer when determining whether and how to implement the relevant customer.

• We are broadly supportive of Option 4 – Turn Off Notifications. This option offers customers the option to opt out of notifications holistically with the minimum cognitive load, making the process simple and easy to manage for the customer. We do however note that there is a risk that customers will miss out on notifications which are important to them – we recommend that the DSB carefully consider this issue.

Option 5: Consequences of Amendment

• We recommend changing the term 'notify' to 'inform' because the intent (according to the CX) is to provide the customer with information instead of than sending a notification.
• The additional requirement to provide ‘instructions for how to amend this schedule or reverse the amendment’ seems unnecessary as the customer is already actively managing their setting. Any redirection would therefore be to the same screens as they are currently in. We would recommend the removal of the last statement: ‘Notification must include instructions for how to amend this schedule or reverse the amendment’. If the sentence is not removed, we recommend changing the MUST to a SHOULD.

Option 6: Means to Amend Notifications – Contextual

• In messaging channels which only allow a small amount of text, it is very difficult to craft a notification which is informative and fulfils the requirements of option 6 (or option 8). This is because security controls will limit the ability to provide an entry point directly from the notification (e.g., email notifications). We therefore recommend changing this obligation from a MUST to SHOULD.
• Noting the complexities of various notification channels, additional examples of acceptable behaviour should be added. i.e. “For channels oriented to short messages the notification MAY include short text directing the customer to the appropriate place, e.g. ‘Visit Online Banking to amend’. DH’s MAY meet this obligation by integrating with the notification preference management capabilities of the messaging platform, if it has one, e.g. Android and iOS push notification preference management.”

Option 7: Means to Amend Notifications – Channels

• Existing notification settings are focused on banking features and differ between different digital channels (Open Banking may leveraged the primary digital channel only). Adding Open Banking notifications to existing notification management channels and experiences will present customer experience challenges that could result in customers confusing notification types. This could result in customers turning off Open Banking Notifications without context.
• We recommend that notification settings are be located within the Open Banking Dashboard and the DOMS services. This reduces the cognitive load, keeping the process simple and easy to manage and provides context to the Notification Settings. Alternatively, we suggest that the location of notification to be left to the discretion of the Data holders.

Option 8: Notification Content – Review Authorisation

• In messaging channels which only allow a small amount of text, it is very difficult to craft a notification which is informative and fulfils the requirements of option 8 (or option 6). We therefore recommend changing this obligation from a MUST to SHOULD.
• Security restrictions would restrict the use of links from notifications (e.g., email notifications)
• To remove confusion, we recommend removing the phrase "from or in relation to the notification itself" as the intent (according to the CX) is that “For the content of the notification, DHs SHOULD/MUST…..”.

Ceasing Joint Account Data Sharing

Option 2: Joint Account Withdrawal Standard 3.a

• We recommend changing this obligation from MUST to SHOULD. Statement 2 ‘”to check with the other account holder(s) before continuing” implies a customer cannot make an independent decision.
• We suggest rephasing statement 3.a to “that even though sharing for this service has now stopped, the other account holder(s) can still create a new data sharing arrangement on the account.
• The CX guidance references the ability to remove the approval for a specific account within an authorisation i.e., that any joint account owner can remove their approval for data to be shared with this ADR. Clarification is required on whether a Data Holder MUST provide the ability to remove approval for a specific account from an authorisation, or whether the ability for a joint account holder to remove approval for all accounts within an authorisation (that they are an owner of) also meet the rules.

[commbankoss]

CBA appreciates the opportunity to provide feedback for this Decision Proposal. Please see our feedback and recommendations in the attached.
DP-162 CBA feedback.pdf

[PratibhaOrigin]

Origin has reviewed the paper and have some queries in relation to the proposed requirements as listed below:

1. Rule 4A.14 Notification requirements for consumer data requests on joint accounts suggests -

The data holder must make the appropriate approval notification to a joint account holder in relation to an event mentioned in subrule (1):

• as soon as practicable after the event occurs, unless the joint account holder has selected
  an alternative schedule of notifications; and
• through its ordinary means of contacting the joint account holders.

Question - If the customer’s ordinary method of communication is postal – are we suggesting that all the JAH notifications triggered via ‘postal’ method.

2. Please clarify what does the following 3 status for joint accounts on DH dashboards mean in the MIRO flows ?

• Sharing enabled for secondary users
• Single Consent enabled
• Joint consent enabled

3. As per the paper , understanding is pre-approval is mandatory option being referred as default option. But , the DHs have option of using co-approval method for joint accounts if they want.Please confirm if that's correct.

Also, Can a DH have a mix of set up for joint accounts - for example pre-approval on one joint account and co-approval required for one account for the same customer ?

4. Ceasing Joint account data sharing – Page 8 states –

As part of the process of removing a joint account approval or changing to a non-disclosure option, DHs MUST advise the consumer:

1. that doing this may impact existing services
2. to check with the other account holder(s) before continuing
3. when removing an approval: a. that even though sharing for this service has now stopped, the other account holder(s) can still share data from the joint account
   b. how to change their disclosure option
   We want to confirm , if the JAH removes the authorisation to share the data for a specific account – why will the other account holder still share data from the joint account as mentioned above?

5. Pending status - IF the JAH-B doesn't approve the authorisation request within the time-frame , the process of authorisation request needs to start again from beginning with JAH-A again going via ADR for that specific joint account. Please confirm if this is correct.

Overall, we agree with the recommendations from DSB team on the notification options on page 9 in terms of ‘should’ and ‘must’.

[CDR-CX-Stream]

Thanks to those who provided feedback - this consultation is now closed.

Submissions are now being considered as part of the standards finalisation process.

This thread will remain open while we respond to some of the queries raised.

[CDR-CX-Stream]

This decision was approved on 10 December 2021. The decision record can be found in the original post.

[CDR-CX-Stream]

In response to queries raised in this consultation:

Queries from @CatrinaM:

Should [notifications] sit at customer level rather than account level?

Notifications are at the account level. Rule 4A.14(3) requires data holders to offer an alternative notification schedule, which could allow the delivery of notifications to be altered and received at the customer level instead.

Is it OK to use first names on DOMS dashboard and notifications (as an example "Jon has stopped sharing his data") or should we remain generic to account holder 1, 2 etc?

It is arguable that rules references to 'account holder A' (rather than 'an account holder'), for example, may require DHs to identify the specific account holder. Community consultation suggested that identifying the specific account holder may raise privacy concerns in some instances. Data holders may identify the specific account holder in relation to the relevant rules requirement, or may deem it necessary to omit name details in certain scenarios in accordance with rule 4A.15. Please note that this is a rules issue and the above can only be taken as an interpretation provided by the DSB, who do not own rules development, compliance, or enforcement.

Our assumption is that the CDR Notifications for Joint Accounts are to be delivered via electronic means only (Email/SMS NOT Paper) Could you please confirm that this is correct?

[This also provides a response to @PratibhaOrigin's query on postal methods.]
It is arguable that if an account holder's 'ordinary means' are paper-based, the DH is required to deliver CDR notifications using this same channel. However, the definition of 'ordinary means' (in rule 1.7) specifies that a DH can agree with the account holder on a 'particular means of contacting the account holder for the purposes of the relevant provision'. The disclosure option management service and consumer dashboard must be provided online, and the DH may negotiate to provide online joint account notifications, for example, in line with this and other provisions even where the consumer receives other banking notifications via non-digital channels.

Queries from @WestpacOpenBanking:

Clarification is required on whether a Data Holder MUST provide the ability to remove approval for a specific account from an authorisation, or whether the ability for a joint account holder to remove approval for all accounts within an authorisation (that they are an owner of) also meet the rules.

The interpretation we have received is that account holders must be able to remove approvals one at a time as per rule 4A.13, and may also allow the relevant account holder(s) to streamline this (as per Pathway 2 in the CX artefacts).

Queries from @PratibhaOrigin:

Please clarify what does the following 3 status for joint accounts on DH dashboards mean in the MIRO flows ?
Sharing enabled for secondary users
Single Consent enabled
Joint consent enabled

Sharing enabled for secondary users = a secondary user instruction has been provided for the account
Single consent enabled = the pre-approval disclosure option has been applied
Joint consent enabled = the co-approval disclosure option has been applied

As per the paper , understanding is pre-approval is mandatory option being referred as default option. But , the DHs have option of using co-approval method for joint accounts if they want.Please confirm if that's correct.

That is correct - pre-approval and non-disclosure options are mandatory, and co-approval is optional to provide. The default flow in the CX artefacts demonstrates pre-approval.

Also, Can a DH have a mix of set up for joint accounts - for example pre-approval on one joint account and co-approval required for one account for the same customer ?

Yes, a DH can offer co-approval in addition to pre-approval (and non-disclosure) and a consumer may choose to have pre-approval apply to one account and co-approval apply to another account. Disclosure options apply at an account level, not a customer level.

We want to confirm , if the JAH removes the authorisation to share the data for a specific account – why will the other account holder still share data from the joint account as mentioned above?

If AH-B removes an approval for a specific authorisation (which has been initiated by AH-A), AH-A can still share data from that account in other data sharing arrangements. This is because AH-B removing an approval is different to AH-B choosing a non-disclosure option. Choosing a non-disclosure option stops all current and future data sharing from the joint account that AH-B shares with AH-A. Note also that when AH-B removes an approval for a specific authorisation, AH-A's authorisation remains active, because accounts are only associated with authorisations.

Pending status - IF the JAH-B doesn't approve the authorisation request within the time-frame , the process of authorisation request needs to start again from beginning with JAH-A again going via ADR for that specific joint account. Please confirm if this is correct.

Potentially. As noted above, accounts are only associated with authorisations, so the authorisation itself would still be active even if the joint account was not approved by AH-B. To associate the joint account with that authorisation, however, AH-B would need to provide their (co-)approval within the required timeframe. If this fails, AH-A would have to begin the process again.

The below provides a response to several related queries:
The final decision includes a revision to the notification settings standards and includes a clarification. The notification settings standards provide a non-exhaustive list of options that data holders may implement to support their compliance with the 4A.14(3) rules. The specific implementation of an alternative notification schedule and offering, which may or may not include options listed here, are at the data holder’s discretion. It is the data holder’s responsibility to ensure it is meeting its obligations under the CDR Rules. Compliance with the CDR Rules on alternative notification schedules would require, at a minimum, implementation of a combination of options (being a combination of options listed in the CX standards, other measures, or both).

[CDR-CX-Stream]

This conversation will be locked as the consultation window closed on 30 November. This issue will be closed when the decision for DP162 is reflected in a standards website release.

[CDR-API-Stream]

This decision was incorporated into release v1.15.0.

[CDR-CX-Stream]

These standards were incorporated into v1.15.0 and this issue will now be closed.