Skip to content

DSB Maintenance Iteration 5: Final Checkpoint: Agenda & Meeting Notes (12th November 2020)

Jump to bottom
CDR API Stream edited this page Nov 10, 2020 · 7 revisions

Date and time: 12/11/2020, 1pm - 2.00pm AEST (2pm - 3.00pm AEDT)
Location: WebEx

Chair: Mark Verstege, DSB
Maintenance overview: Further information
Maintenance project board: See here
Decision Proposal: This maintenance iteration is being consulted on under Decision Proposal 138

Agenda

Meeting notes

Introductions

  • Allow for participants to join
  • Housekeeping
  • Overview, purpose and intended outcomes of the meeting

Actions

  • (Done) DSB to seek request for urgent treatment of Issue #325
  • (Done) ADR/DHs to confirm request for urgent treatment of Issue #325
  • (Done) CBA to provide options for dealing with #315 - Obligation based standards
  • (In Progress) DSB to follow up with the ACCC regarding legal liabilities regarding access token revocation if this was changed to a SHOULD for Issue #240
  • (In Progress) DSB to follow up with ADRs to get volume/frequency metrics for loss of refresh token issues regarding Issue #219
  • (In Progress) DHs to provide implementation impact analysis for Issue #325
  • (In Progress) DSB to publish consent lifecycle for input into Issue #175
  • DSB to request that the second concern in Issue #247 of an adjacent polling method be raised as a separate change request
  • DSB to publish recent clarifications of going-forwards position on payload and end point versioning to Issue #311

For discussion

NPP update

  • DSB / NPPA NDA complete
  • DSB access to NPPA technical documentation pending

Change Requests For Discussion

  1. #315: Obligation date-based standards
    • For discussion
      • InfoSec versioning - profile level or section?
      • Future dated obligation table changes
      • Draft implementation branches and public staging repository
  2. #300: Alternate implementations for one-time consent
    • Proposal: Adopt maximum 24 hour sharing duration to be allowed for one-time consent for separation of collection and use
    • For Discussion:
      • Intent is to make it clear what one-time collection is but this doesn't preclude ongoing data sharing use cases having overlapping sharing durations
      • Is there a better way to describe in the standards the distinction between consent, collection and use. e.g. one-time consent to collect vs ongoing consent to collect?
    • Assumption: This is a non breaking change
  3. #325: Future dated obligation for change to how audience is set for Data Recipients calling Data Holders
    • Proposal: Decision Proposal posted to #325. For walkthrough and discussion
  4. #301: Consider changing BankingScheduledPayment to allow the capture of multiple nicknames and payeeReferences
  5. #318: [1.5.0] Missing Changelog Item: (Nearly) All Enumerations Reordered
    • Proposal: strictly order all enums by natural sort order
  6. #219: Allow retrieval of current refresh_token by arrangement ID
  7. #320: [1.5.0] BPAY crnType introduced as mandatory and backported into existing version

Resolved Change Requests

CR # Issue Title Outcome Status Issue Link
#321 DepositRateType - Valid list of enumerations Clarification provided. Standards documentation to be updated to include clearer requirement Documentation change https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/321
#309 paymentsRemaining cannot currently be 0 Non-normative example to be fixed to show value of "1" Documentation change https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/309
#300 Alternate implementations for one-time consent Standards documentation to be updated to support one-time collection and ongoing use Change Supported https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/300
#307 Make Metrics API Brand Aware CR closed by creator No Change https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/307
#312 Implement Redirects for old Consumer Data Standards links URL redirection has been fixed Change adopted https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/312

#301 Consider changing BankingScheduledPayment to allow the capture of multiple nicknames and payeeReferences

Current Situation

Scheduled payments only allow for a global payee reference and payee nickname to be set regardless of the number of payment instructions in the payment set which each might represent different transactions to different payees. As such, banks cannot cater for different payee references and payee nicknames for each transaction.

Problem Statement

