Which Regulatory Frameworks Apply to Financial Mobile Apps?

Building a financial mobile app involves far more than designing a clean interface and writing solid code. The moment an app touches money, data, or financial decisions, it enters a web of overlapping rules that determine what you can build, how you must behave, and what happens if you get it wrong. Some of those rules come from financial regulators. Others come from data protection law. A few come from the app stores themselves. Understanding which frameworks apply, and why, is the starting point for any team serious about operating in this space.

The UK's regulatory landscape for financial apps has grown considerably over the past decade, shaped by the rise of open banking, the arrival of Consumer Duty, and the slow but steady march of buy now, pay later into mainstream use. At the same time, the global picture has become more complex as apps routinely cross borders without their builders fully realising the implications. A savings app available in both the UK and Germany, for instance, faces different rules in each market, even if the product looks identical to the user.

What makes this particularly interesting from a design and product perspective is that regulation does not just constrain what you build. It actively shapes how users experience your product. Disclosure requirements affect screen layouts. AML checks affect onboarding flows. Consumer Duty asks whether your app genuinely works in the user's interest. These are behavioural and psychological questions as much as legal ones, and the teams that understand both dimensions tend to produce products that are compliant and trusted.

What Counts as a Financial Mobile App Under Regulation?

Not every app that involves money is regulated in the same way. The specific framework that applies depends on what the app actually does, and regulators care very much about the distinction. An app that lets you track your spending by importing bank data falls under different rules than one that moves money between accounts, and both are treated differently from one that allows you to invest in equities.

The Financial Conduct Authority (FCA) uses the concept of "regulated activities" as its primary sorting mechanism. If your app carries out a regulated activity, the firm behind it needs FCA authorisation. Regulated activities include accepting deposits, issuing electronic money, providing payment services, arranging or giving investment advice, and executing orders on behalf of clients. The list is defined in the Regulated Activities Order, and it is broader than many product teams initially assume.

Where the boundaries get blurry

Apps that sit adjacent to financial services often assume they fall outside regulation. Budgeting tools, comparison platforms, and aggregators sometimes do qualify as regulated, particularly if they present financial information in a way that constitutes a financial promotion, or if they facilitate transactions rather than merely display data. The FCA's financial promotions rules are particularly wide-reaching, applying to any communication that is likely to lead to a financial transaction.

The safest approach is to map every feature of the app against the Regulated Activities Order before building, rather than after. Adding a payment function or a lending feature mid-development can fundamentally change the regulatory category the app sits in, and that has direct consequences for authorisation, compliance, and the user experience the product must deliver.

FCA Authorisation and Permissions

If your app carries out regulated activities, the firm behind it must be authorised by the FCA, or it must operate as an appointed representative of an authorised firm. Authorisation is not a formality. The FCA's application process assesses the firm's business model, its leadership, its financial resources, its systems, and its controls. It also asks whether the people running the firm are fit and proper to do so.

Authorisation comes with a specific set of permissions, and those permissions matter at the product level. A firm authorised to provide payment services cannot, on the basis of that authorisation alone, begin offering investment advice. Each regulated activity requires its own permission, and expanding the app's functionality to include new regulated activities means going back to the FCA and seeking a variation of permissions. Product roadmaps that do not account for this process can stall badly.

The Payment Services Regulations 2017

The Payment Services Regulations 2017 (PSRs) implement the EU's second Payment Services Directive (PSD2) into UK law, and they remain in force post-Brexit. They govern any firm that provides payment services in the UK, covering activities such as executing payment transactions, issuing payment instruments, acquiring payment transactions, and providing account information services.

Under the PSRs, firms must be either authorised as a payment institution or registered as a small payment institution, depending on their transaction volumes. Authorised payment institutions face more stringent requirements around capital, safeguarding client funds, and governance. Small payment institutions have lighter requirements but face volume limits that cap growth if the business scales.

The PSRs require firms to safeguard customer funds in accounts completely separate from the firm's own operational money.

From a user experience perspective, the PSRs shape several visible elements of payment apps. Strong customer authentication (SCA) is a direct PSR requirement, which is why users of payment apps are routinely asked to confirm transactions through a second factor, whether that is a fingerprint, a code sent to their phone, or a PIN. Designing SCA flows that feel smooth without feeling insecure is one of the more demanding UX challenges in this space, and it is entirely driven by regulatory obligation rather than product preference.

Open access and liability

The PSRs also set out clear liability rules when payments go wrong. If an unauthorised transaction occurs, the burden falls on the payment service provider to demonstrate that the user was at fault. This shapes how firms communicate with users after a disputed transaction, and it influences the language used in error states and dispute resolution flows throughout the app.

The Electronic Money Regulations 2011

