How to Develop a Secure Mobile Banking App?

When Apple rejected a peer-to-peer currency exchange product we had built, the reason was not a bug or a missing feature. The reviewer flagged it as a potential vehicle for money laundering. The transfer mechanism worked exactly as designed: users could exchange leftover foreign currency with other travellers at interbank rates, avoiding commission, with no upper limit on how many transfers could happen between any two parties. That unlimited capability was the problem.

We went back and retrofitted more stringent KYC checks, enhanced transfer security, and hard limits on transfers between any two parties. The rework took time and budget we had not planned for, and it could have been avoided entirely if compliance had been part of the original specification rather than something we reached for after a rejection.

Security decisions made after build cost more, deliver less, and leave gaps no patch fully closes.

That experience shaped how we think about security in financial products. The question for a mobile banking app is never whether to make it secure. The question is when security decisions get made, and whether they shape the architecture from the start or get bolted on after the fact.

This article works through the decisions that belong in the specification, before a single line of code is written, and the ones that surface mid-project if you do not ask the right questions early enough.

The Architecture Decisions That Belong in the Specification

Architecture shapes everything that follows. Once you have committed to a particular approach, changing it later is expensive in ways that are hard to predict at the start. For a banking app, several decisions carry security implications so large that they should be locked before development begins.

The first is where data lives. A product that stores sensitive financial data locally on the device faces a different threat model than one that keeps everything server-side. Local storage is fast and works offline, but any device that gets lost, stolen, or compromised becomes a potential breach. Server-side storage concentrates risk differently, at the network layer and the infrastructure layer, and demands rigorous access control and encryption in transit.

Offline capability and its security cost

Offline functionality sounds like a product feature, but it is also an architectural choice with direct security consequences. Every piece of data the app holds locally is data that needs to be encrypted, invalidated on logout, and cleared on session expiry. Defining the offline scope in the specification forces a decision about what data the app actually needs to hold, rather than caching broadly and auditing later.

API design and trust boundaries

How the app communicates with backend systems matters as much as what it communicates. A well-defined API layer with clear trust boundaries is far easier to secure than one that evolved informally. On a buying and selling platform for bottles of alcohol we worked on, the client's existing web application had been built in a way that made it too complex to expose cleanly via an API. We ended up embedding web elements from the existing site directly into the mobile product. That workaround added roughly 20% uplift in work across the entire project and forced us to drop features to keep within budget. Defining API boundaries early, in the specification, prevents that kind of structural debt.

Authentication: Choosing the Right Model Before You Build

Authentication is the first thing a user encounters and the first line of defence against unauthorised access. Choosing the wrong model early means rebuilding it later, often at the moment when the product is growing and the cost of disruption is highest.

The choice between password-only, multi-factor, biometric, and passwordless authentication is not purely a UX decision. Each model carries different risk profiles, different regulatory expectations, and different implications for session management. A banking app that relies on passwords alone is out of step with current guidance from most financial regulators. Multi-factor authentication, combining something the user knows with something they have or something they are, is now a baseline expectation rather than an enhancement.

Biometric authentication

Biometric authentication, fingerprint or face recognition, reduces friction significantly and tends to improve completion rates at login. On the security side, biometric data should never leave the device. The operating system handles the biometric check and returns a pass or fail result. The app should act on that result without ever seeing or storing the underlying biometric. This is a common misunderstanding in specifications: teams sometimes plan to send biometric data to a server for matching, which creates a data category with serious legal and security implications.

The cost of skipping authentication discovery

On a dating app project focused on verified profiles and preventing bots, the client chose to skip discovery for the messaging component and focus solely on onboarding. The result was a generic messaging feature that allowed automated and fake messages, directly undermining the verification work done during onboarding. Rewriting that section cost approximately £15,000 in additional budget and two months of extra work. Authentication and identity verification need to run consistently across every part of a product, and that consistency has to be designed in, not assumed.

How Data Should Be Stored, Transmitted, and Classified

A banking app handles data across a wide spectrum of sensitivity. Account numbers, transaction histories, identity documents, and biometric confirmations all sit at one end. App preferences and session tokens sit closer to the other. Treating all of it with the same level of protection is inefficient. Treating it all with the same low level of protection is a liability.

Data classification, deciding which categories of data exist and what controls apply to each, belongs in the specification. Without it, developers make ad hoc decisions throughout the build, and those decisions rarely err on the side of over-protection.

What gets stored locally, how it is encrypted, and when it is cleared on logout must be specified, not assumed.

