Banking transaction data quality

[nils-work]

Description

As a follow-up to this comment on issue #636 - Remove BankingTransactionDetail and incorporate extendedData into BankingTransaction, this issue has been raised to capture further commentary and examples from the community for potential guidance or Standards aiming to address concerns related to transaction data quality in certain circumstances.

The following issues discuss related topics but comments specific to these should be directed to the respective issue where possible:

• #229 - Service field in the Get Transaction Details API
• #324 - [Placeholder] Decision Proposal 324 - Holistic uplift for NPP data sharing
• #656 - A status of POSTED should indicate the final update for a transaction

Also for reference on data quality in general:

• Data Quality in the Consumer Data Right: Findings from Stakeholder Consultation
• Consumer Data Right compliance review of product reference data: ACCC observations

Intention and Value of Change

To collate relevant details to assist with the potential development of guidance or Standards.

Area Affected

• Get Transactions For Account
• Get Transaction Detail
• Associated guidance

Change Proposed / Feedback sought

The following concerns have been raised in relation to transaction data quality under certain circumstances, which may depend on the particular implementation, product/account or transaction type.

Please add a comment to clarify or raise additional concerns or queries, to highlight the level of impact to use cases, or to suggest potential solutions.

1. Transaction description or other text fields including multiple double-spaces, or with leading and/or trailing spaces.
2. Multiple fields concatenated into the description using different conventions, sometimes without spaces, making consistent extraction of valuable detail difficult.
3. description value being an empty string or a type of label (such as OTHER TRANSACTION, OSKO PAYMENT, ANNUAL FEE) rather than other detail that may be available and valuable to use cases supporting the consumer.
4. description detail provided in the reference field, making reconciliation against a reference (perhaps sourced through other means) difficult.
5. Values in the reference field being masked, making reconciliation difficult.
6. Transaction reference is available in other channels but not in CDR, or it is provided in a different field in CDR.
7. endToEndId or extendedDescription detail provided in the reference field, but it doesn't match the reference available in other channels.
8. extendedDescription values not matching what is available in other channels (may be the text "null", an empty string, or just different text).
9. Transactions not following type guidance, e.g., PAYMENT instead of TRANSFER_INCOMING, and inconsistent usage within and across Data Holders.
10. The transaction type value being different for the same transaction, depending on whether it was sourced from the Get Transactions or Get Transaction Detail endpoint.
11. ...DateTime values with invalid or inconsistent timezone information, particularly where a default time value (00:00:00) is provided to imply that the time was unavailable at source and only the date (corresponding to that default time and timezone conversion) is applicable ¹, ², ³.
12. A postingDateTime value in the future.
13. Transaction payee value missing or masked, but full value available in other channels.

Potential solutions

1. Require double-spaces in the description or other fields to be replaced with single spaces and leading or trailing spaces trimmed to improve readability and consistency in display.
2. Consider whether additional fields in the Standards may be helpful in providing more standardised data, rather than Data Holders concatenating values (possibly following different conventions) into a small number of fields.
3. Extend the list of transaction types and provide additional guidance on usage.