ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 11th of November 2021 - ConsumerDataStandardsAustralia/standards GitHub Wiki

ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes

When: Weekly every Thursday at 3pm-4.30pm AEDT Location: WebEx, quick dial +61-2-9338-2221,,1650705270##

Meeting Details:

Desktop or Mobile Devices https://treasuryau.webex.com/treasuryau/j.php?MTID=m9614a7c6166155d3d950a8999e437f9f 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

Agenda

  1. Introductions
  2. Actions
  3. CDR Stream updates
  4. Presentation
  5. Q&A
  6. Any other business

Introductions

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

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 [email protected] should they have any further questions or wish to have any material redacted from the record.

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.

Updates

Type Topic Update
Standards Version 1.14.0 Published Link to change log here
Standards v1.14.0+ is unplanned Pending any minor tweaks, fixes or amendments to v1.14.0
Maintenance 9th Maintenance Iteration Agenda from the 3rd of November 2021 meet
Maintenance 9th Maintenance Iteration Extended until 1st of December 2021 Dates updated here on the comment in Decision Proposal 212
Maintenance Decision Proposal 212 - Banking Maintenance Iteration 9 Link to consultation
Maintenance 10th Maintenance Iteration To commence on 16th of February 2022
TSY Newsletter To subscribe to TSY Newsletter Link here
DSB Newsletter To subscribe to DSB Newsletter Link here
TSY Newsletter 1st of November 2021 View in browser here
DSB Newsletter 5th of November 2021 View in browser here
Consultation Normative Standards Review (2021) Link to consultation
Consultation Decision Proposal 209 - Transition to FAPI 1.0 Advanced Profile Link to consultation
Consultation Decision Proposal 216 - Profile scope support Link to consultation
CDR Implementation Call End of the year Survey: When to wrap up for 2021? When to kick-off in 2022? Link to survey
CDR Support Portal Some Tickets are open for a long period. This is the response automated to the various Rules related tickets. ---- Thank you for this question. It has been referred to the relevant regulator(s) who will consider any issues raised and may provide a further response where appropriate. This question will also be considered in relation to future knowledge articles and guidance. Please note that we cannot provide individual compliance advice and we recommend that CDR participants seek advice from their internal or external advisors. It is the responsibility of CDR participants to determine how they will comply with the CDR Rules. CDR resources and information We encourage participants to review the range of existing CDR guidance material, which you may find useful. This includes the following: • Zendesk CDR Guides / FAQs • Resources for providers on the CDR website • The ACCC’s CDR project page and Compliance guidance for data holders in the banking sector • the OAIC’s CDR Privacy Safeguard Guidelines and various other guidance pieces on the OAIC’s Consumer Data Right web page If you haven’t already, we also encourage you to subscribe to the CDR updates to keep up-to-date with CDR developments.

CDR Stream Updates

Provides a weekly update on the activities of each of the CDR streams and their workplaces

Organisation Stream Member
ACCC CDR Register (Technical) ACCC Team
ACCC CTS Andrea Gibney
ACCC Onboarding Christine Atkins
DSB CX Standards Michael Palmyre
DSB Technical Standards - Banking Mark Verstege
DSB Technical Standards - Energy & Engineering James Bligh

Presentation

None.

Q&A

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

Answer provided

