Some commenters to that piece have suggested that there may have been a decimal vs hexadecimal confusion introduced as part of the Y2K remediation completed in the late 1990s.
An update has appeared on BoQ's website offering a work-around, but still casting no light on the cause of the problem.
EFTPOS Merchant Facility Issue - Update
There is an issue with the time and date stamp on a number of BOQ EFTPOS terminals and we are working with our service providers, Keycorp and First Data, to address this issue as a priority.
If your terminal is experiencing card errors or displaying the incorrect date, please complete a profile maintenance, this will take approximately 2 minutes.
Press Function Number 6, for Terminal Settings
Number 3, for profile maintenance
Number 5, to Start now
When complete a small receipt will print out, at this point press the red cancel key, the terminal will now perform a logon. The receipt will read 2016, this is being investigated.
"Your merchant settlement and customers statement will record the correct details, the card is being validated by the host, the only issue is the receipt displaying an incorrect date"
You are now able to transact in the usual manner. For all other enquiries please call the Merchant Helpdesk on 1800 068 427.
Based on these instructions, it appears that a modified program is being pushed down to the EFTPOS terminal that allows it to ignore the card expiry test, allowing transactions to proceed.
However, there is still no clarity on what caused the date error, or even at what point in the sequence the error exists: is it in the EFTPOS terminal, the back-end servers, the database management software, someplace else?
Right now, if I was the IT Director of any other Australian bank, I'd be very interested in this issue. Not for any gleeful reason, but only to be very sure something similar won't affect my organisation as well.