Consent and Account relationship

Context

Some data clusters do not relate to accounts. CDR consent arrangements may include only data clusters that don't relate to accounts. The reasons are:

• Sharing requests can include only data clusters that do not involve accounts. One of the core principles of the CDR is that it is both privacy enhancing and that ADRs observe data minimisation (refer to section 1.8 of the CDR Rules for its definition), asking only for the data that is required to fulfil their use case. As the CDR moves across sectors beyond just banking this is an important architecture decision
• This position supports any future fine-grained authorisation changes to the Standards
• Accounts have an associative relationship to consent. They are intrinsically related but not coupled
• At the time a Data Recipient makes a data request, the accounts that a Data Holder makes available for the customer are dependent on a variety of factors such as business rules (say an account has a fraud lock), or the account is a joint account and requires multi-party consent
• For this reason consent can be active without any associated “active” accounts at any point in time
• It makes little sense to establish consent for account-level data sharing without accounts, however the status of accounts have their own lifecycles and change over time, thus the accounts associated with the consent record may not be valid in the future at all, or for a period of time
• It is important to understand the intention is not to allow Data Holders to discretionally exclude accounts for anti-competitive reasons – consumers own the accounts and are entitled to select the accounts, unless there is an overriding business reason that prevents showing the account. This exclusion should be consistent both in internet banking channels and the CDR channel
• This means that consent is agnostic to the banking sector allowing the same associative relationship to exist in other sectors where bank accounts are not applicable

Questions

Scenario 1

• Account API was called for 2 accounts specified in the request
• Consent is valid
• One account is a part of consent
• The other one is not a part of consent

Scenario 2

• Account API was called for 2 accounts specified in the request
• Consent is valid
• Both accounts are not part of consent

Scenario 1: Does this API return “unauthorised” response, Or does the API return data for only one account and not indicate the response is partial?

Scenario 2: Does the API return “unauthorised” response, Or does the API return an empty data set?

Answer

Both of these scenarios can be treated as equivalent.

Let’s assume HappyADR is connecting to FriendlyDH and the consumer has established a consent agreement with both parties represented as consent-abc ---is associated with---> {account-123, account-345} but not with {account-567, account-789}.

When returning a list of accounts without specifying an accountId explicitly, the data holder must return the list of accounts that are associated with the consent record which are currently valid to do so. In our example, this is {account-123, account-345}.

If an accountId is specified in the URI or as a filter in a request but it is not associated to the consent, then the correct response should be 422 Unprocessable Entity. In our example, let’s assume that HappyADR is calling Get Balances For Specific Accounts with accountId=account-567. In this instance, the account requested is not associated with the current consent, and FriendlyDH would reply with a 422 error.

Now if HappyADR requests a service that has a list of accounts and the request comes for {account-345} and {account-567}:

• If the ADR is requesting both accounts, so {account-345, account-567} then they were (i) previously provided these two account IDs by the DH, or (ii) the ADR is providing a bogus/malicious request
• Assuming (i), if any or all of the account IDs are no longer accessible but they were previously provided they would no longer be associated with the consent

In either (i) or (ii) the correct response is to return a 422 error with an error payload indicating the specific IDs that are invalid, along with error code 0001.

See https://consumerdatastandardsaustralia.github.io/standards/#tocSresponseerrorlist  for error payload structure.

See

• Maintenance Issue 117
• Error Payload Structures