Flag for account(s) not shared

[jimbasiq]

I am sure this has been discussed but I can't find the reference so raising this ticket to confirm

Description

Many data recipients are using CDR Open Banking data to make a lending decision. In order to make a "good" decision and lend responsibly they need a full financial position for a consumer. Therefore there is a requirement for the data recipient to be informed when a consumer has chosen not to share account information for accounts they could potentially share. This requirement protects both the consumer and the lender.

Area Affected

A consumer correctly gets to select the accounts they wish to share with a data recipient. This ability enables them to not share all their accounts even if a data recipient has asked them to do so in order to make a fair lending decision.

Change Proposed

As the consumer has elected not to share certain accounts we obviously cannot share any account information. Proposal is for the ResponseBankingAccountListV2 to contain a null value in the accounts array for each account that could have been shared but was not.

[perlboy]

Forget about Standards, this proposal seems to overreach on the Rules. A Consumer hasn't consented to a Holder disclosing that they haven't consented to something (yes, that's data too). There is no scope or permission language in place for this. Further, this provides limited benefit because the Consumer could have many other accounts at many other Holders so the value proposition for a Data Recipient being pitched here is invalidated.

The reasonable alternative here would be to instead initiate arrangement requests with a requirement for all accounts to be shared (similar to the difference between essential and optional claims in OIDC). At that point the Recipient would need to decide whether they want to risk losing the Consumer entirely or accept the Consumer can choose what accounts. It doesn't solve the multiple Holder problem but at least it makes it explicit about the desire of the Recipient.

This request seems to be attempting to expand the CDR into a quasi credit reporting agency, which, it isn't. Ultimately, if the Recipient hasn't established enough trust with a Consumer to share all their accounts that's really the recipients problem not the consumers. This type of choice for consumers is another advantage over screen scraping.

[markskript]

I concur with @perlboy - the fact that there were accounts that were not consented to is information in its own right that would need to be consented to. Even if something like this was implemented I don't believe it would achieve the end result you are searching for as it wouldn't be multi-institutional and someone could just 'hide' another account with a different ADH.

[jimbasiq]

@perlboy 's suggestion to initiate arrangement requests with a requirement for all accounts to be shared would solve for the use case I have proposed.

@markskript you are correct, not disclosing a separate data holder is a separate but similar issue.

[nils-work]

Hi @jimbasiq For reference, that type of concept was discussed in Decision Proposal 183 - Purpose Based Consents.

[damircuca]

Hey Peeps

I wanted to provide some additional context regarding a request above. Giving the consumer the ability to select which accounts they want to share enables them to break every possible use case. For e.g. imagine using a personal finance management app and deciding to share only your term deposit account - this renders the app useless. Or let's say you apply for a loan and share your travel card instead - pointless. Similarly, using a round-up app and sharing your mortgage account would also be pointless.

The problem lies in the fact that consumers don't have visibility into what types of accounts the application (the value provider) requires access to. They cannot see the underlying code or determine the correct combination of accounts needed to ensure the app functions properly.

While I understand the idealistic approach to data sharing, we need to be pragmatic about this issue. Companies invest significant resources into persuading users to download their apps, only to hand them over to data holders without any means of tracking conversion drop-offs or ensuring the data they need to service the consumer is complete.

In hindsight, I think this was a really big missed opportunity that should have been given more consideration. Perhaps we should have utilised scopes better, as they are ideal for permission-based exchanges of data required to fulfil specific use cases.

Also note that one of the primary use cases for open banking is to facilitate lending. If we cannot effectively support the lending process, what chance do we have of achieving success? While I agree that use case-specific consents are a ~bad~ poor idea, we should figure out how to ensure that once a consumer has given consent to share their data - that they can successfully complete the process.

It's a fundamental design principle: we should not create a system that allows consumers to make mistakes.

[ShaneDoolanAdatree]

Adatree supports the approach recommended by @perlboy as a long term approach. The multiple Data Holder problem is something that can already been solved by transactions and payee analysis so we don't see that as a barrier here. Granted, this can also be used to find omitted accounts at the same Data Holder, but in our experience, as heavy users of the Trusted Advisor access model, the consumer omitting accounts is often a mistake or deception, and that forcing re-consent is the rectification process. This is a costly process for all involved.

Requesting a consumer to consent to all available accounts on the surface may not adhere to the Data Minimisation Principle, but it would avoid the need for transactions and payee access, so in another way it does. It maintains freedom of choice for the consumer to proceed or not and would allow Data Recipients and Trusted Advisors to access all data required for the safe and responsible implementation of their use cases. Screen scraping is the only existing alternative to this, which provides all data, but no choice, and exposes the consumer to harmful industry practices.

However, I would recommend and support a similar approach as suggested by @jimbasiq as an interim solution since changes to the Security Profile take longer than changes to payload schemas and we would consider this as urgent given rate hikes and general mortgage stress is something we can help address now.

I propose the missing accounts be communicated as integer fields in the meta object of the accounts list response payload. These fields could be totalRecordsAvailable and totalRecordsAuthorised, or similar (not fussed on the naming). This metadata is not in any way harmful to the consumer - in fact it avoids potential harm. The Data Language Standards also state:

Data Recipients and Data Holders SHOULD expand on the proposed language where appropriate to communicate further details of what is being shared.

Given the above, I would argue there is scope for Data Recipients to communicate the additional metadata consented to and how it would be used as part of their lending use case providing full transparency in the interim while the desired approach is implemented for the longer term. Would consumers prefer Data Recipients analyse their payees and transactions to discover missing accounts? Likely not.

[perlboy]

I propose the missing accounts be communicated as integer fields in the meta object of the accounts list response payload. These fields could be totalRecordsAvailable and totalRecordsAuthorised, or similar (not fussed on the naming). This metadata is not in any way harmful to the consumer - in fact it avoids potential harm. The Data Language Standards also state:

It is non-trivial to enumerate a full account list rather than a known set of account identifiers for a Consumer. Adding these integers would be a reasonably large amount of work that has implications for existing solutions implemented to achieve the NFRs because it implies that full account lists are now being front loaded and managed in real time. There's cascading capacity considerations as a result because, unlike consent flow, you never know when you're going to get a call requiring it. Such an approach will invariably result in calls for a long dated FDO, not to mention it would now affect multiple industries. It also wouldn't deal with the inevitable race conditions associated with new (or closed) accounts although this problem would need to be solved in my original proposal as well.

I get that recipients want changes faster, and that's something Biza.io is seeking to do via CDR+, but implementing interim "hacks" isn't the pathway to sustainable ecosystem development.

[nils-work]

DSB Item - Ability for ADR to request all accounts or identify missing accounts #130 has been raised as a Future-Plan Decision Proposal placeholder to be addressed outside the Maintenance cycle.

[jimbasiq]

One more data point to specifically highlight here. We are all (I believe) keen to see screen scraping phased out in Australia in the Banking sector now that CDR Open Banking is available. To be explicit, this topic is one reason why business are remaining on screen scrape services.