Evolution to the EMV 3DS Default SDK

Mobile authentication has changed noticeably since the early days of EMV 3DS. The original Mobile SDK was designed at a time when device operating systems, app security frameworks, and authentication methods were developing at different speeds. As mobile transactions became the dominant channel for digital payments, behaviour fragmentation across platforms became more visible.

The transition to the Default SDK is a response to that shift. It consolidates the requirements, data handling, and runtime behaviours needed for reliable mobile authentication, reducing variation and improving the consistency of outcomes.

What the Default SDK represents

The Default SDK is a baseline mobile authentication implementation defined in the EMV 3DS specification. It provides a common foundation for how:

Device and application information is collected
The authentication context is shared with the access control servers
Strong authenticator challenges are triggered and completed
The user is returned to the merchant environment after authentication

The aim is to create predictable authentication behaviour across Android and iOS environments. The earlier Mobile SDK models tended to vary depending on app frameworks, device security features, and individual implementation choices. The Default SDK is designed to reduce that variation.

Why the transition is happening

Several industry trends influenced the move:

Device-based authentication is now standard practice
- Modern devices have secure hardware-backed biometric capabilities. Authentication frameworks needed to align more closely with these system-level controls.

More consistent handling of authentication signals isrequired
- Issuers use device and contextual information to inform step-up decisions. When signal quality varies, so do authorisation outcomes.

Friction reduction is a priority
- Many abandonment issues stem from challenge flows that behave differently across mobile environments. A unified SDK helps improve predictability.

The Default SDK is designed to support these evolving authentication patterns rather than requiring workarounds or per-app adjustments.

Impact on Issuers and ACS Implementations

Standardising the mobile authentication layer allows issuers and ACS providers to:

Use stronger device-bound authenticators more reliably
Apply risk-based policies with clearer routing logic
Reduce unnecessary step-up challenges in low-risk scenarios

When authentication behaviour is predictable, policy controls become easier to tune.

Impact on Acquirers, Payment providers, and Gateways

Reliable mobile authentication data improves:

Frictionless approval rates
Challenge success consistency
Retrybehaviourin fallback cases

Since mobile checkout is now the primary channel for many merchants, predictable authentication outcomes support both security and revenue protection objectives.

Impact on Merchants and Product Teams

Merchants often interact with authentication through their payment provider rather than directly. The transition to the Default SDK may appear invisible at first, but it influences:

Checkout continuity between app and mobile browser flows
How biometric authentication is surfaced to the user
The frequency of step-up challenges

The result is more consistent user journeys and less unpredictability during payment completion.

Key Elements to Review During the Transition

When planning or assessing readiness, organisations may review:

How the application currently handles device information and authentication prompts
Return-to-merchant navigation patterns during OOB or biometrics flows
Whether historical configuration influences challenge frequency
Whether SDK data aligns with the latest Device Information specification

These are the areas most likely to affect both user experience and fraud decisioning.

Looking Ahead

The shift from the Mobile SDK to the Default SDK aligns authentication with the current state of mobile security architecture. As more issuers adopt device-bound credentials, and as biometric authentication becomes the default confirmation method, the infrastructure supporting those interactions must be consistent and reliable.

The Default SDK provides that foundation.