Mobile app for fintech — security, payments and regulatory requirements

Fintech is today the broadest of categories: a neobank, a lending app, a crypto-asset wallet, a factoring tool, an insurer's app, an online currency exchange, or the payment layer inside a product that is not formally a fintech at all. One thing unites them — the app touches other people's money and other people's identity, and that changes the rules at every stage of the project.

In an ordinary app a bug means poor UX. In a financial app the same bug means a loss of user funds, an incident reported to the supervisor, or a service suspension. That is why a fintech project starts not with mockups but with two questions: which regulatory regime are we operating in and whose licence are we using.

This article walks through what really determines the success of such a project: licensing models, onboarding with KYC, strong authentication and biometrics, payments (including BLIK, NFC and BLE), the security layers of a financial app, and costs.

Note. We describe the regulatory position as understood in July 2026. Financial-sector rules change quickly (PSD3/PSR, the AML package, the AI Act, eIDAS 2), and supervisory interpretations change faster still. Before making product decisions, verify the current position with a lawyer specialising in financial market law.

The licensing model first, the backlog second

The scope of work and the budget for a fintech app depend above all on who the regulated entity is. In practice we see four scenarios:

• Your own licence (bank, national payment institution, lending institution, crypto-asset service provider). Full regulatory responsibility, the longest process, the highest demands on IT.
• Small payment institution (SPI) — a lighter entry threshold and simplified requirements, but with turnover limits. A frequent starting point for a Polish fintech that later moves to a full payment institution licence.
• Agency model / white-label (BaaS) — the licence belongs to a partner (a bank or payment institution) and you build the product layer on their API. The fastest route to market, but your architecture becomes hostage to the partner's capabilities.
• No licence of your own — the product uses only off-the-shelf payment gateways and does not hold user funds. Most of the regulatory burden then sits with the payment operator.

That decision has direct technical consequences: whether you keep your own ledger of balances, whether you must report transactions, what your business continuity obligations are and what an audit of your code looks like. Settling the model before work starts can change the budget twofold.

Regulatory frameworks that touch the mobile layer

Not every rule translates into code. These translate directly:

PSD2 and strong customer authentication (SCA)

The foundation of electronic payments in the EU. It requires authentication with two independent factors from the categories: something you know (PIN), something you have (device), something you are (biometrics). On top of that comes dynamic linking — the authorisation code must be tied to a specific amount and payee, and the user must see both at the moment of approval. That directly shapes the transaction confirmation screen.

PSD2 also provides for exemptions from SCA (low amounts, trusted beneficiaries, transaction risk analysis) — using them deliberately genuinely improves conversion, so plan them as part of the product logic rather than bolting them on later.

DORA — digital resilience

The Digital Operational Resilience Act has applied since January 2025 and, for product teams, means concrete things: ICT risk management, an incident register and classification with reporting deadlines, resilience testing, and also requirements towards third-party IT providers — including the software house that builds and maintains the app. The contract with your vendor must contain the clauses DORA requires (right of audit, business continuity, exit strategy).

AML and anti-money laundering

An obliged institution must apply financial security measures: customer identification and verification, establishing the beneficial owner, screening against sanctions and PEP lists, transaction monitoring and reporting suspicious activity. In the app this translates into the entire onboarding process and into blocking mechanisms that must also work after the account has been opened.

GDPR

Financial data is not formally "sensitive data" within the meaning of Article 9 GDPR, but biometric data used for identification is. Hence the rule: the biometric template stays on the device, inside the system's secure enclave, and the app receives only a "confirmed / not confirmed" result. Never send a fingerprint or a face template to your server unless you have a solid legal basis and an impact assessment (DPIA).

MiCA — if you touch crypto-assets

The MiCA regulation governs the issuance of crypto-assets and the provision of related services in the EU, together with an authorisation requirement. If your app enables storing, exchanging or transferring crypto-assets, that is the first thing to check — along with the status of national implementing rules and supervision by the Polish Financial Supervision Authority.

Cloud, AI and digital identity

Three topics that most often resurface at the architecture stage in 2026:

