May 11, 2018 at 15:16How and why did we make our ATMs
The idea of creating your own ATM sounded a little 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 our own ATM network, and explain why reinventing the wheel again is by no means a futile task.
The idea to automate the cash withdrawal process came up with John Shepherd-Barron. In 1967, this Scottish inventor managed to convince the management of London's Barclays Bank that while the bank is closed for the weekend, a machine can serve customers. Since then, this idea has taken root everywhere, and the functionality of ATMs has expanded from a simple cash out 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 customers, 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 did not want to use standard solutions, since all of them were clamped by the protocol framework and the long-aging Windows XP OS, which was the core of the vast majority of them.
So, we started by finding the right hardware.
The brainchild of Shepherd-Barron in design was not much more complicated than the vending machine, which inspired the inventor. But modern ATMs are computer terminals that combine a wide 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 receives banknotes, a receipt printer, and a set of sensors that monitor the correct functioning of the subsystems ATM
The main requirement for the “iron” part of the future Tinkoff ATM was support for the cash recycling function. The ATM with this option works in a closed cycle, accepts and issues money from one cassette and, as a result, works longer without collection services. In addition, this device must fully support NFC, read QR codes and have a large touch screen.
Along with the search for a hardware solution, we took up software issues.
From the point of view of the programmer, an ATM is a client terminal that independently manages only the equipment connected to it, and the server handles the processing of operations.
For the interaction of an ATM computer with a card reader, pin pad, recycler and other peripherals, as well as for the organization of "communication" with the server, there are long-developed standards and protocols. They severely 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 realize much of what Tinkoff's team had planned.
Initially, we planned to abandon the eXtension For Financial Services (XFS) standard, which describes the logic of managing ATM equipment, in favor of our own Linux-based solution. With it, one could achieve multi-platform. But this idea had to be rejected, since no ATM manufacturer wanted to agree to intervene in the ATM equipment drivers at such a deep level.
Therefore, we involved a contractor, a company that had experience in developing .NET software for payment terminals, to create management software, integrate an ATM with a server and write an API to create various scenarios for using an ATM.
Instead of the Windows XP installed in the competitors' solutions, the ATM received 64-bit Windows 10. The fresh OS provided more opportunities for implementing a visually attractive and responsive interface, which resembles the one implemented in our mobile application, both externally and according to usage scenarios.
Everyone who regularly uses ATMs knows the standard menus that offer you to choose 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 an ATM and a server (host).
To get rid of these atavisms, I had to change the protocols to an original flexible and modern solution that would connect the ATM to the server part entirely written in Java.
At the very beginning, colleagues from other companies told us that we were crazy as soon as we stuttered that we want to get away from the standard NDC / DDC protocols. But time has already judged us.
Of course, almost all of these changes in the bowels of the software are invisible to the client, however, he will easily distinguish Tinkoff ATM from others not only on the screen and menu - software processing has 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 their 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, supports replenishment and withdrawal of funds.
Another previously impossible way to interact with an ATM is quick cash. So we call the issue of money using the QR code generated in your account via the bank’s mobile application. It is enough to scan the smartphone screen and pick up the required amount without any queues and delays with the search for a card, entering a PIN code and navigating through the menu.
In addition, our team managed to eliminate yet another virtual obstacle restricting ATM users. Now, having logged in to the ATM in any way convenient for him, the Tinkoff Bank client gets access to all his cards and accounts from a single personal account. So, for example, by inserting a debit card into an ATM and finding that there are not enough funds on it, you can immediately withdraw money from a credit card left at home.
When creating new ATMs, we paid much attention to optimizing back-office processes: management, monitoring, the system for distributing updates, after-sales service and collection.
Of course, there are standard solutions for all these operations, but they have the same disadvantages as in the NDC / DDC protocols. These solutions do not lend themselves to customization and fine-tuning. They are simply uncomfortable.
Collection is a separate user script that runs 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 instructions for the employee performing the replacement of cassettes with money are displayed on the ATM screen. Having reduced the number of actions performed by the collector, we reduced the number of human errors and accelerated the process of collection.
The servers track the counters of cassettes with money, which in the future will automate the sending of applications 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, more cash may be withdrawn from it or, on the contrary, to replenish cassettes faster than they are empty. Sooner or later, there is a need for collection.
Gathering information on how various factors affect customer behavior, and tracking the dynamics of the use of ATMs in the Tinkoff network, we are developing a technology that allows us to predict how soon it will be necessary to refill or empty the ATM. Thus, it is possible not only to save on regular departures of collectors, but also to increase the availability of services, eliminating the situation in which the ATM is idle waiting for service.
In the future, the collection prediction will partially shift this task to the bank's customers by managing customer flows. These schemes are being developed. The essence of the idea is to stimulate our customers to withdraw funds from overcrowded ATMs and, on the contrary, to replenish accounts at ATMs, where there is very little cash left.
We also solved the problem with updating the internal software. Releases come out once every two weeks and are rolled automatically, while most banks in the market update software at best once a year. And the process itself is quite troublesome.
Another point. We were able to greatly reduce the time it takes to parse claims from customers. Work with the problem begins immediately after treatment.
All the necessary information is transmitted by the ATM to the server, automatically, is readable and 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 obtain certificates from VISA and MasterCard payment systems, a separate team had to be allocated, and yet in June 2017 the prototype of our ATM was ready. Considering what we started in January, it turned out very quickly.
A team of testers was actively involved in the test development. Then the ATM was installed in the business center, and all our employees got access to it. Although testers did an important job of catching most of the critical bugs, some bugs only surfaced during the internal testing phase. Moreover, it was practically impossible to predict the appearance of certain problems in advance.
So, in one case, the scenario for depositing cash into an ATM did not work. Viewing the operation logs did not give anything, the bug was not reproduced. It was possible to find out what was happening only after viewing the recordings from the surveillance cameras.
It turned out that the client logged in to his personal account and took out the bill from the wallet, put it on an NFC reader. Inside the wallet, the ATM found other cards, and the cash deposit scenario, in which such a development was not taken into account, broke.
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 easily fixed. For example, it turned out that people tend to ignore instructions and act mechanically. As an example, let’s give a case in which a client who wants to replenish Tinkoff Bank’s account without a card by the contract number, instead of clicking the “replenish” button, selects “pay”. So he gets into a dialogue where he is invited to choose which of the popular electronic transfer systems or to which account of a mobile operator should transfer funds. The customer selects Qiwi and enters the account number at Tinkoff Bank in the field designated for the telephone. Moreover, Qiwi accepts such a transfer and puts money into some of its technical accounts for further proceedings.
Of course, such an erroneous operation can be recalled and the money returned to the client, but when this happens several times a week, it is obvious that something is wrong with the interface. The introduction of a mask helped to solve the problem, which does not allow anything other than a mobile phone to be indicated in the unfortunate input field.
We ourselves believe that our story with ATMs has just begun. In fact, we got an absolutely unique product only because we did not listen to exclamations such as “how will you even live without the standard NDC / DDC protocols”. Although all sorts of difficulties, of course, were.
ATM card
So far 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 further 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 managed to accumulate.
The idea to automate the cash withdrawal process came up with John Shepherd-Barron. In 1967, this Scottish inventor managed to convince the management of London's Barclays Bank that while the bank is closed for the weekend, a machine can serve customers. Since then, this idea has taken root everywhere, and the functionality of ATMs has expanded from a simple cash out 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 customers, 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 did not want to use standard solutions, since all of them were clamped by the protocol framework and the long-aging Windows XP OS, which was the core of the vast majority of them.
So, we started by finding the right hardware.
ATM hardware base
The brainchild of Shepherd-Barron in design was not much more complicated than the vending machine, which inspired the inventor. But modern ATMs are computer terminals that combine a wide 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 receives banknotes, a receipt printer, and a set of sensors that monitor the correct functioning of the subsystems ATM
The main requirement for the “iron” part of the future Tinkoff ATM was support for the cash recycling function. The ATM with this option works in a closed cycle, accepts and issues money from one cassette and, as a result, works longer without collection services. In addition, this device must fully support NFC, read QR codes and have a large touch screen.
ATM software
Along with the search for a hardware solution, we took up software issues.
From the point of view of the programmer, an ATM is a client terminal that independently manages only the equipment connected to it, and the server handles the processing of operations.
For the interaction of an ATM computer with a card reader, pin pad, recycler and other peripherals, as well as for the organization of "communication" with the server, there are long-developed standards and protocols. They severely 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 realize much of what Tinkoff's team had planned.
Initially, we planned to abandon the eXtension For Financial Services (XFS) standard, which describes the logic of managing ATM equipment, in favor of our own Linux-based solution. With it, one could achieve multi-platform. But this idea had to be rejected, since no ATM manufacturer wanted to agree to intervene in the ATM equipment drivers at such a deep level.
Therefore, we involved a contractor, a company that had experience in developing .NET software for payment terminals, to create management software, integrate an ATM with a server and write an API to create various scenarios for using an ATM.
Instead of the Windows XP installed in the competitors' solutions, the ATM received 64-bit Windows 10. The fresh OS provided more opportunities for implementing a visually attractive and responsive interface, which resembles the one implemented in our mobile application, both externally and according to usage scenarios.
Everyone who regularly uses ATMs knows the standard menus that offer you to choose 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 an ATM and a server (host).
To get rid of these atavisms, I had to change the protocols to an original flexible and modern solution that would connect the ATM to the server part entirely written in Java.
At the very beginning, colleagues from other companies told us that we were crazy as soon as we stuttered that we want to get away from the standard NDC / DDC protocols. But time has already judged us.
What's new for customers
Of course, almost all of these changes in the bowels of the software are invisible to the client, however, he will easily distinguish Tinkoff ATM from others not only on the screen and menu - software processing has 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 their 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, supports replenishment and withdrawal of funds.
Another previously impossible way to interact with an ATM is quick cash. So we call the issue of money using the QR code generated in your account via the bank’s mobile application. It is enough to scan the smartphone screen and pick up the required amount without any queues and delays with the search for a card, entering a PIN code and navigating through the menu.
In addition, our team managed to eliminate yet another virtual obstacle restricting ATM users. Now, having logged in to the ATM in any way convenient for him, the Tinkoff Bank client gets access to all his cards and accounts from a single personal account. So, for example, by inserting a debit card into an ATM and finding that there are not enough funds on it, you can immediately withdraw money from a credit card left at home.
Optimization of back office processes
When creating new ATMs, we paid much attention to optimizing back-office processes: management, monitoring, the system for distributing updates, after-sales service and collection.
Of course, there are standard solutions for all these operations, but they have the same disadvantages as in the NDC / DDC protocols. These solutions do not lend themselves to customization and fine-tuning. They are simply uncomfortable.
Collection
Collection is a separate user script that runs 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 instructions for the employee performing the replacement of cassettes with money are displayed on the ATM screen. Having reduced the number of actions performed by the collector, we reduced the number of human errors and accelerated the process of collection.
The servers track the counters of cassettes with money, which in the future will automate the sending of applications 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, more cash may be withdrawn from it or, on the contrary, to replenish cassettes faster than they are empty. Sooner or later, there is a need for collection.
Gathering information on how various factors affect customer behavior, and tracking the dynamics of the use of ATMs in the Tinkoff network, we are developing a technology that allows us to predict how soon it will be necessary to refill or empty the ATM. Thus, it is possible not only to save on regular departures of collectors, but also to increase the availability of services, eliminating the situation in which the ATM is idle waiting for service.
In the future, the collection prediction will partially shift this task to the bank's customers by managing customer flows. These schemes are being developed. The essence of the idea is to stimulate our customers to withdraw funds from overcrowded ATMs and, on the contrary, to replenish accounts at ATMs, where there is very little cash left.
Regular software updates
We also solved the problem with updating the internal software. Releases come out once every two weeks and are rolled automatically, while most banks in the market update software at best once a year. And the process itself is quite troublesome.
Customer Request Processing
Another point. We were able to greatly reduce the time it takes to parse claims from customers. Work with the problem begins immediately after treatment.
All the necessary information is transmitted by the ATM to the server, automatically, is readable and 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.
Prototype Testing: The First Bumps
To obtain certificates from VISA and MasterCard payment systems, a separate team had to be allocated, and yet in June 2017 the prototype of our ATM was ready. Considering what we started in January, it turned out very quickly.
A team of testers was actively involved in the test development. Then the ATM was installed in the business center, and all our employees got access to it. Although testers did an important job of catching most of the critical bugs, some bugs only surfaced during the internal testing phase. Moreover, it was practically impossible to predict the appearance of certain problems in advance.
So, in one case, the scenario for depositing cash into an ATM did not work. Viewing the operation logs did not give anything, the bug was not reproduced. It was possible to find out what was happening only after viewing the recordings from the surveillance cameras.
It turned out that the client logged in to his personal account and took out the bill from the wallet, put it on an NFC reader. Inside the wallet, the ATM found other cards, and the cash deposit scenario, in which such a development was not taken into account, broke.
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 easily fixed. For example, it turned out that people tend to ignore instructions and act mechanically. As an example, let’s give a case in which a client who wants to replenish Tinkoff Bank’s account without a card by the contract number, instead of clicking the “replenish” button, selects “pay”. So he gets into a dialogue where he is invited to choose which of the popular electronic transfer systems or to which account of a mobile operator should transfer funds. The customer selects Qiwi and enters the account number at Tinkoff Bank in the field designated for the telephone. Moreover, Qiwi accepts such a transfer and puts money into some of its technical accounts for further proceedings.
Of course, such an erroneous operation can be recalled and the money returned to the client, but when this happens several times a week, it is obvious that something is wrong with the interface. The introduction of a mask helped to solve the problem, which does not allow anything other than a mobile phone to be indicated in the unfortunate input field.
The tale will be ahead
We ourselves believe that our story with ATMs has just begun. In fact, we got an absolutely unique product only because we did not listen to exclamations such as “how will you even live without the standard NDC / DDC protocols”. Although all sorts of difficulties, of course, were.
So far 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 further 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 managed to accumulate.