Currently the payee reference and the nickname, acting as short display name for the payee, are required when describing a scheduled payment. However, many banks allow their customers to enter different payee references for each payment instruction in the scheduled payment's payment set. This would not preclude a common payee reference, but if present, it should be superseded by references for each payment in the payment set.

Further to this, the intention of nickname was a display name for the scheduled payment itself not the payee, so making this clear is important.

Options

Options Considered Description Impacts and Implications
Option A - No change Current state - this would mean that the individual payments within a scheduled payment set could not support a payee reference or nickname and only a global payee reference could apply. This would be in objection to how many of the banks have described their solutions offered to customers
  • No change
  • Payee reference unlikely to be used by banks because they allow customers to set the payment reference on a payment instruction level not at the global scheduled payment level
Option B - Make existing fields optional Make the existing nickname and payeeReference fields optional. This would allow banks to leave this data out if they don't support global instructions but still has the shortcomings of Option B.
  • Breaking change
  • Little difference to the current state which allows for empty string to be presented when the data is not provided
  • Doesn't solve the core problem of allowing multiples
Option C - Support individualised payee references
RECOMMENDED 		This change would allow for payee reference to be set as a global value but also override at the individual payment instruction within the payment set. This would allow the greatest flexibility whilst solving for current banking experiences.
  • Breaking change impact to ADRs and DHs however that is to be validated with the community.
  • Alignment of future dated obligations should consider impact and overhead to non major banks so they don't have to support multiple versions
  • Allows for both global and individual payment references

Options Analysis

Option Ecosystem Cost/Effort Architecture Alignment Functional Match Security Alignment Extensibility Ongoing Maintenance
Option A - No change ✅ ❌ ❌ ✅ ❌ ✅
Option B - Make existing fields optional ✅ ❌ ❌ ✅ ❌ ✅
Option C - Support individualised payment references ⭐ ✅ ✅ ✅ ✅ ✅

Legend

  • ✅ - aligned / good fit
  • ⭐ - partially aligned / fit
  • ❌ - poor alignment / fit

Option C changes proposed

*changes marked in italics.

To accommodate for multiple payee references, the following changes are recommended:

Model Field Field Conditionality Field Description Change required
BankingScheduledPayment payeeReference conditional The reference_, if applicable,_ for the transaction that will be used by the originating institution for all payments in the payment set for the purposes of constructing a statement narrative on the payer’s account. Empty string if no data provided Change payeeReference to be conditional
BankingScheduledPayment nickname optional OR mandatory The short display name of the scheduled payment as provided by the customer if provided. Where a customer has not provided a nickname, a display name derived by the bank for the scheduled payment consistent with existing digital banking channels Change nickname to be defined as the display name of the scheduled payment, not the payee
BankingScheduledPaymentTo nickname optional The short display name of the payee as provided by the customer unless toUType is set to payeeId Add payee nickname as an optional field in BankingScheduledPaymentTo
BankingScheduledPaymentTo payeeReference conditional The reference for the transaction that will be used by the originating institution for the given payment in the payment set for the purposes of constructing a statement narrative on the payer’s account. If not empty, it overrides the value provided at the BankingScheduledPayment level Add payeeReference as a conditional field in BankingScheduledPaymentTo.

Impacted Endpoints

  • Get Scheduled Payments for Account v1
  • Get Scheduled Payments Bulk v1
  • Get Scheduled Payments For Specific Accounts v1

All end points are current version 1 and this change might result in a v2 to all three end points.

Implementation Considerations

This change may be considered as non-breaking if DHs are comfortable with the change not creating implementation impact. Because the change would downgrade a mandatory field to conditional, it could be seen as non breaking from the perspective that any bank that is compliant with the mandatory setting of the field would continue to be compliant. As ADRs have not yet built to a productionised versions (DHs are going live the end of November), this could be dealt with without breaking change impact to ADRs.

