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

• https://treasuryau.webex.com/treasuryau/j.php?MTID=m6786d3cadd2da38bd3ae2bf7cca07212
• Dial In Number: +61 2 9338 2221
• Dial In Access Code: 265 1917 2241
• Quick Dial: +61-2-9338-2221,,26519172241##

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

• 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

• Meeting Notes
• Next steps

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

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

• ANZ to create a change request to better support cursors for returning large result sets.
• StayOrGo to create CDR Register change request for a public API to expose non-sensitive Data Holder metadata to public (unauthenticated) clients

• v1.11.1 was published on October 5th 2021. This release contains minor documentation errata
• v1.12.0: Energy standards, Non-Functional Requirements
• v1.13.0: Porting of Register standards from ACCC

The following decision proposals are open for community feedback

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

All open change requests can be found here:

• Standards Maintenance Issues.
• CDR Register change requests.

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

Issue 169: CDR Register OpenID Configuration does not specify token signing algorithm support

• Changes proposed: The swagger definition for the CDR Register OpenID Configuration endpoint does not reflect the design. The request_object_signing_alg_values_supported field needs to be removed and replaced with the token_endpoint_auth_signing_alg_values_supported field.

Issue 189: RegisterDataHolderAuth schema in GetDataHolderBrands descriptions to be clarified

Changes proposed:

• RegisterDataHolderAuth
  Old Description: Provides details of authorisation endpoints for Data Holders
  New Description: Defines the mechanism used and associated endpoints for Data Holder to Data Recipient authentication

• registerUType: Unchanged

• jwksEndpoint
  Old Description: JWKS endpoint for private_key_jwt client authentication with Data Recipient
  New Description: JWKS endpoint used for authentication by the Data Holder with the Data Recipient

Issue 188: SSA definition: Deprecation of revocation_uri

• Proposed that this issue is held over to the next iteration once the Register standards have been incorporated into the Consumer Data Standards
• There is a risk that defining the deprecation schedule this maintenance iteration will be premature. The ACCC are anticipating future API work impacting SSA definitions. Rather than define the deprecation schedule in this maintenance iteration, the ACCC/DSV will combine this work with these future API changes so all impacts can be considered together.

Issue 186: Documentation improvement: JWT Signature verification requirements during the DCR flows

