March 28, 2014 at 23:31ATM. On the other side of the wire
In connection with the recently discussed topic of the design of ATMs, the desire of the Habr to learn more about them, as well as just an overwhelming amount of speculation from such a seemingly technically savvy audience, I decided to write this post. Unlike UserSide , which was mainly engaged in physical servicing of ATMs, and it seems to me that it is very far from those who actually write software for managing the host, I will talk about the “other side”. Naturally, to the best of my knowledge, still too modest.
Since this is my first article on Habr, I apologize for the possibly excessive confusion.
The first thing I want to note is that everything said in the article and almost everything in the comments is true, but true one-sided - it describes particular cases. And although these are special cases, in the manner in which the information is presented, an unprepared reader may get the impression that it only happens as it was told. And although several opposite descriptions of situations managed to appear in the comments, no one ever voiced the main thing - all these are special cases.
One of the members of the forum, referring to his experience, insisted that you can attach any account (and in any currency) to the card in 5 minutes, someone else doubted. It really is. The possibility of this procedure is determined only by the capabilities of the software of the processing system itself, its support from the Internet / mobile bank, the desire of the bank to provide such services to the population, and its desire to pay an extra money to the system developer for this. In the system to which I am involved, the card and the account are two different entities.
In our terminology, a card is a token - just as I remember, for example, a password, certificate, identity document, and some others, I don’t remember at once. The token serves only for access to the account. Moreover, as the account can be accessed through several tokens, so the token can serve several accounts. For example, in one bank where our system works, during a card transaction you may be asked to indicate a specific account - if there are several of them attached to the card.
This feature is called "False PIN" (iPIN). The fact that some bank offers to make it by default, as the main PIN, written down on the contrary, serves only the purpose of easier to remember it. Judging by the comments, I got the impression that not everyone understands this.
As far as I heard from colleagues, this feature is not very popular, because has its negative sides (I don’t know which ones). The fact is that it is used extremely rarely.
Again, this is not an indispensable rule, it is done just for the convenience of service. In our system it is done in this way, I suspect that in all the others it is the same:
When inserting such a card, the host, instead of executing the transaction, asks the ATM for current counters (or the ATM application itself can determine such a card and immediately send the counters on its own - more about applications later). Then the physical collection of the terminal takes place and new counters are entered into it (this is done manually, but I heard from the edge of my ear that it is possible to automatically record cassettes ... but it seems to me that this is rarely where now). After closing the ATM, the door presses a special button called the supervisor button, and the ATM reports to the network at least that the “supervisor mode” sensor status has changed, at the very least its full state, including new counters (or maybe even old ones, see in the chapter on applications). If the report contains only sensor information, then the host itself requests the counters. At this point, the host can compare the new counters with the old and create a collection transaction. Again, I repeat, this works for us, but that does not mean that it works everywhere. But since the scheme is very flexible and autonomous, it is used for sure in almost any software product of this kind.
Instead of a card, the team for the initial survey of counters (before transferring the ATM to supervisor mode for collection) can also be given from the host. In this case, collection may look like this: collectors arrive at the place, call the processing center, the operator executes the command through the system, then everything is as in the first scenario.
It should be noted that all applications can be divided into 2 types:
The most important thing that distinguishes these schemes of interaction between the host and the ATM is which side stores the intermediate data until a full-fledged transaction can be formed. This can happen, for example, in the case when 2 or more accounts are tied to the card - because the interaction scenario does not know the number of accounts in advance, it simply generates a transaction request and sends it to the host. The host rejects it with the reason “Correction is necessary” and sends a list of parameters that need to be clarified. And here two options are possible:
The behavior upon detection of an unselected card is fully customizable - the ATM can either capture it or leave it in the path. The same applies to issuing a card before / after money, at the beginning / end of work, during a power outage (if the bank is not completely poor, there must be a UPS in the ATM). What to do if an incorrect PIN is entered, a false PIN is entered (if any), when the counter of invalid PINs is reset, whether card capture is needed - the host decides everything. If the host does not instruct the ATM to capture the card, he will not capture it, even if it is fake, stolen and lost ten times.
What to do with chip cards if you were unable to read the chip depends on the script settings. A narrower range of services may be offered, or it may simply refuse to serve. The same goes for cards of other banks.
Which issuing algorithm to use and how the ATM will recognize it - again, completely depends on the settings. Of course, now, in the era of mass Internet, it is more profitable for the host to perform all the calculations himself, and only issue commands to the ATM. However, for example, the Kaliginte object for managing the CashDispenser (cash dispenser) also can calculate the purchase amount of the issuance using different algorithms. We do not use this feature in our system. Again, letting the user choose the issuing algorithm, or, as someone said in the comments, even the specific denominations of the banknotes, depends entirely on the bank's desire to create such a scenario (well, and on the capabilities of the software, of course).
The limit of 40 notes really comes from physical limitations - a bundle of 40 banknotes is almost a centimeter thick. About the fact that the ATM simply refuses to give out an amount that cannot be physically issued at a time, with an unintelligible mistake - the fault of the script developer - that he did not provide a clear message about the reason. Everything is simple with Kalignite, it’s plain HTML, as I said above, actually a local site, and for NDC / DDC ATMs, the host response may contain updated screens, the text on which, again, defines the host ... Triton protocol is worse , and he has few error codes, but Tritons in Russia, it seems, are not very common.
The ones I've tested on are worth Windows XP. And I was tested with the Kalignite script, with NDC and DDC ATMs.
Here you go. I hope it was interesting and the chaos in my mind diminished. The main idea that I wanted to convey is that absolutely EVERYTHING is configured. Naturally, somewhere less, somewhere more, but this is more about the deeper nuances than those that are visible at first glance.
Since this is my first article on Habr, I apologize for the possibly excessive confusion.
The first thing I want to note is that everything said in the article and almost everything in the comments is true, but true one-sided - it describes particular cases. And although these are special cases, in the manner in which the information is presented, an unprepared reader may get the impression that it only happens as it was told. And although several opposite descriptions of situations managed to appear in the comments, no one ever voiced the main thing - all these are special cases.
1. Cards and accounts
One of the members of the forum, referring to his experience, insisted that you can attach any account (and in any currency) to the card in 5 minutes, someone else doubted. It really is. The possibility of this procedure is determined only by the capabilities of the software of the processing system itself, its support from the Internet / mobile bank, the desire of the bank to provide such services to the population, and its desire to pay an extra money to the system developer for this. In the system to which I am involved, the card and the account are two different entities.
In our terminology, a card is a token - just as I remember, for example, a password, certificate, identity document, and some others, I don’t remember at once. The token serves only for access to the account. Moreover, as the account can be accessed through several tokens, so the token can serve several accounts. For example, in one bank where our system works, during a card transaction you may be asked to indicate a specific account - if there are several of them attached to the card.
2. The opposite is true for fraudsters
This feature is called "False PIN" (iPIN). The fact that some bank offers to make it by default, as the main PIN, written down on the contrary, serves only the purpose of easier to remember it. Judging by the comments, I got the impression that not everyone understands this.
As far as I heard from colleagues, this feature is not very popular, because has its negative sides (I don’t know which ones). The fact is that it is used extremely rarely.
3. Cards of collectors / supervisors
Again, this is not an indispensable rule, it is done just for the convenience of service. In our system it is done in this way, I suspect that in all the others it is the same:
When inserting such a card, the host, instead of executing the transaction, asks the ATM for current counters (or the ATM application itself can determine such a card and immediately send the counters on its own - more about applications later). Then the physical collection of the terminal takes place and new counters are entered into it (this is done manually, but I heard from the edge of my ear that it is possible to automatically record cassettes ... but it seems to me that this is rarely where now). After closing the ATM, the door presses a special button called the supervisor button, and the ATM reports to the network at least that the “supervisor mode” sensor status has changed, at the very least its full state, including new counters (or maybe even old ones, see in the chapter on applications). If the report contains only sensor information, then the host itself requests the counters. At this point, the host can compare the new counters with the old and create a collection transaction. Again, I repeat, this works for us, but that does not mean that it works everywhere. But since the scheme is very flexible and autonomous, it is used for sure in almost any software product of this kind.
Instead of a card, the team for the initial survey of counters (before transferring the ATM to supervisor mode for collection) can also be given from the host. In this case, collection may look like this: collectors arrive at the place, call the processing center, the operator executes the command through the system, then everything is as in the first scenario.
4. ATM application
It should be noted that all applications can be divided into 2 types:
- the exchange protocol is strictly defined; on the ATM side, a program running on this protocol is running and it is impossible to expand it in any way. These are, for example, NDC, DDC and Triton.
- the exchange protocol is not only not rigidly fixed, but on the contrary, the application at the ATM is an extensible plug-in to support communication with a specific host. This is how Kalignite ATMs are arranged - by the way, the most flexible of those that I have worked with. The Kalignite application is a regular .Net application, the screens displayed on the ATM screen are ordinary HTML pages displayed through a standard .Net browser component (which, in turn, is based on the IE core, i.e. has all its vulnerabilities. However, component is greatly trimmed). Thanks to this development of the visual part of the script, web designers can engage in and enjoy all the benefits - for example, jQuery, a virtual keyboard and everything that your heart desires.
Since the code that is written by the system developer himself works at the ATM, the performance of any service functions can be significantly simplified - for example, a collection transaction can be generated on the ATM itself and sent to the host as a normal transaction request (only this will be an administrative transaction).
The most important thing that distinguishes these schemes of interaction between the host and the ATM is which side stores the intermediate data until a full-fledged transaction can be formed. This can happen, for example, in the case when 2 or more accounts are tied to the card - because the interaction scenario does not know the number of accounts in advance, it simply generates a transaction request and sends it to the host. The host rejects it with the reason “Correction is necessary” and sends a list of parameters that need to be clarified. And here two options are possible:
- the terminal sends only the specified parameters - in this case, the host must somewhere store the information that the ATM sent in the previous request - stateless ATM, host statefull - this is how all ATM programs with a fixed protocol (NDC / DDC, Triton and others) behave because the protocol does not provide a place to store this data;
- the terminal sends all the past data plus updated parameters - statefull ATM, stateless host. This is best done when working with Kalignite, as anyway, you need to (preferably) write your extension for interaction over a convenient host protocol.
5. Card withdrawals and invalid PINs
The behavior upon detection of an unselected card is fully customizable - the ATM can either capture it or leave it in the path. The same applies to issuing a card before / after money, at the beginning / end of work, during a power outage (if the bank is not completely poor, there must be a UPS in the ATM). What to do if an incorrect PIN is entered, a false PIN is entered (if any), when the counter of invalid PINs is reset, whether card capture is needed - the host decides everything. If the host does not instruct the ATM to capture the card, he will not capture it, even if it is fake, stolen and lost ten times.
6. Chip cards
What to do with chip cards if you were unable to read the chip depends on the script settings. A narrower range of services may be offered, or it may simply refuse to serve. The same goes for cards of other banks.
7. A maximum of 40 bills to issue and the algorithm for issuing
Which issuing algorithm to use and how the ATM will recognize it - again, completely depends on the settings. Of course, now, in the era of mass Internet, it is more profitable for the host to perform all the calculations himself, and only issue commands to the ATM. However, for example, the Kaliginte object for managing the CashDispenser (cash dispenser) also can calculate the purchase amount of the issuance using different algorithms. We do not use this feature in our system. Again, letting the user choose the issuing algorithm, or, as someone said in the comments, even the specific denominations of the banknotes, depends entirely on the bank's desire to create such a scenario (well, and on the capabilities of the software, of course).
The limit of 40 notes really comes from physical limitations - a bundle of 40 banknotes is almost a centimeter thick. About the fact that the ATM simply refuses to give out an amount that cannot be physically issued at a time, with an unintelligible mistake - the fault of the script developer - that he did not provide a clear message about the reason. Everything is simple with Kalignite, it’s plain HTML, as I said above, actually a local site, and for NDC / DDC ATMs, the host response may contain updated screens, the text on which, again, defines the host ... Triton protocol is worse , and he has few error codes, but Tritons in Russia, it seems, are not very common.
8. Operating system
The ones I've tested on are worth Windows XP. And I was tested with the Kalignite script, with NDC and DDC ATMs.
Here you go. I hope it was interesting and the chaos in my mind diminished. The main idea that I wanted to convey is that absolutely EVERYTHING is configured. Naturally, somewhere less, somewhere more, but this is more about the deeper nuances than those that are visible at first glance.