3D Secure is an example of such a solution. The overall 3D Secure environment consists of at least four components (ACS, Directory server, 3DS server, Payment Gateway). This number amounts up to seven components if Authentication and Risk Scoring services are separate from the ACS. By introducing a core banking system integrated with ACS, the complexity of the solution becomes relatively high. Things get even messier when In-app purchase and mobile SDK are involved.
Luckily, 3D Secure software components need to be tested and approved by the 3DS protocol owner; i.e., EMVCo, but also by card schemes when deployed at the issuer and acquirer side. Still, even upon certification, after implementation and integration testing, it is common that certain issues occur.
From our experience, one of the main challenges when it comes to successfully testing the 3DS solution is covering all the possible scenarios to confirm the functionality of the solution. By introducing new features, the configuration needs to be aligned with various protocols and regulations. Not to mention the specific client change requests that open more possibilities for errors. Additional issues occur by providing more flexibility in message and data formats. In the two examples below, we describe two problematic scenarios which you can face and where production issues occurred.
Problems might happen with rejected transactions identified after the solution has been deployed in production. In some cases, a missing element in the challenge response sent by the authentication service of a specific bank is identified. This message is generated by a proprietary authentication interface module that is adapted to the issuing bank.
Such test case is covered in the EMVCo certification regression testing. It is a part of the ACS2 upgrade to 3DS v2.2. The test passed the EMVCo certification, although each bank has the possibility to configure the text contained in the module. During the EMVCo certification testing, a dummy authentication module was used, which sent sufficient data to pass the test. But the bank had its own customized authentication module containing text that they defined by themselves. This was not tested with mobile devices as a part of an internal regression testing on the test environment. The result? The issue was overlooked during the testing phase and was spotted only when it was already in production.
Another issue causing transactions to be rejected by issuing or acquiring domain (ACS or 3DSS) is due to the incorrect or unexpected values in the message flow.
3D Secure environment and stakeholders are aligning these days. Card schemes issue 3DS announcements and updates regularly. Newly introduced values that were not updated correctly or not supported at all on one domain might create unexpected behavior of the other domain. This is common for flows that do not pass through the card scheme directory server, such as the challenge flow.
In order to ensure such a robust solution for any of the domains (ACS, 3DS Server), the testing process should involve behavioral analysis in case of such unregulated boundary scenarios, as soon as the card scheme announces new fields.
Even proper adoption of newly introduced values might cause issues for non-robust 3DS solutions because other parties might introduce them prior to you.
3D Secure service providers continuously work with testing environments in order to conduct SW update testing, interoperability testing, testing new business processes, user experience flows, etc. For each of those cases, one or more components are changed in the configuration matter, or the SW upgrade matter and impact the overall process and the environment.
The best way of testing the 3DS environment includes independent testing of each 3DS component first. However, the end-to-end testing should be done prior to migrating the upgrade to production.
End-to-end testing poses a particular challenge as use cases and test cases exponentially rise with new and proprietary business processes. Such test cases should be defined in detail and configured in test tools, which also need to be upgraded in order to support certain test cases.
Banks or 3D Secure service providers usually use commercially available test tools for testing separate 3DS components. However, when it comes to end-to-end testing, they typically develop their own solutions and test environments. Having separate testing solutions in play requires additional (re)configuration when moving from single application testing to environment testing. This demands additional effort and opens new chances for error in (re)configuration.
When it comes to 3D Secure, that means that the test solution needs to be able to simulate other components aside from the device under testing. Let’s put it this way; when ACS is being tested, the test tool simulates both 3DS server, Directory server, and sometimes even Payment gateway. For end-to-end testing, simulators are replaced by configuring other 3DS components, URLs, and necessary keys, as well as other parameters. All of those parameters are stored in the so-called testing profiles for fast switching between testing modules.
In conclusion, test solutions should be easily applied for testing single 3DS components, as well as easily configured for environment testing, end-to-end testing, and UX testing. Such a solution will reduce costs in 3DS regular maintenance and upgrades, as well as minimize possibilities for errors.
Account Takeover Fraud (ATO) is happening when a fraudster uses somebody else's credentials in order to gain unauthorized access to an account and uses it to their own advantage. The fraudster monetizes the account by either transferring funds, making unauthorized purchases, or selling the account data elsewhere. The main problem of this particular type of fraud is that the credentials used for taking over one account are usually used to access multiple other accounts and cause that much more damage. This makes it distinct from card-not-present fraud, where only one relationship is endangered. A more detailed overview of account takeover fraud is available in our recent blog post.
ATO fraud is an emerging type of fraud targeting customer's accounts with valuable information such as saved credit cards, private information, loyalty points, etc. In this way, the fraudster is able to monetize the account by either stealing the funds or the account data and reselling it on the dark web.
Account takeovers are extremely harmful to the business. Not only do they cause chargebacks and ruin their chargeback rates, but they have a detrimental effect on the company's reputation and customer loyalty.
Even though we are dealing with a type of fraud that is incredibly hard to detect, we gathered best practices regarding ATO fraud detection. Watch out for these telltale signs of an ATO attack, and protect your business and your customers.
Users and companies who have account-based websites are the prime targets for fraudsters. A common technique of taking over an account is phishing. For instance, the victim receives a legitimate-looking email containing a link leading to a familiar site that requires login. The unsuspecting victim enters their credentials, while the fraudster on the other side of the screen is harvesting their usernames and passwords. Regularly educate both your customers and staff regarding online security threats such as this one. Be proactive about security measures and implement best practices such as regular changes of user passwords and tips on how to protect user credentials.
Fraudsters are no strangers to contacting the call center of a company directly in order to get more information about sensitive data necessary for login. Train your staff to ask questions that are specific, i.e., questions that only a legitimate account holder could know the answers to.
When a fraudster takes over an account, their goal is to keep it. In order to do that, they need to change specific details necessary for the account recovery process, such as email or mobile phone number. If you notice multiple accounts having the same account details listed, e.g., mobile phone number, the chances of fraudulent activity are pretty high.
By observing the account history, you are able to detect certain anomalies in customer behaviour. If a user suddenly spends an amount larger than the usual or places a suspicious number of orders in a short period of time, investigate further and see if any of the account details have been recently changed. If yes, that might indicate an ATO attack.
Another way of protecting your business and your customers is by implementing backend monitoring. Detect fraudulent activity regarding suspicious IP addresses and analyze timestamp data transfers. This enables you to identify whether a fraudster is trying to intercept any communication happening between the site form and the backend of the website.
Sometimes, fraudsters tend to be lazy and they don't mask their device data. They carelessly log in to multiple accounts, and the recorded activity shows the same device number, the fraudster's. Keep an eye on this one, but don't be alarmed too quickly because family members and work colleagues often share the same device. Look for more clues in order to make sure that you are witnessing an ATO attack.
Staying on the same topic, there are also fraudsters who mask their device data by using device spoofing. Usually, if they implement device spoofing, the device details show up as ''unknown''. There is a pattern where the victim's accounts are usually connected to more ''unknown'' devices than legitimate ones where you are able to see the exact device model. Look out for this one!
Following a data breach, multiple user credentials are published/purchased on the dark web. That also means that fraudsters are trying to log in to the user account using that fresh information. Since they can't possibly know the exact location of each customer, they also can't match their IP address country to fit the profile. Observe accounts that have an unusually high number of IP address counties connected to them. It is a sign of an account takeover attack.
As mentioned earlier, a data breach results in a multitude of user credentials ending up on the dark web. When fraudsters get a hold of those credentials, they use credential stuffing in order to quickly check if any of the purchased usernames and passwords actually work. This is done through checking for both technical and behavioural tracking of bot activity.
We mentioned the necessity to track customer behaviour, but if an attacker is behind the observed activity, we are talking about fraudster behaviour. The (un)fortunate course of events is pretty predictable, and it is the following:
Upon taking over an account, fraudsters tend to leave the details untouched for some time. They gained access and will take care of the rest later. But if there is a notification sent to the user, alerting them about suspicious activity, fraudsters end up in panic mode. They rush to change details such as email and password in order to keep the stolen account. Track these changes triggered by a security alert. Password reset requests might soar.
Loyalty points are often overlooked by legitimate users and remain untouched. But one man's trash is another man's treasure. Fraudsters often target accounts solely because of loyalty programs. Stay alert and track if there is any sudden activity involving the use of loyalty points.
With Account takeover attacks, timing is crucial. It is extremely important to stop the attack in the earliest stage of the fraud lifecycle. By continuous monitoring of account history and customer behaviour, it is possible to detect anomalies and extract activities that do not match previous patterns. Mentioned best practices, accompanied by Strong Customer Authentication (SCA) and 3D Secure technology, promise the highest level of security.
EMVCo continues the 3D Secure strategy set with EMV3DS v2.0 – having a strong focus on adopting current trends in e-commerce and online payment, fast and smooth transactions, minimal friction and disturbance for the Payee, great User Experience, and ultimate level of transaction security.
Check out most notable 3DS v2.1 and 3DS v2.2 improvements in our recent blog post.
In 3DS v2.2 there were additional protocol improvements in this direction. These improvements include the following:
Both VISA and MC, have different 3DS 2.2 adoption roadmaps. As one of the main card schemes, VISA has defined a milestone for issuers and acquirers to adapt to EMV3DS 2.2; until the end of Q1 this year (2021). However, Mastercard has not set such a milestone; since MC has adopted some of the features from EMV3DS 2.2 through its MC 2.1+ extensions.
In addition, ASEE provided a comprehensive overview of the extended transition period. Learn more about the efficient management of the extended transition period in our recent blog post.