ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 1st of June 2023

CDR Implementation Call Banner

Agenda & Meeting Notes

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
teams@vc.treasury.gov.au
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

Agenda

Introductions
Actions
CDR Stream updates
Presentation
Q&A
Any other business

Introductions

5 min will be allowed for participants to join the call.

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.

House Keeping

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.

Community Guidelines

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.

Updates

Type	Topic	Update
Standards	Version 1.24.0 published 7th of May 2023	Version 1.24.0 Change Log
Maintenance	Iteration 15 met on 31st of May 2023	See the agenda and meeting minutes
Maintenance	Iteration Candidates nominated!	List of candidates on the MI5 Project Board
TSY Newsletter	To subscribe to TSY Newsletter	Link here
DSB Newsletter	To subscribe to DSB Newsletter	Link here
TSY Newsletter	26th of May 2023	View in browser here
DSB Newsletter	26th of May 2023	View in browser here
Consultation	Decision Proposal 229 - CDR Participant Representation	Placeholder: no close date Link to consultation
Consultation	Noting Paper 276 - Proposed v5 Rules & Standards Impacts	No Close Date Link to consultation
Consultation	Noting Paper 279 - Accessibility Improvement Plan	No Close Date Link to consultation
Consultation	Noting Paper 280: The CX of Authentication Uplift	No Close Date Link to consultation
Community	CDRMonth kicks off today! Check out the site for events and other information.	Link to site
Community	Congratulations to the winners of this years 'Finnies'	Check out the list of FinTech Australia's 2023 Finnies Winners

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	Register & CTS	Eva
DSB	Consumer Experience	Holly
DSB	Technical Standards - Energy	Hemang
DSB	Technical Standards - Information Security & Banking	Mark
DSB	Technical Standards - Register	James
DSB	Technical Standards - Maintenance Iteration 15	Brian

Presentation

None planned for this week.

Q&A

Questions on Notice

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.

Answer provided

