DSB Maintenance Iteration 4: Finalisation of Iteration Scope: Agenda & Meeting Notes (22nd July 2020) - ConsumerDataStandardsAustralia/standards GitHub Wiki
DSB Maintenance Iteration 4 - Finalisation of Iteration Scope - Agenda & Meeting Notes (2020-07-22)
Date and time: 22/07/2020, 2pm - 3pm AEST Location: WebEx
- https://csiro.webex.com/csiro/j.php?MTID=m1a847c216c0578e19845184f08cdd878
- Dial In Number: +61 2 6246 4433
- Dial In Access Code: 165 673 5848
- Quick Dial: +61262464433,1656735848##
Chair: Mark Verstege, DSB
Maintenance overview: Further information
Maintenance project board: See here
Agenda
- Introductions
- Outstanding Actions
- Release 1.4.0: summary of upcoming 1.4.0 release
- Iteration Candidates: walkthrough review of issues for this iteration
- Any other business
Meeting notes
Introductions
- Allow for participants to join
- Housekeeping
- Overview, purpose and intended outcomes of the meeting
Actions
[ ? ] NAB analysis of NPP changes required for https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/229
Release 1.4.0
Changes included in Release 1.4.0 are available here. Scope includes:
- Maintenance Iteration 3
- Prioritised change requests to support July go-live
- Documentation fixes including non-normative examples
Iteration Candidates
- Iteration candidates were identified in the kickoff call.
- Project board: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/projects/3
- Feedback required on several CRs to understand supported options and considerations
Decision Proposals
Coming soon
- Consent Model and technical roadmap including FAPI 2.0 adoption.
Under Review
- Enhanced Error Handling, Payload Structure: Decision proposal 119
- Enhanced Error Handling, Identification of additional HTTP Status Codes: Decision proposal 122.
- Enhanced Error Handling, Application of HTTP Status Codes: Decision proposal 121.
Open
- Enhanced Error Handling, Catalogue: Refer to consultation Decision proposal 120
- Enhanced Error Handling, CX: Decision proposal 127.
- Workshop planned for August 11th
- Event registration TBC
Notes
- List of iterations candidates was supported. The final scope for the iteration has been adopted: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/projects/3
- Analysis of NPP change request is being considered by WBC and further analysis will be posted to #229 in the coming fortnight.
- The DSB has progressed most items with questions or clarifications as required. Options have been identified for many issues and feedback has been requested
- Data Holders are currently aware of this and are reviewing their responses internally before posting updates accordingly
Maturity instructions for a term deposit may not always be known #153
- In principle support to keep
maturityInstructions
mandatory and apply a default where no explicit customer instruction is provided - In principle support to extend the enumerated type to accomodate holding facilities as a third maturity instruction
- DHs progressing further analysis to be published to the GitHub Issue
ANZSIC Code multiple version support #42
- Appears that most DHs don't implement ANZSIC or ANZSCO codes consistently for all customers
- Some DHs use legacy formats and cannot map to 2006 version of the codes
- Participants on the call accept where the value is not available or cannot be mapped that no value is returned
- No consensus on whether a version field is required to be supplied when a code is available
Addition of enums for extensionUType and service in extendedData - BankingTransactionDetail #181
Service field in the Get Transaction Details API #229
- Further analysis from DHs is required to progress this issue
- Assumption by participants on the call that schema changes will also be necessary
- A fourth service type is expected to be introduced shortly (to be advised)
- X2P1.04 is also due mid 2021 with NPP intending to publish a new service type on an annual basis
A loan may have no end date but loanEndDate is mandatory #150
- Example products will be provided by the DH who raised the CR
- Rather than making these fields optional, the preference is to define a different product type/category that has different constraints rather than make all the fields optional
- No position agreed
A payee may have no nickname provided by the customer #151
- Preference to keep this field mandatory
- DHs are reviewing what the default behaviour is within existing banking channels to determine whether an appropriate default can be returned
- In principle support for a default value "determined by the Data Holder in line with existing digital banking channels"
CRN in BankingBillerPayee should be optional #152
- Identified situation where BPAY CRN is generated on the fly "Intelligent Customer Reference Number"
- DHs reviewing this issue and will provide further analysis
- No position agreed
Negative Available Balance in Get Balances response #177
- DHs reviewing this and will provide further analysis shortly
- No position agreed
Update Query Parameter Transaction #176
- Issue discussed, no position agreed
Update claims permitted in Token Introspection #273
- Issue discussed, no position agreed
Transition arrangements for November 2020 CDR Consent obligations #272
- Issue discussed, pending DSB proposal
Update Get Metrics rejections counts and clarify affected APIs #271
- Issue discussed, no position agreed
'SHOULD' for access token revocation #240
ADR Revocation Endpoint #247
Decrement BankingProduct #266
- Issues are included in this iteration but were not discussed on the call
Other business
- No other business
Next Steps
—