Join the Community

22,039
Expert opinions
43,969
Total members
395
New members (last 30 days)
177
New opinions (last 30 days)
28,688
Total comments

BSA Compliance and FFIEC Examinations for Mobile Apps

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 FFIEC examinations. 

BSA compliance

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 takeovers. 

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 itself.

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 compliance. 

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.



 

External

This content is provided by an external author without editing by Finextra. It expresses the views and opinions of the author.

Join the Community

22,039
Expert opinions
43,969
Total members
395
New members (last 30 days)
177
New opinions (last 30 days)
28,688
Total comments

Trending

David Smith

David Smith Information Analyst at ManpowerGroup

Best 5 White-Label Neobank Solutions in 2024

Ruoyu Xie

Ruoyu Xie Marketing Manager at Grand Compliance

Governance, Risk and Compliance: How AI will Make Fintech Comply?

Now Hiring