Authentication and identity verification testing. A fintech QA checklist

Written by: Senior AQA Engineer

Ievgen Ievdokymov

Posted: 09.05.2026

22 min read

A structured, layer-by-layer testing framework for QA leads, security engineers, and CTOs responsible for fintech authentication security.

Authentication is the first line of defense in any financial application, and statistically, the most actively attacked. The assumption that implementing MFA makes an authentication system secure is now one of the most dangerous misconceptions in fintech security.

Token theft accounted for 31% of breaches in 2025, bypassing MFA entirely by stealing the authenticated session that follows login rather than the credentials that precede it. Adversary-in-the-Middle (AiTM) proxy attacks harvest session tokens after successful MFA completion, leaving no trace of unauthorized access in authentication logs. MFA bypass through authentication downgrade attacks silently replaces FIDO2 with SMS OTP, and the logs show a 'legitimate' login method throughout.

Authentication testing in fintech is harder than standard security testing for three specific reasons. First, the regulatory surface is prescriptive: PSD2 SCA mandates two independent factors from defined categories; KYC/AML requires verified identity proofing before account creation; GDPR governs how biometric and identity data is captured, stored, and processed. Second, the attack surface has expanded beyond the login screen, deepfakes targeting biometric liveness checks, session hijacking post-authentication, and downgrade attacks that weaken factor strength before the user realizes it. Third, the friction-security tradeoff has direct revenue consequences: 89% of consumers move to a competitor after a poor onboarding experience, which means over-engineering authentication costs customers as surely as under-engineering it.

This article delivers a structured, checklist-based identity verification testing and authentication QA framework, organized by layer, prioritized by risk, and mapped to regulatory requirements. It is designed to be used directly, not just read.

The authentication stack in fintech: What you're actually testing

Authentication in a financial application is not a single feature, it is a five-layer stack, and each layer carries distinct attack vectors, regulatory obligations, and testing requirements. Most fintech QA programs cover Layer 2 thoroughly, Layer 3 partially, and Layers 1, 4, and 5 almost not at all. That gap maps almost exactly to where modern authentication attacks succeed.

Layer 1, Identity proofing and KYC, is where the customer relationship is established. A fraudulent identity that passes onboarding creates risk for every subsequent transaction. Layer 4, session management, is where the majority of authentication bypasses occurred. Layer 5, step-up and continuous authentication, is where regulatory obligations for payment initiation are concentrated under PSD2 SCA.

Why this layering matters for test design: compliance testing must validate each layer independently. Testing the end-to-end login flow confirms that the flow works, it doesn't confirm that individual layers are secure against layer-specific attacks. An OTP that fires correctly at login doesn't tell you whether the session token it produces can be replayed after logout.

Before building or auditing your authentication test suite, map every test case to a specific layer. If your coverage is concentrated in Layers 2 and 3 with minimal coverage in Layers 1, 4, and 5, you know exactly where your risk is.

KYC and identity proofing testing checklist

KYC testing in financial applications begins before a user ever logs in. The identity proofing layer determines who is allowed to create an account, and a fraudulent identity that passes onboarding creates an insider threat from day one.

Document verification testing

• OCR accuracy across document types, test that field extraction (name, DOB, document number, expiry date, nationality) is accurate across every supported ID type and issuing country in your product's coverage scope. Include degraded image quality, non-Latin scripts, older document format versions, and documents photographed at oblique angles. OCR errors in this layer are not just UX problems, they create compliance gaps if a name is misextracted and not matched correctly against a watchlist.

• Forgery detection, submit known forgery indicators and confirm detection: mismatched fonts within the document, altered Machine Readable Zone (MRZ) data that doesn't match the visual inspection zone, digitally edited expiry dates, inconsistent security features (holograms, microprinting). Test each indicator independently, then in combination. The system must flag each one, don't accept a combined pass when individual checks may be misconfigured.

• Document expiry enforcement, an expired document should be rejected at onboarding, regardless of all other fields being valid. Test expiry check logic at the boundary: a document that expired yesterday, a document expiring today, and a document expiring tomorrow. In systems that implement perpetual KYC re-verification, test that expiry checking runs at re-verification intervals, not only at initial onboarding.