• Cloud computing — the financial sector has its own supervisory expectations for cloud outsourcing (risk assessment, information classification, data location, exit plan). DORA reinforced them; it did not replace them.
• The AI Act — AI systems used for creditworthiness assessment or scoring are classified as high risk, with obligations on documentation, data quality and human oversight. The timetable for applying those provisions falls in 2026 — check the current status, as the deadlines have been subject to adjustment.
• eIDAS 2 and the digital identity wallet (EUDI Wallet) — the European digital identity wallet is set to become an accepted way of proving identity, including in the financial sector. For a fintech that is an opportunity for cheaper onboarding, and a future obligation to integrate.

Onboarding and KYC — the hardest screen in a fintech app

This is where a product is won or lost. Identity verification is simultaneously a legal requirement and the biggest source of drop-off in the funnel. The methods used in Poland:

• Selfie with liveness detection + document OCR. The market standard. What matters most is resilience to deepfakes and so-called injection attacks — substituting a doctored video stream for the camera feed. That is a real attack vector today, not theory.
• Reading the e-ID over NFC. The electronic layer of the national identity card allows the document's authenticity to be confirmed cryptographically. Technically the strongest document verification method, though it requires NFC support and good UX for holding the document.
• Verification by bank transfer (a penny transfer) — simple and cheap, but slow and effective only when the sender's details match.
• External identity schemes — mojeID, the trusted profile, BankID and, in future, the EUDI Wallet. High conversion among users who already use them.

On top of that comes a layer invisible to the user: checking sanctions and PEP lists, establishing the beneficial owner for corporate customers, assessing customer risk and deciding on the scope of enhanced due diligence.

A practical design tip: separate registration from full verification. Let the user get into the app, see the product's value, and only then go through KYC — with clear information about what they cannot do until verified. Onboarding that opens by demanding an ID document loses a significant share of users before they ever reach the first product screen.

Biometrics and strong authentication — how it really works

The most common mistake in financial apps: treating biometrics like a password. The correct model is different — biometrics is the key to the key.

It works like this: when the device is activated, the app generates a key pair in hardware-backed storage (Android Keystore / iOS Secure Enclave), the private key never leaves it, and the ability to use it is protected by system biometrics. Authorising a transaction means signing the transaction data with that key. The system returns only a success indication to the app — the biometric template itself is out of its reach.

What follows in practice:

• Bind the key to the device (device binding). The account works on one specific, activated device. Changing device is a separate, hardened process.
• Invalidate the key when biometrics change. If someone adds a new fingerprint or face, the key must stop working (setInvalidatedByBiometricEnrollment on Android, the equivalent access policy flags on iOS). Without that, biometrics offer no protection against someone who knows the phone's PIN.
• Design the fallback deliberately. An app PIN as an alternative to biometrics is fine, but it must not lower the security level of the most sensitive operations.
• Show what you are signing. The authorisation screen has to present the amount and the payee, and the signed data must be exactly what the user sees. That is the essence of dynamic linking and, at the same time, protection against manipulation.
• Do not rely on biometrics alone when security parameters change. Raising limits, adding a trusted payee or changing a phone number should require additional confirmation and a cooling-off period.

Payments — BLIK, cards and contactless

The payment layer in a fintech usually combines several channels at once:

• BLIK — in Poland practically mandatory for online payments and phone-number transfers. Beyond the six-digit code, what matters are BLIK recurring payments, refunds and transfers to a phone number.
• Cards and wallets — Apple Pay and Google Pay are methods delivered by your payment operator, not separate providers; they still require their own integration and compliance with platform requirements.
• Transfers and pay-by-link — usually through an aggregator (Przelewy24, PayU, Autopay) or directly via a bank API under PSD2.
• PSD2 services (AIS/PIS) — account aggregation and payment initiation. These require regulated status, or an intermediary that has it, plus qualified certificates.

A separate matter is store rules. Apple and Google require their own purchase mechanisms for digital content consumed in the app, but you settle financial services and real-world goods through your own gateway. The boundary can be non-obvious for hybrid products (e.g. a subscription to premium features inside a financial app), and misjudging it ends in a rejected update. We break this down in detail in the article on payments in a Polish mobile app — BLIK, Przelewy24, Stripe and Apple Pay.

NFC, HCE and BLE — when they are genuinely needed

