Skip to content

ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 23rd of June 2022

Jump to bottom
CDR API Stream edited this page Jun 23, 2022 · 7 revisions

CDR Implementation Call Banner

Agenda & Meeting Notes

When: Weekly every Thursday at 3pm-4.30pm AEST
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.17.0 Published Link to change log here
Maintenance DSB Maintenance Iteration 11: Agenda & Meeting Notes on 22nd of June 2022 Link to the agenda and minutes
Maintenance Additional Meet on the 29th of June 2022 Invitation Sent out to Working Group
TSY Newsletter To subscribe to TSY Newsletter Link here
DSB Newsletter To subscribe to DSB Newsletter Link here
TSY Newsletter 10th of June 2022 View in browser here
DSB Newsletter 17th of June 2022 View in browser here
Consultation Normative Standards Review (2021) No Close Date
Link to consultation
Consultation Decision Proposal 229 - CDR Participant Representation Placeholder: no close date
Link to consultation
Consultation Decision Proposal 255 - Approach to Telco Sector Standards Link to consultation
Guidelines Minor revisions to the CX Guidelines for:
Consent Management (Data recipient): Collection and use consents
Consent Management (Data recipient): Withdrawal
Changes include slight updates to wireframes and minor addition/modifications to annotations.
CX Checklist (on website) updated to include these changes.
For more details, refer to the change log.		 Released 22nd of June 2022

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 Emma Harvey
ACCC CTS Andrea Gibney
DSB CX Standards Michael Palmyre
DSB Technical Standards - Register & MI11 Hemang Rathod
DSB Technical Standards - Banking Mark Verstege
DSB Technical Standards - Engineering Elizabeth Arnold

Presentation

The ACCC has provided open-source reference code and pre-built example code packages that simulate the CDR Register, data holders (banking and energy) and a data recipient and include automation and self-service capabilities. Participants can download these for use in their IT environment when developing and testing their own solutions. The CDR Sandbox expands on this work by providing a centralised, hosted, ecosystem environment containing versions of the mock solutions. Participants can join the CDR Sandbox ecosystem, where they can interact with the provided mock implementations and other CDR Sandbox participants.

The hosted CDR Sandbox is a free tool that provides an environment where:

  • potential CDR participants can investigate and learn in a mock ecosystem environment and assess the scope of work for a CDR solution project
  • prospective CDR participants can validate and test solutions before becoming accredited and commencing on-boarding to the CDR
  • sandbox participants can interact with mock solutions to assist with interpretation of the Standards
  • active CDR participants can interact with the hosted mock solutions to test solution changes, or interact with one another to investigate and resolve issues,
  • test data sharing scenarios can be explored with the mock solutions and with other sandbox participants

The ACCC will present an introduction and demonstration of the CDR Sandbox. The demonstration will focus on the registration, discovery, sandbox data holder and sandbox data recipient capabilities of the CDR Sandbox.

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.

Answer provided

