Decision Proposal 048 - Draft Standards Feedback Cycle 4

[JamesMBligh]

This issue has been opened to capture feedback on the standards as a whole. The standards site will be incrementally updated to accommodate this feedback. This is the fourth cycle of holistic feedback for the standards.

-JB-

[anzbankau]

Hi James,

A couple of small points/clarifications this week.

• ID Permanence: For a given ID is there a maximum duration of time that needs to be catered for? I.e. would there ever be an opportunity to change the ID.
  • Would this opportunity potentially occur when all of a given customer's consents with a Data Recipient have expired?
• What is the expected behaviour for balance end points of closed accounts? Would the expectation be:
  • 0 balance always returned, or
  • Resource not found error
• We propose that isOwned be removed as a filter parameter for: Get Bulk Balances, Get Transactions For Multiple Accounts, Get Bulk Direct Debits.
  • For GET accounts it may make sense as a filter parameter, but we would prefer to see it removed from the other end points as the Data Recipient would already be able to do this filtering and it is not an attribute of the end points mentioned above.
• LoanAccount.minInstalmentAmount: Are we expected to provide the scheduled amount as per the contract or the exact amount that will be due for the next instalment.
• LoanAccount.minRedraw: How current does the redraw need to be, basically prior day or intraday. Recommendation is prior day as the credits are not added to redraw until it is processed by Accounting systems.

[JamesMBligh]

Hi @anzbankau, responses below:

• For ID Permanence the ID should be permanent for the duration of the authorisation. This would include any extensions arising from re-authorisation. I would expect it to be valid, however, for ID's to be regenerated if an authorisation expires or is cancelled and then later on a new authorisation is created.

• As a closed account is provided with a valid AccountID the balance end point should provide a non-error response. A balance of zero would be appropriate since a closed account should reasonably be expected to have a balance of zero.

• Regarding removal of isOwned filter, this relates to feedback that has previously be responded to. The end points that return information on multiple accounts all support the same filter sets, even if the filtered data is not returned. This is so that the same set of filters can be used across multiple data sets without the need to resort to the POST end points and provide specific AccountIDs. For this reason the filter parameters will remain.

• Regarding LoanAccount.minInstalmentAmount, this would be up to the individual bank. If the contract amount is the minimum value that will be enforced then that amount would be appropriate. If another value is the amount the Bank would actually expect the customer to pay then that amount should be provided. The purpose of providing this information is so that a customer can use the information to make a valid decision. Provide the value that would not be misleading.

• For LoanAccount.minRedraw, the NFR regarding data currency would be applicable. Provide the value that you would provide the customer via other comparable channels.

Hope that helps, if any of the above doesn't make sense let me know.

-JB-

[jnflint]

Hi James,
I am not associated with any organisation so I hope you don't mind me reviewing the standard.
The default values for some of the parameters are of the wrong type.
As per the extract below, the default values are quoted. e.g. ParamPage and ParamPageSize are quoted strings - "default": "1" should be "default": 1 and "default": "25" should be "default": 25
isOwned default value should be "default": true i.e. without the quotes.

This trips up some strict validators.

I base the correct format from https://json-schema.org/understanding-json-schema/reference/numeric.html

 "ParamPage": {
      "name": "page",
      "in": "query",
      "description": "Page of results to request (standard pagination)",
      "required": false,
      "type": "integer",
      "default": "1"
    },
 "ParamPageSize": {
      "name": "page-size",
      "in": "query",
      "description": "Page size to request. Default is 25 (standard pagination)",
      "required": false,
      "type": "integer",
      "default": "25"
    }
"isOwned": {
       "type": "boolean",
       "description": "Flag indicating that the customer associated with the authorisation is an owner of the account.  Does not indicate sole ownership, however.  If no present then 'true' is assumed",
       "default": "true"
    }

jf

[JamesMBligh]

Thanks for picking that up @jnflint. All reviews are welcome. Feedback is judged on merit, not source of origin.

I will add these changes to the backlog of minor corrections to be made.

-JB-

[anzbankau]

James,
Just for clarification and confirmation please, the feeType = 'EXIT' enum (for 'Product Fee Types' and 'BankingAccountFee' in 'Product & Account Components' section) is for early/abnormal/unscheduled/irregular/customer-initiated termination/closure of an account (sometimes called 'break fees') as opposed to 'normal' termination/closure such as at loan maturity where security-related fees (e.g. release of mortgage) may apply.
Could the description please be amended to clarify this (in a more succinct way than stated here). (Renaming it to 'EARLY_EXIT' is probably not warranted given the common understanding of 'EXIT').
Thanks.

[JamesMBligh]

Hi @anzbankau, the EXIT type would apply to both types of fees (early exit and normal maturity). The difference can be expressed in other fields such as the name or additionalInfo. If this type were implied to be only early exit then there would be no type for normal closure.

-JB-

[JamesMBligh]

For those that may not have noticed I have now updated product reference with recommendations regarding product fees/discounts and rate tiering. I will be completing the remainder of the recommendations on product reference shortly.

I suggest that feedback for product reference be moved to this thread.

-JB-

[JamesMBligh]

For the product reference changes for fees/discounts and rate tiers I deviated from the ABA recommendation as follows as a result of converting the recommendations to swagger:

• I did not include applicationFrequency in the fees structure as this data is already accommodated via the additionalValue field
• In some cases the accrual field was referred to as accruedRate, accrualRate and calculatedRate. I standardised on accrualRate
• I renamed tieredDepositRate to tiers and made it an array as this is more aligned to the standards and also more expressive (multiple tiers for a single rate can apply)
• The prefix of 'tier' was redundant on some of the properties of tier object
• The BUNDLE_DISCOUNT type was removed as it was equivalent to the new BUNDLE_DISCOUNT_VARIABLE type
• As no types were expressed for rate conditions I removed the type and additionalValue fields. The object remains in case types are defined in future versions

-JB-

[anzbankau]

James,
Could a 'tierName' string property please be added to the TieredRateType to represent the 'dimension' or collection of like tiers. For example 'Term' tier (e.g. 1 year) and 'Balance' (e.g. $10,000 - $100,000) subtier for term deposits.
This will enable data consumers to provide 'column' and 'row' headers for presentation to users and better enable cross-comparisons - rather than trying to interpret the meaning or comparison-basis of a dimension on the tierUnitOfMeasure and other properties.
Note: We consider this just an omission in the original proposal for tiering.
Note: Since the model is flattened (to rate level) the alternative to have additional properties at the higher level of ProductDepositRate.[depositRateTierName, depositRateSubTierName] and ProductLendingRate.[lendingdepositRateTierName, lendingdepositRateSubTierName, lendingdepositRateSubSubTierName] is no less redundant and adds more properties to the specification.
Thanks.

[JamesMBligh]

A tier name and sub-tier name are good additions. I will add these in.

-JB-

[anzbankau]

James,
This probably warrants further discussion, but with BankingProductDetail.[depositRates, lendingRates] being arrays, each instance (of type [BankingProductDepositRate|BankingProductLendingRate]) should have a single rate, with the other properties representing the qualifying criteria for the rate to apply (including the intersecting tiers in a ‘multi-dimensional’ model). The new standards provides an array of tiers, allowing a set of ‘criteria’/’conditions’ (or set thereof when representing the intersection of multiple dimensional tiers) to apply to a single rate. While this may coincidentally be the case, I doubt that this was what you intended.

Option 2 in the ABA proposal used a nested structure, but it had rates within the nesting so that they were associated with all the necessary ‘criteria’. However option 1 was proposed because it ‘flattened’ the multi-dimensional model based upon the rate (much like a fact table in a dimensional model) to preserve the simple ‘array-of-rates’ structure that supports most rates.
...Rod

[JamesMBligh]

This could have been my misinterpretation of the ABA proposal. It was unclear if the tier object was intended to be plural or not. If the feedback is to change tiers from array to singleton then I’m happy to do that. Is that what you are recommending Rod?

-JB-

[JamesMBligh]

I have made the above change and also updated the product category enumeration values as per the ABA recommendations. I believe that all feedback for product reference is now incorporated into the standard.

I would appreciate a review as to whether any items were missed or if further changes were made.

-JB-

[anzbankau]

Hi James, some product related questions we have for GET /banking/accounts/{accountId}

• We imagine this is the case - but for the account detail end point, will the product information change to align to updated product definition?
• For the product features on an account - is the intention to provide back a feature if:
  • the feature is available on the account, or
  • the feature is enabled on the account
• It is understood that for product end points the best accuracy of the information possible in the data structure should be provided. However for account - if the fees or features are too complex to accurately represent in the available data structure, should it not be included in the response?

Thanks

[anzbankau]

Hi James, one more - this time on Transaction end points

• If a Data recipient requests a transaction range that includes transactions beyond what has been consented what is the expected behaviour? Should we
  • Provide back the transactions filtered to only include dates originally consented to, or
  • Provide back the transactions filtered to only include dates originally consented to with a warning, or
  • Provide back an error

Thanks

[anzbankau]

Re: Proposal for Product Reference API for Rate Tiers within Deposit and Lending Rates

