In mobile app development for a simple e-commerce app, login is a matter of a username and password. In a financial services mobile app, the same question suddenly becomes a legal, regulatory and architectural problem all at once.
This isn't overcomplicating things - it's reality. Underestimate it, and the project pays dearly in extra time halfway through.
Why "username + password" isn't enough for mobile apps
The PSD2 directive (Payment Services Directive 2) introduced the concept of strong customer authentication (SCA) in the EU. The essence: for payments or sensitive financial operations, at least two independent factors must be verified - something the user knows (password, PIN), something the user has (phone, hardware token) and/or something the user is (fingerprint, face recognition). In everyday language, this is two-factor authentication.
It is not an optional convenience feature. It is a legal requirement for any app that handles payment or investment operations. (Admittedly it is partly about convenience too: many users like two-factor authentication and it gives them a sense of security.)
In practice, this means the mobile app architecture must include a strong, scalable authentication layer from the very first day of design - not a module bolted on afterwards. It must, of course, also be reflected in internal policies. In our experience, two-factor authentication looks the same from above, but in reality there are many company-specific rules. For example: after every nth login, biometric login is not allowed and the code must be entered; what protocol applies at first login; whether the customer must explicitly enable biometric authentication; biometrics may be disallowed for certain transactions; or exactly what happens when a password expires. Authentication rules and processes differ a great deal between companies in these details - compliance officers always have some latitude. Technically, these small details can mean a lot of work.
The typical mistake - authentication as an afterthought
We often see this pattern: development starts with the user interface and business logic, and authentication goes in "at the end". That works for a simple app. For a financial services mobile app, however, it can mean redesigning the architecture towards the end of the project, when it is most expensive. Often "at the end" simply means the exact details aren't discussed because they don't seem important - until a third-party component is plugged in and suddenly it matters very much exactly how authentication works and with which technical parameters (for example, the third party may not support certain approaches). These questions must be settled up front, because changing them later can add lead time comparable to the whole project.
The reason is simple: strong customer authentication doesn't just appear at login. It appears in every sensitive operation - initiating a transaction, changing a limit, updating personal data. If this isn't thought through during architecture design, the question "where do we need to re-authenticate?" comes up again for every feature, leading to inconsistent solutions.
How we solved it in a real project - a Keycloak-based approach
For a financial services provider's customer-facing mobile app, we implemented two-factor authentication using Keycloak-based identity and access management.
Why Keycloak:
It is an open-source yet enterprise-grade identity management solution, which means no licence costs while its functionality meets financial services requirements. It supports built-in TOTP-based (time-based one-time password) two-factor authentication - alongside the password, the user enters a time-based code generated by an authenticator app (e.g. Google Authenticator). Beyond the fact that the client supported it, we consider it a good solution too: it provides solid technical foundations, and sufficient expertise and technical documentation are available for it. (That is often an even more important factor than the technical parameters themselves.)
The practical implementation:
At first login, the user registers their authenticator app - this is the "possession" factor. At every login, the user must enter the current time-based code alongside the password (the "knowledge" factor). For critical operations, such as initiating a transaction, the system can request the second factor again based on configurable conditions. (For a better customer experience, we allow biometric authentication as a factor.)
The architectural advantage:
Keycloak doesn't just handle authentication - it also centralises authorisation. This means the "who can see and do what" logic is not scattered across the application code but managed in a central, auditable system. From a financial services compliance perspective this is a critical advantage: during an audit, access management is far easier to demonstrate and evidence. Another advantage is that the Keycloak architecture can be managed as separate core infrastructure, so an operations team can oversee it independently of the development team. In our view this gives a healthy division of work and responsibility. From the application's perspective it is a callable, quasi "black box" that doesn't have to be hard-coded into the codebase.
What we learned during development
UX and security are in tension - and that tension must be managed. Every extra authentication step adds friction to the user experience. The answer is not to reduce security but to take a risk-based approach: simpler flows for low-risk operations (e.g. viewing a balance) and stricter ones for high-risk operations (transactions, limit changes).
Biometric authentication is a good complement, not a replacement. Fingerprint or face recognition is convenient, but linking biometric data stored on the device with server-side authentication requires careful design - it is not a "just switch it on" feature. As noted above, many small detailed rules can and must be defined, and they determine the implementation, so this part cannot be glossed over: everything must be defined precisely. Experience also shows that the rules need plenty of fine-tuning after go-live, based on real-world use.
The recovery process is just as critical as authentication itself. What happens if the user loses the phone running the authenticator app? Without a well-thought-out, secure process, the support team will struggle - often at the cost of security compromises.
What we do differently at FrontX
In all our financial services mobile app development work, authentication architecture is among the first design steps - not the last. This means compliance requirements (PSD2, strong customer authentication) are taken into account already in the wireframe and API design phase, rather than being "fitted in" at the end of development.
If you are about to develop a financial services mobile app and the authentication architecture is still an open question, we are happy to talk: frontx.hu/en/company/contact
Frequently asked questions
What does strong customer authentication mean?
Strong customer authentication means that for payments or sensitive financial operations, at least two independent factors must be verified: something the user knows (password), something the user has (phone, token) and/or something the user is (biometric identifier). In the EU it is a legal requirement for every app that handles payment or investment operations.
Why use Keycloak in a financial services mobile app?
Keycloak is an open-source, enterprise-grade identity and access management solution with no licence costs. It supports built-in TOTP-based two-factor authentication and also centralises authorisation - a significant compliance and audit advantage over a scattered, custom implementation. (Sufficient expertise and implementation experience with Keycloak is also available on the Hungarian market.)
When should a mobile app request the second authentication factor again?
Take a risk-based approach: for low-risk operations (viewing a balance), authentication at login is sufficient; for high-risk operations (initiating a transaction, changing a limit), it is worth requesting the second factor again. In our view this should be a business decision - every organisation needs to set its own two-factor authentication rules.
Why must authentication be designed at the very start of development, not at the end?
Because strong customer authentication doesn't only appear at login, but in every sensitive operation. If it isn't thought through during architecture design, it requires expensive, inconsistent changes later in the project. (The many small detailed rules can bring significant technical challenges that are best identified at the start - otherwise the project can take much longer.)
László Behán is Managing Director and Co-Founder of FrontX Kft. He was previously CIO of Signal Biztosító, Head of Development and Data Warehousing at Groupama Biztosító, and Operations Director and a member of the Board at LeasePlan Hungaria. He has 25 years of IT and business leadership experience in financial services. LinkedIn profile
