How ATMs are programmed

Brother

Professional
Messages
2,590
Reaction score
506
Points
83
scale_1200


Personally, when I was far from banking technologies, I was always amazed at what a poor interface many ATMs have ... And now I myself teach people how to develop programs for them. And I want to tell you how all this actually works, and why sometimes there is not enough multimedia in these serious devices.

The vast majority of ATMs around the world have only three proud labels on board. These are Diebold (Diebold), NCR and Wincor. Moreover, Wincor and Diebold have merged, becoming the world's largest manufacturer in this area.

In addition to these (now two, not three) mastodons, there are also some small and medium-sized fish on the market. In principle, many people issued ATMs, many were not lazy. Especially at the dawn of the ATM market. (And still not lazy). Then, as usual in a market economy, there were three main players (for some reason, it almost always happens that three players are a stable structure in any market, and one is the largest, one is medium and one is small, usually - remember the big three mobile operators) ... But this does not mean that there are no other brands. Meet. Both old and new. In general, in this market there is a celestial influence.

But be that as it may, the principles of developing "programs" for ATMs were originally laid by the offices of NCR and Diebold. And that was in those days (and this is the seventies), when computers were big and weak. Accordingly, everything was designed so that all this weak iron somehow worked satisfactorily.

Although, perhaps, this slight arrogance is not entirely appropriate.

It would be more correct to say that the ATMs of that time were made reliably and with high quality, like many other products of those times. So high quality that, they say, they still work in some places. But the protocols of that time did not even foresee the emergence of multimedia. Therefore, they counted on very weak devices.

In reality, as I said, there are quite a few old ATMs in the world (although more in the US) that still work great. Therefore, backward compatibility of protocols is required. As a result, an outdated legacy has been dragged along from time immemorial, new opportunities are being built as extensions. Therefore, if you look at the specification for the NDC protocol (NCR Direct Connect by NCR) or DDC (Diebold Direct Connect by Diebold), you will see how huge it is, and the protocols are discordant, confusing and use strange mechanisms. Let's just say that a normal programmer has a reaction: take and rewrite everything according to his mind! But it is impossible, because there is a fleet of old ATMs that will not understand our striving for beauty. By the way, Wincor did not develop its own protocol. He began to support both (but not completely), plus added its own authoring extensions. NDC and DDC protocols are basically very similar to each other, although there are, of course, differences.

Yes, and medium and small ATM manufacturers simply take and support one of the protocols - NDC or DDC (although now there is also something modern).

So, these protocols proceeded from the fact that the ATM performs a limited set of simple and clear instructions, without any scripts or third-party software.

I am writing all this in order to make it clear why ATM programs are not pure programs. In fact, scripts are being developed for ATMs. Work scenarios. There is not a single line of program code in these scripts, you do not need to write anything in any programming language.

You have a set of states into which the ATM can go and perform some previously known operations in them. And when composing a script, you simply select from the available those states that you need, and put them in a certain order.

For example, state "A" in both protocols is the state of waiting for card input, it must be the very first one. At the start, the ATM starts from the first state. After the card is inserted, the ATM, being in state "A", tries to read it and analyze the result. State "A" has settings, incl. the numbers of the following states. To the state with which number to go if, for example, the card has not been read. Or where to go if everything went well.

And, for example, in state "B" the ATM is waiting for the PIN-code input. In this state, he also knows how to display asterisks on the screen.

State "E" was created to organize a menu of four function display keys (FDK), which are located around the perimeter of the screen. The "Y" state is already for a menu of eight items (most often there are eight buttons around the screen, although in record cases there are four more pieces at the top). In the "D" state, the initial content of the command buffer is set. Etc.

The script developer sequentially specifies the names of the states (they are hard-coded in the protocol), their settings (among them there are necessarily numbers of the next states for different cases), as well as the numbers of the "screens".

The point is that "screens" are described separately from states. And this, by the way, is convenient. It happens that different states may have the same "screen" (yes, even the banal inscription "Wait, the transaction is being processed"), so the screen is described once, and the states indicate the numbers of suitable screens. Some states do not have any visual representation, and some states may have several "screens" (for different cases).

In general, the "program" of the ATM is, in fact, a kind of scenario. In which there is a set of numbered states, interconnected by transitions, a set of numbered "screens", well, plus a set of some settings.

There is no universal script development program, and it makes no sense. The script is downloaded to the ATM over the network from the processing center. And the processing programs there are very different. And each manufacturer of processing software implements a script editor for ATMs by itself. Often, such editors allow you to represent a scenario in the form of a transition diagram, where nodes are states, and arrows indicate transitions between them.

After the script is developed and tested, it is uploaded to the ATM over the network. This online update is very important because the ATM network can be very large. You can't run into every ATM.

And on a modern ATM it is simply installed some Windows XP, but the main thing is that a program is running in it that can understand this ATM protocol and do everything that the script requires of it. This is how it works, if you try to keep within the short format.

Oh yes, I promised to tell you why multimedia is often so sad at ATMs ...

Here's the thing. Above in the text I tried to put the word "screen" in quotation marks everywhere. Because this is not just a picture, or rather, not a picture at all. When a script describes a screen, it is actually listing a list of commands that the ATM must execute in order to get some kind of image. And there the teams are of the level of the last century. "Place the cursor at position 5, 7". "Display the text HELLO". "Place the cursor at position 30, 30". "Select color RED". "Display the text WORLD". Etc. It's sad, of course. Well, it is designed for old ATMs.

But, of course, there are modern extensions for describing screens. Not only a picture can be displayed, but a video, and a whole web page ... That is. multimedia capabilities are present, but they are all on top of individual states, screens, etc. And it's pretty awkward to develop this. It's dreary. But you can. If the bank is well confused, there are whole masterpieces. However, it is not possible to do everything very smoothly and modernly. Due to the fact that all this continues to work against the background of discretely changing states and screens.

In fact, there are more modern protocols and solutions. Where everything is arranged in the programming languages we are used to. But this is more in new ATMs (or simply this software costs some money) and has not yet become widespread.

In general, the ATM is not required to sing and dance. The rustling of banknotes is more enjoyable than a symphony in 3D sound. But it should look presentable. What can be achieved without 4K resolution at 60 FPS.
 
Top