Thanks in large part to the global pandemic, consumers are increasingly turning to mobile apps to manage their finances, payments and transactions. In fact, 58% of mobile consumers report using and downloading more mobile apps and buying more products and
services on them since the COVID-19 pandemic started, according to the
Appdome 2021 Global Mobile Security Survey. Zelle, Venmo, ApplePay and other fintech or mobile based Peer-to-Peer (P2P) solutions are exploding.
Regulators are paying attention, issuing guidance and regulations governing the standards financial app makers need to meet for consumer protection. In the US, the Federal Crimes Enforcement Network (FinCEN) and the Federal Financial Institutions Examination
Council (FFIEC) have detailed specific ways in which mobile financial applications need to be protected. Publishers of financial apps need to be aware of these regulations and develop strategies to ensure they are Bank Secrecy Act (BSA) compliant and can pass
FinCEN’s May 2019 guidance clarified the regulatory treatment for mobile wallets and similar applications, and the consequences of non-compliance can be costly, up to and including imprisonment.
Compliance with the BSA/Anti-Money Laundering (AML) regulations requires organizations to complete four primary tasks:
Maintain an adequate AML and Know Your Customer (KYC) program;
File Currency Transaction Reports (CTRs) for transactions over $10,000;
File Suspicious Activity Reports (SARs) when the organization “knows, suspects, or has reason to suspect that the transaction involves money laundering, is designed to evade the requirements of the BSA;” and
Register with the Department of Treasury.
FFIEC examinations, BSA compliance and mobile apps
In the US, the FFIEC encompasses five banking regulators: the Federal Reserve Board of Governors (FRB), the Federal Deposit Insurance Corporation (FDIC), the National Credit Union Administration (NCUA), the Office of the Comptroller of the Currency (OCC),
and the Consumer Financial Protection Bureau (CFPB). The FFIEC publishes the FFIEC IT Examination Handbook (IT Handbook) to provide guidance to examiners, financial institutions, and technology service providers on identifying and controlling risks associated
with retail payment systems and related banking activities.
In 2016, the FFIEC added a new appendix to its IT Examination Handbook specifically for mobile applications, and it details the primary risks associated with them:
The ability to download applications for application stores not authorized by the manufacturer that have malicious code
Distribution of malware through applications
End user’s ability to access root user privileges (e.g. rooting) or removing the manufacturer’s device controls (e.g. jailbreaking), which may lead to the user downloading apps from untrusted sources and introducing malware onto the device in the process
Personal information, including usernames, passwords, email addresses are stored in the clear
Access to back-end databases using information gathered through mobile apps that have not been properly secured
Mobile app publishers must build security and fraud prevention into DevSecOps to comply with BSA and FFIEC regulations. In this way, organizations can release security into new Android and iOS apps on a regular basis. Through DevSecOps, organizations don’t
have to make tradeoffs between releasing new features and implementing mobile app security because development, operations or security are coordinated in one continuous workflow.
Security measures that enable compliance
To comply, apps must possess fundamental security protections. First, an app should be able to identify and block the tools fraudsters use to commit fraud. Unfortunately, fraudsters abuse common developer tools for dynamic instrumentation, method hooking,
script injection, code injection and accessibility abuse so they can modify or interfere with a mobile app. When these functions are blocked, organizations can stop fraud at the source. Relatedly, an app should prevent anyone from copying it, stealing IP,
re-packaging, re-signing, or publishing alternative versions. Without this protection, fraudsters can create trojan apps that look and feel like the real thing, but carry malicious code onto users’ mobile devices to steal financial information and enable account
Hackers also elevate their permissions so they can manipulate financial apps by jailbreaking (iOS) or rooting (Android) devices. An app needs to be able to recognize when it is operating in a jailbroken / rooted environment and then shut itself down to protect
Strong encryption is must-have protection. Financial apps often only encrypt data that is located in the application sandbox, a protected area within the mobile device where applications run. Unfortunately, this is insufficient to properly protect financial
app data — it must also be protected within the code: the app preferences, strings, resources and in-app secrets, strings.xml value, and java class .dex files. This data includes critical secrets such as usernames, passwords, API keys, SSL certificates, server
URLs and passwords, authentication tokens and client certificates. They, too, must be protected using AES 256 cryptographic protocols.
These security measures are difficult to implement, however, which makes it tricky to incorporate them into DevSecOps. Software development kits (SDKs) can cut down on the amount of complex manual work required, but even then the amount of time and the level
of skill required may be beyond what many development teams can afford. What’s more, the SDKs, themselves, can contain vulnerabilities and weaknesses that may put apps out of compliance.
Today, however, development teams can use AI-powered, no-code platforms that incorporate security directly into the app binary, reducing cost and time. In this way, strong security can be incorporated into DevSecOps, complete with documentation to demonstrate
However a team decides to implement it, security and fraud prevention is an area where financial app publishers cannot skimp. The risk of fraud is simply too great.