ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes (5th of November 2020)

When: Weekly every Thursday at 3pm-4.30pm AEDT
Location: WebEx, quick dial +61262464433,785383900%23%23
Meeting Details:

Desktop or Mobile Devices https://csiro.webex.com/csiro/j.php?MTID=m7c39ee9db5e5892ab35cd0bd7bbf94ce
Once connected to your meeting remember to start your audio and video
Please mute when you are not speaking.

Video Conferencing (VC) Rooms
Use the remote control or touch panel and dial the number indicated below:
External VC Room: 785383900@csiro.webex.com

Phones - AUDIO ONLY

Primary Australia: +61 2 6246 4433
Quick Dial: +61262464433,785383900%23%23
Other Global Numbers: https://conferencing.csiro.au/Call-in.php
Meeting Number/Access Code: 785 383 900

Agenda

Introductions
Actions
CDR Stream updates
Q&A
Any other business

Meeting notes

Meeting Notes
Next steps

Introductions

5 min will be allowed for participants to join the call.

Recording

The Consumer Data Right Implementation Calls are recorded for note taking purposes. All recordings are kept securely, as are the transcripts which may be made from them. No identifying material shall be provided without the participant's consent. Participants may contact@consumerdatastandards.gov.au should they have any further questions or wish to have any material redacted from the record.

Acknowledgement of Country

We acknowledge the Traditional Custodians of the various lands on which we work today and the Aboriginal and Torres Strait Islander people participating in this call.
We pay our respects to Elders past, present and emerging, and recognise and celebrate the diversity of Aboriginal peoples and their ongoing cultures and connections to the lands and waters of Australia.

Actions

Type	Topic	Update
Standards 1.5.1	Published	Link to change log here
Decision Proposal - Energy	Decision Proposal 116 - Billing Data Payloads	View the Decision Proposal 116 here
Decision Proposal - Energy	Decision Proposal 115 - Tailored Tariff Data Payloads	View the Decision Proposal 115 here
Maintenance	5th Maintenance Iteration underway	List of scope and agenda(s) can be found here
Maintenance	Next week's meeting to be moved to Thursday before CDR Implementation Call	Update to be sent in the next 24hrs
DSB Newsletter	To subscribe to DSB Newsletter	Link here
ACCC Newsletter	To subscribe to ACCC Newsletter	Link here
ACCC Newsletter	Newsletter published on the 4th of November 2020	View the newsletter here
Request for clarification	Update: Now Moved CDR Support Portal from Consumer Data Standards Maintenance GitHub	Current requests will be answered and closed out, for new requests - we ask you raise these via the form here or via email to support@cdr-support.zendesk.com
CDR Support Portal	Known issue - those who are subscribed to follow a user profile may not be receiving email notifications of new posts being published	Issue/ Ticket raised with ZenDesk - update pending investigation with Support team
End of Year	Winners of the survey: 10th of December 2020 (52.3%), through to the 14th of January 2021 (76.5%)	We will keep everyone updated on the plan for over the Seasonal Break
Community Request	Request from NTT Ltd for Community help with their usability testing	Good afternoon, I hope this email finds you well. We’re looking to run a usability test for the Australian Competition and Consumer Commission (ACCC), Consumer Data Right (CDR) Participant Portal. In an effort to improve the website, we’re looking for Data Holders who may be interested in trying out a prototype and giving feedback during/after using it. Your feedback would be invaluable, and a way for you to help shape how people use the CDR. What will I be doing in the usability test? You will be asked to do several short tasks using a website prototype. You will also be asked questions about your experience and perceptions of the website. How long is a session? Approximately 1 hour When and where? The usability test can be held at a time of your convenience on Thursday (if this does not suit your schedule please let us know). No traveling is required as this is a remote study that will be performed online using Microsoft Teams. You can participate using your office or home computer. If you have any questions or concerns, please feel free to contact our UX Designer who will be conducting the session at daniel.sealey@global.ntt
Data Conventions	Workshop to be announced in the next fortnight on Data Conventions The Data Standards Body have published a draft of PROPOSED Data Conventions We would like feedback and insight from the community	The Conventions main article can be found here: CDR Support Portal - Conventions

