search

ConsumerDataStandardsAustralia / standards-maintenance

This repository houses the interactions, consultations and work management to support the maintenance of baselined components of the Consumer Data Right API Standards and Information Security profile.
41 stars 9 forks source link

Include the processing timezone of the Data Holder in the CDR Register. #539

Open speedyps opened 1 year ago

speedyps commented 1 year ago

Description

The Banking Transaction API endpoints return postingDateTime, valueDateTime and executionDateTime as a DateTimeString (as per the CDR Specifications). This makes it difficult to identify what transactions fit into a specific day according to the data holder.

executionDateTime is excellent for showing the date and time the transaction physically occurred to the customer as per their time zone. There is no definitive way to know the time zone the data holder used when processing postingDateTime and valueDateTime for a transaction. It cannot accurately be inferred from the offset - especially when Daylight Savings is in effect.

An ADR cannot assume that a bank did the conversion in AEST or AWST. SISS has also seen records from a bank that are all just set to UTC - so it would appear their processing is done (for CDR purposes) in UTC.

For the clients we support at SISS, having the day the transactions have occurred according to the data holder is essential, especially when people try to compare data on the screen to their online banking or bank statements.

Area Affected

CDR Register APIs

CDR Register Schema

Change Proposed

Add a processingTimeZone ( such as per the tz database) as part of the RegisterDataHolderBrand and DataHolderBrandSummary schemas, which are then returned via Get Data Holder Brands and Get Data Holder Brands Summary accordingly.

perlboy commented 1 year ago

All these dates are RFC3339 and therefore have a timezone which is meant to be when the transaction landed on the source system. It is irrelevant what the timezone provided actually is because you can always convert such things to the local time. The only reason a holder would be non-compliant is if they are incorrectly transforming to a timezone'd time incorrectly or incorrectly recording it. Just because a bank is using UTC doesn't mean it is wrong if they have converted from local time to UTC correctly.

That isn't a Standards issue, it's a Holder compliance one. Advertising a "processing time" is simply working around Holder non-compliance. I'd probably recommend reaching out to the Holders in question if you have good evidence it is definitely wrong when transformed and, if that doesn't work, opening an incident on the CDR Service Portal.

speedyps commented 1 year ago

@perlboy, even if the banks all comply with RFC3339 this doesn't necessarily help in determining if the day the transaction occurred according to the bank. If Daylight Savings is in play, there could be uncertainty. We will have the transaction with offset in UTC, and we can discern the transaction in our server's timezone (and its Daylight savings status). We cannot with 100% certainty identify the bank's processing day, although we can make a guess.

Of course, we can learn by observation over time, but our preference would be to be definitive.

Until recently, many transactions from many banks were returned without an offset. Recent releases appear to have addressed this with some banks.

nils-work commented 2 months ago

Similar to #173, as this issue could be relevant to changes being considered in MI19 (#636), is it still a valid concern?