EMV 3DS Access Control Server: Passkeys, FIDO and SPC

The landscape of online payment authentication is undergoing significant transformation, driven by the dual needs of enhancing security against sophisticated fraud and improving the user experience to reduce friction and cart abandonment. The EMV® 3-D Secure (3DS) protocol, particularly its later versions (EMV 3DS 2.x), serves as the foundational technology for authenticating card-not-present (CNP) transactions globally. Managed by EMVCo, this protocol facilitates data exchange between merchants, issuers (via their Access Control Server - ACS), and the interoperability domain (Directory Servers operated by payment schemes) to verify cardholder identity.

Within this framework, two key technological advancements related to the FIDO (Fast Identity Online) Alliance standards are emerging:

1. The use of FIDO authentication data generated during prior user interactions (e.g., merchant login) to enrich the risk assessment for the EMV 3DS frictionless flow.
2. The integration of Secure Payment Confirmation (SPC), a W3C web standard built upon FIDO/WebAuthn, as a streamlined, phishing-resistant "challenge" method within the EMV 3DS flow.

This article provides an overview of the global market for EMV 3DS Access Control Server (ACS) solutions provided to issuing banks. It identifies major vendors and tries to evaluate their current support for both non-SPC FIDO data structures and Secure Payment Confirmation (SPC) for challenge flows. Furthermore, it clarifies the mechanism by which issuers can leverage their own FIDO passkeys for cryptographic verification within the 3DS challenge flow via SPC and discusses the global applicability of this standard.

EMV 3DS operates primarily through two distinct authentication pathways:

• Frictionless Flow: This is the preferred path, aiming for a seamless user experience. The issuer's ACS performs a risk assessment based on a rich set of data exchanged during the transaction initiation (via the Authentication Request, or AReq message). This data includes transaction details, merchant information, device characteristics, browser data (potentially collected via the 3DSMethod JavaScript), and potentially prior authentication information. If the risk is deemed low, the transaction is authenticated without requiring any direct interaction or "challenge" from the cardholder. This flow accounts for the majority of 3DS transactions, particularly where risk engines are well-tuned.
• Challenge Flow: If the ACS determines the transaction risk is high, if mandated by regulations (like PSD2 SCA in Europe) or issuer policy, the cardholder is actively challenged to verify their identity. Traditional challenge methods include One-Time Passcodes (OTP) sent via SMS, knowledge-based questions, or Out-of-Band (OOB) authentication via a banking app. The goal of newer 3DS versions and related technologies like SPC is to make this challenge flow more secure and less cumbersome than legacy methods.

EMVCo and the FIDO Alliance have collaborated to define a standardized way for merchants to pass information about prior FIDO authentications (where the merchant acted as the Relying Party, e.g., during user login) to the issuer's ACS within the standard 3DS AReq message. This mechanism, first supported in EMV 3DS v2.1, leverages specific fields within the AReq, primarily the threeDSRequestorAuthenticationInfo structure, which contains subfields like threeDSRequestorAuthenticationData.

The FIDO Alliance Technical Note and related EMVCo white paper specify a JSON structure for this threeDSRequestorAuthenticationData field when conveying prior FIDO authentication details. This JSON object includes details such as the authentication time (authTime), the FIDO Relying Party ID (rpId or appId), and information about the authenticator(s) used, including the public key, AAGUID/AAID, and indicators of user presence (UP) and user verification (UV).

The rationale is that if a merchant has recently performed a strong FIDO authentication (e.g., using biometrics or a passkey) for the user session initiating the purchase, this information can serve as a valuable additional risk signal for the issuer's ACS. By receiving and processing this standardized FIDO data, the ACS can potentially gain greater confidence in the transaction's legitimacy, increasing the likelihood of a frictionless approval and reducing the need for a separate challenge. It is important to note that in this scenario, the merchant is the FIDO RP, and the issuer consumes this data as an input to its risk engine; the issuer does not cryptographically verify the FIDO assertion itself within this frictionless flow. The ACS retains the option to ignore this data if not configured to process it.