• Proposed to add the following text to the [Registration Request JWT signature verification] (https://cdr-register.github.io/register/#registration-request-using-jwt) section

Registration request JWTs MUST be verified against the associated JWK published by the ADR. Data Holders must extract the jwks_uri from the SSA in the request and verify the request JWT signature accordingly

Issue 407: Align data quality NFR with Privacy Safeguard 11

In line with feedback from the OAIC regarding data quality requirements in relation to Privacy Safeguard 11, it is proposed to change the Data Quality section of the standards from:

Data holders are required to take reasonable steps to ensure that CDR data, having regard to the purpose for which it is held, is accurate and up to date.

A data holder is required to be able to demonstrate that reasonable steps to maintain data quality are being undertaken.

To instead be:

Data Holders and Data Recipients are required to comply with Privacy Safeguard 11 — Quality of CDR data in accordance with s 56EN(1) of the CDR legislation. Privacy Safeguard 11 includes, but is not limited to, requirements for Data Holders and Data Recipients to take reasonable steps to ensure that CDR data is accurate, up to date and complete.

Data Holders and Data Recipients are required to be able to demonstrate that reasonable steps to maintain data quality are being undertaken.

Issue 391: Remove requirement for at least one address in physicalAddresses array

To address raised in the CDR Support article where a physical address is held but is invalid and cannot be provided in a schema compliant manner, it is proposed to remove the requirement of at least one physical address.

This proposal would change the current text:

Must contain at least one address. One and only one address may have the purpose of REGISTERED. Zero or one, and no more than one, record may have the purpose of MAIL. If zero then the REGISTERED address is to be used for mail

To be:

One and only one address may have the purpose of REGISTERED. Zero or one, and no more than one, record may have the purpose of MAIL. If zero then the REGISTERED address is to be used for mail

Implementation considerations:

• Impacts ADRs that currently rely on an address being present
• Data Holders that cannot share one or more addresses must respond with an empty array "physicalAddresses": []

Issue 402: Support for multiple additional information documents

• Requirements

  • Allow product references to include one or more (list) Terms & Conditions URIs
  • Based on consultation, other documents may also be required (e.g. travel insurance details for a credit card)
  • Based on consultation, denoting which document is the primary or secondary document for a given document type is important
  • Based on consultation, other document types may also benefit from a list vs single URI (e.g., bundleUri)

• Options

  • Option 1: Add new AdditionalTermsUri list
    This option would add a new field which supports a list of additional (secondary) terms and conditions URIs.

/***********************
 * Proposal (Option 1):  
 ***********************/

    "BankingProductV4_additionalInformationV2": {
      "type": "object",
      "properties": {
        "overviewUri": {
          "type": "string",
          "description": "General overview of the product",
          "x-cds-type": "URIString"
        },
        "termsUri": {
          "type": "string",
          "description": "The primary terms and conditions for the product",
          "x-cds-type": "URIString"
        },
        "additionalTermsUri": {
          "type": "array",
          "description": "An array of additional terms and conditions for the product, if applicable",
          "items": {
            "type": "string",
            "x-cds-type": "URIString"
          }
        },
        /* ... */
      },
      "description": "Object that contains links to additional information on specific topics"
    }

/***********************
 * Example (Option 1):  
 ***********************/

"additionalInformation": {
    "overviewUri": "string",
    "termsUri": "string",
    "eligibilityUri": "string",
    "feesAndPricingUri": "string",
    "bundleUri": "string",
    "additionalTermsUri": [
      "https://bank.com.au/terms-and-conditions/travel-insurance-terms-and-conditions.pdf",
      "https://bank.com.au/terms-and-conditions/loyalty-rewards-terms-and-conditions.pdf"
    ]
}

• Option 2: Support an array of additional information URIs.

/***********************
 * Proposal (Option 2):  
 ***********************/

    "BankingProductV4_additionalInformationV2": {
      "type": "array",
      "description": "Object that contains links to additional information on specific topics",
      "items": {
        "$ref": "#/definitions/BankingProductV4_additionalInformationV2_Uri"
      }
    },

    "BankingProductV4_additionalInformationV2_Uri": {
      "type": "object",
      "required": ["type", "uri"],
      "properties": {
        "isPrimaryUri": {
          "type": "boolean",
          "description": "Indicates whether the URI is the primary additional information document for the given type. Defaults to `true`. One one primary document URI for each document `type` is allowed.",
          "x-cds-type": "Boolean"
        },
        "type": {
          "type": "string",
          "description": "The type of additonal information document described",
          "enum": [
            "OVERVIEW", /* General overview of the product */
            "TERMS_AND_CONDITIONS", /* Terms and conditions for the product */
            "FEES_AND_RATES",
            "ELIGIBILITY",
            "BUNDLE"
          ]
        },
        "description": {
          "type": "string",
          "description": "Display text providing more information on the document"
        },
        "uri": {
          "type": "array",
          "description": "The URI describing the additional information",
          "items": {
            "type": "string",
            "x-cds-type": "URIString"
          }
        }
      }
    }

/***********************
 * Example (Option 2):  
 ***********************/

"additionalInformation": [
  {
    "isPrimaryUri": true,
    "type": "OVERVIEW",
    "uri": "https://bank.com.au/products/Travel-Credit-Card/"
  },
  {
    "additionalInfoType": "FEES_AND_RATES",
    "additionalInfoUri": "https://bank.com.au/products/Travel-Credit-Card/Fees.html"
  },
  {
    "type": "ELIGIBILITY",
    "uri": "https://bank.com.au/products/Travel-Credit-Card/Eligibility"
  },
  {
    "type": "TERMS_AND_CONDITIONS",
    "uri": "https://bank.com.au/products/Travel-Credit-Card/primary-terms-and-conditions.pdf"
  },
  {
    "type": "TERMS_AND_CONDITIONS",
    "description": "Terms and conditions for complementary travel insurance when the Platinum Advantage card is used to book flights and accommodation.",
    "isPrimaryUri": false,
    "uri": "https://bank.com.au/terms-and-conditions/travel-insurance-terms-and-conditions.pdf"
  },
  {
    "type": "TERMS_AND_CONDITIONS",
    "description": "Terms and conditions for the Platinum Advantage loyalty rewards scheme.",
    "isPrimaryUri": false,
    "uri": "https://bank.com.au/terms-and-conditions/loyalty-rewards-terms-and-conditions.pdf"
  }
}

• Implementation Considerations
  • Option 1:
    • No breaking change to ADRs.
    • No change to the endpoint versioning
    • Less future-proof or flexible
    • Only addresses additional terms and conditions. Similar pattern could be adopted for secondary overview/bundle/entitlements/fees & rates document URIs
  • Option 2:
    • Creates breaking changes for ADRs and DHs
    • Creates a v4 for PRD endpoints
    • Future-proof and extensible: if new document types are added, this is easy to extend

Issue 401: Extending the list of supported feature types

• Key issues:
  • (1) Inconsistency in industry usage of existing enumerated feature types and other types such as feeType (e.g. EARLY_TERMINATION_FEE vs EXIT_FEE)
  • (2) Many product differentiating features may be holder-specific. A structured collision-resistant subType (similar to error code URN naming conventions) may allow Data Holders to implement differentiating features. Over time, they may be standardised across the industry. Discussed whether a subType should be supported that can be specific to each DH. This would maximise competition and flexibility under a set of industry recognised and defined types
  • No ADR feedback has been provided in support of the change

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

• For discussion

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

• For discussion

• Address any other business arising from the community

Actions

• ANZ in the final stage of drafting a change request for pagination cursor support
  • May present different options for review and an ANZ recommendation

Register Issues

• Ivan summarised in-flight changes, no comments from the community

Standards Maintenance Issues

• Issue 407

  • No issues raised with the proposed re-wording

• Issue 402

  • No further feedback raised. Proposal will be posted to the change request.
  • Noted that this would create a breaking change

• Issue 391

  • No issues raised in regards to the options
  • Discussed whether a free form address format would be useful where banks can't sufficiently represent structured addresses.
  • Encouraged the community to raise this as a change request if this was considered important

• Issue 401

  • Design & Distribution Obligations have come into effect. A community member raised the question of how the CDR will address this
    • This is currently tracked in the DSB Future Plan: https://github.com/ConsumerDataStandardsAustralia/future-plan/issues/39
    • Encouraged the community to raise a change request if this should be dealt with earlier
    • Potential to deal with this issue in parallel to Issue 401
  • Overlap with Issue 292
  • Inconsistency in use of featureType and feeType as well as the reliance on OTHER as a fallback category currently imposes high degree of internal mapping work on ADRs to standardise the usage of types across all Data Holder implementations
  • Improved consistency would benefit ADRs
  • Noted that consistency is good but there will always be a need to support flexibility and competition
  • Solutions should focus on balancing both considerations
  • Having holder-specific sub types was supported in principle
  • Proposed enumerated types:
    • Noted that instalment plan as a feature type was not useful - b better off being described within the fees and rates structures
    • WBC to propose descriptions for each featureType
  • Noted that Issue 408 deals with transaction limits.
  • Additional structure in addition to what is proposed may be useful
    • Discussed Introductory Offers as a primary rate or feature where a balance offer, flashback etc are not permanent features but they are offered an incentives for a short period of time to encourage customers to take up a product
  • With Buy Now, Pay Later (BNPL) products, there in an increasing need to solve for instalment plans for lending & credit products.
  • This is a core component of BNPL products and shouldn't be buried deep in the PRD representation
  • Features should be persistent things like payment wallets, insurance etc.

• Issue 292

  • Credit Cards balance plans have their own interest rate
  • Cash advance rates don't typically have an interest free feature / rate
  • Instalment plans are an array of different rates
  • It's common for credit cards to have three or more balance plans for a loan
    • each has its own minimum repayment amount and payment date
  • hierarchy in the balance plan interest rates will help to calculate payments
    • It was noted that existing legislation already requires banks to pay off balances with the highest interest rates first
    • In this respect, having a hierarchy may not be useful other than as a representation of that or combining similar rates within a single plan
    • May require hierarchy to be ordered by / nested by highest interest rate
  • Noted that lendingRateType includes cash advance and purchase rates already but doesn't include balance transfer and instalment rate types
  • Could represent balances similar to purses in the BankingBalance structure
  • Lending rates need to reference or tie together to the balances so it is obvious what rate applies to which balance
  • This may be done via a unique reference ID
  • Balances should have a display name to represent the individual plans so ADRs can easily render them
  • Similar issue to credit cards with home loans supporting a portfolio loan structure (e.g. overall rate + separate fixed and variable rates)

• Issue 291

  • Not discussed due to insufficient time. Carried over to next call

• No other business raised

• Not applicable

• WBC to create proposed featureType descriptions for each enumerated featureType proposed in issue 401