Addition of enums for extensionUType and service in extendedData - BankingTransactionDetail

[YashLakhotia]

Description

As the NPP Scheme has progressed over the years now, new versions have been introduced for Single Credit Transfers (SCT) as well as Overlay Services like OSKO (X2P1). The current API documentation has only one enum value in the BankingTransactionDetail. Enums as documented: Property | Value | CDR enum status extensionUType | x2p101Payload |  Existing service | X2P1.01 |  Existing

Area Affected

API endpoints: GET /banking/accounts/{accountId}/transactions/{transactionId} Schema: BankingTransactionDetail

Change Proposed

Addition of following enums values in the BankingTransactionDetail schema:

Property | Value | CDR enum status

extensionUType | x2p101Payload |  Existing extensionUType | x2p102Payload | TBC extensionUType | x2p103Payload | TBC extensionUType | sct01Payload | TBC extensionUType | sct02Payload | TBC extensionUType | sct03Payload | TBC

service | X2P1.01 |  Existing service | X2P1.02 | TBC service | X2P1.03 | TBC service | SCT.01 | TBC service | SCT.02 | TBC service | SCT.03 | TBC

[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.

[NationalAustraliaBank]

NAB supports the recommendation to extend the transaction detail payload as proposed by @YashLakhotia. We have validated that there are no consumer facing changes to the payload across the current supported versions, though we recommend an additional change to make the extendedDescription optional, to align with the current NPP standards.

For future iterations, particularly as the CDR is extended to include write capability, the DSB should collaborate closely with NPPA to understand industry requirements as they arise and to align on timeframes as new versions are introduced.

[commbankoss]

Commonwealth Bank supports @YashLakhotia's proposal to add additional enum values in the BankingTransactionDetail schema. We also support @NationalAustraliaBank's suggestion for the DSB to collaborate with the NPP on evolving industry requirements.

[perlboy]

This proposal only highlights the pollution that will continue to happen within BankingTransactionDetail. I reiterate my comments made July 2019:

BankingTransactionDetail does not appear to sufficiently allow for attributes of even existing payment types such as: BPay: BPAY reference id Traditional payments: BSB, Account Number etc International payments: Routing codes, payment instructions, intermediaries etc. NPP: Currently only pain.a09.001.01 exists but it is likely this sub-object itself would need an NPPuType Internal Transfers: Source/Destination account (probably using the UUID of the Accounts in question) ISO20022 Payments: Current consultation is being conducted by the RBA for mandatory adoption As can be seen through the collapsing of these structures there is an increasing amount of fuzziness for a recipient developer attempting to clearly identify and present transaction information. Such different views are a regular use case within existing internet banking platforms. That is to say that BPAY transactions usually have a different presentation view than direct transfers which have a different presentation view to those which utilise card providers such as VISA or Mastercard.

While I agree with @YashLakhotia's requirement to ensure these new NPP message types I note that: 1) Much of NPP is based on ISO20022 message formats so there is potential for overlap here 2) Technically not every message on NPP is guaranteed to be an actual transaction (it just happens to be, in non error conditions, that way right now) 3) The proposal requests an enumeration but does not provide a proposed payload for each message type

As outlined in July 2019, normalisation of this structure so that the parent level only contains universally shared components is a far more sustainable way of introducing new payments types in the future.

[CDR-API-Stream]

The recent maintenance iteration call discussed this issue.

• It is understood based on feedback from community members in the iteration call and feedback from the NPPA that eftpos/BPAY service overlays X2P2 and X2P3 have been delayed. Proceeding with this change without sufficient informed data around the schemas for X2P2 and X2P3 data would be premature.
• The DSB is seeking feedback from Data Holders whether there is any production support for newer service overlays at this time

[da-banking]

Hi @CDR-API-Stream Can you please clarify if "Get Account Detail" is intended to only be used for NPP transactions? How about BSB/Account No. based transactions?

The mandatory service value of "X2P1.01" seems to imply that it's only intended for NPP transactions. Please confirm?

[CDR-API-Stream]

Hi @da-banking that is correct, transaction detail is currently only intended for NPP's X2P1.01 (Osko) overlay service. It has been suggested that transaction detail be extended to describe other payment schemes in the same manner as X2P1.01. The DSB would welcome a change request to that effect if the community saw benefit.

[CDR-API-Stream]

The outcome of this issue has been approved by the Data Standards Chair. No change was recommended until such time that both X2P2 and X2P3 overlays are defined and utilised by data holders.

This issue will be closed accordingly but can be re-opened or a new issue raised at such time.