• Cross-field consistency validation, the name on the document must match the name in the application form; DOB must be consistent; nationality must align with issuing country. Test each consistency check independently. A system that validates name but not DOB can be bypassed with a stolen document whose name is replaced but whose DOB is left unchanged.

• Rejection handling and information leakage, when document verification fails, the error message must not reveal which specific check failed. 'Document verification unsuccessful, please try again' is correct; 'MRZ data mismatch detected' gives an attacker the precise information needed to correct their forgery attempt.

Biometric liveness and face match testing

• Passive spoofing resistance, test that static photographs, printed images, and video replays of the legitimate user fail liveness detection. These are the entry-level attacks; if any of these pass, the biometric layer is not functioning.

• Active spoofing and deepfake resistance, test liveness detection against 3D-printed masks, silicone masks, and AI-generated deepfake video. Biometric systems tested to ISO 30107-3 iBeta Level 2 certification have been validated against these attack classes. If your KYC vendor cannot provide current iBeta Level 2 certification, treat their liveness detection as unvalidated against sophisticated spoofing. This is a vendor assessment, but it is a QA responsibility to confirm it.

• False Acceptance Rate (FAR) and False Rejection Rate (FRR) by demographic segment, the aggregate FAR and FRR are starting points, not complete metrics. Test biometric accuracy across age groups, skin tones, and lighting conditions. Systematic accuracy disparities across demographic segments are both a product quality issue, affecting customer experience for specific groups, and a regulatory risk under anti-discrimination and fair access obligations. Require segment-level metrics from your vendor and validate them in your test environment.

• Fallback flow security, when biometric capture fails, the fallback must offer equivalent verification security. Test that the fallback path cannot be deliberately triggered to access a weaker verification route. A user who 'fails' liveness detection three times should not be automatically routed to a manual review queue that can be gamed with a stolen document.

Watchlist and sanctions screening testing

• Exact-match and near-match screening, inject names from sanctions lists, PEP databases, and adverse media sources, including: exact matches, transliterated names, name aliases, and names with common spelling variations. Near-match handling is where most screening gaps exist, a sanctions check that only matches exact strings is trivially bypassed by a one-character name alteration.

• Screening database freshness, a name added to a sanctions list after account creation should be detected at the next monitoring cycle. Test this explicitly: create an account for a synthetic identity, then add that identity's data to a test watchlist entry, and confirm the perpetual KYC monitoring process flags it at the next scheduled run.

• EDD workflow validation, simulate a flagged onboarding case and trace the full Enhanced Due Diligence workflow: correct routing to the compliance review queue, required documentation fields captured, reviewer decision logged with timestamp and identity, audit trail complete. The EDD workflow is regulatory infrastructure, it must be tested as rigorously as any other compliance-critical process.

Credential authentication testing checklist

Password and PIN security

• Policy enforcement at the API layer, test that password policies (minimum length, character requirements, common password rejection, credential reuse prevention) are enforced at the API level, not just in UI validation. Submit a non-compliant password directly to the authentication endpoint without going through the UI, if the API accepts it, the policy is client-side only and can be bypassed by any attacker who makes direct API requests.

• Brute-force protection, confirm account lockout fires after the defined number of failed attempts. Test that the lockout mechanism cannot be reset by the user without additional verification (such as MFA or email confirmation). Test that lockout applies per account, not per IP address, IP-based lockouts are trivially bypassed by rotating IPs, while account-based lockouts protect regardless of the attacker's infrastructure.

• Account enumeration prevention, the login error message must not distinguish between 'username not found' and 'incorrect password.' If different errors are returned for each case, an attacker can enumerate valid usernames before beginning credential attacks. Test this at the API level, where error response bodies and response timing differences can reveal information the UI masks.

• Credential stuffing resilience, inject a set of known-compromised credential pairs from public breach datasets (using synthetic test data that mirrors breach patterns) and validate that the system's velocity detection and anomaly alerting responds appropriately. This tests not the authentication logic but the behavioral monitoring layer that sits above it.

Biometric authentication at login

• Fallback path security, when biometric authentication fails at login (sensor failure, poor environmental conditions, user disability accommodation), the fallback must require a credential of equivalent security, not a lower-tier alternative. Test that the fallback path is not weaker than the primary. A biometric-protected account that falls back to a 4-digit PIN under 'failed biometric' conditions has a weaker fallback than its primary protection suggests.

