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
Addition of enums for extensionUType and service in extendedData - BankingTransactionDetail #181
Comments
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. |
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. |
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. |
This proposal only highlights the pollution that will continue to happen within
While I agree with @YashLakhotia's requirement to ensure these new NPP message types I note that:
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. |
The recent maintenance iteration call discussed this issue.
|
Hi @CDR-API-Stream The mandatory service value of "X2P1.01" seems to imply that it's only intended for NPP transactions. Please confirm? |
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. |
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. |
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
The text was updated successfully, but these errors were encountered: