Most global industry coverage of Strong Customer Authentication (SCA) treats card issuers as passive components in an ecosystem, shaped by merchants and acquirers: who must support 3DS, which merchant categories cause the most step-up friction, and who carries liability when authentication fails.
This view is operationally incomplete. Issuers are decision-makers. They approve or reject an authentication request, accept or refuse a delegated SCA claim, and hold the scheme obligations that govern how all of this is configured. Right now, those obligations are mid-transition: some deadlines have already passed and are now a question of whether your bank is compliant, others arrive across the rest of 2026.
This is a structured account of both: the requirements you should already have in place, and the ones still coming.
Regulation sets the rule, Visa sets the implementation
SCA under PSD2 requires at least two of three factors: something the cardholder knows, has, or is.
What has changed is the scheme infrastructure Visa expects issuers to support to remain compliant: the programs they must participate in, the flows their Access Control Server (ACS) must process, and the certifications they must hold. The distinction matters because a bank can meet the PSD2 mandate while falling out of step with the Visa scheme rules that govern how that mandate is implemented. Compliance is never a static target.
The DAF 3DS Sunset
The authentication landscape is undergoing its biggest revision since EMV 3D Secure. Visa's Digital Authentication Framework (DAF) 3DS program, which records an authenticated payment credential relationship between a card number and a registered merchant at the network level, requiring issuers to approve subsequent authentication requests for that combination without prompting the cardholder to re-authenticate, sunsets in September 2026.
This is a confirmed rulebook change. After that date no new participants will be accepted. Issuers with card ranges enrolled in DAF 3DS should confirm which ranges are affected, prepare to de-enrol those ranges ahead of the September 2026 close, and consider cardholder communication where cardholders have come to expect frictionless behaviour at enrolled merchants.
Only the current 3DS-based routing is ending. The Visa Token Service (VTS) DAF program is unaffected. The principal succession path Visa points issuers toward is the Visa Payment Passkey (VPP) service.
Visa Payment Passkey: Issuer participation requirements
Visa Payment Passkey (VPP) is a FIDO-based, device-bound authentication method built on public-key cryptography. The private key stays on the cardholder's device and is never transmitted across the network.
The relevant compliance point is the issuer participation requirement. Issuers are required to offer enrolment and management of passkeys through their own digital channels, which requires integration with Visa's issuer-side VPP infrastructure, involving native enrolment, secure credential binding and lifecycle management (issuance, device binding, revocation) in your banking app, and an ACS updated to consume, validate, and store FIDO attestations inside the authorisation window.
The deadline is regional, and the two halves now sit on opposite sides of the line. VPP Support and Liability requirements take effect 18 April 2026 for the Europe Region and the AP Region (confirm the full exclusion list against your Visa Online agreement, as the definitive carve-outs are set out in the restricted implementation guides rather than the public rulebook), and 24 October 2026 for the Canada, CEMEA and LAC Regions (LAC excludes Chile). For Europe and AP issuers, this is now a current obligation to evidence, not a future one to prepare for.
Ingesting enriched risk telemetry via DCAP
DCAP and VPP were released as one rule pair (Visa Core Rules) on the same two effective dates: 18 April 2026 for Europe and AP, 24 October 2026 for Canada, CEMEA and LAC. DCAP also launched in the US on 18 April 2026.
Most coverage frames DCAP as a merchant program. The issuer angle is less visible but operationally important: DCAP passes enriched transaction signals through Visa's network to issuers during authorisation, so they can make more informed authorisation decisions in flows where no 3DS challenge has been triggered. The payload typically includes device identifiers, IP address, full billing address and email address.
For the issuer, the compliance and operational requirements are:
- Consuming the enriched data. The program only functions as designed if the issuer's risk decisioning is configured to read and weigh the DCAP data fields. Enriched data that arrives but is never processed delivers none of the intended benefit. This is a configuration obligation that sits with the issuer, not the merchant.
- Understanding the liability structure. The DCAP data-only flow does not carry the liability shift present in a full 3DS-authenticated transaction. For issuers, that means the liability profile of a DCAP-enriched transaction differs from a fully authenticated one, which is a distinction the compliance and risk teams need to understand and document, because it changes who is accountable when a transaction is later challenged.
- Engaging with data quality standards. Visa applies data quality standards to what acquirers and merchants submit, and transactions that fail those standards do not qualify for DCAP. When poor-quality data still reaches the issuer, decision quality degrades. Issuers benefit from treating DCAP data quality as a compliance touchpoint rather than something they silently absorb.
Eligibility governance for delegated authentication
Visa's Delegated Authentication program lets qualifying merchants run the primary SCA verification path themselves, under an explicit contractual agreement with the issuer. The merchant submits confirmation via the 3DS flow that SCA was performed, and the issuer accepts the claim. However, this delegation does not absolve the card-issuing bank from final security oversight.
To satisfy regulatory review, three structures must be formally documented and governed:
- Right to decline: The issuer is not obliged to accept every delegated authentication claim. Visa's rules give issuers the right to review which merchants may perform delegated authentication for their card ranges. In practice, this calls for a structured vetting process that retains the right to approve or decline any merchant based on live performance.
- Risk framework assurance: Issuers are not expected to verify every event, but they are expected to operate a risk framework governing which merchants they extend this trust to, at what values, and when they withdraw it, backed by continuous performance verification against network thresholds.
- Liability documentation: When an issuer accepts a delegated SCA claim, the resulting liability shift is what makes the program work for merchants. The issuer must decide and contractually log which merchants and transaction categories it accepts this for. An undocumented liability position is difficult to defend in a scheme review.
For issuers in Europe, the requirements carry additional regulatory weight given the PSD2 framework, but the Visa scheme obligations apply across all regions, and non-compliance carries the standard range of Visa enforcement consequences.
The 3DS certification clock
Visa periodically updates the test cases that issuers must certify against. Falling behind on certification can mean your ACS is processing authentication requests against outdated parameters, which is a compliance exposure even when the system looks like it is working.
Two items relevant for 2026:
- DAF test cases are now optional. As of 30 October 2025, DAF 3DS test cases became optional for Visa Secure certification, reflecting the September 2026 sunset. Issuers’ technical teams must verify that legacy validation scripts are updated to eliminate these redundant testing loops, and to ensure testing environments are aligned with current VPP and FIDO validation paths.
- Compelling Evidence 3.0 (CE3.0) auto-qualification. From 17 October 2025, Visa began automatically qualifying transactions for Compelling Evidence 3.0 through Visa Secure, including Visa Data Only flows, with an associated fee for successful qualifications introduced from 17 April 2026. The compliance implication for issuers is that authenticated transactions are increasingly used as CE3.0 evidence downstream, which raises the bar on ACS record-keeping and authentication data quality.
How issuers miss deadlines they were notified about
Every change was communicated through Visa's standard bulletin and rulebook channels. Yet issuers still miss effective dates and absorb non-compliance fees.
The failure mode is operational latency: a bulletin is received, acknowledged, and queued, then takes weeks of cross-department assessment just to identify which system is affected. By the time resources are assigned, the timeline has collapsed into last-minute configuration.
The surface is large. A VPP requirement needs input from digital banking, the ACS vendor, the risk-engine team and potentially core banking, yet the compliance team that spots the deadline is rarely the team that implements it. Issuers tracking bulletins through spreadsheets, email forwarding and shared inboxes run this with the most friction and the least auditability. It is the same gap that catches issuers out on monitoring-program thresholds.
A compliance checklist for issuer authentication obligations
Not exhaustive, but it covers the items most likely to be either live and unverified or still in progress. Treat the passed deadlines as items to evidence, the future ones as items to plan.
Visa Payment Passkey (VPP) Integration
- Is your ACS updated to process and store FIDO cryptographic attestations inside the authorisation window?
- Do you offer VPP enrolment and lifecycle management through your own digital channel? If not, is there a documented plan?
- Have you confirmed your region's effective date (18 April 2026 for Europe / AP; 24 October 2026 for Canada / CEMEA / LAC (excluding Chile))?
Digital Commerce Authentication Program (DCAP)
- Is your risk decisioning configured to consume DCAP-enriched data fields?
- Have you documented that the DCAP data-only path does not carry a 3DS liability shift and confirmed your transaction scoring logic?
Delegated Authentication
- Do you have an active review process for which merchants may perform delegated authentication against your card ranges?
- Do you hold formal liability-acceptance logs for each merchant you extend delegated status to?
Digital Authentication Framework (DAF) sunset and Visa Secure / CE3.0
- Have you confirmed which card ranges are enrolled in DAF 3DS today, with a transition plan before September 2026?
- Are your authentication records of sufficient quality to serve as CE3.0 evidence downstream, and have you accounted for the 17 April 2026 CE3.0 fee?
The forward view: PSD3
PSD3 is still moving through the EU legislative process, with application not expected before 2027 at the earliest. The direction of travel is clear: stronger authentication, higher data-quality standards, and more specific issuer obligations. The changes Visa is making now (passkeys, DCAP, the DAF sunset) are the scheme infrastructure that will underpin it. Issuers behind on this wave will face a compounding catch-up problem as PSD3 lands.
Clean mandate tracking via Kajo
To remove this structural latency and protect your operations from unexpected fees, you have to address the root causes: manual checks of payment network updates, spreadsheet tracking, and emailing stakeholders for feedback.
Kajo gives issuing banks an automated way to manage scheme compliance obligations as they arrive, converting Visa, Mastercard, and other primary networks' bulletins into actionable internal tasks, routing them to the right stakeholders while maintaining a clear audit trail. It ingests, filters, and interprets weekly updates, surfacing the bulletins that affect your specific portfolio.
See how card issuers use Kajo to minimise oversights, streamline bulletin coordination, and secure audit readiness across every mandate.