Decision Proposal 225 - Data Recipient Security Standards

[CDR-API-Stream]

23rd February 2022: Feedback closed

Feedback for this consultation has closed. Thank you to everyone who contributed. Feedback will be reviewed and responded to before any proposals or recommendations are made.

--
16th November 2021: Decision Proposal 225 published.

This decision proposal presents a set of questions for the consideration if and how security standards should apply to data recipient access arrangements. This decision proposal does not propose standards, instead it asks for feedback on need, feasibility and implementation considerations.

The decision proposal is attached below:
Decision Proposal 225 - DR Security Standards.pdf

This consultation will be open for feedback until the 18th February 2022.

15th November 2021: placeholder was published.

Placeholder for a decision proposal considering security standards for data recipients and the new access arrangements.

The recent release of the Competition and Consumer (Consumer Data Right) Amendment (2021 Measures No. 1) Rules 2021 introduced amendments that:

(a) increased the ways businesses can participate in the CDR and the range of services by which consumers can derive benefit from their data through new access pathways including: trusted advisers, representatives and sponsored affiliates.
(b) permitted, or where necessary, made clear, that the Data Standards Chair may seek to define data standards in relation to the disclosure of CDR data including by data recipients.

• Repeals 4.10(2)
• Includes 7.5(2)

A decision proposal will be posted here once developed.

[CDR-API-Stream]

The decision proposal has now been published and is attached below:
Decision Proposal 225 - DR Security Standards.pdf

This consultation will be open for feedback until the 18th February 2022.

[AusBanking]

On behalf of ABA members, please find our responses to the questions below:

Question 1 – What principles should the Data Standards Chair apply to determine if any security standards should be made for the CDR access arrangements? • What principles should be applied to whether standards apply and to what extent? • Do the principles apply equally to all access arrangements, or are they specific to one of the access arrangements?

In order to build and maintain customer trust, the following principles should be applied to all access arrangements between all participants (data recipients, data holders, trusted advisors, representatives, further on-sharing and etc) of the CDR ecosystem:

• Privacy and data minimisation
• Data security
• Integration security
• Customer visibility and control
• Customer authentication requirements

Some insecure practices (screen scraping and etc.) outside of CDR ecosystem should be strongly discouraged. CDR needs to cover all functionality that can be achieved by screen scraping, but in a secure manner and with customer consent.

Additionally:

1. The DSB should work closely with the ACCC and the OAIC to ensure the CDR addresses the relevant risks from a holistic perspective.
2. Any standards made should not look to replace existing security mechanisms, however they should look to eliminate insecure practices, such as sending data over email or screen scraping. As such, they should enforce a minimum acceptable level of security standard rather than specify a specific technical standard.
3. Any standards made should recognise that different transfer mechanisms may be appropriate for different circumstances, (e.g., API push vs API pull vs batch or micro-batch files).

Question 2 – How should the Data Standards Chair determine whether standards apply to data recipient access arrangements, or not? • If standards are defined, is this the addition of general requirements or specific security profiles governing the disclosure of data? • If standards are recommended, do they apply equally to all access arrangements or specifically to one or more access arrangements?

If standards are recommended, should they be principle-based or provide detailed standards? • If standards should not apply, why not? • If alternative channels already exist for data collection (e.g., secure APIs or screen scraping) what reasons are security standards recommended for the CDR channel but not the alternative channels? • Rather than apply additional security standards within the CDR, should they instead be imposed through adjacent regulations in each sector that apply universal high-grade security consistently across all digital channels for the transfer of data?

All security standards should be principle based and use open industry standards without customisation. These standards should be independently reviewed by qualified API security professionals before the adoption. Compliance with standards should be made easier and guaranteed by using comprehensive conformance test suites (e.g., OIDF FAPI conformance testing).

Specific standards should be prescribed by DSB for all the access arrangements within CDR ecosystem. Standards prescribed should be suitable for different use cases and modes of interaction.

For the access arrangements outside of CDR ecosystem, the principles above should be followed with the list of requirements to meet for each access arrangement. Specific standards should be recommended but not prescribed.

Adjacent regulations should not be relied upon as their coverage is unlikely to cover all the scenarios in scope for this consultation.

Question 3 – If standards are supported, what standards are recommended, and why? • Should standards exist where data is in transit? • Should standards exist where data is at rest? • Should standards exist for how secondary data recipients authenticate with their sponsor or principal? • Should standards exist for how two data recipients authenticate with one another for disclosure of data? • Should standards exist for the transfer of consent where a data recipient changes its technical infrastructure or outsourced software provider? • If standards are recommended, what impact does this have to consumer experience?

