Open NationalAustraliaBank opened 2 months ago
markskript
commented
2 months 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.
CDR-API-Stream
commented
1 month ago Hi @NationalAustraliaBank this is an important change to progress so thank you for raising it.
Given that transaction data is designated in the CDR rules, this would be a mandatory binding standard, not a voluntary standard.
Schedule 3, section 1.3 (3) defines transaction data as required data.
transaction data, in relation to a particular transaction (a) means information that identifies or describes the characteristics of the transaction; and (b) includes: (i) the date on which the transaction occurred; and (ii) any identifier for the counter-party to the transaction; and (iii) if the counter-party is a merchant—any information that was provided by the merchant in relation to the transaction; and (iv) the amount debited or credited pursuant to the transaction; and (v) any description of the transaction; and (vi) the “simple categorisation” of the transaction (for example, whether the transaction is a debit, a credit, a fee or interest).
CDR-API-Stream
commented
1 month ago Further to the identified service overlay types raised by @NationalAustraliaBank, the DSB has analysed the NPP service overlays in additional detail.
The NPP architecture supports service “overlays” that can be provided on top of the NPP basic infrastructure. These overlay services define the data and messaging formats specific to the overlay. As noted by @NationalAustraliaBank this change proposal, considers:
The Osko service overlay is currently incremented to version 5. These versions are updated when there are breaking changes to the NPP API interface contract. No changes to the X2P1 payment instruction have been identified, and thus no changes to ResponseBankingTransactionById extendedData schema are anticipated apart from the change in version of the X2P1 service.
The way that extended transaction data is currently represented in the Data Standards is to represent the combination of service overlay and overlay version as a separate object structure denoted by unique union types. Given there is no change to the X2P1 payload across the five versions of the X2P1 service and given all service overlays inherit from the same core payment initiation notification structure (based on ISO20022), a simplification of the extended payload structure is proposed.
Basic Single Credit Transfers (BSCTs)
Basic SCTs is the basic NPP business service that allows NPP participants to send payments over the NPP without an overlay. It is an individual transaction that will be cleared then settled. Because of the high degree of business service overlap between the SCT and X2P1 business services, Australian Payments Plus (AP+), who now operate the NPP, have earmarked the future augmentation of both the SCT and X2P1 services into a single overlay. This is likely to be the inclusion of SCT into the X2P1 business service. Whilst no future date has yet been set, the CDR rules have a requirement for banking Data Holders to share up to the previous seven (7) years of transaction history. As such, allowing Data Holders to share this transaction data remains relevant to the CDR.
Category Purpose Payments
NPP supports categorised payments for super, tax and payroll payments. These are largely similar to the other overlays in terms of data fields, however there are special usage and data requirements. This service helps third parties to instruct financial institutions on the purpose of the payment and priority. These payments are denoted by a specific purpose code and NPP guidance for representing additional information and additional reference information in the payment message, which can be presented to the payee. This can include more structured data elements or extended commentary in the payment from the employer, for example, “Adjustment pay for week ending 20/1/19” or “Commission payment for Quarter 1”, up to date details of hours paid, superannuation contributions or details relevant to the employee payslip.
For some category purpose payments like superannuation, these include additional consumer information including the superannuation provider identifier:
International Funds Transfers Instructions (IFTIs)
IFTIs are payments sent between an Australian bank and an overseas financial institution. They may pass through multiple Australian and overseas intermediary institutions on the way. An NPP payment may be used as the final leg of an 'inward' IFTI - that is, a payment originating overseas, sent through an NPP participant as an intermediary on the way to another NPP participant as the final destination. These payments are distinct from basic SCTs in that they incur additional obligations on the payer and payee participants and are defined by a separate service overlay.
Previous consultations and considerations
Previously banks have proposed extending transaction detail to cover more fidelity with respect to BPAY payments, particularly in respect to transactions on business accounts.
Presently it only supports detailed information for Osko payments. Changes raised, include:
Moving the BPAY information to its own extendedData object and cater more multiple BPAY biller payees Change Request 24: Relationship between BPAY fields and transactions is many to one, and Comment to Standards consultation 73
Extending transaction detail to support:
See Comment to Standards consultation 73.
See option considerations and comment here.
Data Holders might achieve further utility of the extendedData schema if they could extend it for their own transaction service overlay schemes. These might be based on NPP basic infrastructure, but alternatively, they may be bespoke to the Data Holder’s services: for example, a digital wallet might offer rich extended data within their closed payment system.
Service overlays like Osko are represented by service overlay codes and the associated version of service overlay. e.g. X2P1.01 … X2P1.05 BSCT.01 … BSCT.05 CATSCT.01 IFTI.01
The following changes are proposed to Get Transaction Detail to accommodate the newer versions of the X2P1 service and the additional service overlays identified in this proposal. Two options are presented for how to represent the NPP service overlays.
Option 1: Support NPP overlays using a sub-object and NPP overlay union
This option extends the current pattern by defining a new payload object for each overlay service and version combination. This has the benefit that each service+version is easily distinguishable and it accounts for changes to the field members. The downside is that this approach results in a high degree of duplication.
In this option, extendedData might be represented as follows:
Enumerated Values
| Property | Value |
|---|---|
| extensionUType |
|
| service |
|
Example
"extendedData": {
"payer": "string",
"payee": "string",
"extensionUType": "x2p105Payload",
"x2p105Payload": {
"extendedDescription": "string",
"endToEndId": "string",
"purposeCode": "string"
},
"service": "X2P1.05"
}With this option, extendedData could also be extended to non-NPP extended data included Data Holder defined extensions.
Option 2: Change extended data to accommodate an inheritance model with a general structure [DSB RECOMMENDED]
Rather than introduce a new union object for each NPP service overlay and version, a common extended message format is defined. Whilst the NPP service overlays different in message requirements and purpose, the fields themselves are mostly common across the overlay types. With this option, the fields in the existing x2p101Payload are extracted out into a common nppPayload object which includes:
The benefit of this option is that is harmonises all NPP overlay services.
| In this option, extendedData might be represented as follows: | Property | Value |
|---|---|---|
| extensionUType | nppPayload | |
| service |
|
|
| serviceVersion | ExternalRef -- Version as defined by NPP |
Example
"extendedData": {
"payer": "string",
"payee": "string",
"extensionUType": "nppPayload",
"nppPayload": {
"extendedDescription": "string",
"endToEndId": "string",
"purposeCode": "string"
"service": "IFTI",
"serviceVersion": "01"
}
}With this option, extendedData could also be extended to non-NPP extended data included Data Holder defined extensions.
No Data Language standards are proposed. Banking transaction data language is currently defined by the Transactions data cluster[1] and is assumed to be general enough in nature to cover the extended transaction data.
Instead it is proposed that transaction data is authorised and disclosed using the existing "bank:transactions:read" scope.
Transaction data is already covered by existing NFR Data Standards. No changes to the existing NFRs are proposed.
No changes are proposed for metrics data reporting. It is expected that the changes proposed are sufficiently represented in the existing Get Metrcis v5 payload.
No changes are proposed for error handling. It is expected that the changes proposed are sufficiently represented by the existing Error Handling codes.
markskript
commented
3 weeks ago Note that in the past 14 days we have seen a SHARP increase in the service code "x2p1.03" being provided in production by one particular data holder. I would suggest that this change request needs to be expedited as that DH is currently (and has been for quite a while now) non-compliant with the standards.
markskript
commented
3 weeks ago Of the options above, Option 2 would be our preference - but our preference is for the quickest resolution based on feedback from Data Holders.
CDR-API-Stream
commented
1 week ago Obligation date As discussed in the MI 21 meeting it is proposed that Option 2 be progressed with an FDO of FY25 # 3 -14th July 2025.
This change would be a breaking change which would introduce a new V2 version of the Get Transaction Detail API.
Service versions It was also discussed that serviceVersion needs to be defined as an ExternalRef rather than an enumerated type to ensure the endpoint is not versioned each time a new service overlay version is introduced to the NPP infrastructure. A Data Holder did raise a consideration regarding lagging compliance if Australian Payments Plus introduced a newer version of any NPP service overlay. This is considered an implementation issue where the Data Standards would remain silent. Data Holders would be required to provide required data in accordance with the CDR rules and could do so in a manner that is inline with any upgrades to their payments systems as new versions are supported.
Additional NPP service overlays Any new NPP service overlays not defined by this change request proposal would need to go through future change requests and endpoint versions unless the service overlays were also considered External References. At present, option 2 proposes this list is a managed enumerated set of overlays.
Additional consumer data defined within NPP service overlays Further, additional schema extensions for superannuation identifiers and extended payer/payee information shall be progressed in a separate change request for consideration in MI 22.
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.