Noting Paper 348 - Use Case Enablement Experiment: Account Origination

[CDR-CX-Stream]

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

[CDR-CX-Stream]

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]

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]

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]

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]

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

[NationalAustraliaBank]

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]

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]

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]

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]

@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.

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).