I'm not from Information Security or any IT related area. But I want to know if there is any security reason for my digital bank to demand my phone to be on "Automatic Date & Time"?
For example, if I'm abroad, I cannot transfer some money to a friend, because a dialog box says that my date and time is incorrect.
Is that a badly programmed software or does it have a purpose?
One of the reasons can be the usage of the digital signature. If the time on your phone differs essentially from the actual current time, this may cause your phone to reject signatures done by the bank server, or your bank to reject signatures done by your phone.
Why is "Automatic Date & Time" important? Of course, the internal time representation on the phone (milliseconds from 01.01.1970 till now) does not depend on the time zone. But it depends on what you do with this. Suppose you are in the time zone ACT = GMT-5. Suppose your local time is 4:00 ACT, which is 9:00 GMT. Now suppose you disabled "Automatic Date & Time" and set the current time zone explicitly to GMT. Your phone shows immediately not 4:00, but 9:00. The internal time representation remains still unchanged, only GUI representation changed.
But now you see, that 9:00 on your phone differs from the time on your friend's phone. So, you manually set time to 4:00. Now both your phone and your friend's phones show 4:00. But your friend uses ACT = GMT-5, where as you use GMT. Thus, the internal representation of the time on your phone is 5 hours behind the real time.
In such case, even if the bank allows tolerance +- 1 minute, this will be not sufficient. Any operations where time comparison is involved will fail.
In addition to Tim's answer, I would add that it also has to do with how SSL Certificates are verified.
If you log onto your computer instead of your phone, and change the date and time on your computer so that it doesn't match your current location time zone and time, you will run into all kinds of errors when you simply browse the internet. That's because the SSL certificates used to verify websites are not permanent, and there is a time comparison that happens within your internet browser (firefox, chrome etc...) to make sure that SSL Certificate the website uses is CURRENTLY valid.
If the system doesn't know your accurate current time, it can't verify the current validity of the security certificates used by the sites you are trying access. The same would be true for accessing a banking app on your phone, because the app connects to a server that uses certificates to verify it's authenticity.
There are security reasons why your bank may expect your mobile to have automatic date and time enabled. This will include protection against replay attack, where each request includes a timestamp, which is validated on server-side.
Having said that, time zones should have nothing to do with it. If you go abroad and can't use your bank mobile app, I'd suggest you to call your bank and make a complaint. To me it sounds like the original mobile app requirements might have been correct, but the implementation ended up with a defect.
There are numerous security algorithms that limit the window of time in which something is valid.
Regardless of the security mechanism, the concept is that a code is generated that can be used to authenticate or prove an identity. But given time, any code could be broken. So the idea is to limit the amount of time possible to break the code by only allowing the code to be valid for a very short amount of time -- after which that code is no longer valid and a new code would be required. Sometimes it's hours ... sometimes it's minutes or even a few seconds. This means the clocks on both sides need to be reasonably synchronized.
With that aside... time-zones usually don't matter. Computers are typically set to UTC (Universal Time) and the time-zone is simply an offset in some number of hours (and occasionally half-hours) to change the time displayed relative to Universal Time. But the algorithms are typically based on Universal Time -- not the local time-zone.
Your bank might be using TOTP one-time-passwords for secure authentications (often used in mobile token generator). So, secure code required to login generated from your PIN will be completely different now and in 5 minutes.
The security idea is that if someone can get you to generate one-time-password while they can observe it, but stop you from using it, they won't have unlimited time to abuse the one time code, but only a very short one.
As for not working without "Automatic Date & Time" in another country, I'd guess it is related to timezones.
Some authentication protocols such as Kerberos require both parties (your phone and the bank's server) to be synced to within a few minutes of each other. Manually setting the time on your phone may not be accurate enough for your bank's implementation of Kerberos, thus the bank has chosen to check if your phone has automatic time updates enabled, and refuses to work if it is correct.
There are extensions to Kerberos to allow the server to send its current time to the client - the client will use this time instead of its own, but your bank may have chosen not to implement this
Legitimate reason:
Digital signature and authentication schemes generally depend on proper time setting. The software may use some security tokens that are only few minutes (as in Kerberos) or even only few seconds valid. There are a good reasons for that (as in preventing token reuse by malicious parties)
Less-legitimate reasons: As the above, but software getting UTC and time zones calculations wrong. Well, it happens and such software only works in its own timezone (and sometimes even break there because of DST changes or something else).
A misguided approach to geo-limits: the software intentionally not working in different time zone because its developers think that only thieves and no legitimate user will use it abroad.
A wrong approach to date boundaries: your transaction request may appear to be a day in the future or in the past. The underlying bank transaction system may detect a fraud attempt.
etc, etc...
Suppose that on June 1, 2020 there was a data breach that leaked the private key for yourbank.example.com's certificate, and on June 2, 2020, the certificate authority that issued your bank's certificate included a revocation for that certificate. Anyone who requests and receives the current status of that certificate between June 2, 2020 and the time the certificate would have expired would receive a notification that the old certificate was no longer valid.
If, however, the computer's clock were set to August 1, 2019, an attacker who knew this, and who had control over the computer's Internet connection could direct connection attempts to a variety of phony servers, including one which would claim that the date was August 1, 2019, and one which would claim that the yourbank.example.com's certificate had not been revoked (as of August 1, 2019, it would not have been). While attackers' ability to exploit this might be limited for computer-clock values that are in the recent past, the further off the clock is allowed to be, the greater the possibilities for mischief.
Such issues create something of a catch-22 for systems that will only be connected to the Internet very rarely (e.g. once every few years), and may not know the date when they do connect. Without a means of knowing whether a time server's certificate is still valid, one would have no way of knowing whether the reported time from what seems to be a time server might be maliciously manipulated. Requiring that users set the time and date may be crude, but if the user is paying attention, it should protect against that sort of manipulation.
