markskript
commented
3 days ago Skript supports this change, with the added benefit in that it will bring some DHs into alignment with the standards where they have already started providing these enum's. That will allow us to remove custom DH-specific workaround code from our solution.
Description
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 • OSKO (X2P1) is the main overlay service offered under the New Payments Platform. • The business service version (eg X2P1.XX) has incremented since original release and is currently operating under version four (eg X2P1.04). • At an industry level, there’s an average of 100m transactions cleared/settled per month. o This would translate to 200m transaction records per month that are restricted as a result of the current Open Banking schema. o Transaction growth is averaging +6.5% MoM increase • We can also refer to the published RBA statistics (Direct Entry and NPP – Original Series – C6.1) for historic statistics o This shows us (per CCDEPNPPON) that since inception, the industry has processed there has been 3.95b OSKO payments and currently accounts for 75% of total reported payments cleared under NPP o This would be similarly multiplied for the context of Open Banking as 7.9b transaction records could not be shared as a result of schema failing to keep pace with the payment clearing stream This issue would also be observed for the ‘more recent’ business services, including: SCTXBRDR - International payments cleared/settled via NPP (as an alternative to RTGS) CATSCT - Salary, tax and superannuation payments
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, X2P1.03, X2P1.04, SCT.04 etc). https://github.com/ConsumerDataStandardsAustralia/standards/issues/28 https://github.com/ConsumerDataStandardsAustralia/standards/issues/41 Service field in the Get Transaction Details API · Issue #229 · ConsumerDataStandardsAustralia/standards-maintenance · GitHub
Please Note: Additional Enums should not cause any disruption to he current implementation of the other data holders as these Enums should be considered as voluntary data disclosure.
Intention and Value of Change
Currently, the most recent relevant transactions ERI of value $8b are not available in the CDR ecosystem. These could go a long way in improved transaction classification and reconciliation. this change will make this valuable data to be potentially available to the ADRs while not impacting the current implementation for the data holders.
Area Affected
x2p101Payload object under GetTransactionDetails
Change Proposed
NAB proposes to offer additional Enums for the newer service overlays which could be considered as voluntary disclosures by those data holders who choose to share this information and the current implementation of other data holders should have no impact. In BankingTransactionDetails • extensionUType enum value to be updated from “x2p101Payload” to “overlayServicePayload” • x2p101Payload object name to be renamed to “overlayServicePayload” • service enum to be uplifted to cover all the services and versions, e.g. X2P1.01, X2P1.02, X2P1.03, X2P1.04, SCT.04 etc.