The ABA proposal (and selection of option 1) was guided by not making too much of a change but since James suggested tier arrays, I incorporated them in a revision of the proposal with a TierSet type to support aspects of the structure in option 2. The following is a stripped-down, compressed format of the proposed schema and examples to make it easier to appreciate ‘tierSet’ examples (also in a vain attempt to fit it into a post). If this is acceptable a tabular specification (update to previous document) will follow.

Schema (Non-elementary types are of the form :{}.
Product:{name,rateSetType,repaymentType
,depositRates=[DepositRate:{rate,rateSetType,calculationFrequency,applicationFrequency
,[tierSet=tiersSet:{setName,name,unitOfMeasure,valueMinimum,valueMaximum} ] ] }
or ,lendingRates=[LendingRate:{rate,rateClass,repaymentType,rateSetType,calculationFrequency,applicationFrequency
,[tierSet=tierSet:{setName,name,unitOfMeasure,valueMinimum,valueMaximum} ] ] }

Enumerations
Product.repaymentType=[PRINCIPAL_INTEREST|INTEREST_ONLY]
[Product|DepositRate|LendingRate].rateSetType=[VARIABLE|FIXED]
LendingRate.rateClass=[INTEREST|COMPARISON]

Example: Transaction and Savings
{XBank Transaction,FIXED,,[{0.4%,,P1D,P1M}]} // FIXED is inherited to all depositRates (singular in these cases) – but could be re-stated
{XBank Savings,FIXED,,[{1.6%,,P1D,P1M}]}

Example: Term Deposits Note: Key tier discriminator is applicationFrequency
{XBank Term Deposit,FIXED,,[ // Interest credited:
{1.2%,,P1M,,{Term,11 < 12 Months,MONTH,11,12} // at maturity
,{1.19%,,P1M,P1M,{Term,11 < 12 Months,MONTH,11,12} // monthly
,{1.19%,,P1M,P3M,{Term,11 < 12 Months,MONTH,11,12} // quarterly
,{1.2%,,P1M,P6M,{Term,11 < 12 Months,MONTH,11,12} ] } // half-yearly

For the full post see the attached document.
Proposal Product Reference Rate Tiers.20190227.docx

[NationalAustraliaBank]

Summary

NAB welcomes the opportunity to continue to provide feedback to this cycle of the draft CDR standards.

Our response will primarily focus on the Product and Account schemas.

Product

Product - General

Product categories have not been updated throughout the whole standard. It is now in the response messages in all the get messages which still include the old product categories.

Product - Eligibility

As per feedback to #39, we recommend the inclusion of another enumerated value for eligibilityType to indicate that a product is available to an individual / natural person. This feedback has not been applied, please address as it is key to be able to differentiate between products available only to an actual person, only to a business / trust or available to both.

Product - Fees

• Fee Types - thank you for simplifying the number of types. We can work with this but suggest it may be cleaner if there was one TRANSACTION fee type (consolidating WITHDRAWAL, DEPOSIT, PAYMENT, PURCHASE into one fee type). This broader category allows for greater flexibility and removes potential confusion where Payments & Purchases are just types of electronic WITHDRAWALS.

• balanceRate / transactionRate / accruedRate - we understand what's being done here and agree this construct is necessary to cater for different ways of calculating a fee, but we suggest that rather than three specific rate type fields it's done as a feeRate field and a rateAppliedTo field with enumerations of BALANCE, TRANSACTION & INTERESTACCRUAL as this can leave room for greater future flexibility by introducing a new enumerated value rather than a completely new set of values. Note this feedback also extends to BankingProductDiscount

• Need to consider how a rule like "the greater of $2.50 or 3% of the transaction amount" would be applied with this model. That is a rule that applies to Cash Advance fees. The condition on only 1 of the 4 types makes this difficult. Would we be expected to put "min fee amount $2.50 in additional info"? This is similar to the FEE_CAP discount except it's a FEE_FLOOR. If anyone else has found a way to represent this sort of scenario with the current schema we'd like to see it.

• How would we be expected to show a complete fee waiver (as opposed to reduction / replacement fee). For example monthly loan service fee waived if attached to a specific product bundle?

• We also have a question about how to apply a % discount to a fee (e.g. Pensioners have a 50% reduction to a branch transaction fee). This scenario doesn't seem to be catered for in the current message. Addressing it could also resolve question on full waiver where fee is reduced by 100%.

• discountEligibilityType should also include BusinessCustomer and PersonCustomer similar to our Product Eligibility feedback

Product - Rates

depositRateType

• A type of FLOATING should be included - A Floating rate is where a fixed rate is applied for a period different to a Fixed Lodgement term (e.g. funds lodged on deposit for 12 months, but the rate is repriced every 3 months linked to the 3 month BBSW rate)
• A type of MARKET_LINKED should also be included to reflect deposit rates pegged to a market indicator such as CPI.
• We believe INTRODUCTORY should be removed as a type and should be flagged separately, possibly in additionalInfo or with a separate indicator? The current approach seems to assume that an Introductory rate is always Variable. We believe the inclusion of this has blurred the line between the Type of rate (variable) and the Conditions in which the rate will apply (an Introductory variable rate that is applicable for the first 12 months only).

lendingRateType

We question again the levelling of some of the rate types. The following bullets are our observations of where Conditions of a rate have blurred with lendingRateType:

• CASH_ADVANCE - if this is included we would also need to include the PURCHASE condition. These are the two conditions when VARIABLE interest is charged for a credit card, remembering that Credit Card interest is calculations operate differently from a standard overdraft or loan.
• INTRODUCTORY, DISCOUNT, BUNDLE_DISCOUNT_FIXED & BUNDLE_DISCOUNT_VARIABLE rates (as per depositRateType are not rate types, they are conditions that could vary a rate and should be covered as (for example) a different VARIABLE rateType with clear conditions information in the additionalInfo / additionalValue fields showing this is a rate that applies under INTRODUCTORY, DISCOUNT, BUNDLE_DISCOUNT_FIXED & BUNDLE_DISCOUNT_VARIABLE conditions & spells those out.
• PENALTY is also a condition and should be a different VARIABLE / FIXED row containing penalty conditions in the additionalInfo / additionalValue fields.
• COMPARISON_FIXED & COMPARISON_VARIABLE are different again, they are not a condition so much as a comparison that applies to a specific published rate - we believe it would be cleaner to include additional fields in the rate group for Comparison (ie: add a field called comparisonRate) rather than have as a separate type. Applying this change would enable less data duplication as the way this schema is currently structured means every rate that could have a comparison rate would need to be duplicated - one row for actual rate & one for comparison rate, and that comparison websites (and other consumers) would need a way of matching the 'actual' rate to the related 'comparison' rate. We suggest this can be simplified by introducing one optional field called comparisonRate included in the BankingProductLendingRate schema.

Can we please change the paymentStructureType field to interestPaymentDue (or something similar) as IN_ADVANCE and IN_ARREARS refers to when interest is paid and is not about the payment structure

BankingProductRateTier

We need to do some more worked examples to prove whether tier & subTier are sufficient, but the initial feel is it not quite flexible enough. This may be better represented as an array allowing more than two levels (to show $100k-$500K, 1yr Fixed, LVR 60% - 80%, IO-Advance, Investment Purpose appears to need three tiering groups but our read of the proposal only allows for two so LVR would need to be captured in additional info. This problem won't present itself fully until we have Home Lending products in scope so may be held over if this can be looked at yet. Another option may be to change subTier into an array.

Account

Account Balance Data Field

v0.2.0 of the CDR standard has removed balances from account list endpoint, but balances have not yet appeared in the account details endpoint as previously advised. Is this an oversight?

Account - General

• BankingLoanAccount - the detail for repaymentType & loanPurpose appear to have become reversed. Please ensure this is corrected and that the enumerated values for loanPurpose are renamed as the are the enumerated values for repaymentType.
• BankingAccountFee - we suggest consolidation the enumerated values of WITHDRAWAL, DEPOSIT, PURCHASE & PAYMENT for feeType to one TRANSACTION fee type (as outlined in our Product Schema feedback)
• BankingAccountDiscount - please apply the changes requested in the Product Fee schema here also to reflect the ability to waive 100% or a smaller % of a fee
• BankingAccountDiscountEligibility - please apply changes to discountEligibilityType enumerated values as outlined in the related Product Schema (e.g. PERSON, BUSINESS)
• BankingAccountDepositRate & BankingAccountLendingRate - we note that the rate tier rules have not yet been applied to these Account schemas and hope this is just a housekeeping issue. Rate tiers can be applicable at the account level for some accounts where the interest rate varies based on the daily balance meaning more than one current rate applies at any point in time. The structure presented here does not allow for rate tiers, as this is necessary to appropriately show account level interest rates. Can you please add this in as per our Product Rate schema feedback?
• BankingAccountDepositRate & BankingAccountLendingRate - please apply the same logic to enumerated values here re. depositRateTypes & lendingRateTypes. These enumerations should match the Product enumerations for deposit & lending rates but do not. Please update these to align. When applying this change, please also consider our feedback on the difference between Rate Types and Rate Conditions.
• BankingAccountLendingRate - please change the paymentStructureType field to interestPaymentDue (or something similar) as IN_ADVANCE and IN_ARREARS refers to when interest is paid and is not about the payment structure (please ensure this change is aligned to feedback we provided for the equivalent Product Schema)
• We note that the introduction of the BankingBalance schema has not incorporated our proposed changes to simplify the balances. This proposal to have a single balance schema & single Limit schema was detailed in Decision Proposal 39 - Draft Standards #39 and in Decision Proposal 044 - Draft Standards Feedback Cycle 3 #44 in the sections titled "balance$type and associated structures" and has not yet been either addressed or responded to. Can you please reconsider this feedback to have one balance item and a separate lendingLimit item (where both can be arrays allowing multi currency) and respond as to why this simpler approach to communicating a balance and a limit has not been adopted?
• BankingLendingBalance - If the above feedback re simplification of bankingBalance is not adopted, please make accountBalance & availableBalance optional as some types of business lending do not have associated balances (e.g. Bank Guarantees)
• BankingTermDepositAccount - (minor) We suggest changing the enumeration from ROLLED_OVER to ROLL_OVER and PAID_OUT_AT_MATURITY to PAY_OUT_AT_MATURITY to more clearly show future tense.

Account and Product

We suggest the CARD_ACCESS Product Feature Type be modified to allow use of the additionalValue field (currently NA) to allow text to list the names of the different cards it may be able to be linked to (e.g. to allow a narrative like "Account may be linked NAB Visa Debit card, NAB Platinum Visa Debit card, or any eligible NAB Credit Card")

Schedule Payment Endpoint(s) Definition

We look forward to providing feedback on the proposed schedule payment related endpoint(s), when they are released. Will this be captured in a separate Decision Proposal / GitHub issue?

Administration Endpoint(s) Definition

We look forward to providing feedback on the proposed administration related endpoint(s), when they are released. Will this be captured in #18 ?

[anzbankau]

Hi James,

For the transaction filters, we understand there is the following pending update:

Get Transactions end-time description will be amended to say “minus” 90 days. Based on feedback from commbankoss the 100 days will be changed to 90 days to approximately match 3 months.

However based on this the current description of end-time being 'effective time at or before this date/time' would also need to be updated to say 'effective time at or after this date/time'. Or the default conditions could be switched so that start-time is earlier than end-time.

Thanks.

[MacquarieBank]

Decision Proposal 048 - Draft Standards Feedback Cycle 4

In the Product Detail API, we would like to see the addition of the following enumerated values to the BankingProductFeature.featureType field:

1.   DISCOUNTS - a feature type that can describe what types of discounts are available to consumers, such as discount gift cards, discount travel, etc …
   

2.   BONUS_REWARDS - a feature type that is used to show how many bonus reward points are given for switching to a product. This is primarily for credit cards. This is analogous to an introductory interest rate, which we note has been included as a rate type in the API. We can foresee that this would be useful in comparing credit cards.
   

3.   BALANCE_NOTIFICATIONS - ability for near real-time notifications to be sent to a consumer when their balances changes (e.g. payment, interest, etc …). This is a highly valued feature, and we could see this as a differentiator when comparing deposit products.
   

4.   OTHER - a generic feature type that can be used to describe all other features of a product.  We feel this is really important, as it is the additional features that can differentiate a product, and help customers understand pricing differences when comparing products. We also note that the UK spec includes OTHER as a featureType.
   

[anzbankau]

James,
If you could please align the Product Category enum lists in their various forms in Product and Account including parameters e.g. Get Accounts product-category (it still has PERS_AT_CALL_DEPOSITS etc.).
Thanks

[JamesMBligh]

Hi All, some response to the minor queries since the last response:

Syncing Account Payload
Yes the structures in the account end points including features, rates etc will be synced with the Product Reference changes. Some of this has occurred but it isn't yet complete

Active vs Available
On the topic of activated vs available features being included in the Account payloads: I will add an optional boolean flag labelled isAvailable. If this flag is absent or false it will be assumed the feature is activated. If it is true it will be assumed the feature is available but not yet activated.

Account Data Accuracy
Responding to the comment below:

It is understood that for product end points the best accuracy of the information possible in the data structure should be provided. However for account - if the fees or features are too complex to accurately represent in the available data structure, should it not be included in the response?
For both Account and Product data it is up to the holder how comprehensively they represent the data they hold so that they are in conformance with regulator requirements (including ACCC rules but also other, industry specific, regulators). The standards do not make a specific statement on this topic outside of the definitions of optionality and the NFRs related to data latency and extent.

Consent To Transaction Extent
The question regarding how to deal with transactions periods requested outside of consent is interesting. There is no inclusion in the regime at the moment for data based consent for data extent. Data based consent is only included for the duration of authorisation. Data extent in response to queries is not limited by consent but by the data extent NFRs. In light of this, a request that queries for data outside of the NFR period (e.g. prior to 1/1/2017 or more than 24 months in the past for open accounts) should be covered by the existing rules around empty result sets. An error should not be returned but an empty, or truncated, result set should.

Clarification Over Previous Feedback
Yes I will changing the default 100 days rule to 90 days as per previous requests.

-JB-

[JamesMBligh]

Response to additional Product Reference feedback is below.

Before providing the feedback, however, I would note that this will likely conclude the feedback taken on Product Reference. The feedback is beginning to become circular with requests for changes followed by requests to reverse those changes. We are also starting to get to the point of diminished returns. After this round of feedback I intend to produce a final decision document setting in place v1 of the schema.

Natural Person Eligibility
Another enumerated value for eligibilityType to indicate that a product is available to an individual / natural person will be added.

Fee Types
Requests for further simplification of transaction types is counter to previous feedback, I think we have a good compromise currently. Instead of removing I will add a TRANSACTION type that would aggregate the four more specific types.

Rates As Enum
I considered this but decided to use specific fields as additional enum values are usually more of a breaking change than additional fields. Also the later feedback on comparisonRate supports this. There are times when some of the rates may occur simultaneously. If new rate types end up being frequently added I am happy to revisit this in the future.

Fee Floor
I would suggest that "the greater of $2.50 or 3% of the transaction amount” would be accommodated in additionalInfo with the preferred fee type represented.

Discount To Fee
I will add a feeRate to discount which would cover the discount being a percentage of the actual fee.

discountEligibilityType
I will update discountEligibilityType to include BusinessCustomer and PersonCustomer similar to our Product Eligibility

Discount Rate Types
Disagree on the removal of INTRODUCTORY. Will add MARKET_LINKED and FLOATING to match lending rates

Lending Rate Types
I will add PURCHASE as a type

Agree that INTRODUCTORY, DISCOUNT, BUNDLE_DISCOUNT_FIXED are variations that could be captured in additionalInfo but these are variations that would be useful to have in structured form based on previous feedback so I will not remove them

Will include comparisonRate and remove COMPARISON_FIXED and COMPARISON_VARIABLE

Will change the paymentStructureType field to interestPaymentDue

Will make tier an array again as this would appear to make this more expressive and address the areas of concern. Where the additional expressiveness is not required an array with a single element would be fine

Feature Types
CARD_ACCESS Product Feature Type will be modified to allow use of the additionalValue field (currently NA) to allow text to list the names of the different cards it may be able to be linked

I will add a dicount feature type for things such as discount gift cards, discount travel, etc. This will be called COMPLEMENTARY_PRODUCT_DISCOUNTS to avoid confusion with fee discounts

BONUS_REWARDS will be added show how many bonus reward points are given for switching to a product

A NOTIFICATIONS feature will be added to describe enhanced notifications capability. The more generic name (rather than the suggested BALANCE_NOTIFICATIONS) will allow coverage of notifications for wider range of events

An OTHER feature type will be added

-JB-

[JamesMBligh]

Regarding the remaining feedback on Accounts:

Balances
In response to the comment

CDR standard has removed balances from account list endpoint, but balances have not yet appeared
in the account details endpoint as previously advised. Is this an oversight?

There is a fine line between “oversight” and “haven’t got to it yet” but it is appreciated that this has been raised.

repaymentType & loanPurpose
Regarding the comment that repaymentType & loanPurpose appear to have become reversed, this will be fixed once investigated.

Rate Tiers
Rate tiers will not be added to the account structure as the expectation is that rates have been applied at the time of account origination

Simplified Balance
The feedback on simplified balance structure has not been rejected. It is under consideration

Minor Changes
For TDs the enumeration will be modified to ROLL_OVER and PAY_OUT_AT_MATURITY to more clearly show future tense

-JB-

[JamesMBligh]

I will be closing out this feedback thread tomorrow (Friday 7th) and opening a new thread.

-JB-

[anzbankau]

James,
Common Field Type: MaskedAccountString
Just a minor suggestion that was raised by @BrianParkerAu in 39 here but may still be in your work queue. Could the description for BankingAccount.maskedNumber simply state: 'A masked version of the account i.e. BSB/Account Number, Credit Card PAN or another number'. The additional text 'this should be formatted with each digit masked and the last three digits unmasked' duplicates and conflicts with the type definition of MaskedAccountString, which states last 4 characters are unmasked.
Thanks.

[AmexAUopenbanking]

Decision Proposal 048 - Draft Standards Feedback Cycle 4

Regarding the Product API, we agree with previous feedback on the need for the enumerated value of ‘Other’ as the current list does not currently describe the vast number of features that can be associated with different Credit Cards. Such benefits are important for the comparison of products that will best suit a customer’s needs. Ideally further consideration could be given to ways to describe key feature attributes instead of having to rely heavily on the additionalValue field (free format string). For example consider optional and common fields like - Feature Name, Loyalty Points Earn Rate, Eligibility, Value, Frequency etc.

[WestpacOpenBanking]

Account Addresses

Previously, we have communicated our concern about the leakage of account addresses outside of the customer security scope and recommended that the BankingAccountDetail.address field is removed.

An account may have more than one address associated with it. These may not be explicitly marked for correspondence, and we don’t always store a shared address. These addresses may be those of third parties who haven’t consented to have their data shared. We may not always be aware that an address is an address of a third party. Aside from the privacy issues, an outcome where sensitive information or perhaps a new credit card is accidentally mailed to third parties by data consumers is undesirable. For these reasons, we re-iterate our concerns and would appreciate guidance on the handling of the scenarios mentioned if the field is to remain.

This concern has also been recently been reinforced by the (research) flow prototypes published by Data61 in the CX Report. These prototypes did not present this detail prominently. Additionally, it was indicated that the tested permission language “Account mail address” was not easily understood by research participants.

URI Structure

We have also posted following feedback to the security working group issue register.

The draft technical standard specifies a <provider path> for resource endpoints. We suggest that explicit requirements are also published for the endpoints in the security standard. We request that the following assumptions are accommodated:

• Endpoints identified as part of the security standard can have a different <provider path> to resource endpoints.
• Endpoints which use non-mutually authenticated TLS be allowed different <provider path> to endpoints which must use TLS-MA.

Issues related to currency

• In most places in the standard, amount fields are associated with currency fields. There are a few exceptions where it might be desirable to address the inconsistency:
  • In BankingProductDepositRate, there is no way to indicate the currency when the unitOfMeasure is CURRENCY. Perhaps the description should be updated to state that the currency is the currency of the balance, and the AUD equivalent of the sum of all balances of a purses style account.
  • BankingDirectDebit doesn’t have a currency for lastDebitAmount. Perhaps the description should be updated to state that the amount is assumed to be AUD.
  • BankingAccountFee and BankingAccountDetail both assume AUD. It might be better to allow for the currency to be specified.
• The fields balanceRate, transactionRate, accuredRate in BankingProductFee have “Assumed to be in AUD.” – perhaps this phrase should be omitted in the context of a rate.
• The behaviour of min-amount and max-amount query parameters isn’t well defined when an account has transactions in multiple currencies.

Questions and comments related to the representation of product data

We have the following queries and comments in relation to the representation of products:

• There isn’t currently a way to represent eligibility criterion or activation fees associated with product features. We suggest adding an additionalInfo and an additionalInfoURI field to BankingProductFeature to allow this. Examples:
  • An additional card holder needing to be over the age of 16 (vs the primary card holder needing to be over the age of 18).
  • A fee for activating a rewards program
• There is still a lendingRateType of DISCOUNT. Is this still needed?
• It is generally not explicit that rates are per annum. We suggest that the description of RateString is updated to note this.
• Descriptions are still generally missing from enumerated values in the standard, including for featureType, feeType and so on. When these are incorporated we suggest modifying the description of the discountType PAYMENTS .
• Perhaps an INTRODUCTORY discount type could be added to the discountEligibilityType enumerated values.

Other feedback and questions

We also have some minor feedback and questions. Many of these points are related to the product endpoints:

• The description of repaymentType in BankingLoanAccount appears to be incorrect. Suggest that it should be “Options in place for repayments. If absent defaults to PRINCIPAL_AND_INTEREST” with enumerated values INTEREST_ONLY and PRINCIPAL_AND_INTEREST.
• The description of loanPurpose in BankingLoanAccount appears to be incorrect. Suggest that it should be “The reason for taking out the loan. The purpose generally affects the rate offered due to different risk profiles”.
• OVERDRAFTS and BUSINESS LOANS have gone missing from the Product Categories list for the product and account detail endpoints.
• The description of acn in BankingAuthorisedEntity is incorrect (duplicate of the ABN description). Suggest that this was supposed to be “Australian Company Number for the organisation. Required only if an ACN is applicable for the organisation type”.
• The description of payeeAccountUType in BankingDomesticPayee is missing a card type. Suggest that the description should be “Type of account object included. Valid values are: - account A standard Australian account defined by BSB/Account Number - card A credit or charge card to pay to (note that PANs are masked) - payId A PayID recognised by NPP”.
• The description of amount in CommonCurrencyAmount has a description specific to one balance type. In particular, the following descriptions have effectively gone missing:
  • accountBalance.amount – Object representing the balance for the loan, line of credit or credit card.
  • availibleBalance.amount – Object representing the current balance for the account. Assumed to be positive or zero.
  • creditLimit.amount – The maximum amount of credit that is available for this account. Assumed to be positive or zero.
  • amortisedLimit.amount – The available limit amortised according to payment schedule.
• BankingPayeeDetail.nickname and BankingPayeeDetail.domestic.account.accountName appear to have duplicate meanings – we don’t typically have an account name except as provided by the customer.
• lendingRateType has enumerated values BUNDLE_DISCOUNT_FIXED and BUNDLE_DISCOUNT_VARIABLE in the context of BankingProductLendingRate.

[anzbankau]

James,
Re: Mandatory/Optional Fields
This may just be in your catch-up list, but we weren’t sure if your great post here summarising the Data61 position has been reflected in the standards here. If you could please confirm. For example, the last bullet point covers the expectation derived from the CDR that it’s the customer’s data so that if it has been recorded by the provider it should be present in the payload. The current standard only seems to cover schema compliance.

You must be sick of this topic, but the following suggested additions don’t go over old ground (as far as we can tell), but would provide consistency to assist payload consumers:

• Leave an Optional field out rather than provide a field with a null value. (If not made a standard, perhaps it should be discouraged.)
• Leave an array field out if there are no elements. (Somewhat following the principle of the previous point.) For example, it would appear odd to have no customer firstName but have a middleName field present – then have to find out there were no elements in the middleName array anyway.

The last item would require Mandatory fields with arrays that state the array may be empty to be made Optional so that it better reflects the intent at the schema level (where it is obvious) rather than embedding the optionality rule in the description. I'm sure we're all scanning the Required column (or filtering a spreadsheet using it) only to get tripped up by Mandatory fields that, on further investigation, are just arrays that can be empty. And there's nothing special about an array to require it for schema compliance when it is logically optional.

[JamesMBligh]

I left this thread open a little longer by request for a few final comments to be submitted. I have now locked the thread and will respond to the final comments above. Following that I will open Feedback Cycle 5.

-JB-

[JamesMBligh]

@anzbankau. Synchronisation of the descriptions of the masked types is in my backlog. As per the feedback to issue #39 I will be making both of the types to describe the showing of 4 digits.

-JB-

[JamesMBligh]

@AmexAUopenbanking. There has been significant discussion around the granularity of feature types and feedback from the community has been conflicting with some participants arguing for low resolution categories and some arguing for high resolution, specific, types. The current position (which, of course, can be modified at a later date via the versioning strategy) is a compromise level of granularity with the expectation that OTHER and additionalInfo would be used to provide greater detail.

This will be the position for v1 of Product Reference.

-JB-

[JamesMBligh]

@anzbankau. Regarding optionality, I will take your suggestion that the representation of optionality in the standards isn’t complete and will extend it based on previously stated positions in GitHub.

-JB-

[JamesMBligh]

Feedback in response to @WestpacOpenBanking.

Some of this is a reiteration of product reference feedback already supplied so I will attempt to maintain consistency in response.

Account Addresses
The concerns raised have been raised before. Note that the concerns regarding addresses that may belong to another entity is covered by the rules, flagged by ACCC, for the management of joint accounts. It is anticipated that these rules will provide a foundation that will address these concerns as it will address consent for sharing of data where ownership is potentially shared. The current payloads will remain in place as has previously been stated.

In regard to CX language findings, it is definitely the case that the difference between an Account level address and Customer level address has been something that needs to be dealt with in the language presented during consent. The CX stream are seeking feedback on this, and other topics, via Medium.

URI Structure
Accommodation for different base paths has been raised previously. This will be addressed in the Discoverability proposal that is pending. It is agreed that different base paths for different purposes would be advantageous.

Currency
The suggestions regarding currency will be reviewed. It is the goal of the standards to be consistent so we will review with that lens in mind.

Product Reference
Responses to feedback regarding Product Reference.

• additionalInfo and additionalUri will be added to the feature structure
• DISCOUNT type is still valid for lendingRateType. It is intended to indicate a discount rate available under certain circumstances. If data holders don’t find it useful they are free not to use it.
• The current desciption of RateString makes no statement about meaning (per annum or otherwise). This can only be inferred via the specific properties that use the type. Not sure of the meaning of the requested change here.
• Enumeration descriptions for product reference have now been reviewed to cover recent changes. I think they are up to date now.
• INTRODUCTORY type has been added to the ‘discountEligibilityType’

Other Feedback
Will review the Other Feedback suggestions and will include results directly in the standards documentation. If anything is misunderstood or missed a query will be raised in feedback cycle 5.

-JB-