Application of FIDO2 and PAD Level 2 for Digital Banking

Digital banking is facing a dual pressure: simplifying the customer experience while simultaneously strengthening security to prevent phishing, account takeover, biometric spoofing, and increasingly sophisticated fraud. In this context, authentication models heavily reliant on traditional OTP are exposing growing limitations in terms of security level, authentication evidence quality, and operational efficiency.

Why do banks need to upgrade the authentication layer now?

Regulatory frameworks for digital banking are shifting from simply requiring “authentication” to demanding “strong authentication with device control, application control, provability, and auditability.” According to this direction, banks need a solution that not only handles login but also covers device changes, reactivation, identity updates, and transactions with abnormal signals.

In particular, when facial biometrics are used as a security factor for critical journeys, simple face matching is no longer sufficient. Systems require an additional layer of Presentation Attack Detection (PAD) Level 2 to enhance resistance against photo attacks, replay attacks, video injection, deepfakes, and other advanced spoofing techniques.

What are the biggest challenges of OTP and soft OTP?

SMS OTP and soft OTP still play roles in many legacy systems, but this model relies on shared secrets per session or per transaction. This makes OTP an attractive target for phishing, SIM swap, social engineering, and malware attacks targeting end-user devices.

From a banking perspective, the three biggest limitations are fraud risk, user experience, and the quality of authentication evidence. In dispute scenarios, banks often need stronger proof that the legitimate user, on a legitimate device, actually approved the action.

What makes FIDO2 different for digital banking?

The core differentiator of FIDO2 lies in its device-bound asymmetric key model. The private key is securely stored locally on the user’s device, while the public key resides on the authentication server. This significantly reduces phishing risks while improving the quality of authentication evidence.

In Mobile-ID’s proposed architecture, FIDO2 is used not only for login but also for step-up authentication, transaction confirmation, and high-risk re-verification journeys. This enables a gradual transition toward passwordless banking aligned with each channel’s readiness.

What problems does PAD Level 2 solve that basic face match cannot?

Many banks have implemented facial recognition for onboarding or re-authentication. However, when facial biometrics become a security factor for financially impactful or identity-critical journeys, simple face matching is insufficient. The system must also defend against presentation attacks.

PAD Level 2 adds protection against spoofing techniques such as printed photos, video replay, masks, and deepfakes. This is critical in scenarios like device reactivation, account unlock, authentication reset, identity profile changes, or high-value transactions with abnormal signals.

Target architecture: from banking apps to a trust orchestration layer

The proposed architecture is designed for seamless integration with existing banking ecosystems. Front-end channels include Mobile Banking, Internet Banking, corporate banking, and journeys supported by back-office or contact centers. Behind them is the trust orchestration layer hosting Trusted Hub, policy engine, transaction approval, device binding, and Face Match + PAD Level 2.

The integration layer connects to IAM/CIAM, Core Banking, CIF, API Gateway, fraud engine, notification systems, and SIEM. On top is the operations and governance layer ensuring logging, audit trails, HA/DR, security monitoring, and audit readiness. This model clearly separates authentication, risk decisioning, and transaction execution across microservice boundaries.

Priority flows for initial implementation

1. Device registration and FIDO credential enrollment

Users authenticate via existing mechanisms or verified identity flows. The application checks device integrity and app version, then invokes Trusted Hub to initiate credential registration. The credential is bound to the account, device, and usage policy.

2. Daily login

The app or web channel sends an authentication request to Trusted Hub. Users authenticate locally via device biometrics or policy- compliant unlock methods. Trusted Hub verifies the assertion, returns the authentication result, and records a complete audit trail.

3. High-risk transaction confirmation

The risk or policy engine evaluates the transaction. When thresholds are exceeded or anomalies are detected, step-up authentication via FIDO2 is triggered. For more sensitive cases, Face Match + PAD Level 2 may be required before execution.

4. Identity or device changes

These are high-risk journeys. Mobile-ID recommends stronger re-verification than standard login, combining FIDO2, PAD Level 2, and additional policy checks, while ensuring sufficient evidence is stored for audit and dispute resolution.

Compliance mapping aligned with regulatory requirements

The proposal emphasizes a practical approach that simplifies compliance matrix creation and acceptance documentation. Mobile-ID’s model maps regulatory requirements to technical controls and operational processes.

Implementation approach and roadmap

To align with real banking environments, Mobile-ID structures rollout into phased stages to control risk while delivering early value.

• Phase 1 – Foundation & Compliance Baseline: assess current state, integrate Trusted Hub with mobile apps, internet banking, IAM/CIAM, and fraud engines; establish security baseline, logging, and monitoring.
• Phase 2 – Strong Authentication for Key Journeys: extend FIDO2 to step-up authentication and transaction confirmation for priority journeys.
• Phase 3 – PAD Level 2 for High-Risk Journeys: integrate Face Match + PAD Level 2 for device change, authentication reset, identity updates, and sensitive transactions.
• Phase 4 – Enterprise Scale & Optimization: expand to Internet Banking and corporate banking, optimize performance, DR drills, and operational KPIs.

Operating model, security, and integration

The solution is designed to be bank-grade, covering not only authentication functionality but also operational requirements such as HA/DR, audit trails, event logging, policy management, credential lifecycle management, fraud engine integration, and incident investigation support.

On the mobile layer, it can integrate with protections like root/jailbreak detection, anti-hooking, anti-repackaging, runtime integrity, and version control policies. On the backend, the Trust Layer centralizes authentication logic and evidence instead of distributing it across multiple channels or applications.

Business value for banks

Why choose Mobile-ID?

Mobile-ID’s differentiation lies in offering a complete FIDO2 stack from client and authenticator to server, tightly integrated with policy engines, Face Match + PAD Level 2, and evidence layers tailored for banking environments. This reduces multi-vendor integration risks, increases consistency, and gives banks greater control over both user experience and risk management.

Rather than providing a standalone SDK or authentication server, Mobile-ID positions the solution as a scalable trust orchestration layer aligned with real-world banking operations in Vietnam.