Every EMV 3D Secure (EMV 3DS) challenge depends on cardholder contact data: the phone number that receives a one-time passcode, the email address used as a fallback, the device registered for banking-app approvals. When that data is out of date, genuine cardholders cannot complete the challenge. When it has been taken over, the challenge goes to the fraudster.
Issuers tend to treat challenge performance as an Access Control Server (ACS) question. Much of it is a data question.
How cardholder contact data failures show up in challenges
|
Challenge method |
Contact data it depends on |
Stale data |
Taken-over data |
|
SMS one-time passcode |
Mobile number |
Code goes to an old number; genuine cardholder abandons |
Code goes to a SIM the fraudster controls |
|
Email one-time passcode |
Email address |
Code goes to an abandoned inbox |
Code goes to a compromised inbox |
|
Banking-app approval (out of band) |
Registered device and app |
Push goes to a replaced or reset phone |
Approval requested on a device the fraudster enrolled |
|
Passkey or biometric |
Registered credential on a device |
Credential lost with the old device |
Credential enrolled by a fraudster after account takeover |
Stale data shows up as abandoned challenges and complaints. Taken-over data is quieter: the challenge succeeds, and the issuer only learns otherwise when the fraud report arrives. What happens when the app cannot open covers the app-specific failure modes.
Why number takeover matters for SMS challenges
A fraudster who moves a cardholder’s mobile number to their own SIM receives every SMS passcode the issuer sends. Australia has tightened telecommunications rules against this. The ACMA’s pre-porting identity verification standard, made in 2020, requires additional identity verification before a mobile number is ported to another provider. A later determination extended multi-factor identity checks to high-risk customer transactions such as SIM swaps, after the ACMA found that SIM swaps had become the main route for mobile number fraud.
These rules reduce the risk; they do not remove it. For issuers, a recently changed number or SIM is still a signal worth acting on, and our article on regulators retiring SMS OTPs explains why many markets are moving away from SMS for this reason.
Keeping cardholder contact data fit for authentication
- Require step-up verification for any change to a phone number, email address or registered device, and notify the previous contact point when it happens.
- Treat a recent contact-detail change as a risk input to the ACS, so a challenge sent shortly after a change is assessed with that in mind.
- Track OTP delivery failures and bounced emails by cardholder, and prompt cardholders to update details before they are needed in a challenge.
- Remove devices from out-of-band registration when a cardholder replaces a phone or reinstalls the app on another device.
- Offer at least one fallback method, so a cardholder with stale data on one channel is not locked out of online payments.
- Review challenge completion by method and by length of time since the last contact-detail change.
Device binding gives the ACS a stronger anchor than a phone number alone (device binding and ACS risk assessment), and how an ACS picks a challenge method explains where fallbacks are configured.
Frequently asked questions
Why do OTP challenges fail for genuine cardholders?
Often because the code goes to an old number or inbox. The cardholder never receives it and abandons the payment.
How does a SIM swap affect 3D Secure?
If a fraudster moves the cardholder’s number to their own SIM, they receive SMS passcodes and can complete challenges. That is why recent SIM or number changes are worth treating as risk signals.
What should an issuer do when a cardholder changes their phone number?
Verify the change with step-up authentication, notify the previous number or email, and treat challenges sent soon after the change with extra care.
Is cardholder contact data the issuer’s or the merchant’s responsibility?
The issuer’s. Challenges are delivered by the issuer’s ACS using the contact data the issuer holds. Merchants send their own customer data in the authentication request, which helps the issuer’s risk assessment but does not change where challenges are sent.
Do passkeys remove the contact data problem?
They reduce it, because a passkey is bound to a device rather than a phone number. Device registrations still need to be kept current when cardholders replace phones.
Strengthening issuing-side challenges
GPayments’ ActiveAccess is an Access Control Server for issuers and issuer processors. To discuss how challenge methods and cardholder contact data work together in your programme, contact GPayments.