Decision Proposal 089 - Direct Consumer Access

[CDR-API-Stream]

This decision proposal outlines a recommendation for direct consumer access to CDR data.

The consultation draft for this decision proposal is attached below: Decision Proposal 089 - Direct Consumer Access.pdf

Note that feedback on this proposal will be extended into the new year due to Christmas and the other activities occurring in the regime. Feedback will be closed on the 7th February 2020

[anzbankau]

When can we expect a standard published on this?

[CDR-API-Stream]

A proposal has been drafted and is being reviewed by the various agency stakeholders to ensure it aligns with intended policy. Due to the work leading up to the February delivery milestone this review may take a little longer than would normally be the case.

[CDR-API-Stream]

This comment is to alert that a proposal for this issue has been added to the issue description.

[da-banking]

DA is confused by the intent behind this proposal.

We had understood the intent of the Direct Request Service in the ACCC Rules to be that if the consumer has the right to instruct a Data Holder to share their data with an ADR, then the consumer has a right to export their data from a Data Holder directly.

The proposal seems to explicitly prevent the consumer from exporting their data from the Data Holder directly, while explicitly requiring Data Holders to develop additional digital representations of the data that they already have within their rich, contextual and expansive digital channels. So the proposal seems to offer nothing useful to consumers, while requiring considerable effort from Data Holders, and adding noise to the user experience.

DA would like the intent of the ACCC Rules to be made clear, and some use cases to be defined.

[anzbankau]

ANZ supports @da-banking request for clarification over the intention of the proposal. If downloading of data is specifically something the standards will not support then could it be documented as such in the proposal as our interpretation of the rules wouldn't prevent this as an approach?

[WestpacOpenBanking]

Westpac recommends that the data standards body develop and publish the direct request service standards using the CX led approach which has been used to develop the grant and manage consent flows. This approach would lead to the best customer outcomes from both privacy and usability perspectives and would likely help to inform further development of the rules.

Topics of research that might be included in customer testing and CX research include:

• How customers are likely to use a direct request service and which use cases they feel are important. Do they favour usages which make use of data presented in a raw format or a visual tabular format or both?
• Would customers share downloaded data in a raw format with third parties if asked for it?
• any information and/or warnings be provided to customers before they make use of a direct request service?
• Is a duplicate interactive visual interface displaying CDR data that must be contained within, but entirely distinct from internet banking likely to cause confusion for customers? Many data holder’s online banking systems already include interfaces for downloading data sets covered by CDR. Would customers prefer to use these existing interfaces and export functionality if this is available?

Notwithstanding any requirement in the rules, we also remark that:

• Mandating common visual and/or raw formats for data increases the risk that data is distributed widely outside the CDR eco-system. This risk is more significant for machine readable formats, but present for both machine readable and human readable formats. This is because human readable formats are generally still machine readable – as demonstrated by the widespread use of screen scraping.
• Notification of refusal to disclose data in the circumstances where there is risk of harm in disclosing data may in itself create a risk of harm in some circumstances.

[commbankoss]

Commonwealth Bank agrees with the principle that customer experience should not be defined in the standards. Additionally, the method of customer access should be determined by the data holder. Commonwealth Bank is assuming that the scope and structure of the Direct Request Service data will be consistent with accredited 3rd party data and would like confirmation of this assumption.

Commonwealth Bank supports the comments made by ANZ and Data Action. The use cases for this proposal are unclear, particularly given existing features banks offer in digital channels. Requiring Data Holders to develop a separate visualisation of CDR data will create unnecessary complexity and overlapping, inconsistent experiences within banks digital banking channels. Expected use-cases, such as record keeping or personal budgeting, would be better met with existing data download features. Additionally, the CDR Rules require both account holders to opt into the ‘Joint Account Management Service’. In the context of consumers directly accessing their own data in a human-readable format we believe a joint account election requirement is inconsistent with existing functionality and may cause unnecessary friction in the experience.