Secure Payment Confirmation (SPC) represents a distinct integration of FIDO standards within the EMV 3DS challenge flow. SPC is a W3C web standard, developed in collaboration with FIDO and EMVCo, built upon WebAuthn. It is formally supported within EMV 3DS starting from version 2.3.

When SPC is used as a challenge method:

1. The issuer (or a party explicitly delegated by the issuer, such as a payment scheme) functions as the FIDO Relying Party (RP). This is fundamentally different from the non-SPC FIDO data flow described earlier, where the merchant typically acts as the RP for its own login/authentication purposes.
2. During the 3DS challenge, the ACS signals the need for SPC and provides the necessary FIDO credential identifiers and a cryptographic challenge to the merchant/3DS Server.
3. The merchant's system invokes the browser's SPC API, presenting transaction details (amount, currency, payee, instrument) to the user in a secure browser-controlled dialog.
4. The user authenticates using their FIDO authenticator (e.g., device biometrics, PIN, security key), which signs the transaction details and the challenge using the private key associated with the issuer-registered passkey.
5. The resulting FIDO assertion (cryptographic proof of authentication and consent) is passed back through the 3DS protocol (typically via a second AReq message) to the issuer's ACS.
6. The ACS, as the RP, cryptographically validates the assertion using the corresponding public key, confirming the cardholder's identity and consent to the specific transaction details.

SPC aims to provide a challenge experience that is both more secure (phishing-resistant, dynamic linking of authentication to transaction data) and potentially lower friction (often faster than OTP entry) compared to traditional methods.

The dual pathways for FIDO integration—one leveraging prior merchant authentication data for frictionless risk assessment, the other using issuer-managed credentials for a direct FIDO-based challenge via SPC—offer distinct approaches to enhancing security and user experience within the EMV 3DS framework. Understanding vendor support for each is crucial for issuers and PSPs planning their authentication strategies.

This section analyzes the capabilities of global providers of EMV 3DS ACS solutions, focusing on their market presence and support for FIDO data (non-SPC) and Secure Payment Confirmation (SPC). Precise market share figures are proprietary and difficult to obtain publicly; therefore, presence is assessed based on vendor claims, certifications, partnerships, geographic reach, and market reports.

• Market Presence: Entersekt, particularly after its acquisition of Modirum's 3DS software business in December 2023, positions itself as a leading global provider of EMV 3DS solutions, aiming for a top-five market position. Modirum had over 20 years of experience in 3DS. Entersekt highlights record growth driven by new clients, especially in North America, and strategic partnerships, including an expanded relationship with Mastercard. They claim to secure over 2.5 billion transactions annually (as of FY24) and are ranked #1 in ATO prevention in banking by Liminal. Their ACS is available hosted (by Entersekt or client) or on-premise. They serve issuers and processors globally.
• Non-SPC FIDO Data Support (Frictionless): Entersekt emphasizes its Context Aware™ Authentication, device and behavioral analytics for risk signals, and integration with various risk-scoring services. Their ACS is FIDO EMVCo 2.2 certified. While they highlight leveraging risk and behavioral intelligence data for RBA, explicit confirmation of processing the standardized FIDO attestation data from prior merchant authentications within the threeDSRequestorAuthenticationInfo field for frictionless flow enhancement is not explicitly stated in online materials. However, their focus on advanced authentication and risk signals suggests capability.
• SPC Support (Challenge): Strong indicators suggest Entersekt supports SPC. Modirum, whose 3DS business Entersekt acquired, provided components for Visa's SPC pilot using 3DS 2.2 with extensions. Entersekt explicitly lists support for SPC compliance as part of its regulatory compliance capabilities. Their ACS supports biometric authentication, is certified for EMV 3DS 2.2, and likely incorporates capabilities from Modirum's pilot involvement. The combination of the Modirum acquisition, explicit mention of SPC compliance, and FIDO certification strongly points towards SPC support in their current offering.