However, this change would, if considered a breaking change by the community, would result in a future dated obligation because it would impact existing ADR client implementations. Data Holders would only be impacted if they continued to support. Initial Data Holders: initial data holders commenced production implementation of scheduled payment APIs from November 2020. This change would have an impact on their existing implementations Non-Major Data Holders: non-majors are required to implement scheduled payment APIs from November 2021. This change would have an impact on currently delivery and the provision of two versions would be overhead that could be avoided. The proposal of a future dated obligation of November 2021 would align with non-major implementation timeframes, and allow for a four-month implementer's draft for additional changes to these end points. At the same time, for non majors, they could adopt v2 without a v1 obligation. This would also provide sufficient timeframes for ADRs to update their builds.

Stakeholder / System impact Impact analysis Considerations Proposed milestones
Initial Data Holder HIGH Must support both v1 and v2 of scheduled payment APIs November 2021
Non-Major Data Holder HIGH Proposed only need to support v2 of scheduled payment APIs November 2021
ADR MODERATE Any use cases consuming scheduled payments must be updated to accomodate v2 November 2021
CDR Register NONE No impact N/A
Conformance Test Suite NONE No impact: CTS does not test conformance of banking APIs N/A
DSB Validation Tools LOW Impact to Java Artefacts to check for conditional implementation and overrides Prior to DH obligations

#320 BPAY crnType introduced as mandatory and backported into existing version

Background

Related GitHub Issues:

Current Situation

In Maintenance iteration 4, a change was approved for BPAY CRN and the introduction of a BPAY CRN Type. This change had identified a July 2021 future dated obligation but the standards were changed without setting an obligation date. Upon review of this and the DSB's process, this change was reversed by the Data Standards Chair and the existing standards definition for BPAY CRN was re-instated.

This change request looks at how to deal with BPAY CRNs for intelligent and variable CRNs in a current state as well as the ideal target state with a clear future dated obligation.

Because "crn" is a mandatory field (although it is described as conditional, this is to accomodate masked credit card PANs, not conditional for absent CRNs), to be compliant with the data standards, any payee without a crn must be omitted from the list of biller payees. This is undesirable, hence a need for a change.

Problem Statement

Currently CRN must be provided in the BankingBillerPayee record but this cannot accommodate variable and intelligent CRNs where the CRN is not known or unchanging.

Key considerations

Variable and Intelligent CRNs are not always known by banks. Whilst in some cases they may, they are unlikely to be relevant or populated for biller payees. Whilst support through the CRN Type can be utilised, its purpose is more relevant for transactions or scheduled payments.

This would require conditional support to populate the CRN when the type is determined to be variable or intelligent. Similarly, consideration should be given to whether a default value of UNKNOWN or VARIABLE should be applied for the CRN Type for Biller Payees.

The change is being considered to BankingBillerPayee which has upstream API endpoint impact to:

  • Get Scheduled Payments for Account v1
  • Get Scheduled Payments Bulk v1
  • Get Scheduled Payments For Specific Accounts v1
  • Get Payee Detail v1

Indirectly, the following API endpoints are also impacted by this change request:

  • Get Transactions For Account v1
  • Get Transaction Detail v1

This is because these two endpoints present a CRN as a valid transaction reference. The inclusion of the type of CRN ought to be considered for banking transactions as well. Further to this, the definition of the CRN in the banking transaction response is inconsistent with the BankingBillerPayee reference which also considers the CRN to be masked where the CRN contains a credit card PAN.

Options

Options Considered Description Impacts and Implications
Option A - No Change

No change is made and any biller payees without a CRN would not be returned.

Description of the CRN is updated to make clear the masking requirements for sensitive information.
  • Variable and Intelligent BPAY billers would not be returned in the list of payees
  • Results in an incomplete data set and a non ideal end state
Option B - Make CRN Optional

CRN is made optional where the data holder does not collect it or cannot identify it or derive it. No CRN Type is defined.

Description of the CRN is updated to make clear the masking requirements for sensitive information.
  • The type of CRN is not provided to the client and future changes which may make it easier to consistently determine the type of CRN would not be possible
Option C - Introduce CRN Type and make CRN conditional
RECOMMENDED

CRN is made optional where the data holder does not collect it, or cannot identify it or derive it. CRN Type is introduced as an optional value so that it can be provided when known.