CDR Stream Updates

Provides a weekly update on the activities of each of the CDR streams and their workplaces

ACCC Rules
ACCC CDR Register (Technical)
DSB CX Standards
DSB Technical Standards - Banking
DSB Technical Standards - Energy & Engineering

Presentation

Presentation/ discussion for this week: Non-functional Requirements

Q&A

Questions will be received by the community via WebEx chat before the questions are opened to the floor. Participants can pre-submit questions to the DSB mailing box.

Current received pre-submitted questions:

Answer provided

Ticket #	Question	Answer
192	We are looking for clarity on requirements that are compulsory for account & transaction data on Phase 1 & 2 products, specifically for joint accounts. We understand that ACCC provided the Joint Account Guidance where scenarios are outlined. The question we have is on the status of Joint Account Guidance document – are the requirements derived from this document compulsory to implement, or only suggested but not compulsory? Specifically the next two requirements – are they compulsory to implement for account & transaction data on Phase 1 & 2 products release: 1. ‘Pause’ via JAMS (Scenario 4a & b) If one of Joint Account Holders removes an election via JAMS for an account that is already in an active sharing arrangement with 3rd party, authorisation should not be withdrawn, but the data sharing for that account should be stopped. Removal of election via JAMS for joint account does not cause removal of this account from authorisation. It only caused the data sharing to stop for this account. 2. Resume via JAMS (Scenario 4c & 7) After the requirement above, if both Joint Account Holders elect though JAMS for this same joint account that is ‘paused’ in an active sharing arrangement to be shared back (meaning this account is marked back as ‘available for data sharing’), the data sharing should continue as this account was never removed from authorisation in the first place.	The joint account guidance relates to compliance with the joint account rules by initial data holders, from November 2020. We have been consulting on proposed amendments to the joint account rules, see section 7.1 of the consultation document and Part 4 of Schedule 3 of the exposure draft. Feedback to consultation will inform whether amendments to the joint account rules are made, and subsequently determine whether the joint account guidance requires updates ahead of the November 2021 sharing by non-major ADIs. However, we consider the proposed amendments to have substantially similar implementation to that proposed by the joint account guidance. That is, the proposed amendments still: require that if a JAMS election is removed, the sharing on the joint account ceases, but the authorisation remains in place to support any other accounts being shared; require that if a JAMS election and an authorisation are both in place, data on the joint account be shared. In the proposed amendments, it may be that the re-instigation of sharing is captured as an amendment notification requirement under the proposed clause 4.16 of Schedule 3. This would allow joint account holder B to have additional oversight of this sharing. We welcome feedback on whether you consider this appropriate, and whether further amendments are required to this clause to capture a re-instigation of sharing scenario.
204	Clarification on Data holder providing link to CDR policy: This question relates to Part 7 – Rules relating to privacy safeguards, section 7.2.1. According to this rule, a Data Holder (DH) will need to include details of the complaints process on the Consumer Data Right (CDR) policy.. The question is at which stage (wireframe) is the CDR policy expected to be shown on Data holder side. As per the CX guidelines, the CDR policy is only visible on the Data recipient Consumer dashboard as attached.	Rule 7.2(8), in division 7.2, states that CDR participants must make their CDR policies readily available through each online service they ordinarily use to deal with CDR consumers. 'CDR participant' refers to both ADRs and DHs, but it is true that the CX Guidelines only show an example of the CDR policy on an ADR dashboard. We would consider the authentication step to be a reasonable place to surface the CDR policy as this will likely be the first online service the CDR consumer uses to interact with their DH for CDR. We would also consider the authorisation flow to be an appropriate context for the CDR policy, along with the data sharing arrangement on the DH dashboard. All of the above examples are reflected in the live implementations of real-world CDR participants. The next release of the CX Guidelines will be augmented with the above examples in mind.
210	We have noticed the answer provided on ZenDesk in relation to the minimum product grandfather period (https://cdr-support.zendesk.com/hc/en-us/articles/900002707406-Minimum-Product-Grandfather-Period), which asked if there were criteria required for products which have been grandfathered. Based on the response that said “No. If the product is open or was closed for less than 12 months it should be included." We note that products can either be on-sale or not-for-sale (grandfathered). We therefore seek clarification on whether the intention of the previous response with respect to required consumer data is as in the attached table.	CDR Support Portal
233	Is there a need to correlate pending and posted transactions such that the data recipient doesn't end up with duplicate transactions (ie a pending transaction that is later duplicated by a posted transaction)?	CDR Support Portal
239	I have read another help article regarding this schema and the ENUM's and I'd like to clarify some additional information. PAYMENT - should this this used for 1. a payment specific to a loan/debt? 2. any payment into an account (eg cash or transfer) 3. a "payment" may also have a type of Transfer_outgoing or Transfer_incoming I read this is open to interpretation, however we have mutilple transaction type codes in our system, which could be seen/returned in more than one way. Should we choose the one we think it best suits? EG. We have a transaction type called Payroll Credit, this could be PAYMENT or it could be Transfer_incoming. Is transfer_incoming & transfer_outgoing more for transfers from/to an external institution?	In regard to your questions on enums you refer to the 'PAYMENT' value but not the field you're referring to. As 'PAYMENT' can be a value of 'feeType' or 'type' in transaction this is ambiguous but, based on the rest of your question, I assume you are referring to transaction type. If this is incorrect please disregard this response and let me know. Q: I have read another help article regarding this schema and the ENUM's and I'd like to clarify some additional information. PAYMENT - should this this used for 1. a payment specific to a loan/debt? 2. any payment into an account (eg cash or transfer) 3. a "payment" may also have a type of Transfer_outgoing or Transfer_incoming A: This is entirely up to the Data Holder. The standards do not specifically call out how to select these transaction types for specific transactions as ledgers and internal processes are so variable. When the type field was introduced (at the explicit request of ADRs) there was a good deal of debate on this topic with the result being the field would be introduced with a minimum number of values that would be relatively common across all ADIs. The only guidance that can be provided is to apply best efforts and be consistent with your other channels. That is the formal answer. The other avenue is that the DSB is working on the concept of 'Conventions' that could be used to document best practice. These conventions would not be binding but could be used as a form of general consensus on the best way to do things that are not prescribed in the standards. The application of type fields to various circumstances could be a an excellent use case for a convention. Would this be helpful?
247	Do Data Holders need to be sharing all 3 phases of Customer Reference Data before becoming an Accredited Data Recipient, or just be up-to-date in line with the phasing table?	Thanks for your query. Simply put, no, data holders do not need to be sharing all 3 phases of Customer Reference Data before becoming an accredited data recipient. Data holders only need to meet their obligations according to the phasing table. ADIs (as well as certain non-ADIs) are subject to reciprocal data holder obligations if accredited prior to the commencement of their requirement to disclose CDR data under the CDR Rules. For accredited ADIs the ACCC has deferred the commencement of reciprocal data holder obligations until 1 March 2021 (Phase 1) and 1 July 2021 (Phase 2 and Phase 3), as per our phasing table. The ACCC has committed to grant an exemption consistent with this deferred commencement of reciprocal data holder obligations for any ADR falling into this category.
251	We had a few questions around the requirements for the profile-related claims (name, given_name, family_name and updated_at) , listed at https://consumerdatastandardsaustralia.github.io/standards/#scopes-and-claims 1.The above are in the must-be supported list Question: Based on the guidance on the ID_Token under Tokens, The ID Token returned from the Authorisation End Point MUST NOT contain any Personal Information (PII) claims. Are we correct in inferring that the profile-related claims must be returned at both userinfo endpoint,as well, as in the ID_Token returned as part of the token response (request made to the /token endpoint )? How is the updated_at intended to be used by the client? we believe this is to indicate the time when user’s personal information was last updated in Dataholders backend systems? please confirm.	CDR Support Portal
253	As per the standards, the schema for BankingTransaction states that postingDateTime, valueDateTime and executionDateTime are expected to be DateTimeString. Further to that, the description for postingDateTime states: The time the transaction was posted. This field is Mandatory if the transaction has status POSTED. This is the time that appears on a standard statement We would like to understand what is the expectation for a case where a DH does not have the time of transaction available and it is not presented to customers in online banking or on statements (date is still shown)? Similarly, what about a case when a transaction time is captured as a system time on infrastructure which does not sit in AU? On a slight different note but relating to transaction API - is the expectation that the list of transactions shared via this API is mirroring what a customer would see on their online banking at a given time?	Q: We would like to understand what is the expectation for a case where a DH does not have the time of transaction available and it is not presented to customers in online banking or on statements (date is still shown)? A: This is up to the Data Holder. The recommendation is to pick a time (e.g. 00:00:00) and use that time consistently for all situations that meet these conditions. Q: Similarly, what about a case when a transaction time is captured as a system time on infrastructure which does not sit in AU? A: The DateTimeString allows for the specification of UTC time or a timezone based offset so all of these scenarios can be handled. The expectations would be set the date time correctly according to the normative RFC so that the date/time can be correctly interpreted. Q: On a slight different note but relating to transaction API - is the expectation that the list of transactions shared via this API is mirroring what a customer would see on their online banking at a given time? A: Yes, although there will of course be differences arising from the fact that Internet Banking sites are user interactive whereas an API payload is a raw representation without any presentation considerations applied.
254	We seek some feedback on a scenario when a customer informs a DH that their credit card was lost or stolen and asks for a card reissue, in which case a new card number would be generated for that customer. If the card was already a part of a sharing arrangement with an ADR: Would the new card number be treated essentially as "the same card", i.e. would the sharing arrangement continue seamlessly? If yes - would this mean that the accountId for this new card number would be the same as for the "old" card number? Also, if current digital experience in the lost/stolen scenario is that a card which is reported as lost/stolen is removed from online banking for a day until a new card is issued, should this behaviour be mirrored in the context of open banking?	It is the understanding of the DSB that most institutions have a clear distinction between a Credit Card Account and an issued card associated with that account. Many institutions offer the ability to have secondary cards, for instance, associated with the same account or to attach scheme debit cards to other account types such as transaction accounts. Also, the concept of data sharing is fundamentally distinct from the use of a card (in physical or tokenised form) for making purchases. The blocking of a card for making purchases is not understood to be a reason for removing the associated card account from data sharing. This may actually be a detrimental response for the consumer as the data sharing may be for a fraud analysis or PFM service that assists the consumer in identifying fraudulent transactions. In some cases, however, the account number for the account may be the PAN for the primary card so a card reissue may result in the changing of this number. If this action technically results in one account being closed and a new account being opened then the DH should treat it as such. In this case the old account should still be shared but as a closed account and the option for sharing the new account should be offered to the customer according to the CDR rules. If, however, this event is treated as a change to the account number but the account is still considered to be the same account (ie. other authorisations and transaction history is maintained) then the account should be considered the same account for the purposes of the standards. This is one of the advantages of the account ID concept in that it disconnects the identification of an account for CDR sharing purposes from any underlying identification idiosyncrasies arising from institution specific implementations or policies.
255	Can you please provide clarification about below fields as the description provided seems a bit vague and can have differing interpretations based on individual providers' internal systems: description - The transaction description as applied by the financial institution is this meant to be a simple description along the lines of "online banking transfer" or "ATM withdrawal" ? reference - The reference for the transaction provided by the originating institution. Empty string if no data provided is this meant to be a message a customer could potentially enter into a transaction or is this meant to be an internal reference number of a transaction?	CDR Support Portal
260	Can Data61 please clarify key selection algorithm for choosing encryption key from ADR's JWKS endpoint, i.e. how to determine which key should be used to encrypt ID token? Different participants will have different number of keys in different order used for signing and encryption, and different keys can have different parameters configured or not. GitHub issue for reference: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/350	The signing and encryption algorithms that are available for use for various tokens are not mandated by the CDR standards. The accepted algorithms by DHs and ADRs are exchanged via the OIDC Discovery and Client Registration protocols respectively, according to the normative standards. For instance, the 'id_token_encryption_alg_values_supported' field and 'id_token_encryption_enc_values_supported' field in OIDD are used to describe the capabilities of the DH and the 'id_token_encrypted_response_alg' (and similar fields) would be used during dynamic client registration for the ADR to select their preferred algorithm from this list. Note that half of this process is defined in the Register design and this should be considered alongside the standards for a complete picture.
266	We provide customers one of two hardware token types for access to internet banking depending on the customer type. In effect, personal account customers have one token (type 'A') and business customers have another (type 'B'). We have a few questions about the conformance of these existing tokens in relation to the CX Standards and CX Guidelines. CX Statement 1 (re: type 'A' token.) "The provided OTP MUST be numeric digits and be between 4 and 6 digits in length" For personal customers, they enter a known 5 digit pin from memory and their device responds with an 8 digit OTP. Would that device/process meet this requirement? CX Statement 1 (re: type 'B' token.) "The provided OTP MUST be numeric digits and be between 4 and 6 digits in length" For business customers, their OTP would be a combination of their personal 4-6 digit PIN from memory plus the six digits showing on their device, forming a code of 10-12 digits. Would that device/process meet this requirement? CX Statement 2. "Data holders MUST communicate the expiry period of the OTP to the consumer in the authentication flow." Does this also apply to hard tokens where - - the expiry may depend on user interaction, like entering an input code, (type A) - they automatically cycle codes and the token may be at any point in its cycle (the token may have its own 'time remaining' indicator though) (type B) and the exact expiry time may not be known in these asynchronous cases (i.e. where an SMS is not triggered immediately before the OTP screen is displayed as per CX Guidelines.) Statement 3. "The provided OTP MUST be used only for authentication for CDR based sharing and MUST NOT be usable for the authorisation of other transactions or actions" The tokens that customers already have and use provide access to their respective internet banking systems, but the code is for 'one time' authentication. Would these existing tokens meet this requirement? Statement 4. "In line with CDR Rule 4.24 on restrictions when asking CDR consumers to authorise disclosure of CDR data, unwarranted friction for OTP delivery is considered to include: - the addition of any requirements beyond normal data holder practices for verification code delivery" If the OTP details described in the statements above are non-compliant, would we be introducing "requirements beyond normal data holder practices for verification code delivery" if we adopted an new, alternative OTP method (SMS for example)?	Context: We provided customers one of two hardware token types for access to internet banking depending on the customer type. In effect, personal account customers have one token (type 'A') and business customers have another (type 'B'). Q: CX Statement 1 (re: type 'A' token.) "The provided OTP MUST be numeric digits and be between 4 and 6 digits in length" For personal customers, they enter a known 5 digit pin from memory and their device responds with an 8 digit OTP. Would that device/process meet this requirement? A: For clarity this isn't a CX statement. It is in the InfoSec profile. The answer is no. 8 digits is longer than 6 digits. That said, the original intent was to prevent absurdly long OTPs that would be a barrier to adoption and the DSB received very little feedback on the length of the OTP. If you would like to propose a change to the OTP length you can raise a change request. Q: CX Statement 1 (re: type 'B' token.) "The provided OTP MUST be numeric digits and be between 4 and 6 digits in length" For business customers, their OTP would be a combination of their personal 4-6 digit PIN from memory plus the six digits showing on their device, forming a code of 10-12 digits. Would that device/process meet this requirement? A: The same answer as above applies. Q: CX Statement 2. "Data holders MUST communicate the expiry period of the OTP to the consumer in the authentication flow." Does this also apply to hard tokens where - - the expiry may depend on user interaction, like entering an input code, (type A) - they automatically cycle codes and the token may be at any point in its cycle (the token may have its own 'time remaining' indicator though) (type B) and the exact expiry time may not be known in these asynchronous cases (i.e. where an SMS is not triggered immediately before the OTP screen is displayed as per CX Guidelines.) A: The intent of this is to indicate to the customer how much time they have to enter the code and still be able to validly continue the consent. The language is based on the assumption that a single OTP is being provided so the expiry of the OTP is the limiting factor. In your case the limiting factor is actually how long the customer has to enter the code before you consider the session expired (ie. I assume that if they left the window open for two hours and then entered a valid code you would already have timed out). I've spoken to Mike to confirm this is the intent of this standard. As above, if you would like to raise a change request on standards maintenance to prompt a clarification of the CX standards to reflect this we would welcome that. Q: Statement 3. "The provided OTP MUST be used only for authentication for CDR based sharing and MUST NOT be usable for the authorisation of other transactions or actions" The tokens that customers already have and use provide access to their respective internet banking systems, but the code is for 'one time' authentication. Would these existing tokens meet this requirement? A: The intent here is that token provided to a customer for another purpose (for instance a payment authorisation) can not be leveraged for CDR consent. Technically a hard token would not comply with this statement in the standards and would be invalid. The compensating controls of the short lifespan of a token code and the physical possession of the token would mitigate the issue being addressed in this statement, however. As above, a change request would be warranted. Q: Statement 4. "In line with CDR Rule 4.24 on restrictions when asking CDR consumers to authorise disclosure of CDR data, unwarranted friction for OTP delivery is considered to include: - the addition of any requirements beyond normal data holder practices for verification code delivery" If the OTP details described in the statements above are non-compliant, would we be introducing "requirements beyond normal data holder practices for verification code delivery" if we adopted an new, alternative OTP method (SMS for example)? A: No. While you would be non-compliant as described above the use of an existing token would not be additional friction as long as the CX was well managed and didn't include extraneous steps. It would simply be an alternate mechanism in the flow that is already included.

Response pending

Ticket #	Question	Answer
173	Appreciate if we could get some answers to these github issues. Expectations when a consumer closes their account/relationship with an ADR Issue 313	Taken on notice
189	I have been unable to find guidance on when a CDR Policy must be made available by Data Holders. A literal reading of the regulation would suggest that it should be made available as soon as any data sharing occurred (i.e 1 October for most data holders). However, the vast majority of a typical CDR Policy is only relevant for customer data sharing. Can you confirm that a Data Holder does not need to provide a CDR Policy until they begin customer data sharing?	Taken on notice
190	I am seeking guidance on how "wholesale" products are handled in the CDR. In this context I'm talking about products that are sold via alternative channels, but branded by the Data Holder. Examples would be term deposits sold through marketplaces such as Australian Money Market or Cashworkz, or loans sold through brokers. In these cases, the terms and conditions may differ from directly sold retail products. As the channels are generally not ADIs and therefore not Data Holders, I would assume any obligations would fall back on the product originating ADI. It's unclear if these products are "publicly available" under the CDR definitions as they are not sold directly by the ADIs concerned. Additionally, the terms and conditions can vary across the re-sellers and so if required, how should they be exposed in the PRD APIs? A separate entry for each re-seller, or a generic entry with, for example, no rates given? Any additional guidance around "wholesale" products sold through alternate channels would be appreciated. Thanks.	Taken on notice
192	We, are looking for clarity on requirements that are compulsory for account & transaction data on Phase 1 & 2 products, specifically for joint accounts. We understand that ACCC provided the Joint Account Guidance where scenarios are outlined. The question we have is on the status of Joint Account Guidance document – are the requirements derived from this document compulsory to implement, or only suggested but not compulsory? Specifically the next two requirements – are they compulsory to implement for account & transaction data on Phase 1 & 2 products release: 1. ‘Pause’ via JAMS (Scenario 4a & b) If one of Joint Account Holders removes an election via JAMS for an account that is already in an active sharing arrangement with 3rd party, authorisation should not be withdrawn, but the data sharing for that account should be stopped. Removal of election via JAMS for joint account does not cause removal of this account from authorisation. It only caused the data sharing to stop for this account. 2. Resume via JAMS (Scenario 4c & 7) After the requirement above, if both Joint Account Holders elect though JAMS for this same joint account that is ‘paused’ in an active sharing arrangement to be shared back (meaning this account is marked back as ‘available for data sharing’), the data sharing should continue as this account was never removed from authorisation in the first place.	Taken on notice
195	Could you please provide clarity about what “a product that is publicly offered” (under the ACCC CDR Rules) and “products that are currently openly offered to the market” (under the CDR Standards for Banking APIs) means when it comes to sharing required PRD. Specifically, if a phase 1 product is currently only offered by direct invitation to existing customers (i.e. not through online application channels), is PRD required to be shared?	Taken on notice
196	https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/329 https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/330	Taken on notice
204	Clarification on Data holder providing link to CDR policy: This question relates to Part 7 – Rules relating to privacy safeguards, section 7.2.1. According to this rule, a Data Holder (DH) will need to include details of the complaints process on the Consumer Data Right (CDR) policy.. The question is at which stage (wireframe) is the CDR policy expected to be shown on Data holder side. As per the CX guidelines, the CDR policy is only visible on the Data recipient Consumer dashboard as attached.	Taken on notice
208	Seeking further clarification with regards to the CDS rule - Part 5, Division 5.2 (Rule 5.10) which states that 5.10 Other conditions on accreditation (1) The Data Recipient Accreditor may, in writing: (a) impose any other condition on an accreditation: (i) at the time of accreditation under subsection 56CA(1) of the Act; or (ii) at any time after accreditation; and (b) vary or remove any conditions imposed under this rule. and that ... (5) The Accreditor: (a) may, but need not, give public notice of a condition or variation imposed or removed under this rule; and (b) may do so in any way that the Accreditor thinks fit. Example: The Accreditor could give public notice of a description of the effect of the conditions, rather than of the conditions themselves. Background: Given that these conditions could be varied and nebulous there is the potential of impact on data holders when engaging or providing CDR Data to an Accredited Data Recipient (ADR) As example - What if the condition is: 1. the ADR is only allowed access to a subset of CDR Data; or 2. only able to receive a particular period of CDR data; or 3. only able to hold authorisation for a particular period. Question: Due to the above are Data holders required to identify and comply with these conditions; and if there is a breach of a condition due to CDR data passed from a Data Holder to an ADR, where does liability sit? Adding some more clarification on the context related to the question, 1. Will these conditions placed on the ADR , be within the metadata update endpoint i.e. DH be informed of these new imposed conditions via metadata update? 2. Regardless of whether it’s in the metadata end point or not, who will be liable to ensure the correct information has been shared between the DR and the DH? a. Will it be on the DR – that they are only requesting the information they have been accredited for? b. If a DH has packaged information, and there is a data set in that package – is it up to the DR to only consume the information they are conditioned to or is it up the DH to remove the set of information DR is not allowed to access ?	-
209	Where there is a joint account with a Power Of Attorney, what are the rules around sharing data, when both parties are required to authorise the sharing of data? The Power of Attorney question also relates to individual accounts. Where a request has been made, however it has been made from the Power of Attorney, what rules apply to sharing the data? If we have deemed the transaction not be be causing financial or physical harm, is there an issue with sharing the data?	-
210	We have noticed the answer provided on ZenDesk in relation to the minimum product grandfather period (https://cdr-support.zendesk.com/hc/en-us/articles/900002707406-Minimum-Product-Grandfather-Period), which asked if there were criteria required for products which have been grandfathered. Based on the response that said “No. If the product is open or was closed for less than 12 months it should be included." We note that products can either be on-sale or not-for-sale (grandfathered). We therefore seek clarification on whether the intention of the previous response with respect to required consumer data is as in the attached table.	-
214	Wanting to confirm the following in the phasing table: 1. Part 4 for 1 Feb 2021: is this a MUST timeframe or can FI's fall back to the 1 July 2021 as the MUST date? 2. Part 3 for 1 July 2021: has it been finalised that CDR Consumers (customers/members of the bank) can request their information directly from the FI?	-

Notes

TBA

Question and answers

#	Question	Answer/ Action

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes (5th of November 2020)