What Do Banks Need Before Building a Money App?

Building a money app sounds straightforward until you look at what actually sits beneath the surface. Most people picture the design, the features, the colour palette. What they rarely picture is the mountain of groundwork that has to exist before a single line of front-end code gets written. And that groundwork, all the regulatory, technical, and psychological scaffolding, determines whether the app ever gets to market, and whether people trust it when it does.

89% of consumers now use mobile banking apps for financial management, according to Insider Intelligence. The demand is real and growing. But demand and delivery are very different things, and the gap between them is filled with requirements that banks ignore at considerable cost. Getting authorised, building the right infrastructure, protecting user data, and designing for the emotional weight of financial decisions are all part of the same project. They cannot be separated.

This article walks through what banks genuinely need before they build, from the regulatory foundations upward, and into the human layer where most apps either earn trust or quietly lose it.

The mountain of groundwork beneath a money app determines whether it ever reaches market, and whether people trust it when it does.

Understanding all of this early is not just good practice. It is the difference between building something that lasts and building something that gets pulled or abandoned six months after launch.

Regulatory Authorisation and Licensing

Before anything else, a bank or financial institution needs the right permissions to operate. In the UK, this means authorisation from the Prudential Regulation Authority (PRA) and the Financial Conduct Authority (FCA), depending on the type of activity the app will support. If the app facilitates payments, it likely needs to be registered as a Payment Institution or an Electronic Money Institution. If it takes deposits, that requires a full banking licence.

The licensing process is not fast. Applications involve detailed business plans, governance structures, evidence of financial resilience, and a clear articulation of how consumer risk will be managed. The PRA and FCA assess these carefully, and incomplete applications are returned. Getting this wrong at the start costs months.

Understanding Scope Before Applying

One of the more common mistakes at this stage is applying for the wrong type of licence because the app's intended scope has not been defined with enough precision. A product that starts as a budgeting tool but wants to add payments later may find itself needing a different or supplementary authorisation. Clarity about the full intended functionality of the app, including what might come in a second or third release, should inform which authorisation is sought from the beginning.

For banks that already hold a full licence, the question shifts toward whether the app's specific features fall within the existing permissions or require additions. Either way, legal review of the intended feature set against current authorisations is a necessary first step, not an afterthought.

FCA Registration and Compliance Requirements

The FCA sets out detailed rules about how financial products must behave, and those rules extend directly into digital products. A money app is a regulated activity, and the firms behind it are expected to demonstrate ongoing compliance, not just at launch but across the full lifecycle of the product.

For banks, this means having a named Compliance Officer, maintaining records in a format the FCA can inspect, and operating systems that flag potential breaches before they become problems. The FCA's Senior Managers and Certification Regime (SMCR) places personal accountability on individuals within the firm, so responsibility for the app's compliance does not sit with an anonymous "team" but with named, accountable people.

Consumer Duty as a Design Requirement

The FCA's Consumer Duty, introduced in 2023, raises the bar further. Firms must now demonstrate that their products deliver good outcomes for consumers, that communications are clear and fair, and that support is accessible when people need it. This is not simply a box-ticking exercise at submission. It is a framework that should shape product decisions from the earliest design phases.

What this means practically is that the FCA expects banks to understand how real users experience the app, not just how it is intended to work. User research, testing, and ongoing monitoring of how people actually behave inside the product are all part of meeting Consumer Duty. The regulation and the design process are not separate workstreams. They feed each other.

Data Protection and GDPR Obligations

Financial apps handle some of the most sensitive data a person can share. Transaction history, account balances, spending patterns, and in some cases biometric data used for authentication all fall under the UK GDPR framework. Banks must have a lawful basis for processing each type of data, and that basis must be documented.

A Data Protection Impact Assessment (DPIA) is required before launching any product that processes personal data at scale or that involves new technologies. For a money app, this is not optional and should be completed well before launch, ideally while the product is still in design. Identifying privacy risks during design is dramatically cheaper and faster than retrofitting protections after the product is built.

Identifying privacy risks during design is far cheaper than retrofitting protections after the product is built.

The Information Commissioner's Office (ICO) expects banks to operate on a privacy-by-design principle. This means data minimisation, clear retention policies, and giving users meaningful control over their information. Cookie consent, data access requests, and the right to deletion all need to be built into the product, not bolted on later.

Privacy notices need to be genuinely clear. That might sound obvious, but many financial apps still use dense legal language in their consent flows, which users scroll past without reading. If users do not understand what they are agreeing to, the consent is not properly informed, and that creates both a regulatory and a trust problem.

Conduct your Data Protection Impact Assessment during the design phase, before development begins. Issues found at this stage cost a fraction of what they cost to fix post-launch.

Anti-Money Laundering and KYC Frameworks

Anti-money laundering (AML) obligations are among the most demanding requirements banks face. The Money Laundering, Terrorist Financing and Transfer of Funds Regulations require firms to have documented AML policies, appoint a Money Laundering Reporting Officer (MLRO), and carry out ongoing monitoring of transactions for suspicious activity.

