Service field in the Get Transaction Details API

[NationalAustraliaBank]

Request For Clarification

NAB request that @CDR-API-Stream label this issue as Urgent.

As per the Consumer Data Standard, the Service attribute within the Get Transaction Detail API has an Enum value of X2P1.01.
https://consumerdatastandardsaustralia.github.io/standards/#tocSbankingtransactiondetail

Whilst X2P1.01 is the only Enum value listed in the Standard, NPP comprises of other types (eg. SCT).

This has been raised in Github previously (see references below), the standard has not been updated to reflect that SCT and X2P1 Enum values are all valid service types under NPP (and all the current / historical versions eg. X2P1.01, X2P1.02, post June -> X2P1.03).

ConsumerDataStandardsAustralia/standards#28
ConsumerDataStandardsAustralia/standards#41

NAB’s interpretation is that for the Get Transaction Details API, we will return extended data for any NPP transaction, whether it is SCT or X2P1 (regardless of the version).

[CDR-API-Stream]

This issue has been marked as urgent at the request of @NationalAustraliaBank.

[CDR-API-Stream]

Hi @NationalAustraliaBank, it is understood that the NPP standards have been updated since the Consumer Data Standards first published NPP supportability. Can you assist in describing any impact to your July implementation dates.

Other than the support for the new NPP extensionUType and service values, what other changes are proposed, if any. Or does the current CDS data model support the new NPP requirements?

It would also be helpful to understand how any of the other banks are dealing with this in respect to their implementations for July 2020.

[YashLakhotia]

Issue is same as [https://github.com//issues/181]

[WestpacOpenBanking]

Westpac would need to complete new build in order to provide responses for additional enumerated values and we do not support this change as an urgent request. We are supportive of adding these fields to the schema at a later date through the normal change request process.

[anzbankau]

ANZ currently aligns to the standards and any change may incur build impact.
ANZ is happy to accept this as a standards maintenance issue and progress the normal maintenance cycle.

[CDR-API-Stream]

Hi all. Thank you to everyone who has provided feedback so far. The DSB held a review session of this issue today with participants that have impacted July 2020 go-live builds. This session included all major banks and ADRs. A summary pack is available here.

The discussion reviewed the implementation of all banks and expected handling by ADRs. This proposed change identified build impacts for banks and breaking changes for the data standards. This change is not supported at this time for July builds. It was agreed to prioritise this change through the data standards maintenance cycle.

Changes proposed

This change and #181 will be prioritised in the next banking maintenance iteration.

Before the DSB provides a recommendation to the chair on this issue it is requested that confirmation be provided by the impacted participants that the change proposed will not adversely impact their ability to implement for July.

^^ @pcurtisrab, @brett-frollo, @WestpacOpenBanking, @commbankoss, @NationalAustraliaBank, @anzbankau, @YashLakhotia

[NationalAustraliaBank]

NAB’s current build for 1 July will return extended data for any NPP transaction, whether it is SCT or X2P1 (regardless of the version).
There is build impact to NAB to filter transaction detail to only X2P1.01.
Discussions with the ADRs (RAB and Frollo) indicate that there is no issue to them if NAB returns other enumerated types (ie. SCT and more recent versions of X2P1).
Based on this, NAB does not intend to modify its 1 July build to filter transaction details to only X2P1.01.

[CDR-API-Stream]

Hi @NationalAustraliaBank, for questions of conformance this would be best that you pose them to the ACCC.

Support for the new NPP service types will be consulted on in the next maintenance iteration.

[commbankoss]

Commonwealth Bank agrees with CDR-API-Stream's proposal and understands that there is no impact to the July 1 deliverable as "This change and #181 will be prioritised in the next banking maintenance iteration."

[CDR-API-Stream]

This change request is being considered in the data standards 4th maintenance iteration. As discussed on the kick-off call yesterday, the DSB would welcome any analysis and feedback from data holders whether SCT, X2P1.02 and X2P1.03 data could be expressed under the extended payload schema currently defined in the data standards or whether there are material data and schema changes or other definition changes introduced in the NPP documentation that need to be considered.

[CDR-API-Stream]

Whilst this change request is being considered within the 4th maintenance iteration, as requested above, the DSB would welcome any further analysis from @NationalAustraliaBank or other Data Holders regarding the NPP changes to progress this issue.

[CDR-API-Stream]

Noting @NationalAustraliaBank's response here, further feedback and analysis from other Data Holders is requested to progress this change request.

[commbankoss]

Commonwealth Bank is supportive of adding these values to the schema for a future date.

[CDR-API-Stream]

Hi @NationalAustraliaBank, Maintenance Iteration 10 commences next Wednesday. This issue has been added to the backlog. The first meeting will involve discussion of which change requests should be prioritised for consultation this iteration. I'd encourage you to participate in that backlog grooming and prioritisation process.

[NationalAustraliaBank]

Hi @CDR-API-Stream ,
As per the discussion in the maintenance iteration meetings, we reached out to our SMEs in the payments space and via them the NPPA. We've concluded that since the analysis between the service overlays, current and upcoming in the NPP space are under the ambit of an independent authority (NPPA), it is best that it should be them who are given the opportunity to guide us on the same.
As a part of these discussions, it was raised with Paul Nicholas from NPPA who agrees it’s something that needs to be arranged between DSB and NPPA.

Paul is okay'ed for us to pass on his contact details as the appropriate NPPA contact.

Paul Nicholas
NPP Technology & Delivery Manager
NPP Australia Limited

I am not adding his email and mobile number here, but he has passed the same to us for sharing with DSB. Please do let us know the appropriate channel where we can provide the same. Thanks so much,

[CDR-API-Stream]

This issue was discussed in the Maintenance Iteration 11 call as part of finalising the list of iteration candidates. Because there are other breaking change requests affecting the same API endpoint as this issue it was agreed to consider this issue from Maintenance Iteration 12 onwards.

[nils-work]

This issue was discussed in the Maintenance Iteration (MI) call on 9 Aug 2023.

The DSB will review this issue (and related #181) and aim to provide an update in the next MI call.
Further comments or feedback on this area of change would be welcome.

[CDR-API-Stream]

This issue was discussed on the Maintenance Iteration call held on 23 Aug 2023. It was agreed this would be incorporated into Decision Proposal 324: Holistic uplift for NPP data sharing.

[nils-work]

A proposal related to this issue has been provided in issue #664 - New Enums for Voluntary disclosure of additional service overlays

[nils-work]

Closing as resolved through #664