Enhancing CDR Adoption: Streamlining Account Selection and Improving Data Transparency

[kambasiq]

Description

Currently, the CDR framework allows consumers to select specific accounts to share with Accredited Data Recipients (ADRs) as part of the flow managed by DHs. While this granular control is beneficial for consumer privacy, it poses a challenge for businesses transitioning from screen scraping to CDR. Screen scraping enables access to all accounts upon successful authentication, whereas CDR requires explicit selection, potentially leading to incomplete data sets. This discrepancy can hinder the adoption of CDR by businesses, particularly those relying on comprehensive financial data for services like affordability assessments. Additionally, inconsistencies in the user experience across different banks, such as the presence or absence of a "select all" option, can further complicate the process.

Intention and Value of Change

The proposed changes aim to streamline the account selection process for consumers and enhance data transparency for ADRs, ultimately promoting greater adoption of CDR.

• Improved User Experience: Clear and consistent user interface elements, including a prominent "select all" option, would simplify the account selection process, reducing friction and enhancing consumer experience.

• Data Completeness: Ensuring ADRs have a reliable indication of whether all available accounts have been shared would allow them to make informed decisions about data usage and service provision. This would mitigate risks associated with incomplete data sets and facilitate a smoother transition from screen scraping. ADRs can highlight the fact that the user hasn't selected all their accounts and send them back through the process.

• Increased CDR Adoption: By addressing the challenges associated with account selection and data transparency, these changes would encourage more businesses to embrace CDR, driving innovation and competition in the financial services sector.

• Alignment with priority use cases: As mentioned by Stephen Jones MP on the address for revamping CDR, Consumer Lending and Borrowing is a high value use case and without these changes it would be difficult to use CDR for this use case.

  Area Affected

• Consumer Experience (CX) Guidelines: Specific recommendations would be incorporated into the CX guidelines to standardise the account selection user interface across different banks. This will be a "must have" requirement.

• Data Standards: Modifications to the GetAccounts endpoint would include metadata fields indicating whether all available accounts have been shared.

Change Proposed

Add a new attribute called "availableRecords" to the "meta" object of GetAccounts end point. This then indicates the number of accounts that were available for sharing, the existing "totalRecords" will always be equal or less than the "availableRecords" and based on this the ADR would know if everything was shared or not.

[nils-work]

Hi @kambasiq

This seems to be related to #584 - Flag for account(s) not shared, which was wrapped into this future plan request: #130 - DSB Item - Ability for ADR to request all accounts or identify missing accounts.

#183 - Decision Proposal 183 - Purpose Based Consents may also be related.

[kambasiq]

@nils-work the topic seems to be similar but the suggested soluitions are different, also this one has a CX element of getting DHs to implement a select all bank account UI element for consumers. The purpose based consent piece is interesting but it seems like a bigger change and might take a long time to implement, has it progress from your side at all?

[CDR-CX-Stream]

Hi @kambasiq - this proposes CX guidelines changes and an endpoint change, but not a CX standards change.

The CX guidelines are optional to follow, however your proposal appears to include a requirement for DHs to implement a 'select all' action for account selection. If that is correct it would be a new CX standard that would appear here.

Are you able to clarify if that is the intended proposal?

[kambasiq]

@CDR-CX-Stream, It proposes two changes: First one to the end point so the ADR knows the consumer didn't share all their accounts so they can intervine and make it clear to the user that they need all the accounts.

Second one is a UI change to DHs account selection screen, some banks already do this but some don't. Would be great to have a consistent exprience where a consumer can easily indicate they want to share all their accounts and be able to select all their accounts in that screen with a single click/tap.

[CDR-CX-Stream]

Thanks @kambasiq - I take that to mean it is a request for CX guidelines to recommend select all functionality, which DHs can implement voluntarily, and not a proposal for CX standards to require that DHs implement select all functionality. We can progress the CX guideline portion quite easily. Thanks for the clarification.

[markskript]

It proposes two changes: First one to the end point so the ADR knows the consumer didn't share all their accounts so they can intervine and make it clear to the user that they need all the accounts.

We appreciate the use-case here, but it's my understanding that this would need to be a rules change as was discussed on the last MI call. The current data that is in scope for CDR is defined in Schedule 3 of the rules. The concept of "the consumer has more accounts than they consented to" is not listed as a piece of data that is currently available through the CDR.

M.

[kambasiq]

It proposes two changes: First one to the end point so the ADR knows the consumer didn't share all their accounts so they can intervine and make it clear to the user that they need all the accounts.

