ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 1st of February 2024
When: Weekly every Thursday at 3pm-4:30pm AEDT
Location: Microsoft Teams
Meeting Details: Join on your computer, mobile app or room device Click here to join the meeting
Meeting ID: 446 019 435 001
Passcode: BU6uFg
Download Teams | Join on the web
Join with a video conferencing device
[email protected]
Video Conference ID: 133 133 341 4
Alternate VTC instructions
Or call in (audio only)
+61 2 9161 1229,,715805177# Australia, Sydney
Phone Conference ID: 715 805 177#
Find a local number | Reset PIN
Learn More | Meeting options
- 5 min will be al lowed for participants to join the call.
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.
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 [email protected] should they have any further questions or wish to have any material redacted from the record.
By participating in the Consumer Data Right Implementation Call you agree to the Community Guidelines. These guidelines intend to provide a safe and constructive space for members to discuss implementation topics with other participants and members of the ACCC and Data Standards Body.
⭐ indicates change from last week.
| Type | Topic | Update |
|---|---|---|
| Standards | Version 1.29.0 | Published: 21st December 2023 Change log |
| Maintenance | Maintenance Iteration 18 commences 7th February 2024 | Invitations issued Please reach out to [email protected] for an invitation |
| DSB Newsletter | To subscribe to DSB Newsletter | Link here |
| DSB Newsletter ⭐ | 19th of January 2024 | View in browser here |
| Consultation | Decision Proposal 229 - CDR Participant Representation | Placeholder: no close date Link to consultation |
| Consultation | Noting Paper 279 - Accessibility Improvement Plan | No Close Date Link to consultation |
| Consultation | Noting Paper 323 - NFR Workshops | Link to consultation |
| Engineering ⭐ | JS Holder SDK: The Github Repo has been updated to align to CDS version (1.28.0). | The relevant NPM package has been released in the NPM registry. |
Provides a weekly update on the activities of each CDR stream and their work.
| Organisation | Stream | Member |
|---|---|---|
| ACCC | Register and Accreditation Application Platform | Eva |
| ACCC | Conformance Test Suite & Participant Tooling | Christian |
| DSB | Consumer Experience | Michael |
| DSB | Engineering | Sumaya |
None this week.
Questions will be received by the community via Microsoft Teams chat before the questions are opened to the floor. Participants can submit questions outside of the CDR Implementation Call to the CDR Support Portal.
In regards to topics for questions, we ask the participants on the call to consider the Community Guidelines when posing questions to the subject matter experts.
| Ticket # | Question | Answer |
|---|---|---|
| 2195 Part 1 | As per the CDS, the maximum page size is 1000 records. I just want to confirm that an ADR can call the 'Get Billing For Account' endpoint with a page size of 1000 records and the threshold is 1.5 seconds? For simplicity, lets assume this is the only API that hour. If so, is it possible to set our own max page size that is determined by what we know our system can achieve for the nominated thresholds? (It would be higher than the default of 25) |
No, the max page size is defined in the standards specifically to avoid data holder specific page size caps. |
| 2195 Part 2 | Was it designed so that a request for 1000 records would be an outliner and therefore would likely fall into the 5% of calls w.r.t performance requirements? It would be quite ambitious to design for every request to be 1000 records. Have any other data holders raised concerns about this? |
It was actually designed that way to allow for batch (or non-interactive) requests. These can be identified by the DH and have a different response time expectation on purpose. If an ADR is requested 1000 records per page in an interactive context then I dread to see their user experience and I would suspect it would be breach of their 'don't be anti-social' NFR. Is that occurring currently? |
| 2218 | The previousDays property is an array of NaturalNumber (although the data standards show '[object]'), so the examples should use '[0]' rather than '0'. Please let me know if I should raise a change proposal to correct the data standards from '[object]' to '[NaturalNumber]'. It would also be useful to know whether an empty array is permissible, since the sentence in the description for previousDays only mentions the maximum: 'A maximum of seven entries is required if available'. On the first day of operation after implementation there will be no value available for yesterday, so an empty array would be accurate. |
Issue 348 Included in Version 1.29.0: reflect the correct x-cds-types, from '[integer]' to '[NaturalNumber]' |
| 2224 | Thanks for this. Just to clarify further as this guidance article doesn't explicitly outline it, for calls passed through to the secondary data holder, is the calculation method for the response time EXCLUDING the secondary data holder response times? For instance if a call comes into Get Usage, requires 2 secondary data holder calls each taking 1 second and the total time end to end for the call is 2.5 seconds is the calculated response times as follows: AverageResponseMetricsV2 .primary: 2.5 seconds total - (2 x 1 second per SDH call) = 0.5 seconds? AverageResponseMetricsV2 .secondary: 2 x 1 second = 1 second ? |
It’s not clear what you mean by excluding secondary data holder (SDH) times. If you mean that the primary data holder (PDH) average response times should exclude SDH times, then that is correct. An example formula would be like below: Average Response Time = response time taken by DH (if PDH, excludes SDH and vice versa) / number of API calls Using that in your example we get the following: AverageResponseMetricsV2.secondary.primary = 0.5 / 1 = 0.5 AverageResponseMetricsV2.secondary.secondary = 2 / 2 = 1 Let us know if you see any gaps or incorrect insight that may result from this |
| 2231 | We have a query in relation to the “PerformanceMetrics” schema for Get Metrics v5. The latest CDS release on Github, doesn’t show the category ‘authenticated’ for the schema (refer PerformanceMetricsV3 – Consumer Data Standards (consumerdatastandardsaustralia.github.io)), whereas the approved decision proposal #288 shows that in the example and also states that the split should be similar to ‘InvocationMetrics’ break-up. | The performance metrics should align to the NFR tiers and therefore should not have an authenticated tier as authenticated calls are broken down into highPriority, lowPriority, etc. The sample in the decision doc is, unfortunately, erroneous due to a cut and paste error but the actual text of the decision is accurate, as are the standards themselves. |
| 2241 | We are keen to understand how DH’s are interpreting the oldest-time parameter in calls such as Get Transactions for Account. The official definition is as follows: Constrain the transaction history request to transactions with effective time at or after this date/time. If absent defaults to newest-time minus 90 days. Format is aligned to DateTimeString common type We have not been able to find a definition for “effective time”. Based on our understanding it should be equivalent to a “modified date”, but we have found scenarios where at least one DH appears to be treating this as “execution time”. This caused issues over the Xmas/NY public holidays where transactions appeared in the feed late and we missed them as we only poll DH’s over a 2-3 day rolling window. |
There is a definition for 'effective date' in the standards at the top of the Get Transactions For Account endpoint. To quote, it says: As the date and time for a transaction can alter depending on status and transaction type two separate date/times are included in the payload. There are still some scenarios where neither of these time stamps is available. For the purpose of filtering and ordering it is expected that the data holder will use the "effective" date/time which will be defined as: Posted date/time if available, then Execution date/time if available, then A reasonable date/time nominated by the data holder using internal data structures For context, the reason for the obvious ambiguity here is that there is no real standardised handling of transaction timestamps in the various core banking systems used by the different banks. The standards had to allow for the variability in these implementations. If the DH you are referring to is including postingDateTime but is filtering on executionDateTime then I would consider that to be non-compliant with the plain reading of the above statements. If they don't actually present postingDateTime then their behaviour would seem to be compliant. |
Attendees are invited to raise topics related to the Consumer Data Right that would benefit from the DSB and ACCCs' consideration.
View a number of informative and useful links in the Consumer Data Standards Guide on Information Links.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
|
 |
 |
 |