• Market Presence: Broadcom's Arcot is a foundational player in the 3DS market, having co-invented the original protocol with Visa. They position themselves as a recognized global leader, serving over 5,000 financial institutions worldwide and processing transactions from 229 countries. Their Arcot Network emphasizes a vast consortium data approach (claiming 600M+ device signatures, 150 trillion data points) to power their fraud scoring and risk engines. They have a strong presence in Europe, Australia, and North America.
• Non-SPC FIDO Data Support (Frictionless): Broadcom heavily emphasizes the richness of their data network and the use of AI/neural networks for fraud detection and risk-based assessment, going beyond standard EMV 3DS data elements. They explicitly state their solution leverages data flowing through multiple issuers and incorporates digital data like device and geolocation. While not explicitly mentioning processing the specific FIDO JSON structure from threeDSRequestorAuthenticationData, their focus on ingesting diverse data points for RBA strongly suggests they could consume such data if provided, aligning with the intent of the EMVCo/FIDO guidance. Their platform aims to maximize frictionless approvals through superior risk assessment.
• SPC Support (Challenge): Broadcom's documentation confirms support for FIDO authenticators (Security Key, Biometric, Passkey) within their broader VIP Authentication Hub / Identity Security suite. Their 3DS ACS supports various challenge methods including OTPs and push notifications, and they mention support for biometrics. They also offer Delegated Authentication capabilities and have introduced post-challenge risk evaluation features. However, explicit confirmation that their EMV 3DS ACS product currently supports SPC as a specific challenge method (requiring EMV 3DS v2.3+ capabilities and the two-AReq flow) is absent in the provided documentation. While they are a major player likely capable of implementing it, current public-facing material focuses more heavily on their RBA engine and traditional/OOB challenge methods.

• Market Presence: Netcetera positions itself as a significant international payment player, particularly strong in Europe and the Middle East. They state their ACS is used by over 800 banks/issuers, securing 50+ million cards worldwide. They emphasize certifications with all major card networks (Visa, Mastercard, Amex, Discover, JCB, UnionPay, etc.) and PCI compliance. They were notably the first ACS vendor worldwide to achieve EMV 3DS 2.3.1 certification.
• Non-SPC FIDO Data Support (Frictionless): Netcetera's documentation highlights the importance of data gathered via the 3DSMethod for ACS risk assessment to increase frictionless authentication. They offer integration with risk tools. However, specific confirmation of processing prior merchant FIDO authentication data (from threeDSRequestorAuthenticationInfo) for risk assessment is not explicitly mentioned in the reviewed materials.
• SPC Support (Challenge): Netcetera demonstrates strong support for SPC. They were the first vendor globally certified for EMV 3DS 2.3.1, the version incorporating SPC. They participated in the Visa SPC pilot, providing the v2.3.1 components. Their product documentation explicitly defines SPC. They have conducted webinars discussing FIDO and SPC integration and published articles highlighting SPC's benefits. This combination of certification, pilot participation, and explicit documentation confirms their support for SPC challenges.

