-
Notifications
You must be signed in to change notification settings - Fork 56
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
Comments
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. |
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. |
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. |
Thank you @darrenbooth for your comments. We will respond following some internal engagement which will also consider the incoming draft rules consultation content. |
The feedback window for this report has been extended until COB Friday 19 July 2024. |
We have below clarifications from published report and hoping can get clarifications/further information.
|
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. |
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:
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. |
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. |
@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). |
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. |
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 2024Friday 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
The text was updated successfully, but these errors were encountered: