-
Notifications
You must be signed in to change notification settings - Fork 56
ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes (22nd of April 2021)
CDR API Stream edited this page Apr 25, 2021
·
7 revisions
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: [email protected]
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
- Presentation
- Q&A
- Any other business
- 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 [email protected] 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.8.0 Published | Link to change log here |
| Standards | Version 1.9.0 Drafted | Link to Version Project Board here |
| Standards | Version 1.10.0 Drafted | Link to Version Project Board here |
| Maintenance | 6th Maintenance Iteration wrapping up for 2021 | Read about the Maintenance Iteration - If you would like to join these please reach out to [email protected] |
| Maintenance | This week is the final call of the 6th maintenance iteration. The purpose of the meeting is to review the final change candidates and future dated obligations. Further to this, the meeting will discuss the changes to be made for the Enhanced Error Handling decision proposals. |
Agenda for today's Maintenance Iteration call. |
| Maintenance | Decision Proposal 161 - Banking Maintenance Iteration 6 | Link to consultation |
| Maintenance | 7th Maintenance Iteration - Kick off; 28th of April 2021 | Invites to come today/ tomorrow morning |
| DSB Newsletter | To subscribe to DSB Newsletter | Link here |
| ACCC Newsletter | To subscribe to ACCC Newsletter | Link here |
| ACCC Newsletter | 26th of March 2021 Edition | View in browser here |
| DSB Newsletter | 16th of April 2021 Edition | View in browser here |
| Consultations | Decision Proposal 160 - CX Standards This is a placeholder issue for consultation on CX Standards for non-individual consumers, business partnerships, and secondary users. This proposal is not yet ready for publication. This placeholder issue has been opened to gather initial community commentary on the scope and content of the proposal. While the intention is for this consultation to focus on the relevant items raised in Noting Paper 157*, the DSB encourages feedback on any additional CX Standards and CX Guidelines that the community views as required for the purposes of non-individual consumers, business partnerships, and secondary users. *Items 12-14. Item 16 on secondary user withdrawal standards will be dealt with separately. - Non-individual Consumers - Business Partnerships - Secondary users |
Link to consultation |
| Consultation | Decision Proposal 162 - CX Standards, Joint Accounts, Authorisation Flow | Link to consultation |
| Consultation | Decision Proposal 165 - Brand aware metrics | Link to consultation |
| Consultation | Decision Proposal 166 - CX metrics for Data Holders | Link to consultation |
| Consultation | Decision Proposal 167 - Direct to consumer | Link to consultation |
| Workshop | OIDF & DSB - Technical Workshop & the Consumer Data Standards | Register here |
| Workshop | OIDF & DSB Introduction session: held on the 20th of April 2021 | Great session with 61 attendees and some great questions. Plan is for slide decks, recording and blogpost from OIDF to be posted - stay tuned as we work out where to host these files etc |
Provides a weekly update on the activities of each of the CDR streams and their workplaces
| Organisation | Stream | Member |
|---|---|---|
| ACCC | CDR Register (Technical) | Ivan Hosgood |
| ACCC | Onboarding | Chantelle Demian |
| DSB | CX Standards | Eunice Ching |
| DSB | Technical Standards - Banking | Mark Verstege |
| DSB | Technical Standards - Energy & Engineering | James Bligh |
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.
We are trialling Sli.do for Question and Answer. Join our Q&A live here: https://www.sli.do/ Code: #169517
| Ticket # | Question | Answer |
|---|---|---|
| 570 | We have the following questions on the recently published V2 Rules. 1. Subdivision 4.2.2, 4.3(2) - Why are collection and use consents and no other consent types mentioned in these provisions? Was this intentional? 2. Can each consent type be independently obtained from consumers on separate days? e.g. Day 1 seek Collection consent; day 2 seek Direct Marketing consent for identical accounts? In 4.11 (1A) can we request Disclosure consent at the same time as asking a collection and use consent? This provision says an accredited person cannot request a disclosure consent until after it has requested a collection and use consent. 3. Consent types such as Use, Disclosure and Direct Marketing do not require authorisation from the Data Holder’s (DH’s) side. Assume these can be requested without a full consent flow to the DHs? E.g. Day 1 obtain Collection & Use consents for 3-months with request to DH; after 2.5 month refresh Use consent for another 3-month period without a new Collection consent and without sending requests to DH as no action is required on their part. 4. In 4.11 (1) (a) (i) it requires the consumer to be able to select the specific types of CDR data when providing Disclose consent. Does this statement implies Disclosure consent has to be obtained at the same time of Collect consent? 5. Under 4.11(1)(ba), is the "select the person" referencing the Accredited Person? 6. Is Disclosure consent only applicable to disclose to Accredited Person? Can the Disclosure consent be to another partner organisation? 7. In 4.11 (1) (d) it seemed to indicate DHs can now charge for CDR Data? 8. 4.18 (2A): "... must set out details of each amendment that has been made to the consent". If a consent that has been amended 3 times, on 3 separate occasions does this require all 3 amendment details to be shown in the latest Receipt or only the most recent amendment consent is required in the latest Receipt? If all 3 amendment details are required in the Receipt then the receipt can grow to be very long over time as each amendment details contains the full information on date/time, data clusters, etc. 9. In 4.20 does the ongoing notification requirement only refers to Collection and Use consents? What about other consent types? 10. Assume an ADR’s terms of service contract with its customers already includes customers providing consent for the ADR to use their data to undertake direct marketing or research. Is the ADR still required to obtain such consent, Direct Marketing/Research, from customers on each consent authorisation or amendment? |
Rule 4.3(2) reflects the policy intention as to when collection and use consents may be sought. The circumstances under which other consents may be sought are dealt with elsewhere in the rules. The remaining questions relate to the interpretation of the CDR Rules, including whether the rules permit specific activities to be undertaken in a certain way. The regulator is not in a position to provide legal advice on such issues. It is the responsibility of CDR participants to determine how they will comply with the CDR Rules. We recommend that you seek advice from your internal policy team or legal advisor. |
| 590 | Here’s a question for the Rules team that we are hoping to have clarified. Subject: Expiry/Revocation of active consents on customers ceasing to be eligible customers In terms of consent authorisation withdrawal requests received from a CDR consumer through an alternate method of communication (such as by phone or in writing), Rule 4.25(2)(a) allows for a maximum of 2 business days for the DH to give effect to the withdrawal and notifying the ADR. - Is this understanding correct? On a similar vein, is there any timeframe by which the DH should revoke/expire an active consent authorisation, when the consumer ceases to be an eligible customer on the DH's end (i.e. closes all their accounts with a DH). For example, If a customer ceases to be an eligible customer on a certain day, is the DH expected to revoke/expire the consent authorisation on the same day OR can this occur on the following day OR up to a maximum of 2 business days later. Is there any 'maximum' allowed duration defined in the rules, or any guidance, around this. Also, in addition/in relation to the above question, is there any 'maximum' allowed duration around notifying the accredited person of the expiry/revocation of the consent authorisation, after the customer ceases to be an eligible customer. |
In terms of consent authorisation withdrawal requests received from a CDR consumer through an alternate method of communication (such as by phone or in writing), Rule 4.25(2)(a) allows for a maximum of 2 business days for the DH to give effect to the withdrawal and notifying the ADR. - Is this understanding correct? The Rules do not specify when the ADR has to be notified by. It only has to happen 'in accordance with the data standards' which do not specify timelines for revocation. It is implied that a revocation from a dashboard should be communicated immediately and this would be expected but the standards do not give timings (or even comment) on revocations arising from changes in eligibility. On a similar vein, is there any timeframe by which the DH should revoke/expire an active consent authorisation, when the consumer ceases to be an eligible customer on the DH's end (i.e. closes all their accounts with a DH). For example, If a customer ceases to be an eligible customer on a certain day, is the DH expected to revoke/expire the consent authorisation on the same day OR can this occur on the following day OR up to a maximum of 2 business days later. Is there any 'maximum' allowed duration defined in the rules, or any guidance, around this? Again, the rules are silent about this. Given 2 days is stated for withdrawal of authorisation, this seems sensible re: a customer no longer being eligible. In addition the Data Standards do not give timings (or even comment) on revocations arising from changes in eligibility. Also, in addition/in relation to the above question, is there any 'maximum' allowed duration around notifying the accredited person of the expiry/revocation of the consent authorisation, after the customer ceases to be an eligible customer. Rules are also silent about notification of the ADR if the consumer is no longer eligible and the Standards leave this up to the Data Holder to decide on implementation. One final point to in relation to all of the above questions is that the intent of the regime as a whole is to move to real time, or near real time, data sharing to give the best value services to consumers. This means that future rule changes or standards changes are more likely to require real time notification than batch notification. It would be wise for data holders and data recipients to make architectural and design decisions to accommodate this direction in case of future changes to the regime. |
| 681 | Elaborating more on my previous question: Data Holder needs to pass JWT during ADR revocation endpoint call (refer “Data Holders calling Data Recipients” https://consumerdatastandardsaustralia.github.io/standards/#client-authentication). Who will generate this JWT and how ADR will validate the token? |
the JWT is generated by the Data Holder. The JWT is signed using the DH's private key and the ADR can decrypt and validate the JWT by using the DH's public key obtained by calling the DH's JWKS endpoint. |
| 716 | As per ACCC guidelines on metadata cache management, Data holder will fetch Data Recipient information along with Data Recipient Status and Software Product Status from ACCC. Customer data will be shared with ADR based upon Data Recipient and Software Product status. Does Data Holder need to update any Data Recipient metadata (retrieved through GetDataRecipient API) in Dynamic Client Registration repository? |
The management of data is in any specific implementation is at the discretion of the participant and the DSB and ACCC do not provide specific guidance. In general, however, any meta data received from the Registry should be seen as definitive and should be used when presenting consent and dashboard screens to the customer. |
| 717 | When will Client Authentication improvements (standards-maintenance#360) be actioned/decided? Does CTS support this new method? If CTS does not support Client Authentication improvement, will a Holder be able to pass early? CDR Register introduced new fields in the SSA which are effective "from July 2021". Is a holder expected to support this during onboarding? Does CTS test? Does the CTS support ES256 signatures and tokens? Action proposed by Ivan and Dominic: CTS Delivery Schedule |
We have consulted our CTS team and received the responses below: When will Client Authentication improvements (standards-maintenance#360) be actioned/decided? Does CTS support this new method? CTS does not currently test GetMetrics. Support for GetMetrics and client authentication is expected in May. If CTS does not support Client Authentication improvement, will a Holder be able to pass early? CTS was never intended to provide full coverage, it is expected that Data Holder would test their respective endpoints and ensure that they comply with CDS. CDR Register introduced new fields in the SSA which are effective "from July 2021". Is a holder expected to support this during onboarding? Does CTS test? DH’s are expected to support them. DH is expected to return openid scope in the registration response. They are also expected to return the optional fields in SSA like legal name, if it receives them in a registration request Does the CTS support ES256 signatures and tokens? CTS does provide ES256 support for ADR testing, for Data Holders CTS does verify it’s support in the discovery document only. Schedule statement will come separately. |
| 721 | The enumerations for Transaction Type in the Banking Transaction Schema Payload seem rather confusing when considering credit card transactions. 1. As a Data Holder, we have classified credit card purchases, cash advances, balance transfers and refunds as "transfers-outgoing". 2. Payments made to a credit card account are classified as "payment". 3. Reversal transactions are classified to matched the original type of transaction. Does this interpretation seem reasonable and likely to be understood by Data Recipients? |
This is entirely up to the Data Holder. The standards do not specifically call out how to select these transaction types for specific transactions as ledgers and internal processes are so variable. When the type field was introduced (at the explicit request of ADRs) there was a good deal of debate on this topic with the result being the field would be introduced with a minimum number of values that would be relatively common across all ADIs. The only guidance that can be provided is to apply best efforts and be consistent with your other channels. That is the formal answer. The other avenue is that the DSB is working on the concept of 'Conventions' that could be used to document best practice. These conventions would not be binding but could be used as a form of general consensus on the best way to do things that are not prescribed in the standards. The application of type fields to various circumstances could be a an excellent use case for a convention. Would this be helpful? |
| 723 | Question: Is a blocked or suspended account eligible for data sharing ? Scenario: Bank suspends a customer account #1001 temporarily (Say due to fraudulent transaction) for a week. Assumption: There is only one online account #1001 associated with the customer Clarification: Is the customer considered eligible for data sharing ? | The interpretation of customer eligibility over time is in the hands of the data holder. The only comment on the the interpretation you have presented, however, is that a blocked or suspended status is often understood to be temporary whereas account closure is permanent. In this context, you could have the situation where all of a customer's consents were revoked due to a temporary suspension of an account that is later resolved. This would not be a positive customer outcome and could result in customer complaints. If there were many complaints of this nature across the regime it may warrant a change to the rules or standards. |
| 724 | Question: If a customer, who is ineligible for data sharing turns eligible, should the transaction data for the period, when the customer was ineligible, need to be shared with data recipients upon request Scenario: A customer who has been with the bank for 2 years (ineligible for data sharing), turns 18 and becomes eligible Clarification: Is the transaction data for the past 2 yrs, eligible for data sharing upon request.? |
Yes |
| 727 | in the event we encounter unplanned and/or we plan outages, are we required to notify the regulator. If so what are the guidelines associated to this and where is this Information located for me to review. | There are no specific notification requirements to the regulator for outages. Information on availability and outages are required as part of standard reporting to the regulator and the regulator may request additional information. In addition, the standards include the Outages API which is expected to be implemented. Any planned outages reported via this API ahead of the outage can be considered a planned outage and excluded from consideration in availability metrics reporting. |
| 729 | This is with reference to the definition of meta for the GetBalancesForSpecificAcccounts in the request payload https://consumerdatastandardsaustralia.github.io/standards/#get-balances-for-specific-accounts meta is defined as optional https://consumerdatastandardsaustralia.github.io/standards/#tocSrequestaccountids Based on the examples and the specs, our expectation is that a request with no meta information would look like this: 1. {"data": {"accountIds": ["string"]},"meta": {}} Or 2. meta absent completely from the request. Q:Is the following also a valid representation (null provided as a value for meta) 3. {"data": {"accountIds": ["string"]},"meta":null}
|
all three examples would be valid according to the definition of Optional Optional fields MAY be present but this is not guaranteed. It is also valid for these fields to be present but have a null value. Note that optional fields indicate that data may sometimes not be held by a Data Holder and this is an expected scenario. |
| 736 | Is there a limit for the number of accounts that can be presented to the end customer in the authorisation flow and the ones responded with in the banking APIs such as Get Accounts/Get Bulk Balances/Get Balances for Specific Accounts/ Get Bulk Direct Debits/Get Direct Debits For Specific Accounts/Get Scheduled Payments Bulk/Get Scheduled Payments For Specific Accounts? I am having in mind the use case where an end customer has hundreds of accounts, for example we have a customer with 500 accounts. As a data holder do we have an obligation to present all 500 accounts in the authorisation flow and the API responses? Or could we limit the number? Having so many accounts poses usability and performance challenges. Is it acceptable from a regulator perspective to show all the accounts in the authorisation flow (even if 500) but limit the number of accounts that can be selected for sharing in a consent to for example 25. If we were to share transaction data for let's say a year for 500 accounts at once, it would pose a huge load on both data holder and data recipient side. Chances are something will go wrong. This way we would limit the load and the customer can select further 25 accounts in another consent. The number of customers with this many accounts is in reality in the tens and would be onerous on both data recipient and data holder side to design systems that support this huge loads for what is an edge case that will rarely happen. |
there is currently no limit. All eligible accounts must be shown, however DHs may wish to show an optimised CX using pagination or filtering of accounts in the Account Selection screen. There are existing provisions for large data sets in the standards that prevent the example of all transactions being returned for 500 accounts. The Pagination section (https://consumerdatastandardsaustralia.github.io/standards/index.html#pagination) documents how DHs may refuse requests where the number of transactions requested is larger than 1000. In the event of a large Bulk API call, the DH can support pagination of the results to minimise the load to the DH. |
| 738 | At the bottom of https://consumerdatastandardsaustralia.github.io/standards/#traffic-thresholds I note that each of the secure & public traffic thresholds are specified at 300 TPS. Does this mean that a data holder could limit the access to either their secure or public APIs if they go above 300 TPS? Wouldn't this allow 6 particularly large (or busy) ADRs or worse, a nefarious public API consumer to exhaust this capacity and prevent other users from access these endpoints? 300 TPS seems like a particularly low general limit for API access. For secure APIs it would seem the 50 TPS per ADR would more than protect an DH from misuse. For the public APIs (which are all readily cacheable), 300 TPS across the entire unauthenticated masses of the internet also seems extremely low. |
> At the bottom of https://consumerdatastandardsaustralia.github.io/standards/#traffic-thresholds I note that each of the secure & public traffic thresholds are specified at 300 TPS. Currently the NFRs are non-binding. 300TPS represents close to 25.9m API calls per day per DH. This provision gives a ceiling to the number of requests so that DHs can right-size their implementations and it was deemed sufficient as a starting point. > Does this mean that a data holder could limit the access to either their secure or public APIs if they go above 300 TPS? Yes that is the purpose. These are separate 300TPS thresholds for secure (authenticated API) access and 300TPS for public (unauthenticated API) access. > Wouldn't this allow 6 particularly large (or busy) ADRs or worse, a nefarious public API consumer to exhaust this capacity and prevent other users from access these endpoints? There are additional rate-limiting thresholds that apply. NFRs are currently not binding to observe usage patterns and assess these performance targets once there is broader adoption of the CDR. Were 6 large ADRs to repeatedly call a DH every second then DHs would be within their rights to limit the given ADR's access if they deemed it to be unreasonable traffic or suggestive of a DoS. For Customer Present and authorisation traffic the following traffic thresholds will apply: Unlimited sessions per day 10 TPS per customer 50 TPS per data recipient For Unattended traffic the following traffic thresholds will apply for low traffic periods: 20 sessions per day, per customer, per data recipient 100 total calls per session 5TPS per session 50 TPS per data recipient For public clients, banks can use their discretion to rate limit based on known public clients if they believe a single client is unreasonably exhausting capacity. > 300 TPS seems like a particularly low general limit for API access. For secure APIs it would seem the 50 TPS per ADR would more than protect an DH from misuse. > For the public APIs (which are all readily cacheable), 300 TPS across the entire unauthenticated masses of the internet also seems extremely low. For reference, the total daily API volume in the UK in February 2021 was 23.9m API calls across 19 brands (~1.26m / brand / day). |
| 741 | If a payee in a scheduled payment has the same bsb and account number as a registered payee in the customer's IB address book, is that payment considered to be to a registered payee ? This may occur where the customer ignores that the payee is already in their address book and adds their details again manually for the payment. If the system doesn't recognise the new payee as being the same as the existing address book payee, would it be acceptable to use 'domestic' as the toUType? Thanks, | > If a payee in a scheduled payment has the same bsb and account number as a registered payee in the customer's IB address book, is that payment considered to be to a registered payee ? Yes that's correct. > If the system doesn't recognise the new payee as being the same as the existing address book payee, would it be acceptable to use 'domestic' as the toUType? Yes this would be acceptable. It is important to note that the payeeId would only be applicable provided the payee scope has been consented to as per the description: Present if toUType is set to payeeId. Indicates that the payment is to registered payee that can be accessed using the payee end point. If the Bank Payees scope has not been consented to then a payeeId should not be provided and the full payee details should be provided instead |
| 745 Part 1 | In Standards 1.7.0, there are new changes introduced for Scheduled Payments i.e., nickname and payeeReference in the BankingScheduledPaymentTo. Could you let us know the obligation date for these changes? It is missing in Future date obligations and the version has not been updated for the schema. |
There are no future dated obligations applicable. The changes introduced to BankingScheduledPaymentTo are optional. The change to nickname was changing from mandatory to conditional because feedback indicated that the same payeeReference is not always applicable across the payment set. If you are currently responding with a payeeReference you would be compliant. The change to the nickname of the Scheduled Payment was to correct a bug in the documentation. |
| 745 Part 2 | I think you are referring to the BankingScheduledPayment schema but my question is for the BankingScheduledPaymentTo schema. Version 1.7.0 has introduced two new attributes - nickname and payeeReference - both these are conditional. DH will not have these attributes in their current implementations and it is a change to the schema.We were under the assumption that these will be optional from the maintenance iteration 5 but in the standards they are conditional. Now the condition is such that we have to provide these attributes by deriving the data even if we do not have it and there are no future date obligations for this change. Please correct me if i'm wrong here.. | thanks for the clarification. The introduction was not seen to result in a breaking change. The payee reference is only required if captured within an individual payment instruction. Likewise nickname was included and should be provided where available but does not give rise to a future dated obligation. |
| 746 | When a data holder only provides a Mobile App as the digital channel to a consumer can the data holder implement the app-to-app redirection flow for the CDR customer authentication and consent authorisation requirement? Alternatively, in this scenario, does the data holder have to implement a mobile web browser capability outside of the DH’s mobile app to action ALL CDR customer authentication and consent authorisation requests? For further clarification for this scenario are the following redirection options supported within the CDS, and can or must be implemented by the data holder to cater for the different ADR digital channel options; ADR Digital Channel to Data Holder Digital Channel (CDR Consent Authorisation) 1. Mobile web browser to Mobile web browser 2. Mobile web browser to App 3. App to Mobile web browser 4. App to App |
In response to your question around support for different interaction models for consent. It is expected that Data Holders will not restrict the implementations of Accredited Data Recipients so it should not be assumed that the recipients will implement an app based model. This means that holders should not assume an app based client. As this implies the possibility of a web based client in the context of a browser it will require that the data holder supports the consent flow in a browser context. |
| 753 | In the ACCC rules Part 4,4.7 (3) states: (3) The data holder must inform the accredited person of such a refusal in accordance with the data standards We are not aware of any standards that address this requirement. Note that there may be requests which are not refused in full so error messages are not necessarily able to fully address this requirement. Please advise. |
The standards have used the error handling mechanisms in the APIs as the notification mechanism for these scenarios. We have defined specific error codes for instance for a refusal based on authentication or a refusal based on NFR thresholds being exceeded. These are currently the only mechanisms the standards define. |
Updating the table below - if your question/ ticket has not received a response yet the team continues to work on a response. We do apologise for the delay on some tickets, the teams are doing their best to get to everyone's questions.
To our valued CDR participants, We have undertaken a review of the CDR Support Portal as a channel for providing guidance on CDR Rules. Based on the volume and nature of questions we have received recently, we have decided to move to a model based on publishing guidance to the community, rather than providing individual responses to stakeholder questions. Our goal is to prioritise the provision of guidance that is accessible, transparent and has industry-wide application. We intend to develop this to meet clear community needs, which we will identify and prioritise based on questions and issues raised by stakeholders. We kindly ask for your patience as we work our way through the tickets, feedback and guidance
A work in progress - open for feedback from the community on what you would like to see.
| Organisation | Description | Link |
|---|---|---|
| OAIC | Main landing page for the Office of the Australian Information Commissioner and the Consumer Data Right | Link |
| DSB | CX Artefacts - The CX Guidelines provide optional examples of key requirements and recommendations to help organisations build best practice consent models. CDR Participants should also refer to the CDR Rules, data standards, and privacy guidelines for a complete view of obligations to facilitate compliance. | Link |
| DSB | Consumer Data Standards Main Page - About the DSB team, engaging with our consultations and Events | Link |
| DSB | The Consumer Data Standards - The technical and consumer experience standards for the Consumer Data Right | Link |
| DSB | The Banking Product Comparator - a demonstration of Product Reference Data from Data Holders as part of the Consumer Data Right | Link |
| DSB | GitHub Consultations - all public consultations from the Data Standards Body | Link |
| DSB | Java Artefacts - An Open Source Project comprised of reference implementations of both Data Holders and Data Recipients | Link |
| ACCC & DSB | The Consumer Data Right Support Portal Knowledge base for the Consumer Data Right covering Rules through to Technical articles and questions |
Link |
| ACCC | ACCC Main focus area/ landing page for the Consumer Data Right | Link |
| ACCC | GitHub Consultations - all public consultations from the ACCC Register Team | Link |
| ACCC | CDR Register Design Reference | Link |
| ACCC | Public page for the Consumer Data Right | Link |
| ACCC | Participant Portal page including sign-up and log-in | Link |
| TSY | Consumer Data Right background and historic records from the Treasury | Link |