Authentication in Fintech - ProductFTW #66

This year at ProductFTW, we will spend more time talking about fintech and real product work. I think it is exciting to focus on the day-to-day decisions PMs have to make when money, regulation, and risk are involved. Lucky for our readers, this is something the ProductFTW team works on every single day at Totavi.

When I start a new card product, the first meaningful requirements I write are almost always about account creation and authentication.

Most people think authentication is a solved problem. That assumption usually holds until real money is involved. Log in, log out, reset your password. There are vendors, SDKs, and best practices for all of it. As Matthew stated in ProductFTW #46:

Auth lives in this awkward space: critical to your product but rarely a core differentiator.” 

Fintech adds another layer of constraints on top of that.

Why Fintech Auth Looks Different

If you spend most of your time building non-financial consumer products, banking apps often feel behind. Many of them do not support Google login or other common single-sign-on (SSO) options.

That choice is intentional.

In fintech, authentication is closely tied to identity, fraud, and regulatory responsibilities. When a bank authenticates a user, it grants access to money, personal data, and regulated actions. Adding a third-party identity provider introduces a dependency that the bank does not control.

If that provider changes behavior, experiences an outage, or locks a user out, the bank still owns the outcome. Support tickets rise, fraud risk increases, and regulators still point the finger at the bank.

Recovery flows matter just as much: When something goes wrong, banks need clear answers about who accessed an account, how they authenticated, and what signals were present at the time. That level of visibility is harder to maintain when authentication relies on external identity systems.

There is also a platform constraint that many teams underestimate. Supporting Google SSO on mobile means supporting Sign in with Apple on iOS. That adds additional flows, testing paths, and edge cases. Each provider has different rules for account linking and recovery, which quickly increases complexity.

This is why SSO debates in fintech usually end in “we’ll revisit this later” and quietly sit on the backlog.

Mistakes I See

Someone drops a login screen into Figma, writes a generic user story about needing to access an account, and moves on. It feels harmless because authentication appears as a component rather than a system. In fintech, that assumption breaks things later.

Authentication decisions are data model decisions. The moment you decide when an account exists, you are deciding which objects exist in your system, which relationships are valid, and what data you store about someone before they ever become a customer.

This is where the applicant-to-cardholder lifecycle starts to matter. 

• Are you creating a user record before submitting an application? 
• Are you creating an account before underwriting?
• Are identity verification attempts attached to a person who may never be approved?
• Does a customer ID get generated early and flow into downstream systems? 
• Are you cleanly converting an applicant into a cardholder, or layering on status flags to make it work?

Most PMs do not realize they are defining the ERD when they choose an account-creation strategy. Engineering will still build something, but it will be shaped by whatever decision was implicitly made in the application flow. Months later, you end up with awkward entities that only exist to paper over that choice.

In practice, the lifecycle usually looks something like this:

1. A visitor shows up and starts an application.
2. That visitor becomes an applicant once they submit their personal information.
3. An applicant becomes an approved account holder after underwriting.
4. An approved account holder becomes a cardholder once a card is issued and activated.

Those are different states with different permissions, data requirements, and compliance implications. They should not all collapse into a single account object just because it makes login easier.

When Does the Account Exist?

Once you start thinking about authentication as part of the lifecycle and data model, the next decision becomes unavoidable: When does the account actually exist? In card products, this usually comes down to two options. Creating the account before the application or after approval.

Creating the account early establishes a persistent identity. Users can save progress and return to an in-flight application. Activity can be tied to a known user instead of a temporary session. This approach works well when the card is embedded into an existing product that already has a login. The user already has an account, and the card is additive. Early account creation fits naturally into that experience.

The downside is friction. Every additional step before application submission increases drop-off. Asking for credentials before a user has committed to applying introduces risk to conversion.

Creating the account after approval removes that friction. The user focuses on applying. Credentials come later, once there is a reason to log in. The tradeoff shows up downstream. Saved applications are harder. Returning users require more logic. Temporary identifiers eventually need to be reconciled into real accounts.

There is no universally correct answer. Embedded finance products often create accounts earlier. Standalone card products tend to delay account creation.

