PRD - Constraint types

[Mekaal]

Description

We have a product that has what we would consider a constraint that is not covered by any existing constraint type. The specific 'constraint' is that deposits must be 'held' for a minimum of seven days. We have in the absence of a suitable constraint type (eg OTHER) added as a feature.

Area Affected

Constraint Types for Product detail

Change Proposed

Add a constraint type of OTHER

[nils-work]

Hi @Mekaal, CDR participants

There may be different ways to describe a product where funds may not be at-call for a period of time. This scenario may be distinct from how products in the TERM_DEPOSITS category are typically defined.

The below table provides some examples as a point of discussion. Some may require smaller or larger changes to the Standards, others may already be supported.

Options for Product Detail

#	Option	Comments
1	Describe the constraint as featureType: OTHER	Currently supported and being used by participants. Generic Type would require parsing of additionalInfo field for useful interpretation. Usage of additionalValue field is not defined.
2	Provide a new featureType of FUNDS_AVAILABLE_AFTER	New enum with a more specific name/meaning. additionalValue could be defined to provide a duration value, e.g., P7D. Absence of this feature would imply funds are available with no specific 'hold' or retention period.
3	Define an OTHER constraintType	New enum would provide flexibility for this and other more generic constraints. Generic Type would require parsing of additionalInfo field for useful interpretation. Usage of additionalValue field is not defined.
4	Define MIN_TERM and MAX_TERM constraintType	Two new enums to provide general flexibility for time-based constraints. additionalValue fields could be defned to provide respective duration values, e.g., P7D, P1Y
5	Define a FUNDS_AVAILABLE_AFTER constraintType	New enum with a more specific name/meaning. additionalValue field could be defined to provide a duration value, e.g., P7D

Examples -

// Option 1 - feature
{
    "featureType": "OTHER",
    "additionalInfo": "Funds will be available after a 7 day retention period."
}

// Option 2 - feature
{
    "featureType": "FUNDS_AVAILABLE_AFTER",
    "additionalValue": "P7D",
    "additionalInfo": "Funds will be available after a 7 day retention period."
}

// Option 3 - constraint
{
    "constraintType": "OTHER",
    "additionalInfo": "Funds will be available after a 7 day retention period."
}

// Option 4 - constraint
{
    "constraintType": "MIN_TERM",
    "additionalValue": "P7D",
    "additionalInfo": "Funds will be available after a 7 day retention period."
}

// Option 5 - constraint
{
    "constraintType": "FUNDS_AVAILABLE_AFTER",
    "additionalValue": "P7D",
    "additionalInfo": "Funds will be available after a 7 day retention period."
}

Relevant links to the Standards -

• Get Product Detail
• BankingProductFeatureV2
• BankingProductConstraint

An important point to note is that the BankingProductConstraint structure is not applicable to Get Account Detail, but the status of a 'hold' would be valuable in determining whether funds are available to transfer from an instantiated account. To support this, further options are provided:

Options for Account Detail

#	Option	Comments
1	Apply detail through featureType	featureType option selected for PRD could readily be applied to accounts (though would still be a new endpoint version). additionalValue could reflect the days remaining by counting down to zero (P7D, P6D...P0D, etc.), removed completely, or isActivated set to false when not applicable.
2	Deduct a hold on funds from the availableBalance of an account	Currently supported. Doesn't provide additional detail about the reason or known duration.
3	Add constraint structure to Account Detail schema	constraintType option selected for PRD would be a larger change if introduced to the Account Detail endpoint, but could provide more detail for future requirements, potentially including issue #408. additionalValue could reflect the days remaining by counting down to zero (P7D, P6D...P0D, etc.) or removed completely when not applicable.

Examples -

// Option 1 - feature
{
    "featureType": "FUNDS_AVAILABLE_AFTER",
    "additionalValue": "P7D",
    "additionalInfo": "Funds will be available after a 7 day retention period.",
    "isActivated": true
}

// Option 2 - balance
{
    "accountId": "string",
    "currentBalance": "20000",    // Total deposited funds
    "availableBalance": "0",      // Funds not subject to a hold or retention period
    "currency": "AUD"
}