Description of the CRN is updated to make clear the masking requirements for sensitive information.
  • Variable CRN Type can be used where the DH cannot determine that the CRN is an intelligent CRN

Options Analysis

Option Ecosystem Cost/Effort Architecture Alignment Functional Match Security Alignment Extensibility Ongoing Maintenance
Option A - No change ✅ ❌ ❌ ✅ ❌ ❌
Option B - Make CRN Optional ✅ ⭐ ⭐ ✅ ❌ ⭐
Option C - Introduce CRN Type and make CRN conditional
RECOMMENDED		 ⭐ ✅ ✅ ✅ ✅ ✅

Option C changes proposed

To accommodate for multiple payee references, the following changes are recommended:

Model Field Field Conditionality Field Description Change required
BankingTransaction crn optional BPAY CRN for the transaction (if available). Must be present if the type of CRN is FIXED_CRN. Where the CRN is not recorded, such as for variable CRNs, an empty string value MUST be supplied.
Where the crn contains sensitive information, it should be masked inline with how the Data Holder currently displays account identifiers in their existing online banking channels. If the contents of the CRN match the format of a Credit Card PAN they should be masked according to the rules applicable for MaskedPANString. If the contents are are otherwise sensitive, then it should be masked using the rules applicable for the MaskedAccountString common type. 		Change CRN to require masking under appropriate circumstances. This change is being made to make it clear the pre-existing requirements for CRN values and it is not considered a breaking change.
Affects:
  • Get Transactions For Account v1
  • Get Transaction Detail v1
BankingTransaction crnType conditional

Denotes the type of CRN of the transaction if it is known or can be derived (null otherwise).

FIXED_CRN: A unique reference number such as a credit card or a fixed reference number identifying a customer's account that does not change with each bill.

VARIABLE_CRN: Biller generated reference number provided to the customer that is unique to each bill.

INTELLIGENT_CRN: Biller generated reference number provided to the customer that is unique to each bill which fixes the amount of the bill being paid, expiry date or both.

Change to accomodate a CRN type, where it is known. This provides further information to the client about the CRN. This is not considered a breaking change because vs v1.5.0 of the data standards, this change proposes the field is only conditionally populated when known and when it cannot be derived, a null value is sufficient (that is, treat it as optional). 

This means clients could continue to consume the payload response without breaking their implementation because this new field would provide additive informational data not required data.


Affects:
  • Get Transactions For Account v1
  • Get Transaction Detail v1
BankingBillerPayee crn conditional BPAY CRN of the Biller. Must be present if the type of CRN is FIXED_CRN. Where the CRN is not recorded, such as for variable CRNs, an empty string value MUST be supplied.
*Must be present if the type of CRN is FIXED_CRN. *Where the crn contains sensitive information, it should be masked inline with how the Data Holder currently displays account identifiers in their existing online banking channels. If the contents of the CRN match the format of a Credit Card PAN they should be masked according to the rules applicable for MaskedPANString. If the contents are are otherwise sensitive, then it should be masked using the rules applicable for the MaskedAccountString common type. 		Change CRN to require masking under appropriate circumstances. The CRN is required where the CRN is a FIXED_CRN and is known for the payee. This is not considered a breaking change because vs v1.5.0 of the data standards, this change proposes the field is only conditionally populated when known. 

This means that current implementations would not be required to change their interface contract with the client. They would only require a data change to be more complete (see next statement).

This removes the current limitation where Data Holders cannot present the CRN when the payee reference includes a variable or intelligent CRN.


Affects:
  • Get Scheduled Payments for Account v1
  • Get Scheduled Payments Bulk v1
  • Get Scheduled Payments For Specific Accounts v1
  • Get Payee Detail v1
BankingBillerPayee crnType conditional

Denotes the type of CRN if it is known or can be derived (null otherwise).

FIXED_CRN: A unique reference number such as a credit card or a fixed reference number identifying a customer's account that does not change with each bill.