Know Your Customer (KYC) sits at the heart of this. Before a user can open an account or move money through the app, the bank must verify who that person is. This involves collecting identity documents, checking against sanctions lists, and applying Enhanced Due Diligence (EDD) where users present higher risk. The app's onboarding flow is both a design challenge and a compliance process, and those two things need to work together rather than against each other.

Balancing Friction and Thoroughness

KYC processes are a known source of drop-off during onboarding. Users encounter document upload flows, liveness checks, and waiting periods, and some do not complete the process. The temptation to simplify or shorten these flows to improve conversion needs to be weighed carefully against the legal requirement for adequate verification.

The design opportunity here is to make the process feel transparent and purposeful rather than bureaucratic. Users who understand why they are being asked for information, and who can see clearly where they are in the process and how long it will take, are more likely to complete it. Framing KYC as something done to protect the user, rather than something imposed on them, changes how it feels without changing what it requires.

Design your KYC flow so users can see exactly where they are in the process and how many steps remain. Transparency about progress reduces the anxiety that causes drop-off.

Core Banking Infrastructure and Technical Architecture

A money app needs a reliable, secure, and auditable back-end to function. For banks, this means either building on existing core banking systems or selecting a modern core banking platform that can handle the transaction volumes, the regulatory reporting requirements, and the integrations the app will need.

Legacy core banking systems, which many established banks still run, were not designed with mobile-first products in mind. Wrapping a modern app around an old core is possible, but it creates technical debt and often leads to slower transaction processing, limited real-time data availability, and difficulties integrating with newer third-party services. Banks starting this conversation need to be honest about what their existing infrastructure can and cannot support before committing to a product roadmap.

Databases, Uptime, and Audit Trails

For financial apps, database choices carry regulatory weight. All transactions need to be logged accurately, and records must be retrievable for audit purposes. Systems also need to meet uptime requirements that are more demanding than those of a typical consumer app, because money does not stop moving at weekends and users expect access at any hour.

According to Appwrk, almost 62% of users uninstall an app if it crashes or freezes. For a financial app, a crash at the wrong moment can cost a user relationship and leave a transaction in an unclear state, creating both a customer service problem and a potential compliance issue. Infrastructure resilience is a design requirement, not a technical afterthought.

Third-Party Partnerships and Open Banking APIs

Very few money apps are built entirely from scratch by a single institution. Banks typically rely on a network of third-party providers for payments processing, identity verification, fraud detection, customer support, and data aggregation. Each of these relationships introduces risk, and each needs to be governed properly.

Open Banking, governed in the UK by the Payment Services Regulations and overseen by the FCA, allows authorised Third Party Providers (TPPs) to access bank account data and initiate payments with customer consent. Building with Open Banking APIs gives banks access to a rich ecosystem of capabilities, but it also means operating within strict technical and security standards set by the Open Banking Implementation Entity (OBIE).

A survey of 2,000 developers conducted by Veracode, reported by Dark Reading, found that only 52% of developers said they always consider security when evaluating a new third-party library, compared with 67% who always consider functionality. Security being an afterthought in library selection is a significant concern for any app, and for a financial app it is particularly consequential.

Vendor Due Diligence

Banks must carry out due diligence on every third-party provider that touches customer data or money movement. This means reviewing security practices, checking for relevant certifications such as ISO 27001 or SOC 2, and having contractual protections in place. The bank remains responsible for what happens inside the product even when a third party is handling part of the process. That accountability cannot be outsourced.

Fraud Prevention and Cybersecurity Standards

Financial apps are high-value targets for fraud and cyberattack. Banks building in this space need to meet standards set by the FCA, the Payment Systems Regulator (PSR), and where card payments are involved, the Payment Card Industry Data Security Standard (PCI DSS). These are not voluntary guidelines. They are requirements, and non-compliance carries financial penalties and reputational damage.

Strong Customer Authentication (SCA), mandated by the FCA under the Payment Services Regulations, requires that high-value or sensitive transactions are protected by two or more independent authentication factors. Building SCA into the app experience in a way that feels natural rather than interruptive is one of the more nuanced design challenges in financial product work.

According to Worldmetrics, 2026, 65% of enterprises report a mobile app breach in the last two years. The threat environment for financial apps is real and active, and security architecture decisions made at the start of the project have consequences that run for the full life of the product.

Monitoring and Incident Response

Prevention is necessary but not sufficient. Banks also need documented incident response plans that describe what happens when a breach or fraud event occurs, how users are notified, how regulators are informed, and how the situation is contained. The FCA requires notification of major incidents within specific timeframes. Having a plan that exists only in theory, and has never been tested, is a risk in itself.

Test your incident response plan before launch with a simulated breach scenario. Discovering gaps in the plan during a real event is far more costly than finding them in a rehearsal.

