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

Decision Proposal 39 - Draft Standards #39

Closed
JamesMBligh opened this Issue Nov 1, 2018 · 67 comments

Comments

Projects
None yet
@JamesMBligh
Copy link
Contributor

JamesMBligh commented Nov 1, 2018

This thread is for feedback on the full 2 November working draft. Overarching feedback on the draft can be made here, and complete responses to the draft in .doc format can also be uploaded.

Updated 11 November 2018
Thanks to everyone who is already adding feedback to this thread. With organisations having three weeks to respond to the working draft in full, we're going to hold off on deeply engaging with this thread until after the 23rd November. We are watching and monitoring and absorbing feedback, so please do keep it coming.
Cheers,
Ellen

@JamesMBligh JamesMBligh self-assigned this Nov 1, 2018

@JamesMBligh JamesMBligh changed the title Decision Proposal 37 - Draft Standards Decision Proposal 39 - Draft Standards Nov 1, 2018

@perlboy

This comment has been minimized.

Copy link
Contributor

perlboy commented Nov 2, 2018

Could you please publish the source swagger.json used to generate the docs? The github has the result doc but not the definition itself? At the moment we are "estimating" the swagger definition so it would be good to get the direct one as soon as possible, even if it is in draft.

In lieu of an official swagger.json we have published an approximated OpenAPI 3.0.x compatible version within our CDR Sandbox project: https://github.com/bizaio/cdr-sandbox/blob/develop/support/swagger.json

We have verified compilation using the online Swagger editor (https://editor.swagger.io) although we admit we could clean up some general ordering. Once things are locked down we will do further cleanup.

We will review changes following this thread and synchronise as quickly as possible as we work towards a development sandbox in support of the emerging CDR standard.

@speedyps

This comment has been minimized.

Copy link

speedyps commented Nov 5, 2018

Just a question on the Transaction responses as provided in the specification.

In existing data delivery in Australia (via files), and in the UK Banking Spec, the transaction type is supplied with every transaction. This is a key field of a transaction, and the draft seems to have excluded this field.

In the UK, the Transaction response must include either:

  • the BankTransactionCode - which is the appropriate ISO 20022 code,
  • or the ProprietaryBankTransactionCode - which is what the bank uses to represent the data internally - often the BAI2 code.

This seems to have missed the requirement stated in 5.3.2 - Transaction Data in the ACCC CDR Rules Framework

  • "any identifier or categorisation of the transaction by the data holder (that is, debit, credit, fee, interest, etc.)."
@BrianParkerAu

This comment has been minimized.

Copy link

BrianParkerAu commented Nov 6, 2018

I have called out the same issue

@BrianParkerAu

This comment has been minimized.

Copy link

BrianParkerAu commented Nov 6, 2018

By way of an intro to everyone, 86400 is a new entrant to the banking market and currently applying for an ADI license. We are supporters of Open Banking and its possible use cases to enhance customer experiences.

The APIs that have been discussed in this open forum, and visible on the portal seem to be a very small subset of the APIs available in the UK model.

The information returned in a Transaction query is lacking key elements that would create consumer value; Specifically the BankTransactionCode and MerchantDetails elements. As the specification is currently defined, the consumer of the data will need to parse the content to be able to categorise the transactions, and the quality is likely to be less than if the information was provided. Parsing the contents of the description is problematic as the format lacks any industry recognised structure. I would also advocate adding a BillerDetails element to structure BPAY payments - ie include the biller code, name and CRN.

I also note the lack of support for Standing Orders. I had expected this to be front of mind as from a consumer perspective they need visibility to payments they have scheduled. The UK model appears quite robust in this regard... OBReadStandingOrder1. From a customer perspective who is looking to transfer their banking relationship to an new FI having the ability to access this information would make the process easier, and less error prone.

Also missing is the concept of an Address Book. This is implemented in the UK model as OBReadBeneficiary. From a customer perspective having the ability to port their address book to a new provider creates a better experience.

The masking applied to accounts and PANs is inconsistent with industry standards. The last 4 digits should be displayed in the clear - not 3 as currently defined.

As others have noted the Extended Transaction data for NPP is incomplete. NPP transactions can be delivered as "Single Credit Transfers" (SCT) that have no defined service levels, or as an Overlay service that defines service levels (eg OSKO payments). The Services enumeration currently doesn't address this.

Also missing from the NPP definition is "non-financial" transactions. These could include "request to pay" type messages that are to be delivered to a payer. They then have the ability to respond and send the funds to the Payee using the contents of the message.

Transactions currently have defined states - PENDING or POSTED. Pending transactions normally relate to card based authorisations that are awaiting settlement. When settled the amounts may not match the values stored on the PENDING transaction and may carry FX rates and fees. These don't seem to be captured anywhere in the spec.

Also missing is a discussion on when PENDING transactions expire. Typically this is within 3-5 business days of the authorisation request but varies by institution. This suggests that all calls to retrieve transactions will need to select at least 3-5 days of transactions.... unless all current PENDING transactions are returned if the selection end-date is the current date. Currently the input parameters only allow selection of transactions POSTED between the selected dates.

@speedyps

This comment has been minimized.

Copy link

speedyps commented Nov 6, 2018

One other question relating to transactions.

Unlike how the Direct Debits or Balances schemas are working, where the same response is used for the Bulk call and the specific Account call, for transactions, the Bulk call and the specific account calls are using different responses - I'm excluding the Detailed call from this.

All include accountId,

But Get Transactions For Account has displayName and nickName, and doesn't flag if additional detail is available (isDetailAvailable).

Get Bulk Transactions however, doesn't have displayName and nickName, but has the isDetailAvailable flag.

Ideally, shouldn't these two calls just return the same information? I think they should both have the isDetailAvailable flag at the very least.

I personally wouldn't have the account displayName and nickName in a transaction call.

@davidthornton

This comment has been minimized.

Copy link

davidthornton commented Nov 6, 2018

The single biggest issue facing this spec is the proper handling of pending and posted transactions, as they specifically relate to scheme authorisations.

The ability to connect each pending transaction to a posted journal entry once the transaction has settled is crucial to the delivery of value to consumers. This is because it comes to bear upon the currently available funds of a customer at any given time.

If a customer (or their nominee) isn't able to determine a customers' currently available funds, it throws out of sync the vast multitude of realtime/budgeting/value added calculations, services and potential notifications.

In short, improper handling of account authorisations would render the spec almost useless.

@speedyps

This comment has been minimized.

Copy link

speedyps commented Nov 6, 2018

There is a mistake in the https://consumerdatastandardsaustralia.github.io/standards/#get-transactions-for-specific-accounts area.

The 200 response points to AccountsBalancesResponse not (I assume) AccountTransactionsResponse

@speedyps

This comment has been minimized.

Copy link

speedyps commented Nov 6, 2018

There are no end-date parameters on the Transaction requests, so it isnt possible to retrieve transactions within a specified range, only from a date to today.

Going back through the Decision 28, I couldn't see commentary suggesting that the end-date parameter was being removed.

@BrianParkerAu

This comment has been minimized.

Copy link

BrianParkerAu commented Nov 6, 2018

The extendedData element appears only returned when querying a specific transaction : accounts//transactions/.

A call to accounts/transactions does not return this data element - instead it returns isDetailAvailable = true/false.

It would be preferable to provide a parameter to control the return of the extendedData element in the following APIs:

accounts//transactions
accounts/transactions

Alternately always return the extendedData element

@BrianParkerAu

This comment has been minimized.

Copy link

BrianParkerAu commented Nov 6, 2018

@speedyps You are correct ... the end-date is no longer part of the filter.... although it is part of the UK standard.

@JamesMBligh Was this intentionally removed?

@JamesMBligh

This comment has been minimized.

Copy link
Contributor Author

JamesMBligh commented Nov 6, 2018

Hi All, some minimal response to some of the feedback to clarify. I don’t attempt to respond to all feedback here but there are some logistics to comment on...

Swagger
Yes, swagger is coming. It may take a few more days.

Discrepancies
There are some discrepancies noted between the decisions and the draft spec. There was a lot of content to transition and sometimes I made mistakes. Apologies. This includes the transaction payloads, end-time filters, missing products, etc.

I have been reviewing since release and believe I have fixed these discrepancies. I suspect that some will still remain. Please note if something seems wrong. Also interested in whether the documentation is readable.

Transactions
Hopefully there is still value in the spec if we don’t get transactions exactly correct in the first draft. Some use cases don’t even require transactions ;)
At the moment I believe the transaction documentation matches the discussion on the transaction payload decision. If it doesn’t let me know, otherwise the feedback is noted and will be considered.

Missing Payloads

  • Standing orders is not included as it wasn’t referenced in the ACCC Rules Framework, which the standards are subordinate to.
  • Address Book is essentially payees which is included.

-JB-

@BrianParkerAu

This comment has been minimized.

Copy link

BrianParkerAu commented Nov 6, 2018

@JamesMBligh The Swagger doesn't show the banking/payees end points although it is referenced in issue 32. Could I suggest that you provide a folder to record all of the final decisions - at present it requires trawling through all of the closed items to locate the pdf.

@BrianParkerAu

This comment has been minimized.

Copy link

BrianParkerAu commented Nov 7, 2018

The latest Swagger defines common field types "MaskedPANString" and MaskedAccountString. Both of these show the last 4 digits in clear.

The Get Account Detail response shows the account being returned as MaskedAccountNumber with text indicating the last 3 digits are in the clear.

This appears to be an error. When details are returned the Account Number should be returned in the clear. ie change the name from "maskedNumber" to "accountNumber" and set the type to String.

Consider removing the MaskedAccountNumber type completely as it is conflicting with the common type "MaskedAccountString".

@BrianParkerAu

This comment has been minimized.

Copy link

BrianParkerAu commented Nov 7, 2018

When accountNumber is returned in the clear (see previous comment) guidance should be provided on the formatting to include BSB and Account. Specific reference needs to be made to handling 5 digit BSB's (ie unconditionally format as a 6 digit number followed by a separator (- or /) followed by the account number (these also should have formatting rules (eg 9 digit numbers with leading zeroes). NPP Participants will be well aware of the problems free-form account numbers have caused.

Alternately implement a BSBAccount type {"bsb":"12345", "accountNumber":"12345"} where leading zeroes don't need to be considered.

@BrianParkerAu

This comment has been minimized.

Copy link

BrianParkerAu commented Nov 7, 2018

Rule 5.3.2 requires the inclusion of "any identifier or categorisation of the transaction by the data holder (that is, debit, credit, fee, interest, etc.).

This seems to be omitted from the Get Transactions and Get Transaction Details

I had expected to see structures similar to the UK model : Either the BankTransactionCode (which is the ISO transaction code list), or ProprietaryBankTransactionCode, or both may be populated.

Parsing the description to determine the transaction type is problematic due to the proprietary formatting of this field by FI's.

@BrianParkerAu

This comment has been minimized.

Copy link

BrianParkerAu commented Nov 7, 2018

Rule 5.3.2 should also cover the identification of Card based transactions using the AS2805 fields supplied in the message.

The MerchantDetails structure as implemented in the UK model would satisfy this need. Populating the Merchant Name and Merchant Category Code from the AS2805 fields will deliver a more accurate result than attempting to parse the message and add considerable value to consumers of the API

@jh-a

This comment has been minimized.

Copy link

jh-a commented Nov 7, 2018

Virtually every use case of value to customers requires transactions and their detail. As transaction detail has to be requested individually, what would be one call to the transactions endpoint with readtransactionsdetail as the permission grant (UK model), could become 1001 calls where each transaction detail is pulled individually (Aus model). As soon as this approach is scaled for any number of customers/accounts it becomes completely unsustainable for data providers and data consumers alike.

@speedyps

This comment has been minimized.

Copy link

speedyps commented Nov 7, 2018

Transactions
Hopefully there is still value in the spec if we don’t get transactions exactly correct in the first draft. Some use cases don’t even require transactions ;)
At the moment I believe the transaction documentation matches the discussion on the transaction payload decision. If it doesn’t let me know, otherwise the feedback is noted and will be considered.

@JamesMBligh, not having the transaction types ie things like Interest, Withdrawal, Deposit, Transfer, Direct Debit, ATM, ACH, Dividends, Check etc is a step backwards from what is available now. This is a fundamental part of data delivery today (and has been for the last 20 years). I would strongly suggest that the transaction record include a Type field. My recommendation would be to use the UK Open Banking spec ProprietaryBankTransactionCode entry. This would then match existing functionality and allow providers to use their own internal codes (and optionally specify if they adhere to an existing standard)

If we wanted to stretch that bit further (but it might incur too much work for providers), I would recommend including the BankTransactionCode as per the UK Open Banking spec, (mapped to ISO 20022). This would mean that all transactions will be being reported the same way across all providers. However, I accept that this is probably one step too far based on our current timelines.

@perlboy

This comment has been minimized.

Copy link
Contributor

perlboy commented Nov 8, 2018

When accountNumber is returned in the clear (see previous comment) guidance should be provided on the formatting to include BSB and Account. Specific reference needs to be made to handling 5 digit BSB's (ie unconditionally format as a 6 digit number followed by a separator (- or /) followed by the account number (these also should have formatting rules (eg 9 digit numbers with leading zeroes).

This sounds like "a good idea" and can be solved with an OpenAPI format definition on the strings in question.

If we wanted to stretch that bit further (but it might incur too much work for providers), I would recommend including the BankTransactionCode as per the UK Open Banking spec, (mapped to ISO 20022). This would mean that all transactions will be being reported the same way across all providers. However, I accept that this is probably one step too far based on our current timelines.

I agree that transaction type records seem like a relevant component to add to the standard. With that said I oppose the idea of adopting a proprietary record set because it's "too hard" to adopt an ISO standard. Provider implementation difficulty shouldn't trump the use of open standards not to mention that data mappers are used heavily within organisations already (ie. it isn't particularly difficult). If ISO20022 meets the requirements it should be adopted.

Without wanting to politicise this process I dare say that organisations will come up with a myriad of reasons why they won't be able to hit the proposed timeline. While some of these will be valid it seems to me that the mere fact this standard is coming about through legislation indicates implementation challenges are far outweighed by protectionist attitudes in the industry generally. Happy to be refuted on this but maybe this is best taken offline (or integrated with a helpful response) to avoid poisoning @JamesMBligh's thread.

Virtually every use case of value to customers requires transactions and their detail.

I disagree, a mere listing of high level transaction data seems like a very common use case akin to the current typical transaction list within normal internet banking applications. With that said though I agree that making 1:N calls to obtain detailed information could represent a significant API scale demand.

Perhaps the middle ground here is that GET /accounts/{accountId}/transactions could include a detailed=true parameter which determines whether the returned object is BasicTransaction or TransactionDetail. The challenge of this approach is that the response is now softly typed with an anyOf between the two. I'd also point out that anyOf was not supported until OpenAPI 3.0.x so this makes older implementations incompatible. At this stage I don't believe the standard declares a minimum OpenAPI version, perhaps it should?

The alternate to the above would be the introduction of a GET /accounts/{accountId}/transactions/detailed or GET /accounts/{accountId}/transactions-detailed method which would allow hard response typing while still achieving the goal. I favour the /transactions/detailed approach as it allows further extension while facilitating load balancer based decisions. Of course such decisions are possible in the non nested approach but imply a pattern match (rather than a URI routing) which would add additional performance consideration.

With regards to Product Categories, I'd highlight the standard is enforcing a set list of types without a catchall like OTHER_TYPE being available. With changes in financial products occurring on a regular basis it's quite possible new (potentially implementation specific) account types will exist and not having a way of communicating these within the standard will result in misrepresentation for these cases and/or somewhat unnecessary adoption of vendor specific variable overloading (which is supported but a bit excessive?).

With regards to the Account schema. The explicit use of separate Balance return types lends itself to nastiness if it extends past the current three. While this may be driven by the UK standard it is likely the reason for this was because at the time OpenAPI 2.x (fka swagger) didn't support nested oneOf's. I believe OpenAPI 3.x has added this support allowing for more explicit oneOf on the three return types. Ie. The return variable can be "balance" with 3 different types. This could put a spanner in code generation libraries though so maybe we just accept that there will be if/else chains to determine what balance variable to read.

With regards to scope names, it's pedantic but the traditional method of scope declaration is x:y:read/write which typically lends itself to trivial pattern matching during security evaluation. The scope names as defined now seem more human readable than machine readable and this will result in pick list hardwiring resulting in nested if/else during implementation.

Finally, the use of POST's to supply an array of values (as is the case in POST /accounts/transactions & POST /accounts/direct-debits) isn't "normal" REST nomenclature. Typically such requests would be placed inside GET's with query strings although I acknowledge that doing so could introduce query string limitations and also loose typing as OpenAPI GET support of arrays in query strings isn't particularly nice. All that aside though it means that scope assessment is once again being hardwired in a way that disregards the method type in the process and so WAF's won't be able to do explicit filtering at the point of receive. I accept I haven't provided much of a suggestion here but I've always seen GET as read, POST as create and PUT as update. This breaks such typical conventions but perhaps I just need to "get over it". :-)

@BrianParkerAu

This comment has been minimized.

Copy link

BrianParkerAu commented Nov 8, 2018

@jh-a I totally agree. Access to the detail should be controlled by a scope/permission to allow the additional structures to be populated by the provider when processing the Get Transactions call. Forcing the consumer to make additional calls to Get Transaction Detail will significantly degrade the end-user experience, place unnecessary load on the provider and provides no additional security on the detail data.

@perlboy

This comment has been minimized.

Copy link
Contributor

perlboy commented Nov 8, 2018

@jh-a I totally agree. Access to the detail should be controlled by a scope/permission to allow the additional structures to be populated by the provider when processing the Get Transactions call. Forcing the consumer to make additional calls to Get Transaction Detail will significantly degrade the end-user experience, place unnecessary load on the provider and provides no additional security on the detail data.

This implies multiple response types with the same http code (or sparsely populated detailed transaction objects which, quite frankly, "sucks"). This was considered and rejected in 2015 (OAI/OpenAPI-Specification#270) but an alternate has since become available via anyOf/oneOf/allOf in OpenAPI 3 (https://swagger.io/docs/specification/data-models/oneof-anyof-allof-not/).

With that said, using scope/permissions as the discriminator, in my opinion, is a "bad idea" as it is now tying the security implementation to the data generation layer. Channeling the KISS principle security rules should be defined cleanly & separate from data generation.

It is very common practice to separate these layers (in code and/or infra and/or department) as it means security audits have a far smaller evaluation surface and can be coupled with response filtering (ie. inside the WAF) away from the data generation side.

I don't see any particular advantage over simply adding a boolean "enable detail" parameter or separate detailed list call which, assuming OpenAPI 3 is the minimum expectation, can be facilitated with a oneOf wrapper on the transaction data. This approach could be trivially inspected at the security layer against the token permissions while keeping the data generation layer cleanly defined based on the input parameters.

@speedyps

This comment has been minimized.

Copy link

speedyps commented Nov 8, 2018

I don't see any particular advantage over simply adding a boolean "enable detail" parameter or separate detailed list call which, assuming OpenAPI 3 is the minimum expectation, can be facilitated with a oneOf wrapper on the transaction data. This approach could be trivially inspected at the security layer against the token permissions while keeping the data generation layer cleanly defined based on the input parameters.

I agree with @perlboy on this. I think my preference would be for a flag to say enable detail, as that feels slightly cleaner.

@BrianParkerAu

This comment has been minimized.

Copy link

BrianParkerAu commented Nov 8, 2018

@speedyps Works for me... a flag to control what is generated, and scope to ensure the caller is authorised to set the flag.

@dmcranston

This comment has been minimized.

Copy link

dmcranston commented Nov 23, 2018

Hi,
I am not sure if this is the correct thread or not.
In the specification it references components of the JASON:API specifications rather than taking on the whole specification. Is there are reason the PI's are not being fully compliant to that specification?

@kennethleungswift

This comment has been minimized.

Copy link

kennethleungswift commented Nov 23, 2018

To supplement on my colleague @DDobbing 's feedback above, from SWIFT’s perspective, we highly recommend the consideration of using ISO20022 message elements and components where applicable.

Another point I want to make is to make sure the design of payload has considered both from the lenses of consumer client and corporate client. For instance, the response data’s structure and completeness are more important for reconciliation purpose from a corporate client’s perspective.

A few more suggestion:
6. TransactionCode
• It has been mentioned by other folks but would like to stress the importance of this for end-users to accurately identify and distinguish the transaction without additional parsing / guessing logic.
• Consider to use the ISO element BankTransactionCode and/or ProprietaryBankTransactionCode – as in UK Open Banking.
7.The following elements are missing which are essential and important for a transaction from a bank customers’ perspective to perform reconciliation in a structural manner:
• ChargeAmount (related bank charges on the transaction if applicable)
• CurrencyExchange, InstructedAmount (when it is a FX related transaction)
• CreditorAgent
• CreditorAccount
• DebtorAgent
• DebtorAccount
• MerchantDetails (if it is retail and card transaction related)
• CardInstrument (if it is retail and card transaction related)
All the above are ISO20022 elements and used in UK Open Banking as well as the wider standards in the existing bank account reporting space

@MacquarieBank

This comment has been minimized.

Copy link

MacquarieBank commented Nov 23, 2018

Our first feedback is to say well done on reaching the milestone of a first draft for Open Banking! Below is our feedback on the first draft. Please note, given this is the first draft, we have sought feedback from a wider group of internal stakeholders, so some feedback will be on earlier decision proposals. We felt it was important to include this feedback, as it relates to complexity in implementation.

HTTP Headers (MGL-1)

We support the requirement to return a minimum of set of standard HTTP response headers, to ensure strong security amongst all data holders. A good starting point for these headers is https://www.owasp.org/index.php/OWASP_Secure_Headers_Project#tab=Headers

URI Structure (MGL-2)

Although discussed in an earlier decision proposal, feedback from our engineers is a strong preference to avoid naming collisions in the URI structure.

As an example:

GET …/accounts/{id} Returns the detail of a specific account
GET …/accounts/transactions Returns the transactions of multiple accounts
GET …/accounts/{id}/transactions Returns the transactions of a specific account

The second API makes it difficult, as you need to ensure there is no {id} = transactions. It would be preferable to have this as GET ../transactions

Pagination (MGL-3)

We don't support making the following attributes mandatory: page, last, totalRecords, totalPages.
We do not currently provide the functionality to jump to a random page in our website or mobile app, and favour a standard 'cursor' approach, where you can simply fetch the next set of transactions. This is a common approach used by many applications (e.g Facebook, Twitter, Google), and is natively supported by many database technologies.

Having to implement page, last, totalRecords, totalPages requires architectural changes, and will have an impact on performance. Given the timeframe of 1st July 2019, this would be difficult to accommodate.

Security (MGL-4)

As noted in our previous feedback, we do not support using MTLS. See our original comment for rationale and preferred alternative.

Get Accounts (MGL-5)

(MGL-5.1) Could a more detailed description be given for the providerType field? It is not clear what we should provide for this field. Perhaps a more descriptive field name could also be given?

(MGL-5.2) Our preference would be for balances to be removed from this API, and only be included in the balances API. The rationale for this is:
• Easily allows a customer to only share account details (and not balances) if they choose
• Reduce maintenance and testing as the balance schema changes over time
• Improve performance by not having to retrieve balances (if not required by the data recipient)

Get Bulk Balances (MGL-6)

We have concerns about being able to meet API principle #9 (APIs are performant), particularly where the consumer may have thousands of accounts (e.g. a business, accountant, or financial adviser). For July 1 2019, we would like to see this made optional, and give time to explore if there are any better patterns for handling bulk balances. If bulk is required, a data consumer can still retrieve all accounts, and then retrieve balances for a set of accounts at a time.

Get Bulk Transactions (MGL-7)

We have concerns about being able to meet API principle #9 (APIs are performant), particularly where the consumer may have thousands of accounts (e.g. a business, accountant, or financial adviser). For July 1 2019, we would like to see this made optional, and give time to explore if there are any better patterns for handling bulk transactions. If bulk is required, a data consumer can still retrieve all accounts, and then retrieve transactions for a set of accounts at a time.

Get Direct Debits (MGL-8)

As has been communicated prior, direct debit authorisations are not held by banks, so this API cannot technically be implemented. Our recommendation is that this API is flagged in some way, so that all participants are aware that it is not feasible to implement.

Get Products (MGL-9)

  1. The current enumeration of feature types is insufficient to fairly compare products. Below is a list of additional feature types we would like to see added:
    a. Concierge Service
    b. Discount gift cards
    c. Entertainment Offers
    d. Airport services
    e. Discount Travel Bookings
    f. Bonus Reward points
    g. Chip enabled card
    h. Purchase notifications
    i. Mobile Banking - this is to differ from online banking (i.e. a purpose built mobile app has been created)
    j. BPAY
    k. Scheduled Payments
    l. Direct Debit
    m. International Transactions
    n. Cash Deposits
    o. Cheque Deposits
    p. Emergency Travel Assistance
    q. Government Guarantee
    r. Interest Redirection
    s. Cheque Book
    t. Integrated Online Trading
    u. Account Type Switching - ability to switch between account types (e.g. At-Call and Term Deposit) while retaining same account number
    v. Business Segment Expertise
    w. Trust Accounting
    x. Dedicated Relationship Manager
    y. Third Party Integrations - describes the number of existing software integrations
    z. Bulk Payments
    aa. Merchant Payment Terminals
    bb. Payment Reconciliation
    cc. Customisable Interest payment frequency
    dd. Customisable TD Terms - you can specify a term deposit of any length you like (e.g. 65 day term deposit)
  2. We would also recommend a new Product Category to cover Regulated Trust Accounts (Deposits)
  3. We would recommend removing business/personal from Product Category, and leaving that to be part of Eligibility. We have some products that are applicable for both personal and business clients, so we cannot map this to a Product Category accurately.
  4. We would like to see the ability to define both tiered and stepped rates. Given there is an upcoming workshop on this, we will wait for the outcome of this.
@spikejump

This comment has been minimized.

Copy link

spikejump commented Nov 23, 2018

In addition to earlier feedback, we have the following additional comments.

+1 on use of cursor based pagination. Perhaps with examples of bulk API call with return of multiple account transactions with attention to pagination.

Perhaps include additional customer$type of "delegate" to accommodate a delegated user who has access to an account permitted by the account owner, e.g. financial advisers.

May be CreditCardAccountType needs a "balance$type"?

Both Loan and Credit Card Accounts should have an "autoInstallment" Boolean to indicate whether the bank will automatically direct debit the customer to pay the minimum amount type.

There should be an Investment account type (for specificAccount$type) supporting brokerage, annuity, pre-tax retirement and post-tax retirement holding types and transactions to support personal financial management or investment advisor applications.

@da-banking

This comment has been minimized.

Copy link

da-banking commented Nov 23, 2018

Direct Debits

Repeating our comment on #29:

We do not have the data required to meet the proposed structure. If this is retained in scope in its current form, we would implement the directDebitAuthorisations as an empty array.

We understand that the current position of Data61 is that as the ACCC has this specifically in scope, then it will remain in the API. We consider this position bizarre. Having an endpoint that does nothing makes no sense. We hope the ACCC sees sense.

Security

There is no mention about the user opting into the sharing of specific accounts.

Our expectation is that the PSU will be able to consent explicitly to which accounts are available to the data consumer (as per UK).

Get Transaction Detail

Just a clarification on the ExtendedTransactionData.payee field - outbound payments via NPP need not be to a PayID - the value assigned to the payee field may simply be a name assigned by the user.

What's the intent of this structure?

"extension$type": "extendedDescription",
"extendedDescription": "string"

It appears that we are redirecting one string field to another.

We propose the extension$type is NPP and extendedDescription and service are both specific to this type.

As identified by others, need support for sct as well as x2p1.

Pending transactions

There have been several mentions of pending transactions. These are not a thing from the perspective of a core banking system. They do not appear as a transaction on the account or the general ledger or a customer's statement. Pending transactions, which we call holds, are an entirely separate concept that can change the available balance of an account. They can be deleted, and they can auto-expire. Including holds, if in scope, should be a distinct endpoint to the transaction endpoints.

Get Products

The effective bool parameter appears a little odd.

If true then only include products that are effective right now and exclude products that may be available at a future time. If false only include products effective in the future. If absent defaults to include all products.

Giving a specific meaning to effective being unspecified is inconsistent, counter-intuitive and inflexible. For consistency with other APIs, we recommend an enum instead:
CURRENT, FUTURE, ALL

We would also re-iterate the need we stated here that discounts can be applied to customers, not just to products and accounts. This is a form of bundling. An example of this might be a regular customer gets $100 per month of waived transaction fees, rolled up across all of their accounts; where a high-value customer might get $200 per month of waived transaction fees.

The Product Discount Type enum is too limited. For example, a discount may be offered on the basis of age or employment status. Indeed most of the items described in Product Eligibility Types may also be a valid reason to provide a discount. That is, while access to the product may not be limited to specific eligibility criteria, discounts on fees for that product may be based on such criteria. Perhaps the the list of Product Discount Types should include the values in Product Eligibility Types. At a minimum, OTHER is essential to capture novel scenarios.

Also a swagger nitpick - example code includes discountType as a field of features, but the documentation for ProductFeature does not.

Pagination

Others have suggested cursor based pagination is preferred. We have no strong preference either way, and will support either, but not both.

@WestpacOpenBanking

This comment has been minimized.

Copy link

WestpacOpenBanking commented Nov 23, 2018

Westpac has the following additional comments

Endpoint versioning and Swagger

The current proposed versioning strategy is problematic when viewed in regard of swagger and automated tools for development (including automated code generation), quality assurance, operations and so on. In particular, there is no standardized way for swagger 2.0 to accommodate endpoint versioning with the proposed header negotiation – it can only expose all endpoints and fields for an API. We note that the versioning proposal was only able to be commented on by one bank and two individuals, and we feel that this issue needs to be revisited with wider input.

We strongly suggest a block versioning split by authenticated/unauthenticated endpoints and by industry (including a separate version for common endpoints) in alignment with the UK. This approach will support the development needs of both consumers and holders by allowing them to continue to use off-the-shelf and standardized development tools and welcome further discussion on the issue.

Other remarks on the Swagger specification

  • A majority of vendors and tools only support Swagger 2.0 at the current time. We would be unable accommodate a change to OpenAPI 3.0 before July 19.
  • The swagger file that has been published is not consistent with the html documentation or the decisions that have been published. For example, the swagger spec has min-amount and max-amount parameters for GET /banking/accounts with the descriptions from the transactions endpoint. We’ve not yet had time to find and list every difference in detail but suggest the use of documentation generation tools rather than trying to edit the documentation and the swagger separately.
  • We support the comments made by @perlboy on embedded enumerations, object extensions, the DRY paradigm, the use of ‘required’ and definition inconsistencies.
  • The json version of the swagger file is not valid json. The problem appears to be extra commas in various places. We’d suggest the use of linting tools to catch this type of error.

Sensitive PII data included

A number of endpoints, including the customer endpoints, the account detail endpoint, the payee endpoints and the transaction endpoints include sensitive data. We have concerns with sharing sensitive data without masking/hashing. We also note that the sensitive data shared may not be the data of the party who gave consent to share it. Sharing such information at scale puts at risk sensitive information of both customers and non-customers.

BillerCode

We are able to provide billerCode for payees. For transactions, the billerCode is part of the payment instruction which is not always possible to link to the transaction and may or may not be held by us.

Transaction Codes

Transaction codes in Australia depend on the payment type and are often proprietary (with less standardization than in the UK). We think that the most value to data consumers will be provided by providing an appropriate ISO 20022 code, but that doing so requires considerable mapping activity to occur. This would also be the case with a less complex scheme with fewer transaction types. For pragmatic reasons around the July 19 deadline and build complexity we suggest that codes are added to a later version of the standard.

Data quality and data entry

Data quality issues are common with customer entered information. For example, customers might accidentally transpose or misspell names or may not understand the difference between a business name and a trading name and enter those fields incorrectly. We suggest that the descriptions of person, organisation and payee endpoints reflect how data has been collected and that it is subject to customer error. This would facilitate transparency around the accuracy obligations under the proposed Consumer Data Right Privacy Safeguard 11.

Minor inconsistencies between draft standard and decision proposals

In addition to those noted in our previous response, we have spotted the following inconsistencies between the draft standard and the decision proposals:

Schema Field name Discrepancy
Person lastUpdateTime Description missing
Person firstName Decision is optional, standard mandatory. Description partially missing
Person middleNames Description missing including note that array can be empty
Person Prefix Formatting example part of description missing
Person Suffix Formatting example part of description missing
Person organisationType Standard is has required = false, decision has the field being required.
PAFAddress N/A Decision says that this will be defined in the draft standard, but there is only a placeholder
Account productCategory Called accountCategory in the decision. Optional in draft standard, mandatory in decision.
Account balance$type String instead of enum and permissible responses from decision missing
AccountDetail termDeposit/creditCard/loan Decision allows for none of these to be included for appropriate account types. Standard requires inclusion of exactly one of these objects
AccountDetail specificAccount$type Mandatory in decision, required is false in draft standard
AccountDetail address (Note our earlier feedback on security scopes in relation to this field) It is optional in the draft standard and mandatory in the decision.
ProductFee Amount Mandatory in decision, not required in standard
Many schemas additionalValue Wording in draft standard is confusing because the field isn’t labelled ‘Conditional’
TransactionBasic Reference Draft standard has required, decision has optional
Payee Type Enumeration is of string type

We agree with @anzbankau’s comments on the transaction, product and account endpoints, on common schemas and their general comments section. In particular, we note that the comment about the inconsistent use of an amount object for storing amounts and currencies. We suggest alignment with the UK and consistency.

@NationalAustraliaBank

This comment has been minimized.

Copy link

NationalAustraliaBank commented Nov 23, 2018

Summary

NAB welcomes the opportunity to respond to the 2 November 2018 Working Draft of the CDR/Open Banking Standards.

Summary of our feedback:

  • This feedback should be read in conjunction with NAB's related feedback to Treasury and the ACCC
  • Sensitive information should be excluded and/or phased until proof of controls are in place
  • Security should be a top priority and play a leading role in the definition of the Standards
  • Phasing of scope according to our recommendation detailed below
  • Feedback on the process and impacts to implementation timelines
  • General standards feedback

Related feedback

This response builds on NAB’s extensive contributions to the public policy debate on Open Banking. These include:

  • NAB’s September 2017 submission to the Review into Open Banking
  • NAB’s March 2018 submission in response to the Review
  • NAB’s September 2018 submission in response to the Treasury Laws Amendment (Consumer Data Right) Bill 2018 (CDR Bill)
  • NAB’s October 2018 submission in response to Treasury’s further consultation on the CDR Bill
  • NAB’s October 2018 submission in response to the ACCC’s consultation on the Rules Framework

Sensitive Information

In all of NAB’s interactions regarding the development of the CDR we have emphasised that safety and security of customer data is absolutely paramount. NAB continues to have serious concerns regarding the security implications of some aspects of the framework. This includes the sharing of sensitive information including Personally Identifiable Information (PII) and information that supports banking identity verification, such as mobile numbers and email addresses. It also includes customer sensitive transaction and payee data.

NAB objects to the inclusion of customers' personal information as there are significant security risks associated with the sharing of such a level of confidential data.

Given that KYC data is excluded in Phase 1 and customers will not be able to switch providers via the CDR alone, NAB does not consider there is an appropriate use-case for the data. There is also a strong argument that any personal information can be supplied by the customer to the data recipient directly.

Security

There are significant security risks associated with the sharing of confidential data and therefore security should be our top priority as part of the Open Banking scheme. NAB welcomes the kick-start of the industry security forums but we strongly recommend Data61 dedicate more resources to carefully and dutifully analyse abuse-cases and design controls in collaboration with the industry to achieve a high security standard.

We have identified a number of security gaps that require further analysis and inclusion in the Standards, as follows:

  • The hybrid authorisation flow needs to be further detailed. NAB prefers the separation between authentication and consumption devices in order to be able to prevent phishing attacks
  • A more granular set of scopes should be further analysed, in particular for the customer's transaction data as detailed below. A customer may not be fully aware of the data they are sharing and its consequences
  • A definition for payload data integrity to protect it against data tampering (signing)
  • Fingerprinting of origin devices and collection of intelligence data from end-point devices to detect and prevent malicious activities
  • API endpoints - definitions of applicable thresholds (throttling) and filtering enforced based on client and end-user information (i.e. IP address, endpoint device signature, etc)
  • Session timeouts - we suggest a session timeout < 15 minutes; access-tokens should be revoked once the timeout is reached
  • The consent revocation processes and notifications based on rules definitions (i.e. data removal, de-identification)
  • Client Authentication Method and the use of Private Key JWT (preferred)
  • The inclusion of PII payload on ID Token requires further analysis (from Data61 Security forum conducted on 16/11/2018)

The definition of these and other security gaps are essential to complete the solution's blueprint. Where these matters remain uncertain, it limits the ability of data holders to build a solution and has the potential to add delays and risks to the process.

Phasing of scope

We strongly recommend focusing on a smaller set of Minimum Viable Product (MVP) APIs for Phase 1 rather than attempting such an ambitious scope. It will be a major accomplishment to have the system go live by July 1st 2019 regardless of the number of APIs that are present in the scheme. Instead we should focus on de-risking the implementation by focusing our attention on the non-functional aspects of the scheme. We highly recommend following an Agile or Iterative methodology as this allows us to learn and adapt as we uncover the finer intricacies of what makes for a successful and secure system.

Now that we have visibility of the data scope which consists of 17 APIs we are confident that the timelines are unrealistic, especially given the fact that industry testing will need to start well before July 1st 2019. We also are cognisant that the directory and administration APIs are unclear and will also require significant data holder implementation effort.

As a start, we propose the following APIs be removed from the MVP scope. These APIs either provide the same data as other APIs, expose sensitive data, or we as data holders do not have the data available.

GET /banking/accounts/transactions (bulk transactions)  
POST /banking/accounts/transactions (bulk transactions)  
GET /banking/accounts/{accountId}/direct-debits  
GET /banking/accounts/direct-debits  
POST /banking/accounts/direct-debits  
GET /banking/payees  
GET /banking/payees/{payeeId}  
GET /common/customer  
GET /common/customer/detail

We also propose that a plan is developed to include a review and updates to the Standards based on the planned phasing i.e. Phase 1, 2 and 3. Rather than review the current published Standards as the final end state version, NAB considers that there should be an opportunity to review and revise the Standards after each phase implementation in order to improve them for the next phase.

Feedback on the process

We commend the progress made thus far, the openness of the process and the pace at which the various industry bodies are working in parallel. There are however, fundamental gaps:

  • Particularly, in the security and user experience domains these gaps impact the data holders' ability to deliver a successful and consistent implementation of Open Banking. We strongly recommend that we pause and reflect on the risk of rushing to expose our customer's most sensitive information. With this in mind, refer to our feedback on phasing of scope.
  • The accreditation process, requirements and obligations for data recipients need to be articulated in conjunction with the Standards to ensure that the controls are embedded within and are compatible with the Standards.
  • There are a number of administration end points that have not been articulated or understood from the data holders' perspective, which we believe need to be in place before we expose any data within the scheme. This again amplifies our point on phasing of scope.

General standards feedback

We have previously given feedback via DP30 that the definition of mandatory vs. optional vs. conditional for each field/object was too ambiguous e.g. sometimes within the standard Optional seemed to indicate a provider choice.

To minimise confusion and interpretation whilst implementing the APIs we would like to see the revised version of the Standards clearly distinguish:

  • Optional (provider choice)
  • Mandatory (if the data is available)
  • Mandatory (create, capture or enrich data)
  • Conditional (specific rules which follow one of the above)

Transactions APIs

The following feedback relates to the transactions APIs:

  • Get Transactions For Account
  • Get Transaction Detail
  • Get Bulk Transactions
  • Get Transactions For Specific Accounts

Overall

Detailed transaction remittance information within transaction data APIs allows data recipients to infer and correlate information about our customers, their behaviour and lifestyle patterns (e.g. data about hospital visits and specialist treatments and conversations via NPP detailed and instant remittance information). The inclusion of this information may not be apparent to customers when giving consent and is irrevocable once granted. Customers may not be aware of the possibilities of how this data may be used in ways which they did not intend.

Therefore, we recommend additional and more granular authorisation scopes for transaction data as per the below list:

  • Transactions Basic - provides access only to basic transaction information e.g. date, amount, status.
  • Transactions Detail - provides access to more detailed but not sensitive or personal transaction information e.g. extensionType, service.
  • Transactions Sensitive - provides access to sensitive or personal information e.g. payer name, payee name, reference, extendedDescription.

Query Parameters

The inclusion of complex query parameters such as transaction amount and free text searches across vast data sets and unbounded timescales is resource intensive for data holders. We recommend reducing the MVP scope and making these query parameters optional.

Description

We believe the definition "The transaction description as applied by the financial institution." is too broad and can be interpreted in many different ways. We believe this should be detailed further with some examples given.

Direct Debits APIs

The following feedback relates to the direct debits APIs:

  • Get Direct Debits for Account
  • Get Bulk Direct Debits
  • Get Direct Debits for Specific Accounts

As previously mentioned in DP29, banks are not the data holders for direct debit authorisations which are debited from their customers' accounts.

NAB strongly objects to the proposed approach which is a workaround to derive the data from the already processed direct debits. This will not be a trivial exercise, could lead to inconsistencies across implementations and exposes incomplete and misleading data. We also question whether this would deliver the intended user experience, particularly in the use case of account portability, as key data is missing e.g. frequency, amount per debit, expiry date. We also note that in Phase 1 account portability within the CDR will not be possible given KYC data is excluded.

Get Payee Detail

As previously mentioned above and in DP32, the API payload contains the personal information of other parties. NAB strongly objects to the inclusion of data that belongs to other people or organisations without their explicit consent. The transfer of this data would effectively involve the transfer of personal information where the individual to whom it relates has not explicitly consented to its transfer. In addition and as noted above, in the absence of a use-case for data portability in Phase 1 of the CDR we do not agree or endorse that this data should be included.

DomesticPayeeType - bsb and accountNumber

We note that the bsb and accountNumber for the customer's payee are not masked whereas we do expect the customer's account number and BSB to be masked. We believe this is inconsistent and masking should also apply to the payee's account number and BSB.

DomesticPayeeType - payId

The name field should not be included in the Standards. This field is mandatory and is defined as "The name assigned to the PayID by the owner of the PayID." However, this is not data required to make an NPP PayID payment nor is it always held or stored by the data holder. There are other ways to access this data held by the NPP PayID Central Addressing Service.

The identifier field is a payee's personal information e.g. mobile number, email address. The identifier is not the customer's data and the data holder does not have consent from the payee to share this data. The payee may not want the customer to share their personal information with a third party. The payee may have provided their PayID to the customer with the expectation that it would only be used to make a payment via the customer's banking channel.

Common Schemas

address within AccountDetail

Similar to our other concerns regarding the inclusion of a customer's personal or sensitive information within the payloads, we object to the inclusion of the correspondence address information within the Account Detail payload. The correspondence address is considered PII and is particularly sensitive, especially if this potentially reveals the location in which the bank will send out physical plastic cards. Also, we believe it is not intuitive for a customer that their detailed account information also includes their address.

balance$type and associated structures

We believe the way Balance and Limit are represented are overly complex and suggest this should be be simplified. We believe the current proposal creates the need for more complex processing rules for data holders and data recipients than is necessary.

A simpler representation is possible with only one balances object (allowing multiple balances and currencies) and a separate limit object. Our recommendation is summarised below:

  • Create a new balances object as an array containing only the balances (see below)
  • Create a new limits object and move limit details out of the LendingBalanceType into this object (see below)
  • Remove the following objects - balance$type; PursesBalanceType; LendingBalanceType; DepositBalanceType

This allows any account to have one or many balances in one or multiple currencies.

This simpler representation delivers on the intent and is simpler to understand, interrogate and implement and is the most accurate representation of the data. An example of how this might be represented is below:

Name                 Type               Required    Restrictions      Description

» balances           [AccountBalance]   true        none              Array of balances on the account

» limit              [AccountLimit]     false       none              The credit limit details for the account

AccountBalance Properties

Name                 Type               Required    Restrictions      Description

» currentBalance     CurrencyAmount     true        none              The current balance of the account at this time. Should align to the current balance available via other channels such as ATM balance enquiry or Internet Banking.

» availableBalance   CurrencyAmount     true        none              The available funds in an account. Assumed to be positive or zero.

AccountLimit Properties

Name                 Type               Required    Restrictions      Description

» creditLimit        CurrencyAmount     true        none              The maximum amount of credit that is available for this account. Assumed to be positive or zero.

» amortisedLimit     CurrencyAmount     false       none              The available limit amortised according to payment schedule.

ProductCategory

While we can work with the enumerations outlined in the standard, we think it’s easier and at times more accurate to remove the Business and Personal separation for this classification and use eligibility criteria to determine whether available to businesses or individuals or both for most product types.

We also believe the Foreign Currency options can be treated as Features within existing product categories rather than mandating them as their own categories.

Given the above, we propose a simpler list that looks like the below.

  • AT_CALL_DEPOSITS
  • TERM_DEPOSITS
  • RESIDENTIAL_MORTGAGES
  • CREDIT_AND_CHARGE_CARDS
  • PERSONAL_LOANS
  • LEASES
  • TRADE_FINANCE
  • OVERDRAFTS
  • BUSINESS_LOANS
  • TRAVEL_CARDS

maskedNumber

This definition of masking conflicts with the definition in the standards section under "Common Field Types". Also in the standards section there are two masked data types, one for credit cards and one for other account numbers, whereas within the Accounts payload, only one type is used for both.

CreditCardAccountType

We don’t understand the difference between minPaymentAmount and paymentDueAmount and this should be further detailed in the description. They appear to be the same field.

LoanAccountType

LoanEndDate, nextInstalmentDate, minInstalmentAmount and repaymentFrequency do not apply to most Overdraft type products so recommend they should be optional and not mandatory

openStatus (missing)

We note that openStatus is missing in the response. This has previously been agreed to be included but has not made it into this version.

providerType / productName

We note the previous change of providerType to productName in this schema has been rolled back. We assume this is an oversight as this was fixed in final published versions of DP27 and DP31.

isNegotiable

As previously stated, we do not support inclusion of a field called isNegotiable, particularly as described. We propose the following replacement name and description:

“pricingOnRequest" - pricing for this product is not published because of the complexity of factors that drive the final price and can only be finalised as part of the application process.

Product & Account Components

Overall

We are concerned that the split of the Account and Product Components into different groups / enumerations (for example Product Feature Types / Account Feature Types, but extends also to Fee Types, Discount Types and Rate Types) will lead to these diverging over time and this does not seem necessary. This is already happening with the ESTABLISHMENT fee type being available as an option in Product Fee but missing from Account Fee. We assume this is an oversight, but propose they are all merged to remove future / unnecessary anomalies or confusion. If these are to stay split, what controls will be in place to ensure they remain consistent? Feedback throughout is combined in the interest of not repeating ourselves.

Rate Type Feedback

As per our feedback on DP30 the modelling of interest rates is insufficient. The suggestion that complications for differences in rates should all be covered in the additionalValue field can be implemented by NAB but is not easily machine-readable. Examples of the sort of information that would need to be placed in the additionalValue field is outlined in the links below that we publish today. Note that the additionalValue field will need to include information about lending purpose, repayment type and fixed term in the home loan examples.

https://www.nab.com.au/personal/interest-rates-fees-and-charges/indicator-rates-selected-term-deposit-products

https://www.nab.com.au/personal/interest-rates-fees-and-charges/interest-rates-for-home-lending

Product Feature Types / Account Feature Types

We recommend the inclusion of the additional Feature Types listed below:

  • Capped Interest Rates
  • Flexible Maturity Fixed Rate
  • Foreign Currency
  • Multi Currency
  • Other – to allow data providers to name specific features outside the suggested groups – this allows data holders to introduce and promote new features on products without telegraphing this to its competitors

Product Fee Types / Account Fee Types

We recommend the removal of the fee types listed below from the enumeration as they are specific fee names, not fee types (i.e. these should be listed fees within the Fee name field mainly classified as OTHER_EVENT):

  • OVERDRAW (OTHER_EVENT)
  • REDRAW (OTHER_EVENT)
  • CHEQUE_STOP (OTHER_EVENT)
  • CHEQUE_BOOK (OTHER_EVENT)
  • CARD_REPLACE (OTHER_EVENT)
  • PAPER_STATEMENT (OTHER_EVENT)
  • MIN_BALANCE (PERIODIC)
  • CHEQUE_CASH (TRANSACTION)

Product Discount Types / Account Discount Types

We recommend the inclusion of the additional Discount Types listed below:

  • Loyalty – with loyalty rules in the additionalValue field
  • Customer eligibility – with eligibility rules in the additionalValue field
  • Other – to allow data providers to name specific discount types outside the suggested groups

Product Deposit Rate Types / Account Deposit Rate Types

As per previous feedback, we recommend the inclusion of the additional Deposit Rate Types listed below:

  • Floating
  • Market Linked

Product Eligibility Types

We recommend the inclusion of a type to indicate that a product is available to an individual / natural person.

Common (customer) APIs

Overall

As explained above and in DP26, we strongly believe that PII that is currently used for the purposes of identity verification, password recovery or multi-factor authentication should not be shared with data recipients under any condition.

lastUpdateTime

The exact intent of this field is not clear. For instance, it may refer to either the last time that the complete set of customer data has been reviewed and updated; or any individual data field has been updated. Depending on the intent, NAB may or may not hold this data. Given the uncertainty regarding the intent and accuracy of the field, we recommend the field to be removed or be made optional.

firstName, middleNames, prefix

These fields should be optional as they may not apply to all customers.

isPreferred (Phone)

This field should be optional as it is for email. No preference may have been captured so can not be inferred. Also, some customers may have requested (as a preference) not to be contacted by phone, so provision of any phone number as a preferred contact number would be inconsistent with previous customer preferences.

occupationCode

NAB considers that this field should not be included within the customer payload, as it is likely to be inaccurate (i.e. it may be out of date) and that it is sensitive customer information for an individual. In addition, we note that this field was not specifically referred to within the Designation Instrument or Rules Framework.

abn, acn, isACNCregistered, industryCode, organisationType, registeredCountry, establishmentDate

This data was not specifically requested within the Designation Instrument or Rules Framework so we do not believe it should be included within the customer payload.

phoneNumbers, emailAddresses

NAB has previously provided detailed feedback regarding our concerns with respect to sharing sensitive PII data. NAB strongly believes this data should not be included in the payloads as it increases the risk of identity takeover in the event of a breach.

physicalAddresses

As above, NAB has serious concerns with sharing sensitive PII data via payloads. We also note that this data was not specifically requested within the Designation Instrument or Rules Framework.

@commbankoss

This comment has been minimized.

Copy link

commbankoss commented Nov 23, 2018

Commonwealth Bank is supportive of the principles that have been applied to developing the Consumer Data Standards (Standards). A summary of our recommendations are below, and have attached a document containing our detailed analysis.
Data_Standards_Submission_Github.pdf

Standards

With respect to the standards, Commonwealth Bank is broadly supportive of the recommendations associated with the versioning of APIs, HTTP response code definitions, and payload extensibility. Further clarity is required around the definition of fields marked as mandatory or optional.
We are partially supportive of the definition of API versions with a recommendation around standardising to HTTP header versioning only. Commonwealth Bank also has strong views around technical complications relating to pagination and recommends the use of cursor based pagination as an alternate approach. Lastly, Commonwealth Bank recommend Data61 revaluate ID permanence for its complexities.

Security

In relation to information security, Commonwealth Bank is concerned that important topics are yet to be addressed. Given the relationship between the API Standards and Security Standards, it is difficult for us to provide support around a number of topics until more clarity is provided on security.
There has been limited documentation available regarding the Information Security Standards and the lack of clarity around this is emerging as an implementation risk for the regime. Commonwealth Bank recommends that Data 61 devote additional resources towards developing standards in this area, provide additional time for review, and ensure that industry participants are able to submit separate feedback regarding the Standards for information security once they are released.
A key concern around information security is the ability for a consumer to provide fine grained consent to data being shared, and this has not been adequately reflected in the standards established to-date.
The regime should ensure that security standards define how to prevent known vulnerabilities associated with API implementations from being easily exploited through common attack vectors, such as phishing attacks. For this reason we continue to advocate for a decoupled authentication framework, as opposed to redirection frameworks from uncontrolled devices, to re-enforce safe practices and help protect consumers.

Banking APIs

Commonwealth Bank is broadly supportive of the majority of the API definitions relating to accounts. Our primary concerns are around the scope of included data. We believe the current coarse-grained approach may lead to unnecessary over-sharing of sensitive data. For particular aspects of the standard, such as the implementation of individualised account objects and bulk data, we have technical concerns around the complexity which will result in a protracted delivery timeline. As such we suggest that they are pushed to a further version of the standards to accommodate this.
The product reference data API requires further assessment. Commonwealth Bank recommends Data61 continue to work collaboratively with the industry to understand how to best represent product in the regime and refine this API.
We also re-iterate our concerns about the inclusion of a direct debit payload as this data is not held by the bank. Finally, we have concerns around the potential leakage of Personal Information which is included in the payee payload.

Common APIs

Commonwealth Bank are not supportive of the current definition of the customer payload. We believe description and use cases of this API are not fit for purpose and could again lead to inadvertent data leakage. We recommend the deprecation of this API in favour of an amendment to the accounts payload, and use of the OAuth 2.0 UserInfo service.

Additional Recommendations

  • Testing
    • The Commonwealth Bank needs adequate testing standards to ensure we are building what is required for July. This must be included in version 1 of the Standards in December.
  • Reporting
    • The administrative endpoint is still a pending decision proposal on GitHub (28th July 2018). Clarity on reporting requirements is necessary so we have time to build the required capability in time for 1 July 2019 compliance.
  • Authorisation Flows
    • We understand that these proposals will be considered more fully in the information security working groups and welcome additional workshops to facilitate this discussion.
@bpaygroup

This comment has been minimized.

Copy link

bpaygroup commented Nov 23, 2018

BPAY is Australia’s leading payments scheme and operates for the benefit of more than 150 member financial institutions. In February 2018, the BPAY Group launched its new payment product, Osko by BPAY®, offered by more than 60 financial institutions including the four major banks. Osko® is the first product available on the NPP.

Feedback from BPAY Group, is as follows:

ExtendedTransactionData: Each overlay service for the NPP can define its own transaction data elements (eg: X2P1 may contain different data elements to X2P2). The ExtendedTransactionData element does not appear to provide the capability to identify which fields belong to which service type. Suggest that extension$type should be an object that is specific to the overlay service used, containing the data elements for that service.

For X2P1.01, the extension data should include the following fields to support the Osko product:

  • extendedDescription: the 280 character description associated with a payment
  • endToEndId: unique identification, as assigned by the initiating party (Payer), to unambiguously identify the transaction
  • purposeCode: code used to describe the underlying reason for the transaction

Note that endToEndId and purposeCode are not currently included as part of the extension data.

For X2P2.01 and X2P3.01, we would anticipate that the extension data for each will include a different set of fields to those used for X2P1.01. The data structures used for ExtendedTransactionData should support these different field sets for the different transaction types.

ExtendedTransactionData:payee has description: “Label of target PayID. Mandatory for an outbound payment”. Note that a transaction can be addressed to a BSB-Account (which is not a PayID). Would anticipate that the user entered account name would be used in this case, suggest description should be updated for clarity , eg: “the name assigned to the BSB/Account Number or PayID (by the owner of the PayID)”.

ExtendedTransactionData: should also have data element for PayeePayId (in addition to the payee field used for the name), that is populated in case where a PayID is used to address the transaction. This should also have a supporting field that identifies the type of the PayID used (PayeeAccount$Type).

PayeeAccount$Type enumeration: the enumeration values should be aligned with the NPP descriptions for aliases: email, telephone, ABN, organisation identifier. Currently listed in spec as: email, mobile, org_number, org_name.

ExtendedTransactionData:Service enumeration: the valid value is currently listed as “X2P1.01”. This should be lowercase “x2p1.01” to correspond with the NPP definition.

TransactionDetail: does not provide any fields that allow identification of the transaction type, other than if it is an NPP transaction. Should have capability to identify type of transaction for all types, eg: Direct Entry, BPAY Payment, Osko Payment, Osko Request, etc. Also, TransactionDetail also does not contain any elements that allow identification of the payee for these transaction types (eg: BSB-Account, BPAY Biller Code & CRN). Consideration should be given to adding support for additional transaction types and their corresponding data elements to TransactionDetail (or potentially ExtendedTransactionData as extensionTypes).

TransactionBasic:Description & TransactionDetail:Description: suggest further clarifying the expectations around what will be in the Description field, and its potential relationship with other description fields that exist (eg: ExtendedTransactionData:ExtendedDescription). For example, for an NPP transaction is the expectation that these fields will both contain the same value?

@AmexAUopenbanking

This comment has been minimized.

Copy link

AmexAUopenbanking commented Nov 23, 2018

American Express Australia has the following feedback in relation to the draft standards in addition to the questions and comments raised during the working group sessions.

General Questions:
Many of the fields specified in the Standards are marked as optional or not mandatory to provide. American Express feels that to enable more robust usage of the Open Banking capability that unless no data is held for a particular data element that the standard should align to the wider regulations and ensure that more data elements should be made mandatory to supply to a data recipient.

To assist with resource and capacity planning will there be a draft character limits placed on each field or are all fields assumed to have no fixed character limit?

Transactions

Foreign Exchange rate used for a transaction is an important data element that is not currently included in the Standard. American Express's position is that this should be included as a transaction level data element.

For transactions that are not Institution to Institution but follow a merchant to consumer model the Standard should clearly define which data element should carry the merchant name and details for consistency across users

Some edge cases for certain transactions types occur, in situations where charges are presented late (up to 6 months) or disputed transactions are suspended on a customers account certain mis-match in date and time of transaction type (Pending/Posted) may occur. These should be added to the test cases when testing the robustness of the Standard after the next draft release.

Account

The data holder will attempt to mask any PII known to be held when being passed however for customer input fields such as NickName the Standard should specify that once consent is obtained the data will be passed as is without further investigation or masking if customers choose to enter PII in fields where they should not.

MaskedAccountNumber field should be increased to the last 5 digits. Last 3 digits for American Express accounts are very common so last 4 digits would be the minimum to differentiate between cards held by a single consumer with American Expresses preference to display last 5 digits.

ProviderType element Standard should include Charge Card as distinct from CreditCard.

balance$type element Standard should include Charge Card as distinct from CreditCard.

Product

The Fee field should have an additional field to determine the frequency with which the fee type is charged (Monthly, Annually etc.)

ProductDiscount - Open question on if this element should be used to pass data on non dollar discounts and acquisition offers such as points bonuses etc.

ProductFeature The valid list of types documented only cover a small subset of features available, an additional field should be defined to enhance the information passed in this field.

American Express hopes to continue to provide feedback and participation in the sessions and looks forward to the next revision of these standards.

@UltradataOpenBanking

This comment has been minimized.

Copy link

UltradataOpenBanking commented Nov 23, 2018

Ultradata would like to thank Data61 for the open process associated with the creation of the Data Standards and has the following feedback in relation to the draft CDR standards.

Consent / Authentication / Authorisation

  • Should an authorisation become null and void if the operational arrangement of the customer changes? For example, if the customer becomes a joint account holder or signatories change on a business entity? This is not currently accommodated.
  • Are there plans for APIs to access authorisation data from a Data Holder or for APIs to access consent data from a Data Recipient? Discussion in the CX workshop highlighted the benefit of supporting aggregated consent/authorisation management to simplify consumer access.
  • Are there plans for APIs to update (for example, switching from basic to detailed access to customer data) authorisation data from a Data Holder? Alternatively, is this expected to be achieved by first rescinding consent and then cycling through the consent / authentication / authorisation process again? If so, this would appear to impose unfortunate constraints on the CX.
  • What plans are there for Data Holders to notify Data Recipients that a consumer has rescinded access to their information? Will this be managed by an API that the Data Recipient must support?
  • What plans are the for the accreditation authority to notify Data Holders that a Data Recipient’s accreditation has been rescinded? Will this be managed by an API that the Data Holder must support?
  • The rules framework requires a Data Holder to report on API performance. What plans are there to publish APIs for Data Holders to report on performance against SLAs. Alternatively, is there an expectation that reports will be submitted in a prescribed format? If so, when will the requirements around this be available?

Scheduled payments / Standing orders

  • Ultradata concurs with the position from @BrianParkerAu and others. Being able to switch banking relationships from one financial institution to another would appear to be a core requirement and so being able to move scheduled payments in this process (notwithstanding the omission from the ACCC Rules Framework) would be highly desirable and arguably a higher priority than direct debits. Recognising the exigencies of the current timeline, Ultradata would support the introduction of APIs to for this purpose in a future edition of the standards.

Direct Debits

  • Conforming with the requirements of the APIs for direct debits is not an issue for Ultradata.

Transactional Data

  • Ultradata supports the proposal to include an “enable detail” flag when calling GET /accounts/{accountId}/transactions to reduce the need to make additional calls to get transaction detail from GET /banking/accounts/{accountId}/transactions/{transactionId}
  • Ultradata will be able to support the inclusion of transaction type, merchant name, merchant category code and BPAY biller details such as biller code, name and CRN. These data elements will allow for a much more precise categorisation of transactions and reduce the need for consumers to parse information from narratives.
  • Ultradata is able to support the requirements of the API with regards to the provision of pending and posted transactions.
  • Extended transaction data for NPP will likely include messages that contain private information from the consumer perspective. An additional authorisation scoping level might be needed to determine whether this information is shared with a Data Recipient. A separate API for extended remittance advice (RI) might be considered in a future draft. These types of data are likely to become richer (with larger payloads) over time as NPP expands, adding further weight to managing the retrieval of this information in a separate API.

Change cadence, obsolescence, versioning etc

  • The advice at recent workshops is that a more agile approach will follow with updates to the standards and these will be “small and often”. What will be the expectation on Data Holders and Data Recipients to implement these updates?

Error Handling

  • Ultradata’s view is that that a poor developer experience will result if only the http status code is returned without partial responses. This will likely lead to additional help desk cases from Data Recipients and unnecessary effort to diagnose root cause of issues when an informed error would suffice.

Organisation v customer v agent

  • Ultradata intends to support this by following the conventions of existing internet banking applications.
@JamesMBligh

This comment has been minimized.

Copy link
Contributor Author

JamesMBligh commented Nov 26, 2018

Thanks for the extensive feedback. The feedback period was extended due to specific requests. If there is outstanding feedback please send it via email to cdr-data61@csiro.au. Any email feedback will be posted on this thread for transparency.

The planned steps from here are as follows:

  1. Feedback will be collated and reviewed over the next few days
  2. Changes to the standards based on the feedback will be recommended internally and reviewed
  3. Changes will be applied over the weekend
  4. A summary of changes and issues that more feedback is requested for will be posted
  5. A new feedback period of two weeks will be opened next Monday

-JB-

@ConsumerDataStandardsAustralia ConsumerDataStandardsAustralia locked as resolved and limited conversation to collaborators Nov 26, 2018

@ellenbroad

This comment has been minimized.

Copy link
Contributor

ellenbroad commented Nov 27, 2018

Customer Owned Banking Association (COBA) submission received via email to the CDR mail box 22 November 2018
003_20181122 - COBA submission - Consumer Data Standards.pdf

@ellenbroad

This comment has been minimized.

Copy link
Contributor

ellenbroad commented Nov 27, 2018

Australian Retail Credit Association (ARCA) submission received via email to the CDR mailbox 22 November 2018.
024_ARCA Submission to Data61 draft Consumer Data Standards.docx

@ellenbroad

This comment has been minimized.

Copy link
Contributor

ellenbroad commented Nov 27, 2018

SunTec Business Solutions submission received via email to the CDR mailbox 22 November 2018.

032_CDR-Consumer Data Standards- Working Draft- Submission by SunTec Business Solutions- Nov 2018.docx

@ellenbroad

This comment has been minimized.

Copy link
Contributor

ellenbroad commented Nov 27, 2018

illion submission received via email to the CDR mailbox 22 November 2018.
035_23 11 18 illion - Data61 (Data Standards) Submission Final.pdf

@ellenbroad

This comment has been minimized.

Copy link
Contributor

ellenbroad commented Nov 27, 2018

Finder submission received via email to the CDR mailbox 22 November 2018.
037_Finder - Feedback on working draft of Open Banking standards.docx

@ellenbroad

This comment has been minimized.

Copy link
Contributor

ellenbroad commented Nov 27, 2018

Visa submission received via email to the CDR mailbox 22 November 2018.
038_2973_001.pdf

@ellenbroad

This comment has been minimized.

Copy link
Contributor

ellenbroad commented Nov 27, 2018

AGL submission received via email to CDR mailbox 26 November 2018.
039_AGL submission - Data61 API standard submission final.pdf

@ellenbroad

This comment has been minimized.

Copy link
Contributor

ellenbroad commented Nov 27, 2018

Law Council of Australia submission received via email to CDR mailbox 22 November
034_2018 11 23 - Consumer Data Standards.pdf
2018.

As of 9am 27 November, this is all submissions received via the CDR mailbox.

@ellenbroad

This comment has been minimized.

Copy link
Contributor

ellenbroad commented Dec 2, 2018

Apologies everyone - two submissions were missed in the CDR mail box. Uploading now.

Submission 031 from Xero Ltd received via email to CDR mailbox 23 November 2018.
031_ConsumerDataStandardsAustralia feedback to decision proposal 39 - Draft Standards.pdf

@ellenbroad

This comment has been minimized.

Copy link
Contributor

ellenbroad commented Dec 2, 2018

Submission 033 from CommsAlliance received via email to CDR mailbox 23 November 2018.

033_181123_CA Submission Draft API Standards_SUBMITTED (1).pdf

@JamesMBligh

This comment has been minimized.

Copy link
Contributor Author

JamesMBligh commented Dec 4, 2018

Hi everyone. I was hoping to get this out over the weekend but the quantity and, more importantly, quality of the feedback that was provided meant that it took a bit longer to process and get reviewed than I anticipated.

Please find attached here a PDF containing a summary of the feedback received that has also be categorised.
Draft Standards Feedback Summary - Feedback Cycle 1.pdf

The feedback that was policy or security related has been passed on to the relevant teams. The feedback that was related to the API standards has either been accepted or responded to.

I will now open two new issues. One specifically for product reference data - as this is clearly an area that needs specific focus - and one for comments against the standards as a whole. Comments or requests for clarification can be posted there.

-JB-

@ellenbroad

This comment has been minimized.

Copy link
Contributor

ellenbroad commented Dec 20, 2018

FinTech Australia was given an extension to the 23 November deadline. Submission 034 attached, received via email to the CDR mailbox Friday 7 December 2018.
Final 2 Fintech Australia _ Open Data WG_ Consumer Data Standards Submission_AU_Active01_904003094_2.DOCX.pdf

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.