DSB Maintenance Iteration 9: Agenda & Meeting Notes (03 November 2021) - ConsumerDataStandardsAustralia/standards GitHub Wiki

DSB Maintenance Iteration 9 - Agenda & Meeting Notes (2021-11-03)

Date and time: 03/11/2021, 2pm - 3.30pm AEDT (1pm - 2.30pm AEST)
Location: WebEx
Dial-in details:

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

Agenda

  • Wait 5 minutes for all participants to join. Kickoff at 2:05pm (AEDT)
  • Outstanding Actions
  • Release plan: schedule of forwards looking standards releases
  • Open Decision Proposals: key consultation dates
  • Iteration 9 change request candidates
  • Any other business

Meeting notes

Introductions

This week is the fifth call of the 9th maintenance iteration. The purpose of the meeting is to discuss options for iteration candidates adopted in the 9th maintenance iteration.

Please note: This maintenance iteration has been extended by 4 weeks and will conclude 1st December 2021. This is to incorporate energy change requests and align to end of year shutdown.

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

Actions

  • WBC to create proposed featureType descriptions for each enumerated featureType proposed in issue 401
  • ANZ to create a change request to better support cursors for returning large result sets.
  • (#291) Stay Or Go to provide examples of loyalty scheme data
  • (#291) [IN PROGRESS] DSB to propose initial structure for consultation
  • (IDToken) DSB to create a CR for customer definition
  • (IDToken) [IN PROGRESS] DSB to seek clarification regarding rules for nominated representatives

Release plan

  • v1.12.0 was published on 14th of October 2021: This release contains binding non-functional requirements for banking and energy
  • v1.13.0 was published published on the 22nd of October 2021: porting of Register standards from ACCC
  • v1.14.0 was published on the 29th of October 2021: Energy API standards
  • v1.15.0+: no current release candidates are scheduled

Open / Active Decision Proposals

The following decision proposals are open for community feedback

DP # Closing date DP
216 19/02/2022 Decision Proposal 216 - Profile Scope Support
209 16/11/2021 Decision Proposal 209 - Transition to FAPI 1.0 Advanced Profile
TBC Pending Decision Proposal TBC - Data Recipient Security Standards
211 Pending Decision Proposal 211 - Scope of Risk-based Authentication and Identity Proofing Framework, Threat and Attack Model
210 Pending Decision Proposal 210 - Transition to FAPI 2.0 Profile
203 No closing date Normative Standards Review (2021)
158 Closed Decision Proposal 158 - Participant capability discovery

Future Plan

Review of Q4 and new changes: https://github.com/ConsumerDataStandardsAustralia/future-plan/projects/1

Iteration 9 Change Requests

All open change requests can be found here:

Data Standards CRs:

Maintenance Iteration Schedule

  • Maintenance Iteration 9 extended until 1st December 2021
  • Proposed that Maintenance Iteration commence 16th Feb 2022

Issues Consulted

The following issues have been consulted on during this iteration. The current status is summarised.

Standards Maintenance Issues

Source # Change Request Status Recommendation Affected Schema
(if applicable)		 Affected Endpoint
(if applicable)
Standards Maintenance Issue 404 Profile scope not aligned with CX standards DP216 is live This issue will be consulted on in Decision Proposal 216 - Profile Scope Support given the breadth of the standards changes N/A
  • ID Token
  • OIDC UserInfo endpoint
Standards Maintenance Issue 395 Does DHs' PAR endpoint require enabling private key jwt client authentication in addition to request object validation? No change No change N/A N/A
Standards Maintenance Issue 397 Transaction Security Ciphers Alternative supported Defer to FAPI 1.0. The change proposed by the DSB to defer to FAPI standards will be included in the DP 209 consultation. Standards will be changed in accordance to the schedule for FAPI 1.0 adoption N/A N/A
Standards Maintenance Issue 406 Change Request to make 'scope' optional in the token end-point response in FAPI Not supported Retain current requirement for scope support. Alignment to FAPI 1.0 (Final) requirements for the scope value will be included in the DP 209 consultation. Standards will be changed in accordance to the schedule for FAPI 1.0 adoption N/A
  • oAuth Token endpoint
Standards Maintenance Issue 150 A loan may have no end date but loanEndDate is mandatory Supported - Breaking Change Change repaymentFrequency, loanEndDate and nextInstallmentDate fields to be optional.
  • BankingLoanAccount
  • Get Account Details (v1 -> v2)
Standards Maintenance Issue 396 Define new Digital Wallet Payee Type to relevant schemas Supported - Breaking Change Extend payee support for provider-agnostic digital wallets. Get Payees v2 and Get Payee Detail v2 future-dated obligation of 31st of March 2022. Data Holders can support v2 as early as is practical but no later than 31st of March 2022. Retirement of v1 APIs 1 month after v2 FDO (i.e., any time after 31st April 2022).
  • BankingPayee
  • BankingPayeeDetail
  • Get Payees (v1 -> v2)
  • Get Payee Detail (V1 -> v2)
Standards Maintenance Issue 405 Alternative mechanisms for OTP Under consultation No recommendation yet made N/A N/A
Standards Maintenance Issue 407 Align data quality NFR with Privacy Safeguard 11 Change supported Changes to Data Quality NFRs working in line with OAIC feedback regarding data quality requirements in relation to Privacy Safeguard 11 N/A N/A
Standards Maintenance Issue 402 Support for multiple additional information documents Change proposed; Under consultation Proposes changes to supported multiple additional product documents BankingProductV3
  • Get Products (v3 -> v4)
  • Get Product Detail (v3 -> v4)
Standards Maintenance Issue 401 Extending the list of supported feature types Under consultation Proposes changes to supported feature types
  • BankingProductFeature
  • Get Product Detail (v3 -> v4)
  • Get Account Detail (v1 -> v2)
Standards Maintenance Issue 291 Credit card loyalty program data: significant gaps and lack of structure Under consultation Proposes changes to better support loyalty schemes
  • BankingProductDetailV3
  • BankingAccountDetail
  • Get Product Detail (v3 -> v4)
  • Get Account Detail (v1 -> v2)
Standards Maintenance Issue 292 Credit card balance plans and payment hierarchy: inadequate information within the CDS Under consultation Proposes changes to supported multiple payment plans and balances
  • BankingProductDetailV3
  • BankingAccountDetail
  • Get Product Detail (v3 -> v4)
  • Get Account Detail (v1 -> v2)
Standards Maintenance Issue 391 Remove requirement for at least one address in physicalAddresses array Under consultation Proposed change to remove requirement of at least one address to be returned. Feedback from DHs has indicated that this is not always possible when the address held on record is invalid
  • CommonPersonDetail
  • CommonOrganisationDetail
  • Get Customer Detail (v1 -> v2)

CDR Register Maintenance Issues

Source # Change Request Status Recommendation Affected Schema
(if applicable)		 Affected Endpoint
(if applicable)
CDR Register Issue 169 Update Register APIs to search for and differentiate between archived entities Change supported Documentation fixes. Staged and published after v1.13.0 release N/A N/A
CDR Register Issue 189 RegisterDataHolderAuth schema in GetDataHolderBrands descriptions to be clarified Change supported Documentation fixes. Staged and published after v1.13.0 release N/A N/A
CDR Register Issue 188 SSA definition: Deprecation of revocation_uri Change supported Documentation fixes. Staged and published after v1.13.0 release N/A N/A
CDR Register Issue 186 Documentation improvement: JWT Signature verification requirements during the DCR flows Change supported Documentation fixes. Staged and published after v1.13.0 release N/A N/A
CDR Register Issue 174 Update Register APIs to search for and differentiate between archived entities Delayed Carried over to next iteration N/A N/A
CDR Register Issue 126 Consider changing statement in Certificate Management about the use of ACCC CA issued certificates for ADR end points Delayed To be consulted on under DP 211 threat modelling N/A N/A
CDR Register Issue 123 Consider identicons to allow DHs to provide multiple attributes to map to individual accreditations Under consultation Requesting feedback. No recommendation has been made. N/A N/A
CDR Register Issue 175 Publish an endpoint version schedule to document the introduction and deprecation of Register and DCR endpoints Documentation enhancement This will be covered with the merging of the CDR Register standards into the Consumer Data Standards. Deprecation schedules for various endpoint versions can then be discussed in future maintenance iterations N/A N/A

Cross-Sector & InfoSec Data Standards Issues For Consultation

No issues for discussion.

Banking Data Standards Issues For Consultation

Issue 402: Support for multiple additional information documents

  • For discussion

Issue 401: Extending the list of supported feature types

  • For discussion

Issue 291: Credit card loyalty program data: significant gaps and lack of structure

  • For discussion

  • Observations:

    • Some products offer multiple loyalty programs (for an additional fee, dollars spent can accrue airline frequent flyer points instead of the bank's own rewards points)
    • Earn rates often come with conditions and these can vary between banks such as min and max spends, time periods, opt-in to higher rewards program etc.
    • Eligibility conditions tend to focus on what transactions accrue points and this has the potential to change the accrual rate (e.g. international payments, payments to preferred or designated merchants, etc.)
    • Rewards can be redeemed in many ways and this may be important to consumers when comparing products (redeem for digital eCards, redeem for physical goods in a bank's rewards store, transferrable to another rewards program, etc.)
    • many products offer an introductory points offer and bonus rates
    • Few banks currently describe their loyalty program data completely or correctly via the CDR (vs online or PDS)
    • Banks will refer to their loyalty programs by marketing names "e.g. Ultimate Awards"
    • Banks offer a lot of descriptive features and additional information that explain the rewards program

  • Design Question 1: Should Loyalty Rewards continue to be modelled as a feature of the product? Or should rewards be modelled as their own resource?

    • Earn rates, fees and features are highly dependent on the product offering
    • Banks tend to offer common rewards programs where the features vary based on the product
    • Loyalty program data could be modelled as its own resource and the categories (e.g. Gold/Silver/Bronze) modelled under the loyalty program level

  • Design Question 2: Should products be queryable based on rewards features / earn rates / etc.?

    • Adds load to DH processing of product data
    • Enriches the querying and filtering of PRD data

  • Design Question 3: Should "points accrued" be supported (voluntarily) for transaction data?

    • This would allow ADRs to ascertain points awarded for each spend
    • If accrual of rewards points is important, ADRs could then offer complementary services

  • Loyalty PRD Data

    • can have fees associated
    • introductory offers
      • conditions
      • expiry date / apply before date
    • eligibility
    • tiered earning rates
      • expiry date of tier
      • min spend
      • max spend
    • bonus rates
    • different rewards schemes (option to choose from them and may incur additional fees) []
    • Rewards Available []
    • Eligible earning partners / transactions []
    • Point transfers allocations

  • Are there any other design questions or requirements?

Issue 292: Credit card balance plans and payment hierarchy: inadequate information within the CDS

  • For discussion
  • Current state:
    • Account Detail can have only zero or one loan
    • Product Detail can have many lending rates but don't have balance plan details
Balance Plan Attribute BankingLoanAccount mapping
Plan Name new
Plan Type (e.g. Purchase, Cash Advance, Balance Transfer, Instalment Plan) repaymentType -> requires expanding
Interest Rate BankingAccountDetail-> lendingRate (would require linking to loans[]
Term inferred?
Plan Creation Date originalStartDate
Plan Expiry Date loanEndDate
Payment Hierarchy Position new
Starting Balance originalLoanAmount, originalLoanCurrency
Current Balance new
Instalment Amount nextInstalmentDate, minInstalmentAmount, minInstalmentCurrency
Instalment Frequency repaymentFrequency
Balance Plan Attribute BankingProductLendingRateV2 mapping
Plan Name new
Plan Type (e.g. Purchase, Cash Advance, Balance Transfer, Instalment Plan) lendingRateType -> requires expanding, repaymentType
Interest Rate rate, comparisonRate, tiers
Term Not applicable
Plan Creation Date Not applicable
Plan Expiry Date Not applicable
Payment Hierarchy Position new
Starting Balance Is a minInvestment / maxInvestment required? Is this $ or also %?
Current Balance Not applicable
Instalment Amount nextInstalmentDate, minInstalmentAmount, minInstalmentCurrency
Instalment Frequency calculationFrequency, applicationFrequency, interestPaymentDue

CDR Register CRs:

Issue TBD: Data Holder Multi-Sector support

  • For discussion

Issue TBD: Data Recipient Multi-Sector support

  • For discussion

Energy Data Standards Issues For Consultation

No items for discussion

Any other business

  • Address any other business arising from the community



Meeting Minutes

Notes

Register Issues TBC

Standards Maintenance Issues

  • Banking

    • Issue 402: Support for multiple additional information documents

      • Discussed options presented. Option 3 was preferable with inclusion of the additional description represented in the Option 2 proposal
      • Option 3 minimises breaking change. The array of secondary documents would be change to an array of objects including description an URI

    • Issue 401: Extending the list of supported feature types

      • Westpac have provided descriptions for the proposed new feature types
      • CASHBACK for an offer should be treated differently to cashback for a transaction
      • Discussed moving offers into a separate well-defined object to represent offers more thoroughly
      • Instalment plans are one type of balance plan and relate to the CR raised on issue #292 (may also apply to asset finance, personal loans, margin loans etc.)
      • Instalment plans would benefit from an enumerated type and uType

    • Issue 291: Credit card loyalty program data: significant gaps and lack of structure

      • Design question 1:
        • Difficult to describe loyalty programs in the current product feature structure
        • Needs its own structured representation
        • It was suggested that because loyalty programs are common across industries, it would be better to represent a loyalty program as a resource in the Common APIs and link this to the products.
        • Product specific characteristics such as earn rates can then be described in the product
        • For example GetLoyaltyPrograms and GetLoyaltyProgramDetails
        • Would allow other industries to voluntarily offer their loyalty data and it allows existing DHs to represent their own + partner programs
        • Because banks rely on common partners (e.g. Qantas, Velocity, Fly Buys etc.) these can be referenced via a URN or stable cross-industry reference identifier
      • Design question 2:
        • Preference is for the client to do the filtering, rather than apply filtering via query params
        • This allows clients to query their data in different ways and reduces implementation and infrastructure burden on DHs
      • Design question 3:
        • Seen as highly advantageous to share transaction-level rewards points accrued.
        • This would present some complexity for DHs so it should be considered voluntary
        • Common problem faced by customers is that they don't know what transactions have earnt them points and how many
        • This solution would solve that issue. It would also solve the issue of representing eligibility of participating retailers allowing that to be described in more free form text
        • DH raised the question about "currency" of the data held by the bank. Banks don't reconcile rewards points on a daily basis. Typically this is batch processed each month
        • It is expected that DHs can continue to do this commensurate to existing solutions rather than in realtime
        • DSB will progress a proposed solution based on this discussion and feedback

    • Issue 292: Credit card balance plans and payment hierarchy: inadequate information within the CDS

      • Problem applies to all lending facilities, not just credit cards.
      • Agreed that the scope of the solution will address all lending facilities
      • Lending rates needs to link/relate to loan details in BankingLoanAccount
      • loan balances should be included in the BankingBalance object
      • Similar problem for loyalty account balances. The intention of the balance endpoint and balance schema is to support a variety of balance views on accounts. Agreed that the solution will represent balances via the balance endpoints
      • Another important aspect of credit cards is the number of interest free days
      • Mapping presented looked mostly correct. DSB will progress a proposed solution based on this mapping and feedback on balances

  • Register

  • Energy

Actions

  • (Issue #401) DSB to identify if a change request already exists to deal with introductory offers. If not, the community will raise one.
  • (Issue #292) DSB to propose strawman solution
  • (Issue #291) DSB to propose strawman solution

Other business

None

Next Steps

None

⚠️ **GitHub.com Fallback** ⚠️