We appreciate the use-case here, but it's my understanding that this would need to be a rules change as was discussed on the last MI call. The current data that is in scope for CDR is defined in Schedule 3 of the rules. The concept of "the consumer has more accounts than they consented to" is not listed as a piece of data that is currently available through the CDR.

M.

Hi Mark, wouldn't this be a perfect example of a situation where the CDR as it stands is not fit to support one of the high priority use cases called out by Stephen Jones? who would escalate this to the broader CDR program?

[markskript]

Hi Mark, wouldn't this be a perfect example of a situation where the CDR as it stands is not fit to support one of the high priority use cases called out by Stephen Jones? who would escalate this to the broader CDR program?

Hi Kam,

Not disagreeing or agreeing - just stating that the API change would be a rules change, which isn't something the DSB can action through standards maintenance. I believe Rules feedback goes via CDRRules@treasury.gov.au but I'm sure someone from the DSB/ACCC can confirm.

The CX change would be something that could be looked at via standards maintenance I believe and I'm in support of that.

M.

[kambasiq]

Hi Mark, wouldn't this be a perfect example of a situation where the CDR as it stands is not fit to support one of the high priority use cases called out by Stephen Jones? who would escalate this to the broader CDR program?

Hi Kam,

Not disagreeing or agreeing - just stating that the API change would be a rules change, which isn't something the DSB can action through standards maintenance. I believe Rules feedback goes via CDRRules@treasury.gov.au but I'm sure someone from the DSB/ACCC can confirm.

The CX change would be something that could be looked at via standards maintenance I believe and I'm in support of that.

M.

Mark, wouldn't it make more sense for DSB to escalate this to the Treasury? It seems like a broken process if we have to engage with different CDR teams in government to progress the viability of CDR for use cases.

[CDR-CX-Stream]

Discussion on this issue in the MI call October 2 included:

• Technical request tied to future planned work: #183 - Decision Proposal 183 - Purpose Based Consents and #130 - DSB Item - Ability for ADR to request all accounts or identify missing accounts

• CX request: DSB stated that the existing CX standard (Authorisation: Account selection functionality) and CX guidelines (Authorisation to disclose, Default example) already allow and show 'select all' functionality. Updates to the CX Guidelines for account selection are in progress to further clarify the ability for DHs to implement 'select all' functionality.

• DSB noted that CX Guidelines are optional to implement and while they are not mandatory, the rules indicate that CDR Participants must have regard to them.

• Basiq stated that making it mandatory for data holders to include the 'select all' function would be preferred

• Action: Community to provide views on a mandatory 'select all' functionality in account selection

[CDR-CX-Stream]

As requested by @kambasiq on the MI21 call on October 2, the DSB is elevating the CX portion of this issue to a request for a CX standard that requires all data holders to include an ability for the consumer to 'select all' their accounts during the authorisation flow.

Community feedback is sought on this change.

[CDR-CX-Stream]

The DSB has developed draft CX Guidelines (see this link) demonstrating how data holders may, under the existing CX standards, voluntarily implement 'select all' functionality for account selection.

These draft guidelines also demonstrate the voluntary CX standard that allows data holders to implement additional functionality where a large number of accounts are presented at this step.

We invite the community to provide feedback on these draft guidelines, which would be published on the Authorisation to disclose page of the CX Guidelines website pending further consultation as part of maintenance iteration 21.

We also continue to encourage the community to provide feedback on the adjusted proposal to make select all functionality mandatory for data holders to implement, as per this comment.

[CDR-API-Stream]

Hi @kambasiq, in relation to the first change being proposed in this issue:

Add a new attribute called "availableRecords" to the "meta" object of GetAccounts end point. This then indicates the number of accounts that were available for sharing, the existing "totalRecords" will always be equal or less than the "availableRecords" and based on this the ADR would know if everything was shared or not.

The first change described above cannot currently be supported because it does not satisfy the rules for privacy considerations.

The CDR gives consumer the rights to control and choose what CDR data they wish to consent to share with an accredited person. This is supported by the CDR Rules – for example, under rule 4.11(1), an accredited person must allow the consumer to choose the types of CDR data they wish to share. Disclosing whether the consumer did not share all accounts and how many accounts they did not disclose could result in consumer harm especially where non-disclosure is for the protection of vulnerable consumers. As this could result in privacy concerns and potential consumer harm, further investigation is required to surface any related risks.

In addition to CDR rules related to privacy entities subject to the Privacy Act should be aware of their obligations under the Australian Privacy Principles (APPs) including APP3 - collection of solicited personal information and APP6 – Use or disclosure of personal information.

Given the use case relates to responsible lending, it is worth noting the Privacy Act also contains strict rules about how personal information must be handled. More information about the interaction between the CDR and the Privacy Act including credit reporting can be found here - Consumer Data Right and the Privacy Act | OAIC.