• New device biometric enrollment, when a user attempts to use biometrics on a device not previously enrolled, the enrollment process must require step-up verification before the new biometric is accepted. Test by attempting biometric enrollment on a new device without completing re-verification. If enrollment succeeds without step-up, a stolen device with the user's biometric can be enrolled without the account owner's knowledge.

• Client-side biometric bypass, on a jailbroken or rooted device, biometric results can sometimes be spoofed at the OS level using hooking tools. Test that biometric decisions are validated server-side, not trusted based on a client-side success signal. A server that accepts 'biometric confirmed' from the client without independent verification is trusting an input it cannot verify.

MFA testing checklist

MFA testing in fintech encompasses far more than confirming the OTP prompt appears. The most consequential authentication security testing in this layer probes whether MFA can be bypassed, structurally, through implementation defects, or through deliberate design gaps.

Core MFA implementation

• Server-side MFA enforcement, this is the most critical single test in the MFA layer. Confirm that a session token obtained after successful password entry, but before MFA completion, cannot be used to access protected resources. The correct sequence: password accepted → intermediate state with no resource access → MFA completed → session token issued with access rights. Test by intercepting the authentication flow and attempting to use the post-password intermediate token to call authenticated endpoints directly. If that succeeds, MFA is client-side only and provides no security against an attacker who bypasses the UI.

• OTP validity and reuse prevention, a TOTP code is valid for 30 seconds and must be rejected the moment it is used, not when its time window expires. Test OTP reuse within the same valid window: submit the correct code, confirm access, then immediately resubmit the same code. It must be rejected. Test code submission after expiry: a code valid at T=0 must be rejected at T=31 seconds.

• OTP rate limiting, confirm that submitting incorrect OTP codes triggers rate limiting on the same terms as failed password attempts. Rate limiting applied to password attempts but not OTP attempts leaves a second brute-force vector open on TOTP-protected accounts.

MFA bypass scenarios

This is the testing category almost entirely absent from standard fintech QA programs, and the category where modern account takeover attacks concentrate.

• Authentication downgrade testing, if the application supports both FIDO2 and SMS OTP, test whether an attacker can force the session to use SMS OTP by suppressing or modifying the FIDO2 option in the authentication response. A FIDO2-enrolled user who can be silently downgraded to SMS OTP is exposed to SIM swap and OTP interception attacks that FIDO2 was specifically designed to prevent. Confirm that FIDO2 cannot fall back to weaker factors without explicit user action and step-up verification.

• IP address and header-based MFA bypass, some applications implement MFA exceptions for specific IP ranges or HTTP headers (such as X-Forwarded-For or internal debug headers). Test each bypass path explicitly. IP-based exceptions must be tested for spoofability, the X-Forwarded-For header can be set by any client and is not a reliable authentication control without additional validation.

• Federated login MFA consistency, where the application supports both local accounts and OIDC/federated identity providers, confirm that MFA is enforced on every authentication path. Test the specific scenario: a user has a local account with MFA configured; they also have a federated account at an identity provider where MFA is not enabled; if the federated account can be linked to the same email address as the local account, federated login bypasses MFA entirely.

PSD2 SCA compliance testing

• Factor independence validation, PSD2 SCA requires two independent factors from knowledge (something known), possession (something held), and inherence (something the user is). Requiring both a password and a security question is not SCA-compliant, both are knowledge factors. Test that your implementation genuinely satisfies factor independence, not just multi-step verification.

• SCA exemption boundary testing, PSD2 permits specific exemptions: low-value transactions (under €30), trusted beneficiaries, and risk-based authentication for low-risk scenarios. Test each exemption boundary explicitly. Can a €31 transaction be structured as two €15.50 payments to exploit the low-value exemption? Can a newly added beneficiary claim 'trusted beneficiary' status immediately, before a cooling-off period expires? Each exemption creates a potential bypass path that must be tested.

• SCA audit trail validation, every SCA challenge, every exemption applied, and every outcome must be logged with transaction ID, timestamp, authentication method used, exemption type where applicable, and user identifier. Test log completeness across every SCA path. In a regulatory examination, the audit trail is the evidence, a missing log entry means a missing compliance record.