Transmission security is less ambiguous. TLS should be enforced for all communication between the app and backend systems, with certificate pinning to prevent man-in-the-middle attacks. Certificate pinning ties the app to a specific certificate, so even if an attacker manages to present a fraudulent certificate, the app will reject the connection. This is a configuration decision that needs to be in the specification, because retrofitting it after APIs are already in use creates risk during the transition.

Local storage and what should never sit there

Certain data categories should never be stored on the device at all. Raw authentication credentials, unencrypted transaction records, and identity document images are examples where the risk of local storage outweighs any performance benefit. Defining these prohibitions explicitly in the specification gives developers a clear rule to follow rather than a judgement call to make under deadline pressure. According to NowSecure, 70% of analysed mobile apps can leak personal data through storage, APIs, logs, and SDKs. Classification up front is the most direct way to reduce that surface.

Define at least three data tiers in your specification: data that must never be stored locally, data that may be stored locally only in encrypted form, and data that carries no special restriction. Assign every data type to a tier before development begins.

Why Compliance Must Be Designed In, Not Retrofitted

Financial products operate under regulatory frameworks that impose specific technical requirements. PSD2 in Europe mandates strong customer authentication for payment initiation. FCA guidance in the UK sets expectations around fraud controls and consumer protection. These are not optional extras. Building a product that meets them after the fact is consistently more expensive than building to them from the start, because compliance requirements often affect architecture, data flows, and user journeys in ways that touch multiple systems at once.

The peer-to-peer currency exchange product we built is the clearest example of what retrofitting compliance actually costs. AML requirements were not part of the original specification. Apple's rejection forced a full compliance review, a redesign of the transfer mechanism, additional KYC layers, and hard limits on transfers between parties. Each of those changes required reopening decisions that had already been made and built around. The rework was measurably more expensive than getting it right in the first specification.

Compliance as a design constraint

Treating compliance as a design constraint, the same way you treat screen size or connectivity, changes how specifications are written. Instead of listing features and then asking a compliance team to review them, you start with the regulatory environment and let it shape the feature list. Transfer limits become a product feature, not a restriction bolted on after a rejection. Identity verification becomes part of the onboarding flow, not a separate screen added to satisfy a legal requirement.

When to involve legal and compliance expertise

The specification stage is the right time to bring in legal or compliance expertise, before technical decisions lock in approaches that may need to change. Waiting until testing, or worse, until a regulator or platform reviewer raises concerns, means the cost of compliance falls on a build that was not designed to accommodate it.

KYC, AML, and Transfer Limits: Getting Regulatory Requirements Right Early

Know Your Customer and Anti-Money Laundering requirements exist to prevent financial products from being used to move illicit funds. For a mobile banking app, these requirements translate into specific product decisions: how identity is verified at onboarding, how ongoing transaction monitoring works, and where limits apply to transfer volumes and frequencies.

KYC verification typically involves collecting and verifying government-issued identity documents, matching them against a live selfie or video, and checking the user against sanctions lists and politically exposed persons databases. Each of these steps involves a third-party provider, a data storage decision, and a regulatory obligation around how long verification records are kept and who can access them.

Transfer limits as a product feature

On the currency exchange product, unlimited transfers between two parties was a feature, not an oversight. It was part of the value proposition. But it created exactly the pattern that AML frameworks are designed to detect and prevent: repeated transfers between the same parties with no clear commercial rationale. Adding hard limits after the fact meant revisiting the product's core mechanics and communicating a significant change to users who had already signed up. Defining transfer limits in the specification, with AML requirements as the explicit reason, would have produced a more defensible product from day one.

Ongoing monitoring

KYC at onboarding is a starting point, not a complete solution. Regulatory frameworks increasingly expect ongoing transaction monitoring: detecting unusual patterns, flagging high-risk behaviour, and maintaining audit trails that can be produced on request. These capabilities need infrastructure, and that infrastructure needs to be planned for in the architecture rather than added to an existing system that was not designed to support it.

Map your product's transfer flows against AML typologies before writing the specification. If a mechanism could plausibly be used for layering or smurfing, assume a regulator or platform reviewer will notice it and design the controls before you build.

GDPR and Data Retention: Resolving the Conflict Before It Becomes a Crisis

GDPR gives users the right to request deletion of their personal data. Financial regulations, and in some cases criminal law, require certain data to be retained for defined periods. For a banking app, these two obligations point in opposite directions, and the tension has to be resolved in the specification rather than discovered in production.

