Skip to content

ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 20th of January 2022

Jump to bottom
elizabetharnold edited this page Jan 27, 2022 · 10 revisions

ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes

When: Weekly every Thursday at 3pm-4.30pm AEDT
Location: WebEx, quick dial +61-2-9338-2221,,1650705270##

Meeting Details:

Desktop or Mobile Devices https://treasuryau.webex.com/treasuryau/j.php?MTID=m9614a7c6166155d3d950a8999e437f9f 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: 1650705270@webex.com

Phones - AUDIO ONLY

Agenda

  1. Introductions
  2. Actions
  3. CDR Stream updates
  4. Presentation
  5. Q&A
  6. Any other business

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.

Updates

Type Topic Update
Standards Version 1.15.0 Published Link to change log here
Maintenance 10th Maintenance Iteration To commence on 16th of February 2022
TSY Newsletter To subscribe to TSY Newsletter Link here
DSB Newsletter To subscribe to DSB Newsletter Link here
TSY Newsletter 13th of December 2021 View in browser here
DSB Newsletter 14th of January 2022 View in browser here
Consultation Normative Standards Review (2021) No Close Date
Link to consultation
Consultation Decision Proposal 222 - CX Standards : Insights and Trusted Adviser Disclosure Consents Feedback closes 21st of January 2022
Link to consultation
Consultation Decision Proposal 225 - Data Recipient Security Standards Feedback closes 18th of February 2022
Link to consultation
Consultation Decision Proposal 229 - CDR Participant Representation Placeholder: no close date
Link to consultation
CDR Support Portal Updated - Revised joint account implementation guidance CDR Support Portal Article

CDR Stream Updates

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

Organisation Stream Member
ACCC CDR Register Hopeson Chiao
ACCC CTS Andrea Gibney
ACCC Onboarding Christine Atkins
DSB CX Standards Eunice Ching
DSB Technical Standards - Register Ivan Hosgood
DSB Technical Standards - Energy Hemang Rathod
DSB Technical Standards - Banking Mark Verstege
DSB Technical Standards - Engineering James Bligh

Presentation

None.

Q&A

Questions will be received by the community via WebEx chat before the questions are opened to the floor. Participants can submit questions outside of the CDR Implementation Call to the CDR Support Portal.

We are using Sli.do for Question and Answer. Join our Q&A live here: https://www.sli.do/ Code: #169517

Answer provided