As a general principle, in order to build and maintain customer trust, the security standards should exist for all access arrangements and interactions. Customer should maintain visibility of their data and all parties that have access to their data. Customers should have ability to revoke access to their data at any time. This revocation should be transparent, (i.e., there should be a way for the customer to identify, via their data holder dashboard, which on-sharing related consents, facilitated through the same ADR, they are revoking).

Question 4 – What concerns or considerations must be factored into pre-existing commercial data integrations and solutions? Many access arrangements supported within the CDR replicate existing commercial arrangements for non-CDR data sharing. Defining additional security and technical requirements for pre-existing commercial solutions may therefore impact existing implementations. Are there any considerations in this regard that should be factored into making standards, or alternatively where standards should not be imposed?

CDR access arrangement should be used as an opportunity to increase security of data sharing and customer control. Existing access arrangements that don’t satisfy principles above should be discouraged and phased out.

Question 5 – Are security considerations limited to any given sector or do they apply to all CDR data? As the CDR expands across sectors, data recipients will have access to data sets across different sectors. So too, Data Holders may operate in more than one sector (for example an organisation providing banking, wealth and general insurance products).

Security standards should be consistent between different industries to promote security, interoperability and increase vendor support.

Question 6 – Should the Data Standards define customer authentication requirements for customers authenticating with accredited persons or with non-accredited persons in a CDR access arrangement? Whilst consumers must authenticate with their data holders to authorise the disclosure of data to a data recipient, there are no standards pertaining to the authentication of the customer in the data recipient. A digital identity and/ or customer authentication is not a pre-requisite to the use a data recipient goods or service.

For every customer interaction that results in sharing, on-sharing, deleting, or modifying data or insights based on their data, should have a minimal level of authentication and, potentially, identity proofing requirements mandated.

Question 7 – If action initiation or payment initiation are introduced into the CDR, does this raise new or additional security considerations for access arrangements? If action initiation was adopted by Treasury, this may provide alternate pathways for consumers to initiate payments, update their data and accounts, and open new accounts. Considering the potential future enhancements to the CDR, are any additional security measures relevant for data recipients?

Minimal levels of authentication should be reviewed to make sure that they are suitable for higher impact transactions like action or payment initiation. For example, in Europe Strong Customer Authentication requirements were introduced as a part of PSD2.

Question 8 – Are there any additional implementation or security considerations? • Do these implementation considerations preclude the making of security standards or do they change or increase build considerations? • Do these considerations impact reasonable implementation obligation dates? • If so, where standards are recommended, what obligation dates are considered practical and reasonable? • What key challenges would introducing security standards present? • What key risks would introducing security standards mitigate?

ABA members believe that the following should be considered:

1. Loss of customer visibility and control should be addressed for sponsored data recipients and other on-sharing scenarios. Note: depending on the solution, a register standards uplift might be required which could impact existing participants.
2. Loss of privacy as a result of on-sharing should be addressed (e.g., pairwise unique identifiers are no longer unique and private between different participants of the ecosystem). ABA members recommend that new pairwise identifiers be generated when on-sharing.
3. Operational impact needs to be considered for complex multiparty arrangements, investigations and support, response to security incidents.
4. To guarantee industry wide compliance, comprehensive conformance testing must be performed by all participants (where applicable, for example, to verify integration security).
5. Appropriate protections for the data once it leaves the core CDR (e.g., consider stipulating that the data must not leave Australia).

[JTRlaw]

Trusted Advisers cannot be captured in security standards for other non-accredited persons within the CDR regime.

Trusted Advisers are a restrictive group of professionals held accountable to professional standards, the majority are licensed and regulated by a Government agency and accountable to the Privacy Act 1988. In addition, professional accountants are already required to authenticate who their clients are. That is, while not accredited within the CDR regime, TAs are held accountable on matters of privacy, usage, client verification and secure storage of personal data.

Question 1: Access to CDR data for a trusted advisers is driven through consumer nomination and consent. Access within an accredited persons platform does not require additional standards as the accredited person holding this data is already held accountable to stringent security standards.

Question 2: Access arrangements should not require additional standards. The accredited person holding the data is already meeting the stringent security standards for CDR data within the CDR regime. Seeking to add additional security standards to access data held by an accredited person appears to duplicate these existing standards.