On an anonymous messaging app we worked on, we encountered a version of exactly this conflict. GDPR's right to erasure sat directly against the need to retain message data in case of criminal investigation. A user who had sent inappropriate or bullying messages could request deletion of their account and all associated data. If the product complied fully with that request and a police investigation followed, the data would be gone. We resolved it by implementing a data retention policy of around six months: even if a user deleted their account, the underlying data was held for that period before being permanently wiped.

Applying the same logic to financial data

A banking app faces a similar but more complex version of the same problem. Financial transaction records may need to be retained for five to seven years under anti-money laundering regulations. A user exercising their right to erasure cannot simply have those records deleted. The resolution is to separate the data into categories: identity and preference data, which can be deleted on request, and regulated financial records, which must be retained for the required period regardless of a deletion request. That separation needs to be designed into the data model from the start.

Communicating retention to users

Users who request deletion and receive a confirmation that their account has been closed will reasonably assume their data is gone. If regulated records are being retained, the privacy notice needs to say so clearly, and the deletion confirmation message needs to be accurate about what has and has not been removed. This is both a legal requirement and a trust issue.

Securing Third-Party Integrations and API Layers

Banking apps rarely operate in isolation. They connect to payment processors, identity verification providers, open banking APIs, fraud detection services, and credit reference agencies. Each integration is a potential entry point for an attacker, and each one needs to be evaluated at the specification stage rather than trusted by default.

On a production management product for the motion picture industry, we expected to integrate directly with platforms used for storing production documents and to pull data via email integrations. When we finally gained access to those systems, they were far more locked down than anticipated and we did not have the access we needed. We had to pivot to ingesting emails tied to specific roles within a production instead. The lesson for financial products is that third-party access assumptions made in the specification are frequently wrong, and the fallback options tend to be architecturally worse than the primary plan.

API key management

API keys that provide access to financial infrastructure must never be stored in the app's codebase, bundled into a release build, or committed to a public repository. Serverion reports that 61% of organisations have accidentally exposed secrets such as API keys in public repositories. Keys should be stored server-side and provided to the app only through authenticated, short-lived tokens. The specification should define key rotation policy, access scopes, and what happens if a key is compromised.

Evaluating third-party security posture

Not every third-party provider maintains the same security standards. Before integrating a service that will handle personal or financial data, the provider's security certifications, breach history, and contractual obligations around data processing need to be reviewed. This review belongs in the specification phase, not after the integration is already half-built.

List every planned third-party integration in the specification alongside its data access scope, authentication method, and fallback if the provider changes its API or access model. A provider that changes or deprecates an endpoint mid-project creates security risk if the fallback was not planned.

Location, Identity, and User Safety as Security Concerns

Security in a banking app is primarily thought of as protection against external attackers. But user safety, the protection of one person's data and identity from another person using the same platform, is a security concern too, and it shapes product decisions in ways that purely technical threat modelling does not capture.

On a fitness social app, the original design showed users' real-time locations on a map so people could find workout partners nearby. Research showed that a high proportion of the expected user base would be female, which made precise location sharing a real safety concern. We redesigned the feature to introduce randomised location offsets. Users could see only the approximate area where a potential workout partner was, could review profiles and exchange messages, and could then choose to reveal their exact location. The opt-in structure preserved the product's core value while removing the mechanism that created risk.

Identity verification and account takeover

For a banking app, the equivalent concern is account takeover: a situation where someone gains access to another person's financial account, whether through credential theft, social engineering, or weak authentication recovery flows. The password reset and account recovery journey is frequently the weakest point in an otherwise well-secured app. Recovery flows that rely on email alone, or that accept easily-obtained personal information as identity verification, create a path around all the stronger authentication controls built into the main login flow.

Permission requests and data minimisation

A banking app that requests location data, contact list access, or camera permissions beyond what the product actually requires creates a user trust problem as well as a data minimisation issue under GDPR. Each permission request should be justifiable against a specific feature, and permissions that are not actively used should not be requested. Defining the permission model in the specification, with a rationale for each permission, prevents scope creep at the development stage.

Session Management, Authorisation, and Access Control

A user who authenticates successfully should have access to exactly the data and actions their account permits, for exactly as long as the session is active. That sounds straightforward but requires careful design across session timeout, token management, and role-based access control, especially if the product has different account types or shared household access features.

Session tokens should have short expiry windows and be refreshed silently while the user is active. When a session ends, whether through logout, timeout, or the app moving to the background for an extended period, the token should be invalidated server-side rather than simply removed from local storage. A token that is removed locally but remains valid server-side can still be used if an attacker has obtained it.

