Decision Proposal 031 - Detailed Account Payload

[JamesMBligh]

This decision proposal outlines a recommendation for the final account payload defined in decision proposal 015. This one is for account details.

Feedback is now open for this proposal. Feedback is planned to be closed on the 1st November. Decision Proposal 031 - Detailed Account Payload.pdf

Please note the specific concerns. Also note that the date is very close to the scheduled date for publishing the first version of the standard. As a result I will respond with an amended version based on feedback to date on the 26th October.

[anzbankau]

As discussed during ABA meeting on 24/10/18, ANZ propose that 'accountCategory' be changed to 'productCategory'. For consistency, the same change should be made to the 'Basic Account' [#27] and 'Detailed Account' [#31] decision proposals. Given James' explanation of the intention of 'providerType' in the same discussion, we also suggest that it be changed to 'productName' (not 'accountType' as discussed). Accounts are instances of a product so the product represents its type. Since it's the name used by the provider (i.e. consistent with other channels but not consistently applied across providers - so not an enum) it's not 'productType'. The description should state that it's the provider's product name with no reliable relationship to the productCategory.

[JamesMBligh]

Please note, we have brought the feedback date back 1 day to allow for a draft standard to be published on the 2nd of November.

-JB-

[da-banking]

specificAccount$type The defined values for specificAccount$type do not cover all of the kinds of accounts that banks have. For example a transaction account would be a low interest account with a debit card, and a savings account might offer better interest than a transaction account, but only work through Internet Banking. We don't think these other kinds of accounts would carry any specific fields, so we do not propose to introduce other enum values and subtypes. Instead we recommend that the specificAccount$type be made optional and is set to one of the defined values only when an account has the additional data for one of the defined types.

loanAccountType The offsetAccountId may refer to an account that has not been shared with the third-party at the customers discretion. In this scenario, our preference would be to omit the property as though there was no offset account, rather than generate and maintain an ID token that would invariably get a HTTP 404 response if used on the /banking/accounts/{accountId} endpoint.

address We have no direct relationship between an account and an address. Our systems are customer-centric, not account-centric, and therefore addresses can only be related to an account via a customer who could be an owner or a signatory on an account.

We are unclear on the use-case that this inclusion is supporting, and it makes the "Detailed Bank Account Data" and "Customer Data" authorisation scopes ambiguous.

We recommend removing this property from the account object, or making it optional. The customer's address should be determined via the /common/customer/detail endpoint, or the #36 OIDC userinfo discussion if it is adopted.

Fees, discounts and rates We have made specific feedback regarding fees, discounts and rates on Decision Proposal 030 - Product Payloads, and won't repeat it here, though we would expect any decision made on the Product Reference Payload that was applicable here to be applied consistently.

[JamesMBligh]

Hi @da-banking, comments on feedback.

specificAccount$type - fair enough. Probably should be optional

loanAccountType - that sounds like a reasonable treatment. I'll add a comment along these lines to the description

address - some institutions have the ability to specify addresses at account level and at customer level which is why the address data is included here. We can make the field optional to accommodate institutions that don't capture the data at the account level

Fees, etc The changes here and on product will be synchronised

-JB-

[JamesMBligh]

@anzbankau, if we change providerType to productName that implies that the string is able to used for display rather than just as an identifier ('Name' normally implies displayable text). As this is a field specifically included to aid the bank I am fine with this but wanted to clarify.

Alternatives would be to call the field productType or to have productName and productType as two fields.

-JB-

[jh-a]

@JamesMBligh given the comments on the basic payload around accountID permanence, wouldn't there be a problem in a scenario where a data consumer requests basic access to an account, then wants to subsequently request detailed access to the same account.

It is difficult to understand how a random, alpha numeric code as an identifier only understood at the API layer could become sensitive. The lack of an immutable accountID is likely to cause problems for data consumers, and the rationale provided doesn't ring true, as this would be purely a data point understood at the API layer for the identification of resources and their sub-resources.

Account ID Permance As per a previous decision proposal record IDs (including the accountId) are designed to be permanent only in the context of a specific authorisation. The intent is to ensure that a new, and potentially sensitive, reusable identifier is not inadvertently created under the CDR regime. As such, there will be no intent to link the accountId to another data delivery mechanism.

[anzbankau]

• It may be useful for the Term deposit account type to have maturity instructions (e.g. rollover principle+interest etc).
• Maturity amount should be conditional. As a bank can offer floating rate TDs.
• Credit Card Account Type - minPaymenDate – Is usually referred to as due date.
• LoanAccountType – Would original loan date and original loan amount be useful?
• LoanAccountType – minInstalment Amount – For interest only loans, is this the interest payable?
• LoanAccountType – offsetAccount – Allow for multiple offset accounts.
• Address – description implies registered address. Please change to mailing address.
• Feature type enum – propose INTEREST_BEARING.
• Fee Type enum – propose late payment fees, international transaction fees, and international ATM fees.
• DepositRate type enum – Propose additional type for when interest is accrued and assigned (e.g. assigned quarterly by credited at maturity – effectively a higher rate)
• Lending rate type enum – Propose additional types: REPAYMENT_TYPE = 'INTEREST_ONLY', 'PRINCIPAL_INTEREST'. Also need to support periods for which they apply.
• Should account have interest rate field for deposit accounts or is an additional type required.
• General comment, having a currency field with every amount field will be good. If the currency field is not populated we can then assume AUD. E.g. fees are missing a CCY.
• Having an optional file in account object to indicate base CCY of the account may be beneficial? If the currency field is not populated we can then assume AUD?

S/RC/RD (181031-2)

[MacquarieBank]

Macquarie has the following feedback on the Account Detail Payload: • Should the specificAccount$type be Conditional (only required if the account is one of these types)?

[NationalAustraliaBank]

While NAB supports the need to provide detailed account data, before finalising the payload there is a need to update it to:

• incorporate feedback from Decision Proposal 027 - Basic Account Payloads

• Aspects of the feedback provided for DP30 - Product Payloads should be consistently applied to the standard

• additional feedback as below:

Common Object Types

• Term Deposit Account Type

  • lodgementDate (which represents the most recent start date for the term of a term deposit, as it may have been cyclically re-lodged) would be more appropriate than a depositDate as described.

  • the maturityAmount should be optional as this is not available for more complex term deposits e.g. where the rate isn't fixed for the term.

  • Include an optional field for maturityInstruction with enumerations for ROLLED_OVER or PAID_OUT_AT_MATURITY

Credit Card Account Type

• rename minPaymentDate to paymentDueDate

Loan Account Type

This common object as defined is only applicable to term loans and not overdrafts/line of credit, because overdrafts and lines of credit do not have scheduled repayments.

missing fields

• repaymentType (Interest Only, Principal & Interest,...)
• repaymentFrequency

Detailed Account Data

• We do not support the inclusion of address within the payload given our explicit feedback provided on the sharing of personally identifying information.

• We support ANZ's proposal to rename providerType to productName

• We also support ANZ's proposal to rename accountCategory to productCategory and ensuring this must be used consistently across Decision Papers 27, 30 & 31.

• Feedback on representation of balance$type carries forward to this document. Please address & respond to previous feedback on Decision Proposal 27.

• the description for discounts within the fees array should reflect discounts that have actually been applied to the account, not discounts that "may be available" at product level.

• the description for the depositRates array should reflect interest rates that actually apply to the account, NOT the "Interest rates available for deposits"

• the description for the lendingRates array should reflect interest rates that actually apply to the account, NOT the "Interest rates charged against lending balances"

[WestpacOpenBanking]

Westpac has preliminary comments and questions with regard to this proposal. We are likely to provide additional feedback, including on the suitability and fairness of the proposed structure for different product types during the draft standard feedback period.

Many of our comments and questions on this proposal, including those made about the overall structure are common with those given for the product payload proposal and we won’t repeat them. Instead we provide the following additional comments and questions:

• As mentioned, there can be a relationship between an account and an address in some instances. It is generally a mailing address rather than a registered address as the description suggests. However, we are concerned about the leakage of this personal detail outside of the customer security scope and suggest that the field is removed for that reason.
  • The meaning and intent of providerType is not currently clear to us from the proposal or the comments made to date.
  • We agree with @da-banking’s comments on specificAccount$type and loanAccountType.
  • The current structure doesn’t capture many useful pieces of information for credit card holders including:
  • Payment due date
  • Payment due amount
  • Minimum payment amount
• The wording of the last part of the maxRedraw description in the loan account type might be improved by substituting with “even if the feature exists for the product”.
• Perhaps the maskedNumber field would be better served by the name maskedAccountNumber.
• We agree with @anzbankau’s comments on maturity instructions, maturity amount, LoanAccountType, Fee Type, Deposit rate and the universal inclusion of a currency field.
• As per our commentary for decision proposal 30, the key value pair approach for describing fee and features is likely to limit the future ability to accurately describe these items.

[WestpacOpenBanking]

We're including our feedback for the generic product payload proposal here because we reference it above and we were not able to post it before closure on that page.

Westpac has preliminary comments and questions with regard to this proposal. We are likely to provide additional feedback, including on the suitability and fairness of the proposed structure for different product types during the draft standard feedback period.

Payload Structure

A given product may have many different available combinations of features, fees, constraints, eligibility criteria and rates associated with it. Although elements in arrays can appear more than once, this approach risks ambiguities and there are likely to be many cases where the only way to represent these combinations in the current structure is as separate resources (“product offers”) with separate productId values.

The use of enumeration types and the additionalValue field in a key value pair fashion is unusual. Example:

{
  "data": {
    "productId": "1234",
    "lastUpdated": "2018-10-30T21:58:52+00:00",
    "accountCategory": "Term Deposit",
    "name": "Term Deposit",
    "description": "A Westpac Term Deposit lets you invest your money with the certainty of a fixed interest rate and a choice of terms.",
    "isNegotiable": "False",
    "depositRates": [
      {
        "depositRateType": "FIXED_MONTHS",
        "rate": "3%",
        "additionalValue": "24"
      }
    ]
  }
}

Use of the normal JSON syntax for representing this data instead as

{
  "data": {
    "productId": "1234",
    "lastUpdated": "2018-10-30T21:58:52+00:00",
    "accountCategory": "Term Deposit",
    "name": "Term Deposit",
    "description": "A Westpac Term Deposit lets you invest your money with the certainty of a fixed interest rate and a choice of terms.",
    "isNegotiable": "False",
    "depositRates": [
      {
        "FixedMonths": 24,
        "rate": "2.40%"
      }
    ]
  }
}

would:

• Facilitate nesting of elements as the standard is extended to more completely and accurately represent products, such as those outlined in @da-banking’s comment and in this example:

{
  "data": {
    "productId": "1234",
    "lastUpdated": "2018-10-30T21:58:52+00:00",
    "accountCategory": "Term Deposit",
    "name": "Term Deposit",
    "description": "A Westpac Term Deposit lets you invest your money with the certainty of a fixed interest rate and a choice of terms.",
    "isNegotiable": "False",
    "depositRates": [
      {
        "minFixedMonths": 24,
        "maxFixedMonths": 35,
        "rate": "2.40%",
        "calculationPeriod": "monthly",
        "criteria": [
          {
            "and": [
              {
                "minAmount": "5000",
                "maxAmount": "250000",
                "minimumAge": "18"
              }
            ]
          }
        ]
      }
    ]
  }

• Help clients ignore fields which are not understood.
• Eliminate the problem where a valid enumeration of some type depends on the context of use.
• Remove the need to have a versioning approach for the allowed enumerations.

We suggest that properly structured payloads are defined for each product as in the UK. These definitions could be simple at first and be iterated on over time. Initially these structures would be defined for term deposits, savings accounts, transaction accounts and credit cards before moving on to other product types. For the reasons outlined above this approach will be more flexible and reduce the need for frequent endpoint versions overall.

Updating of product information

• Is productId intended to be immutable? Should a product offer be updated by creating a new resource with a new productId and by setting effectiveFrom and effectiveTo as needed to depreciate the old product each time or should it be updated by changing the resource (and lastUpdated) at the time that the new pricing comes into effect? Are both permissible?
• Will the period with which products no longer offered are to be returned by API be proscribed or mentioned in the standard (noting the period of “a few weeks” mentioned in the introductory text)? Is the intent to give flexibility? How will this work if productId is intended to be immutable?
• Is a product version number required in order to limit the proliferation of productIds?

Caching, filtering and pagination

• The updated-since field complicates the use of standardized caching tools by both data providers and data consumers and should be removed in favour of use of the HTTP ETag header by data providers and the If-None-Match or If-Modified-Since HTTP headers by data consumers. The use of HTTP Cache-Control headers should also be allowed for or recommended to describe when content will become stale.
• There do not appear to be use cases which only require a subset of a filtered set of resources. For this reason the default page size should be increased or to 1000 or pagination should be removed altogether.
• If pagination is kept we suggest that responses are sorted by lastUpdated and page-size are removed as a method of achieving the reduced response total size as was intended with updated-since without negative impacts on caching.

URIs

• There is no facility to link to disclosure documents associated with a product (for example a Product Disclosure Statement, Financial Services Guide, Credit Guide or the Code of Banking Practice).
• There may be many terms and conditions documents associated with a product. For example there might be terms and conditions associated with a deposit account, the associated debit card and use online banking. The data structure should allow for both the multiple and single terms and conditions cases, perhaps through the use of array.
• A product might be associated with many bundles. We suggest an optional array of bundleURIs.
• A URI to product features might be useful.

Features

• A featureType could exist for cheque books.
• Unlimited free transactions are likely to be associated with particular channels and transaction types. They also have eligibility criteria.
• It may be possible to have additional cards with no maximum.
• The Description of featureType doesn’t align with the one given in the Detailed Account Proposal in the sense that there is no line stating that "Note this is not the same as Detailed Account”

Eligibility

• Turnover is unlikely to be the only condition used for business eligibility
• Business and individuals are not the only entity types to which eligibility criterion can apply. Charities and self-managed super funds are two other examples.
• It is feasible that a maximum age might apply to a product.
• Some products are only available for students.
• Turnover is unlikely to be the only criterion used for eligibility for business accounts.

Deposit rates

• Should the BONUS depositRateType be used to capture tiering or banding of rates and if the bonus is time limited?
• That is the reasoning for having both FIXED_DAYS and FIXED_MONTHS (and similarly with other enumeration types)? This is another example of where structured JSON is better suited to describe the situation.
• Should there be a deposit introductory rate (HONEYMOON) as for lending rates?

Lending rates

• INTRODUCTORY would align better than HONEYMOON with normally used terminology.
• Should the DISCOUNT additionalValue be “Description of the conditions when the discount applies”?
• Should the PENALTY additionalValue be “Description of the conditions when the penalty applies”? There might be penalty rates for e.g. being in default or when a facility has expired.
• How do different rates associated with credit cards (cash advance rate, balance transfer rate, smart plan rate, purchase rate, …) fit into the structure?
• Should a field for payment type (e.g. interest only, principal + interest for mortgages) be included here?

Fees and discounts

• Not all fees on all accounts are in AUD. We suggest that wherever amounts appear in the standard they have an associated optional currency field defaulting to AUD.
• We support the comment made by @da-banking with regard to the proposed structure not considering fees which are not fixed, discrete debits from a customer amount and need to accommodate other fee types.
• Should the BUNDLE discountType be used in the case where a discount applies to a different product in an applicable bundle?

Other Comments

• Westpac has a technical requirement to be able to serve public APIs from a different domains. Other data holders are likely to have similar requirements. Reasons for this include our approach to caching and DDoS protection. The UK standard allows for this. It would be appreciated if the parts of the standard addressing URI structure are adjusted in order to accommodate, perhaps by allowing data holders to specify a domain by endpoint or just separating by authenticated and unauthenticated APIs.
• Since there is no customer context to determine the brand, a brand field should be added for each product.
• Guidelines on the expected length of description and other text fields might help to increase the usefulness of these fields for data consumers.
• We note that the ACCC has placed closed accounts of former customers out of scope for July 19. On that basis we do not consider closed accounts in scope for July 19 either for former or current customers as has been suggested in the Basic Accounts endpoint proposal.

[JamesMBligh]

@jh-a I would refer you to the discussions and proposal on id permanence (https://github.com/ConsumerDataStandardsAustralia/standards/issues/9)

-JB-

[JamesMBligh]

@NationalAustraliaBank, apologies for missing the comment on balance$type in proposal 27. I assume it was this line:

If balance$type is used as the sub-type field how will the scheme ensure that banks use consistent balance structures for similar product types?

The response is that there is no need for consistency. The consistency is implied from the choice of balance type. If a deposit balance is presented it is because it is an account that is best represented as a deposit account and vice versa for a lending balance.

-JB-

[JamesMBligh]

As we are publishing tomorrow we’re being strict with feedback closure. Here are responses to feedback provided.

Please note that feedback that was also provided on product data (as their is overlap) won’t be commented on again here. Any relevant changes to product will be carried into the equivalent structures in this payload.

General Feedback

• Will add currency fields for amounts
• specificAccount$type will be made optional
• Correspondence address will remain as it is important for portability. This inclusion will be tested via the UX stream research proposal to identify any customer concerns

TDs

• Will include TD instructions with options ROLLED_OVER and PAID_OUT_AT_MATURITY
• Will make the maturity amount optional
• depositDate will be renamed lodgementDate

Credit Cards

• Will rename minPaymentDate to paymentDueDate
• Will add paymentDueAmount

Loans

• Will add an optional original load date and original loan amount
• For clarification, minInstalmentAmount is the minimum periodic payment so for interest only loans this would be the interest payable
• offsetAccount will be made an array
• repaymentType will be added with options of INTEREST_ONLY and PRINCIPAL_AND_INTEREST
• repaymentFrequency will be added. Will utilise ISO8601 as proposed by DA on the product proposal
• Disagree with the Westpac suggestion that account should be replaced with product on the maxRedraw field. The implication here is that this account has the feature but that no additional payments have been made that would allow for a redraw to occur. Would prefer not to blue account and product in this way
• Will rename maskedNumber to maskedAccountNumber

Fees

• For specific transaction type fees it would be expected to use the name and/or the additionalInfo fields to specific the specific type of transaction that would incur the fee (as there are potentially many different types
• The description for discounts indicates they may be available as some discounts and bonuses have criteria that must be achieved before they are applied so this language is still applicable

Rates

• With regards to the feedback on “assigned quarterly but credited at maturity”. Happy to add this but don’t really understand what it is or what the enum value would be
• Rates for deposit accounts would be made available in the depositRates array
• Will update the descriptions to indicate that they are applied against the account

-JB-

[JamesMBligh]

@WestpacOpenBanking, I have provided response to your comment regarding product payload on the product payload thread.

-JB-

[JamesMBligh]

The finalised decision for this topic has been endorsed. Please refer to the attached document. Decision 031 - Detailed Account Payload.pdf

-JB-