Guidance for accounts becoming unavailable

[nils-work]

Description

Discussion in recent Implementation and Maintenance calls has suggested that guidance may be required for situations where accounts that have previously been shared become unavailable.

Intention and Value of Change

To provide clarity and a consistent experience for Data Holders and Data Recipients.

Area Affected

• Guidance, incorporating any relevant Rules and Technical requirements
• Standards if required.

Change Proposed

Provide guidance for questions/situations including:

1. What is the expected behaviour of the Get Accounts endpoint when a previously authorised account becomes unavailable for sharing?
   1. Reasons may include:
      1. Account was closed more than two years ago (limit of required sharing)
      2. Authorising user loses Nominated Representative status (for a Non-Individual Consumer)
      3. JA DOMS set to non‑disclosure option, JAH removed from account, or avoidance of harm measures applied to account
      4. Secondary user instruction withdrawn
      5. Fraud or similar flag applied
      6. Consumer modified the authorised accounts without following the ADR amendment flow (if the Data Holder provides this capability)
2. What is the expected behaviour of the following endpoints in those situations:
   1. Get Account Detail (with accountId in path)
   2. Get Account Balances (with account list in post body)
   3. Get Transactions for Account (with accountId in path)
3. What is the difference between:
   1. Unavailable Banking Account (account temporarily unavailable)
   2. Invalid Banking Account (account permanently unavailable)
4. Should ADRs use any of these signals (errors or absence of a previously received account) as a trigger to delete or de-identify collected data for that account?
5. Consent without accounts, eligibility and revocation:
   1. Can a consumer create an authorisation without accounts?
   2. If an arrangement initially includes accounts, but all accounts subsequently become unavailable, should the Data Holder revoke the arrangement?

Current guidance related to these topics for reference:

• CX guidance: Unavailable accounts
• Error scenarios and responses > Accounts
• Guidance on closed accounts
• Consent and Account relationship
• Consent with no attached accounts
• Blocked or suspended accounts and temporarily locked accounts: consumer eligibility and refusals to disclose data
• Clarification on closing an account
• Consent on closed accounts
• Data sharing on closed accounts
• Authorisations when a joint account holder is removed from or added to a joint account
• Authorising a Joint Account that is disabled by one Joint Account Holder
• Expected CX Behaviour for Closed Accounts
• Invalid or unavailable energy account in request: 404

[perlboy]

Add in Dashboard behaviours too, should a Consumer who is either ineligible or has accounts which are ineligible be able to access the consent dashboard?

[markskript]

It appears the guidance at https://cdr-support.zendesk.com/hc/en-au/articles/5729181240591-Error-scenarios-and-responses#Accounts might already cover this scenario?

Accounts that cannot be shared: 404, 422 In a call to the Get Accounts API, the DH should return only the list of accounts that can be shared. If an account is not shareable it must not be returned in the accounts list. For API calls that specify multiple accounts, where a request specifies an accountId that is not shareable, then an error must be returned.

If that is the current guidance, then I assume that if a DH provides an account in the Get Accounts API list, but that account isn't actually available (returning a 422) then they are in compliance breach as the account should NOT have been included in the Get Accounts API listing.

Is that the correct interpretation?

[markskript]

@nils-work @markverstege can I please get some guidance on whether my interpretation above is correct from a standards perspective before I start raising compliance issues? It's my understanding that if an account becomes unavailable after consent was established (for example, the nom-rep status was revoked) then that account SHOULD NOT appear in the list of accounts return via the Get Accounts API.

If that is correct then I'll close this CR

[nils-work]

Hi @markskript

Your interpretation appears to be correct.

The guidance is -

In a call to the Get Accounts API, the DH should return only the list of accounts that can be shared. If an account is not shareable it must not be returned in the accounts list.

[markskript]

Thanks @nils-work . We will reference this guidance in a number of compliance cases with DH's.

I'm happy for this CR to be closed.