Ticket # Question Answer
1252 Are there any specific guidelines for data holders to have two separate dashboards for individual (residential) and business accounts? Or is it upto the data holders on how to implement it? The ACCC has recently published this knowledge article that we believe will assist you in answering your question. We note that our nominated representatives, non-individuals and partnerships in the CDR guidance could also be of use too.
1382 For CDR in the Energy Sector.
As part of the Customer Authentication process (i.e. https://www.notion.so/Redirect-with-One-Time-Password-d0f7d66491444e0da800ffb03e69dd14), when prompting the Consumer for the User Identifier (aka Customer ID), can Data Holders ask the Consumer to enter 2 pieces of data to more accurately identify the Customer?
e.g. both "account number" and "mobile number"		 By preference, and expectation, it is expected that a single piece of information is used to uniquely identify a customer, however, there is the option for different types of information or for subsequent clarification so a specific profile can be determined (e.g. a personal profile vs a business profile that the same individual may have access to).
To a degree the answer is contextual. In the example you gave you suggest asking for a Customer ID and a mobile number. Are you suggesting you have two customers with the same Customer ID and can only separate them by mobile number (which sounds strange) or are you really trying to validate which one of the mobile numbers you have on file for a specific customer to use for the OTP.
If it is the former then yes this would be a valid approach but, since you are using the mobile number as part of the user identification, it would be problematic to also use it for OTP delivery.
If it is the latter then I would not recommend asking the user to free type the mobile number you are going to use for OTP unless you are going to ensure it is a phone number already on file as this would be a security risk.
1539 Just wanted to confirm what are the id permanence rules that apply in the case of Nominated Reps and Secondary users
Ex1: Nom Rep1 and Nom Rep 2 are nominated reps of Company A. Both have set up consents separately on behalf of the company with ADR A
ADR A makes a getAccounts API call using the arrangement setup with Rep 1 and then again with the arrangement setup with Rep 2
Should a different account PPID be returned in the response for both cases OR should the same PPID be used since the customer is the company?
What would be the PPID rules in the case of the secondary userS?		 First of all, to clarify, the terms PPID and ID Permanence are mixed up in your question. The PPID is a concept equivalent to the sub or subject claim in the OIDC specification. This is a normative standard and separate from the CDR standards. The ID Permanence rules apply to the CDR payloads, however, so the PPID and ID Permanence rules don't overlap.
The reason this is important is, if we don't separate the concepts, we get a circular reference. The PPID effectively defines the customer, whereas the ID Permanence rules require the same values across consents for the same customer (ie. it relies on the PPID value).
So, based on previous guidance, I will respond with two responses:
1.) For any single ID that ID Permanence rules apply to (e.g. Account ID, Service Point ID, etc) the value should different for the same entity if the Data Holder, Client (ie. Software Product) or Consumer (ie. PPID) are different. Same Data Holder and Client but a different PPID should mean a different value.
2.) The PPID should follow the rules set by OIDC and should be different unique for each consumer (per CDR Federation) section, not the authenticated user. This is never an issue for individual consumers as the authenticated user is the consumer. For non-individual consumers, however, the authenticated user is the nominated representative. So, if two nominated representatives set up a consent with the same Software Product then the same PPID would be issued as the PPID is linked to the underlying consumer that the representative represents.
1555 I am studying the mapping between CDS schemas and relevant UI displays in the CDR Providers page.
For a Data Recipient, I am thinking that the accreditationNumber is used for displaying the "Accreditation number" accompanying a Data Recipient, for example: ADRBNK000071 for Adatree Pty Ltd.
-> CDS API: "Get Data Recipients"
---> Response: ResponseRegisterDataRecipientList
-----> For each RegisterDataRecipient, there is an accreditationNumber.
However, for a Data Holder, I cannot find a data field in the CDS (I tried looking for something like providerNumber) which is used for displaying the "Provider number" accompanying a Data Holder in the CDR Providers page, for example: DHBNK000027 for AMP Bank Limited.
Could you please help instruct me on this?		 I'm afraid that the provider search is out of our scope and isn't bound by the standards so there is no guarantee that the "Provider Number" even appears in the register APIs.
if it does, however, it is most likely one of the IDs on the Get Data Holder Brands API. It will either be dataHolderBrandId or legalEntityId. I would guess the former.
If you would like confirmation, I would either contact the ACCC via email (as they manage the Registrar function) or ask this question on the weekly implementation call where ACCC personnel are in attendance.
1556 Just one more point to clarify. In the definitions (explanations) above, the word 'recurring' has been emphasised. Would a one time future dated payment be also considered as a scheduled Payment ? after-all a single payment also provides visibility to ADRs on the future state of the account. In response to your query, yes a single future dated payment would be considered a scheduled payment. The recurrence union in the scheduled payment structure has a onceOff variant specifically to accommodate this scenario.
1562 In GetCustomerDetails > Organisation, OrganisationType is mandatory with list of values.
As this information is unavailable in our system, we cannot provide. defaulting to OTHER may not be right too.
Can this field be made optional (to be consistent with energy lanagugage) or Can a new ENUM value be added as UNKNOWN?
I see some discussion happening in Issue #485 but I am not sure if related or different. Hence posting this as query for your clarification		 We can't respond to requests for change via the CDR Support Portal. They need to be raised on standards maintenance.
As this is likely to be urgent, I suggest making a comment on the holistic thread highlighting that, depending on the outcome of 485, the OrganisationType field needs to be made optional.
The link to the holistic thread is: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/511
1565 We are about to offer a product that has a fixed rate for the term of the loan arrangement.
Under GET Product Detail, the CDS requires the lending rate object to provide the fixed rate term in the additionalValue field when the lending rate type is FIXED. Can you please advise what period we should provide for this product as there is no preset fixed interest rate period. Instead, the product's rate will be fixed for the entire loan term (which itself is bespoke to each individual lending arrangement).		 This is a scenario that was not considered when the PRD schema was originally defined. Feedback from the banks at the time only indicated relatively short fixed rate terms.
I would suggest doing the following:
- Set the duration to the maximum length that the loan would be offered for (ie. if the loan would be 30 years maximum then set the value to PY30)
- Add a comment in the additionaInfo field indicating that the rate applies for the term of the loan
- Raise a CR in standards maintenance seeking a more permanent solution
1567 We are writing to query about the Data Holder Responsibility changes in Standards v1.17.0, where it says “If Data Holder do not receive a status for a Data Recipient or Data Recipient Software Product or receives a status that is not recognised. Data Holder should ignore the value and use the previous status value retrieved from the CDR Register. Data Holders should continue to use the previous status value until a valid value is returned by the CDR Register or the ACCC informs the Data Holder using an alternative mechanism.” And in the Issue 453 page, it says “Operational consideration on how participants are informed of missing or invalid statues are left for the ACCC to drive and are not part of the standards maintenance process.”
Does the above mean that the current Data Holder Responsibilities implementation does not need to cater for the ACCC’s alternative mechanism of informing the updated/valid status value? What if we continue to use the previous status value when CDR Register is unavailable while ACCC has informed an updated value through their alternative mechanism?		 The change was only meant to apply to the technical channel, not for additional out of band channels (that are not defined in the standards). I would expect that, if the ACCC verifiably reaches out to inform of an alternate status then that status should manually override the previous API value if there is an outage on the Register.
1568 We are writing to query about the changes of the x-v header requirement changes in Standards v1.17.0.
The standards is now require that: ”x-v requirements for versioned Register APIs moved from mandatory to optional”. But we noticed that the x-v header for the newly added GetDataHolderBrandSummary API is still remained as “Mandatory” in the Standards. Can we please confirm that this is correct?		 Yes that is correct.
The reason the x-v is optional on the older APIs is because for the initial implementation the x-v header was not included and many data holders have implemented to that spec. The goal of v1.17.0 was to rectify that situation for the new variants of the existing APIs. As the older versions get deprecated x-v will likely become mandatory again as per all other resource APIs in the CDR.
For the brand new API this history does not exist so there was no need to make an accommodation for transition.
1572 Assuming a data holder is not providing capability to support product data requests. In this scenario what is the data holder obligated to provide in the bi annual data holder report in relation to product data?
For example, Product Data Requests Received. Is the data holder expected to respond with 0, or the number received, even through they aren't responding?
Note:
The BiAnnual Data Holder report has fields for Product Data Requests
8. Number of product data requests received
11. Refusals in response to product data requests
See: https://www.accc.gov.au/system/files/CDR%20-%20Example%20of%20reporting%20form%20for%20data%20holders%20%28rule%209.4%29%20-%20v1.0_0.pdf 		A data holder can provide a ‘N/A’ response where a question is not relevant to them, for example, if they do not have a product data request service and therefore, do not receive product data requests. In the energy sector, where a data holder has elected to provide its own product data request service, it should therefore be reporting a value for number of product data requests received in a reporting period. If a data holder that has a product data request service has received no requests, then reporting a ‘0’ would be appropriate.
1577 Appreciate if the below points can be clarified for CDR representative model.
1. During the DCR process will the CDR Representative (along with software product) register with Data Holder or will it be CDR Principal?
2. If CDR representative performs DCR, how would a DH know when request for data sharing comes from CDR Principal on a valid collection and use consent by representative?
3. If CDR Principal performs DCR, how would a DH validate the CDR representative and SP details during consent authorisation?
4. In DH dashboard DR logo, DR name and SP would belong to CDR representative and the accredited ID would be from CDR Principal, is this correct understanding?		 I'd like to direct your attention to the following guidance regarding CDR representatives.
DSB Noting Paper – Representatives & Affiliates Conventions
https://github.com/ConsumerDataStandardsAustralia/standards/issues/228
ACCC Rules Guidance
https://cdr-support.zendesk.com/hc/en-us/articles/4415549259919-CDR-Representatives-Guidance
There are a number of options on the ways you can implement CDR representatives and the answers to your questions will depend on the models you choose.
1579 W.r.t to the Sch Payment endpoint, as I understand, the Data Holder has to send back currently active one-time or recurring payments to the ADRs. Some accounts however may have an outgoing sweeping arrangement (regular and variable amount) as setup in the back office and not necessarily visible / accessible to the user.
Would we need to send back such back-office sweeping arrangements to the ADR ?		 The scheduled payments API was not intended to represent sweeping arrangements, only specific payments set up by the user.
The listing of sweeping in Account Details as an active feature of the account though (ie. by using the OTHER enum value and specifying the sweeping arrangement in the additionalValue field).
1583 Following up on a question I raised today in the Implementation call about including errored responses in the average response time calculation for Get Metrics. I can find the below in the support portal.
Could you please confirm that timeouts should be excluded from the average response calculation but anything resulting in a valid error (eg a 404, 422) should be included? https://cdr-support.zendesk.com/hc/en-us/articles/900005261283-Inclusion-of-rejected-API-calls-in-Metrics 		The article you have linked to isn't about timeouts. It is specifically asking about rejection responses arising from NFR thresholds being exceeded (ie. the 429 response). There is no reason for this response to take a long time.
In the implementation call I suggested that API responses that timed out and therefore gave no practical response may need to be excluded as their response time could effectively be infinite so a single invocation that never responds would give an infinite average response for a period (even a month). If they are excluded from average response time they should still be counted as errors though. I think this is just common sense.
Ultimately, the real guidance would be to ensure that the APIs don't time out as that is bad.
1591 Is it possible to clarify the PRD obligation for Energy retailers (Data Holders)? In Schedule 4, Section 3.1 Meaning of required product data and voluntary product data—energy sector Note 2, https://www.legislation.gov.au/Details/F2022C00187 it states that AER and Victorian agency becomes data holders of required product data, does it translates to them needing to provide Get Generic Plans and Get Generic Plan Detail APIs described in the standards?
If the product reference data is being supplied by AER and Victorian agency, will the individual Energy retailers be required to also stand up these APIs? If so, which APIs should be consider as the source of truth? The one supplied by AER and Victorian agency or the one supplied by the Energy Retailer?		 We created a noting paper clarifying this situation. It can be found at: https://github.com/ConsumerDataStandardsAustralia/standards/issues/248

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