Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Noting Paper 348 - Use Case Enablement Experiment: Account Origination #348

Open
CDR-CX-Stream opened this issue Apr 22, 2024 · 11 comments
Open
Assignees
Labels
Category: API A proposal for a decision to be made for the API Standards made Category: CX A proposal for a decision to be made for the User Experience Standards Category: Noting Paper A paper outlining a specific outcome or clarification that is being posted for noting Industry: All This proposal impacts the CDR as a whole (all sectors) Industry: Banking This proposal impacts the banking industry Status: Feedback Period Closed The feedback period is complete and a final decision is being formulated

Comments

@CDR-CX-Stream
Copy link
Member

CDR-CX-Stream commented Apr 22, 2024

Context

In response to community feedback, the DSB commenced ‘experiments’ to explore speculative CDR propositions, especially in the context of actions being considered in the CDR. A simple bank account origination use case was the first experiment subject used to test and explore the CDR’s capabilities.

A report has been finalised that discusses the findings and insights generated through a government collaboration with industry, which explored how the CDR might enable mortgage refinancing.

The DSB led this experiment with the participation of accredited data recipients (ADRs), data holders (DHs), and LIXI. The experiment focused on how the CDR could enable new-to-bank customers to submit a loan product application and facilitate mortgage refinancing. A video outlining the fictional offering can be viewed online here.

To assess the most compelling opportunities for the CDR to enable this use case, the experiment group collaborated on end-to-end consumer journeys and consent designs that were tested in Consumer Experience (CX) research, and co-developed experimental standards to facilitate application population and data disclosure.

The experiment tested 4 hypotheses and identified several ways that the CDR could enable this use case. These findings included that the use case could be enabled with existing consent mechanisms and the leveraging of existing LIXI standards, with additional opportunities including further streamlining with hypothetical CDR enhancements that could include a consent uplift, a ‘warm lead’ CDR action, and voluntary CDR standards.

Report

The report has now been published and can be found below:
Simple Account Origination Experiment Report.pdf

Pages 1-12 contain an abridged version of the report. An unabridged version of the report is provided from page 13, along with other appendices relating to the experiment.

Open for Comment

While this is not a formal consultation, the DSB expects next steps to include further consultation on experimental and voluntary standards to facilitate this use case. The community are invited to provide feedback on this report, particularly the identified opportunities and next steps.

This thread will remain open for comments until COB Friday 12 July 2024 Friday 19 July 2024.

The community is also invited to propose further experiments in the DSB's new experiment repository.


Edit: Report Published: 14 June 2024
Edit: Feedback window extended to Friday 19 July 2024
Edit: Feedback closed Friday 19 July 2024

@CDR-CX-Stream CDR-CX-Stream changed the title Noting Paper <Number> - <Title> Noting Paper 348 - Use Case Enablement Experiment: Account Origination Apr 22, 2024
@CDR-CX-Stream CDR-CX-Stream added Category: API A proposal for a decision to be made for the API Standards made Status: Open For Feedback Feedback has been requested for the decision Category: CX A proposal for a decision to be made for the User Experience Standards Category: Noting Paper A paper outlining a specific outcome or clarification that is being posted for noting Industry: Banking This proposal impacts the banking industry Industry: All This proposal impacts the CDR as a whole (all sectors) labels May 23, 2024
@CDR-CX-Stream
Copy link
Member Author

The report has now been published and can be found in the original post.

This thread will remain open for comments until COB Friday 12 July 2024.

The community is also invited to propose further experiments in the DSB's new experiment repository.

@darrenbooth
Copy link

There is a massive assumption at the start that does not seem to always hold up under the current Rules: That the lender would either become a data holder of the data, or would handle data according to non-CDR protections, such as the Privacy Act and in line with their existing lending obligations.
Regarding this assumption, this is currently dependent on Rule 7.2(2)(b) “the CDR consumer has acquired a product from the person”. Acquire means to buy or obtain (common dictionary definition). At the point of the application, no product has been acquired, this seems to only occur once the application has been successful (noting that it could also be interpreted that the CDR consumer could have acquired another existing product previously from the person, which could result in all interactions with the CDR consumer falling under Rule 7.2). So for the use case to work, what changes are being proposed to address compliance obligations for the lender up to the point that the application is successful (i.e. the product has been acquired), and for compliance obligations for pending, failed or withdrawn applications, whereby a product is not acquired? I note RG5, but this does not seem to go far enough to fully enable this use case.

@darrenbooth
Copy link

Also noting the assumption that this use case only works for bank data holders, any change to the Rules to enable the use case should also consider how the use case can be applied to non-bank lenders. Non-bank lenders should not be put in a position of competitive disadvantage due to changes to Rule 7.2. This seems to go against the original objective of CDR, which was to create competition.

@CDR-CX-Stream
Copy link
Member Author

Thank you @darrenbooth for your comments. We will respond following some internal engagement which will also consider the incoming draft rules consultation content.

@CDR-CX-Stream
Copy link
Member Author

The feedback window for this report has been extended until COB Friday 19 July 2024.

@NationalAustraliaBank
Copy link