Session management testing checklist

Session management is where the authentication attack landscape is most active, and where the majority of production fintech breaches now originate. Session token security testing is not optional in a financial application; it is the primary defense layer once authentication is complete.

Token security and lifecycle

• Post-MFA token issuance, confirm that access tokens with resource-access rights are only issued after the complete authentication sequence, all factors verified server-side, has completed. Test by intercepting the flow at each stage and attempting to use intermediate states to call protected API endpoints. No intermediate authentication state should produce a usable token.

• Token expiry enforcement, access tokens must expire at the defined interval and be rejected thereafter. Test by capturing a valid access token, waiting for expiry, and resubmitting it to a protected endpoint. The rejection must occur server-side, a client-side expiry check that can be overridden by clock manipulation is not expiry enforcement. Refresh tokens must also expire; test that an expired refresh token triggers a full re-authentication flow, not a silent token renewal.

• Token scope enforcement, an access token issued for account read access must be rejected when used to initiate a transaction or modify account data. Test scope boundaries by attempting out-of-scope operations with each token type in your system. Scope enforcement failures are particularly consequential in open banking contexts where third-party providers receive tokens scoped to specific actions.

• Mobile token storage security, on a jailbroken or rooted device, examine where session tokens are stored after a legitimate authentication session. Tokens in plaintext SharedPreferences, NSUserDefaults, or application logs are extractable without additional access. Secure token storage uses the platform's secure enclave (Android Keystore, iOS Secure Enclave) with appropriate access controls.

Session invalidation

• Post-logout token invalidation, after logout, the session token must be invalidated server-side. Test by capturing the token before logout and replaying it after logout. If the request succeeds, the token has not been invalidated, it exists in a valid state on the server regardless of client-side logout behavior. This is the most common session management defect in financial applications: a logout that clears the client-side cookie without invalidating the server-side session.

• Post-credential-change session invalidation, after a password change, a new MFA method is added, or a suspicious access event is detected, all existing sessions must be invalidated. An attacker who has established a persistent session through token theft retains access until that specific token expires, unless active session invalidation is implemented. Test by establishing a session, changing the account password from a second session, and confirming the first session is invalidated.

• Concurrent session policy, define the intended behavior when a user authenticates on a second device while a session exists on the first. For high-value fintech accounts, the first-device session should be notified and optionally invalidated. Test that this policy is enforced and that the notification cannot be suppressed.

Step-up authentication for high-risk actions