// Option 3 - constraint
{
    "constraintType": "FUNDS_AVAILABLE_AFTER",
    "additionalValue": "P7D",
    "additionalInfo": "Funds will be available after a 7 day retention period."
}

Any feedback on these possible options, or suggestions for alternatives, would be welcomed.

[perlboy]

Are funds truely held for 7 days or is there simply a penalty if they are withdrawn prior?

[nils-work]

Hi @perlboy
If changes are necessary, it may be worth considering both options to ensure flexibility, as they may have different implications as you've suggested.

[anzbankau]

Hi @Mekaal,
Further to @perlboy's question on the nature of the product, could you please describe what happens after the deposits are held for the minimum of 7 days? Does it become a traditional deposit/savings/transaction account (AKA 'demand deposit') where funds are available immediately? Further general product information or a link would be helpful. For example, how would you categorise it e.g. Cash Management Account, Investment Account?

[Mekaal]

Hi All It is this product - https://www.serviceone.com.au/BankingAndFinance/Accounts/PersonalAccounts/SavingsAccounts/MoneyManagementAccount Regards Mekaal Hassan | Business Analyst Bendigo and Adelaide Bank Limited | Level 2 The Bendigo Centre, Bendigo VIC 3550 Phone: 03 5485 6936 Please note that my days of work are Monday, Tuesday, Thursday, and Friday. From: ANZ Bank ***@***.***> Sent: Wednesday, 15 March 2023 4:37 PM To: ConsumerDataStandardsAustralia/standards-maintenance ***@***.***> Cc: Mekaal Hassan ***@***.***>; Mention ***@***.***> Subject: Re: [ConsumerDataStandardsAustralia/standards-maintenance] PRD - Constraint types (#387) CAUTION: This email originated from outside of the organisation. Do not click links or open attachments unless you recognise the sender's full email address and know the content is safe. Hi @Mekaal<https://urldefense.com/v3/__https:/github.com/Mekaal__;!!OkoFT9xN!J5D3rgE53hBHKKxpu2rp-H386AolLNjCxgafKHXc4bWGz20RuwfLoPe7YngyGOGHj-5xcGoAcgI4PR1k_MIQ-9ZacZqucttGpw$>, Further to @perlboy<https://urldefense.com/v3/__https:/github.com/perlboy__;!!OkoFT9xN!J5D3rgE53hBHKKxpu2rp-H386AolLNjCxgafKHXc4bWGz20RuwfLoPe7YngyGOGHj-5xcGoAcgI4PR1k_MIQ-9ZacZpkW91mjw$>'s question on the nature of the product, could you please describe what happens after the deposits are held for the minimum of 7 days? Does it become a traditional deposit/savings/transaction account (AKA 'demand deposit') where funds are available immediately? Further general product information or a link would be helpful. For example, how would you categorise it e.g. Cash Management Account, Investment Account? — Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https:/github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/387*issuecomment-1469371518__;Iw!!OkoFT9xN!J5D3rgE53hBHKKxpu2rp-H386AolLNjCxgafKHXc4bWGz20RuwfLoPe7YngyGOGHj-5xcGoAcgI4PR1k_MIQ-9ZacZokGaXSVA$>, or unsubscribe<https://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AL7FTO3KWDKSBGCED44ZRWTW4FIOPANCNFSM46NLSKJQ__;!!OkoFT9xN!J5D3rgE53hBHKKxpu2rp-H386AolLNjCxgafKHXc4bWGz20RuwfLoPe7YngyGOGHj-5xcGoAcgI4PR1k_MIQ-9ZacZpXFiZnpw$>. You are receiving this because you were mentioned.Message ID: ***@***.***> ******************************************************************************** This communication is intended only for use of the addressee and may contain legally privileged and confidential information. If you are not the addressee or intended recipient, you are notified that any dissemination, copying or use of any of the information is unauthorised. The legal privilege and confidentiality attached to this e-mail is not waived, lost or destroyed by reason of a mistaken delivery to you. If you have received this message in error, we would appreciate an immediate notification via e-mail to ***@***.*** or by phoning 1300 BENDIGO (1300 236 344), and ask that the e-mail be permanently deleted from your system. Bendigo and Adelaide Bank Limited ABN 11 068 049 178 ********************************************************************************

