-
Notifications
You must be signed in to change notification settings - Fork 56
DSB Maintenance Iteration 5: Final Checkpoint: Agenda & Meeting Notes (12th November 2020)
Date and time: 12/11/2020, 1pm - 2.00pm AEST (2pm - 3.00pm AEDT)
Location: WebEx
- https://csiro.webex.com/csiro/j.php?MTID=md498fcab7a2000cbb4b0072b4b266111
- Dial In Number: +61 2 6246 4433
- Dial In Access Code: 165 106 9550
- Quick Dial: +61262464433,1651069550%23%23
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
- Introductions
- Outstanding Actions
- Change Requests For Discussion: change requests and decision proposals for discussion
- Any other business
Meeting notes
- Allow for participants to join
- Housekeeping
- Overview, purpose and intended outcomes of the meeting
- (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
NPP update
- DSB / NPPA NDA complete
- DSB access to NPPA technical documentation pending
Audience Claim Issue 325
- Consultation on DP325 closes COB Monday 16/11/20
- Current plan is to create v1.6.0 of the data standards to address this urgent change, only.
-
#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
-
For discussion
-
#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
-
#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
-
#301: Consider changing BankingScheduledPayment to allow the capture of multiple nicknames and payeeReferences
- Refer to #301 analysis
-
#318: [1.5.0] Missing Changelog Item: (Nearly) All Enumerations Reordered
- Proposal: strictly order all enums by natural sort order
- #219: Allow retrieval of current refresh_token by arrangement ID
-
#320: [1.5.0] BPAY crnType introduced as mandatory and backported into existing version
- Refer to #320 analysis
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
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.
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 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 |
|
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. |
|
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. |
|
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
*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 . |
- 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.
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 | MODERATE | Must support both v1 and v2 of scheduled payment APIs | November 2021 |
Non-Major Data Holder | MODERATE-LOW | Proposed only need to support v2 of scheduled payment APIs | November 2021 |
ADR | MODERATE-LOW | 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 |
Related GitHub Issues:
- https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/152
- https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/320
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.
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.
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 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. |
|
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. |
|
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. |
|
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 |
⭐ | ✅ | ✅ | ✅ | ✅ | ✅ |
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:
|
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:
|
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:
|
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
- 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.
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 |
|
N/A |
Non-Major Data Holder | LOW |
|
November 2021* (this is the currently phasing of the affected end points and there is no new impact or obligation imposed) |
ADR | LOW |
|
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 |
|
January 2021 |
For discussion
The following change requests have been proposed for this iteration:
- #152: CRN in BankingBillerPayee should be optional
- #320: [1.5.0] BPAY crnType introduced as mandatory and backported into existing version
- #229: Service field in the Get Transaction Details API / #181
- #300: Alternate implementations for one-time consent
- #175: Premature Completion of Consent (Hybrid) Flow
- #219: Allow retrieval of current refresh_token by arrangement ID
- #240: 'SHOULD' for access token revocation
- #325: Future dated obligation for change to how audience is set for Data Recipients calling Data Holders
- #307: Make Metrics brand aware
- #315: Obligation based standards
- #150: A loan may have no end date but loanEndDate is mandatory
- #301: Consider changing BankingScheduledPayment to allow the capture of multiple nicknames and payeeReferences
- #309: paymentsRemaining cannot currently be 0
- #310: [1.4.0] BankingProductFee feeType adds Variable which is a new payload version
- #318: [1.5.0] Missing Changelog Item: (Nearly) All Enumerations Reordered
- #319: [1.5.0] Missing Changelog Item: Maturity Instructions
- #321: [1.5.0] Clarification of future obligation dates
- #247: ADR Revocation Endpoint
TBA
TBA
TBA