Noting that the second half of this issue is being progressed as a potential CX Standard, it is also worth considering purpose-based consent in future which may direct the Data Holder to share by default certain data clusters, products or account types. Provisions to allow the consumer to make choices to change those default settings during authorisation may remain an important design consideration.

[kambasiq]

Hi @kambasiq, in relation to the first change being proposed in this issue:

Add a new attribute called "availableRecords" to the "meta" object of GetAccounts end point. This then indicates the number of accounts that were available for sharing, the existing "totalRecords" will always be equal or less than the "availableRecords" and based on this the ADR would know if everything was shared or not.

The first change described above cannot currently be supported because it does not satisfy the rules for privacy considerations.

The CDR gives consumer the rights to control and choose what CDR data they wish to consent to share with an accredited person. This is supported by the CDR Rules – for example, under rule 4.11(1), an accredited person must allow the consumer to choose the types of CDR data they wish to share. Disclosing whether the consumer did not share all accounts and how many accounts they did not disclose could result in consumer harm especially where non-disclosure is for the protection of vulnerable consumers. As this could result in privacy concerns and potential consumer harm, further investigation is required to surface any related risks.

In addition to CDR rules related to privacy entities subject to the Privacy Act should be aware of their obligations under the Australian Privacy Principles (APPs) including APP3 - collection of solicited personal information and APP6 – Use or disclosure of personal information.

Given the use case relates to credit decisioning, it is worth noting the Privacy Act also contains strict rules about how credit providers and credit reporting bodies must handle personal information. More information about the interaction between the CDR and the Privacy Act including credit reporting can be found here - Consumer Data Right and the Privacy Act | OAIC.

Noting that the second half of this issue is being progressed as a potential CX Standard, it is also worth considering purpose-based consent in future which may direct the Data Holder to share by default certain data clusters, products or account types. Provisions to allow the consumer to make choices to change those default settings during authorisation may remain an important design consideration.

Is there an actual legal advice that reads "indicating a consumer has 3 accounts and only has shared 2, with no additional information about the accounts not shared, is considered private information under privacy law". This seems like an arbitrary read of the rules because if the rules are this strict then we should have a scope for every single field in CDR APIs so the consumer can "select what CDR data they want to share".

Would be good to get some actual legally framed statement on how this disclosure can be harmful and which Australian Privacy Principals covers this. I am not sure how credit decisioning got mixed up with affordability assessment for responsible lending purposes?

I think it is important to get really transparent feedback on the following questions/statements from the CDR program and without introducing unnecessary and somewhat irrelevant concepts:

• How does the CDR program sees CDR data being used for responsible lending as one of the three high priority use cases without ADRs being able to at least be notified that the consumer is not sharing everything? we are not asking for any hint of what is not being shared? we just want to be able to halt the progress of the application process and hand off to a manual process for more scrutiny.
• If the only solution CDR program sees is a "Purpose based consent" that will take years to implement and in which the ADR gets to make requests that limits the ability of the consumer to reduce the scope of what they share via banking screens, how would that be any different with your assessment of my requests so far? is it going to be achieved by additional consent on ADR side? if so then why can't we just ask for that consent now? We could simply add a declaration tick box to our existing screen that says "I acknowledge that I need to share all my bank accounts via CDR to progress with my lending application, DHs will inform the [ADR] if I fail to do so"
• In general the way the real world works is that a service provider informs a consumer that they need a series of information before a consumer can make use of their service, if the consumer is unhappy about sharing the information they will look for another service provider who doesn't ask for them or they would complain to the relevant government body if they believe it is unreasonable. The precedent we are setting here is to break this real life model by introducing an ability for consumer to agree to share the needed data for getting the service but then through banking screens opt out from sharing the data they agreed to share.

[CDR-API-Stream]

Hi @kambasiq, thanks for the comment.

I am not sure how credit decisioning got mixed up with affordability assessment for responsible lending purposes

Thanks, the comment has been corrected.

I think it is important to get really transparent feedback on the following questions/statements from the CDR program

These questions are policy related in nature so the DSB has passed them onto the Treasury rules team for consideration. We also encourage you to reach out to Treasury's CDR rules team. You can reach them via their mailbox: CDRRules@treasury.gov.au.

[CDR-CX-Stream]

The DSB will publish CX Guidelines demonstrating how data holders may, under the existing CX standards, voluntarily implement 'select all' functionality for account selection, in response to the original request for CX changes. View the proposed Guidelines here.

As per this comment on the adjusted proposal to make select all functionality mandatory for data holders to implement, the CX team will conduct further analysis alongside other consent drop-off concerns.