Protections for mobile apps must have the capability to recognize and block the tools that criminals use and abuse to commit fraud.
By Karen Hsu
The global COVID-19 pandemic forced consumers to find contactless ways to take care of shopping, banking and other transactions, and many turned to mobile apps. A new way of doing things that seems to have stuck. Nearly 60 percent of mobile consumers said that they use and download a greater number of mobile apps and are using them to purchase more goods and services since early 2020, according to the Appdome 2021 Global Mobile Security Survey. Payment apps such as Venmo, Zelle, ApplePay and other fintech or mobile-based peer-to-peer consumer apps are seeing exponential growth.
Regulators have taken note. They have issued regulations and guidance to create standards that financial app makers need to meet to ensure that consumers are properly protected.
In the US, the Federal Financial Institutions Examination Council and the Federal Crimes Enforcement Network have laid out detailed regulations governing which and how mobile financial applications are to be protected. Banks that publish financial apps must be familiar with these regulations and create plans to make sure that they comply with the Bank Secrecy Act and can satisfy an FFIEC examination.
Compliance with BSA
The May 2019 FinCEN guidance further detailed the regulatory requirements for mobile wallets and other applications with similar functionality. Non-compliance can be extremely expensive and in some cases could result in prison time, so financial app publishers should definitely take these regulations seriously.
The BSA/AML regulations lays out the primary requirements that organizations must meet:
- Maintain effective know your customer and AML programs.
- For each transaction over $10,000, file a currency transaction report.
- When the organization suspects or knows that transactions may involve money laundering or represents attempts to evade BSA requirements, file suspicious activity reports.
Mobile apps: Ensuring BSA compliance and passing FFIEC examinations
“FFIEC IT Examination Handbook” is published by the FFIEC to assist technology service providers, financial institutions and examiners with identifying and controlling the risks that retail payment systems and related banking activities may face.
A new appendix was added by the FFIEC in 2016 that is specifically for mobile applications, detailing the main risks that they carry. In broad terms, they include:
- The ability for consumers and other end-users to download applications from app stores that not authorized by the manufacturer and may contain malicious code
- Applications acting as a vector for the delivery of malware
- The ability of end-users to run financial apps on rooted (Android) or jailbroken (iOS) devices in order to access root user privileges and remove the manufacturer’s device controls. Doing so could result in the user using untrusted sources to download apps which could install malware onto the device
- Unencrypted storage of personal information on the device or in the app, such as email addresses, passwords and usernames
- Unsecured secrets, tokens and URLs that can provide hackers with unauthorized access to back-end databases.
To comply with FFIEC and BSA regulation, mobile app publishers need to integrate fraud prevention and cybersecurity protections in their development, security and operations processes to ensure that they can regularly add new security protections into their new and updated Android and iOS apps. When combined with sufficient automation, DevSecOps enables organizations to avoid having to make terrible decisions about whether to delay the app, cut new features or release apps with unaddressed security vulnerabilities. It can do this because operations, security and development are synchronized and coordinated into a continuous workflow.
Security measures that enable compliance
Compliance requires a number of fundamental protections built into an app. For starters, a mobile app’s protections must be able to recognize and block the tools that criminals use and abuse to commit fraud. Most commonly, fraudsters abuse common developer tools that enable dynamic instrumentation, code injection, script injection, accessibility abuse and method hooking—all of which enable them to interfere with or modify the app. By blocking these functions, developers can deprive fraudsters of their tools of the trade, stopping fraud before it starts.
Additionally, the protections inside an app should prevent anyone from copying, altering, repackaging and resigning the app. This will help protect against many exploits, including weaponizing the app by creating a Trojan app that looks like the original and and generally mimics the original user experience. But they carry malicious code that can enable criminals to take over financial accounts and steal sensitive information.
A further tactic that hackers use is to elevate their permissions on the device by rooting (Android) or jailbreaking (iOS) it, which enables them to manipulate the financial apps that run on it. When an app is operating in a rooted / jailbroken environment, the app’s protections should be able to recognize the threat and shut down to protect itself.
Another fundamental protection for a financial app is strong encryption, which usually means encryption via the AES 256 standard. Often, protections in financial apps only encrypt data when it’s in the application sandbox, which is a protected area where applications run within the mobile device. However, this isn’t sufficient to protect data in the financial app. There are many other places where hackers can extract data if it’s left in the clear, most notably in an app’s code. The app needs to encrypt data in the strings, preferences, resources, in-app secrets and much more.
Data in an app’s code is especially sensitive because it includes login credentials, security certificates, back-end server URLs and keys that enable the app to connect to other services. With this data, hackers can successfully mount devastating attacks that target a financial institution’s core systems. They, too, must be protected using strong cryptographic protocols.
Protecting data within code, however, is particularly difficult to implement in a way that doesn’t negatively impact the app, and incorporating the other protections listed above requires a great deal of complicated, manual coding. Software development kits can reduce the amount of manual work that would be required starting from scratch, but they’re far from plug-and-play solutions. They can require a great deal of manual coding, which may be beyond the skills and resources of many development teams. Plus, these tools themselves may contain vulnerabilities, as they often depend on many layers of libraries and other code which could threaten compliance.
There are now, however, AI-powered, no-code platforms that can integrate security into the app, which saves time and increases precision and protection. When integrated into a development organization’s DevSecOps’ process, organizations can incorporate strong security without having to make trade-offs with their release schedule or app functionality.
Whatever choices are made regarding security implementation and anti-fraud protections, these are not areas where banks can afford to skimp. The risk of fraud and non-compliance is simply too large.
Karen Hsu is CMO of Appdome. She previously served as CEO of BlockchainIntel, which she co-founded. She also co-founded the non-profit Blockchain By Women.
