Withdrawal of a SUI by an Account Holder leaving an "Empty" Authorisation

[rob-hale]

Description

Consider the situation where a Secondary User (SU) has created a data sharing arrangement that encompasses:
a) account(s) that are owned by that SU, and
b) account(s) owned by another account holder - courtesy of a Secondary User Instruction (SUI).
If the other account holder now removes the SUI, how should the arrangement be represented in the dashboards of the respective parties? This matter is further complicated where the SUI relates to a Joint Account (JA).

Area affected

1. We assume Jane would not be able to withdraw Sue's authorisation because she wasn't the requester of it.
2. Jane can withdraw the approval though - that's the 2UI - the instruction. What should happen to the status of the arrangement if she does?
3. If we decide that the arrangement should become inactive then what happens to data sharing on Sue's account which is still valid under the same arrangement?
4. If the arrangement disappears for Jane, but remains active and visible for Sue, that wouldn't appear to meet OAIC privacy requirements in respect of showing prior arrangements.
5. So should a new status be presented in this scenario - something like Suspended or Disabled?
6. The rules also permit the SUI to be reinstated, at which point data sharing should be possible once again.
7. There is a similar scenario in DOMS for a Joint Account that transitions from pre-approval to non-disclosure with an existing authorisation in flight. The arrangement is still active but potentially no accounts would be visible. This could then revert. All the while, the arrangement would still exist.

New item or change proposed

Please provide guidance in terms of how to manage the status and visibility of arrangements in these situations and the recommended CX.

---

⚠️ Disclaimer ⚠️
The CX Guidelines provide optional implementation examples for key rules, standards, and best practice recommendations.

They demonstrate key aspects of the consent model, but certain areas may be considered out of scope. This may include, for example, where the rules and/or standards are silent or non-prescriptive to provide CDR participants with flexibility or discretion according to their own systems or protocols.

❗The CX Guidelines span policy, rules, standards, and best practice, so requests will be considered on a case by case basis and timings may not fall within a Maintenance Iteration cycle.

Importantly, the CX Guidelines are optional to follow, but the CDR rules require CDR participants to have regard to them. The CX Standards differ in that they are binding data standards that must be followed.

[nils-work]

Hi @rob-hale

I just wanted to add a few comments in the hope of clarifying some of your points or possibly to help reveal other issues.
Happy for any feedback, or to be corrected on any misunderstanding of your scenario or the rules.

1. We assume Jane would not be able to withdraw Sue's authorisation because she wasn't the requester of it.

Correct, to my understanding

2. Jane can withdraw the approval though - that's the 2UI - the instruction. What should happen to the status of the arrangement if she does?

I think the 'approval' and the 'instruction' that you've referred to, are two different things:

• Rule 1.15(5)(b)(i) describes functionality that allows an account holder to 'give the indication' (I think this has been called an 'approval' in Implementation calls, as it has some similarity to the JA 'approval removal') that they no longer approve of that account being shared to 'that accredited person', which is further detailed in Rule 4.6A(a)(ii).
• Rule 1.15(5)(b)(ii) describes an 'instruction', which is further detailed in 1.13(1)(e).

Following the scenario though, neither withdrawing the 'approval' (by which is giving the 'indication' that the account holder no longer approves of sharing) or withdrawing the secondary user instruction would affect the status of an arrangement as it appears to the requester***.

Changing the 'approval'/indication, or instruction may also not affect the accounts that appear in arrangements on dashboards (though they might now be labelled 'Not sharing'), but the settings would affect the accounts that are returned in endpoints.

***As there are multiple users involved in secondary user and joint sharing, there needs to be differences in how the status of arrangements appear from different viewpoints (for the different user dashboards, plus the endpoints for the requester).
This type of difference is already expected where relevant account holders are not able to see accounts and other scope details that do not relate to them, for example.

3. If we decide that the arrangement should become inactive then what happens to data sharing on Sue's account which is still valid under the same arrangement?

The arrangement should continue to appear 'Active' on Sue's dashboard and data would continue to be disclosed for her individual account (but not for the account where the 'dis-approval' indication was given, or the instruction withdrawn), but if Jane no longer had an association to that arrangement, it would appear as 'Inactive' or 'Archived' on her dashboard.

4. If the arrangement disappears for Jane, but remains active and visible for Sue, that wouldn't appear to meet OAIC privacy requirements in respect of showing prior arrangements.

The arrangement should appear as 'Inactive' to Jane, where it could still be associated with the historical details of sharing (CDR receipt etc.)

5. So should a new status be presented in this scenario - something like Suspended or Disabled?

I'm not sure how much difference an additional 'in-between' state would help for users, but this could be considered to be in the competitive space.

6. The rules also permit the SUI to be reinstated, at which point data sharing should be possible once again.

That's correct, and that could make the arrangement return to the 'Active' state again for Jane.
It could have always been 'Active' for Sue, but when the instruction is reinstated, it would allow the account to start sharing through the endpoints again, and the 'Not sharing' label on that account on her dashboard could be removed.

7. There is a similar scenario in DOMS for a Joint Account that transitions from pre-approval to non-disclosure with an existing authorisation in flight. The arrangement is still active but potentially no accounts would be visible. This could then revert. All the while, the arrangement would still exist.

That's correct and the requester and relevant holders could have different views on their dashboards, as is the case for secondary users.

Does all of that seem to make sense?

[rob-hale]

Hi @nils-work - sorry I remember seeing this just before the holiday break and then forgot to come back and comment :(
Your responses help - thank you! I think what we're starting to clarify is that a single arrangement can indeed have multiple statuses based on who is viewing the arrangement. I think that will work, maybe we need to test that out and see if we unearth any additional challenges along the way...

[CDR-CX-Stream]

@rob-hale a knowledge article relating to this request has now been published here: https://cdr-support.zendesk.com/hc/en-us/articles/6589715324047

This article was developed in collaboration with other CDR agencies. We will now begin developing accompanying CX guidelines. The knowledge article refers to existing guidelines for joint accounts that could also be used as a reference.

[CDR-CX-Stream]

Considering the ongoing Operational Enhancement Consultation, specifically addressing the Secondary User Instructions (SUI) component of this Change Request, we recommend advancing this ticket to incorporate CX guidelines related to joint accounts for this MI and carrying this ticket forward to the next MI to include guidelines for secondary user sharing. We welcome any feedback you may have on this.

[CDR-CX-Stream]

As discussed on the last MI call, the proposed CX guidelines focusing on the joint account scenario of this change request can be accessed using this figma link. We invite any feedback on the proposed guidelines.

Also noting, the secondary user sharing component of this ticket will be addressed in the next MI.

--Update: 11 April 2024---
Final cx guidelines and supporting artefacts have now been published in the cx guidelines website.