Capital Requirements and Financial Reserves

Banks and payment institutions must hold minimum levels of capital as a condition of their authorisation. The exact amount depends on the type of licence held, the volume of transactions processed, and the specific risk profile of the business. For Electronic Money Institutions, the minimum initial capital requirement is 350,000 euros, though ongoing requirements are calculated as a percentage of the average outstanding electronic money issued.

These capital requirements are not simply a licensing formality. They represent the financial buffer that protects consumers if the institution runs into difficulty. The PRA monitors capital adequacy on an ongoing basis, and firms that fall below their minimum requirements face regulatory intervention. For banks building new digital products, the additional operational costs of the app need to be modelled against available capital from the outset.

There is also the question of operational resilience. The FCA and PRA's joint rules on operational resilience require firms to identify their important business services, set impact tolerances for disruption, and demonstrate that they can remain within those tolerances even under severe but plausible scenarios. For a money app, payments processing and account access are almost certainly important business services, and the resilience requirements apply directly to them.

Building User Trust at High-Stakes Moments

All of the regulatory and technical requirements above are prerequisites. But they do not, on their own, make an app that people trust. Trust is built or lost in the moments when the product asks something of the user, and in financial apps, those moments are frequent and carry real weight.

The distinction worth drawing is between passive use and active requests. When a user is simply viewing their balance or browsing transaction history, trust is less directly tested. The moment the product asks them to share financial data, confirm a payment, or grant access to additional accounts, trust becomes the central variable. Hesitation at those points is meaningful. It signals that something about the request feels uncertain or risky, and that something is worth investigating.

User testing in financial products has a known limitation here. When people review checkout flows or data-sharing disclosures in a usability session, they assess them rationally, because they are not actually parting with money. Live analytics tell a different story. When users are genuinely about to transact, even small elements of ambiguity can erode trust just enough to cause drop-off. The emotional state in a test environment and the emotional state at a real moment of financial commitment are very different things, and designing only for the former leaves gaps that show up in production data.

• Map every point where the app asks something of the user, from sharing data to confirming a payment.
• Assess the trust stake at each of those points, from low-stakes (setting a display name) to high-stakes (connecting an external account).
• Focus design attention on the high-stakes moments where hesitation is most likely and most consequential.
• Monitor live analytics at those points after launch, because real-world behaviour and test behaviour will differ.

Reducing anxiety at high-stakes moments works best through education. Framing what is about to happen, explaining why it is being asked, and making clear where the user is within the process and what comes next all reduce the feeling of stepping into the unknown. People do not need to be experts in financial regulation. They need to feel informed enough to proceed with confidence.

Accessibility and Consumer Duty Obligations

The FCA's Consumer Duty explicitly requires that products and services are accessible to all consumers, including those with disabilities, limited digital literacy, or vulnerability. This is a legal obligation, and it also reflects something straightforward: an app that excludes a portion of its potential users is a less effective product.

More than a quarter of the world's population has a diagnosed vision impairment, according to the World Health Organisation. Designing without accessibility in mind means designing for a narrower audience than the one that actually exists. Colour contrast, text size, screen reader compatibility, and navigation for motor-impaired users are all design decisions with direct regulatory and human implications.

Practical Accessibility in Financial Products

A survey by Springer and Empirical Software Engineering found that 60% of mobile developers consider accessibility very important for app development. The gap between that attitude and actual implementation is where problems emerge. Accessibility features need to be tested with real users who rely on them, not simply validated against a technical checklist.

For financial apps specifically, accessibility carries additional weight because the consequences of exclusion are not just inconvenient. A user who cannot navigate a money transfer flow because of a visual impairment is not simply frustrated. They are locked out of a service they need. Consumer Duty makes addressing this a direct requirement for banks, and the design process needs to treat it as such from the beginning rather than addressing it as a retrofit in a later sprint.

Conclusion

Building a money app is a long project before it is a visible one. The work that shapes whether the app can launch, and whether people trust it when it does, happens in the regulatory, technical, and design decisions made long before the first user sees a screen.

Authorisation, compliance, data protection, AML frameworks, infrastructure resilience, third-party governance, fraud prevention, capital adequacy, and accessibility all need to be in place and working together. Each area has its own specialists and its own regulatory body, but they are not independent workstreams. Decisions in one area affect all the others, and a gap in any of them can delay a launch or undermine a product that has already reached users.

The human layer matters just as much. Users bring real anxiety to financial products, and that anxiety responds to specific design choices. Transparency, education, clear framing, and giving people genuine ownership of their progress through high-stakes moments are all things that can be built into a product if they are prioritised from the start. They cannot be added convincingly after the fact.

Banks that approach this as a single integrated project, where regulatory requirements and user experience are designed together rather than handled separately, produce better products. The groundwork is extensive, but it is also the foundation on which everything else depends.

If you are thinking through what your money app needs before it can be built, let's talk about your product.

Frequently Asked Questions