November 23, 2016 at 18:34How did we make a bot for Otkritie Bank
Recently, Otkritie Bank and I launched a banking bot with payment functions for individuals on Facebook Messenger . Now Otkritie’s customers can pay for mobile communications, using the bot you can find the nearest ATM or bank office, find out the exchange rate, find out how to order a card, call the bank and sign up for payment from the Deposit Insurance Agency. In this article we will talk about working on a project.
Getting started, we thought about situations when it would be more convenient for the user to interact with the bot, and not with the main mobile application. The list of bot benefits is as follows:
But of course, in comparison with the application, the bot has a number of serious limitations:
After analyzing the situations of interaction between the bot and the user, we compiled a list of potential functionality:
Informational functionality
Operations
Other
NLP (Natural language processing) for query processing
Of course, all this could not fit in the first release, and in the end we settled on the following MVP:
Informational functionality
Operations + Balance
Other
However, we immediately decided that the payment functions would be implemented in a “universal” way, in order to subsequently connect other counterparties.
Alexander Nesterov, Opening Digital, product owner
“Of course, the bot will not replace our support service, mobile application or online banking, but some simple questions and regular tasks are easier and more convenient to solve in the familiar messenger interface. Therefore, the bot is another additional channel for servicing our customers, which makes communication with the bank even more convenient and affordable. ”
Initially, we planned to make a bot with NLP, but in the end we abandoned this idea. The linguistic processing platforms we experimented with - WIT.AI (owned by Facebook) and API.AI (a Russian startup in Silicon Valley, which Google bought just a month ago) - cope with the Russian language frankly poorly. Living users are asking the bot not at all the questions that he expects to hear, so in more than 50% of cases the system does not give relevant answers, and users are upset.
Arthur Sakharov, CTO of Redmadrobot
“So far, the definition of synonyms and machine learning almost do not work in these systems. With those specific phrases for which the engine is trained, there are no problems. But a step to the side - and your bot does not understand at all that he wants it. And API.AI is insanely expensive for the functionality that is there, but we did not plan to develop our own NLP system for the first launch. Despite the fact that in the end we nevertheless made the choice in favor of a “push-button” bot, two fully working prototypes with our backend and linguistic processing - both in Telegram and Facebook Messenger, were sawn down. ”
These prototypes are:
Telegram has a certain number of banking bots, but all of them are limited in capabilities due to the security features of this messenger. When choosing a platform for launching the Otkritie Bank bot bot, we evaluated both the security and the popularity of instant messengers. Of the messengers that support the creation of full-fledged bots, Facebook Messenger occupies the first place in popularity in Russia. According to TNS Russia , it is five times more popular than Telegram.
Messenger has many important security features that Telegram lacks: access control for administrators, two-factor account authentication, user authorization with sending confirmation to our server through the second channel. At the time of the creation of the system, there was not even a reliable way to determine who sends messages to your backend: telegrams or an attacker's http client. Unlike Telegram, the security of accounts, administration and messages for bots were immediately laid down in the Facebook platform. Telegram has a number of bank bots, but none of them have authorization and payments. Everywhere it is only informational functionality such as ATMs and shares: AlfaBank, Raiffeisen, Sberbank, Promsvyazbank, AK Bars, Rosbank. Rocketbank (@rocketbank_bot) had its payment bot,
There are several ways to securely log in to Facebook. We used this: when a user wants to log in, the bot asks him to enter the code, which must be obtained through the mobile application.
It is appropriate to note that authorization in a bot requires a bank application, and this may seem strange: usually, authorization is done through Internet banking. However, this is strange only for those banks where a lot more customers use the web version than the application. Now the audience of messengers lives mainly in mobile, so authorization through a mobile application is logical.
The user can request through the bot information about his accounts. But there is also a mobile application that accesses the Otkritie Bank API for the same data. To do without improvements on the Discovery side, we simply used a ready-made API and sent a request there from our backend - the same as it would be from a mobile application.
In fact, the system is the same as with the accounts: when the user wants to put money on the phone, behind the scenes in “Opening” a request arrives according to the API specification for the mobile application. The backend of the bot itself transforms the program interface of the supplier payment schemes into a dialogue interface for communicating with users.
The Discovery CRM system stores information on payments from the Deposit Insurance Agency - when and in which banks there are free slots for recording payments. When a client via Facebook says that he needs to record, the backend could theoretically get directly into the bank’s network, but for security reasons, the system was implemented differently.
The problem is solved using the queue in which we put the requests. For example, “I need to get free time for recording for such and such an office.” The internal system itself checks the queue once every few seconds and collects the data, previously validating and checking it, processes the requests and puts the data back into the queue, from where our back-end picks them up. Thus, we distribute these systems and can do without direct connections to local databases.
I must say, the service is popular among users - in the first days of payment, several hundred people record.
At the moment, the system works like this. In the future, we plan to expand the capabilities of the bot - to improve the authorization mechanism and introduce payment according to templates.
What does the bot have under the hood?
Getting started, we thought about situations when it would be more convenient for the user to interact with the bot, and not with the main mobile application. The list of bot benefits is as follows:
- Available for all customers and non-bank customers
- No need to install anything
- Easy to login
- Can be embedded on the website and in the self-service terminal
- Cross-platform
But of course, in comparison with the application, the bot has a number of serious limitations:
- Third party environment
- Limited visualization quality
- Non-realtime system and less responsiveness, for example, when choosing a financial product
- Cannot work with complex data
- Not visible all available options
After analyzing the situations of interaction between the bot and the user, we compiled a list of potential functionality:
Informational functionality
- Currency Rates
- ATMs and offices
- Bank details and about
Operations
- Login
- Patterns
- Recharge Phone
- Translations
- Auto Payments
Other
- Card Order
- DIA (this is payments to customers of other banks through the Deposit Insurance Agency)
- Push notifications about operations and other events
- Switch to live operators
- Queuing at offices
- news
- Feedback
NLP (Natural language processing) for query processing
Of course, all this could not fit in the first release, and in the end we settled on the following MVP:
Informational functionality
- Currency Rates
- ATMs and offices
- Bank details and about
Operations + Balance
- Login
- Recharge Phone
Other
- Card Order
- DIA
However, we immediately decided that the payment functions would be implemented in a “universal” way, in order to subsequently connect other counterparties.
Alexander Nesterov, Opening Digital, product owner “Of course, the bot will not replace our support service, mobile application or online banking, but some simple questions and regular tasks are easier and more convenient to solve in the familiar messenger interface. Therefore, the bot is another additional channel for servicing our customers, which makes communication with the bank even more convenient and affordable. ”
Natural Language Processing vs. buttons
Initially, we planned to make a bot with NLP, but in the end we abandoned this idea. The linguistic processing platforms we experimented with - WIT.AI (owned by Facebook) and API.AI (a Russian startup in Silicon Valley, which Google bought just a month ago) - cope with the Russian language frankly poorly. Living users are asking the bot not at all the questions that he expects to hear, so in more than 50% of cases the system does not give relevant answers, and users are upset.
Arthur Sakharov, CTO of Redmadrobot“So far, the definition of synonyms and machine learning almost do not work in these systems. With those specific phrases for which the engine is trained, there are no problems. But a step to the side - and your bot does not understand at all that he wants it. And API.AI is insanely expensive for the functionality that is there, but we did not plan to develop our own NLP system for the first launch. Despite the fact that in the end we nevertheless made the choice in favor of a “push-button” bot, two fully working prototypes with our backend and linguistic processing - both in Telegram and Facebook Messenger, were sawn down. ”
These prototypes are:
Why Facebook Messenger
Telegram has a certain number of banking bots, but all of them are limited in capabilities due to the security features of this messenger. When choosing a platform for launching the Otkritie Bank bot bot, we evaluated both the security and the popularity of instant messengers. Of the messengers that support the creation of full-fledged bots, Facebook Messenger occupies the first place in popularity in Russia. According to TNS Russia , it is five times more popular than Telegram.
Messenger has many important security features that Telegram lacks: access control for administrators, two-factor account authentication, user authorization with sending confirmation to our server through the second channel. At the time of the creation of the system, there was not even a reliable way to determine who sends messages to your backend: telegrams or an attacker's http client. Unlike Telegram, the security of accounts, administration and messages for bots were immediately laid down in the Facebook platform. Telegram has a number of bank bots, but none of them have authorization and payments. Everywhere it is only informational functionality such as ATMs and shares: AlfaBank, Raiffeisen, Sberbank, Promsvyazbank, AK Bars, Rosbank. Rocketbank (@rocketbank_bot) had its payment bot,
Authorization and integration with banking infrastructure
There are several ways to securely log in to Facebook. We used this: when a user wants to log in, the bot asks him to enter the code, which must be obtained through the mobile application.
It is appropriate to note that authorization in a bot requires a bank application, and this may seem strange: usually, authorization is done through Internet banking. However, this is strange only for those banks where a lot more customers use the web version than the application. Now the audience of messengers lives mainly in mobile, so authorization through a mobile application is logical.
Getting invoice data
The user can request through the bot information about his accounts. But there is also a mobile application that accesses the Otkritie Bank API for the same data. To do without improvements on the Discovery side, we simply used a ready-made API and sent a request there from our backend - the same as it would be from a mobile application.
Payment for services
In fact, the system is the same as with the accounts: when the user wants to put money on the phone, behind the scenes in “Opening” a request arrives according to the API specification for the mobile application. The backend of the bot itself transforms the program interface of the supplier payment schemes into a dialogue interface for communicating with users.
Record for payment from the DIA
The Discovery CRM system stores information on payments from the Deposit Insurance Agency - when and in which banks there are free slots for recording payments. When a client via Facebook says that he needs to record, the backend could theoretically get directly into the bank’s network, but for security reasons, the system was implemented differently.
The problem is solved using the queue in which we put the requests. For example, “I need to get free time for recording for such and such an office.” The internal system itself checks the queue once every few seconds and collects the data, previously validating and checking it, processes the requests and puts the data back into the queue, from where our back-end picks them up. Thus, we distribute these systems and can do without direct connections to local databases.
I must say, the service is popular among users - in the first days of payment, several hundred people record.
What is the result
At the moment, the system works like this. In the future, we plan to expand the capabilities of the bot - to improve the authorization mechanism and introduce payment according to templates.