July 18, 2015 at 11:30Once again to the issue of ATMs
Recently safinaskar asked me the following question in a private conversation:
Since the answer has slowly grown, I thought that it was worthy of a separate article, especially since some topics were touched on which I myself did not understand well and did not want to mislead people with incorrect answers. I hope there will be clarifications and additions in the comments.
I doubted a little where the note should be taken - to a geek magazine On the one hand, when transferring articles, my previous article on this topic remained on habrahabr. On the other hand, judging by the administration’s policy, they want to leave the Habr exclusively for those articles, the bulk of which is program code. Therefore, you see my current article here.
Software development, like any other activity, requires a certain qualification. And software development in such an area as finance - and even more so. Now let's remember what a bank is. This organization does not develop software for its ATMs, otherwise it would have to keep staff for this. But scenario development is a one-time procedure, therefore it is inefficient. Thus, the development is ordered from specialized companies.
As you know, hardly anyone will entrust this development to anyone. And in order to change a proven scenario, you need good reason. Say, the bank’s desire to provide an extended range of services through ATMs, and not just money withdrawal / investment and balance information. For the same reasons, miserable scenarios will change only when they are sure that this will bring financial gain.
I myself rarely use ATMs, but I don’t use ATMs of other banks at all, so I can’t say. But I think that is so. Most likely, Wincor ATMs operating under NDC / DDC protocols with some Wincor extensions are the most common in Russia. Therefore, let's talk about them.
I must say that the specifications for 2013 (the latest version of the specification that I saw) are not very different from the specifications for 2003. Basically, some dubious features are outdated, the opportunity has appeared to embed HTML pages on screens. However, this possibility is not yet supported by us, so I don’t know anything about it, quite tolerable scenarios are implemented by pictures. Not to say that it looks so wretched. And then, do you really want to see the ubiquitous advertising also at an ATM? She is there, of course, but at least not so annoying and, as a rule, on the main screen, and not inside the script.
No, it's more about backward compatibility and the inability to radically change the protocol for communicating with an ATM because of this. In addition, it seems to me that the ATM comes with its software: new software - a new ATM. Since an ATM is not a cheap thing, this can also slow down changes. Although it must be admitted that the new features of the software are often not related to the user interface and the script can be written for the old versions. But there are other considerations. I saw ATMs whose CRT displays are nearing the end of their life, and if you show a picture there, you get a blurry spot. The text interface is better. In addition, there may still be ATMs that do not know how to display pictures. But zhelezyachniks can better tell about this, I only work on the host part.
Because the PIN is checking the host. The ATM cannot perform this operation (generally speaking, NDC / DDC protocols have such an opportunity, but we must remember that they arose at a time when the concept of "information security" did not exist).
Of course, you can make a separate request to verify the PIN at the beginning of the script, but this is an additional request to the server and increase the timeout. Although this is used - for example, if it is necessary to split the script into different branches for foreign cards belonging to the NSPK system and completely foreign cards. Only a host can do this classification.
For your own cards, an extra request can slow down the service too much. For example, in the network of ATMs serviced by our system, there are ATMs in which at the peak of the load transactions occur every 2 minutes, from different cards, and, as a rule, one transaction per card. Slow down the script by half in order to warn a person that the PIN is wrong? This is also an additional load on the host - after all, according to the PCI DSS standard , a separate iron server must check the pins, and the PIN in any case will be checked again during the operation, according to the same PCI DSS.
Enter PIN before or after the operation is selected - the scenario developer decides on the requirements of the bank. Perhaps entering a PIN at the very beginning is simply more familiar. And for chip cards, it may also be necessary - in order to gain access to chip applications, you may need to go through authorization on the chip. But these are my assumptions, as a matter of fact, I do not know.
Hello, I saw your article about ATMs habrahabr.ru/post/217337 . My question is: why is the interface of all ATMs so anti-friendly, so identical and so “tough”, unlike other machines (say, Qiwi machines)? I dealt with ATMs Sberbank, Rosbank and My Bank (now went bankrupt).
Do I understand correctly that the software for conventional machines (eg Qiwi) is the most common software, developed in the same way as software is usually developed. It is easy to make changes to the software, it is written with the usual tools for regular OS (e.g. Windows), UX is taken into account and sometimes there are bugs.
And software for ATMs is written once and for all (for security purposes), security is placed above UX. So? And hence the problems with UX?
I have the feeling that all ATMs use the same program, is that so?
If I'm not mistaken, the ATM first asks for a pin, then the amount, and only then checks the pin for correctness. Why is that?
Since the answer has slowly grown, I thought that it was worthy of a separate article, especially since some topics were touched on which I myself did not understand well and did not want to mislead people with incorrect answers. I hope there will be clarifications and additions in the comments.
I doubted a little where the note should be taken - to a geek magazine On the one hand, when transferring articles, my previous article on this topic remained on habrahabr. On the other hand, judging by the administration’s policy, they want to leave the Habr exclusively for those articles, the bulk of which is program code. Therefore, you see my current article here.
Software development, like any other activity, requires a certain qualification. And software development in such an area as finance - and even more so. Now let's remember what a bank is. This organization does not develop software for its ATMs, otherwise it would have to keep staff for this. But scenario development is a one-time procedure, therefore it is inefficient. Thus, the development is ordered from specialized companies.
As you know, hardly anyone will entrust this development to anyone. And in order to change a proven scenario, you need good reason. Say, the bank’s desire to provide an extended range of services through ATMs, and not just money withdrawal / investment and balance information. For the same reasons, miserable scenarios will change only when they are sure that this will bring financial gain.
I have the feeling that all ATMs use the same program, is that so?
I myself rarely use ATMs, but I don’t use ATMs of other banks at all, so I can’t say. But I think that is so. Most likely, Wincor ATMs operating under NDC / DDC protocols with some Wincor extensions are the most common in Russia. Therefore, let's talk about them.
I must say that the specifications for 2013 (the latest version of the specification that I saw) are not very different from the specifications for 2003. Basically, some dubious features are outdated, the opportunity has appeared to embed HTML pages on screens. However, this possibility is not yet supported by us, so I don’t know anything about it, quite tolerable scenarios are implemented by pictures. Not to say that it looks so wretched. And then, do you really want to see the ubiquitous advertising also at an ATM? She is there, of course, but at least not so annoying and, as a rule, on the main screen, and not inside the script.
And software for ATMs is written once and for all (for security purposes), security is placed above UX. So? And hence the problems with UX?
No, it's more about backward compatibility and the inability to radically change the protocol for communicating with an ATM because of this. In addition, it seems to me that the ATM comes with its software: new software - a new ATM. Since an ATM is not a cheap thing, this can also slow down changes. Although it must be admitted that the new features of the software are often not related to the user interface and the script can be written for the old versions. But there are other considerations. I saw ATMs whose CRT displays are nearing the end of their life, and if you show a picture there, you get a blurry spot. The text interface is better. In addition, there may still be ATMs that do not know how to display pictures. But zhelezyachniks can better tell about this, I only work on the host part.
If I'm not mistaken, the ATM first asks for a pin, then the amount, and only then checks the pin for correctness. Why is that?
Because the PIN is checking the host. The ATM cannot perform this operation (generally speaking, NDC / DDC protocols have such an opportunity, but we must remember that they arose at a time when the concept of "information security" did not exist).
Of course, you can make a separate request to verify the PIN at the beginning of the script, but this is an additional request to the server and increase the timeout. Although this is used - for example, if it is necessary to split the script into different branches for foreign cards belonging to the NSPK system and completely foreign cards. Only a host can do this classification.
For your own cards, an extra request can slow down the service too much. For example, in the network of ATMs serviced by our system, there are ATMs in which at the peak of the load transactions occur every 2 minutes, from different cards, and, as a rule, one transaction per card. Slow down the script by half in order to warn a person that the PIN is wrong? This is also an additional load on the host - after all, according to the PCI DSS standard , a separate iron server must check the pins, and the PIN in any case will be checked again during the operation, according to the same PCI DSS.
Enter PIN before or after the operation is selected - the scenario developer decides on the requirements of the bank. Perhaps entering a PIN at the very beginning is simply more familiar. And for chip cards, it may also be necessary - in order to gain access to chip applications, you may need to go through authorization on the chip. But these are my assumptions, as a matter of fact, I do not know.