Mobile Authentication SDK for Issuers: Biometrics, Push and Session Binding

A mobile authentication SDK for issuers is a component embedded in a banking app that lets cardholders approve 3D Secure challenges with biometrics or device credentials. The verification result is bound to the specific authentication session it was created to complete.

For issuers in the UAE, app-based authentication is no longer optional. The Central Bank of the UAE set 31 March 2026 as the deadline for phasing out SMS and email OTPs, and in-app approval with biometric verification has become the expected way to confirm online card payments.

Replacing the OTP screen with a biometric prompt is the visible part of that shift. The harder part is coordinating mobile verification with the ACS's decisions and the lifecycle of each authentication request.

Biometrics and push notifications provide the customer interaction. Session binding connects the verification result to the intended request. Platform support determines how those capabilities fit the issuer's application stack.

In our experience, a reliable implementation keeps a clear distinction between authentication policy, local verification and the final session outcome. Most problems in app-based authentication appear where those three are mixed together.

What the OTP Phase-Out Changes for Issuers

When SMS OTP was the default, the banking app was one of several channels. If a push notification failed, the cardholder could still complete the purchase with a code. Once SMS OTP is retired, the app flow carries the full transaction volume.

That changes how app-based authentication should be designed and measured. We see three consequences:

1. Push delivery becomes part of payment conversion. A notification that arrives late or not at all is a lost purchase, not only a messaging issue.
2. Fallback needs deliberate design. Issuers need to decide in advance what happens when biometrics are unavailable, the app is outdated or the device is offline, and which alternatives the regulator still permits.
3. Session handling becomes visible to cardholders. With more purchases confirmed in the app, concurrent requests, expiry and reconnection stop being edge cases.

The sections below look at biometrics, push confirmation, session binding and platform support with these consequences in mind.

Keep Authentication Policy Separate from Mobile Verification

The ACS decides which authentication path applies to a transaction. The banking application provides the interaction when that path requires app-based verification.

This separation matters when policies change. Adjusting which transactions receive a challenge should be treated separately from changing the approval screen or upgrading a mobile dependency.

The integration has three areas of responsibility:

The exact boundary between the ACS and the authentication backend depends on the deployment.

FinOn's Authentication SDK supports ACS-triggered step-up authentication, and FinOn's ACS provides configurable policies and challenge logic through an administrative interface.

For implementation teams, the practical task is to map those responsibilities to their existing systems before defining the mobile flow.

Biometrics: Local Verification and Payment Context

Biometric verification answers a question about the person interacting with the device. The payment integration must also establish which request that verification relates to.

The approval screen therefore needs recognisable transaction context, such as merchant and amount, and clear outcomes for confirmation, rejection and expiry. A successful biometric interaction must not leave the application uncertain about the status of the underlying request.

Biometric data should stay on the device. The SDK should rely on the operating system's biometric capabilities and receive only the outcome of the check.

Cancellation, unavailable biometrics and verification failure should be handled separately. They can require different next steps and should remain distinguishable in operational reporting.

Fallback is an issuer policy decision as well as a user-interface concern. The application needs to know which alternatives are permitted and when a request can no longer continue. Where SMS OTP is being retired, as in the UAE, the permitted fallback options also need to reflect the regulator's requirements.

Push Confirmation: Delivery Is Only the First Event

Push notifications provide an entry point to app-based authentication. Their delivery does not establish that the customer reviewed the request or completed verification.

A useful monitoring model separates three events:

This distinction makes failure analysis more precise. A low request-opening rate calls for a different investigation from a high rate of backend validation failures.

The configured flow should also account for direct app opening, late notifications and multiple pending requests. In each case, the application should retrieve the current request status rather than treat the notification as the source of truth.

What Is Session Binding in App-Based 3DS Authentication?

Session binding connects a verification result to the authentication session it was created to complete.

Consider two purchases awaiting confirmation. Approval of the first must leave the second independently actionable. That relationship needs to remain intact through retries, delayed responses and connectivity interruptions.

In FinOn's Authentication SDK, the verification result is cryptographically bound to the authentication session.

Cryptographic validation and session-state management address related requirements. The implementation must establish both that the result belongs to the request and that the request can still accept it.

A compact acceptance test should cover:

1. Two concurrent authentication requests.
2. Repeated submission of a completed result.
3. Expiry during verification.
4. Loss of connectivity after confirmation.
5. Retrieval of the final status after the app reconnects.

Device registration should remain a separate concept. Associating a device with a cardholder does not establish which pending operation the cardholder approved.

Platform Support and Release Compatibility

Platform support needs to be evaluated against the application's actual dependencies.

FinOn's Authentication SDK is available for these environments:

Details are available on the FinOn ACS product page.

The compatibility matrix for the selected release should clarify supported operating-system and framework versions. For cross-platform applications, bridge dependencies and their update cycle also affect maintenance.

To remain maintainable over time, the mobile authentication SDK issuer teams choose must fit the application's release process. Regression testing should cover cold start, backgrounding, restart and interrupted connectivity whenever authentication dependencies change.

Issuer Authentication SDK vs Merchant-Side 3DS SDK

Teams often look for an ACS SDK when they need mobile verification connected to the issuer's Access Control Server. The name alone does not identify the component's role.

The host application is the useful distinction:

Requirements for a 3DS SDK iOS or 3DS SDK Android integration usually relate to the merchant application. Before comparing functionality, confirm whether the integration belongs in the merchant application or the issuer application.

FinOn provides its merchant-app SDKs as part of the 3DS Server and SDK offering, separately from the Authentication SDK delivered alongside its ACS.

EMV 3DS Certification: SDK, 3DS Server and ACS

FinOn's merchant-side 3DS SDK iOS and 3DS SDK Android are EMVCo-approved for EMV 3DS 2.2.0. FinOn's 3DS Server and ACS are approved for both EMV 3DS 2.2.0 and 2.3.1. All four approvals are listed in EMVCo's approved products directory.

Certification evidence should be matched to the exact component and release being integrated. The approval scope of a 3DS SDK should remain distinct from the issuer-side out-of-band implementation.

EMVCo identifies OOB authentication methods and implementations as outside the scope of the 3DS Core Specification.

Certification review therefore complements end-to-end testing. It does not replace validation of request handling, session expiry or completion across the issuer's configured channels.

Evaluate the Complete Authentication Flow

The most useful rollout metrics describe the full request lifecycle:

• Challenge completion rate.
• Time from initiation to final authentication result.
• Session expiry rate.
• Technical failures by integration stage.
• Fallback usage and completion.

Separate customer rejection from technical failure. Segment results by operating system, application version and authentication method so that aggregate figures do not hide platform-specific issues.

Authentication success should also remain distinct from payment authorization approval. Where downstream data is available, it can help establish whether an authentication improvement translates into better payment completion.

We recommend treating authentication as part of the payment funnel rather than as a separate security metric. An issuer that reports only fraud outcomes will not see where legitimate customers abandon the flow.

For issuers, these measurements connect SDK functionality to an operational question: whether the implemented flow gives customers a reliable way to complete the required verification. For issuers moving away from SMS OTP, they also show whether the new flow is ready to carry the full transaction volume.

Request a Technical Demo

FinOn's Authentication SDK supports Face ID, Touch ID, fingerprint and device-level credentials, push-based transaction confirmation and out-of-band authentication through the issuer application. It does not store or transmit biometric data.

To assess FinOn's Authentication SDK against your architecture, share your ACS provider, mobile framework and current authentication flow. We will walk you through biometric verification, push confirmation and session binding, including platform compatibility and certification scope.

Request an Authentication SDK Demo →