Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider additional featureType enumerated values #401

Closed
WestpacOpenBanking opened this issue Aug 26, 2021 · 4 comments
Closed

Consider additional featureType enumerated values #401

WestpacOpenBanking opened this issue Aug 26, 2021 · 4 comments

Comments

@WestpacOpenBanking
Copy link

Description

There are product features commonly listed by data holders under the enumerated value of OTHER. We suggest adding additional enumerated values as this will help to make the data between data holders more consistent. We recommend that this issue only be prioritised if there is data recipient demand. Example additional enumerated values that may be considered include:

  • CASHBACK_OFFER
  • RELATIONSHIP_MANAGEMENT
  • INSTALMENT_PLAN – an ability to pay back purchases in instalments.
  • FRAUD_PROTECTION
  • EXTRA_REPAYMENTS
  • GUARANTOR

Area Affected

Change Proposed

Add additional enumerated values based on common use of the OTHER feature type, expected scope of features to be included in responses and desirability for data recipients.

@CDR-API-Stream
Copy link
Collaborator

This issue was discussed in the Maintenance Iteration call.

The following considerations were discussed:

  • Design & Distribution Obligations: Obligations have come into effect. This was discussed as an additional consideration and enhancement.

  • Overlap with Issue Credit card balance plans and payment hierarchy: inadequate information within the CDS #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
    • Having holder-specific sub types was supported in principle
  • Regarding the @WestpacOpenBanking proposed enumerated types:

    • Noted that instalment plan as a feature type was not useful - this would be better off being described within the fees and rates structures
    • @WestpacOpenBanking to propose descriptions for each featureType
  • 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.

@WestpacOpenBanking
Copy link
Author

Westpac suggests the following descriptions for the proposed enumerated values:

Value Description Use of additionalValue Field
CASHBACK_OFFER Subject to terms, conditions and eligibility criterion, a customer may receive a cashback offer for opening an account or by spending at a certain retailer. The amount of the cashback offer (in AUD)
RELATIONSHIP_MANAGEMENT Relationship management is available for eligible customers. NA
INSTALMENT_PLAN The product has the option to pay for eligible purchases over time with a set number of payments. NA
FRAUD_PROTECTION The product includes fraud protection features. NA
GUARANTOR Subject to terms and conditions, the customer may be able to nominate a guarantor during the origination process. NA

We suggest that DSB and the community consider whether RELATIONSHIP_MANAGEMENT makes sense to include as a feature – RELATIONSHIP_MANAGEMENT is usually advertised as a separate service.

@CDR-API-Stream
Copy link
Collaborator

These changes have been staged for review: ConsumerDataStandardsAustralia/standards-staging@release/1.15.0...maintenance/401

@CDR-API-Stream
Copy link
Collaborator

CDR-API-Stream commented Dec 23, 2021

This change was incorporated into release v1.15.0. Refer to Decision 212 for further details.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

No branches or pull requests

2 participants