Ticket # Question Answer
462 Clarification is required to understand the behaviour of DELETE - DCR on existing objects holding relationship to the deleted software product client. Appreciate your confirmation on following: Client Object : Is all registration data for this client supposed to be deleted by Data Holders? Consent Data : When an ADR chooses to execute the DELETE registration, should all the consents related to the relevant software product be deleted? Access Tokens/ Refresh Tokens: In the event of deletion all the related tokens to this client must be deleted as well . Re-registration : Is this software product authorised to re-register with the Data Holder? If yes, will they be using and existing SSA or will they be required to request a new SSA. ---- As per reference to DCR spec : https://tools.ietf.org/html/rfc7592#section-2.3, please see following: A successful delete action will invalidate the "client_id","client_secret", and "registration_access_token" for this client, thereby preventing the "client_id" from being used at either the authorization endpoint or token endpoint of the authorization server. If possible, the authorization server SHOULD immediately invalidate all existing authorization grants and currently active access tokens,all refresh tokens, and all other tokens associated with this client. It would be great to get defined OB requirements for the SHOULD part in the excerpt above. It is recommended to consider expected behaviour of UI components and notification to be displayed to the OB customer when this action is performed. As, Data Holders MAY be displaying ADR information in consent dashboard and will have to cater for unexpected deletion of an ADR from DH ecosystem. The status of the ADR at the Legal Entity level determines actions the Data Holder is required to take at the Software Product level. These statuses and actions are described in https://cdr-register.github.io/register/#data-holder-responsibilities To respond to each of your questions: 1. Client Object: Is all registration data for this client supposed to be deleted by Data Holders? Yes, when the Delete API is called, all details are to be removed, this is good security hygiene practice. 2. Consent Data: When an ADR chooses to execute the DELETE registration, should all the consents related to the relevant software product be deleted? The Data Holder is required to 'expire' all consents at the time the ADR status is set to REVOKED OR SURRENDERED and the status of the software product changes to INACTIVE. Therefore at the time delete is requested there should be no active consents. If the ADR is deleting a Software Product from the CDR ecosystem independent of the above-mentioned changes in Status either at the Legal Entity or Software Product Status, then yes the Data Holder must delete all associated consents. IMPORTANT NOTE when an ADRs status is SURRENDERED and the status of the software product is INACTIVE all consents must be preserved. Data Holders can also undertake these security hygiene tasks when the software status changes to REMOVED, regardless of whether an ADR calls the DELETE function. 3. Access Tokens/ Refresh Tokens: In the event of deletion all the related tokens to this client must be deleted as well. Yes, consistent with our response to question 2 above. 4. Re-registration: Is this software product authorised to re-register with the Data Holder? If yes, will they be using and existing SSA or will they be required to request a new SSA Yes, although it is not possible to use an existing SSA as they have a lifetime of 10 minutes. The ADR must be able to initiate re-registration against the previous software product.
556 Under https://cdr-register.github.io/register/#client-registration-management the Auth Server support for a delete endpoint is marked as Optional does this mean that a Dataholder can choose to not implement the delete endpoint? 1. What is the expected usage scenarios for this endpoint? Why or when would an ADR want to delete their registration (given there is a PUT to modify registration details as well?) (Assumption is that this endpoint is used by the ADR to clean up their registration with a Dataholder while the ADR's status in the register itself has not changed) 2. What is the expected Dataholder behaviour in response to a Delete request if there are active arrangements associated with the registered client? a. Reject the delete request OR b. Same behaviour as in a Software Status Removed scenario (https://cdr-register.github.io/register/#data-holder-responsibilities) - Invalidate Consents and - Clean up Registration (And Stop Sharing, Auth, etc) 3. The Duplicate check for registration requests is on the Software Product ID. If a registration associated with the software product ID has been deleted, a subsequent registration request using the same software product id should succeed? The CDR Register design does not specify the behaviour of the data holder when a delete request is received, however, the data holder should ensure that the other requirements in Client Registration are maintained. To respond to each of your questions: 1. What is the expected usage scenarios for this endpoint? Why or when would an ADR want to delete their registration (given there is a PUT to modify registration details as well?) As of yet, none. It is conceivable that an ADR would choose to clean up their registrations either at the beginning of a software product's lifecycle, where erroneous registrations may have occurred or at the end of the lifecycle when the software product is decommissioned. However, currently, the design does not require all data holders to support this functionality. Future design iterations may look at changing this position if there is community demand for standardising this functionality. 2. What is the expected Dataholder behaviour in response to a Delete request if there are active arrangements associated with the registered client? a. Reject the delete request OR b. Same behaviour as in a Software Status Removed scenario (https://cdr-register.github.io/register/#data-holder-responsibilities) - Invalidate Consents and - Clean up Registration (And Stop Sharing, Auth, etc) When an ADR chooses to execute the DELETE registration, the Data Holder is required to 'expire' all consents at the time the ADR status is set to REVOKED OR SURRENDERED and the status of the software product changes to INACTIVE. Therefore at the time delete is requested there should be no active consents. If the ADR is deleting a Software Product from the CDR ecosystem independent of the above-mentioned changes in Status either at the Legal Entity or Software Product Status, then yes the Data Holder must delete all associated consents. IMPORTANT NOTE when an ADRs status is SURRENDERED and the status of the software product is INACTIVE all consents must be preserved. Data Holders can also undertake these security hygiene tasks when the software status changes to REMOVED, regardless of whether an ADR calls the DELETE function. 3. The Duplicate check for registration requests is on the Software Product ID. If a registration associated with the software product ID has been deleted, a subsequent registration request using the same software product id should succeed? Yes, this is important as an active software product that is issued an SSA from the CDR Register must be able to register with all relevant data holders in the ecosystem. The previous registrations are not a factor in this requirement.
640a In the 11 March Implementation call meeting minutes (https://github.com/ConsumerDataStandardsAustralia/standards/wiki/ACCC-&-DSB-%7C-CDR-Implementation-Call-Agenda-&-Meeting-Notes-(11th-of-March-2021)) there is an answer to question 619 where the answer mentioned legal_entity_name being immutable. Is this really the case? We are under the assumption that legal entity name can change over time due to, for example, merger & acquisition, rebranding, etc. When this happens the existing registration in ACCC Register can't be used any more? ADRs will then need to have a new entry created and re-register with all DHs, essentially start anew? You are correct, when we start looking at use cases regarding brands and their portability to move across to other legal entities as a result of mergers, acquisitions etc, the immutability of legal entity ids and names comes into question. Detailing these use cases is work currently in flight and I have raised a ticket to track external collaboration on this work. Please refer to GitHub issue #178: https://github.com/cdr-register/register/issues/178
640b Had a quick look at the raised issue. Assume there's a typo there? "may result in these fields becoming immutable to satisfy this use case." Is that "immutable" meant to be "mutable"? Also, for whatever is worth, our current thinking is ID remaining as immutable makes sense. However, name should be mutable. For example, we have Intuit today as a brand. Tomorrow we might want to change to Intuit Australia or Intuit QuickBooks or simply QuickBooks. IMHO, how participants present their brands it is completely up to the discretion of the participants. Currently, the legal entity details are immutable but perhaps we can consider them becoming mutable. There is work pending on determining how the portability of brands will occur and whether we can allow brands to move between legal entities. Therefore, the legal entity id and name may change simply because the owner of the brand has changed, not that the owner's details have changed. The scenario you have outlined, where the current owner changes their name, is an additional scenario that needs to be included in this analysis.
773 As per FAPI-RW Section 8.6 "For JWS, both clients and authorization servers shall use PS256 or ES256 algorithms" Base on that can a data holder support one of those two algorithms (eg: only PS256) or is it mandatory to support both algorithms? Data Holders have the discretion to choose their preferred algorithm(s). DHs may support both algorithms if desired. DHs must publish their support via "id_token_signing_alg_values_supported" and "request_object_signing_alg_values_supported" to allow for negotiation with the ADR clients. If the DH does not publish their algorithm support it is assumed the DH will support any of the recommended algorithms. ADRs must support both because different DHs may support different algorithms.
994 Part 1 ---- Follow-up question: Does this means GetDataRecipientsStatus and GetSoftwareProductsStatus needs to be scheduled for every 2-5 min. GetDataRecipients will be scheduled for every 6 hours. Please confirm. The following is documented in the CDR Register Design:Cache update periods The following are the recommended caching times for data retrieved from the Register APIs: https://consumerdatastandardsaustralia.github.io/standards/#cache-update-periods It is recommended you retrieve the status information from the GetDataRecpientsStatus and GetSoftwareProductsStatus endpoints every 2-5 mins. If this model is followed, then yes. you can retrieve the remaining Data Recipient information from the GetDataRecipients endpoint every 6 hours.
1003a For AU, we would like to confirm our understanding on the JWKS URI to be used. We are of the opinion that the main JWT will have a issuer (iss) property with a value of "cdr-register" which can help us decipher the country (AU in this case) and hence use a JWKS URI predetermined for it in our code. We will use this JWKS URI to verify the signature of a second JWT which is inside the software_statement property of the main JWT. The second (inner) JWT will have a property called jwks_uri and this URI is to be used for verifying the signature of the outer main JWT. Is this understanding accurate, if not, please let us know how we are to decipher JWKS URIs for both the JWTS. Also please let us know if only one of the JWT's signature is to be verified, or both. We can create our own JWTs and sign them ourselves asymmetrically for internal testing. However, if we could get a real world example that we can use in our testing to make sure that the JWKS URIs are picked correctly and verification takes place as expected. One idea is to provide such a JWT but the problem with that is, it's validity may expire by the time it comes to us. Is there is a way where we can create an actual JWT for this flow? 1.The create registration flow documented in the CDR Register design will provide a breakdown of the various JWKS URIs and when they are used to verify both the SSA and the registration JWT signatures. a. The SSA generated by the register will have an iss claim set as "cdr-register" b. Please refer to the create registration flow to map how each JWT is to be validated. Both the SSA and the registration JWT require validation 2. Testing against the SSA and other JWTs has been a topic of discussion previously. There are non-normative examples provided in the CDR Register documentation for reference. Now these are not designed to be used in testing, instead they can be used in conjunction with jwt.io to understand the composition of the JWTs. Its not up to the ACCC to dictate your testing criteria but I would encourage you to generate your own JWTs so you can cover the different variations you may need to encounter. Its not a tall order, jwt.io describes many libraries which can be leveraged. Also, we do have a mock register which you can interrogate the code on: https://github.com/ConsumerDataRight/mock-register Remember though that it does not come with warranty and is an open source project relying on community contributions to evolve.
1003b 1.) From your confirmation, we will use the issuer value from the SSA to determine the JWKS URI for verifying the SSA JWT. This is the JWKS uri we have identified for AU -> https://api.cdr.gov.au/cdr-register/v1/jwks. (Let us know if this is not the URI or if there can be other URIs in addition to this) 2.) Do we need to verify the incoming JWT as well? (The one that contains the SSA) If so, should we use the value found as jwks_uri within the SSA? If so, is this a known set of values that we can expect to get hold of? 1.) Yes this is correct, as described in: https://cdr-register.github.io/register/#getjwks 2.) Yes this is correct. The jwks_uri defined in the SSA belongs to the software product. Therefore, this is not a known set of values and is published and maintained by the Data Recipient. It is required you will retrieve these keys to validate the JWT request. This is covered in the sequence diagram
1003c Would it be possible to get a sample of the request data recipient would send to data holder with schema including all mandatory and optional attributes listed? The non-normative examples provided in the documentation seeks to provide this level of detail. Additionally, the ACCC has now provided an example implementation of the CDR Register, Data Holder, and Data Recipient. Please refer to their GitHub repositories at: https://github.com/ConsumerDataRight Running these implementations will give you a good reference to how each of the entities interacts with each other.
1130 As a Data Holder, we are working through the requirements for Direct Debits and have the below question: Scenario: In instances where the direct debit is rejected due to insufficient funds or payment is stopped, we show the original transaction then reverse it, to show the customer that a direct debit was received but had to reverse it due to any of the 2 reasons mentioned earlier. Q: Should we show the direct debit original transaction only or should we show direct debit reversal transactions as well in the direct debit end point? As always, appreciate the guidance :) The Direct Debit endpoint is intended to show Direct Debit Authorisations and not Direct Debit Transactions. A limitation of Direct Debits under BEX is that an institution receiving a direct debit can only infer an authorisation from transaction history. So, the expectation would be that this would be presented as a Direct Debit authorisation in the Direct Debit endpoint even if the payment was stopped or there are insufficient funds. The transactions endpoint should contain the additional detail however if this would normally displayed on a statement or in internet banking.
1132 We have noticed in the CTS test suite that there is a check to ensure the a DH polls the GetDataRecipients endpoint twice every 5 minutes. It is unclear to us what we should do with the response from the GetDataRecipients call and currently our implementation makes no use of this response. The details returned as part of the response for the GetDataRecipients are the exact same details we received from an ADR during the DCR process. We are under the impression that those details will not change, and if they do that the ADR would need to re-register with us. The CTS testing has raised questions as to how a change in the metadata associated with an ADR will propagate through to DHs. Several fields returned by the GetDataRecipients call could potentially change and NOT require the ADR to re-register. For example, the Industry or the logoURI. Our understanding was that this would not happen, but maybe the intention is that ADRs can change these fields (and others like them) and that these changes would then propagate out to DHs via the regular polling of the GetDataRecipients endpoint. Can you please confirm the intention of this endpoint? If there are Data Recipient fields which you expect to change, what are those fields? Some fields, such as the accreditation number and software product ID should not change, but there may be fields which can change. Could you please indicate which ones we should update our cache with during the GetDataRecipients polling? The GetDataRecipients API can be polled as an alternative to the GetSoftwareProductsStatus and GetDataRecipientsStatus APIs. As per the register standards https://cdr-register.github.io/register/#metadata-cache-management , "Data Holders and Data Recipients will be required to cache all other participant data they use and periodically update this cache using a slow poll." Apart from the statuses , it is possible that some non Identifying metadata about the brands and Software Products can change .For example Logos, Brand Names, Software Product Name, description etc. With regards to CTS, based on the information you provide during onboarding, you will get assigned a test plan which either has scenario 11a "Get Software Product Status Register Polling" or 11b "Get Data Recipients Register Polling", which will test if your solution polls these endpoints for updating your DR Status cache, which as per standard should be be polled periodically between 2-5 mins.
1141 We would need to access a mock registry and ADR for our testing purpose and not for CTS. Can you please help provide us how to access the mock registry and ADR? We would need the certs, keys and steps to implement them in our environment. To access the mock solutions, it needs to be built and deployed in your local environments, the process for this can be found at https://github.com/ConsumerDataRight/mock-data-recipient#build-and-deploy-the-source-code section. The information regarding the certificates and how to use them have been detailed in the "Certificate Management" section. https://github.com/ConsumerDataRight/mock-register/tree/main/CertificateManagement https://github.com/ConsumerDataRight/mock-data-recipient/tree/main/CertificateManagement
1148 The CDR Register Design Reference has defined that where the ACCC (as Data Recipient Accreditor) has made a decision to revoke the accreditation of an Accredited Data Recipient, and has notified the decision to the Registrar, the Registrar will * revoke Accredited Data Recipient's certificates, and * update the CDR Register to change the Accredited Data Recipient's status to 'revoked' and status of all associated Software Products to 'inactive' * Once the appeals timeframe has been exceeded, Software Products will be moved to the 'removed' status. My question is when the ADR Accreditation is Revoked, and the associated Software Product is "Inactive", what is the Data Holder's responsibility? This scenario seems not having been included in the "Data Holder Responsibilities" table. And what's the implication of this scenario for the Data Recipient side? The CDR Register design includes cascade rules for when a software product's status is dictated by the status of the parent legal entity. For your reference: https://cdr-register.github.io/register/#accredited-data-recipient-and-software-product-statuses However, you have highlighted a gap in the documentation and you are right, the cascade rules are incomplete and don't map to the actions of the Registrar. I have raised a GitHub ticket on the standards maintenance site to highlight this gap. https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/431 Further analysis will be required to bring this to conclusion so please refer to the standards-maintenance issue as we work on this problem.
1155 A term deposit can pass through the below stages. - Term Deposit opened on day1 - Term deposit funded on day 20 Between day2 and day 19, is this term deposit eligible for data sharing ? Yes it is.
1157 According to the spec legal entity id(dataRecipientId) is optional in SSA[1]. But that value is used in data recipient get status endpoint[2] as the data recipient identifier[3] So is it safe to assume that the legal entity id is mandatory in SSA as data holders need that value to identify and read the corresponding status? If not how can the data holders identify the corresponding status of the data recipient? Additional Note: Current mock register[4] issued SSAs do not contain legal l entity id. So believe if the above-mentioned is correct this will have to be corrected as well. [1] https://cdr-register.github.io/register/#dynamic-client-registration [2] https://cdr-register.github.io/register/#tocSdatarecipientsstatuslist [3] https://cdr-register.github.io/register/#ecosystem-entities [4] https://github.com/ConsumerDataRight/mock-register The legal_entity_id will always be returned via the SSA. The optionality was to cater for the change when this field was introduced. It is expected that you use this value to reference the statuses returned by the GetDataRecipientStatuses endpoint. There is still an open question in the design on the mutability of the legal_entity_id and the legal_entity_name. Further work is required to identify how changes in the ecosystem will result in these fields changing. Examples may include acquisitions of brands, changes in names etc. Please refer to GitHub ticket #178 as we progress this issue.
1161 Could you point me to the specific requirement / rule / legislation that says a Data Holder has to provide 7 years of data to the data recipient ? So, if I as a consumer share an active account with a Data Recipient, can they extract transactions for the past 7 years using the get/Transactions API ? My understanding is that paragraph 56AC(2)(c) of the Act defines the term "holding day" and allows for the designation instrument to specify this day with some constraints. The designation instruments for banking specifies this day as 1 January 2017 (section 5c). This means that transaction data prior to 1 January 2017 does not need to be shared but after that date it does. I'm not sure if there is a seven year limitation anywhere.
1162 Regarding the decision in the link regarding LOA level. If a Data holder supports OTP for authentication, is it fair to assume that DH will support LAO2 claim and reject any request with claim LOA3. https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/182 for read access operations, DHs shall support LOA2. Some implementations of OTP using a secure authenticator may result in an LOA3. DHs should publish their supported LOAs using "acr_values_supported" which advertises what "acr" values an ADR can request. You are correct that at present an ADR should only be requesting an LOA2. https://consumerdatastandardsaustralia.github.io/standards/index.html#levels-of-assurance-loas If the DH does not support LOA3 or cannot achieve LOA3 then you are correct, the request should be rejected.
1164 Having looked through GitHub I am unable to find any further information on this other than the details outlined in Issue #167. And a previous Issue #089. It is understood from what James communicated today in the iteration meeting that, the Direct-to-Consumer piece has been deferred and that it was not in scope and not required to be delivered by 1 November 21. Can I clarify the following. Is the whole piece of work deferred? Therefore no obligations are required to be implemented? And therefore nothing needs to be delivered until further notice? For any implementation that has been completed at our end – could I ask that the following please be confirmed that we are to follow the obligations as set out in CDR v2.0? Is the following CDR-API Stream update noted below the latest information associated to work around Direct-to-Consumer? If not could someone please direct me to the correct update, I am unable to find anything further. In the recent announcement by the Treasury - Developments in Australia’s Consumer Data Right in response to community feedback - it was stated that obligations regarding the direct to consumer modality would be deferred. Specifically the announcement states. Treasury has heard stakeholder views on the optimal settings for providing CDR data ‘direct to consumers’ and proposes to undertake further work to ensure we get the settings right for direct to consumer obligations. Compliance with these obligations, which are due to come into effect in November 2021, will be deferred, pending a future consultation process. In response, this consultation will also be deferred. A new consultation will be scheduled in the future. There are currently no technical standards for Direct To Consumer and the obligations for this modality has been deferred by Treasury (as noted in your question). The Treasury has not indicated any specific date yet. In this context, there is no implementation expected from Data Holders to our knowledge.
1168 Q1: Where loan funds have not been disbursed, do these accounts need to be shared or do we start sharing the account once the funds are disbursed? Q2: If we have to publish undisbursed Loans, the loanEndDate and nextInstalmentDate are not known until the funds are disbursed. These are mandatory fields. What should be populated in these fields? We recommend that these fields are optional. Q: Where loan funds have not been disbursed, do these accounts need to be shared or do we start sharing the account once the funds are disbursed? A: This would be up to the data holder but the rule of thumb is that the behaviour should align with other Digital Channels. For instance, if it is visible in internet banking then it should be shareable. Q: If we have to publish undisbursed Loans, the loanEndDate and nextInstalmentDate are not known until the funds are disbursed. These are mandatory fields. What should be populated in these fields? We recommend that these fields are optional. A: Feel free to raise a change request to this effect on standards maintenance. It is worth noting, however, that the load structure isn't mandatory and you could choose to leave that structure unpopulated until the loan is disbursed. Whatever you choose to do please ensure you do not leave out a mandatory field as that would be non-compliant with the standards.
1175 For the Data Holder implementation of Open Banking, we would like to understand the role of the Data Holder in validating the FAPI headers like x-fapi-auth-date and x-cds-client-headers. Since these values are populated by the ADR and as per the CDR standards conditionally but in the Banking API's these same fields are considered optional for Data Holder. We would like to understand Data Holder obligations for the FAPI headers. the best source of information if the FAPI Part 1 and Part 2 specifications. It is at the discretion of the DH whether they make use of the client x-fapi headers. The only exception is the x-fapi-interaction-id. DHs must respond with an x-fapi-interaction-id value: either the value provided by the client, or otherwise, if the client did not provide a value, it must generate one for the response. DHs must also validate that mandatory headers are provided or return an error code. Some x-fapi headers are conditionally required. Let me know if that answers your question, or feel free to follow up with more questions.

Useful Links

View a number of informative and useful links in the Consumer Data Standards Implementation Guide on Information Links.