Skip to content

ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 26th of May 2022

Jump to bottom
CDR API Stream edited this page May 26, 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.170 Published Link to change log here
Standards Decision Proposal 237 - Maintenance Iteration 10
This decision was approved by the Data Standards Chair on 12 May 2022. The decision record is attached to the GitHub Issue		 Decision Proposal 237
Maintenance DSB Maintenance Iteration 11: Agenda & Meeting Notes on 25th of May 2022 Link to the agenda and minutes
TSY Newsletter To subscribe to TSY Newsletter Link here
DSB Newsletter To subscribe to DSB Newsletter Link here
TSY Newsletter 6th of April 2022 View in browser here
DSB Newsletter 20th of May 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 240 - ADR Metrics Feedback closes 27th of May 2022
Link to consultation
Consultation Decision Proposal 245 - Enhancing Data Recipient Accreditation Negotiation Feedback closes 27th of May 2022
Link to consultation
Video [25] Maintenance Iteration 11 - with Jarryd Judd (24/05/2022) Link to the Data Standards Body YouTube Channel

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 Preeti Patel
DSB CX Standards Michael Palmyre
DSB Technical Standards - Register Ivan Hosgood
DSB Technical Standards - Energy & MI11 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.

Answer provided

The following table will be updated after the meeting.

Ticket # Question Answer
1480 API - Get Balance - Energy Account
Re. the field 'balance' (i.e. the current balance of the account)
Our assumption is this is the customer’s current account balance, that is the balance at that point in time when the request is made. Is this the correct view? Or is the CDR obligation to align the 'balance' to the balance available via other channels? We note there are additional separate rules (based on certain scenarios - Payment plan, Payment status, amount value on the account etc.) of showing balances when it comes to other channels.
re. context that depends on the scenario - say a customer account is on Bill Smoothing, the account balance shown in Channel 1 – My Account (online portal) current balance would be the plan amount (e.g. fortnightly payment due). Whereas in Channel 2 – IVR (telephony), the current account balance will show the open amount to be paid (FPL9 balance). For example:
Bill Smoothing Plan is $50/fortnight.
Customer hasn’t paid 3 instalments, $150 overdue.
My Account will display $50/fortnight to be paid.
Whereas, IVR will prompt, $150 to be paid.		 It should return the outstanding amount to be paid, in the example it would return $150.
1511 Part 1 Refresh token revocation
When a token revocation is done, should the refresh token be revoked as well? If so, what is the error message to be returned for a token call using the refresh grant for a revoked access token?		 I assume you are talking about a revocation arising from a call to the OIDC token revocation endpoint. In this case, the client specifies the token to be revoked and if a refresh token is specified then it should be revoked.
Does this answer the question or are you talking about a different scenario?
1511 Part 2 Yes, I am referring to an OIDC token revocation scenario. In the event of a consent amendment or consent revocation, I believe both the access and refresh tokens must be revoked? In that case, Yes. If a consent is amended (ie a new consent is created with the same arrangement ID) or explicitly revoked all of the tokens associated with the consent should be revoked immediately.
1540 Format for masking of Card Numbers
Our solution currently provides Card masking format in line with masking as applied in other areas of our core banking system and utilises existing masking routines. This provides card numbers in the following format "**********1234" where all except the last 4 digits are masked.
This is in line with Data Standards defined for MaskedPANString with the exception that our system uses "" whereas the standards indicate an "X" should be used.
It has also been noted in the knowledge base article "Masking sensitive data ib transaction description detail" that data holders should abide by their standard practices.
Our system complies with the noted convention that Card numbers SHOULD be masked with the difference from the MaskedPANString description being that our standard system uses the asterisk character for masking.
Given the MaskedPANString provides this usage as a SHOULD (and not MUST) is the use of the asterisk character "" compliant with the standards given all other masking format is the same?		 Apologies for the confusion. This is a case where the language dates back to 2018 and was written before we started enforcing SHOULD and MUST more rigorously (hence the lower case use of the word). The guidance here should not be interpreted as a SHOULD it should be interpreted as a MUST. This is to ensure type consistency for ADRs who may well be applying a RegEx to these values to present it in their own way.
The statement regarding transaction detail is not applicable in this context as that applies to free form text where a customer may have written a PAN in the free form text field for some reason. Many banks scan for this and mask the number out in various ways. As this is not a strongly typed field the standards defer to common practice in this instance.
1543 Clarification regarding Profile Scope
1. As per the CDS v1.17.0 specification, ADR could either request for the OIDC profile which would include all the claims listed in name data cluster or one or multiple claims without using the profile scope. In a scenario where profile scope has been requested by an ADR in the original consent and on a consent amendment flow decides to remove the profile scope and include some claims in 'name' data cluster (and vice versa), do DH requires to pre-select the data cluster or the cluster is presented as not selected?
2. As per the guideline provided in below article[i] where additional information is required to display, Is it required to show the claims (in a consumer friendly wordings) in above scenarios where claims have been modified in a consent amendment flow or can a generic notification can be used to notify the change in claims. "e.g. The ADR has modified the required details under this data group".
3. And as per the change made on CDS v1.17.0 version on profile scope, does DH requires to display both 'Name' and 'Contact Details' data clusters if only the Profile scope is being sent by the ADR. Refer https://cdr-support.zendesk.com/hc/en-us/articles/4411787656975-Decision-Proposal-216-Profile-scope-support
Change for point 1: The data clusters are not pre-selected rather DH is required to identify the change in data clusters and tag them to notify the customer regarding changes.		 Regarding question 1, yes they would. From a data representation perspective the profile scope and the claims that OIDC define as included in that scope should be treated as synonymous.
Regarding question 2, I believe that the article indicates that the participant SHOULD provide additional guidance at their discretion (which means its an extremely good idea but up to you how you do it). You MUST, however, present the data cluster language according to the standards: https://consumerdatastandardsaustralia.github.io/standards/#profile-scope-and-standard-claims
Regarding question 3, no. The standards have been clarified that the contact language is only required if the additional contact claims are included in the consent.
1546 Part 1 CDR Imp Call 19/05 - Capacity assessment of the Get Usage for Service Point
Question raised on the CDR Implementation Call 19th of May 2022.
Regarding capacity analysis for https://consumerdatastandardsaustralia.github.io/standards/#get-usage-for-service-point
Size of payload and what analysis was done for a year or two of data. There is a potential for a large file size for 2 years worth of data with ~30mb size of file.
Question: was there consideration put on the capacity participants may need to support on this endpoint?		 We do some analysis with AEMO but it was desk checking only. Note that payload size is limited by the pagination rules so the largest possible single payload is 1000 records with each record being a full day of 5min interval reads. Since 5min reads always have a quality of ACTUAL (the default) this results in between 15 and 20 bytes per interval (noting that value may vary in size). Extrapolated out the worse case scenario was more the 5Mb mark. AEMO indicated that this was an edge case scenario, however.
We did discuss reducing the page size limit to 500 or 100 but there was not enough concern at the time to warrant it.
If this does cause a problem in actual practice we would certainly look to reduce the max page size for these payloads as the remedy (unless there is a better one).
1546 Part 2 Firstly, a bit of scene setting, it's hard to say without more insight however our staff went and asked DataHolder A for their data extracts. Most of them have smart meters (successive floods in SE Qld resulted in a lot of new meters) that are configured with register identifiers aligned to PEAK, OFF_PEAK and SHOULDER and seem to be 15 minute reads by default. Guidance from one of our customers this is "normal" with out of cycle reads (ie. PEAK register during OFF_PEAK time) being 0s. As a bit of simple math, for a simple configuration (no solar, export etc) this results in a single NMI, with a single meter, with three registers for up to 730 days with 96 reads per day at 15-20 bytes per interval. Total record count would be 2190 with each record being 1440+ bytes (15 byte * 96) resulting in ~1.4MB per page or ~3MB for total result set for 15 minute reads.
The concern here hasn't been so much the page size but more trying to manage the situation of the likely Data Recipient behaviour (similar to Get Transactions) where usage is downloaded from page 1 through to Max Pages automatically. In this case the total data size matters because it results in sustained throughput up to the NFR.
AEMO provisions MarketNet capacity per mbit ($17K/mbit/year) and this is shared for inbound read data (~3.2c/mbit/sec). That means the "typical" smart reader download is a direct cost of about 77c (assuming I haven't broken my math) and 1.4MB delivery on 1Mbit would be 10x the NFR which means MarketNet access would need to be provisioned at 10Mbit+ which is likely prohibitive for smaller retailers and realistically, 30+ concurrent reads would exceed the theoretical maximum of a network connection.
To be honest, I'm not sure what the go forward plan is here. I suspect an asynchronous job lodgement and then alternate retrieval may assist....		 t's an important issue to raise. An ADR may have no choice but to cycle through two years to facilitate their business case when a new consent is established so they can seed a full set. After that, however, they should only be requesting incremental data on a regular basis (which would be super small if done daily, even with 15min interval reads).
Certainly the intention here is to allow for the sharing of the designated data (which may be large) but to also provide reasonable NFR relief and to ensure that ADRs are not being anti-social and creating a real issue. If you have real data on issues that will arise feel free to raise a CR and we will consult on a change, either to the API itself or to the NFRs. Alternatively we could wait until later in the year and track what really occurs in production and provide the relief then with real world data.
1550 CDR register API Invalid Industry
I'm looking at GetDataRecipients API from CDR Register:
https://consumerdatastandardsaustralia.github.io/standards/includes/swagger/cds_register.yaml
```
/cdr-register/v1/{industry}/data-recipients:
get:
description:		 -
Endpoint used by participants to discover data recipients and associated brands and software products, available in the CDR ecosystem.
Obsolete versions: v2
operationId: GetDataRecipients
parameters:
- description: The industry the participant is retrieving data for (Banking,
etc)
explode: false
in: path
name: industry
required: true
schema:
enum:
- banking
- energy
- telco
- all
<br> When I try to use telco or even all I get the following error: <br>
curl https://api.cdr.gov.au/cdr-register/v1/telco/data-recipients
{
"errors": [
{
"code": "urn:au-cds:error:cds-register:Field/InvalidIndustry",
"title": "Invalid Industry",
"detail": "industry url parameter is invalid"
}
]
}

```
It seems that only banking can be provided as a valid industry. Is this expected?
953 Using an OSP once Accredited
If a non-ADI is accredited, and during the accreditation process they did not have an OSP in their CDR Data Environment Boundary, do they need to notify the ACCC if they subsequently start to share CDR data with an OSP.
Given they did not have an OSP at the time of accreditation, their OSP was not included as part of the carve-in assurance report and they did not have any of the Schedule 2 Part 1 controls on OSP management included in the scope of their assurance report. Do they therefore need to make any attestation, or have any additional assurance testing performed on their CDR Data Environment (including the controls at OSP)?		 Rule 5.14 requires an accredited person to notify the Data Recipient Accreditor (DRA) within 5 business days if, amongst other things, a material change in its circumstances that might affect its ability to comply with its obligations to take the steps identified in Schedule 2 of the CDR rules occurs. If an accredited person engages an OSP and it assesses that the engagement might impact its ability to take the steps in Schedule 2 of the Rules, it must notify the Data Recipient Accreditor accordingly. There is otherwise no obligation on the accredited person to formally notify the DRA of its new OSP if it is satisfied that the engagement of the OSP does not threaten its ability to take the steps in Schedule 2.
In addition to this, the accredited person will need to consider its OSPs when preparing its subsequent attestation statements and assurance reports.
955 OSP of an accredited OSP in scope for non-ADI assurance report
I understand that a non-ADI applicant requires an assurance report for Schedule 2 that 'carves in' OSPs for accreditation.
If the ADR applicant uses an accredited OSP, then the ADR assurance report can leverage the accreditation for the accredited OSP to demonstrate that the accredited OSP complies with Schedule 2 for the carve-in. However, if the accredited OSP has subsequent to their accreditation started to share CDR data with an unaccredited OSP, is the unaccredited OSP in scope for the ADR assurance report, given the unaccredited OSP has not had any independent assurance obtained over their compliance with Schedule 2 for the purposes of the 'carve-in'?		 In circumstances where an accredited OSP has started to share CDR data with an unaccredited OSP subsequent to the principal’s accreditation, we consider it appropriate for these new OSPs to be considered as relevant in subsequent assurance reports and attestation statements where control requirements that apply to the principal are performed by the outsourced service provider. We also note that accredited persons are liable for their OSPs’ acts and omissions, which includes OSPs sub-contracted by other OSPs, and we strongly encourage accredited persons to seek their own assurances about these parties’ CDR data environments.
1418 Joint Account Withdrawals
Thank you for taking the time to help answer/clarify the joint account withdrawal options.
The example scenario:
Candice and Perry have a joint account and the disclosure option set is 'Pre Approval' so when Candice shares data with ADR1, Perry's approval is automatic and the consent is established. After the consent with ADR1 has been active for a little while, Perry decides he wants to withdraw approval for the consent/authorisation with ADR1 but not opt out of sharing data for the joint account altogether, as they also have a consent/authorisation with ADR2 for the same joint account.
My question is:
Can Perry go to his dashboard and select the consent/authorisation with ADR1 and withdraw approval specifically for this one only? or is it only Candice who can do this since she was the one who created the consent in the first place?
Guidance in the JOint Account Guidance Document suggests:
9.3. A requester may withdraw their own authorisations, but they cannot withdraw the authorisations given by other account holders or secondary users.
(This point suggests that Candice is the only one who can withdraw the authorisation in this example?)
but another point mentions...
9.5. Non-requesting joint account holders must be allowed to withdraw an approval in relation to each authorisation to disclose joint account data. This applies regardless of whether there is a pre-approval or a co-approval disclosure option on the account. Withdrawing an approval means the data holder will stop sharing the joint account data in relation to the corresponding authorisation, it will not stop sharing joint account data in relation to other authorisations
(Does this point suggest Perry can withdraw an approval in relation to the authorisation with ADR1? or is saying Perry can only withdraw his "Pre-Approval" option?)
Choosing non-disclosure option means a joint account cannot be shared with any ADR, correct? so in this example scenario, consent/authorisations with ADR1 and ADR2 will cease?
It seems Perry has very limited control over specific consents/authorisations if he was not the one who initiated it, if Perry only has option to change to non-disclosure to stop sharing to a particular ADR.
CX guidance https://www.notion.so/Withdrawal-c2fa944134ff437cb6abc1d5675986fa seems to illustrate that Perry would be able to go in and withdraw the specific consent/authorisation with ADR1 but all other sharing arrangements with ADR2 would be unaffected?		 Thank you for this question. We encourage you to continue considering our Joint account implementation guidance which we think can be used to answer your question. However, to assist further we have added some inline responses below.
The example scenario:
Candice and Perry have a joint account and the disclosure option set is 'Pre Approval' so when Candice shares data with ADR1, Perry's approval is automatic and the consent is established. After the consent with ADR1 has been active for a little while, Perry decides he wants to withdraw approval for the consent/authorisation with ADR1 but not opt out of sharing data for the joint account altogether, as they also have a consent/authorisation with ADR2 for the same joint account.
My question is:
Can Perry go to his dashboard and select the consent/authorisation with ADR1 and withdraw approval specifically for this one only? or is it only Candice who can do this since she was the one who created the consent in the first place?
Assuming Candice has given an authorisation in relation to ADR1, Perry can withdraw his approval in relation to this authorisation (meaning sharing from the joint account with ADR1 under this authorisation would cease) but cannot withdraw Candice’s authorisation.
For more information, see the section under the heading ‘Withdrawal of approvals – stop sharing joint account data with a particular accredited person’ in our Joint account implementation guidance, particularly paragraph 9.7. It may also be helpful to revisit the definitions of ‘approval’ and ‘authorisation’ on page 5.
9.3. A requester may withdraw their own authorisations, but they cannot withdraw the authorisations given by other account holders or secondary users.
(This point suggests that Candice is the only one who can withdraw the authorisation in this example?)
Correct.
but another point mentions...
9.5. Non-requesting joint account holders must be allowed to withdraw an approval in relation to each authorisation to disclose joint account data. This applies regardless of whether there is a pre-approval or a co-approval disclosure option on the account. Withdrawing an approval means the data holder will stop sharing the joint account data in relation to the corresponding authorisation, it will not stop sharing joint account data in relation to other authorisations (Does this point suggest Perry can withdraw an approval in relation to the authorisation with ADR1? or is saying Perry can only withdraw his "Pre-Approval" option?)
Perry can withdraw his approval in relation to Candice’s authorisation to disclose CDR data to ADR1. The pre-approval disclosure option is a disclosure option and not an approval. See the definition of disclosure option at section 3 of the Joint account implementation guidance. Perry can independently apply a more restrictive disclosure option, such as the non-disclosure option. Applying this option would stop all disclosures from the joint account. See section 5 of our Joint account implementation guidance for more information in relation to disclosure options.
Choosing non-disclosure option means a joint account cannot be shared with any ADR, correct? so in this example scenario, consent/authorisations with ADR1 and ADR2 will cease?
The consents / authorisations will remain current but sharing from the joint account will cease because of the application of the non-disclosure option.
It seems Perry has very limited control over specific consents/authorisations if he was not the one who initiated it, if Perry only has option to change to non-disclosure to stop sharing to a particular ADR.
In addition to being able to apply the non-disclosure option, Perry may withdraw approvals in relation to specific authorisations given by other joint account holders.
CX guidance https://www.notion.so/Withdrawal-c2fa944134ff437cb6abc1d5675986fa seems to illustrate that Perry would be able to go in and withdraw the specific consent/authorisation with ADR1 but all other sharing arrangements with ADR2 would be unaffected?
Perry cannot withdraw consents or authorisations he has not given. Perry can withdraw an approval in relation to an authorisation.
1439 Raised and taken on notice 25th of March 2022:
Rules/OAIC guidance required on this one (data corrections related) -
As an example, if a customer calls and states we (as a DH) are sharing an incorrect mobile number, and if that mobile number shared is the same mobile number we have recorded in our source systems, should this type of scenario be handled using the CDR specific data correction process (incl. written notifications and SLAs) or BAU process to correct these errors?		 Clause 2.1 of schedule 3 to the CDR rules states that a person’s contact details, including their telephone number is considered customer data. Where incorrect data has been shared, Privacy Safeguard 13 would apply as required by s56EP of the Competition and Consumer Act 2010 and Rule 7.15 of the Rules.
The OAIC has published further guidance on Privacy Safeguard 13 here.
1464 How much historic data do we need to provide when a customer turns 18? At the point that the customer turns 18, we generally have the current and previous financial year of their data in our core banking system. Any data further back than that will be in our archive. When a customer turns 18 do we need to dig out this archived data to provide a full 7 years of historic data? According to the CDR Rules (Schedule 3, clause 3.2(4)(a)), transaction data is required consumer data for transactions that occurred within the previous 7 years. Therefore, once a consumer becomes eligible for the CDR, data holders are required to provide transaction data from that account dating back 7 years from the current date. Data holders are also able to provide a longer period of transaction data as voluntary consumer data.
1491 Account Privileges
In Part 2, 2.2 the definition of account privileges states - the person is able to make transactions on the account. Can you please confirm that make transactions means make financial transactions? Is such a definition the minimum that a DH must facilitate - ie could optional functionality be introduces whereby secondary users be appointed who have only read-only access to the account?		 Thank you for your question. As you have correctly identified, under the CDR Rules a person must be able to make transactions on the account to have account privileges (schedule 3, clause 2.2 of the CDR Rules). Our view is that a person with read-only access to an account would not be considered able to ‘make transactions’ on the account. This means that they would not be considered to have account privileges and would not fall within the definition of a secondary user (see rule 1.7). This means they could not be appointed as a secondary user under the CDR Rules.
1528 There are currently 2x zendesk articles referencing reporting post implementation of standardized error codes. The links provided below:
https://cdr-support.zendesk.com/hc/en-us/articles/360004722076-Reporting-Exemptions
https://cdr-support.zendesk.com/hc/en-us/articles/4523876174863-What-constitutes-a-refusal-to-disclose-required-data-
The first article states: “ Under the current data standards, where a data holder has refused to disclose CDR data in reliance on a data standard, it is expected that they will include the relevant HTTP response code set out in the standards. When the standards are updated to incorporate the standardised error codes, it will be expected that any relevant error code set out in the standards be included in the data holder’s report as applicable. “
However, the second article is explicit with details on codes applied for refusal to share data and which ones are applicable for reporting purposes.
We would like to confirm that when looking at bi-annual reports and the new standardized error codes do we refer to the second article instead of the first.		 We expect data holders to comply with the latest knowledge article as soon as possible. We have now archived the previous knowledge article – apologies for the confusion.
1548 Secondary User Instructions Timebound
Is there a maximum timeframe that a secondary user instruction is valid for? For example, if I make a secondary user instruction for Mary on my Savings Account, will that Secondary User Instruction expire after 12 months, so that I continually need to re-create it, or is the instruction going to last indefinitely until I withdraw it (or Mary becomes ineligible)?		 The CDR Rules do not provide for a maximum timeframe for which a secondary user instruction is valid. Therefore, in your example, your secondary user instruction for Mary will remain current until you withdraw the instruction under rule 1.13(1)(e)(ii) or rule 1.15(5)(b)(ii).
Please also refer to our ‘Secondary users in the banking sector FAQ document’ which provides further information in relation to secondary users – including information about what happens when a secondary user loses account privileges.

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