How to reduce pain points in the digital transaction journey?

News & Publications > Blog

Posted on 17.02.2020 at 15:57

Drawing upon our previous discussion on what modern principles lies in building security solutions for banks and their clients, we noted that these technologies must be as simple as possible and secured-by-design to meet modern demands and needs. This helps to simplify processes for all parts of the business cycles – bank’s business divisions, information security departments, end-users and juridical divisions.

In this blog post, we will discuss about the communications flow between banks and their end-users in a remote banking system. For example, if a user wants to transfer his funds from his account to another through a remote banking system, it is highly important both for him and the bank to prove that this is exactly what this specific user wants to do.

A common way to do this is through two-factor authentication (2FA) systems, with instruments like SMS, OTP, Push-codes, hardware tokens, OTP-generators and so on. However, these instruments either have a weak security protocol or they are very inconvenient. Additionally, they can be overpriced.

To tackle these issues, Airome Technologies developed PayConfirm – a software platform that assists users to confirm digital transactions through “just one tap” on a smartphone to replace expensive, non-secure and inconvenient confirmation methods.

One of the main design principles that guided the development of PayConfirm was to simplify the security solution from all points of view.

Confirming digital transaction through “just one tap” has shown excellent results. However, there is still room for improvement. As modern technologies continuously innovate to provide increased convenience in our lives – such as auto-drive systems and voice assisted technologies like Alexa – users continuously demand for a system that will help reduce much of the friction that goes on in their day to day life.

With PayConfirm, we can provide a process known as “frictionless authentication”. This means we can try to decide if a user wants to conduct transaction via his e-banking account without the need to disturb him at all.

As mentioned in our previous blog post, PayConfirm consists of two parts: server and the mobile client

Consisting of a secured communication channel with the server, the mobile client works through the user’s smartphone by collecting a series of information pertaining to the user and their smart device for security purposes. This information includes: the device location, if the device has been rooted or not, or if there is some suspicious software installed and other parameters.

On the other hand, the PayConfirm server system can determine usual and common user’s actions. This include but not limited to: payees for user’s transactions, the usual transaction amount for transfers, the location a user connects from.

Using all this data with some level of probability, we can determine the risk level for a concrete transaction or user’s action.

For example, if monthly transactions are made to pay off bills, it is considered a low-risk operation.

However, when a user logs in to their accounts using PayConfirm from an unusual location (for example, another country), it is considered a medium risk operation – despite not managing any form of funds – and the system will keep an eye out.

When a user transfers all their money to a suspicious offshore bank account and tries to confirm this action with a rooted device, the system will flag the transaction as a high-risk operation.

Utilising this risk model – based on the information collect from the user’s device and user behavior – the system can determine if it is necessary to disturb our user or not. However, we still should remember about a juridical side of the interaction which requires us to receive confirmation from the user even if the risk level is low.

In PayConfirm we implemented an “adoptive” authentication with the described principles. PayConfirm server has five risk levels for each transaction: no risk, low, medium, high and critical. PayConfirm can determine transaction’s risk level using all the collected and known information. If a transaction presents no risk, it sends signal to the user’s mobile device to confirm the transaction in a “silent mode”.

Briefly, PayConfirm uses the following risk level model:

• When a mobile device receives push-notification in the background, PayConfirm’s libraries will calculate a cryptographic digital signature for the transaction with a specialized “auto-confirm private key”. The app will also collect information about the device and send all this data to the PayConfirm server. The server will further analyze the risk level, verify the signature and decide to accept confirmation or not.
• If there is no risk – no any actions needed. The transaction is automatically confirmed.
• When the server detects either low or medium risk level – it will notify the user to check their transaction details via the mobile app, look to transaction details and tap to confirm the transaction.
• When a risk level is high, users must provide an additional authentication factor. PayConfirm will request an additional “code-word” or through a biometrical verification factor such as face recognition with liveness detection.
• When risk level is critical, confirmation will be declined.

Based on analysis, most daily transaction operations tend to fall in the no-risk level bracket. In other words, users are not required to manually confirm transactions or actions. These operations will be confirmed with their credentials automatically, without any actions.

Additionally, the technology is not restrictive. Users can further manually authorise unusual transactions. Moreover, in an event if something wrong happens – PayConfirm will be able to secure the users funds.

To sum up, PayConfirm was designed to ensure that digital transaction processes are highly secured, no matter the circumstances. This in turn has make what was once a painful authorisation process into a seamless experience for users.