VARIABLE_CRN: Biller generated reference number provided to the customer that is unique to each bill.

INTELLIGENT_CRN: Biller generated reference number provided to the customer that is unique to each bill which fixes the amount of the bill being paid, expiry date or both.

 Change to accomodate a CRN type, where it is known. This provides further information to the client about the CRN. This is not considered a breaking change because vs v1.5.0 of the data standards, this change proposes the field is only conditionally populated when known and when it cannot be derived, a null value is sufficient (that is, treat it as optional). 

This means clients could continue to consume the payload response without breaking their implementation because this new field would provide additive informational data not required data.


Affects:
  • Get Scheduled Payments for Account v1
  • Get Scheduled Payments Bulk v1
  • Get Scheduled Payments For Specific Accounts v1
  • Get Payee Detail v1

Impacted Endpoints

  • Get Scheduled Payments for Account v1
  • Get Scheduled Payments Bulk v1
  • Get Scheduled Payments For Specific Accounts v1
  • Get Payee Detail v1
  • Get Transactions For Account v1
  • Get Transaction Detail v1

Because this change is considered as a non-breaking interface contract change to existing implementations, this would not result in versioning of the affected endpoints. All end points would remain at v1 and the change could be adopted by data holders as soon as is practicable.

Implementation Considerations

Care has been taken to deal with this issue in totality without creating a breaking change. Contrasted to the approach taken in Maintenance Iteration 4 which resulted in CRN and CRN Type being mandatory and a breaking change, this change proposal seeks to apply defaults where they cannot be determined. Further to this, it considers the broader impact of CRN and BPAY billers beyond just the Get Payee end points.

Stakeholder / System impact Impact analysis Considerations Milestones
Initial Data Holder MODERATE
  • May require updates to existing payload responses to accommodate the BPAY billers without CRNs
  • Requires update of CRNs to include the associated CRN Type for transactions and billers where it is known or can be derived
 N/A
Non-Major Data Holder LOW
  • Non-major ADIs can ensure they go live next year with all BPAY biller payees in the customer's payee address book being supported
 November 2021*
(this is the currently phasing of the affected end points and there is no new impact or obligation imposed)
ADR LOW
  • ADRs can update their client applications to make use of the extended data set and CRN type at their discretion
 N/A
CDR Register NONE No impact N/A
Conformance Test Suite NONE No impact: CTS does not test conformance of banking APIs N/A
DSB Validation Tools LOW
  • Impact to Java Artefacts to check for conditional implementation and overrides
 January 2021

Any other business

For discussion

Open Change Requests

The following change requests have been proposed for this iteration:

  1. #152: CRN in BankingBillerPayee should be optional
  2. #320: [1.5.0] BPAY crnType introduced as mandatory and backported into existing version
  3. #229: Service field in the Get Transaction Details API / #181
  4. #300: Alternate implementations for one-time consent
  5. #175: Premature Completion of Consent (Hybrid) Flow
  6. #219: Allow retrieval of current refresh_token by arrangement ID
  7. #240: 'SHOULD' for access token revocation
  8. #325: Future dated obligation for change to how audience is set for Data Recipients calling Data Holders
  9. #307: Make Metrics brand aware
  10. #315: Obligation based standards
  11. #150: A loan may have no end date but loanEndDate is mandatory
  12. #301: Consider changing BankingScheduledPayment to allow the capture of multiple nicknames and payeeReferences
  13. #309: paymentsRemaining cannot currently be 0
  14. #310: [1.4.0] BankingProductFee feeType adds Variable which is a new payload version
  15. #318: [1.5.0] Missing Changelog Item: (Nearly) All Enumerations Reordered
  16. #319: [1.5.0] Missing Changelog Item: Maturity Instructions
  17. #321: [1.5.0] Clarification of future obligation dates
  18. #247: ADR Revocation Endpoint

Meeting Minutes

Notes

TBA

Other business

TBA

Next Steps

Actions

TBA

Getting Started

Meetings

Maintenance Iterations

CDR Implementation Call

Clone this wiki locally