Commonwealth Bank agrees that consumers should be authenticated using the data holder’s existing mechanisms, and any additional checks should be left to the data holder to determine in-line with their security practices. As such, Commonwealth Bank recommends the proposal be reworded from “In addition to normal authentication Data Holders MUST perform an additional “proof of human” check to ensure that access is not being automated” to “In addition to normal authentication Data Holders MUST perform additional checks based on its internal security measures”.

[CDR-API-Stream]

Considering the impact of this proposal there has been relatively light feedback. For this reason the consultation period will be extended for three weeks until the 7th of February.

[amanuel13]

The cba view that the Data Holder should use existing methods to authenticate direct consumers including any additional checks based on internal security policies is not supported. This additional checks step and not supporting raw data availability would be inconsistent with the accredited third party data assumption comment made. It would inhibit the ability for the consumer to authorise or themselves direct export the data for own use via or provision to and reuse by a consumer authorised third party. The comments to date indicate clear separation of how the consumers data could be accessed and exported from the data holder. Between direct consumer access via a data holders normal direct consumer access method such as internet banking to via a third parties api using the same current normal authentication as is currently offered through several neo banks. An inconsistent CX. The inabiilty to contemplate and therefore include every possible use case in the rules is acknowledged. Basic obvious use cases as a minimum required to be supported should be defined and included in the CX standards if not the rules. Else the CX and support of CDR and open banking intent will not gain confidence and use by consumers.

[commbankoss]

@ amanuel13, the requirements regarding authentication are outlined in proposal 089. Referring to page 2: “Data Holders MUST authenticate consumers using existing mechanism utilised for their existing digital channels…In addition to normal authentication mechanisms Data Holders MUST perform an additional “proof of human” check to ensure that the access is not being automated. This check should be sufficient for the purpose but the specific type of check is left to the Data Holder to determine”.

Commonwealth Bank has responded to those requirements raised by the Data Standards Body. Commonwealth Bank is not proposing additional requirements regarding authentication and has outlined support for consumers accessing the ‘direct access service’ using existing mechanism utilised for internet banking.

[amanuel13]

commbankoss , There is no issue with your response and stated right and approach that covered the part of my comment that related to "direct consumer access via a data holders normal direct consumer access method such as internet banking". Appreciating obligation of Data Holders to protect their customers data.

It is the second part relating to access " via a third parties api using the same current normal authentication as is currently offered through several neo banks such as only User/account name and password which may not be the same as that used by the data holder (CBA). An inconsistent CX.

Not intending to inhibit data sharing but would CBA reject consumer authorised requests received sent by another entity (Neobank, third party AISP, etc containing only username/account name). Yes impacting resultant screen scraping used another separate issue needing addressing.

A view of the need for the rules/standards to provide direction or requirements to address the possible inconsistent consumers authorisation/account access CX including potential blocking of the consumers authorised request. . If it does require the same requirements as the data holder CBA a mechanism to enable the requesting entity to be aware of what they are and provision for them to be provided.

[Susan-CDR]

Suncorp agrees with the comments made above with regards to understanding use cases for this proposal. Suncorp also agrees that many of the data sets required for CDR are already available as existing features offered in online banking, so the value of duplicating this information by displaying it in a separate view is unclear and potentially confusing for the customer. Suncorp agrees that the consumer experience should be determined by the data holder (informed by use cases), rather than by defined in the standards.

[vk3il]

I would like to provide a comment as a potential CDR consumer and would also encourage the DSB to consult with consumers before finalising this proposal. As a consumer, I already have plenty of access to my banking data through both apps and online portals. I don’t feel the need to receive yet another view of this data in human readable form.

However, what I would highly value is a standardised way to connect my personal financial management software to my bank in a simple and automated manner. I realise that I’m probably one of the 5% who actually bother to reconcile my bank accounts to a personal accounting package, but for us 5%, an API oriented interface would be very useful. It would be fabulous if all banks provided a standard interface to enable this.

Rather than designing something new for Australia, I would suggest that the DSB adopt the OFX standard which is used widely in the USA and which is supported already by most personal financial management applications. This type of interface is in fact what I expected to see from the direct consumer access requirements in the rules.

[jimmcslim]