[anzbankau]

Thanks @Mekaal. Knowing it's a Money Management account and the 'funds available 7 days after being deposited' language helps.
Our preference is for Product Details Option 5 and 3 (i.e., 'OTHER' - for future flexibility) and Account Details Option 2.
Explanatory points:

1. Constraint rather than feature: Most deposit/savings/transaction accounts are 'demand deposits' i.e., funds are available on demand. Limitations on this is an accessibility constraint. It's not a feature that makes the product/account more attractive to a customer or prospective customer.
2. We agree with Stuart that it must be a limitation, not just a reason to charge a fee.
3. The standards for this requirement (enums and descriptions) should not use terms like 'hold' and 'term'. The focus should be on the availability of the funds rather than language like 'retention period'. These terms are commonly used in banking for reasons other than deposited funds not being available for a short period. 'FUNDS_AVAILABLE_AFTER' is in line with the purpose, whereas 'MIN_TERM' and 'MAX_TERM' in the context of account would normally suggest the term of the account for term deposits and term loans e.g., fixed rate loans.

[nils-work]

Thanks @perlboy, @anzbankau, @Mekaal for your valuable input.

After further discussion in the DSB, there is a view that constraints may be better considered as being relevant only to the application/origination of a product, and not used to define ongoing operational limitations.

That convention is already covered by the first part of the constraints field description (application for), but may warrant a change to remove the subsequent part (operation of) -

Constraints on the application for or operation of the product such as minimum balances or limit thresholds

As an alternative, it is suggested that the features array be used to describe not only 'attractive' features but also any limitations of the key characteristics of the product.

That may be guided by an update to the features property description -

Array of features available for the product Array of features and limitations of the product

For this change request, that approach would align to Option 2 for Product Detail (introducing a new FUNDS_AVAILABLE_AFTER featureType enum), and Option 1 (FUNDS_AVAILABLE_AFTER enum) and Option 2 (leveraging existing fields in the Balances endpoints, as supported here) for Account Detail as suggested in this comment.

If it was considered to be appropriate, the same approach may be applicable to issue #408, which is requesting a way to describe other operational limitations.

These featureTypes are already available -

• BALANCE_TRANSFERS
• FREE_TXNS
• FREE_TXNS_ALLOWANCE
• UNLIMITED_TXNS

and the proposed MAX_BALANCE, MIN_BALANCE, MAX_TXNS etc. types with corresponding additionalValue fields may fit well with those.

Does this seem like a viable approach to carry forward, or are there any other considerations?

[nils-work]

Hi @Mekaal
The DSB is proposing this issue be addressed as part of Decision Proposal 306. Any feedback would be welcome.

[anzbankau]

@nils-work,

In regards to:

After further discussion in the DSB, there is a view that constraints may be better considered as being relevant only to the application/origination of a product, and not used to define ongoing operational limitations.

Could you please provide the rationale for this view? Our preference below is not in favour of this option, but the DSB discussion doesn't appear to recognise that customer accounts are not associated with product offerings in the standards or in data holder product collateral. For example, a product offering may be generic but refined as customers make choices during the origination process, and many accounts are no longer offered as products i.e., they're 'grandfathered'.

Product options 1 and 2 and account option 1 propose including constraints/limitations into the features array. We're not sure how the quoted text relates to the proposed options, but they appear to abandon the natural language use of 'feature' and 'constraint' that has been in the standards from the first draft. James went through the product offerings on bank websites to determine the arrays in the product detail schema. While there are certainly variations on features/benefits (including wordier equivalents) and 'constraint' is too negative a term to use for marketing, the essence of the distinction remains. The language in the standards should align with this - for clarity and to promote consistency. Unfortunately the product @Mekaal provided as the basis for this change proposal appears to have been removed, but the product guide for the Adelaide Cash Managament Account (the closest match) has a product overview table with 'Feature' as the column heading. The table does not appear to have anything that reads like a limitation/constraint.

Our choices (from our earlier comment):