• NFC for contactless payments requires card tokenisation and host card emulation (HCE). On Android this is a mature, open mechanism. On iOS, access to HCE for payment apps was opened up in the European Economic Area following the changes forced by the DMA — on Apple's licensing terms, which is worth verifying before promising such a feature on a roadmap.
• NFC for reading documents (e-ID, passport) in KYC — this requires no payment permissions at all and is often the best justification for NFC in a fintech app.
• Accepting payments on a phone (SoftPOS / Tap to Pay) — the phone becomes a terminal. It requires certification and cooperation with an acquirer, but it opens up a whole product category for micro-businesses.
• BLE is useful for integrating with payment terminals, readers and peripheral devices. It is one of the most underestimated budget areas — testing requires physical hardware and behaviour differs between phone models.

Security of a financial app — layer by layer

Security in a financial app is not one feature but a set of decisions spread across the whole stack. The minimum scope we apply in fintech projects:

Data and keys

• Keys and tokens exclusively in Keystore / Keychain, never in preferences, files or code.
• No financial data in logs, diagnostic dumps or system backups.
• Automatic clipboard clearing after copying an account number, and masking the screen in the task switcher.

Communication

• TLS with certificate pinning and a well-thought-out certificate rotation procedure (pinning without a rotation plan is a scheduled outage).
• Short sessions, refreshed tokens, logout on inactivity, server-side session invalidation.

Environment integrity

• Detection of root/jailbreak, emulators, debuggers and hooking (Frida and similar).
• Checking app integrity through platform services (Play Integrity, App Attest).
• Obfuscation and runtime protections (RASP) — they will not stop a determined attacker, but they raise the cost of a mass attack.

Process

• Verification against OWASP MASVS and testing per MASTG as a shared language with your auditor.
• A penetration test before going live and after every major change in the authorisation area.
• Dependency scanning and an SBOM — in a regulated sector this is part of the requirements towards suppliers.
• A separate incident response process with deadlines aligned to DORA.

Fraud prevention

• Device fingerprinting and detection of unusual behavioural patterns.
• Limits and cooling-off periods for a new device and newly added payees.
• Protection against social engineering — today the most common vector of losses is not breaking cryptography but convincing the user to approve the transaction themselves. What helps: clear authorisation screens, contextual warnings and detection of active screen sharing during a transaction.

How much a fintech app costs

A financial project is more expensive than a functionally comparable unregulated app — not because of the number of screens but because of the compliance layer, testing and integrations. Indicative net ranges:

The biggest items invisible in a first estimate: the KYC provider (a licence fee plus a charge per verification), audits and pentests, the payment partner's test environments (sandbox access is often the schedule bottleneck), incident handling and maintaining compliance after launch. We described the general estimating methodology and budget split in the article how much a mobile app costs in 2026.

If you hear a banking app quoted at the level of an ordinary MVP, compliance, security testing and maintenance have most likely been left out of it.

Checklist before starting the project

1. Settle the licensing model — own licence, small payment institution, agent or BaaS. The rest of the architecture follows from it.
2. Map regulatory obligations onto concrete functional requirements (SCA, AML, reporting, retention).
3. Pick a KYC provider early — their API and constraints shape the entire onboarding funnel.
4. Design the authentication model before the first screen: hardware-backed keys, device binding, fallback, dynamic linking.
5. Confirm the availability of payment channels and the store requirements for your monetisation model.
6. Plan security as a process — MASVS, pentests, incident response, dependency updates.
7. Agree contract terms with your vendor with DORA in mind: audit, business continuity, exit strategy.
8. Build the operations panel from the start — customer service, blocks and complaints are part of the product, not an add-on.

Summary

A fintech app differs from an ordinary app not in the number of features but in the fact that each of them must stand up to a supervisor, an auditor and an attacker at the same time. The licensing model sets the budget, KYC decides conversion, strong authentication and biometrics decide trust, and the security layer decides whether the product survives its first serious attack.

The good news: all of these requirements are predictable. A team that knows them before the start designs them as architecture — instead of gluing them on as fixes after the first audit, when changes cost many times more.

At Mobilesoft we build mobile apps for industries with high security and compliance demands, including the financial sector — from identity verification and transaction authorisation through to payment integrations and BLE. If you are planning such a project, we will help you work through the technical and regulatory requirements and size the scope realistically. Get in touch to discuss the details and receive a quote.