How and why we made our ATMs
The idea of creating your own ATM sounded somewhat crazy. But we deliberately took the risk to give our ATM new opportunities that competitors do not have. In this post, we want to tell what our team learned in the process of developing, testing and deploying its own ATM network, and explain why reinventing the wheel is not a useless exercise.
The idea to automate the process of issuing cash came up with John Shepherd-Barron (John Shepherd-Barron). In 1967, this Scottish inventor managed to convince the management of the London-based Barclays Bank that while the bank is closed for the weekend, the machine can serve customers. Since then, this idea has taken root everywhere, and the functionality of ATMs has expanded from a simple issue of money to most banking operations.
A modern ATM is able to accept cash and non-cash payments, work with bank accounts, connect to the banking service system and perform various operations in it.
')
For our bank, which does not have retail branches, and our clients, these opportunities are extremely useful, but from the moment of its foundation until recently, Tinkoff used the infrastructure of partner banks. So, we have all the prerequisites for creating our own ATMs.
Despite the rush, we didn’t want to use standard solutions, since they were all clamped down by protocols and the long-standing Windows XP OS, which was the core of the absolute majority of them.
So, we started with finding the right "hardware".
The Shepherd-Barron brainchild was not much more complicated by design than the vending machine that inspired the inventor. But modern ATMs are computer terminals that combine the most different equipment.
The minimum required for any ATM is a control computer, a card reader, a pin-pad — a keyboard for entering a PIN code and payment amounts, a device issuing and receiving banknotes, a receipt printer, and a set of sensors that monitor the correctness of the subsystems ATM machine.
The main requirement for the “iron” part of the future Tinkoff ATM was support for the cash recycling function. An ATM with this option operates in a closed loop, receives and disburses money from one cassette, and due to this, it works longer without a cash collection service. In addition, this device must fully support NFC, read QR codes and have a large touch screen.
Simultaneously with the search for a hardware solution, we dealt with software issues.
From the programmer's point of view, an ATM is a client terminal that independently manages only the equipment connected to it, and the server deals with processing operations.
There are long-established standards and protocols for the interaction of an ATM computer with a card reader, a pin-pad, a recycler and other peripherals, as well as for organizing "communication" with the server. They severely limit the flexibility of developing and implementing new features.
The idea of creating ATM software from scratch might seem dubious, but otherwise it would have been impossible to implement much of the Tinkoff team’s plans.
Initially, we planned to abandon the eXtension For Financial Services (XFS) standard, which describes the logic of ATM equipment management, in favor of a proprietary solution based on Linux. With it you could achieve multiplatform. But this idea had to be dropped, since no ATM manufacturer wanted to agree to intervene in the ATM equipment driver at such a deep level.
Therefore, we attracted a contractor — a company that had experience in developing .NET software for payment terminals — to work on creating management software, integrating an ATM with a server, and writing an API to create various scenarios for operating an ATM.
Instead of Windows XP installed in competing solutions, the ATM received 64-bit Windows 10. Fresh OS gave more possibilities for implementing a visually attractive and responsive interface that resembles the one implemented in our mobile application, both externally and under usage scenarios.
Everyone who regularly uses ATMs is familiar with the standard menus that offer to choose a language, account, etc. These scripts and algorithms are largely unintuitive and inconvenient. They are hard-wired in standard NDC / DDC protocols designed for ATM and server (host) communication.
To get rid of these atavisms, we had to change the protocols to the original flexible and modern solution, which would connect the ATM with the server part, entirely written in Java.
At the very beginning, colleagues from other companies told us that we were crazy when we stuttered that we wanted to get away from the standard NDC / DDC protocols. But time has already judged us.
Of course, almost all these changes in the bowels of the software by the client are not noticeable, however, it will easily distinguish the Tinkoff ATM from others not only on the screen and menu - the processing of the software allowed to implement new scenarios for using the ATM.
First of all, we are talking about authorization in your account using NFC . Each client, whose smartphone or card supports contactless payment, can use an ATM, simply by attaching his device or card to the reader. Through the efforts of our programmers, NFC fully works with the Google Pay, Apple Pay and Samsung Pay payment systems, and supports depositing and withdrawing money.
Another, previously impossible way to interact with an ATM, is quick cash . So we call the issuance of money using a QR code generated in your account via the bank’s mobile application. It is enough to scan the screen of the smartphone and pick up the required amount without any queues and delays in searching for the card, entering the PIN code and navigating through the menu.
In addition, our team managed to eliminate another virtual obstacle limiting ATM users. Now, by logging in to an ATM in any way convenient to him, Tinkoff Bank's client from a single personal account gets access to all of their cards and accounts. For example, by inserting a debit card into an ATM and finding that there is not enough money on it, you can immediately withdraw money from a credit card remaining at home.
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, for all these operations there are standard solutions, but they have the same drawbacks as in the NDC / DDC protocols. These solutions are not amenable to customization and fine-tuning. They are simply uncomfortable.
Encashment is a separate user script run on an ATM. And it is more complicated than those that are responsible for issuing funds or replenishing accounts.
In the decisions of Tinkoff Bank, the interaction of the collector with the ATM is minimized. He is no longer required to make calculations, enter additional data into the ATM. The process is controlled from the host, and the ATM screen displays instructions for the employee performing the replacement of the cash drawer. By reducing the number of actions performed by the collector, we reduced the number of human errors and accelerated the collection process.
The servers monitor the cash cassette counters, which in the future will allow automating the sending of requests for servicing ATMs and even predict the need for it.
In theory, a Recycle ATM may not be collected at all, but in reality, depending on the location of the ATM, the time of year and holidays, it may take more cash from it or, on the contrary, replenish cassettes faster than they are empty. Sooner or later there is a need for collection.
Collecting information about how various factors influence customer behavior, and tracking the dynamics of using Tinkoff ATMs, we are developing a technology that allows you to predict how soon it will be necessary to refill or empty an ATM. Thus, it is possible not only to save on regular departures of collectors, but also to increase the availability of services by eliminating the situation in which the ATM is idle while waiting for service.
In the future, the prediction of collection will partially shift this task to bank customers by managing client flows. These schemes are being worked out now. The idea is to encourage our customers to withdraw cash from crowded ATMs and, on the contrary, to replenish accounts in ATMs, where there is very little cash left.
We also solved the problem with updating the internal software. Releases come out with us once every two weeks and roll automatically, while most banks in the market update the software at best once a year. And the process itself is quite troublesome.
One more thing. We managed to greatly reduce the time it takes to analyze claims from customers. Work with the problem begins immediately after treatment.
All the necessary information is transmitted by an ATM to the server, automatically, is given in a readable form and is sent to the support service along with the recordings from the cameras. As a result, most problems can be solved in just a couple of hours.
To receive certificates from the VISA and MasterCard payment systems, a separate team had to be allocated, and yet in June 2017 our ATM prototype was ready. Taking into account that we started in January, it came out very quickly.
The test team actively joined the test team. Then the ATM was installed in the business center, and all our employees got access to it. Although testers did important work, catching the majority of critical bugs, some errors began to emerge only at the stage of internal testing. And in advance to predict the appearance of certain problems was almost impossible.
So, in one case, the scenario of depositing cash into an ATM did not work. Viewing operations logs did not give anything, the bug was not reproduced. It was possible to figure out what happened only after viewing the recordings from surveillance cameras.
It turned out that the client logged in to his personal account and took the bills out of his wallet, put it on the NFC reader. The ATM found other cards inside the wallet, and the cash deposit scenario, which did not take into account this development, broke down.
And if it was easy to cope with this problem (by updating the software), then the 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 cite the case in which a customer who wants to replenish Tinkoff Bank's account without a card according to the contract number, instead of pressing the “top up” button, chooses “pay”. So he gets into a dialogue, where it is proposed to choose which of the popular electronic transfer systems or to which cellular operator you should transfer funds. The client chooses the Qiwi item and enters the Tinkoff bank account number in the field intended for the phone. Moreover, Qiwi accepts such a transfer and puts money on some of its technical accounts for further proceedings.
Of course, such an erroneous operation can be withdrawn and the money returned to the client, 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 to solve the problem, which does not allow to indicate anything other than a mobile phone in the ill-fated input field.
We ourselves believe that our ATM history has just begun. In fact, we got an absolutely unique product only due to the fact that we didn’t listen to exclamations like “how are you going to live without standard NDC / DDC protocols”. Although all sorts of difficulties, of course, were.
ATM card
While in our network there are a little more than 200 ATMs, 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 then we plan to increase the pace. 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 been able to accumulate.
The idea to automate the process of issuing cash came up with John Shepherd-Barron (John Shepherd-Barron). In 1967, this Scottish inventor managed to convince the management of the London-based Barclays Bank that while the bank is closed for the weekend, the machine can serve customers. Since then, this idea has taken root everywhere, and the functionality of ATMs has expanded from a simple issue of money to most banking operations.
A modern ATM is able to accept cash and non-cash payments, work with bank accounts, connect to the banking service system and perform various operations in it.
')
For our bank, which does not have retail branches, and our clients, these opportunities are extremely useful, but from the moment of its foundation until recently, Tinkoff used the infrastructure of partner banks. So, we have all the prerequisites for creating our own ATMs.
Despite the rush, we didn’t want to use standard solutions, since they were all clamped down by protocols and the long-standing Windows XP OS, which was the core of the absolute majority of them.
So, we started with finding the right "hardware".
ATM hardware basis
The Shepherd-Barron brainchild was not much more complicated by design than the vending machine that inspired the inventor. But modern ATMs are computer terminals that combine the most different equipment.
The minimum required for any ATM is a control computer, a card reader, a pin-pad — a keyboard for entering a PIN code and payment amounts, a device issuing and receiving banknotes, a receipt printer, and a set of sensors that monitor the correctness of the subsystems ATM machine.
The main requirement for the “iron” part of the future Tinkoff ATM was support for the cash recycling function. An ATM with this option operates in a closed loop, receives and disburses money from one cassette, and due to this, it works longer without a cash 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 dealt with software issues.
From the programmer's point of view, an ATM is a client terminal that independently manages only the equipment connected to it, and the server deals with processing operations.
There are long-established standards and protocols for the interaction of an ATM computer with a card reader, a pin-pad, a recycler and other peripherals, as well as for organizing "communication" with the server. They severely limit the flexibility of developing and implementing new features.
The idea of creating ATM software from scratch might seem dubious, but otherwise it would have been impossible to implement much of the Tinkoff team’s plans.
Initially, we planned to abandon the eXtension For Financial Services (XFS) standard, which describes the logic of ATM equipment management, in favor of a proprietary solution based on Linux. With it you could achieve multiplatform. But this idea had to be dropped, since no ATM manufacturer wanted to agree to intervene in the ATM equipment driver at such a deep level.
Therefore, we attracted a contractor — a company that had experience in developing .NET software for payment terminals — to work on creating management software, integrating an ATM with a server, and writing an API to create various scenarios for operating an ATM.
Instead of Windows XP installed in competing solutions, the ATM received 64-bit Windows 10. Fresh OS gave more possibilities for implementing a visually attractive and responsive interface that resembles the one implemented in our mobile application, both externally and under usage scenarios.
Everyone who regularly uses ATMs is familiar with the standard menus that offer to choose a language, account, etc. These scripts and algorithms are largely unintuitive and inconvenient. They are hard-wired in standard NDC / DDC protocols designed for ATM and server (host) communication.
To get rid of these atavisms, we had to change the protocols to the original flexible and modern solution, which would connect the ATM with the server part, entirely written in Java.
At the very beginning, colleagues from other companies told us that we were crazy when we stuttered that we wanted to get away from the standard NDC / DDC protocols. But time has already judged us.
What's new for customers
Of course, almost all these changes in the bowels of the software by the client are not noticeable, however, it will easily distinguish the Tinkoff ATM from others not only on the screen and menu - the processing of the software allowed to implement new scenarios for using the ATM.
First of all, we are talking about authorization in your account using NFC . Each client, whose smartphone or card supports contactless payment, can use an ATM, simply by attaching his device or card to the reader. Through the efforts of our programmers, NFC fully works with the Google Pay, Apple Pay and Samsung Pay payment systems, and supports depositing and withdrawing money.
Another, previously impossible way to interact with an ATM, is quick cash . So we call the issuance of money using a QR code generated in your account via the bank’s mobile application. It is enough to scan the screen of the smartphone and pick up the required amount without any queues and delays in searching for the card, entering the PIN code and navigating through the menu.
In addition, our team managed to eliminate another virtual obstacle limiting ATM users. Now, by logging in to an ATM in any way convenient to him, Tinkoff Bank's client from a single personal account gets access to all of their cards and accounts. For example, by inserting a debit card into an ATM and finding that there is not enough money on it, you can immediately withdraw money from a credit card remaining 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, for all these operations there are standard solutions, but they have the same drawbacks as in the NDC / DDC protocols. These solutions are not amenable to customization and fine-tuning. They are simply uncomfortable.
Collection
Encashment is a separate user script run on an ATM. And it is more complicated than those that are responsible for issuing funds or replenishing accounts.
In the decisions of Tinkoff Bank, the interaction of the collector with the ATM is minimized. He is no longer required to make calculations, enter additional data into the ATM. The process is controlled from the host, and the ATM screen displays instructions for the employee performing the replacement of the cash drawer. By reducing the number of actions performed by the collector, we reduced the number of human errors and accelerated the collection process.
The servers monitor the cash cassette counters, which in the future will allow automating the sending of requests for servicing ATMs and even predict the need for it.
In theory, a Recycle ATM may not be collected at all, but in reality, depending on the location of the ATM, the time of year and holidays, it may take more cash from it or, on the contrary, replenish cassettes faster than they are empty. Sooner or later there is a need for collection.
Collecting information about how various factors influence customer behavior, and tracking the dynamics of using Tinkoff ATMs, we are developing a technology that allows you to predict how soon it will be necessary to refill or empty an ATM. Thus, it is possible not only to save on regular departures of collectors, but also to increase the availability of services by eliminating the situation in which the ATM is idle while waiting for service.
In the future, the prediction of collection will partially shift this task to bank customers by managing client flows. These schemes are being worked out now. The idea is to encourage our customers to withdraw cash from crowded ATMs and, on the contrary, to replenish accounts in ATMs, where there is very little cash left.
Regular software update
We also solved the problem with updating the internal software. Releases come out with us once every two weeks and roll automatically, while most banks in the market update the software at best once a year. And the process itself is quite troublesome.
Processing customer requests
One more thing. We managed to greatly reduce the time it takes to analyze claims from customers. Work with the problem begins immediately after treatment.
All the necessary information is transmitted by an ATM to the server, automatically, is given in a readable form and is sent to the support service along with the recordings from the cameras. As a result, most problems can be solved in just a couple of hours.
Testing the prototype: the first bumps
To receive certificates from the VISA and MasterCard payment systems, a separate team had to be allocated, and yet in June 2017 our ATM prototype was ready. Taking into account that we started in January, it came out very quickly.
The test team actively joined the test team. Then the ATM was installed in the business center, and all our employees got access to it. Although testers did important work, catching the majority of critical bugs, some errors began to emerge only at the stage of internal testing. And in advance to predict the appearance of certain problems was almost impossible.
So, in one case, the scenario of depositing cash into an ATM did not work. Viewing operations logs did not give anything, the bug was not reproduced. It was possible to figure out what happened only after viewing the recordings from surveillance cameras.
It turned out that the client logged in to his personal account and took the bills out of his wallet, put it on the NFC reader. The ATM found other cards inside the wallet, and the cash deposit scenario, which did not take into account this development, broke down.
And if it was easy to cope with this problem (by updating the software), then the 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 cite the case in which a customer who wants to replenish Tinkoff Bank's account without a card according to the contract number, instead of pressing the “top up” button, chooses “pay”. So he gets into a dialogue, where it is proposed to choose which of the popular electronic transfer systems or to which cellular operator you should transfer funds. The client chooses the Qiwi item and enters the Tinkoff bank account number in the field intended for the phone. Moreover, Qiwi accepts such a transfer and puts money on some of its technical accounts for further proceedings.
Of course, such an erroneous operation can be withdrawn and the money returned to the client, 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 to solve the problem, which does not allow to indicate anything other than a mobile phone in the ill-fated input field.
Tale will be ahead
We ourselves believe that our ATM history has just begun. In fact, we got an absolutely unique product only due to the fact that we didn’t listen to exclamations like “how are you going to live without standard NDC / DDC protocols”. Although all sorts of difficulties, of course, were.
While in our network there are a little more than 200 ATMs, 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 then we plan to increase the pace. 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 been able to accumulate.
Source: https://habr.com/ru/post/358356/
All Articles