Question 6: We do not agree that standards are needed for customer authentication by an accredited person or trusted adviser. Customer authentication will already form part of an accredited persons’ contract to take on board a customer. Customer authentication by a trusted adviser is not relevant in the CDR regime as data disclosed to a trusted adviser moves that data outside the CDR regime.

We would note that many trusted advisers already have customer authentication obligations. For example, the Australian Taxation Office and Tax practitioners Board recently released guidelines on client identify verification for tax agents.

New standards should only be considered where a gap has been identified within the CDR regime that places the consumer at risk. Access to data held by an accredited person, on the accredited person platform, is already captured by the security standards for that accredited person. Disclosure to a trusted adviser moves the data outside the CDR regime therefore CDR security standards would not apply.

[jimbasiq]

Basiq response : Decision Proposal 225 - Data Recipient Security Standards

Thank you for the opportunity to comment on this proposal. We very much support and embrace the model of questioning the industry, prior to an actual proposal.

Overview of Basiq

Basiq is a Platform As A Service that provides the building blocks for financial services, predominantly in the form of modern secure APIs. We provide services to over 120 partners, ranging from small FinTech start-ups, to big players in the Australian Tech industry. The data we currently base our services on is sourced from financial institutions that are both ADIs and non-ADIs, always with the consent of the consumer. This integration with the data holding institution can be from Digital Data Capture APIs (screen scraping), statement uploads, or CDR Open Banking APIs.

In our response, Basiq would like to both represent ourselves and our current and future Partners who access the consented, aggregated and enhanced data we provide.

Concerns around introducing new barriers to participation

Basiq fully supports the CDR framework and we are actively encouraging all of our 120+ Partners to move to consuming CDR data in preference to other data sources. The path to accessing CDR data has of course been greatly improved with the additional optionality of the various models available. However, many of our partners see CDR as introducing friction over what is already available. Basiq is working hard to support and encourage our Partners, but if additional barriers to adoption were introduced, this would certainly make our job harder. In this vein, we would suggest any additional rules be considered with the goal of being helpful and outlining what is “best practice”, rather than overbearing.

Principles-based approach to security obligations

Basiq believes a principles-based approach to data recipient access arrangements and security obligations should be applied. Detailed standards, such as stipulating a specific authentication mechanism that may be equivalent to several other options, would cause great disruption not only to ourselves and to organisations similar to us, but also to all Partners using our services, specifically under the Affiliate/Representative model. That said, we of course vet our Partners to ensure the correct technical, security and process maturity is in place before any formal relationship is executed and CDR data is shared. However, the CDR attestation questions, which guide our due diligence process when onboarding a Partner for CDR data access, already require a level of competency around securing that data, both in transit and at rest. We provide services to ensure data is well governed both in our data enclave and those of our Partners. Adding further complexity, could add to any potential friction in on-boarding Partners to consume CDR Data.

Agreement of security considerations prior to a decision

Any changes to our existing API interface with our Partners will cause friction for Basiq but also for every single Partner who consumes our APIs. We ask that any such change is discussed and the benefit agreed to outweigh this friction. What the CDR framework needs most of all right now is adoption of FinTechs and other service providers to enable innovative and helpful solutions and services to Australian Consumers.

Security considerations apply to all CDR data

Basiq support a single approach for all cross cutting elements across all sectors and believe the same mentality should be applied here. All sectors will be providing PII data so the same level of security should be maintained.

Thank you once again for this opportunity. Please get in contact to discuss any of these points further.

Kind Regards

Jim Basey
Head of Technology
Basiq
[email protected]

[NationalAustraliaBank]

Summary Feedback:
NAB welcomes the opportunity to provide feedback on decision proposal 225, seeking input on whether security standards should be considered for transfer of CDR data beyond the primary data recipient.

The detailed feedback is provided against individual questions in the decision proposal. In summary, NAB recommends development and implementation of CDR security technical and general standards to promote customer trust in the CDR ecosystem by ensuring that all participants accessing, processing, transmitting and storing CDR data are accountable for the security of CDR data through adoption of these standards beyond primary ADRs. Due considerations may be made based on the security risks, new access arrangements including existing non-CDR channels.

Question 1