My preference is to create the account after approval. It keeps the application flow lighter and avoids storing large volumes of personal data for users who never make it through underwriting. Once an account exists, your data model, compliance obligations, and retention requirements change. Reversing that decision later is expensive.

Email vs Username

Once you decide when the account exists, the next decision is how users identify themselves.

Have you ever wondered why most major credit card issuers use usernames rather than emails? After reviewing some of my card logins, Chase, Amex, Capital One, and Barclays all use usernames and passwords.

This is because emails change, people lose access, work emails get shut off, and shared inboxes disappear. When email is the primary identifier, account recovery becomes a frequent problem, and account access gets tightly coupled to communication.

Usernames are more stable. They separate authentication from communication. That separation matters during fraud investigations, recovery flows, and legal processes. It also reduces the number of lockouts caused by email changes.

Early-stage products often default to email-based login because it feels easier. At a small scale, that works. At a larger scale, it creates cleanup work. That is why legacy issuers stick with usernames, even when it frustrates new users to remember application-specific ones.

Password Requirements

Password rules quickly surface as a point of tension between product, security, and fraud teams.

Password guidance has changed a lot over time, largely driven by NIST. Older standards pushed complexity rules, frequent rotation, and forced resets. That led to predictable behavior. Users reused passwords, wrote them down, or made small variations that were easy to guess. Newer NIST guidance shifted toward longer passwords, fewer arbitrary rules, and rotation only when there is evidence of compromise. The goal was to reduce user friction while improving real-world security.

In fintech, that guidance is a starting point, not a ceiling. Many teams still choose stricter requirements based on fraud patterns, threat models, and regulatory expectations.

Lately, guidance often points to 8 to 15 characters and discourages forced complexity. That makes sense until you have dealt with credential stuffing and account takeover attempts.

Stricter requirements reduce certain risks and increase friction. Looser requirements improve conversion and increase downstream costs. This is a business decision with operational consequences. PMs run into trouble when password requirements are treated as a UX choice. In fintech, these decisions affect fraud exposure, support volume, and regulatory posture.

Fortunately, many phones and browsers now offer password suggestions. As my family knows (not that I would ever share streaming passwords), I am fully on board with device-generated passwords. I don’t think it is unrealistic to require 15-character passwords with numbers and special characters.

Remember Me, Face ID, PINs

After initial login, speed becomes the focus. Users expect faster access over time. Features like remember me, Face ID, PINs, biometrics, and passkeys all make that possible, and each one shifts how risk shows up.

Persistent sessions increase exposure when a device is lost. Biometrics and passkeys shift trust to the device and operating system. PINs can become weak points if implemented poorly or reused elsewhere.

Passkeys are interesting because they remove passwords entirely and reduce phishing risk, which is a real win. They also introduce new considerations around device portability, account recovery, and cross-platform support. If a user loses a device or switches ecosystems, recovery flows matter a lot more than they do with passwords.

This is why financial apps tend to be conservative on first login and on new devices. Step-up authentication is common. Trust is built over time.

When I build applications, I usually start with more friction. SMS-based MFA, device verification, and conservative session policies help establish confidence early. Faster login options can be layered in once the user and device are familiar.

Layered and Contextual Checks

In fintech, authentication rarely relies on a single signal. Device, IP, and location data are commonly used to add context and reduce fraud without adding visible friction for every user.

These signals are evaluated together. A familiar device on a consistent network behaves differently from a new device in a new location. When multiple signals change at once, teams can step up authentication instead of treating every login the same.

This approach reduces reliance on any single factor and lets products respond to risk dynamically. Most users move through the flow without interruption, while higher-risk scenarios trigger additional checks.

Why This Matters for PMs

Authentication is not a feature users praise. It is a feature they notice when it breaks. In fintech, failures are expensive and difficult to unwind.

PMs often want to move past authentication quickly so they can focus on the rest of the product. That instinct is understandable, but carries risk. Authentication decisions shape conversion rates, fraud exposure, support costs, and the compliance posture for years.

Auth is hard in fintech because every decision trades convenience for control or speed for safety. Get it right and users barely think about it. Get it wrong, and everything else suffers.

About ProductFTW

ProductFTW is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it.

Part of the Fintech Product Management Field Guide — ProductFTW's writing on what makes building card, payment, and banking products different.