• Market Presence: Worldline positions itself as the European leader in payment and transactional services and a major global player (claiming #4 worldwide payment player status). They process billions of transactions annually and emphasize guaranteed compliance, fraud control using AI/ML, and scalability. Their ACS is stated to be EMV 3DS certified and compliant with major schemes (Visa Secure, Mastercard Identity Check) and PSD2. They report processing over 2.4 billion 3DS transactions yearly for over 100 issuers.
• Non-SPC FIDO Data Support (Frictionless): Worldline's ACS offering includes an RBA rules engine allowing issuers to configure frictionless or challenge flows based on risk. Their broader "Trusted Authentication" solution leverages device intelligence and behavioral analysis. While they support FIDO generally, explicit confirmation of processing prior merchant FIDO data (non-SPC) within the ACS for risk assessment is not detailed in the provided snippets.
• SPC Support (Challenge): Worldline shows clear indications of supporting SPC. Their documentation acknowledges the evolution of EMV 3DS 2.3 to include SPC/FIDO. They explicitly market their "WL Trusted Authentication" solution as supporting FIDO authentication and offer a "WL FIDO Server" suitable for "3DS use cases, with emvCO2.3 and SPC.

• Market Presence: GPayments positions ActiveAccess as a "robust market leading Access Control Server (ACS) platform" with over 20 years in the 3D Secure space. They are certified with major card schemes (Visa Secure, Mastercard Identity Check, JCB J/Secure) for both 3DS1 and EMV 3DS. Their solution can be deployed on-premise or cloud-hosted. Market reports identify GPayments as a notable player offering ACS solutions.
• Non-SPC FIDO Data Support (Frictionless): ActiveAccess supports integration with third-party RBA solutions and utilizes various parameters for its own risk assessment. However, the provided documentation does not explicitly mention support for ingesting or using prior merchant FIDO authentication data (non-SPC) for frictionless risk assessment.
• SPC Support (Challenge): The reviewed documentation for ActiveAccess does not explicitly mention support for Secure Payment Confirmation (SPC), WebAuthn challenges, or FIDO challenges as part of its challenge flow capabilities. While they support various authentication methods including OOB (which can encompass biometrics), specific SPC support is unclear from the available information.

• Market Presence: Visa, as a major global payment network, defines the Visa Secure program based on the EMV 3DS standard. They pioneered the original 3DS protocol. Rather than primarily acting as a direct ACS vendor in the same way as technology companies like Entersekt or Broadcom, Visa operates the program and relies on a list of approved 3DS vendors (including ACS providers) whose products are certified compliant with EMV 3DS and Visa Secure rules. Issuers typically procure ACS solutions from these certified vendors. Visa itself focuses on the network (Directory Server), defining program rules, promoting adoption, and driving innovation like SPC pilots.
• Non-SPC FIDO Data Support (Frictionless): Visa Secure, based on EMV 3DS, inherently supports the exchange of rich data for risk assessment to enable frictionless flow. The EMVCo/FIDO framework for passing prior FIDO data operates within the Visa Secure ecosystem if the chosen ACS vendor supports processing it.
• SPC Support (Challenge): Visa is actively involved in piloting and promoting SPC. They are working with partners (like Netcetera and Modirum/Entersekt in pilots) to test and refine the SPC flow within the 3DS protocol. This strong engagement indicates strategic support for SPC as a challenge method within the Visa Secure program, contingent on ecosystem readiness (ACS, merchant, browser support).

• Market Presence: Similar to Visa, Mastercard operates the Mastercard Identity Check program based on EMV 3DS. They provide options for issuers and merchants, including stand-in processing and potentially leveraging partners or subsidiaries like NuData. Mastercard acquired NuData Security, a behavioral biometrics company, in 2017, enhancing its risk assessment capabilities. They also emphasize ongoing innovation in biometrics, RBA, and AI. Like Visa, they rely on certified vendors for core ACS components but may offer bundled services or leverage acquired technology.
• Non-SPC FIDO Data Support (Frictionless): Mastercard Identity Check leverages the rich data exchange of EMV 3DS 2.x for improved risk decisioning and frictionless flow. Their acquisition of NuData suggests a strong focus on behavioral analytics as part of this risk assessment. Support for processing prior merchant FIDO data would depend on the specific ACS implementation used by the issuer within the Identity Check program.
• SPC Support (Challenge): Mastercard is a key member of EMVCo and involved in the development of EMV 3DS standards, including v2.3 which supports SPC. They are also promoting passkey adoption more broadly. More details can be found here. They are a strong SPC supporter and push towards modern authentication methods.

The EMV 3DS ACS market features numerous providers beyond those detailed above. Vendors such as /n software, RSA, 2C2P, 3dsecure.io, Adyen, ACI Worldwide, Computop, and others also offer certified solutions or play significant roles in specific regions or segments. This analysis aims to cover prominent global players but is not exhaustive due to the market's dynamic nature. Vendor capabilities, particularly regarding emerging standards like SPC, evolve rapidly. If you notice any inaccuracies or have updated information on vendor support for FIDO data or Secure Payment Confirmation, please reach out so we can ensure this overview remains current and accurate.

A core principle of using Secure Payment Confirmation (SPC) within the EMV 3DS challenge flow is that the card issuer (or a party explicitly delegated by the issuer, such as a payment scheme) functions as the FIDO Relying Party (RP). This is fundamentally different from the non-SPC FIDO data flow described earlier, where the merchant typically acts as the RP for its own login/authentication purposes.

For SPC to function in a 3DS challenge, the following steps are involved:

1. Enrollment: The cardholder must first register a FIDO authenticator (e.g., device biometrics like fingerprint/face ID, device PIN, or a roaming security key) with their issuing bank. This process creates a passkey, where the public key and a unique credential identifier are stored by the issuer and associated with the cardholder's account or specific payment card. Enrollment might occur within the bank's mobile app, online banking portal, or potentially offered after a successful traditional 3DS challenge. Crucially, for SPC to be invoked by a third party like a merchant website, the credential must typically be created with explicit user consent allowing its use in such contexts, often involving specific WebAuthn extensions during registration.
2. Authentication (during 3DS Challenge):
   • When a 3DS transaction triggers a challenge, and the issuer/ACS supports and selects SPC, the ACS identifies the relevant FIDO credential ID(s) linked to the cardholder and device.
   • The ACS includes these credential ID(s), along with a unique cryptographic challenge and transaction details (amount, currency, payee name/origin, instrument icon/display name), in the Authentication Response (ARes) sent back to the 3DS Server/Requestor.
   • The merchant's 3DS Requestor component uses this information from the ARes to invoke the browser's SPC API.
   • The browser presents a standardized, secure dialog displaying the transaction details provided by the ACS.
   • The user confirms the transaction and authenticates using their registered FIDO authenticator (e.g., touching a fingerprint sensor, facial recognition, entering device PIN, tapping a security key). This action unlocks the private key stored securely on the device/authenticator.
   • The authenticator signs the presented transaction details and the cryptographic challenge received from the ACS.
   • The browser returns the resulting FIDO assertion (the signed data payload) to the merchant's 3DS Requestor.
   • The 3DS Requestor transmits this assertion back to the Issuer ACS, typically encapsulated within a second AReq message.
   • The Issuer/ACS, acting as the authoritative Relying Party, uses the cardholder's previously stored public key to cryptographically verify the signature on the assertion. Successful verification confirms that the legitimate cardholder, using their registered authenticator, approved the specific transaction details presented.

The integration of SPC into the EMV 3DS challenge flow necessitates modifications to the standard message sequence, typically involving two AReq/ARes exchanges:

1. Initial Authentication Request (AReq #1): The merchant/3DS Server initiates the 3DS process by sending an AReq containing transaction and device data. To signal capability for SPC, the request may include an indicator like threeDSRequestorSpcSupport set to 'Y' (or similar, depending on the ACS vendor's implementation).
2. Initial Authentication Response (ARes #1): If the ACS determines a challenge is required and opts for SPC, it responds with an ARes indicating this. The transStatus might be set to 'S' (indicating SPC required) or another specific value. This ARes contains the necessary data payload for the SPC API call.
3. SPC API Invocation & FIDO Authentication: The merchant's 3DS Requestor component receives ARes #1 and uses the payload to invoke the browser's SPC API. The user interacts with their authenticator via the browser's secure UI.
4. FIDO Assertion Return: Upon successful user authentication, the browser returns the FIDO assertion data to the 3DS Requestor.
5. Second Authentication Request (AReq #2): The 3DS Requestor constructs and sends a second AReq message to the ACS. This message's primary purpose is to transport the FIDO assertion data. It typically includes:
   • ReqAuthData: Containing the FIDO assertion.
   • ReqAuthMethod: Set to '09' (or the designated value for SPC/FIDO assertion.
   • Potentially the AuthenticationInformation value from ARes #1 to link the requests.
   • Optionally, an SPCIncompletionIndicator if the SPC API call failed or timed out.
6. Final Authentication Response (ARes #2): The ACS receives AReq #2, validates the FIDO assertion using the cardholder's public key, and determines the final authentication outcome. It sends back ARes #2 containing the definitive transaction status (e.g., transStatus = 'Y' for Authentication Successful, 'N' for Failed).

This two-AReq flow represents a deviation from traditional 3DS challenge methods (like OTP or OOB handled via CReq/CRes or RReq/RRes messages) which typically complete within the initial AReq/ARes cycle after a transStatus = 'C' is received. While the user interaction part of SPC (biometric scan, PIN entry) is often significantly faster than typing an OTP, the introduction of a second full AReq/ARes round trip adds network latency between the 3DS Server, Directory Server, and ACS. Implementers and vendors must carefully optimize this flow and handle potential timeouts to ensure the overall end-to-end transaction time remains competitive and meets user expectations.

Secure Payment Confirmation is positioned for global adoption due to its dual standardization. It is formally defined as a web standard by the World Wide Web Consortium (W3C), having reached Candidate Recommendation status in mid-2023 with ongoing work towards becoming a full Recommendation. Simultaneously, SPC has been integrated into the EMV® 3-D Secure specifications starting with version 2.3, managed by EMVCo, the global technical body for payment standards. This integration ensures that SPC functions within the established global framework for CNP transaction authentication. The collaboration between W3C, FIDO Alliance, and EMVCo underscores the industry-wide effort to create interoperable standards for secure and user-friendly online payments.

While SPC's design, particularly its ability to cryptographically link user authentication to specific transaction details ("dynamic linking"), helps satisfy Strong Customer Authentication (SCA) requirements under regulations like Europe's Payment Services Directive (PSD2), its utility is not confined to these mandated regions. SPC is a global technical standard applicable in any market, including the United States and Canada, provided the necessary ecosystem components are in place.

In markets without explicit SCA mandates for every transaction, the primary drivers for adopting SPC are:

• Improved User Experience: Offering a potentially faster and more convenient challenge method (e.g., using device biometrics) compared to traditional OTPs or knowledge-based questions, potentially reducing cart abandonment. Pilots have shown significant reductions in authentication time compared to traditional challenges.
• Enhanced Security: FIDO-based authentication inherent in SPC is resistant to phishing attacks, credential stuffing, and other common threats targeting passwords and OTPs.

Therefore, issuers and merchants in regions like North America may choose to implement SPC strategically to enhance security and provide a better customer experience, even without a regulatory requirement to do so for all transactions.

The successful deployment and widespread adoption of Secure Payment Confirmation (SPC) depend heavily on coordinated readiness across multiple components of the payment ecosystem. While the underlying FIDO standards and passkey technology are maturing rapidly, specific browser-level support for the SPC API and full integration across the payment chain remain critical hurdles. Other ecosystem players are generally advancing well.

Ecosystem Readiness Summary (Status May 2025)

What this means in practice (May 2025)

The primary gating factor for SPC adoption is the user-agent (browser) layer:

• Safari (macOS & iOS): ❌ WebKit still lacks the secure-payment-confirmation Payment Request method. Any site visited in Safari must fall back to other authentication methods (OTP, OOB, potentially non-SPC WebAuthn experiences). Apple has not expressed interest to implement the extension.
• Chrome / Edge (Chromium): ⚠️ Baseline SPC (credential creation + authentication) is stable, but keys are not yet stored in hardware authenticators and have only be used in pilots. Implementers should expect potential breaking changes and be prepared to gate functionality based on API availability checks (e.g., canMakePayment()) or feature flags.
• Firefox: ❌ The team has signalled interest but has no committed implementation timeline; merchants must plan for graceful fallback paths.

Because issuer infrastructure (ACS, FIDO servers) and scheme directory servers are largely ready or advancing rapidly, and merchant/PSP tools are becoming available, the main barrier to widespread SPC usage is browser support. Once browser coverage improves, the remaining tasks primarily involve merchant/PSP integration (upgrading to EMV 3DS v2.3+, adding SPC invocation logic, handling the two-AReq flow) and scaling up issuer enrollment of passkeys specifically for payment contexts.

For now, expect SPC to appear only for a limited slice of transactions. Until Safari (and thus the entire iOS ecosystem) ships support, SPC cannot achieve market support.

The analysis reveals a clear divergence in the readiness of the two primary FIDO integrations within EMV 3DS as of May 2025. While the foundational elements for Secure Payment Confirmation (SPC) as a challenge method are advancing – particularly issuer/ACS capabilities and scheme readiness – its widespread adoption is significantly hampered by the critical bottleneck of browser support, most notably the lack of implementation in Apple's Safari (blocking all iOS/iPadOS devices) and Firefox, along with limitations in current Chromium implementations. SPC remains a promising future state, but it is not a practical, ubiquitous solution today.

Based on the current ecosystem state we following recommendations are in place:

• Merchants:
  • Prioritize Passkey Adoption: Implement passkeys for user login and authentication. Beyond improving your own security and user experience (factors not detailed here), this creates the data needed for 3DS frictionless flows.
  • Pass FIDO Data: Ensure your 3DS integration correctly populates the threeDSRequestorAuthenticationInfo field with details of successful prior passkey authentications during the checkout session. Work with your PSP/3DS Server provider to enable this.
• Issuers:
  • Enroll User Passkeys: Begin offering and encouraging cardholders to enroll passkeys directly with you (for banking app access, future SPC, etc.). Build the necessary FIDO Relying Party infrastructure.
  • Leverage Merchant Passkey Data Now: Instruct your ACS vendor to ingest and utilize the FIDO data passed by merchants (threeDSRequestorAuthenticationInfo) as a strong positive signal within your RBA engine. Maintain records of trusted merchant passkeys associated with users where possible. Aim to significantly increase frictionless approvals for transactions preceded by a strong merchant passkey authentication.
  • Prepare for SPC, Monitor Actively: Ensure your ACS roadmap includes full EMV 3DS v2.3.1+ SPC support, but treat it as a future enhancement. Continuously monitor browser developments (especially Safari) to gauge when SPC might become viable at scale.
• ACS Vendors:
  • Enhance RBA with Passkey Intelligence: Heavily invest in your RBA engine's ability to process and trust merchant-provided FIDO/passkey data. Develop logic to track passkey usage across merchant purchases for a given user/device. Store public keys (from direct issuer enrollment) to verify the cryptographic integrity of merchant authentication data if provided. Tie successful passkey usage directly to higher frictionless approval rates.
  • Build Robust SPC Capabilities: Continue developing and certifying full SPC challenge flow support (EMV 3DS v2.3.1+) in readiness for future market adoption.
• Payment Schemes/Networks:
  • Champion Frictionless FIDO Data: Actively promote and potentially incentivize the passing and utilization of merchant FIDO authentication data (threeDSRequestorAuthenticationInfo) within the 3DS flow. Provide clear guidance and support to issuers and ACS vendors on leveraging this data effectively for RBA.
  • Continue SPC Advocacy & Browser Engagement: Maintain efforts to standardize and promote SPC, critically engaging with browser vendors (Apple, Mozilla, Google) to encourage full, interoperable implementation of the SPC API standard.

The immediate, tangible opportunity lies in enhancing the frictionless flow by leveraging the growing adoption of passkeys at the merchant level. All ecosystem participants should prioritize enabling the creation, transmission, and intelligent consumption of this prior authentication data within the existing EMV 3DS framework. This path offers near-term benefits in reducing friction and potentially fraud without waiting for universal SPC browser support. Concurrently, preparing the groundwork for SPC – particularly issuer passkey enrollment and ACS readiness – ensures the ecosystem is positioned to adopt this superior challenge method once the browser bottleneck is resolved.