Ticket #	Question	Answer
1723	The following Security Endpoints are listed as requiring “Client Authentication Required”: Token Endpoint Introspection Endpoint Token Revocation Endpoint CDR Arrangement Revocation Endpoint (for Data Holders) PAR Endpoint There is a statement in the standards which reads as below: The aforementioned assertion MUST be sent to the Authorisation Server's Token endpoint with the POST method and MUST include the following REQUIRED parameters and MAY contain the following OPTIONAL parameters: grant_type - REQUIRED. The grant type(s) supported by the Authorisation Server. client_id - REQUIRED. The client ID of the bearer. client_assertion_type - REQUIRED. This MUST be set to urn:ietf:params:oauth:client-assertion-type:jwt-bearer. client_assertion - REQUIRED. The encoded assertion JWT. scope - OPTIONAL. The requested scope as described in Section 3.3 of [RFC6749] The part that confuses us is that it appears to be saying that we only need to supply the client_assertion and client_assertion_type at the "token" endpoint, however they feel we need to supply these parameters at any of the Security Endpoints (listed above) when the Private Key JWT Client Authentication method is being used. Basically, we are not sure what parameters are mandatory for the 5 security endpoints which require “Client Authentication”. A definitive list of required parameters at each endpoint would be useful. Can you please advise?	Thanks for the question. In regards to client authentication, the assertions need to be presented and validates on security endpoints where "Client Authentication Required" is listed as "Yes".
1764	This has delved into a cross over into Standards and CX Guidelines that we will cover in a different thread. We will try to limit continuation in this thread to Rules specific components. We concur that this action is not a SUI withdrawal. We used the term "withdrawal" because this is the wording used in the limited CX Guidelines (only secondary user instruction/withdrawal is documented) on this topic. The rules approach seems to be the Consumer "indicates" sharing is to cease for a specific accredited person. We understand the intended outcome for the secondary user's authorisation with respect to continuing to share data for the Consumer themselves and other accounts selected. Regarding the "account holder perspective", this is where there is a significant and a potentially impossible implementation problem. As we understand it, the desire is that the historical state of the arrangement should be displayed to the account holder with the current state displayed to the secondary user. This would imply a single arrangement having two different states depending on view but the arrangement identifier being uniform? This would imply some sort of temporal view of an arrangement where the account holder can see the arrangement up to a certain point in time? What happens if the account holder then "undos" the indication to stop sharing? Does the arrangement roll back to its original state? Further, what is the intended behaviour of notifications in this situation, particularly with regards to secondary users on joint accounts? The rules don't appear to elaborate how this action, conducted by one account holder, should be communicated to other account holders? Regarding the response on the secondary user perspective. We understand the that an authorisation cannot be established for the ADR for which an indication has been given to block. Could you please clarify your answer further though regarding "the previous data sharing arrangement should still be displayed with an indication that the data sharing arrangement has been stopped". In the situation where an existing arrangement was in place the Secondary User may be sharing other accounts or data so the arrangement is still active (as per your previous comment "but the secondary user’s authorisation does not expire. This allows sharing from other accounts under the same authorisation to continue") which seems to be contradictory to the latter statement? Additionally, if the data sharing is "stopped" should we be sending revocation notifications to Data Recipients? It is not currently possible to technically communicate to a Data Recipient that a specific account has been removed from an arrangement. While there is coverage for vulnerability reasons in the Rules to effectively "alter" an arrangement state without displaying it (ie. showing Active state for an arrangement involving Joint Account without sharing) there doesn't appear to be an explicit carve out for this behaviour other than the "reasonable steps" provisions (which is the main driver of these questions).	The following links appear to address your questions in relation to this issue: CR557 Authorisation states for joint account and secondary user sharing We hope this information assists you.
1827	In line with the recently revised v1.21 CDS for FAPI 1.0, 'WE' will be upgrading its DH implementation to enable support for Authorisation Code flow (ACF) from 14-Apr-23 & also continue supporting OIDC Hybrid flow (OHF). 'WE' believe the interpretation of the standards below will support the transition outcomes desired by the CDS. 'WE' recommends CDR-API-Stream to further amend the standards (or release as industry guidance) to explicitly clarify usage of “response_mode” for ACF & OHF as described below, along with non-normative samples to ensure JARM requirements are correctly adhered to by ADR. Authorisation Code flow ( ACF ) • From 14-Apr-23, 'WE' expects ADR clients when requesting ACF will need to send “response_type”:“code” & an additional JWT claim “response_mode” with the values equal to “jwt” or “query.jwt” or “fragment.jwt” as part of the PAR request object JWT. Westpac DH Authorisation server will return the auth code in JARM format for the aforesaid successful ACF requests. • This is in line with the following requirements stated in DP 282 & FAPI JARM standards ( https://openid.net/specs/openid-financial-api-jarm.html#response-encoding). • 'WE' DH Authorisation server will reject ACF requests if the “response_mode” is not supplied or has any other values like “query”, “fragment”, "form_post", "form_post.jwt" which are other than the acceptable values required for supporting ACF with JARM i.e. “jwt” or “query.jwt” or “fragment.jwt”. • The above implementation ensures ACF is used in conjunction with PAR, PKCE & JARM. OIDC Hybrid flow ( OHF ) • ADR clients who want to use OHF & need auth code in http redirect response can continue sending PAR request object in existing format as mandated from 16-Sep-22 with “response_type”:“code id_token”. JWT claim “response_mode” is not mandatory to be supplied by ADR clients in this case or if supplied can have values equal to “query” or “fragment”. 'WE' DH implementation will return auth code in the http redirect response for aforesaid successful OHF requests in line with 16-Sep-22 guidelines.. • ADR clients who want to use OHF & need auth code in JARM format will need to send PAR request object with “response_type”:“code id_token” & additional JWT claim “response_mode” with values “jwt” or “query.jwt” or “fragment.jwt”. JWT claim “response_mode” is not mandatory to be supplied by ADR clients for OHF requests but if supplied must have values “jwt” or “query.jwt” or “fragment.jwt”. In this case 'WE' DH implementation will return auth code in the JARM response format for such successful OHF requests.	FAPI 1.0 is clear that response_mode must be "jwt" when using Authorization Code Flow: "the response_type value code in conjunction with the response_mode value jwt;" We have a CR in Maintenance Iteration 15 to address the gap in the non-normative examples: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/559
1936	QLD has once off rebates that are applied to each customer's account, for example, https://www.qld.gov.au/community/cost-of-living-support/concessions/energy-concessions/cost-of-living-rebate Should these once-off rebates be included in EnergyConcession? Based on the descriptions here https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/476#issuecomment-1082558393 it seems like the intention is not to include one off rebates.	Joint response from DSB and ACCC: Following discussions with the ACCC Regulatory Guidance team, they have clarified the following: We confirm our preliminary view that once-off rebates or concessions are within scope. In accordance with sub clause 3.2(6) of Sch 4, this information would be required to be shared if it is requested, and the rebate (transaction or event) occurred within 2 years of the time the request is made. In terms of how this information is to be shared: - It should be shared via the concessions API with the same start and finish date that corresponds with the date that the rebate was made/credited to the account of the consumer
1940	you have an article under masked account numbers that talks to Alpha numeric account numbers - see below. It refers to "Term deposits" - Can i assume this is for any account type with alpha numeric fields? Heritage uses account code(such as L50) at the end of the string, which contains non-numeric character. Therefore I assume we ok to use alpha numeric in our strings? This relates to this ticket CDR-XXXX This is the info in your article Alpha-numeric account numbers For scenarios where the term deposits held by a DH have alpha-numeric identifiers, the DSB recommends the following approach for returning accountNumber and maskedNumber fields within the BankingAccountDetailV2 response schema. Populate the maskedNumber field with a masked version of the alpha-numeric identifier. Leave out the accountNumber field in the BankingAccountDetailV2 response as it is optional.	Is the question here whether you can use alpha numeric strings in the maskedNumber field? If so, this is permissable for term deposits as it is for other bank account types.
1947	further to my query in today implementation call and my ticket 1940. This is due to the following ticket that was raised against us : Account Number contains character rather only numeric values At present, we are including the account number in its Heritage format of 1234567S1, which would break the rules if only digits should be sent. Hence my query re alpha-numeric account numbers outside of term deposits - https://cdr-support.zendesk.com/hc/en-us/articles/5527282549135 We could change it to the member number, 1234567, to populate this field. The member number combined with the BSB, which is also being included, can be used to identify our accounts. This combination is used for transfers and payments. However, we may still need to leave the accountNumber field blank because we already have maskedNumber in the response and it will become meaningless if we still include the accountNumber.	A few things to unpack here: - If the account number for the bank account has alpha characters in it, then you can ommit the accountNumber given it is an optional field. In this instance, presenting the alpha-numeric account number in the maskedNumber is permissable albeit there is a presumption that the maskedNumber is a masked version of the numerical account number. The ZenDesk guidance has been updated to reflect this: https://cdr-support.zendesk.com/hc/en-us/articles/5527282549135 - If the member number and BSB identify an account and allow the customer to deposit funds into their term deposit, the approach you've suggested to represent the member number as the account number would work. If the member number is representative of multiple accounts owned by the customer this probably isn't the right approach - If you feel that the standards could benefit from allowing Data Holders to include an alpha-numeric account identifier, we'd recommend you raise a Change Request on our Standards Maintenance project.
1960	We have one of the Term Deposit 1-364 days product which has the description stated as ‘interest paid at maturity’. We would like to clarify about the value in ‘applicationFrequency’ field for each tier term period as it was difficult to reflect the correct period after which the total calculated amount is applied to the account. For example, a 36 days term deposit with interest paid at maturity what should be the value in ‘applicationFrequency’ field. Should it be based on how long the TD was for, in our case here P36D even though the applicable rate tiers are a mix of P1M (Rate tier for 0 - <1Month) and P2M (Rate tier for 1month - <2month) OR should be left blank like a few other Data Holders have done as the applicationFrequency is a non-mandatory field and the ISO standard value may not be the right applicationFrequency as its more than a period of 1 month and less than a period of 2 months.	The applicationFrequency field is intended to be a generic way for showing how often interest will be actually applied to an account. The type is an ISO8601 duration structure so it has a great deal of flexibility. P36D is a perfectly acceptable value under this standard (you can even go down to minutes and seconds if you so desire). Any suggestion that this field should be limited to months is incorrect. These fields are optional as some accounts have variable values for calculation and application depending on other aspects or conditions when a product is originated. The definition of optionality in the standards is applicable, however. If there is a known and valid value then it should be populated.
1964 Part 1	We are currently in the process of developing the compliant API's as a Data Holder within the Banking Sector. As part of this, we seek clarification on the method of authentication for consent requests to us by Data Recipients. The standards refer to requiring an OTP, and: - Data Holders MUST NOT request that the customer enter an existing password in the redirected page. - Data Holders MUST provide a one-time password (OTP) to the customer through an existing channel or mechanism that the customer can then enter into the redirected page. - Data Holders SHOULD implement additional controls to minimise the risk of interception of the OTP through the selected delivery mechanism. - The provided OTP MUST be used only for authentication for CDR based sharing and MUST NOT be usable for the authorisation of other transactions or actions - The provided OTP MUST be numeric digits and be between 4 and 6 digits in length - The algorithm for the creation of the OTP is at the discretion of the Data Holder but SHOULD incorporate a level of pseudorandomness appropriate for the use case We seek to direct users into the our App, to acknowledge the consent request without providing an external SMS or email code. We feel this provides a more secure solution and is inline with industry standards. For reference please see the following 2 Industry standards examples: - https://help.okta.com/oie/en-us/Content/Topics/identity-engine/authenticators/configure-authenticators.htm - https://www.cyber.gov.au/protect-yourself/resources-protect-yourself/personal-security-guides/protect-yourself-multi-factor-authentication Could you please confirm if this approach is acceptable, and if any other Data Holders have implemented a similar solution. From our assessments of the API's, we believe we will be able to implement and compliant solution and pass conformance testing.	This has come up before. Redirect to an app is not currently an acceptable mechanism for authentication of a customer and an OTP is required. There were reasons for this position to be adopted at the time. We are currently working through the process of changing this by consulting on more enhanced authentication models but currently the standards are explicit that an OTP must be provided via an existing channel used by the customer.
1964 Part 2	Thanks for the response. We are continuing to scope this internally. It is our strong preference to direct participants into the DH app to authenticate and provide consent vs sending a OTP via email or SMS. We recognise this as a more contemporary, and secure means of identifying the correct customer and having them provide consent. Our current compliance date is estimated early 2024, do you think the appropriate standards changes would be in effect by then?	I completely understand your position. Many other Data Holders have expressed this also. I can't put a timeframe on the standards change and I certainly wouldn't want you to make a scope decision that ends up putting you in a bind if the standards don't end up changing. One step you can take to be proactive is raise your request on the change request issue tracker and seek to get the change into one of the maintenance iterations.
1965	1. We are implementing API for banking sector, does this mean that we have to create Banking API and Common API? What about Admin API? 2. Regarding the Admin API > Metadata Update API: what action should we (as a data holder) take when this API is called?	Q: We are implementing API for banking sector, does this mean that we have to create Banking API and Common API? What about Admin API? A: Yes. Bank Data Holders must implement the Common, Admin and Banking endpoints. This is laid out in the banking schedule of the rules. It is helpful you can see the sectoral breakdown of endpoints in this article: https://cdr-support.zendesk.com/hc/en-us/articles/360004135055. Q: Regarding the Admin API > Metadata Update API: what action should we (as a data holder) take when this API is called? A: Each Data Holder is expected to periodically contact the register and update their cache of all valid ADRs, their status and their metadata. When the Metadata Update API is invoked by the Register the Data Holder should execute this periodic process immediately regardless of how recently it was last executed. The intent of this API is to ensure critical changes in the Register (such as a revocation or suspension) are able to be propagated as soon as possible to protect consumers. It is very rarely called but must be implemented.
1967	Question 1: As a DH in order to display the legalEntityName during the authorisation process, do we display the data stored during the ADR/client registration (Register Data Recipient oAuth Client) or based on the Metadata Cache Management where we can get this same information? Question 2: If an ADR updates information like LogoUri in the CDR registry, do they need to update the same with Data Holders by calling the Update Client Registration endpoint of Data Holder? Question 3: Information retrieved as part of Metadata Cache Management is only check the Data Recipient and associated Software Statuses and no other information?	Q: As a DH in order to display the legalEntityName during the authorisation process, do we display the data stored during the ADR/client registration (Register Data Recipient oAuth Client) or based on the Metadata Cache Management where we can get this same information? A: Data Holders are required to do a slow poll to periodically update ADR metadata from the Register. This updated metadata would take precedence over any data provided via DCR. Some data, however, is only provided via DCR and this should be maintained until a DCR update is performed. Q: If an ADR updates information like LogoUri in the CDR registry, do they need to update the same with Data Holders by calling the Update Client Registration endpoint of Data Holder? A: No. They would only do this if they wanted the change to take effect immediately Q: Information retrieved as part of Metadata Cache Management is only check the Data Recipient and associated Software Statuses and no other information? A: No, that is incorrect.
1968	Is there any audit log requirement that we (as a Data Holder) need to satisfy? For example, “record any data request from Data Recipient”, “record the time the consumer provided their consent”, “record the time the consumer revoked their consent”, etc.	I am assuming your question is related to "what operational information should be collected and retained by a Data Holder?". The answer to this question is complicated by the fact that the ACCC, as regulator, is able to request pretty much any data they think they need to ensure compliance and operational integrity of the ecosystem. That said, data holders can't keep everything. Generally, the guidance we give is that there is a non-binding expectation that you will collect the information that you would reasonably want to have to troubleshoot and operationally manage the system. You should also seriously consider collecting enough information to be able to provide evidence that you are meeting the NFRs documented in the standards. Specifically, however, you must (ie. non-optionally) collect the information required to populate the Get Metrics API and the six monthly report that is requested by the ACCC.
1976 Part 1	Need one clarification related to the recent comment (https://github.com/ConsumerDataStandardsAustralia/standards/issues/298#issuecomment-1543393740) added on 11th May to the DP 298 https://github.com/ConsumerDataStandardsAustralia/standards/issues/298 Comment: "the intention during Phase 3 is that Data Holders permit ADRs registering both flows so they can test and fallback to Hybrid Flow without updating their client registration. If they have to update it to switch flows this could have unforeseen impacts with their live software products and establishing consumer consents." As a Data Holder we want to clarify below understanding. An ADR can register using Hybrid flow for their Software Product #1 and they can register using Auth code flow (ACF) for Software Product #2. But they can't register same Software Product #1 using both Hybrid and ACF? If in case an ADR is allowed to register the same SP #1 using both flows, then DH is expected to return same client_id or different client_id to ADR?	Question 1: An ADR can register using Hybrid flow for their Software Product #1 and they can register using Auth code flow (ACF) for Software Product #2. But they can't register same Software Product #1 using both Hybrid and ACF? Answer: If the ADR has two software products they can register them to use both flows. Question 2: If in case an ADR is allowed to register the same SP #1 using both flows, then DH is expected to return same client_id or different client_id to ADR? Answer: The client_id is bound to the oAuth client. At present a software product is a one-to-one mapping to an oAuth client. When returning a client_id this is unique to each software product.
1976 Part 2	Just to clarify further if the ADR has only one software product can they register using both hybrid and ACF flows with the same Data Holder? If yes, will the client id after registration would be the same for Hybrid and ACF for this SP provided by DH?	Question 1: Just to clarify further if the ADR has only one software product can they register using both hybrid and ACF flows with the same Data Holder? Answer 1: Client Registration is on a software product by software product basis. An ADR software product is registered with a Data Holder to obtain an oAuth client ID. A separate client ID is registered for each individual Software Product. An ADR can register for both Hybrid and ACF flows for the same oAuth client. Question 2: If yes, will the client id after registration would be the same for Hybrid and ACF for this SP provided by DH? Answer 2: A client Id is unique to the oAuth client being issued by the Data Holder. A client registration can include a request to register their oAuth client for both Hybrid and ACF flows. Question 3: During a DCR (client registration or Update Registration) can an ADR send both values ("code id_token" and "code") in the same request for a Software product in the field "response_types"? Answer 3: Yes they can
1984	I am writing to seek guidance regarding the Last Consumer Change Date (LCCD) and its implications for our contact centre operations. While I understand that it may be early to address this matter, obtaining clarity in the near future would greatly assist us in managing customer requests effectively. Specifically, I would appreciate your guidance on the following questions related to the management of LCCD updates: 1. Handling Customer Requests for LCCD Update: In situations where LCCD initiation is not occurring, if a customer contacts our contact centre to request an update of their LCCD in order to access data beyond the current retailer FRMP timeframe, we would like to understand the appropriate approach. Should we accept the date provided by the customer at face value, or is it necessary for us to request proof of the updated LCCD? 2. Documentation for Proof of Updated LCCD: Assuming that proof is required, we would appreciate your insights on the types of documentation that would be considered ideal as proof of an updated LCCD. For instance, would documents such as occupancy agreements, lease agreements, sale agreements, utility bills, or any other specific documents be considered acceptable proof? Obtaining clarity on the handling of LCCD updates and the necessary proof requirements will enable us to ensure compliance and provide consistent and accurate assistance to our customers. If this question isnt relevant, would appreciate if you could elaborate on why. Thank you for your attention to this request and support as usual.	The CDR Support Portal is currently managed by the Data Standards Body (DSB) and the Australian Competition & Consumer Commission (ACCC). However, we consider that AEMO would be in a better position to respond to your enquiry as it is responsible for implementing and managing the LCCD. As such, we encourage you to submit an enquiry to AEMO via their ‘Contact us’ form.
1985 Part 1	With reference to the following support article regarding Energy invoices (https://cdr-support.zendesk.com/hc/en-us/articles/4415999114511-Energy-Invoice-Electricity-Usage-Charges) - specific Q&A called out at the end. It appears that the Energy Invoice API intention is to not disclose concession information and as such in the Energy Invoice API concessions applied to an invoice are bundled into total discount fields. For the Energy Billing API however it is less clear as Concessions could be represented either line-by-line or bundled. Contextually impacting this is the fact that both Invoices and Billing fall under the same API scope. As such, our interpretation is that consistent with Energy Invoices, the Energy Billing API should also aggregate concessions and discounts together. Can you please advise. Specifically the following Q&A: Question In the EnergyInvoiceElectricityUsageCharges schema, does the field totalOnceOffDiscounts include concessions and rebates? During consultations, it was mentioned that concession and rebates are not included. If not included, then invoiceAmount will not be accurate, as the invoiceAmount takes into account the concessions deducted. Answer Decision Proposal 198 suggested that distinct fields should not be created for concessions. They should be included in the total fields. A comment by CDR-API-Stream on 25 Oct 2021 states: “Concessions and rebates should be included in the total fields as suggested. Separate fields have not been created due to the sensitivity of this data set. By aggregating this data a customer is able to share their invoice data without the need to disclose a hardship-related concession. Concessions have been separated into a specific data scope for this reason.”	As such, our interpretation is that consistent with Energy Invoices, the Energy Billing API should also aggregate concessions and discounts together The billing API is to share individual billing transactions that would have occurred within a given time period. Transactions should not be aggregated for this API (they are already aggregated in the Invoice APIs). The billing API does (similar to invoice API) not include separate/individual fields to capture concession or rebates. They could be included in EnergyBillingOnceOffTransaction or EnergyBillingOtherTransaction (depending on the context). The description field is at the discretion of the DH to populate so you could exclude any details indicating or inferring if its a concession or rebate.
1985 Part 2	OUr concern here is that per the published FAQ "Concessions have been separated into a specific data scope for this reason." The data scope for Invoices and Billing is the same data scope. By including a line-by-line billing feed that includes specific line items with concession information, the principle of separating out concession information into a separate scope would not be upheld in this case.	That is precisely why the billing API does not have specific fields to capture or reflect concession information. They have quite generic fields such as amount and description (which, as noted, is at the discretion of DH to populate). Concession information (i.e. what are the concessions applied to a consumers account) is in a separate scope and API. The transactions resulting from them are shared in a generic manner.
1987	We have a query on the following fields : 1. data.scheduledPayments.payeeReference ==> The reference for the transaction, if applicable, that will be provided by the originating institution for all payments in the payment set. Empty string if no data provided. 2. data.scheduledPayments.paymentSet.to.payeeReference ==>The reference for the transaction, if applicable, that will be provided by the originating institution for the specific payment. If not empty, it overrides the value provided at the BankingScheduledPayment level. The 1st description states we can provide an empty string if no data is provided however the 2nd description states that if the field is NOT EMPTY, then it overrides the value provided at the BankingScheduledPayment level. Q1 : The 2 descriptions seems to contradict each other Q2 : Since the 2nd field sits within an paymentSet array, we may potentially have lets say 10 sets of payees. In this case, how do we determine which payeeReference from the paymentSet to copy across to the payeeReference within the BankingScheduledPayment level ?	The intention of the payeeReference field is that it will indicate the actual value of the reference in any payment generated from the schedule. The descriptions of these fields, at the top level and in the payment set refer to this use of the field. So, the sub-fields are not intended to force you to change the value of the master field, both fields can be present with different values but the reference in the resulting payments would be different. For instance, in your example, a payment to Emily would have a reference of "AAA" and a payment to Janice would have a reference of "BBB". If the paymentReference in the second entry of the paymentSet (to Janice) was blank then the a payment to Janice would have a reference of "string".
1988	Is it a requirement for Data Holders to allow Data Recipient clients (both new and existing) to register to use both ACF and Hybrid authentication flows during the FAPI 1.0 Migration Phase 3? i.e. ``` { "response_types": ["code", "code id_token"] }	Question: Is it a requirement for Data Holders to allow Data Recipient clients (both new and existing) to register to use both ACF and Hybrid authentication flows during the FAPI 1.0 Migration Phase 3? Answer: Yes it is. Until July 10th Data Holders must support both flows. After July 10th Data Holders are permitted to retire Hybrid Flow. However any Data Holder continuing to advertise support for both flows after that date would need to continue supporting registrations for both flows in accordance with the OIDC spec.
1989	We need urgent help in below clarifications: 1. During a client registration can an ADR send both values in the request "response_types_supported": ["code id_token", "code"] ? 2. Are these mandatory fields in the client registration authorization_encrypted_response_alg and authorization_encrypted_response_enc for authorisation code flow (ACF)? Thanks.	Answer 1: see Ticket 1976 Question 2: Are these mandatory fields in the client registration authorization_encrypted_response_alg and authorization_encrypted_response_enc for authorisation code flow (ACF)? Answer: authorization_encrypted_response_alg is Conditional, not mandatory. Similarly authorization_encrypted_response_enc is Optional. It is contingent on the registration request being sent by the data recipient. Data Holders may choose to apply authorisation response encryption in accordance with JARM. A Data Recipient is allowed to request registration without authorisation response encryption to indicate that they don't want the authorisation response encrypted. Response signing is mandatory.