How we boosted banking app: fraudsters gone or being trapped

As a product person, you don’t casually build features, but solve the real-worlds problems, and those issues could be split into two types: the one that brings the value and add up to the overall experience in different ways, and other ones that helps to protect and ensure safe usage of the service for the company clients.

One of the key differences in fintech is that you not only create stuff that balances out these two sides of the spectrum, but also need to be aware of heavy cost coming with compliance, security, legal issues. It includes fines, suspending the licenses, dealing with frustrated customers. So, things could go south fast.

Regular check-ins with other team members of Security and Safety committee revealed concerning trend of fraudsters obtaining accesses to the banking accounts and moving the money out. Most of the data came from Customer Support speaking with frustrated users who found their accounts were fully drained.

The taskforce to fight this problem was formed, and we locked ourselves in a war-room to brainstorm solutions. Some of an intel suggested that there were leakages. Besides, group also discovered targeted social engineering attacks: fraudsters would disguise as a company staff, police or government employees.

Group carefully considered dimensions: damage, ease of performing. Then decided to start with an actor:

1. Errors – system malfunction that led to undesirable activity.
2. Fraud – when someone got an unauthorized access to the client’s data.
3. Scam –A legitimate account holder being tricked to willingly provide sensitive information.

Fraud cases were selected as the first stage, team investigated elimination of the root cause, but it seemed that sources of attacks were distributed, not related to each other. Another factor pushing the team to find a quicker solution was timing: cases spike twice a month around salary advance time and payday itself.

After reviewing the calendar, we realized we were approaching the latter phase, so the preference was given to a technical solution. Following an evaluation of various options, the taskforce finally decided to implement a stage solution that blocks secondary devices unless explicitly whitelisted by the customer.

There are multiple things that you can collect from the device, like it’s unique ID, IMEI, then combine it with user credentials. The idea was: if we see a new combination in the system, it would be considered suspicious and will be suspended immediately. Data showed that the risk of false positives was bearable.

The first issue that the team faced was that the device ID wasn’t tracked. Immediately a quick update was introduced, allowing to capture this data and sending it to the backend. As our check-ins were conducted regularly, it was quite visible that the updates were not being rolled out as fast as was expected initially.

Next step was to do the force updates. Logging people out would also help to increase the conversion. To make the process smoother, the userbases were split into few groups with different sizes, so that the changes could be applied gradually to them. To factor in and mitigate risk, first batch was the smallest one.

The second issue was the probability of false positives cases. The person, who got their id registered first might be a fraudster, while the second device could belong to the real user. Approximately, there would be around 15% of such cases. To support resolving it, the Customer Support tool was upgraded accordingly.

The entire plan with steps was shared with stakeholders to ensure there is nothing missing. Detailed instruction of what to do and how to communicate was shared with people on the hotline along with a quick demo of how to use updates in their tool. The tracking for unblocking events was also added as the hotfix.

Speed factor was crucial, hence team also made sure the changes would roll-out fast. Often this process involves fundamental changes in the app, so this was taking into an account by making sure we start publishing updated version soonest to face all possible issues with submission to stores and code review.

Including all relevant parties in the loop was the priority, hence the teams on the ground also get their instructions and were provided with abilities to resolve false positives on the spot, during the onboarding and KYC-ing customers or resolving their cases as they would come to them during the regular catch-ups.

On the app itself the blocking was not displayed explicitly. User would see a message saying there is an issue and suggesting contact the bank. Funny enough, there were calls from fraudsters, who were brave enough to get in touch and request unblocking accounts. This is how a feature “Block ID” was introduced.
 

As the changes were hitting the production, all taskforce members worked close exchanging data in a real time, collecting user’s feedback, see the number of updated devices, tracking false positive cases, analyse details of compromised accounts to not only solve tactical tasks, but have info for all strategic decisions.

When the last milestone was hit, we had a neat report ready. The roll-out of all existing devices was done completely. All future installs were equipped with a proper tracking. The fraud cases of this type decreased down to 0.3% percent. There was an assumption these are remaining case of non-reported false positives.

Sharing lessons learnt within the company was held, as it is crucial part helping to summarise, present finding, adds the transparency and offers others departments an opportunity to provide their perspective to the problem leading to constructive conversations and building better solutions for the business itself.

There were other ideas of how to improve things further. The bad guys could be stopped at different stages: unusual location, transaction, amount, time. The patterns of phone usage, digital “portraits”, creating a base of the “known suspects” to potentially collaborate with other institutions to exchange, enrich the data.