The Developer’s View of Consent Management Flow of Consumer Data Standards for Banking in Australia

Managing consent given by the consumer to share the consumer data with Data Recipient is important aspect of Consumer Data Right legislation. This article provides a detailed view of each interaction of the consent flow from a developer perspective.

Prerequisites with Data Recipients

In order to receive data from a Data Holder there are two prerequisites. Data Recipients need to register themselves manually with ACCC and need to become accredited as the first step. This includes registeration of their software products with ACCC. Only Accredited Data Recipients (ADR) is able to participate in CDR eco system.

Then ADR need to register them selves with the Data Holder using their registration API. In order to register them selves, they need to get a SSA (Software Statement Assertion) from ACCC the register and present that to the Data Holder on the registration request. Registration response will contain the dynamically generated identifier for the ADR Software Product issued by the Data Holder. These interactions are shown graphically below.

Data Request Initiation

ADR will initiate an authorization request on the Data Holders authorization endpoint. The authorization request should comply with OIDC 1.0 standard and need to be further constrained by FAPI-RW profile.

Standard OIDC Authorization Request is shown below with request encrypted.

https://localhost:8243/authorize/?<payload>&response_type=code%20id_token&client_id=__VNF_K3ie4cG6W1yaQ9iiDI2bMa&scope=openid%20bank:accounts.basic:read%20bank:accounts.detail:read%20bank:transactions:read%20bank:payees:read%20bank:regular_payments:read%20common:customer.basic:read%20common:customer.detail:read&redirect_uri=http://google.com

when payload decrypted the content looks below.

“acr” claim defines the Level of Assurence required for this operation.

Single Ordinal

A Single LoA value is carried in the acr claim which is described in section 2 of [OIDC].

• An LoA of 2 is represented by the URI: urn:cds.au:cdr:2
• The authenticator used to attain this level MUST conform with the Credential Level CL1 rules specified under the Trusted Digital Identity Framework [TDIF] Authentication Credential Requirements specification.
• An LoA of 3 is represented by the URI: urn:cds.au:cdr:3
• The authenticators used to attain this level MUST conform with the Credential Level CL2 rules specified under the Trusted Digital Identity Framework [TDIF] Authentication Credential Requirements specification.

READ operations SHALL only be allowed where at least an LoA of 2 has been achieved during the establishment of consent.

WRITE operations SHALL only be allowed where:

• At least an LoA of 3 has been achieved during the establishment of consent, or
• At least an LoA of 2 has been achieved during the establishment of consent and a subsequent challenge/response has resulted in an LoA of 3 being achieved within the lifespan of the current Access Toke

Requesting Sharing Duration

To facilitate the specification of the duration for consent to share CDR data that is approved by the consumer, a mechanism for the Data Recipient to specify a sharing duration to the Data Holder is required.

To accomplish this, the Data Holder MUST support an additional claim in the authorisation request object named sharing_duration. The sharing_duration claim MUST be handled as follows:

• The value of the sharing_duration parameter will contain the requested duration for sharing, in seconds.
• If the sharing_duration value exceeds one year then a duration of one year will be assumed.
• If the sharing_duration value is zero or absent then once off access will be assumed and only an Access Token (without a Refresh Token) will be provided on successful authorisation.
• If the sharing_duration value is negative then the authorisation should fail.

Note that the period of one year in the above statements should be interpreted as 365, 24 hour days (or 31,536,000 seconds).

The Data Recipient is able to obtain the expiration of sharing via the sharing_expires_at claim.

Data Holder will redirect the consumer to the login page of the Data Holder’s digital experience. Consumer will be authenticated by the digital experience and may use Multi-Factor Authentication. Digital experience might need to check on additional policies like joint accounts and minors logging in etc.,

As an example Consumer Data Right Rules Framework defines following for Minors.

The Open Banking review did not make specific recommendations on whether consumers who are minors should be able to consent to sharing their data, although the ACCC understands the issue has been raised in consultations.

