The idea of creating your own ATM sounded a little crazy. But we deliberately took risks in order to provide our ATM with new capabilities that our competitors do not have. In this post, we want to share what our team learned from developing, testing, and deploying our own ATM network, and explain why reinventing the wheel is not a futile exercise.
The idea to automate the cash dispensing process came to the mind of John Shepherd-Barron. In 1967, this Scottish inventor managed to convince the management of London's Barclays Bank that while the bank was closed for the weekend, a machine could serve customers. Since then, this idea has taken root everywhere, and the functionality of ATMs has expanded from simply issuing money to most banking transactions.
A modern ATM is capable of accepting cash and non-cash payments, working with bank accounts, connecting to the banking service system and performing various operations in it.
These capabilities are extremely useful for our bank, which does not have retail branches, and our clients, but from its inception until recently, Tinkoff has used the infrastructure of partner banks. So we have all the prerequisites for creating our own ATMs.
Despite the rush, we did not want to use standard solutions, since they were all constrained by protocols and the long-outdated Windows XP operating system, which was the core of the vast majority of them.
So, we started by searching for suitable hardware.
The minimum required for any ATM is a control computer, a card reader, a pin pad - a keyboard used to enter a PIN code and payment amounts, a device that issues and accepts banknotes, a receipt printer, as well as a set of sensors that monitor the correct operation of the subsystems ATM.
The main requirement for the hardware part of the future Tinkoff ATM was support for the cache recycling function. An ATM with this option operates in a closed cycle, accepts and issues funds from one cassette, and thanks to this, operates longer without collection service. In addition, this device must fully support NFC, read QR codes and have a large touch screen.
From a programmer’s point of view, an ATM is a client terminal that independently controls only the equipment connected to it, and the server processes transactions.
There are long-developed standards and protocols for the interaction of an ATM computer with a card reader, pin pad, recycler and other peripherals, as well as for organizing “communication” with the server. They greatly limit the flexibility of development and the introduction of new features.
The idea of creating ATM software from scratch might seem dubious, but otherwise it was simply impossible to implement much of what the Tinkoff team planned.
Our original plan was to abandon the eXtension For Financial Services (XFS) standard, which describes ATM hardware control logic, in favor of our own Linux-based solution. With it it would be possible to achieve multi-platform. But this idea had to be abandoned because no ATM manufacturer was willing to agree to interfere with the drivers of ATM equipment at such a deep level.
Therefore, to create control software, integrate the ATM with the server, and write an API for creating various scenarios for the operation of the ATM, we involved a contractor - a company that had experience in developing software in .NET for payment terminals.
Instead of Windows XP installed in competitors' solutions, the ATM received 64-bit Windows 10. The new OS provided more opportunities to implement a visually attractive and responsive interface that resembles that implemented in our mobile application, both externally and in terms of use scenarios.
Anyone who regularly uses ATMs is familiar with the standard menus that ask you to select a language, account, etc. These scripts and algorithms are largely unintuitive and inconvenient. They are hardwired in standard NDC/DDC protocols designed for communication between the ATM and the server (host).
To get rid of these atavisms, we had to change the protocols to an original flexible and modern solution that would connect the ATM with a server part written entirely in Java.
At the very beginning, colleagues from other companies told us that we were crazy as soon as we mentioned that we wanted to move away from standard NDC/DDC protocols. But time has already judged us.
First of all, we are talking about authorization in your personal account using NFC . Every client whose smartphone or card supports contactless payment can use the ATM simply by touching their device or card to the reader. Thanks to the efforts of our programmers, NFC fully works with the payment systems Google Pay, Apple Pay and Samsung Pay, and supports deposits and withdrawals of funds.
Another previously impossible way to interact with an ATM is quick cash . This is what we call issuing money using a QR code generated in your personal account through the bank’s mobile application. It is enough to scan the smartphone screen and pick up the required amount without any queues or delays with searching for a card, entering a PIN code and navigating through the menu.
Additionally, our team was able to remove another virtual barrier limiting ATM users. Now, having logged into the ATM in any way convenient for him, a Tinkoff Bank client gets access to all his cards and accounts from a single personal account. So, for example, if you insert a debit card into an ATM and find that there are not enough funds on it, you can immediately withdraw money from the credit card left at home.
Of course, there are standard solutions for all these operations, but they have the same disadvantages as the NDC/DDC protocols. These solutions cannot be customized or fine-tuned. They are simply inconvenient.
Collection is a separate user script that runs on the ATM. And it is more complex than those responsible for issuing funds or replenishing accounts.
In Tinkoff Bank solutions, interaction between the cash collector and the ATM is minimized. He is no longer required to make calculations or enter additional data into the ATM. The process is controlled from the host, and the ATM screen displays instructions for the employee replacing the cash cassettes. By reducing the number of actions performed by the collector, we have reduced the number of human errors and speeded up the collection process.
The servers monitor cash cassette counters, which in the future will make it possible to automate the sending of requests for ATM servicing and even predict the need for it.
In theory, a Recycle ATM may not collect money at all, but in reality, depending on the location of the ATM, the time of year and holidays, more cash can be taken from it or, on the contrary, the cassettes can be refilled faster than they are emptied. Sooner or later, the need for collection arises.
By collecting information about how various factors influence customer behavior and monitoring the dynamics of use of Tinkoff ATMs, we are developing technology that allows us to predict how soon an ATM will need to be refilled or emptied. In this way, you can not only save on regular visits by collectors, but also increase the availability of services by eliminating the situation in which the ATM is idle waiting for service.
In the future, forecasting collection will make it possible to partially shift this task to bank clients by managing client flows. These schemes are currently being developed. The essence of the idea is to encourage our customers to withdraw funds from overcrowded ATMs and, on the contrary, to top up their accounts at ATMs where there is very little cash left.
All necessary information is transmitted by the ATM to the server, automatically, put into readable form and sent to the support service along with camera recordings. As a result, most problems can be solved in just a couple of hours.
The testing team was actively involved in the test development. The ATM was then installed in the business center and all our employees had access to it. Although the testers did an important job catching most of the critical bugs, some errors only began to surface during internal testing. Moreover, it was almost impossible to predict the emergence of certain problems in advance.
So, in one case, the script for depositing cash into an ATM did not work. Viewing the operation logs did not yield anything, the bug was not reproduced. It was possible to find out what was going on only after viewing the recordings from CCTV cameras.
It turned out that the client logged into his personal account and took out bills from his wallet and put it on the NFC reader. The ATM found other cards inside the wallet, and the cash deposit script, which did not take this development into account, broke down.
And if this problem was not difficult to cope with (by updating the software), then cases in which the human factor plays a role are not so easily corrected. For example, it turned out that people tend to ignore instructions and act mechanically. As an example, we will give a case in which a client who wants to top up a Tinkoff Bank account without a card using the agreement number, instead of clicking the “top up” button, selects “pay”. So he gets into a dialogue where he is asked to choose which of the popular electronic transfer systems or to which mobile operator account the funds should be transferred. The client selects the Qiwi item and enters the Tinkoff Bank account number in the field provided for the phone. Moreover, Qiwi accepts such a transfer and deposits the money into some of its technical accounts for further proceedings.
Of course, such an erroneous transaction can be recalled and the client's money returned, but when this happens several times a week, it is quite obvious that something is wrong with the interface. The introduction of a mask helped solve the problem, which does not allow you to enter anything other than a mobile phone in the ill-fated input field.
So far, there are a little more than 200 ATMs in our network, which allowed us to quickly hone all the nodes of this complex “organism,” including the control center. In the near future, their number will double, and we plan to increase the pace further. And if you are interested in technical details or cases in this area, in subsequent posts we will be happy to share the experience that we have managed to accumulate.
The idea to automate the cash dispensing process came to the mind of John Shepherd-Barron. In 1967, this Scottish inventor managed to convince the management of London's Barclays Bank that while the bank was closed for the weekend, a machine could serve customers. Since then, this idea has taken root everywhere, and the functionality of ATMs has expanded from simply issuing money to most banking transactions.
A modern ATM is capable of accepting cash and non-cash payments, working with bank accounts, connecting to the banking service system and performing various operations in it.
These capabilities are extremely useful for our bank, which does not have retail branches, and our clients, but from its inception until recently, Tinkoff has used the infrastructure of partner banks. So we have all the prerequisites for creating our own ATMs.
Despite the rush, we did not want to use standard solutions, since they were all constrained by protocols and the long-outdated Windows XP operating system, which was the core of the vast majority of them.
So, we started by searching for suitable hardware.
ATM hardware
Shepherd-Barron's brainchild was not much more complex in design than the vending machine that inspired the inventor. But modern ATMs are computer terminals that combine a variety of equipment.The minimum required for any ATM is a control computer, a card reader, a pin pad - a keyboard used to enter a PIN code and payment amounts, a device that issues and accepts banknotes, a receipt printer, as well as a set of sensors that monitor the correct operation of the subsystems ATM.
The main requirement for the hardware part of the future Tinkoff ATM was support for the cache recycling function. An ATM with this option operates in a closed cycle, accepts and issues funds from one cassette, and thanks to this, operates longer without collection service. In addition, this device must fully support NFC, read QR codes and have a large touch screen.
ATM software
Simultaneously with the search for a hardware solution, we took up software issues.From a programmer’s point of view, an ATM is a client terminal that independently controls only the equipment connected to it, and the server processes transactions.
There are long-developed standards and protocols for the interaction of an ATM computer with a card reader, pin pad, recycler and other peripherals, as well as for organizing “communication” with the server. They greatly limit the flexibility of development and the introduction of new features.
The idea of creating ATM software from scratch might seem dubious, but otherwise it was simply impossible to implement much of what the Tinkoff team planned.
Our original plan was to abandon the eXtension For Financial Services (XFS) standard, which describes ATM hardware control logic, in favor of our own Linux-based solution. With it it would be possible to achieve multi-platform. But this idea had to be abandoned because no ATM manufacturer was willing to agree to interfere with the drivers of ATM equipment at such a deep level.
Therefore, to create control software, integrate the ATM with the server, and write an API for creating various scenarios for the operation of the ATM, we involved a contractor - a company that had experience in developing software in .NET for payment terminals.
Instead of Windows XP installed in competitors' solutions, the ATM received 64-bit Windows 10. The new OS provided more opportunities to implement a visually attractive and responsive interface that resembles that implemented in our mobile application, both externally and in terms of use scenarios.
Anyone who regularly uses ATMs is familiar with the standard menus that ask you to select a language, account, etc. These scripts and algorithms are largely unintuitive and inconvenient. They are hardwired in standard NDC/DDC protocols designed for communication between the ATM and the server (host).
To get rid of these atavisms, we had to change the protocols to an original flexible and modern solution that would connect the ATM with a server part written entirely in Java.
At the very beginning, colleagues from other companies told us that we were crazy as soon as we mentioned that we wanted to move away from standard NDC/DDC protocols. But time has already judged us.
What's new for clients
Of course, almost all of these changes in the depths of the software are invisible to the client, but he can easily distinguish a Tinkoff ATM from others not only by the screen and menu - the redesign of the software has made it possible to implement new scenarios for using the ATM.First of all, we are talking about authorization in your personal account using NFC . Every client whose smartphone or card supports contactless payment can use the ATM simply by touching their device or card to the reader. Thanks to the efforts of our programmers, NFC fully works with the payment systems Google Pay, Apple Pay and Samsung Pay, and supports deposits and withdrawals of funds.
Another previously impossible way to interact with an ATM is quick cash . This is what we call issuing money using a QR code generated in your personal account through the bank’s mobile application. It is enough to scan the smartphone screen and pick up the required amount without any queues or delays with searching for a card, entering a PIN code and navigating through the menu.
Additionally, our team was able to remove another virtual barrier limiting ATM users. Now, having logged into the ATM in any way convenient for him, a Tinkoff Bank client gets access to all his cards and accounts from a single personal account. So, for example, if you insert a debit card into an ATM and find that there are not enough funds on it, you can immediately withdraw money from the credit card left at home.
Optimization of back-office processes
When creating new ATMs, we paid a lot of attention to optimizing back-office processes: management, monitoring, update distribution system, service and collection.Of course, there are standard solutions for all these operations, but they have the same disadvantages as the NDC/DDC protocols. These solutions cannot be customized or fine-tuned. They are simply inconvenient.
Collection
Collection is a separate user script that runs on the ATM. And it is more complex than those responsible for issuing funds or replenishing accounts.
In Tinkoff Bank solutions, interaction between the cash collector and the ATM is minimized. He is no longer required to make calculations or enter additional data into the ATM. The process is controlled from the host, and the ATM screen displays instructions for the employee replacing the cash cassettes. By reducing the number of actions performed by the collector, we have reduced the number of human errors and speeded up the collection process.
The servers monitor cash cassette counters, which in the future will make it possible to automate the sending of requests for ATM servicing and even predict the need for it.
In theory, a Recycle ATM may not collect money at all, but in reality, depending on the location of the ATM, the time of year and holidays, more cash can be taken from it or, on the contrary, the cassettes can be refilled faster than they are emptied. Sooner or later, the need for collection arises.
By collecting information about how various factors influence customer behavior and monitoring the dynamics of use of Tinkoff ATMs, we are developing technology that allows us to predict how soon an ATM will need to be refilled or emptied. In this way, you can not only save on regular visits by collectors, but also increase the availability of services by eliminating the situation in which the ATM is idle waiting for service.
In the future, forecasting collection will make it possible to partially shift this task to bank clients by managing client flows. These schemes are currently being developed. The essence of the idea is to encourage our customers to withdraw funds from overcrowded ATMs and, on the contrary, to top up their accounts at ATMs where there is very little cash left.
Regular software updates
We also solved the problem with updating the internal software. Our releases come out once every two weeks and are rolled out automatically, while most banks on the market update their software at best once a year. And the process itself is quite troublesome.Processing customer requests
One more thing. We were able to significantly reduce the time it takes to sort out customer complaints. Work with the problem begins immediately after the request.All necessary information is transmitted by the ATM to the server, automatically, put into readable form and sent to the support service along with camera recordings. As a result, most problems can be solved in just a couple of hours.
Prototype testing: first bumps
To obtain certificates from the VISA and MasterCard payment systems, we had to allocate a separate team, and yet in June 2017 the prototype of our ATM was ready. Considering that we started in January, it turned out quite quickly.The testing team was actively involved in the test development. The ATM was then installed in the business center and all our employees had access to it. Although the testers did an important job catching most of the critical bugs, some errors only began to surface during internal testing. Moreover, it was almost impossible to predict the emergence of certain problems in advance.
So, in one case, the script for depositing cash into an ATM did not work. Viewing the operation logs did not yield anything, the bug was not reproduced. It was possible to find out what was going on only after viewing the recordings from CCTV cameras.
It turned out that the client logged into his personal account and took out bills from his wallet and put it on the NFC reader. The ATM found other cards inside the wallet, and the cash deposit script, which did not take this development into account, broke down.
And if this problem was not difficult to cope with (by updating the software), then cases in which the human factor plays a role are not so easily corrected. For example, it turned out that people tend to ignore instructions and act mechanically. As an example, we will give a case in which a client who wants to top up a Tinkoff Bank account without a card using the agreement number, instead of clicking the “top up” button, selects “pay”. So he gets into a dialogue where he is asked to choose which of the popular electronic transfer systems or to which mobile operator account the funds should be transferred. The client selects the Qiwi item and enters the Tinkoff Bank account number in the field provided for the phone. Moreover, Qiwi accepts such a transfer and deposits the money into some of its technical accounts for further proceedings.
Of course, such an erroneous transaction can be recalled and the client's money returned, but when this happens several times a week, it is quite obvious that something is wrong with the interface. The introduction of a mask helped solve the problem, which does not allow you to enter anything other than a mobile phone in the ill-fated input field.
The fairy tale will be ahead
We ourselves believe that our story with ATMs has just begun. In fact, we got an absolutely unique product only thanks to the fact that we did not listen to cries like “how will you even live without standard NDC/DDC protocols.” Although, of course, there were all sorts of difficulties.So far, there are a little more than 200 ATMs in our network, which allowed us to quickly hone all the nodes of this complex “organism,” including the control center. In the near future, their number will double, and we plan to increase the pace further. And if you are interested in technical details or cases in this area, in subsequent posts we will be happy to share the experience that we have managed to accumulate.