The Electronic Money Regulations 2011 (EMRs) apply to any firm that issues electronic money, which is a digital store of monetary value held on a device or server, used to make payments. If your app allows users to top up a wallet and spend from it, you are almost certainly dealing with electronic money, and the firm issuing it needs to be authorised as an electronic money institution (EMI) or registered as a small EMI.

EMIs face significant regulatory requirements around safeguarding. Funds that users load into an e-money account must be protected, either by holding them in a segregated bank account or by covering them with an insurance policy. This requirement exists to protect users if the EMI becomes insolvent, and it has direct implications for the operational infrastructure behind the app.

From a product standpoint, the EMRs affect how onboarding flows work, because users must understand the nature of the e-money product they are signing up to. The distinction between an e-money wallet and a bank account is legally meaningful but not always obvious to users, and explaining it clearly without creating confusion is a genuine design challenge. Framing things properly, so users understand what they are looking at and where they sit within the product, reduces anxiety and builds the kind of trust that keeps people engaged long-term.

When designing e-money onboarding flows, make the distinction between a wallet and a bank account explicit and early. Users who do not understand what they have signed up to will lose trust the moment something unexpected happens.

Consumer Duty and Its Implications for App Design

The FCA's Consumer Duty, which came into force in July 2023, represents a significant shift in how financial firms are expected to think about their customers. The Duty requires firms to deliver good outcomes for retail customers across four areas: products and services, price and value, consumer understanding, and consumer support. Each of these has direct implications for how a financial app is designed and how it behaves over time.

The consumer understanding outcome is particularly relevant for app design. The FCA expects firms to communicate in ways that support good financial decisions, which means moving beyond technically accurate disclosures toward genuinely comprehensible ones. A terms and conditions screen that a user scrolls past in three seconds does not meet the spirit of Consumer Duty, even if it is legally compliant in its content.

Dark patterns and the Duty

Consumer Duty has given regulators a clearer basis for challenging interface design choices that nudge users toward decisions that serve the firm rather than the customer. Features that make cancellation harder than sign-up, notifications that encourage higher-risk behaviour, or defaults that favour expensive options over cheaper ones can all attract scrutiny under the Duty. The FCA has been explicit that it will look at the totality of the user journey, not just individual disclosures in isolation.

The positive framing of Consumer Duty is equally worth noting. Apps that genuinely educate users, surface relevant information at the right moment, and make it easy to understand financial position and options are not just compliant, they are more likely to retain users who feel supported rather than confused.

Audit your app's notification strategy against Consumer Duty. Any push notification that encourages spending, borrowing, or higher-risk behaviour needs a clear rationale for why it serves the customer's interest, not just the firm's revenue targets.

Open Banking and the CMA9 Rules

Open banking in the UK emerged from a Competition and Markets Authority (CMA) investigation into retail banking. The CMA required the nine largest UK banks, known as the CMA9, to implement open banking standards, allowing customers to share their account data with authorised third parties through secure APIs. This created the technical foundation on which a large number of financial apps now depend.

Third-party providers that access open banking data must be registered with the FCA, either as account information service providers (AISPs) or payment initiation service providers (PISPs). AISPs can read account data with user consent. PISPs can initiate payments directly from a user's bank account. Both categories carry their own compliance requirements, including consent management, data minimisation, and specific obligations around how user data is stored and used.

The open banking rules also set standards for the consent experience itself. Users must actively grant access, understand what they are consenting to, and be able to withdraw that consent easily. Designing consent flows that meet these requirements without creating friction that pushes users to abandon the process is one of the more nuanced challenges in this space. Asking permission to proceed, and giving users genuine ownership of their choices within the product, is both a regulatory requirement and a strong predictor of long-term engagement.

Anti-Money Laundering and Know Your Customer Requirements

Anti-money laundering (AML) obligations apply to a wide range of financial firms, including banks, payment institutions, EMIs, and investment firms. The Money Laundering Regulations 2017, as amended, require these firms to carry out customer due diligence (CDD) before establishing a business relationship, which in practice means verifying who the user is before they can use the app's core features.

Know your customer (KYC) processes are the practical implementation of CDD. They typically involve collecting identity documents, verifying them against official records, checking users against sanctions and politically exposed persons (PEP) lists, and assessing the risk level of each customer relationship. For mobile apps, this process usually happens during onboarding, and how it is designed has a profound effect on conversion rates and user trust.

Balancing compliance with experience

KYC flows that feel invasive, confusing, or disproportionate cause significant drop-off. Users who do not understand why they are being asked for a passport scan, or what will happen to the image once submitted, are understandably hesitant. Framing each step with clear context, explaining the reason behind the request, and showing progress through the process all reduce abandonment without compromising the integrity of the check itself.

