ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 21 November 2024
When: Weekly every Thursday at 3pm-4:30pm AEST
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 allowed 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 and present, 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 | Updated | Links |
|---|---|---|
| Standards | Version 1.32.0 | Published: 21st of October 2024 Change log |
| Standards | Version 1.33.0 | Coming soon |
| Maintenance ⭐ | Iteration 21 Schedule: |
MI 21 complete for 2024! Thank you everyone who contributed to these forums |
| Maintenance | Iteration 22 to commence in February 2025 | Registrations and invitations to be issued first week of December |
| DSB Newsletter | To subscribe to DSB Newsletter | Link here |
| DSB Newsletter ⭐ | 15 November 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 |
| Consultation | Noting Paper 355 - Deceptive Patterns Independent Health Check | No feedback sought Link to Noting Paper |
| Consultation | Noting Paper 357 - LCCD Benefit Workshop Summary | No feedback sought Link to Noting Paper |
| Consultation | Noting Paper 359 - Deceptive Patterns Health Check - Next Steps | No feedback sought Link to Noting Paper |
| End of Year | Calls remaining in 2024: - - - 28 November 2024 - 5 December 2024 |
Return on 16 January 2025 |
Provides a weekly update on the activities of each CDR stream and their work.
| Organisation | Stream | Member |
|---|
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 |
|---|---|---|
| 2369 | This question concerns the Get Metrics endpoint. For most endpoints in the CDR spec, the x-fapi-interaction-id header is listed. The value in this header is what we use to identify individual API requests, which is necessary for support and troubleshooting if an ADR runs into a technical issue. However, this header is not present for Get Metrics. What is the recommended approach for uniquely identifying API requests on this endpoint, so that if the government regulator encounters issues calling Get Metrics, we can properly troubleshoot? | The Get Metrics endpoint is not customer-authenticated, so it hasn't had the same FAPI elements applied to it as the other 'consumer' resource endpoints. Where necessary, a couple of Consumer Data Standards-specific headers have been created, including - x-cds-client-headers x-cds-arrangement If you feel there is a need to have a header specified for for Get Metrics it may be worth raising a Change Request through the Standards Maintenance process. Options may be to apply x-fapi-interaction-id to that endpoint or create a new CDS-specific header (e.g., x-cds-interaction-id - although that may create a sense of duplicate functionality.) |
| 2450 | Transaction ID Uniqueness and Immutability of Posted Transactions We would like to understand the expected (allowed) behaviour from a Dataholder regarding Transaction IDs and their uniqueness for posted transactions. In particular, if a transaction is reversed or otherwise cancelled, can the DataHolder "update" the details of an already posted Transaction with a new set of details (i.e., recycle a transactionId)? The following is a scenario we are facing with a specific DH. a) 1st March Deposit $100.00 from ABC Manufacturing TransactionID 123456789 with status of POSTED b) Let's assume that we collect this transaction and provide it to the consumer on March 1st or 2nd. c) 25th March Payment $95.00 to ABC Manufacturing TransactionID 123456789 with the status of POSTED d) Again, let's assume that we will collect this transaction as an ADR on the 25th or 26th. However, this TransactionID is already in our database and therefore detected as a duplicate, BUT this 'new' transaction has a completely different set of details (new date, new amount, new description and new type). In addition to updated details, the balance has moved by the difference in the amounts. This approach is causing multiple issues (and potentially more). 1) "duplicate" transactionId 2) Posted transactions having updated details many days (20+) after moving from pending to posted 3) The changes to the transaction are significant, meaning data already provided to a consumer is now materially incorrect. 4) Movements in a balance that are not clearly matched to "new" transactions 5) Suppose the original transaction was not collected; only the updated transaction is collected. In that case, this does not represent the correct flow of transactions, and it means an ADR can never reconcile the transactions to the balance. Our primary concern and reason to seek clarity is around the significant update of a posted transaction & effective reuse of a TransactionId |
I was aiming to provide potential solutions to this issue in this comment - https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/656#issuecomment-2472273922 The intent of the proposed changes were: PENDING/POSTED are clarified Once a transaction is POSTED, the amount MUST NOT change. This means adjustments or reversals must be recorded as new transactions. Allow more efficient querying of the endpoint (this is only for convenience and related to a suggestion in the NFR CG for a Bulk Transaction endpoint) Ability to understand if/when a record has changed (with potential future ability to query by this field) Ability to understand if subsequent processes are expected to change the detail already available Ability to mark a transaction as 'removed' to allow them to be ignored by the ADR, for DH reasons such as fraud (or other possible scenarios), rather than the ADR having to recognise when transactions have disappeared. This may rely on the DH still providing the record in their endpoints. The key suggestion in relation to this query is 2. There are otherwise no standards around the 'reuse' of a transaction Id for a reversal and as you may have heard on the MI call today, some DHs may reflect something similar in other channels. This question may relate more to the definition of a transaction and whether all Data Holders treat them the same or adhere to the same conventions. |
| 2452 | I was looking at the candidate standards for non-bank lending - I need help with the 'Get Account Balance' and 'Get Transaction Detail' APIs. Get Account Balance I need help understanding if this API is relevant to me if I am a BNPL provider. To provide an example my BNPL product which allows customers to pay in 6 instalments and they have available $1,000 available to spend in thier account. How would 'Get Account Balance' API be relevant? and would the 'currentBalance' and 'availableBalance' fields within the API be relevant given $1,000 are not the users funds or they cannot be transferred out of the account either. Link to the API: https://consumerdatastandardsaustralia.github.io/standards/includes/additional/candidates/non-bank-lending/banking-non-bank-lending.html#cdr-banking-api_get-account-balance Get Transaction Detail Q1: What transactions are expected to be listed here? Is it transactions which are effectively orders placed by the consumer through using a BNPL provider? or is it transactions which capture the payments made by the consumer to the BNPL provider as part of the instalment payments? or both? example: Orders scenario Using the above BNPL product description - I buy headphones using my BNPL product for $300. So the transaction detail API response would have details for the order for $300 and the 'merchantName' from whom I purchased? Or Instalment scenario Or would the transaction detail API have details of my individual instalment payments for $50 that I would make back to my BNPL provider? and if so would the 'merchantName' just be my BNPL provider? Q2: What would the 'extendedData' object need to be populated with? as I understand this section is only relevant if transfer of funds is done using NPP. In the orders scenario the payment would technically be from the BNPL provider to the merchant - Is the expectation that the 'payer' field would be name of BNPL org and the 'payee' would be he name of the merchant? and then have the 'x2p101Payload' details if available? or in the case of the instalment scenario - Is the expectation that the 'payer' field would be name of customer, and the 'payee' would be the name of the BNPL provider? Link to the API: https://consumerdatastandardsaustralia.github.io/standards/includes/additional/candidates/non-bank-lending/banking-non-bank-lending.html#cdr-banking-api_schemas_tocSbankingtransactiondetail |
Q1: Get Account Balance I need help understanding if this API is relevant to me if I am a BNPL provider. To provide an example my BNPL product which allows customers to pay in 6 instalments and they have available $1,000 available to spend in thier account. How would 'Get Account Balance' API be relevant? and would the 'currentBalance' and 'availableBalance' fields within the API be relevant given $1,000 are not the users funds or they cannot be transferred out of the account either. A1: I think it would be expected that the account balance would generally reflect what is shown in other channels, but unless you have reason to think it should be different, it could be as follows, which should be similar to how a credit card account may be presented: Consumer has $1,000 available to spend. Consumers makes a purchase for $600. currentBalance = -600.00 availableBalance = 400.00 creditLimit = 1000.00 If you feel the description of the availableBalance field: "...funds available for transfer." is too specific and could be changed to something like "...funds available for transfer or to make purchases.", you could consider raising a change request in the Standards Maintenance repository. Q2: Get Transaction Detail Q1: What transactions are expected to be listed here? Is it transactions which are effectively orders placed by the consumer through using a BNPL provider? or is it transactions which capture the payments made by the consumer to the BNPL provider as part of the instalment payments? or both? A2: Again, I think this would be expected to match other channels, but more than likely all the transactions ('both' as you suggested) - including the purchases from merchants and repayments to the BNPL provider. I imagine again that this would be similar to the transaction history for a credit card, for example. Q3: What would the 'extendedData' object need to be populated with? as I understand this section is only relevant if transfer of funds is done using NPP. A3: A valid response from the Get Transaction Detail endpoint is only expected where the isDetailAvailable field in the Get Transactions for Account response is true. This is only expected for NPP-based transactions (only using the X2P1.01 service currently, though there is a change request to support other versions). I don't think payments between the BNPL provider and merchant would normally be expected, as I don't think they would normally appear in the consumers transaction history. If you have more detail on this aspect or can explain where it may be relevant please let me know. |
| 2453 | Are we required to support "mtls_endpoint_aliases" as defined in RFC8705 Section 5? I can only find reference in the standards to requiring support for RFC8705 section 3 " Holder of Key Mechanism [MTLS] MUST be supported as a Holder of Key (HoK) Mechanism. Note that, by implication, resource requests MUST be validated to ensure the client certificate and access token match. OAUTB SHALL NOT be supported due to a lack industry support. [MTLS] HoK allows issued tokens to be bound to a client certificate as specified in section 3 of [MTLS]. ", ref https://consumerdatastandardsaustralia.github.io/standards/#transaction-security Background: When diagnosing the root cause of incident https://cdrservicemanagement.atlassian.net/servicedesk/customer/portal/2/CDR-6536 - the error was diagnosed as us calling the incorrect token endpoint. The correct token endpoint was only advertised in the "mtls_endpoint_aliases" section of the well-known document. |
The Standards do not provide specific detail on the use of the optional mtls_endpoint_aliases parameter, but as MTLS/RFC8705 is provided in the Normative references, it may be assumed to be supported in general. If you feel that further clarity on this, or other areas should be provided in the Standards, you could consider raising a new issue in Standards Maintenance. |
| 2463 | I am reaching out to request clarification on the management of access tokens as per the CDR standards. My query pertains to the token endpoint's behavior when it receives multiple requests for the same consent arrangement within the token's validity period, which can last up to 10 minutes. When an ADR makes several calls to the token endpoint for the same arrangement during this time frame, I seek to understand whether it is permissible to reuse the existing token associated with the consent arrangement, or if a new token should be generated for each individual request. As a data holder, we are encountering a high volume of token requests, sometimes exceeding 200 within a few seconds. The task of managing and validating this volume of tokens is becoming increasingly costly, which is why we are seeking the aforementioned clarification. To elaborate further, let's assume we receive 30 unattended requests for the token endpoint for the same arrangement(same user same ADR), all within a 30-second span, and the access token has a validity period of 10 minutes. The question is whether we should treat these 30 requests as 30 separate sessions and consequently reject 10 of them due to a rate limit of 20(https://cdr-support.zendesk.com/hc/en-us/articles/360004493255-Traffic-thresholds), or should we consider all 30 requests from the ADR as a single session since they occur within the 10-minute validity window, and thus reuse the token that is still valid? |
Sessions are described in Definitions: Session: A session is defined as the life span of a unique Access Token. Multiple API requests made with a single, valid, Access Token would be considered part of a single Session. https://consumerdatastandardsaustralia.github.io/standards/index.html#definitions As the ADR may be unaware (it may be due to a bug in their code, for example), have you requested the affected Data Holder to raise a Jira ticket against the ADR in the ACCC system to ask why they making multiple requests as you've described? The ADR should only require one access token per 10 minute period, not one token per endpoint request. The Traffic Thresholds section explains the session limits applicable to different times of the day and it may be appropriate to reject sessions beyond those expectations. I would first try to understand what is causing the behaviour though, as using 20 sessions within a few minutes may not be what the ADR is intending. |
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.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |