Missing features

[BrianParkerAu]

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.

[davidthornton]

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.

[JamesMBligh]

@BrianParkerAu, as we are managing a structured feedback approach it would be helpful to put these comments in the open thread on issue 39 rather than creating a new issue. Your feedback is most welcome and we would love to see it added to the existing thread.

I will lock this issue now so that commentary isn’t bifurcated.

-JB-