• High-risk action coverage, the complete set of actions requiring step-up re-verification must be explicitly defined and tested. The frequently overlooked items: new beneficiary addition (an attacker with a compromised session adds a payee, then initiates transfers that subsequently don't trigger step-up because the payee is now 'trusted'), registered email or phone number change (creates a new recovery path), and new device enrollment. Test each action by attempting it directly via API without completing the step-up flow.

• Step-up bypass via API, the step-up authentication challenge must be enforced at the API layer, not just in the UI flow. Test by making direct POST requests to the action endpoints, beneficiary creation, profile update, high-value transfer, without the step-up token that the UI flow would require. If the endpoint accepts the request without the step-up credential, the control is UI-only and provides no protection against attacker API access.

Account recovery and password reset testing checklist

Account recovery flows are, consistently, the weakest point in the authentication chain. They are designed for the locked-out legitimate user, but that design is exactly what an attacker probes first. A sophisticated MFA implementation is entirely negated if password reset requires only an email link.

• Reset verification equivalency, the password reset process must require verification equivalent to the account's MFA configuration. An account protected by a hardware token that allows password reset via email link alone has bypassed its own MFA. Test this explicitly: on an account with each MFA type configured, initiate a password reset and determine whether the process requires the configured second factor or only email confirmation.

• Reset token security, single use and expiry, password reset links must be single-use: once clicked, the token is invalidated regardless of whether the reset was completed. Test by clicking a reset link, completing the password change, then attempting to reload the same reset URL. It must be rejected. Test time-limited expiry: reset tokens should expire within 15–30 minutes; test that an expired token is rejected server-side, not only client-side.

• Reset flow enumeration prevention, the reset confirmation message must not reveal whether an account exists for the submitted email address. 'If an account is registered with this email, a reset link has been sent' is correct. 'No account found for this address' enables attacker enumeration of registered users.

• High-security account recovery requirements, for accounts that have completed enhanced KYC or hold high-value balances, email-link-only password reset is insufficient. Test that these accounts require identity re-verification at recovery, OTP to the registered device at minimum, biometric re-verification for accounts with biometric authentication enrolled.

• New device login notification, a successful login from an unrecognized device must trigger an out-of-band notification to the account holder via a previously verified channel. Test that this notification fires, that it contains sufficient information for the user to identify unauthorized access, and that the notification delivery channel cannot be changed without step-up authentication.

Password reset flows are the most common pathway for account takeover in financial applications. Every authentication testing engagement should begin with a complete mapping of all recovery paths, including 'forgot username,' 'locked account,' and 'new device' flows, before any other testing begins.

QA checklist summary table

The table below consolidates every test area covered in this article into a single prioritized reference. Use it to assess current coverage, plan testing cycles, and map findings to regulatory obligations.

Automation guidance: What to automate, what to keep manual

Not every item in the checklist above is equally suited to automation. Misclassifying tests as automatable when they require adversarial manual judgment wastes engineering time and creates false coverage confidence. The framework below provides a practical decision boundary.

Automate in CI/CD regression

These are the tests that should run on every build and every release, providing continuous validation of the authentication baseline:

• Password policy enforcement at the API level, submit non-compliant credentials directly to authentication endpoints

• OTP expiry and reuse rejection, token replay immediately after use; token submission after time-window expiry

• Session token expiry, replay captured tokens after their defined expiry interval

• Post-logout token invalidation, replay a captured token after the logout endpoint has been called

• Step-up authentication trigger, confirm each defined high-risk action returns a step-up challenge when called without the step-up credential

• SCA audit log completeness, confirm log entries are generated for each authentication event with required fields present

Periodic manual assessment, quarterly or pre-release

These tests require human judgment, adversarial creativity, or interaction with external systems that automation cannot reliably simulate:

• MFA bypass scenarios, downgrade attack simulation, IP exception testing, federated login gap assessment

• Account recovery flow security, token reuse, enumeration, cross-channel bypass

• Cross-device biometric enrollment security, new device registration without step-up verification

• SCA exemption boundary conditions, structured transaction testing to probe exemption misuse

• Session management under adversarial conditions, concurrent session handling, session persistence after credential changes

Security-specialist adversarial testing, annual or triggered

These tests require specialist skills, tooling, or deliberate coordination and are not suitable for routine QA cycles:

• Full authentication bypass attempts, AiTM simulation, post-authentication session token harvesting scenarios

• Biometric spoofing and deepfake resistance, 3D mask testing, AI-generated deepfake video against liveness detection

• Document forgery detection limits, systematic testing of forgery detection boundaries using realistic forgery techniques

• KYC fallback flow exploitation, attempting to trigger and abuse manual review paths as a weaker verification alternative

• Authentication downgrade in production configuration, FIDO2 suppression testing against the live production authentication configuration

Conclusion

Authentication testing in fintech is not a single test suite, it is a five-layer discipline, each layer with its own attack surface, its own regulatory mapping, and its own required testing approach. A program that covers credential authentication and MFA prompt appearance, and calls that 'authentication testing,' is leaving Layers 1, 4, and 5 effectively unexamined, which is precisely where most successful attacks operated.

The checklist in this article is designed to be used directly: map your current test suite against it, identify the gaps, and assign each gap to the appropriate testing type, automated regression, periodic manual, or specialist adversarial. The result will be a coverage map that is both more honest and more actionable than a coverage percentage.

Identity verification testing, MFA bypass testing, session token security, and KYC compliance QA are not separate disciplines, they are layers of the same security obligation. Build a testing program that covers all of them, and you have built a program that protects both your customers and your regulatory standing.

Need to audit or build your fintech authentication testing program? DeviQA's security testing practice works with fintech teams on authentication coverage assessments, MFA security testing, KYC/IDV QA, and session management validation. Get in touch to discuss your stack.

About the author

Ievgen Ievdokymov

Senior AQA engineer

Ievgen Ievdokymov is a Senior AQA Engineer at DeviQA, focused on building efficient, scalable testing processes for modern software products.