Enhanced due diligence applies to higher-risk customers and situations, which means some users will face additional verification steps depending on their profile. Designing flows that branch appropriately, without making lower-risk users feel they have been flagged for something, requires careful thought about how the experience adapts to individual circumstances.

GDPR and Financial Data Handling

The UK General Data Protection Regulation (UK GDPR), alongside the Data Protection Act 2018, governs how financial apps collect, store, and use personal data. Financial data is among the most sensitive categories that apps can handle, and the obligations under UK GDPR are correspondingly serious. Every piece of personal data collected must have a lawful basis, must be used only for the purpose it was collected for, and must be retained only as long as necessary.

Financial apps regularly collect data that spans several categories: identity information from KYC, transaction history, behavioural data from in-app activity, and in some cases biometric data used for authentication. Each of these carries its own considerations under UK GDPR, and the combination of them in a single product creates a data environment that requires careful architecture and clear privacy governance.

Consent and legitimate interest

The lawful basis for processing financial data matters practically, because it determines what choices users have. Where consent is the basis, users must be able to withdraw it as easily as they gave it. Where legitimate interest is relied upon, the firm must be able to demonstrate that its interest outweighs the user's rights. Using consent as a basis for processing that is actually necessary for the service tends to cause problems later, because users who withdraw consent then cannot use the product, which undermines the validity of the consent in the first place.

Privacy notices in financial apps are a particular challenge. They must be comprehensive enough to be legally valid but simple enough to be genuinely understood. Progressive disclosure, where the most relevant information appears at the moment of collection rather than in a single dense document, tends to produce better outcomes for both compliance and user understanding.

App Store Rules and Platform-Level Compliance

Beyond regulatory frameworks, financial apps must also satisfy the rules of the platforms on which they are distributed. Apple's App Store and Google Play each maintain their own guidelines for financial applications, and these operate independently of, and sometimes in addition to, legal requirements.

Apple requires apps that offer financial services to clearly disclose all fees, ensure that products and services are legal in each jurisdiction where the app is available, and avoid misleading users about the nature or cost of the product. Apps offering lending, insurance, or investment products face additional scrutiny and may need to provide documentation of relevant licences or authorisations before being approved for distribution.

According to Pye Tait Consulting, 2023, only 16% of surveyed app developers were aware of the UK Government's Code of Practice for app store operators and app developers. That figure rises with company size, reaching 33% among medium and large companies, but it suggests that a substantial number of teams are building financial apps without a clear picture of the platform-level rules they are operating under. Among developers who were introduced to the Code by an app store operator, 46% said this happened before submission, which means roughly half encountered these requirements at a point where changes would be costly.

Read the App Store and Google Play financial services guidelines before your first submission, not after your first rejection. Platform requirements interact with regulatory ones in ways that affect your interface design, not just your legal documents.

Regulations for Investment and Trading Apps

Investment and trading apps sit under some of the most detailed regulation in the financial services sector. The Markets in Financial Instruments Directive (MiFID II), implemented in the UK through the Financial Services and Markets Act and associated rules, sets out requirements for firms that provide investment services, including the execution of orders, portfolio management, and investment advice.

Under MiFID II requirements retained in UK law, investment firms must assess the appropriateness of products for their customers, ensure that marketing communications are fair, clear, and not misleading, and maintain records of transactions. For apps that offer retail investors access to complex instruments such as contracts for difference (CFDs), options, or leveraged products, there are additional restrictions on promotion and mandatory risk warnings that must appear at specific points in the user journey.

The design tension in trading apps is distinctive. Experienced traders want speed and directness, reaching time-sensitive trades through minimal steps. Retail investors who are newer to the market need contextual information and guidance to make informed decisions. A single interface that serves both audiences poorly is a compliance risk and a design failure simultaneously. The app that guides everyone through the same steps frustrates expert users. The one that strips away all context leaves novices exposed. Getting the calibration right requires a clear understanding of the actual audience the product serves, not an assumed one.

Buy Now, Pay Later and Emerging Regulatory Coverage

Buy now, pay later (BNPL) products occupied an unusual regulatory gap for several years. Because most BNPL agreements were structured to fall outside the definitions covered by the Consumer Credit Act 1974, the firms offering them were not required to carry out affordability checks, provide standardised credit information, or offer the same dispute resolution rights as other credit providers. That position is changing.

The UK government has confirmed that BNPL products will be brought into FCA regulation, requiring firms to obtain authorisation, conduct affordability assessments, and provide FCA-standard disclosures. The legislation has moved slowly, but the direction is clear, and firms building BNPL features into retail or e-commerce apps need to design with the incoming framework in mind rather than building to the current gap.

BNPL apps face the challenge of making credit feel accessible without obscuring the reality that users are taking on debt.