We have below clarifications from published report and hoping can get clarifications/further information.

  1. It appears that the experiment may not have considered 7.2(2)(a) of sch 3 of the Rules and simply included a consent to disclose data to the bank in accordance with the Privacy Act, is this correct?

  2. Details on how is it proposed that clause 7.2 in sch 3 would be amended will be helpful ?
    - Currently, the consumer needs to have already acquired a product with the bank and the CDR data needs to be relevant to providing that product. Is the DSB proposing that these requirements are removed or modified? Would this be for any use case or for specific use cases?
    - The proposed consent in the wireframes does not cover the items in 7.2(2)(c), what is the DSB proposing the consent should include?

  3. The drafted consent does not include the consequences of failing to agree to share the data. We believe it is an important component that should be retained in the consent process.

@perlboy
Copy link
Contributor

perlboy commented Jul 12, 2024

In the situation where a Consumer is currently at Bank A and chooses to switch to Bank B using SwitchMe app. Would 7.2 actually apply to Bank B during origination? The mere act of origination doesn't seem like it'd meet the requirement of 7.2(2)(b) in the first place ("has acquired" is past tense and there isn't a statement of "is acquiring").

Simplistically I would have thought SwitchMe app has an OSP agreement with Bank B for the purposes of disclosing CDR Data obtained on behalf of the Consumer from Bank A. This would be analogous with an aggregator/broker situation for which there is currently only Privacy Act protection? Once that initial data was submitted, the product agreed and established, the data itself effectively becomes CDR Data available for disclosure from Bank B.

@JamesMBligh
Copy link
Contributor

I think the point the report is making is that everyone is overthinking AP consents and rule 7.2 and that is actually inhibiting their use unnecessarily.

The way I see it (using the scenario that @perlboy has described) is as follows:

  1. SwitchMe gets a CDR consent from the consumer to get data from Bank A but they ask for an AP consent to share this data with other banks at the direction of the consumer
  2. SwitchMe shares the data with Bank B as part of the application process. Bank B is an ADR in this context as an accredited person receiving CDR data
  3. During the application Bank B assesses the application and offers the consumer a product. As part of that offer Bank B explains that they will become a data holder of the consumers data
  4. The consumer becomes a customer of Bank B and has their product and Bank B no longer has ADR obligations for the data provided during the application

Is any of that wrong?

Regardless, if the intention of AP consents and rule 7.2 was specifically to allow this scenario (why else do they exist), then maybe a rules clarification from the Treasury or ACCC would help.

@darrenbooth
Copy link

Without trying to read people minds on why Rules where written a certain way (although my understanding is that it was deliberately written in a way to limit its scope and use, to reduce any anti-competitive Rules that were available to some organisations but not others), Rule 7.2 is very clear that it only applies where the consumer has already acquired a product with the ADI. Rule 7.2 seems to have been written in a way to limit its use in the listed scenario - such that up to the point of the consumer becoming a customer (assuming they aren’t already a customer) the CDR data needs to be treated under the CDR Rules and not the Privacy Act.

I don’t think this is being overthought, the Rule is very clear. I assume this is why it was listed in the (not so recent) operational enhancements consultation as a future area for Rule change consultations.

@perlboy
Copy link
Contributor

perlboy commented Jul 12, 2024

@JamesMBligh Your response makes me ponder whether there is two Banks, for simplicity, both accredited in their own right, or if there is two Banks and an Independent ADR. Is this Rules discussion the same? I suspect not since one involves the expansion of use within an entity (a Bank setting up it's own product based on another banks data) while the other involves Bank A transmitting to an Independent ADR who then discloses to Bank B to acquire a product. I've always seen this as Bank B being an OSP to the Independent ADR with the service being the bank product. The experiment seems to interchange these in approach but broadly assumes Scenario 2 or I've (probably) misread something.

@darrenbooth I'd agree with the supposition that the data would be handled according to the CDR Rules during the origination process. I guess it needs to be understood where the data ceases to be CDR Data versus "bank data", available for disclosure again as CDR Data, once a product is originated. This seems much more simplified for a Bank to Bank situation.

Here's a super simplistic view with how I interpret the context for Rules vs. Privacy Act. Fundamentally customer pre-fill involves the Consumer working through a process at the Holder side (just as they would right now outside the ecosystem). I don't really see the handling of that data beyond the initial OSP handover as controversial.

image

Edit: Added possible related party disclosure for Bank B acting in it's capacity as a Data Recipient disclosing to Bank B in it's capacity as a Data Holder. Edit 2: Also added that such a disclosure may be bi-directional (initiate then share back).

@CDR-CX-Stream
Copy link
Member Author

Thanks everyone for providing your feedback and queries.

Your comments and the issues you've highlighted have been passed on to the Treasury. A DSB interpretation will be posted in this thread based on the premises of the experiment, noting that some of these are hypothetical (i.e. not possible under the current rules/standards), though the DSB intends to internally test how some existing mechanisms could be utilised to support this use case today. As noted in the paper, a use case blueprint is being developed to illustrate some of these points.

Feedback on this paper is now closed while the DSB drafts a response.

@CDR-CX-Stream CDR-CX-Stream added Status: Feedback Period Closed The feedback period is complete and a final decision is being formulated and removed Status: Open For Feedback Feedback has been requested for the decision labels Jul 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Category: API A proposal for a decision to be made for the API Standards made Category: CX A proposal for a decision to be made for the User Experience Standards Category: Noting Paper A paper outlining a specific outcome or clarification that is being posted for noting Industry: All This proposal impacts the CDR as a whole (all sectors) Industry: Banking This proposal impacts the banking industry Status: Feedback Period Closed The feedback period is complete and a final decision is being formulated
Projects
None yet
Development

No branches or pull requests

6 participants