NAB is of the opinion that consumer trust in the CDR ecosystem is underpinned by the security of their CDR data. With the introduction new participant arrangements, the security profile of the CDR ecosystem will significantly change with higher degree of exposure due to complex data flows amongst multiple participants in the new arrangement models. NAB recommends that the adequacy of existing security standards between data holders and primary ADRs for applicability while data sharing between new arrangement participants be assessed.
• The principle NAB recommends is that the baseline security standards should apply to any participant in the CDR ecosystem who has access, stores, processes or transmits CDR data regardless of the access arrangement.
• Relaxation of the standards to certain participants and arrangements may be considered such as trusted advisors when they only have access to CDR data provided by a platform service by an ADR and do not have the ability to store, download or aggregate, or further disclose CDR data through their APIs.

Question 2

An objective risk assessment in light of new access arrangements and future ADR products is required.
• At the first instance, NAB believes that specific security profile may be required for CDR data disclosure beyond primary ADR that is aligned with existing data holder/ADR profile and may have additional security provisions.
• The standards should be detailed where the CDR data is being disclosed to other data participants. Baseline standards should apply to all access arrangements.
• Where some participants such as trusted advisors who are end users of another ADR platform and do not aggregate data through APIs, the detailed standards may not apply to them. However, the privacy and security responsibilities should be covered as per terms or use between ADR platform service and trusted advisor and fall within CDR regulatory governance.
• Further, the standards for first party non-CDR channels may be unnecessary as the CDR data is not being shared with a third party.
• Currently, it appears that there is a lack of standardisation in security of alternate channels including insecure practices of screen scrapping through sharing of customer credentials which jeopardizes the security of data holder’s systems. NAB opines that convergence of the two channels i.e. CDR and alternate on common security standards will lead to overall superior outcomes and secure digital economy.
• NAB recommends that additional security standards beyond primary ADR should be enforced through the CDR data regime regardless of industry sector. Imposing through adjacent regulation may lead to inconsistent, non-coherent and varying degrees of adoption across industry sectors.

Question 3

The existing model that has two components addresses secure transfer of data and security of the CDR data environment that stores and processes it. Standards for data transfer/sharing between data holder and primary ADR relate to the first component and minimum mandatory security controls for CDR data environment for ADRs relate to the second component.
• Standards should exist for transfer/transit of CDR data between primary ADRs and beyond. These standards should be enhanced to mitigate the increased risk due to complex data flow. E.g. these complex data flows may need to reflect traceability of CDR data from one end of the data stream to the source. This will enable the CDR participants to identify the point of compromise during the data breach incident and respond more effectively and contain the incident.
• Security controls specified in Schedule 2 (part 1 and part 2) are adequate to apply to all participants including primary ADRs and beyond for CDR data at rest security within defined CDR data boundaries of respective participants.
• The standard for new arrangements must specify how the secondary recipients authenticate with their sponsor or principal.
• The standard must specify how the two data recipients authenticate with one another.
• The standard should specify transfer of consent.
• The recommended standards will have a positive impact on customer experience and promote customer trust in the overall CDR ecosystem. With the introduction of multiple participants and pathways, a CDR consumer is likely to get confused with the complexity of the new arrangements and intertwined data flows. Currently, the consumer can easily understand through their consumer dashboard where all his/her CDR data has been shared and is in control, where and when to stop the data sharing either through data holder or ADR consumer dashboards. The standards must be uplifted to address this challenge for the CDR consumer.

Question 4

There are three data access pathways/interfaces in the non-CDR channel i.e. 1 , 2 ,3 and 3a as depicted in the figure 1 of the proposal. NAB opines that :

1. Interface 1 is a proprietary interface of the data holder and CDR data is shared directly with the consumer through secure mechanisms and not with third parties. Therefore, this interface may be excluded from the scope of CDR standards.
2. Interface 2 with trusted third-party apps is governed through agreements between the data holder and trusted third party. Implementations may vary from one data holder to the other. Nonetheless, the security accountability would be defined in the agreements hence it is not of a significant concern. This channel may or may not be included within the CDR standards scope.
3. Interface 3 and 3 b with untrusted third- party commercial arrangements within non-CDR channels may have lack of governance and inconsistent implementation of security controls towards protection and handling of CDR data. Considerations should be given for non-CDR access arrangements that involves disclosure customer credentials and data to untrusted third-party apps. Following are the issues from a data holder perspective:
   • A data breach of user credentials at a third party site will result in compromise of the data holders’ system. There is no agreement on accountability of security between the two parties under the interface 3 and 3b arrangements.
   • In the event of a cyber incident at an untrusted third-party site- there is no onus or obligation on the untrusted third party to reveal how the breach happened whereas the impacted data holder seeks this information to respond to these incidents or protect its systems from future attacks.
   • There is no liability model for data breaches that exists within CDR or non-CDR access arrangements. Though, CDR rules mandate APs to have insurance.
   There is a lack of governance or non-existence of formal agreements for such agreements between an untrusted third party and the data holder- this may result in poor security outcomes. These untrusted access arrangements should be brought under regulation through security standards similar to CDR channels.