• Product option 5 (new constraintType=FUNDS_AVAILABLE_AFTER) - the example 'deposited funds are available after 7 days' (to restate in a less negative tone) is a funds access limitation, not a feature or benefit to the customer.
• Product option 2 (new constraintType=OTHER) - additional enumeration for flexibility (as provided in other type enumerations in the product schema).
• Account option 2 (reflect funds held in availableBalance) - to avoid a significant schema and data sourcing change. Option 3 is clearly semantically richer, but we suggest the magnitude of the change would require a separate change proposal to allow the community to contribute to the value proposition.

[nils-work]

Hi @anzbankau

A factor in the thinking was that constraints (and eligibility) are currently only available Product Detail and as such, may only logically apply to origination - as the description states:

Constraints on the application for ...

Although the description adds 'or operation of the product', the separation between the PRD and the instantiated account may make later review and comparison of ongoing limitations difficult, whereas the features array persists (if only by name) from Product Detail to Account Detail.
Note: Grandfathered (or otherwise) accounts are not expected to be directly associated with the features of equivalent on-market product details.

A product may have constraints on opening that are different to constraints after opening, such as MIN_BALANCE. These could be defined in the existing constraints field, but that can become 'detached' after instantiation and difficult to re-associate with an account in operation.

Examples of ongoing constraints, as stated above may include -

• BALANCE_TRANSFERS
• FREE_TXNS
• FREE_TXNS_ALLOWANCE
• UNLIMITED_TXNS
• MAX_BALANCE
• MIN_BALANCE
• MAX_TXNS

Although the features property name may be associated with 'benefits', that may not preclude it from providing details of limitations where no other suitably-named property with relevant enums exists. Presentation of the payload schema is a separate concern, but the array could have been considered 'Features and Limitations'.

Further suggestions are welcome, but the options for describing ongoing constraints or limitations may include:

#	Option	Comments
1	Use the existing features array to provide all details applicable to the operation of an account (beneficial or otherwise)	An existing property already defined in Product Detail and Account Detail Interpretation of the contents of the array may be unclear. More specific enums or an additional flag in the schema may help with the distinction between feature/limitation if necessary. This is what was suggested above.
2	Add the constraints property to Account Detail	Add property to Account Detail only This may still make any distinction between 'application' constraints and 'operational' (ongoing) constraints difficult in PRD where both types would be expected to be provided together. More specific enums or an additional flag in the schema may help with the distinction between application/ongoing if neessary. This may be a good alternative to above as it keeps consistent naming and meaning.
3	Add a new 'limitations' array to both Product Detail and Account Detail to convey details that are not considered application constraints or 'beneficial' features	New property in Get Product Detail and Get Account Detail Could be used to describe ongoing operational limitations only, distinct from application constraints and beneficial features.
4	Rename the existing features property to something like featuresAndLimitations to clarify a broader scope	Renamed property in Product Detail and Account Detail Interpretation of the contents may be clearer if it is to include both types. More specific enums or an additional flag in the schema may help with the distinction between feature/limitation if necessary.
5	No change to fields, continue to use constraints in PRD only	It may be unclear where there are constraints that could be interpreted as either for the 'application for', or 'operation of' the product/account. There may be no clear place to define operational limitations that may be applicable and important for account comparison after instantiation.

[anzbankau]

@nils-work,

Thanks for the explanation and the comprehensive enumeration of the options for constraints/limitations.

We accept the significant impact of schema changes on data providers and consumers. Your detailed work here should be referenced in the future, should an opportunity arise to differentiate product constraints and account limitations in the schema.

Our preferred options are :

• Product option 2 (new featureType of FUNDS_AVAILABLE_AFTER)
• Product option (new constraintType=OTHER) - for flexibility - in line with other type enumerations in the product schema
• Account option 2 (reflect funds held in availableBalance) - to avoid a significant schema change

[nils-work]

Hi @Mekaal, @anzbankau

The FUNDS_AVAILABLE_AFTER featureType and OTHER constraintType are now reflected in the Candidate Standards for Banking.

The features property description was also updated to Array of features and limitations of the product.

Consultation on making the Candidate Standards binding is now open through Decision Proposal 338.