Ticket # Question Answer
803 With Reference to : https://cdr-register.github.io/register/#dynamic-client-registration
1. As a dataholder aiming to support LegalEntityId and LegalEntityName as part of the 1st of July implementation, can we assume that from the 1st of July, all DCR requests WILL include the legalEntityId and legalEntityName as part of the DCR Request (and the Optional bit is whether the Dataholder supports these values)?
2. Do Dataholders need to cater to both scenarios (DCR request may or may not include the legalEntityId and legalEntityName)?
Reading through the related article, it seems that the intent is that these values would always be available in the request, is this confirmed for 1st of July?
https://cdr-support.zendesk.com/hc/en-us/articles/360003965516?input_string=legalentityid+and+legalentityname+in+dcr+request
3.If the fields (legalEntityID and Name) are not modifiable, will these fields be included in a registration update request?		 Each question addressed below
Question 1. As a dataholder aiming to support LegalEntityId and LegalEntityName as part of the 1st of July implementation, can we assume that from the 1st of July, all DCR requests WILL include the legalEntityId and legalEntityName as part of the DCR Request (and the Optional bit is whether the Dataholder supports these values)?
DSB Response: legalEntityId and legalEntityName will always be returned as part of the DCR request.
Question 2. Do Dataholders need to cater to both scenarios (DCR request may or may not include the legalEntityId and legalEntityName)?
DSB Response: No. legalEntityId and legalEntityName will always be returned.
Question 3. If the fields (legalEntityID and Name) are not modifiable, will these fields be included in a registration update request?
DSB Response: SSAs are generated as part of a registration update request, therefore legalEntityId and legalEntityName will be provided during an update.
939 We are working with several non-ADI entities (ie. Commercial and Consumer Lenders) and we are trying to work out what their obligations and by when, are for participation in CDR and how.
We think the concept of a Reciprocal Data Holder applies to them, but are confused as to how it works and what they will need to have in place to comply with CDR participation. Your site suggests the following:
"An accredited person may be subject to reciprocal data holder obligations. This means that an accredited person may be required to share particular CDR data at particular times in accordance with the obligations of a data holder under the CDR Rules, separate to the obligations of an accredited person."
What is the difference between an "Accredited Person" and "Data Holder" obligations?
In our potential client scenario we see the entity (Lender) being someone - "where the data is generated in respect of a product that is publicly offered by the accredited person to consumers and generally known as one of the types of products in Phase 1, Phase 2 or Phase 3 products."
Therefore is the "Accredited Person" the entity offering the product and if so, how do they become "Accredited" and is it as a DH or ADR to be recognised as a "Reciprocal Data Holder"?		 An accredited data recipient will be a data holder for certain data where the entity holds data specified in the designation instrument and that data was not transferred to it under the consumer data rules (or derived from such data) [subsection 56AJ(3) of the Competition and Consumer Act].
This could occur where the accredited data recipient provides similar services to an entity listed in the designation instrument. For example, a non-ADI lender would hold transaction information about credit provided to its customers but as it is not an ADI it would not be a designated data holder under the relevant designation instrument.
Please note there is some information in the ACCC's revised Accreditation Guidelines on reciprocal data holder obligations that may assist with your enquiry. The revised Guidelines are available at https://www.cdr.gov.au/sites/default/files/2021-10/CDR-accreditation-guidelines-v3-published-29-October-2021.pdf
1072 This is with reference to the article on the subject
https://cdr-support.zendesk.com/hc/en-us/articles/360004324176-Data-Holder-sector-identifier-uri-Support
Wanted to clarify/confirm the validation that is required during the DCR process on the redirect_uris published at the sector-identifier-uri endpoint:
The DCR request is a nested JWT structure with the request payload containing an outer JWT structure request containing the SSA as an inner JWT.
So the DCR request could have the following
1. redirect_uris - DCR request - outer JWT ( optional )
2. redirect_uris - DCR request - inner JWT (SSA) (required)
3. sector-identifier-uri - DCR request - inner JWT (SSA) (optional)
Could you confirm if our understanding of the validation rules that need to be applied is correct?
A. Published redirect_uris should match or be a subset of the redirect_uris in the SSA
(this is the same as the validation that is applied to the redirect_uri in the outer JWT if supplied)
B. Published redirect_uri should match the redirect_uri (if supplied) in the outer JWT
C. If sector_identifier_uri provided in DCR request, and the endpoint is not reachable, should the DCR request be failed?		 I have extracted portions of your request into this response so I can answer each directly.
Regarding your interpretation of the DCR Request:
1. redirect_uris - DCR request - outer JWT ( optional )
DSB Response: This is correct
2. redirect_uris - DCR request - inner JWT (SSA) (required)
DSB Response: This is correct. The SSA is generated by the CDR Register based on the redirect_uris configured against the software product. As this field is mandatory, It is invalid for an SSA to be generated without these values
3. sector-identifier-uri - DCR request - inner JWT (SSA) (optional)
DSB Response: This is correct. The SSA is generated by the CDR Register based on the sector_identifier_uri configured against the software product. As the sector_identifier_uri is an optional field, if it is not configured, the SSA will simply be generated without this value.
I have extracted the following from OIDC Section 8 for reference:
When a sector_identifier_uri is provided, the host component of that URL is used as the Sector Identifier for the pairwise identifier calculation. The value of the sector_identifier_uri MUST be a URL using the https scheme that points to a JSON file containing an array of redirect_uri values. The values of the registered redirect_uris MUST be included in the elements of the array.
In the context of your questions, I have assumed when you say published redirect_uris, you mean redirect_uris published in the sector_identifier_uri JSON document.
Could you confirm if our understanding of the validation rules that need to be applied is correct?
A. Published redirect_uris should match or be a subset of the redirect_uris in the SSA
(this is the same as the validation that is applied to the redirect_uri in the outer JWT if supplied)
DSB Response: No. The values of the registered redirect_uris MUST be included in the elements of the array. This means that the published values are a superset of those used in the DCR process.
B. Published redirect_uri should match the redirect_uri (if supplied) in the outer JWT
DSB Response: Published redirect_uris are a superset of those in the SSA and the JWT. Therefore, they should match or the set is included in the published redirect_uris
C. If sector_identifier_uri provided in DCR request, and the endpoint is not reachable, should the DCR request be failed?
DSB Response: Yes. During registration, if the sector_identifier_uri is unreachable, POST and PUT requests to the register endpoint should fail. ADRs' sector_identifier_uri hosted endpoints are checked during the CTS.
1179 Sometimes, a corporate client may have accounts that are not normally visible/accessible in their online channel. Do these have to be included as part of consent as well ? Obviously, these accounts are accessible only to select users using other methods. Please note that the ACCC has recently released revised guidance on assessing whether a product is in scope for CDR (available at https://cdr-support.zendesk.com/hc/en-us/articles/900003420066-Guidance-for-data-holders-assessing-whether-a-product-is-in-scope-for-CDR). As set out in the guidance, we note that data holders must provide a service enabling an eligible CDR consumer to make consumer data requests in relation to the in-scope products provided to them by the data holder. The ACCC considers it appropriate for a data holder to meet CDR obligations by leveraging (at a minimum) its primary retail and primary business digital banking channels. An eligible consumer who does not ordinarily transact through one of the data holder’s CDR enabled banking channels but wishes to utilise the CDR for any publicly offered in-scope products it obtains from the data holder, must be given the option to access one of the primary digital banking channels to use the CDR.
The ACCC does not consider it reasonable for a data holder not to offer consumer data sharing for in-scope products on the basis that the product is not generally accessible via a primary retail or business banking digital channel where a consumer wishes to access the CDR for that product.
1197 Are the following correct values for Scheduled Payments response, [BankingScheduledPaymentInterval] for and :
1. where Frequency - DAIL fromDate - 2021-07-21
interval = P1D 		dayinterval = DO NOT RETURN as no response required for P1D
2. where Frequency - MNTH fromDate - 2021-07-21
interval = P1M
1204 Can you please help clarify the different of a Transfer Incoming and a Payment in the Transaction Category. E.g. Is a cheque deposit a Transfer Incoming or a Payment. Thank you Some general advice regarding the transaction type
TRANSFER_INCOMING is indented to represent a transfer payment into an account owned by the consumer;
TRANSFER_OUTGOING is intended to represent a payment to another account
PAYMENT is intended to represent an outgoing payment like a BPAY payment or credit card merchant payment
A PAYMENT shouldn't be incoming
For TRANSFER_OUTGOING and PAYMENT, the caveat is that this is data holder discretion. The difference between TRANSFER_OUTGOING and PAYMENT may be arbitrary for some rails like NPP
1240 Just reaching out to check this with CDR Technical operations as we are unsure how this relates to CDR standards.
Summary:
TLS renegotiation is enabled on our server and Fiskil was expecting it not to be. By temporarily enabling it on their end, Fiskil was able to bypass the issue.
Query :
Do we need to specify the disable flags in the registry on our server to NOT allow TLS renegotiation? Our server is not specifying the disable flag and is enabled hence expecting TLS renegotiation		 The Consumer Data Standards can't define all the transport layer requirements outside of those defined by FAPI.
However, Data Holders cannot add friction to the registration and data disclosure processes unless it is specified in the standards. In this scenario, If TLS renegotiation is to be enabled by data holders, which in turn adds friction to the ADR, then there needs to be a security requirement imposed on the standards. This would need to be discussed as part of the standards maintenance process.
1262 We have few questions on Account Details API response fields below :
1. In case where Term Deposit is already closed or matured then what would be the expectation to map 'maturityAmount' and 'maturityDate' for that closed/ matured TD in Account Details response schema.		 maturityAmount is optional. If there is no amount on maturity (it is closed) then this doesn't need to be provided. MaturityDate can be set to the date the term deposit matured. If the "BankingTermDepositAccount" object cannot be responded with compliantly, then you could omit the "termDeposit" and "specificAccountUType" fields in the response for the account details.
1277 just checking if there was a change request raised for the above requirement as per the recommendation given? We have a similar loan product with multiple-sub loans and seeking to understand the lending product is to be presented as part of BankingAccountDetail. There is a change request to address multiple balance loans for credit and lending products: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/292
This will be addressed in Maintenance Iteration 10 which kicks off on the 16th of February. If there are any representational changes that you believe are important to convey through the data standards I'd encourage you to raise a change request. Attending the maintenance iterations is an extremely useful opportunity to discuss and drive changes to the data standards so I'd recommend you attend those as well.
1278 What should be the response that is returned when the value of cdr-arrangement-id sent in the PAR request is equal to null or an empty string? a null cdr_arrangement_id should be ignored. The data standards do not require the cdr_arrangement_id to be presented in the request object:
The Data Recipient Software Product MAY provide the cdr_arrangement_id claim in the Request Object sent to the PAR End Point.
Behaviour for an empty string is not defined however it may be ignored or an error returned. For errors, this is covered by RFC9126 and RFC6749: a 400 Bad Request with "invalid_request" would be appropriate. You may provide further details of the error in the oAuth error response including the CDR error code (i.e. urn:au-cds:error:cds-all:Authorisation/InvalidArrangement) in the "error_description".
Refer to https://datatracker.ietf.org/doc/html/rfc6749#section-5.2 for details.
1291 CRN for individuals have 6 digits or more, and long enough to mask. However some CRN numbers are less then 6 digits and therefore unable to mask. In order to be compliant could you please provide information or a solution to ensure CDR compliance. The CRN description field says the following;
"Where the CRN contains sensitive information, it should be masked in line with how the Data Holder currently displays account identifiers in their existing online banking channels. If the contents of the CRN match the format of a Credit Card PAN they should be masked according to the rules applicable for MaskedPANString. If the contents are are otherwise sensitive, then it should be masked using the rules applicable for the MaskedAccountString common type."
Essentially, if the contents of the CRN are not sensitive then masking is not required. If it is sensitive then you have the option to match the masking you already do in other channels.
If this still doesn't help I would suggest raising a CR to update the description to allow for a sensible masking strategy.
1293 Following the release of 1.15 standards, can you please confirm when you are providing non-normative examples which align with the FAPI 1.0 transitions requirements? The DSB are happy to do so. If there are any non-normative examples you don't believe correspond to FAPI 1.0 please raise a change request on Standards Maintenance and we can address them in Maintenance Iteration 10 or via a patch release sooner if required.

Useful Links

View a number of informative and useful links in the Consumer Data Standards Implementation Guide on Information Links.

Getting Started

Meetings

Maintenance Iterations

CDR Implementation Call

Clone this wiki locally