The UX implications of BNPL regulation are significant. Affordability checks add friction to what is often positioned as a frictionless checkout experience. Disclosures about the total cost of credit must appear clearly before the user commits. Designing these elements in a way that is genuinely informative rather than a box-ticking exercise will be the central design challenge for BNPL apps as regulation arrives. Presenting the costs and the benefits together, rather than leading only with the convenience, produces better outcomes for users and builds more durable trust in the product.

Operating Across Borders: EU and International Frameworks

A financial app available outside the UK immediately encounters additional regulatory regimes. Within the EU, the regulatory landscape for financial apps is shaped by PSD2 (the second Payment Services Directive), MiFID II, GDPR, and the more recently introduced Markets in Crypto-Assets Regulation (MiCA) for crypto-related products. Post-Brexit, UK firms no longer benefit from financial services passporting, which means that operating in EU member states requires either local authorisation in each country or a presence in a member state that holds an EU licence.

For apps operating in the United States, the picture is further complicated by the fragmented nature of US financial regulation. Federal rules from the Consumer Financial Protection Bureau (CFPB) overlap with state-level licensing requirements that vary considerably. Money transmission licences, for instance, are issued at the state level, and a firm operating across all 50 states faces a complex and expensive licensing process. The California Consumer Privacy Act (CCPA) adds data protection obligations for Californian users, with the CCPA applying to for-profit companies with annual gross revenue of at least $25 million.

The practical consequence for product teams is that regulatory scope needs to be defined before the app is made available in a new market, not after users from that market have already started signing up. The features that are permissible in one jurisdiction, a particular type of financial promotion, a specific investment product, or a certain data processing practice, can be prohibited or differently regulated in another. Geofencing features, localised disclosures, and jurisdiction-specific onboarding flows are the technical and design responses to this reality.

How Disclosure Requirements Shape the User Experience

Disclosure requirements are the place where regulation and design collide most visibly. Almost every framework discussed in this article requires the app to communicate something specific to users, and the question of how to do that without degrading the experience is one that product teams across financial services wrestle with constantly.

The instinct in much product design is to minimise text, reduce friction, and move users through flows as quickly as possible. Regulatory disclosure requirements push directly against this instinct. Risk warnings must be prominent. Fee information must be accessible. Material changes to terms must be communicated clearly. Each of these creates a moment where the user's attention must be directed toward information they may not want to engage with.

Timing and context in disclosure design

The most effective disclosures appear at the moment they are relevant rather than as a separate document the user is expected to read before they begin. Showing a fee disclosure at the point in the checkout flow where the fee applies, rather than in a general terms screen at sign-up, produces better comprehension and reduces the sense that information is being hidden. The same principle applies to risk warnings in investment apps, which land more meaningfully when they appear before a specific transaction rather than as a generic disclaimer during onboarding.

User testing of disclosure designs tends to produce misleadingly positive results. When participants review warning screens or data consent flows in a research session, they assess them rationally and without the emotional weight of an actual financial commitment. Live behavioural data tells a different story. In real transactions, even a disclosure that looked fine in testing can introduce enough hesitation to cause a user to abandon the flow entirely. Designing disclosures that work in the emotional moment of a real financial decision, not just in the calm of a usability session, requires a combination of behavioural data and careful framing.

Test disclosure screens using live behavioural analytics, not only usability sessions. The emotional state of a real transaction is fundamentally different from a test scenario, and disclosures that seem fine in testing sometimes erode trust at exactly the moment it matters most.

Conclusion

Regulatory compliance in financial mobile apps is not a legal department problem that gets handed back to product teams once the paperwork is done. The frameworks covered here, from FCA authorisation to Consumer Duty, from UK GDPR to App Store guidelines, shape the user experience at every stage of the journey. Onboarding flows, payment screens, risk disclosures, consent dialogues, and support pathways all carry the fingerprints of regulatory obligation. The question is whether those obligations are met in ways that support trust and comprehension, or in ways that create friction and anxiety.

The teams that navigate this well tend to start with regulation as a design input rather than a design constraint. When a Consumer Duty requirement to support good financial decisions is treated as a brief to design genuinely educational moments into the product, the result is an app that users trust and return to. When AML checks are framed as moments of reassurance rather than interrogation, drop-off falls. When disclosure requirements are approached as opportunities to communicate clearly at the right moment, compliance and user experience stop being in tension.

Financial apps carry real weight in people's lives. The money involved is real, the decisions are consequential, and the anxiety that comes with financial uncertainty is genuine. Regulatory frameworks exist, at their best, to protect people in those moments. Design that takes both the regulation and the psychology seriously produces products that deserve the trust they receive.

If you are building a financial app and want to think through how regulatory requirements interact with your user experience, let's talk about your product.

Frequently Asked Questions