Role-based access control

If the product includes joint accounts, business accounts, or delegated access, the authorisation model needs to define exactly what each role can see and do. A delegated user who can view transactions but not initiate payments needs that boundary enforced server-side, not just hidden in the UI. UI-level restrictions are easily bypassed by anyone who can intercept the API calls the app makes. The access control logic lives in the backend, and the specification needs to define it at that level.

Privilege reduction over time

Accounts that accumulate permissions over time, as features are added or roles change, end up with broader access than they need. Reviewing and reducing permissions as part of ongoing maintenance is a practice that pays off over time. Organisations that implement automated policy enforcement and risk scoring often report significant reductions in over-privileged accounts within the first quarter. For a banking product, over-privileged accounts are a specific liability rather than a general technical debt issue.

Testing Security in a Financial Context

Security testing for a banking app is not the same as functional testing. A functional test confirms that a feature behaves as designed. A security test asks whether the feature can be made to behave in ways it was not designed to allow, and whether those unintended behaviours create risk.

Penetration testing, where a specialist attempts to breach the product using the techniques an attacker would use, should be planned before launch rather than arranged as an afterthought. The findings from a penetration test often require architectural changes, and those changes are easier to make before the product is live and users are depending on it.

The gap between test conditions and real transactions

User testing involving financial data produces results that do not always match live behaviour. When people review flows in a usability session, they are assessing them functionally because they are not actually parting with money. Live analytics tell a different story. When users are genuinely about to transact, even elements that looked fine in testing can create enough hesitation to cause drop-off. Security and trust signals, the things that reassure a user that their money is safe, need to be tested in conditions that replicate the real emotional stakes of a financial transaction.

Continuous testing after launch

A security audit at launch is a snapshot. The threat landscape changes, libraries develop vulnerabilities, and new attack patterns emerge. Scheduling regular security reviews, including checks on third-party library versions and API configurations, should be part of the product's ongoing maintenance plan from the start. According to NowSecure, 95% of tested mobile apps fail at least one OWASP MASVS security control. Many of those failures are in products that passed an earlier review before a new vulnerability was discovered.

What a Security-First Specification Actually Contains

A specification that treats security as a first-class concern looks different from one that lists features and assumes security will be handled during development. The difference lies in what it covers and in how it structures decisions.

The following components belong in a security-first specification for a banking app.

1. A data classification schema, mapping every data type the product will handle to a storage tier, retention period, and deletion rule.
2. An authentication model, defining the methods allowed, the recovery flows, and the session management rules.
3. A compliance map, listing the regulatory frameworks that apply and the specific product decisions each one drives.
4. A third-party integration register, listing each provider, its data access scope, and its authentication mechanism.
5. A permission model, justifying each device permission the app will request.
6. An authorisation matrix, defining what each account role or type can see and do, enforced at the API layer.
7. A testing plan, including penetration testing, security review schedule, and the criteria that must be met before launch.

Each of these components resolves a decision that, if left open, will be made under pressure during the build. The currency exchange product that Apple rejected lacked a compliance map. The dating app that required a £15,000 messaging rewrite lacked a consistent identity model across the product. The alcohol trading platform that cost 20% more in work than planned lacked a third-party integration register that had been properly tested against the actual state of the client's existing systems. The specification is where those gaps get closed.

Conclusion

Building a secure mobile banking app is a specification problem as much as a technical one. The decisions that matter most, how data is classified, how authentication is modelled, how compliance requirements shape the product, and how third-party integrations are evaluated, all need to be made before development begins. Making them afterwards is possible, but the currency exchange project showed what that costs: a rejected app, a forced redesign, and rework across layers that had already been built and signed off.

The pattern across the projects we have described here is consistent. The anonymous messaging app's GDPR and retention conflict, resolved through a six-month retention policy, was a design decision that could have been a crisis. The fitness app's location redesign, prompted by demographic research, was a trust and safety decision that the original specification had not anticipated. The dating app's messaging rewrite, at £15,000 and two months, was the cost of skipping discovery on a single component.

Security in a financial product is a set of decisions made at the start, which then constrain and shape everything that follows. The specification is where those decisions belong, and the teams that make them early are the ones who avoid the rework, the rejections, and the retrofits that define the alternative.

If you are building a mobile banking product and want to work through the specification decisions before development begins, let's talk about your banking app.

Frequently Asked Questions