Closed markskript closed 3 weeks ago
perlboy
commented
1 month ago I don't really understand the problem here, if Holders are "defaulting" a time to UTC and it is inaccurate they are disclosing incorrect data and this is a compliance issue. You should open an incident on those 13 brands to come back with an answer or they fix their default to provide a more suitable timezone. Any Standards solution here is janky and penalises those complying.
markskript
commented
1 month ago @perlboy fully agree! We have raised ticket with one DH and they have suggested the root cause of the issue is a lack of guidance in the standards around this area - which is what I was hoping to address here.
I also have cases open and will be using the feedback from ADR's around whether they have custom-workarounds in place to drive those further with the ACCC
perlboy
commented
1 month ago What a load of rubbish, the Standard is very clear it MUST be provided as an offset to UTC:
Custom workarounds are definitely in play at a bunch of ADRs but Biza does not and never will do such things. If you want to let me know which Holders you've found to be non-compliant we will verify and open incidents.
nils-work
commented
1 month ago markskript
commented
3 weeks ago The change proposed in #173 appears to not be feasible without changing the definition of the postingDateTime field to allow a date-only value.
As such, based on the feedback above and my understanding, I believe the following is true
Do people agree?
If this is purely a compliance issue, the fact that we are seeing it across multiple data holders indicates that it is likely a standards-interpretation issue as well, hence I think there is still value in making a standards change, or at least an official guidance, on how to handle this scenario from the DH perspective.
nils-work
commented
3 weeks ago Hi @markskript (and @josh3n, as you have noted similar concerns)
I've provided some examples below to support discussion on this topic.
Current guidance states that a Data Holder may provide a default time value such as 00:00:00 in a DateTimeString field to imply that a time is not available.
If I understand the concern raised in this issue, it can be challenging for a Data Recipient to correctly determine when a 'default' time has been supplied. This is important when deciding whether the time can be displayed to the consumer, or if only the date is accurate. In some cases it may not be clear if the the date that the default time is associated with should be converted to another time zone or not.
I think these issues may be demonstrated in the tables below, but are you able to indicate which versions are problematic and which may be preferable in your view (if any)?
The 'converted' AEST and AWST values are identical in both tables. The raw values are provided in Z/+00/UTC and +10/AEST which seem to be common formats.
Examples where the Data Holder is providing values in the Z or +00 (UTC) offset -
# |
Value | +10/AEST/Sydney | +08/AWST/Perth |
|---|---|---|---|
| A0 | 2024-08-21T12:22:17Z |
Wed, 21 Aug 2024, 10:22:17pm | Wed, 21 Aug 2024, 8:22:17pm |
| A1 | 2024-08-21T14:00:00Z |
Thu, 22 Aug 2024, 12:00:00am | Wed, 21 Aug 2024, 10:00:00pm |
| A2 | 2024-08-21T16:00:00Z |
Thu, 22 Aug 2024, 2:00:00am | Thu, 22 Aug 2024, 12:00:00am |
| A3 | 2024-08-22T00:00:00Z |
Thu, 22 Aug 2024, 10:00:00am | Thu, 22 Aug 2024, 8:00:00am |
| A4 | 2024-08-22T04:00:00Z |
Thu, 22 Aug 2024, 2:00:00pm | Thu, 22 Aug 2024, 12:00:00pm |
| A5 | 2024-08-22T10:12:05Z |
Thu, 22 Aug 2024, 8:12:05pm | Thu, 22 Aug 2024, 6:12:05pm |
| A6 | 2024-08-22T14:00:00Z |
Fri, 23 Aug 2024, 12:00:00am | Thu, 22 Aug 2024, 10:00:00pm |
| A7 | 2024-08-22T16:00:00Z |
Fri, 23 Aug 2024, 2:00:00am | Fri, 23 Aug 2024, 12:00:00am |
| A8 | 2024-08-22T22:48:22Z |
Fri, 23 Aug 2024, 8:48:22am | Fri, 23 Aug 2024, 6:48:22am |
| A9 | 2024-08-23T00:00:00Z |
Fri, 23 Aug 2024, 10:00:00am | Fri, 23 Aug 2024, 8:00:00am |
Examples where the Data Holder is providing values in the +10 (AEST) offset -
# |
Value | +10/AEST/Sydney | +08/AWST/Perth |
|---|---|---|---|
| B0 | 2024-08-21T22:22:17+10:00 |
Wed, 21 Aug 2024, 10:22:17pm | Wed, 21 Aug 2024, 8:22:17pm |
| B1 | 2024-08-22T00:00:00+10:00 |
Thu, 22 Aug 2024, 12:00:00am | Wed, 21 Aug 2024, 10:00:00pm |
| B2 | 2024-08-22T02:00:00+10:00 |
Thu, 22 Aug 2024, 2:00:00am | Thu, 22 Aug 2024, 12:00:00am |
| B3 | 2024-08-22T10:00:00+10:00 |
Thu, 22 Aug 2024, 10:00:00am | Thu, 22 Aug 2024, 8:00:00am |
| B4 | 2024-08-22T14:00:00+10:00 |
Thu, 22 Aug 2024, 2:00:00pm | Thu, 22 Aug 2024, 12:00:00pm |
| B5 | 2024-08-22T20:12:05+10:00 |
Thu, 22 Aug 2024, 8:12:05pm | Thu, 22 Aug 2024, 6:12:05pm |
| B6 | 2024-08-23T00:00:00+10:00 |
Fri, 23 Aug 2024, 12:00:00am | Thu, 22 Aug 2024, 10:00:00pm |
| B7 | 2024-08-23T02:00:00+10:00 |
Fri, 23 Aug 2024, 2:00:00am | Fri, 23 Aug 2024, 12:00:00am |
| B8 | 2024-08-23T08:48:22+10:00 |
Fri, 23 Aug 2024, 8:48:22am | Fri, 23 Aug 2024, 6:48:22am |
| B9 | 2024-08-23T10:00:00+10:00 |
Fri, 23 Aug 2024, 10:00:00am | Fri, 23 Aug 2024, 8:00:00am |
markskript
commented
3 weeks ago Hi @nils-work
Here is the current guidance
For example, a DH unable to supply a time value could choose to supply 00:00:00, and the full DateTimeString value, in AEST, might be: 2024-07-30T00:00:00+10:00
What I am seeing with one DH in particular though, is 00:00:00 in UTC is being added. i.e. 2024-07-30T00:00:00 (i.e. with NO timezone offset). It's like they saw the first part of the guidance, but didn't see the second part with the example that reminded them that 00:00:00 should only be presented with the appropriate offset.
So what I'm seeing is the A3 example above in scenarios where the DH doesn't have a time component, which to me, does not match the guidance, resulting in incorrect data which breaches the standards.
Thanks, Mark.
nils-work
commented
3 weeks ago As noted above and in the Standards, a DateTimeString value always requires an offset to be specified.
If there are concerns with this requirement, participants are welcome to raise a Change Request.
markskript
commented
3 weeks ago We discussed this on the Implementation call today, and the general consensus is that the standards are clear here. If a DH is providing a posting date, and they don't have a time stored, then providing a static value of "00:00:00Z" will be interpreted as midnight UTC. If the transaction is not being posted at midnight UTC (i.e. 10am AEST) then the data provided is incorrect and needs to be addressed as a compliance issue.
Happy to close this standards change out as not being required.
Description
We have identified at least 13 brands within the banking ecosystem that do not appear to store a time component for the date/time of when a transaction is "posted". Since the the posting_date_time field is defined as a DataTimeString, this is forcing Data Holders to provide a "default" time value just to ensure their response is standards compliant.
The standards currently lack guidance as to how to correctly default the time component of this field. We have surveyed the 13 brands mentioned above and see the following interpretations when the time component is obviously being "defaulted".
Default to "14:00:00", with no timezone offset (so interpreted as UTC). If the ADR chooses to display this value to the consumer converted to AEST then it will appear as midnight on the next day, which would be correct, but only if the ADR/consumer has chosen to view date/time values in AEST.
Default to "00:00:00", with no timezone offset (so interpreted as UTC). If the ADR chooses to display this value to the consumer converted to AEST then the consumer will see a confusing time component, but the date will be correct. This option is fine if the ADR is only choosing to display the "date" part of the field.
Default to "12:00:00", with no timezone offset (so interpreted as UTC). We don't see how the ADR could display this in a way that isn't confusing to the consumer once converted into a local timezone.
None of the above approaches are great. Option 1 is probably acceptable, but only if the consumer/ADR have chosen AEST to display the data.
Intention and Value of Change
We propose to update the standards to provide specific direction for data holders that do not currently have a time component for the postingDateTime field. This will remove ambiguity and ensure ADR/consumers do not have to implement DH-specific-interpretations.
Area Affected
https://consumerdatastandardsaustralia.github.io/standards/#cdr-banking-api_schemas_tocSbankingtransaction
Change Proposed
We see a number of options and are keen to obtain guidance from the community to decide which way to go forward
Option 1 - update the standards with the following addition to the description of the postingDateTime field
"If not time component is stored by the DH then a value of 00:00:00+10 should be appended to represent midnight on the day of settlement in the AEST timezone".
Option 2 - update the standards with a new DateString field and change the definition of postingDateTime
This would be a breaking change and require a FDO. It would also mean that we would lose the time component from DHs who are currently providing a "real" value. I would question the value of this time component though considering we also get a date/time in the executionDateTime field.
Option 3 - we introduce a flag that tells us how to interpret the postingDateTime field
We could introduce a new field to the BankingTransaction definition that indicates "doesPostingDateTimeHaveTime", but this would require a FDO and just complicate processing logic and both ends.
Feedback
We are keen to hear feedback on