-
Notifications
You must be signed in to change notification settings - Fork 56
ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes (10th of December 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
- Introductions
- Actions
- CDR Stream updates
- Q&A
- Any other business
Meeting notes
- 5 min will be allowed for participants to join the call.
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.
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.
| Type | Topic | Update |
|---|---|---|
| Standards | Version 1.5.1 Published | Link to change log here |
| Standards | Version 1.6.0 Drafted | Link to Project Board with proposed changeshere |
| Standards | Version 1.7.0 Proposed | Link to Project Board with proposed changeshere |
| Maintenance | 5th Maintenance Iteration has wrapped up for 2020 | List of scope and agenda(s) can be found here |
| DSB Newsletter | To subscribe to DSB Newsletter | Link here |
| ACCC Newsletter | To subscribe to ACCC Newsletter | Link here |
| 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 |
| Events | 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 |
| Events | DSB Data Quality Workshop 02 : Data Conventions | Register here on Eventbrite |
| Feature | Articles changed/ published in the last seven days | CDR Support Portal |
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
No presentation this week.
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:
| Ticket # | Question | Answer |
|---|---|---|
| 52 |
ANZ is looking for some clarity around log retention requirements. Based on the rules section 9.3 (1)(e) and 9.3 (3) highlighted below a data holder would be required to keep logs of instances where CDR data has not been disclosed in reliance of an exemption from the obligation to disclose for 6 years. As we understand it this exemption would include where we protect our system from malicious behaviour or high volumes (aligned to the NFRs) which would risk our platforms. Given these controls are generally performed at the first entry point to a data holder like a web application firewall (WAF) the data within these logs would be subject to the security controls of the regime. We are wondering if keeping the full log detail of these requests holds any value to the regime, we say this because at the point of capture the detail in this log cannot be tied back to a particular customer as the only thing that is present is a short lived access token which won’t have relevance to the customer until exchanged in the DH’s IDP. We understand these records are valuable in assisting construct counts for the reports and metrics endpoints but is the whole record mandatory or could we just keep a collection of the aggregated count information? There is also some concern from security teams over the nature of the data in these logs which may indicate attack information or potential threat vectors and this information should only be kept for a period of time (12-18 months) and then purged from the records. Please note: regardless of the WAF records decision, all refusals subsequent to WAF (within the ANZ domain) will be recorded. Given the concerns around the security and the real value of these logs we feel this requirement may need to be reviewed/revisited or simply clarified if we have understood this incorrectly. CDR Rule 9.3 - Records to be kept and maintained Records to be kept and maintained – Data holder (1)A data holder must keep and maintain records that record and explain the following: (d) disclosures of CDR data made in response to consumer data requests; (e) instances where CDR data has not been disclosed in reliance on an exemption from the obligation to disclose CDR data; Specificity of records (3) Each record referred to in this rule must include the date and time when the record was made and, if applicable, the date and time when the event described by the record occurred. Period for retention of records (5) Each record referred to in this rule must be kept for a period of 6years beginning on the day the record was created. Regulatory reporting requirements defined in the data holder reporting form:
A reference to 'requests you received' includes all requests you received, regardless of whether the request was successful or not.
A reference to a 'refusal' to disclose CDR data is intended to cover all refusals to disclose CDR data. For the avoidance of doubt, circumstances where the data holder must report on the number of refusals to disclose CDR data include for technical reasons, refusals where it is considered necessary to prevent physical or financial harm or abuse, and refusals where the data holder has reasonable grounds to believe disclosure of some or all of the requested CDR data would adversely impact the security, integrity or stability to the Register of Accredited Persons or the data holder's ICT systems, and any other reason the data holder has not disclosed CDR data in response to a request. |
CDR Support Portal Article |
| 203 | The response addresses the continued support for V2, which currently has no published end-date. End-date for Version 2 aside, we still have a scenario where we need to go live with Phase 2 PRD on Feb 1st, and then enable V3 by Feb 28th. This may be more of a question for the ACCC, as it would simplify things if the Feb 1st ACCC date for Phase 2 PRD, was shifted by 28 days, to align to the DSB V3 date of Feb 28th. Then the “other adi” sector could go live with Phase 2 PRD at the same time as we go live with V3, and do a single release instead of two releases. We understand that we would also need to support V2, but we’re trying to avoid multiple releases where possible, and would like to see alignment between the ACCC & DSB obligation dates. Is this something that can be considered and discussed with the ACCC please? |
Thanks for your query. Noting James Bligh's earlier response on compliance dates, we can confirm that the ACCC does not intend to shift phase 2 product reference data obligations will shift from 1 February 2021. We acknowledge your feedback and will continue to consider appropriate and reasonable compliance dates as CDR rollout continues. Please do not hesitate to reach out if you would like to discuss further. |
| 279 | Can you please confirm the list of Testing phases which are mandatory for non-major bank? Or for a bank that is planning to go-live as Data Holder in Mid-2021. It was announced in one of the meetings held in Oct 2021 regarding Conformance Test Suite that Industrial testing is now out of scope/non-mandatory testing phase for Data Holders. Can you please confirm what else is no marked as non-mandatory. | CDR Support Portal Article |
| 309 | collection arrangements of multiple ADRs, So what happens on the ADR side if there is a reseller of an Intermediaries solution? Eg. Intermediary sells their services to another accredited body who provides a CDR solution to another ADR? Are there then multiple certificates at the DH sold? Are all parties disclosed to the DH? | At present, a collection arrangement can only occur between two ADRs and cannot be further sub-contracted (see rule 1.10(2)(b)(iv)). |
| 342 | One of our ADI clients has raised some questions about sharing account data for businesses. The challenge they have is that they cannot easily identify ‘owners’ of business accounts. Typically, they would setup owners to have a ‘signatory’ relationship to the business account. So, they cannot differentiate the ‘owners’ from other parties, e.g. employees who are also authorised to transact on the account. Even for a sole-trader, they would typically setup the owner to have a ‘signatory’ relationship to the account, rather than an ‘owner’ relationship. So, for business accounts with only ‘signatory’ relationships, is the FI still obligated to share the account data? Are the current rules intended to allow business accounts to be shared if they are singly-owned or jointly-owned? Is the ACCC planning to revise the rules for sharing business account data in future? |
Yes, under the current rules, a person is eligible to share CDR data from an account if they are (a) an individual who is 18 years of age or older, and (b) the account holder. (See Schedule 3, Part 2, which also contains a few other eligibility conditions). You're correct that data must be shared from accounts held by an individual, or jointly with one other individual (Schedule 3, clause 3.2). We therefore expect that for business consumers who are individuals, accounts falling within the scope of these provisions would be enabled for sharing in accordance with the current rules. For example, an account held by an individual who was a sole trader would be within scope, and should be enabled for sharing. The ACCC recently consulted on revised rules to enable sharing by more business consumers, including non-individual consumers (such as bodies corporate) and more complex business partnerships (link). This also contains information about implementation issues relating to accounts held jointly by two individuals for business purposes, which you may find useful. The intention of the proposed rules is to provide a route for business customers to nominate, to their data holder(s), one or more representatives with authority to share CDR data. We are now considering the responses we received and will make a decision about whether to revise the rules in due course. |
| 343 | In regards to CDR Support Article If we currently use hard tokens for internet banking OTP and start using SMS for Open Banking, would that be considered as introducing "requirements beyond normal data holder practices for verification code delivery"? "the use of an existing token would not be additional friction" I'm asking about if we changed to a new method (SMS) for Open Banking, which may be different to what customers currently use for Internet Banking. Did you mean - "the use of an SMS would not be additional friction" ? |
The using of the term "existing token" was specific in the response. The standards require that the OTP mechanism is one that the customer would already be familiar with and not newly created just for CDR. This was based on feedback from the UK where banks introduced new authentication mechanisms just for CDR and this caused friction and adoption problems. As a result, the introduction of a new OTP mechanisms for multiple digital channels, including CDR, would be compliant. The introduction of a new OTP mechanism just for CDR would not. |
| 344 | Our consumer dashboard shows our customers/members their expired and withdrawn consents. Is there a minimum duration that we are required to display these - or can they be purged once expired/withdrawn? | There is nothing on this topic in the standards. In the rules, however, clause 1.14 and 1.15 specify that all established consents should be shown and includes the statement "if the consent is not current—when it expired". This explicitly indicates that expired consents should also be presented. As there is no clause indicating when this requirement expires it would appear that there is no provision in the rules for the purging of expired or revoked consents. Clearly, the removal of a consent immediately on expiration or revocation would not be aligned with these clauses in the rules. |
| 345 | In CDS page, X-V and X-min-V request headers are referred as Type string, but in description section it is stated that “ X-V Must be set to a positive integer”. Can you please clarify weather X-V & X-min-V request header are string or positive integer type ?? My second question is around response header parameter x-v, Suppose we have built version 1 (x-v=1) of the API, and request header has x-v=0001, then what is the expected behaviours- Request is valid and response header is x-v =1 Request is Invalid 400 Bad Request, as we support x-v=1 Request is valid and response header is x-v=0001 |
Q: In CDS page, X-V and X-min-V request headers are referred as Type string, but in description section it is stated that “ X-V Must be set to a positive integer”. Can you please clarify weather X-V & X-min-V request header are string or positive integer type ?? A: Technically, all headers are strings. Unlike in the JSON specification, the HTTP specification does not make a distinction for headers between numbers and strings. As a result both statements are correct in context. To be clear, the requirement is to populate a HTTP header with a positive integer value Q: My second question is around response header parameter x-v, Suppose we have built version 1 (x-v=1) of the API, and request header has x-v=0001, then what is the expected behaviours- Request is valid and response header is x-v =1 Request is Invalid 400 Bad Request, as we support x-v=1 Request is valid and response header is x-v=0001 A: Under the principle of providing a good, tolerant server implementation the best response is option 1. The standards do not require leading zeroes for a positive integer but equally they do not preclude leading zeroes. As a result treating this an error would be an over interpretation and not aligned with the intent. If you are building an ADR solution, however, I would not recommend to include leading zeroes. |
| 348 | Can you please confirm if below understanding related to average TPS and peak TPS are correct or not? * Hourly Transaction Per Seconds is calculated by dividing total requests count with 3600. * Average TPS metrics will be calculated through below formula - Average TPS Metrics = Sum (hourly TPS for a day)/24 * Peak TPS metrics is calculated from hourly TPS calculated for Average TPS metrics Peak TPS Metrics = Max (hourly TPS for a day) |
Q: Can you please clarify if below understanding related to Average TPS and Peak TPS metrics is correct or not ? * Hourly Transaction Per Seconds is calculated by dividing total requests count with 3600 * Average TPS metrics will be calculated through below formula - Average TPS Metrics = Sum (hourly TPS for a day)/24 * Peak TPS metrics is calculated from hourly TPS calculated for Average TPS metrics Peak TPS Metrics = Max (hourly TPS for a day) A: There is no such thing as Hourly Transaction Per Second as a metric. What you have represent is Transactions Per Hour divided by 3600 which removes all of the granularity that would be expected to be available for a TPS calculation. This is demonstrated by your proposal for the peak metric. Your calculation for Average TPS for a day would be satisfactory but your calculation of peak TPS would be misleading as the peak would be smoothed over an hour's worth of data. If there were 1000 transactions in an hour but they all occurred at the same time you should report a peak of 1000 TPS but instead you would report a pea of 0.3 TPS. This demonstrates the inadequacy of hourly aggregation. If you are concerned about the calculation overhead for TPS it would be acceptable to aggregate to the minute and still obtain reasonable results, and this is often done in the industry, but any aggregation above a minute would be misleading. |
| 353 | Why would specificAccountUType be limited to just termDeposit, creditCard and loan? If I am interpreting the purpose of this correctly, how would an account not falling into these categories, such as Savings account or Transaction account be categorized in a getAccountDetail API? | The specificAccountUType field, as with all fields with the UType suffix, is not an identifier of the type of the record (in this case an account). These fields are discriminators for the schema to identify which one of a series of optional structures will be present. As we have only included the termDeposit, creditCard and loan structures for additional inclusion that is all that is included in the specificAccountUType enum list. If you are looking for a more comprehensive account type field please refer to the productCategory field. This enum is intended to categories the account into a series of account categories and does include the additional types you reference. |
| 354 | occupationCodeVersion The applicable ANZSCO release version of the occupation code provided. Mandatory if an occupationCode is supplied. If occupationCode is supplied but occupationCodeVersion is absent, default is ANZSCO_1220.0_2013_V1.2 It appears to state that occupationCodeVersion is mandatory if occupationCode is specified. However, the second part seems to suggest that if the code is specified and version is absent a default is assumed. Can this be clarified? |
The statement you reference is misleading but was including to assist in backwards compatibility. We were conscious that some DHs may have already built this end point for the November implementation without the version field added (it was a later addition). We did not want to introduce a v2 before the end point had even gone live for v1 as this would have added additional overhead for all DHs. As a result we included the default value behaviour to accommodate transition. We could probably do a better job with the description, however. We will look at fixing this up in the future. |
| Ticket # | Question | Answer |
|---|---|---|
| 107 | Answer in progress | |
| 139 | Answer in progress | |
| 174 | Answer in progress | |
| 189 | Answer in progress | |
| 196 | Answer in progress | |
| 203 | Answer in progress | |
| 209 | Answer in progress | |
| 214 | Answer in progress | |
| 221 | Answer in progress | |
| 225 | Answer in progress | |
| 232 | Answer in progress | |
| 244 | Answer in progress | |
| 250 | Answer in progress | |
| 256 | Answer in progress | |
| 257 | Answer in progress | |
| 259 | Answer in progress | |
| 261 | Answer in progress | |
| 263 | Answer in progress | |
| 265 | Answer in progress | |
| 268 | Answer in progress | |
| 283 | Answer in progress | |
| 290 | Answer in progress | |
| 291 | Answer in progress | |
| 292 | Answer in progress | |
| 293 | Answer in progress | |
| 299 | Answer in progress | |
| 301 | Answer in progress | |
| 303 | Answer in progress | |
| 308 | Answer in progress | |
| 310 | Answer in progress | |
| 311 | Answer in progress | |
| 312 | Answer in progress | |
| 318 | Answer in progress | |
| 319 | Answer in progress | |
| 321 | Answer in progress | |
| 323 | Answer in progress | |
| 324 | Answer in progress | |
| 329 | Answer in progress | |
| 331 | Answer in progress | |
| 333 | Answer in progress | |
| 334 | Answer in progress | |
| 335 | Answer in progress | |
| 336 | Answer in progress | |
| 337 | Answer in progress | |
| 338 | Answer in progress | |
| 339 | Answer in progress | |
| 340 | Answer in progress | |
| 341 | Answer in progress | |
| 346 | Answer in progress | |
| 347 | Answer in progress | |
| 350 | Answer in progress | |
| 351 | Answer in progress |
- TBA
| # | Question | Answer/ Action |
|---|---|---|
Other business
- TBA
- TBA
- TBA