The ACCC notes that there are many banking products which are either promoted for minors or available to minors. Minors over a certain age (often 12 or 14) are able to transact on an account without the consent of a parent or guardian, although the parent/guardian may be able to limit the level of funds at their disposal. Additionally, the Privacy Act does not set out a specific age at which minors can consent to share their personal information. Guidelines on the Australian Privacy Principles (APPs) suggest though that by the age of 15 a minor would have sufficient understanding and maturity to do this he ACCC does not propose to make rules that will treat minors differently to any other consumer who may take advantage of the CDR.

User will be moved to the “Consent Page” of the digital channel after successful authentication as shown below.

The Open Banking review recommended that a consumer’s consent must be explicit, fully informed and able to be permitted or constrained according to the consumer’s instructions.79 The Open Banking review found that consumers need to be confident that the CDR is focused on giving them control of their data, as without this confidence, consumer take-up of the CDR will be limited and the initiative may not achieve its policy objectives.80

The government reiterated the importance of genuine consent for the CDR regime, stating that consumers should be able to understand what they are consenting to, and that consents should be clear and unambiguous, and not open ended.81 While the Open Banking review specifically recommended that consent be explicit, fully informed and able to be permitted or constrained according to the consumer’s instructions, it also supported an expanded list of features, which were called for by a wide range of stakeholders:

 consent should be freely given by the consumer

 a consumer’s consent should be express

 consumer consent should be informed

 the consent obtained should be specific as to the purpose of sharing data, that is, the uses to which the data will be put

 consent should be time limited

 consent should be able to be easily withdrawn with near immediate effect.

Permission details requested are extracted from the scope definition of the authorization request as shown below.

This UI flow need to be governed by the Consumer Experience Standards as shown below.

After consent is given Data Holder will return the authorization code back to the Data Recipient. Data Recipient will make a token request to the token endpoint on the Data Holder. The flow is shown below.

After providing consent the decision has to be persisted by the Data Holder in consent history data store and consumer should be able to see the history through consent dashboard.

Important Features of Consent Mandated by CDR Rules Framework

The Framework indicates that collection, use and disclosure of CDR data by CDR participants will require express consent from consumers. Comparisons have been made to the rigorous consent requirements under the GDPR. However, the new CDR regime actually appears to go beyond the GDPR’s ‘lawful basis’ test, by requiring express consent without permitting entities to rely on any other basis for using data (eg where necessary to perform a contract with the relevant individual).

• Express and specific — Under the Framework, consents obtained from consumers should permit the consumer to specify their consent to:
• the scope of data provided;
• the uses to which the data is put; and
• the duration of time over which the data is made available and held (eg entities will not be able to seek an ongoing, indefinite consent to access and use a consumer’s data, with the ACCC suggesting it could limit this period to 90 days — similar to the EU’s Revised Payment Service Directive, known as ‘PSD2’).
• Unbundled — The rules will include a specific prohibition on bundling CDR consent with any other direction, permission or agreement. This reflects the recent, global legislative shift towards specific, unbundled consent. However, it is also likely to increase the cost and difficulty for entities in preparing consents (as consumers will need to be shown, and agree to, a greater number of consents), and will require that businesses consider all of their intended uses of CDR data in advance.
• Opt-in model — The Framework suggests that the rules will prohibit the use of ‘opt-out’ style consents (eg use of pre-ticked boxes or default settings) and specifies that implied consent will not be sufficient to satisfy an ADR’s obligation to obtain consent.
• Withdrawal process — The ACCC will develop rules to provide consumers with a simple process to withdraw consent. ADRs and data holders will be required to develop an interface or dashboard that outlines historical and current consents and authorisations, to permit individuals to easily withdraw consents. Once a consumer’s consent is withdrawn, all CDR data that an ADR (or its contractors or service providers) holds must be deleted or de-identified.

Consent given has following relationship between ADR and the consumer.

A consumer can be an Agent of an organization or an individual account holder.