I would also like to support @vk3il's comment, he has articulated many of the same thoughts that I wanted to share. By all means I hope that the introduction of the CDR for the banking industry results in a rich ecosystem of personal finance/budgeting fintechs, but it would also be great if the standards supported an approach where a desktop app, or Excel plug-in, etc could also direclty access the APIs on behalf of a single user. I think people who subscribe to the idea of https://plaintextaccounting.org/ for their personal/small business accounts would also appreciate access in an automate-able, scriptable, and 'headless' manner.

[NationalAustraliaBank]

NAB doesn't support the current proposal for direct consumer access. As mentioned by Data Action, Westpac, and CBA, dedicated viewable interfaces for these sets of information already exist and a new interface may potentially create a confusing user experience for consumers, and assisted banking processes. Additionally, the joint account management service may also introduce further complexity, creating inconsistency with current views of joint accounts in existing channels.

To help understand what the potential options are for the direct request service, basic use cases should be outlined for why a customer may access their data via the direct request service, and in what structure or format that is useful for the tools or applications they are most likely to use. This should aim to enable use cases that are not currently supported and ensure consumers still have control over their data.

NAB supports the recommendation for a CX led approach as outlined by Westpac, in order to further understand the potential use cases that this direct request service should enable in line with the intent of the CDR.

[SP3269]

I'd like to access my data without intermediaries, in exact same form that the indirectly authorised parties see it, without being subjected to lengthy manual process.

[maddogdavis]

Immediate access to my data at all times authenticating with SSH. Transfer via RSYNC. Data is superset of that available to indirectly authorised parties. SSH key pre-registered at local bank branch with sufficient ID. Support other authentication methods in addition to SSH. Support other transfer mechanisms in addition to RSYNC.

[endgame]

Why is this project called "Consumer Data Standards" when many of the parties here are arguing against providing machine-readable data to consumers?

[perlboy]

Hmm, this is an interesting topic with some clearly divergent views about what "Consumer Data" is and how it is defined from a legislative instrument perspective. My primary question would be why the solution proposes to require any data transformation? Part 3 of the rules specifies nothing about the format of the content so I'm not sure why it makes sense to transform the data rather than remain aligned to the published (and freely licensed under MIT) schemas. This would mean the "competitive space" could perform transformation aligned with their requirements.

Is there documented reasons why this couldn't be kept simple by initially requiring Holder's to provide a "Download" button of a ZIP file containing a complete set of payloads in exactly the same JSON structure that is presented via API? This like-for-like option doesn't appear to have been proposed but instead re-presented as a "simple tabular format" which is a bit of an oxymoron when considering the number of attributes in the payloads.

A relatively simple workflow could be adopted similar to Google's Takeout using the defined data cluster language. Once the user has received their data in the currently defined JSON format, potentially with an out of band method of supplying the archive password, various software could build adapters based on the published specification.

By way of example Plain Text Accounting could build a CDR adapter or use existing CDR payload parsing libraries, to perform client side transformation as required. This is not too dissimilar to commonly available download methods using the venerable OFX/QIF formats and would avoid the emergence of essentially two standards (the JSON one defined and the new CSV/Tabular one proposed).

By doing this the burden on Holder's is reduced to simply using their existing payload generation capabilities for the API side, Payload consistency is likely much more achievable and the Consumer is only limited to solutions which parse the CDR payloads themselves which, isn't much of a limitation since any alternative transformation would still need an adapter to parse a complex CSV. json2csv already exists to cover the typical Excel load use case and the development to produce a cdr2ofx tool is likely achievable during an overnight hackathon (any takers? :)). That is to say the friction of conversion from a fixed set of known and clearly defined schemas is low.

In summary I don't see the reasoning for attempting to predict the desired format of these requests when the DSB has defined rich usable JSON payload formats already.

Footnote: @SP3269 this is precisely what I'm suggesting. Ship a zip file with the JSONs in exactly the same format that a Data Recipient would receive them via an API.

[CDR-API-Stream]

Thanks everyone for the feedback. We will closely this consultation now (after extending it for a few weeks) before a final decision is made. As this standard is heavily influenced by policy considerations the final recommendation will only be made after inter-agency consultation has also been conducted.