Question 5

Additional security considerations should be given to certain data classes for specific industry sectors that warrant a higher level of security regardless of the ADR consuming it E.g. Payment initiation services by CDR participants in the future through CDR channel is more likely to be targeted for cyber criminals and will bear more impact on financial industry sector over the others.

Question 6

Data Standards should be defined for accredited or non-accredited persons to identify and authenticate their customers to minimize the risk of frauds and unauthorised CDR data disclosure so that the digital economy can thrive on strong foundations.
Alternatively, a risk- based approach could be considered, e.g. the accredited persons offering critical consumer services such as payment initiation would have more rigorous standards for customer authentication as against basic services e.g. insights into CDR research data.

Question 7

NAB believes that, with the introduction of action initiation services such as account opening, payment initiation into CDR would significantly increase the risk and additional security considerations must apply to the participants of the CDR ecosystem. E.g. payments initiation participants must have equivalent controls and processes as adopted by the banks including but not limited to stringent customer identity verification (KYC checks), fraud monitoring, controls relating to transaction limits etc.
In addition, a cross industry platform to share threat and fraud intelligence should be established under direction of the regulator that will provide framework and oversight to minimize the impact of cyber and fraud incidents affecting the CDR eco-system.

Question 8

• The additional considerations as stated above allude to change and build considerations for security standards.
• These considerations will have an impact on implementation obligation dates.
• The complexity involved in the implementation cannot be accurately determined as this stage. We would defer NAB’s response on this until a consolidated view is made available.
• The key challenges that we anticipate in introducing these standards will be in engaging the new participants from new arrangements or existing non-CDR arrangements in the development and feedback process. Further, we expect existing inconsistent implementations and resistance in adopting new standards for convergence of non-CDR participants.
• The standards would largely mitigate the risk relating compromise of CDR data and fraud related risks.

[JJLWHarrison]

TrueLayer welcomes the opportunity to comment on Decision Proposal 225 in relation to Data Recipient Security Standards.

The CDR Rules already set high level security requirements in Schedule 2 which are applicable to the protection of consumer data under a number of CDR access arrangements including both the representative and affiliate models. Schedule 2 includes requirements for security governance and the encryption of data in transit and at rest.

Introducing further standards (or variations to existing standards) specific to particular access arrangements would require more complex rules, assessments, attestations and assurance obligations. This may unnecessarily further hamper participation. This would seem contradictory to the intent of these new arrangements which were introduced to lower barriers to entry and increase competition.

TrueLayer is not aware of any evidence to suggest that existing security standards fall short or are inadequate. We therefore suggest that the existing wording of Schedule 2 is sufficient and appropriately principles-based. These principles should be applied relatively uniformly across all new access arrangements and sectors. We do not recommend prescribing any additional or specific technical approaches.

We suggest that obligations of Principals and Sponsors are already well-defined within the rules and intermediaries adopting these business models are able to accomodate associated information security requirements into contractual arrangements with Representatives and Affiliates.

There is potentially an argument that organisations receiving CDR Insights may not need to adopt such sophisticated information security controls due to the associated risk in the event of a breach. For example, MFA may not be deemed necessary in order to manage a set of binary responses to a relatively low risk query. However, there will be variability in that risk based on the query itself and the related metadata used to associated the response with an individual. In our view, the existing Information Security standards aren’t unreasonable and we would suggest that any contemporary technology business should be adopting similar principles, regardless of whether they host CDR data or not.

[EnergyAustraliaCDRBA]

EnergyAustralia welcomes the opportunity to provide feedback on this decision proposal in regards to Data Recipient Security Standards.
EnergyAustralia has consolidated the responses to all the items listed within the decision proposal for consultation in the attached pdf. Thank you.
EnergyAustralia_CDR - DP225 Response - Data Recipient Security Standards.pdf

[CDR-API-Stream]

Thank you to everyone who contributed. Consultation has now closed. Feedback will be reviewed and responded to before any proposals or recommendations are made.