The latest PSD2 directive includes SCA exemptions which are available in the 3D Secure v 2.2 upgrade. Exemptions enable cardholders to process particular types of online transactions without the need for an additional authentication step. The initial introduction of Strong Customer Authentication (SCA) requirement was turning heads. Merchants and issuers feared that added friction caused by demanding the cardholder to authenticate using two out of three security elements; knowledge, possession, inherence; would cause friction, ending up with a spike in cart abandonment rates. PSD2 approached this issue by defining particular types of online payments which do not require SCA, i.e., SCA exemptions.
In 2020 nearly a quarter of the world population shopped online. To be exact, 2.05 billion consumers purchased at least one item online and contributed to the overall eCommerce growth. Let's put things into perspective; this means that roughly every fourth person you see passing by has purchased at least one item online in 2020. Cardholders are active participants of the eCommerce ecosystem. They have high standards when it comes to their online shopping experience.
The main motivator behind such a shift in customer behaviour is convenience. Purchasing online provides them with a broad offering, as well as the alternatives, backed up with easy access to information about the product/service. But what happens when there is a hiccup during the checkout process? It is naive to assume that the cardholder goes through a lengthy trial-and-repeat process. They simply move on to the next best thing. What follows is a missed opportunity for sale, cart abandonment rates soar, and customer loyalty is at stake.
A Baymard research states that too long/complicated checkout process is within the top five reasons why customers abandon their purchase and do their business elsewhere. 18% out of the 4329 survey participants expressed their reason for abandoning a purchase to be an issue during the checkout process. That means nearly 780 missed opportunities for a pinned sale; 780 customers lost during the last stage of the buyer's journey.
Until recently, eCommerce merchants had little to no influence on how the checkout experience would look like from the cardholder's perspective. They had to rely on UX designed by the cardholder's issuing bank, which often involved numerous pop-up screens and redirects. Although friction generally means more security, it raises alarm bells in customers' heads or simply annoys the end user.
By implementing the latest 3D Secure technology, including features such as Strong Customer Authentication (SCA) exemptions, cardholders enjoy a smooth checkout experience that is straightforward and demands only the necessary amount of friction, if any.
A part of the latest PSD2 directive are SCA exemptions, online transactions that do not demand an additional authentication step because they meet the predefined criteria. Being aware of the cardholders' low tolerance for friction, PSD2 introduced SCA exemptions in order to relieve merchants and issuers from having to demand SCA for each and every online transaction made. By defining such exemptions, the end-users encounter a checkout experience that is genuinely frictionless.
In order to enable the above-mentioned exemptions, a certain type of data-driven evaluation is necessary. Each exemption type demands an individual risk assessment approach, and therefore, particular data is necessary to evaluate if a transaction meets any of the exemption criteria. This demands a cautious setup of the parameters, regardless if the risk scoring engine is rule-based or relies on machine learning.
Enhanced data collection enabled by the new 3D Secure 2 protocol allows the issuer to conduct a more precise risk analysis. Fraud monitoring is necessary on both exempted and SCA-required transactions. Also, in case of merchant whitelisting, risk scoring is necessary on both the transaction risk level as well as the merchant risk level. Real-time fraud monitoring enhances the level of security and does not impact the execution of the transaction. In cases where criteria for exempted transactions are met, the cardholder will place their order instantly. However, if the transaction is flagged, an alternative authentication flow will be applied in order to prevent a possible fraudulent activity.
Although PSD2 puts pressure on merchants and issuers to apply 2FA in the form of Strong customer authentication; SCA exemptions are a convenient way of avoiding additional authentication. If the setup of the parameters is correct, honest cardholders will enjoy a fully frictionless experience. By implementing 3D Secure 2 technology, issuers and merchants are granting flexible and straightforward online payment authentication to their customers.
The latest PSD2 directive enforced Strong Customer Authentication (SCA) as an additional layer of security for online payment processing. To fight fraud, cardholders need to confirm their identity using two-factor authentication (2FA). This includes authenticating themselves using two out of three security elements:
This approach was not welcomed by issuers and merchants, raising concerns regarding the overall traffic impacted by the added authentication step. In the cardholder's eyes, SCA means more friction, and more friction is an inconvenience for the end-user. In order to address this issue, PSD2 also includes SCA exemptions.
SCA exempted scenarios include transactions that do not require an additional authentication step in order to process the payment. It is a clever concept for mitigating friction when applicable. The given transaction must meet specific criteria regarding the risk level and some predefined types of transactions to be classified as an exemption. SCA exemptions are the following:
Merchant Whitelisting, also known as Trusted Beneficiaries, enables cardholders to choose known merchants whom they trust in order to skip the additional authentication step and enjoy a genuinely frictionless online payment experience. Regardless of the transaction amount or merchant/issuer fraud rate, SCA is not necessary. Of course, not all merchants are eligible for whitelisting. The selection of merchants that a cardholder is able to whitelist is under the issuing bank's control. Based on preselected criteria regarding the industry type of the merchant, level of risk, and cardholder's transaction history, the issuer proposes a list of merchants eligible for whitelisting based on the cardholder's request.
The process of whitelisting a merchant is done through transaction authentication. The cardholder who is about to make an online purchase can enroll the merchant to their whitelist. This is done through the authentication interface that contains a checkbox indicating the possibility of whitelisting a particular merchant. By checking the box and applying SCA for the given transaction, both transaction and whitelisting verification are successful and PSD2 & RTS compliant.
This means that every future purchase made by the cardholder won't require SCA, i.e., unless the cardholder decides to remove the merchant from the whitelist at some point.
The cardholder is the one in control of the whitelisting. Merchants have no information if they are either whitelisted or removed from the whitelist by the cardholder. Also, merchants can't apply themselves for whitelisting evaluation on the issuer side. Based on the cardholder's proposal for a particular merchant to be whitelisted, the issuer conducts further risk evaluation and either approves or denies merchant inclusion on the eligible merchant list.
Regardless of the fact that the merchant is previously whitelisted by the cardholder, each transaction is sent for authentication. This happens because merchants have no idea if they are whitelisted by the cardholder or not. In case that the merchant was previously successfully enrolled on the cardholders whitelist, and this was verified with the initial SCA necessary for MWL enrollment, ACS skips risk analysis and processes a frictionless transaction.
According to Mastercard liability rules are the following:
'' The liability shift applies to 3DS independently of the program protocol version (3DS 1.0 or EMV 3DS). If the Merchant does not support 3DS or uses Data Only (refer to section Acquirer SCA Exemptions), liability in case of fraud is with the Acquirer/Merchant. In all other cases, the Issuer is liable if no Acquirer PSD2 SCA exemption applies or if the Issuer has delegated SCA to the Merchant. If the Merchant applies an Acquirer exemption through 3DS and the Issuer accepts it, then the Merchant is liable. If the Issuer goes through SCA without accepting an Acquirer exemption, the Issuer is liable.''
Initial 3D Secure liability shift states that for transactions that are authenticated using 3D Secure, liability shifts to the issuer. The same goes for MWL transactions. Since the issuer deemed a merchant eligible for merchant whitelisting, for any transaction that proves to be a fraudulent one, liability stays on the issuer side.
3D Secure v2.2. brings a number of new features aiming to make the solution even more flexible. By introducing SCA exemptions (Merchant Whitelisting being one of them), issuers and merchants get a sense of relief regarding SCA requirement for two-factor authentication. Enhanced risk analysis enabled the application of SCA exemptions such as low-value payments (LVP) and merchant whitelisting (MWL). This results in a more user-friendly experience and makes the authentication process straightforward. A more detailed summary of EMV 3DS2 features is available in our recent blog post.
Selling online means that a part of your business will also be chargeback disputes. Chargebacks are a way of customer protection that guarantees a return of funds in particular scenarios. Common reasons for incoming chargeback disputes include fraudulent transactions, item not received, processing issues, etc. Resolving a chargeback dispute can be quite daunting for the merchant since it involves various parties. Participants involved in a single chargeback include the cardholder, card scheme, issuing bank, merchant, acquiring bank, and a payment gateway. You can see how things are likely to become tricky at some point.
Although chargebacks traditionally favor the cardholder, since banks want to protect their clients, not all is lost. There are particular cases, which need to be carefully detected, that are worth fighting for. The chances are, you are not going to win each and every time, but orders for which you have strong proof of the cardholder placing an order and receiving the item/service are a good reason to start fighting. Let's review the most common merchant mistakes when it comes to tackling chargebacks.
Attempting to overturn every chargeback dispute would be naive and a waste of your time. On the other hand, missing out on the opportunity to keep your funds based on strong evidence where there is no merchant error will cause serious losses. According to Chargeback Gurus, Issuing banks report that 17% of chargebacks are actually friendly fraud, while merchants state that the number is closer to 32%. That's a pretty good reason to start fighting back. Set up clear rules based on which you will be able to identify which chargeback disputes are worth fighting for. Prepare all necessary evidence starting with the customer placing and receiving an order. Arm yourself with details that prove no merchant error was involved, and you can approach the dispute with high hopes of coming out victorious.
Make sure your team is up-to-date with the latest reason codes for chargebacks. Every chargeback comes with a reason code. A reason code tells you what type of chargeback you're dealing with, why did the cardholder file a chargeback, and lists necessary evidence needed to overturn the chargeback. Card schemes publish their resolution protocols along with reason codes in order to enable merchants to better understand the issue(s) that occurred and how to act accordingly in the upcoming dispute process. A comprehensive guide on reason codes by Chargeback Gurus gives an updated overview of reason codes by the card scheme.
Your goals are ultimately the same, so why not join forces with your card processor? They have far more experience dealing with chargebacks and provide more insight into how to approach a certain case. Card processors have the necessary knowledge to overturn a chargeback, as well as important information about resources and tools used for fighting them.
Chargeback rates higher than 1% indicate fraudulent activities happening on your site, e.g., ATO Fraud. This is followed by issuing banks flagging you as a high-risk merchant. Another important metric that gives you information about the next steps is your win/loss rate. A low rate suggests that you are ineffective in fighting chargebacks and should consider changes in your approach, whether it be resources or the team in charge.
Customers file chargebacks for a number of reasons. There are scenarios where the main cause of a chargeback is simply confusion caused by poor communication. To reduce the number of chargebacks, make sure that the customer recognizes the transaction in their statement, is not mislead by the product description, and understands the process following a placed order. By doing so, you are decreasing the chances of a chargeback dispute and having more time to focus on your core business.
Make sure you have a database containing all the steps of an order, from order placement to a signed slip after delivery. Having all the evidence organized in one place makes it easier for you and your team to prove that everything is ''by the book'' on your end. This enables you to act promptly in case of a chargeback and showcase all of the details necessary to avoid a chargeback.
Invest time in developing a chargeback flow. Clearly state all of the steps needed for approaching a case, from detecting a possible chargeback win to actually overturning a chargeback dispute. You are empowering your team with a systematic approach in order to be more efficient and keep them on track.
Investing in a fraud prevention solution enables you to devote your time to your core business, relieves your chargeback team from manual analysis, and, most importantly, protects your business and your customers. After all, prevention is the best cure. Take your time to research a solution that is best suited for your business. Stop chargebacks before they even happen.
There is no doubt that disputing a chargeback is a complex, time-consuming process that might not end up as a success. However, if you decide not to fight at all, your revenue, as well as reputation, might suffer. Before giving up, take the time to develop a chargeback flow and avoid the above-mentioned practices. Make sure that you communicate with your customers through every stage of the order and gather compelling evidence. React promptly. The results might be very rewarding.
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.
Account Takeover Fraud (ATO) happens when a fraudster gets a hold of the victim's login credentials and uses the account for their own gains. That includes activities such as making online purchases using the stolen account and saved card data, using loyalty credits, selling the account or the extracted data on the dark web, etc.
A typical ATO attack works as follows:
What makes ATO fraud more dangerous than card-not-present fraud is the fact that with a single combination of credentials (e.g., username and password), the fraudster is able to access multiple accounts. The truth is, we are terrible with passwords. We constantly reuse them and make a low effort regarding our online security. Take a look at some interesting stats pointed out in a recent article by DataProt:
The list goes on. This gives us a clear picture of how irresponsibly we behave when it comes to our online presence security. The username and the password have little to no value. But the information behind those credentials is what piques the fraudster's interest.
There are a few different methods fraudsters use in order to get a hold of the user's credentials. More sophisticated methods such as phishing and malware are used to obtain more valuable credentials. It enables the fraudster to take over a victim's bank account, for instance. Other methods use credential stuffing and brute force attacks in order to obtain an account and target eCommerce accounts.
A phishing scam consists of sending a link via email, text message, or even social media containing malware that collects the victim's credentials. This method usually uses well-established website interfaces that the users trust. And while the interface seems familiar and legitimate, there is a fraudster in the background that is harvesting your credentials and accessing your account in order to use it to their own advantage.
Another known method for conducting ATO attacks is purchasing stolen credentials of the dark web in bulk. This information is usually published after a data breach and damages both users and businesses. The most valuable information published after a data breach consists of emails and their corresponding passwords.
For how many accounts do you use your email address and the same password? Think about it. By using automated scripts and bots, the fraudster is able to quickly scan through a multitude of account-based websites. They collect further information such as saved credit card numbers, social security numbers, etc. To see whether your email or phone number is a part of a data breach, check out haveibeenpwned.com.
Malware, or ''malicious software'', is software specifically designed to cause harm and damage in order to gain unauthorized access. By downloading content from sketchy sites, you are at risk of unknowingly installing malware to your device. That malware is able to track everything the user types. Now the fraudster just needs to be patient and wait for you to enter your credentials.
A man-in-the-middle attack is based on intercepting a message and altering it to the fraudster's advantage. By using malware, the fraudster is able to intercept, edit, and resend an altered message sent between the victim's device and the bank's server.
The consequences of an ATO attack affect both businesses and customers. The fact that the fraudster used legitimate credentials in order to log in to an account makes it that much harder to detect whether it is an unauthorized person behind the username. The fraudsters are getting better and better at mimicking the ''usual'' user behaviour by carefully choosing the amount to be spent, time of login, time of order, and other details visible in the account history.
By the time the rightful owner of the account notices any strange activity, they are probably already locked out of their account because the fraudster rushed to change the vital account recovery details as soon as they gained control of the account. Even if victims manage to retrieve their accounts, their personal information is most probably already compromised.
When talking about businesses whose customers' are victims of an account takeover attack, we need to mention great financial and reputational losses. The financial loss is due to incoming chargeback costs accompanied by inventory costs. The data breach itself ruins the company's reputation with clients, while higher chargeback rates cause problems with issuers and card schemes. Customers lose trust in such businesses and tend to turn to the competition, which means that customer loyalty is also at stake. The overall reputation of the business suffers, and the options for damage-control are scarce when overturning such an unfortunate course of events.
A report from Sift on Digital Trust & Safety Index reveals how ATO fraud progressed and caused losses amounting up to $16.9 billion in 2019. The pandemic-ridden year boosted eCommerce, and users turned to shop online. The increased online presence meant prolific ground for fraudsters to operate on. The report states that ATO attacks surged by 282% between Q2 2019 and Q2 2020.
The impact on businesses is detrimental. Customers who are victims of an ATO attack describe their behaviour and next steps. 40% of users continued using the site but decided to change their credentials. 20% of users continued using the service and contacted the support team in order to solve the issue. Nearly one-third of surveyed customers stated that they abandoned the site where an attack took place and turned to a direct competitor. But losing 28% of your customers is not the only issue. If you consider the average customer's lifetime value and customer acquisition costs, the cost of an ATO attack grows even higher.
The research also reveals that the fraudsters are getting better and more efficient with their time. The period between Q2 2019 and Q2 2020 recorded thought-out waves of ATO fraud. This means that the fraudsters are now using automation and bots. This way they take over as many accounts as possible while burying security teams with alerts and stressed-out customers.
Static passwords proved to be insufficient regarding online payment security. In order to heighten the security measures, implementing MFA (multi-factor authentication) enables your customers to protect their accounts using authentication methods such as biometrics (fingerprint, face-scan). Even if the fraudster gets a hold of the cardholder's pin or password, multi-factor authentication involving biometrics makes it hard, if not impossible, for the perpetrator to fake a fingerprint scan in order to process a fraudulent payment. Strong Customer Authentication (SCA) enabled through 3D Secure 2 solves this issue and provides both security and convenience to the end-user.
The next line of defense is the continuous monitoring of account activity supported by machine learning. ATO fraud requires detection in the earliest stages of the fraud lifecycle. To detect any anomalies in user behaviour, monitoring is a necessity that needs to be present from the moment a user starts their banking session. By tracking customer behaviour and how they interact with the device , monitoring allows the detection of ''normal'' customer behaviour. If monitoring identifies that customer behaviour has certain anomalies and deviations in regard to the ''normal'' behaviour, this might indicate an ATO attack.
Another means of prevention is Dynamic Linking required by the latest PSD2 directive. Dynamic Linking is successful at preventing social engineering attacks because it links each transaction to its amount and its recipient. The authentication code generated for a particular transaction is generated based on the transaction amount, account number, and other predefined details about the transaction. This means that in case of altering any transaction data during the interception (e.g., man-in-the-middle attack), the authentication code will change as well, and the authorization would be unsuccessful.
Fraud prevention in real-time is essential. Determining if requesting a change of email, or phone number is a possible ATO attack is a challenge. The above-mentioned techniques, accompanied by real-time fraud detection, allow for a better risk assessment. It provides a higher level of security, protecting your business and your customers.
SMS one-time-password (OTP) is a well-known, simple form of authentication. It enables users to authenticate themselves with a dynamic code from an SMS message. Often used for 2FA (two-factor authentication), SMS OTP is commonly used as a second factor necessary for gaining access to a particular network or service, usually combined with a static PIN/password. Although two passwords are better than one, SMS OTP is not the most reliable method for verifying identity. That is due to an array of risks revolving around the method. Some of them include SIM swapping, SIM hacking, intercepting the message, account takeover, etc.
Until recently, SMS OTP was one of the most convenient ways of authenticating an online transaction or logging into a payment account. The user would simply enter the received OTP into their payment application and approve the transaction. In such cases, SMS OTP commonly contains additional information regarding the transaction, including the transaction amount and the payment beneficiary. To conduct 2FA, banks and payment service providers combine static PINs and SMS OTP, PIN being a knowledge element, and SMS OTP representing a possession factor.
The second payment services directive (PSD2) enforces Strong Customer Authentication, demanding online payment authentication using two out of three security elements. Those elements include Knowledge, Possession, and Inherence. By definition, SMS OTP, which is a possession element, in combination with a static PIN/password, is an acceptable authentication method conforming to the PSD2 SCA requirement. SMS OTP alone is not a possession element. The SIM card associated with the respective mobile number represents possession.
For a device to be considered as possession, there needs to be a reliable means to confirm possession through the generation or receipt of a dynamic validation element on the device.
In this context, a one-time password sent via SMS would constitute a possession element and should therefore comply with the requirements under Article 7 of the Delegated Regulation, provided that its use is ‘subject to measures designed to prevent replication of the elements’, as required under Article 7(2) of this Delegated Regulation. The possession element would not be the SMS itself, but rather, typically, the SIM-card associated with the respective mobile number.
To conclude, SMS OTP is PSD2 compliant when combined with a static PIN/password or another authentication method. This method needs to include either knowledge or an inherence security element.
However, SMS OTP is subject to a variety of security concerns. A considerable amount of risk revolves around using SMS as a channel. This is primarily due to possible interception of the message and man-in-the-middle attacks. Further on, SIM swaps performed to receive the message originally sent to the victim, containing OTP, present a threat. Being a well-known authentication method, fraudsters have more than enough knowledge necessary to crack the system.
Although SMS OTP is PSD2 SCA compliant, EBA's opinion on the matter is a bit more complex. Another component introduced by PSD2 raised questions about SMS OTP compliance, that being Dynamic Linking.
Dynamic linking aims to specifically link each transaction to its amount and the recipient of the payment. The end goal is to prevent man-in-the-middle and similar attacks. Dynamic linking connects the transaction amount or order details to the authentication code and sends it to the user. If any of the information is altered, a new authentication code will be generated, and the fraudulent attempt would fail. One of the requirements of Dynamic Linking states that the payment information must be protected.
In addition, regardless of whether a strong customer authentication element is possession, knowledge or inherence, Article 22(1) of the Delegated Regulation requires that “payment service providers shall ensure the confidentiality and integrity of the personalised security credentials of the payment service user, including authentication codes, during all phases of the authentication” and Article 22(4) of the Delegated Regulation states that “payment service providers shall ensure that the processing and routing of personalised security credentials and of the authentication codes generated in accordance with Chapter II take place in secure environments in accordance with strong and widely recognised industry standards”.
We are talking about an SS7 - telephony signaling protocol, which is not secure. Any information regarding the transaction amount or the order details in the SMS has to be encrypted. The decryption of the content would require significant effort on the user side, cause confusion, and create friction. The conclusion drawn from EBA's opinion the following; SMS OTP for Dynamic Linking is not PSD2 compliant unless the content of the message is not protected with additional encryption or sent through a secure channel.
Although it is among the top authentication methods, use it with caution. Consider it as an alternative authentication method rather than a standard one. Enabling SMS OTP as a fallback method is a good practice; if all else fails, you can rely on SMS OTP. Another tip is to consider delivering OTP through a more secure channel. Most banks have their own mobile applications which use secure TLS/HTTPS protocols to communicate with the server. Also, if the population is less tech-savvy, i.e., the older population which is not familiar with smartphones, they will appreciate the option to use SMS OTP as one of their primary methods of authentication.
As stated by the official summary of the PDS2 directive, the main goal of the regulation is to provide a legal foundation for the further development of electronic payments within the EU. It is a comprehensive set of rules aiming to make payments within the EU simple, efficient, and secure. Motivated by offering a broader set of choices and better prices for consumers, PSD2 advocates opening up payment markets to new participants, to create more competition, leading to greater efficiency and strengthening consumer's trust.
The directive strives to enhance the existing set of EU rules regarding electronic payments. It emphasizes innovative and emerging payment services, such as internet and mobile payments. Rules stated in the directive concern security requirements, i.e., safeguarding consumer's financial data, promising secure authentication, and reduction of online payment fraud rates. Transparency is another key point that PSD2 advocates in order to provide accurate and timely information about requirements regarding the payments services. PSD2 establishes the rights and obligations of participants involved in the online payment environment. The users, as well as providers of payment services.
Several notable suggestions regarding leveling the payments playing field are pointed out, and those are the following:
The first payment services directive dates from 2007. While it set out good practices and regulated guidance on rules regarding payment services, as of today, it is obsolete. With the rapid evolution of ''all things digital'', new e-commerce trends, authentication methods, and the overall innovative approach to payment markets, PSD was outdated and needed an upgrade. Now that we had a brief history lesson let's get back to our main topic.
With new regulation came new terminology, and below are the ones concerning PSD2:
AISPs (Account Information Service Providers) – Providers that can ask for permission to connect to a bank account using an API. They use that bank account information in order to provide a service. Having access to such data implies a ''read-only'' approach, i.e., they can't move the fund from the account.
ASPSPs (Account Servicing Payment Service Providers) – A customer's issuing bank that provides and maintains payment accounts. They publish APIs so that the customers are able to share their account data with TPPs in case they want them to initiate payments on their behalf.
PISPs (Payment Initiation Service Providers) – Authorised PISPs are able to move funds on the customer's behalf upon connecting to the bank account. An example of a practical use case is the automatic transfer of funds to a customer's savings account.
TPPs (Third-Party Providers) – Third-Party Providers are either/both Payment Initiation Service Providers (PISPs) and/or Account Information Service Providers (AISPs).
PSUs (Payment Service Users) – Users of any of the above mentioned service providers.
PSD couldn't foresee trends in the payment industry ten years in advance, and that is why PSD2 steps in. It brings a fresh set of rules in an effort to enable modern, innovative payment services to users. PSD2 provides them with the highest level of security in terms of online payment fraud, which is constantly present. A comprehensive list of the most important payment threats published by the Europen Payments Council makes you think twice before entering your card data to process an online payment, and it should. Take a look.
The 2019 Payment Threats and Fraud Trends Report provides an overview of the most important threats in the payments landscape, including:
In order to combat fraud, PSD2 introduced Strong Customer Authentication (SCA). PSD2's weapon of choice protects customers by demanding them to authenticate with two out of three authentication elements, namely:
Initially, this put pressure on issuers and merchants. They were wary of the effects it will have on the overall traffic. The added authentication steps could potentially drive away the customer from their purchase. But there is a cure for this disease, and it comes in the form of SCA exemptions within the scope of the SCA mandate.
SCA exemptions include various scenarios where SCA is not necessary. The customer is not asked for an additional authentication step during the processing of a payment. SCA exemptions are the following:
There are other scenarios that are out of the scope of the SCA requirement but are not classified as SCA exemptions.
3D Secure is a protocol that enables Strong Customer Authentication and protects online payments by adding an additional layer of security. It is the main determinant for PSD2 compliance and enables both payment service providers and merchants to achieve alignment. You can get more insight on the latest version of the 3D Secure protocol in our blog post.
If you're a merchant or a PSP, main question of the day is: Am I PSD2 compliant? If not, how do i become PSD2 compliant?
Merchants need to decide between two options. One option suggests that they pick a PSD2 compliant PSP. This relieves them from all the administrative aspects of compliance and enables them to focus on their primary business. The second option advises merchants to integrate authentication into their checkout process. This requires more effort financially but enables them to be PSD2 compliant and in charge of the customer's checkout experience.
If you're an issuing ar an account-holding institution, you want to follow the following steps: create APIs in order to enable transactional payment data access, provide access to accounts to TPPs, make sure you have a Consumer Identity and Access Management solution set up in place, and finally implement the network and API security infrastructure.
Lastly, Third-Party Providers must take care of their PISP or AISP license. They need to establish a trust framework with banks and financial institutions. Next, they need to develop secure apps including user consent and fraud monitoring. Lastly, TPPs need to implement a consumer IAM solution.
Although PSD2 is causing a stir in the online payments industry by demanding fast onboarding and regulatory compliance, it brings an array of new opportunities for new players in the payments environment. Increased competition most definitely increases efficiency and boosts customer trust. By introducing innovative approaches in regards to online payment security, it reduces payment card fraud, as well as opens doors for further improvement in the risk assessment department enabled by extensive data sharing. Even though PSD2 enforces strict rules and binds the participants to comply, it is done in an effort to assure more quality services that do not compromise on security.
False declines are legitimate transaction attempts that are declined because of suspected fraud. They are the so-called ''false positives'', fully valid transactions classified as invalid, and rejected by the Access Control Server (ACS).
Picture this - you're about to purchase something online, let's say a new smartwatch. You spend some time researching all of the functionalities. You find the best deals offered to you from various merchants. That's it! After hours, maybe even days of researching online, you are finally ready to make a purchase. You enter all of the required details necessary to finalize your purchase, and – your order declines. Frustrating would be an understatement for this situation.
Now let's examine the next steps. The cardholder will most likely turn to the competition or use a different credit card in order to process their order successfully. Either way, there will be a loser at the end of this story. The cardholder will keep this unpleasant situation in their mind. The chances of them using the same declined credit card or returning to the ''problematic'' merchant are slim to none.
And there it is; a missed sale, reduced revenue, and an unhappy customer - the three horsemen of false declines.
The occurrence of false declines is closely connected to the anti-fraud solution used by the merchant, issuer, or acquirer. The cardholder is usually presented with a generic message such as ''transaction refused''. This offers no additional information that explains the decline or guides the cardholder to take the next step.
Common reasons for false declines involve the following:
Also, anti-fraud solutions based on behavioral analysis might classify a transaction as fraudulent, while it is, in fact, a valid one. Let's say that the cardholder has a pattern of purchasing low-value items online, not more than 10 EUR per transaction. All of a sudden, that same cardholder decides to book an all-inclusive trip online. Regardless of sufficient funds and correct card information during checkout, the transaction might be blocked because the pattern is unusual, and the system flags it as suspicious or fraudulent activity.
There is a fine line when it comes to configuring the ACS solution in order to identify suspicious transactions correctly. False negatives represent transactions that are fraudulent but are valid according to the system. On the other hand, we have false positives, which represent valid, honest transactions that end up as false ones. Configure the system ''too loosely'', you're going to end up with false negatives. Set it up ''too strictly'', you are risking a high number of false positives, i.e., false declines.
If we examine the end impact of fraudulent transactions, we need to keep in mind that the loss is not equal to the amount of the processed fraudulent transaction. It can be anywhere from 100% (gold) to 0% (digital goods) of the amount displayed in the web store. If we take sneakers as an example, the total cost of loss will be equal to the manufacturing cost. It is usually as low as 5% of the displayed price.
When talking about false declines, the end impact is much more significant. After receiving a notification about an invalid transaction, the cardholder doesn't have any guidance on the next steps. They will most likely use a different credit card or look for the same product/service in the neighbor's yard, the competition. Either way, they are leaving with an unpleasant experience with the overall service, and it is not likely that they will use the same rejected credit card or revisit the same merchant.
Riskified surveyed 5000 US-based consumers in order to find out more about their online shopping experiences and fraud. Regarding our topic, the survey discovers that almost one third of shoppers in every segment are wrongfully rejected during a purchase, resulting in a false decline. After being rejected, 42% of shoppers abandon their cart immediately and move on to the next best thing. If we look at the big picture, that means that all acquisition costs and efforts went through the window because of a ''single'' false decline.
False positives are extremely expensive. The Global Fraud Survey published by the Merchant Risk Council states that the average online store rejects 2.6% of all transactions under the claim they might be fraudulent. The pricing pattern says that the higher the price, the higher the percentage of declines (e.g., merchants decline around 3.1% of orders over 100$).
3D Secure 2 enables issuers to access ten times more transaction data than before, which results in more precise risk analysis and profile creation of the cardholder. The end result? Less false declines, among other benefits, of course. Both merchants and issuers are able to increase profits and keep their customers satisfied and returning to use their service.