Challenges of merchant-bank communication and the role of 3DS

Challenges of merchant-bank communication and the role of 3DS

In a recent survey, a staggering 95.8% of the respondent answered positively to the statement “Easy credit card verification between merchants, banks and schemes should be an evident responsibility for all parties”. “Absolutely”, states Tonya Robertson, Direct Sales Manager at South African Airways. “Lets face it - fraud exists because we cannot verify transactions at a bank level”. And that just about covers the frustration most merchants have about our broken payment ecosystem. Why are merchants liable for fraud, if they don’t have the opportunity to verify a transaction with the customer? But also vice versa: how is it possible that goods are being shipped if the bank already knows the purchase was fraudulent? What’s preventing the system to change? In this article, we’ll investigate what current ways there are to enable merchant-bank communication, the powers at play in this political minefield, and what’s to be expected in the short to mid-term future.

Current set-up of payment ecosystem

In the current set-up, merchants are liable for fraud unless the transaction was 3D secured, in which case the issuing bank takes liability. As a shocking 1 to 2% of the transaction attempts are known to be fraudulent, merchants invest heavily in fraud prevention. “Verifying ownership of the card is our biggest issue right now” says Drayton Williams, Investigations Manager at Momentum Travel. The challenge: merchants only have transactional data to analyze if a transaction is genuine or not. They can combine this with historic fraud data, or behavioral analysis, but the big missing piece of the puzzle always remains some sort of identity check. There’d be the option to actually contact the cardholder, or at least the bank. “This would make sense, as the issuers are the ones holding the relevant information. One quick call/email saves a lot of time”, confirms Kerry Ann Pitt, Corporate Security Credit Card Fraud at Virgin Atlantic Airways. 

So, what would the ideal world look like? The merchant would alert the bank to flag suspicious transactions, which would in turn analyze the spending pattern of a customer and decide if the transaction at hand fits in the normal behavior. In case of doubt, the bank would have the option to simply verify with the cardholder if he/she indeed just bought 4 flat screen TV’s. It would be quick and predominantly automated so barely obstructing the payment flow and customer experience. It would be secure, and fair: banks would do what they’re expected to do - guarding our savings. Why isn’t this happening in all cases, one might wonder. Here’s the caveat: the merchant doesn’t know what bank to reach (there’s no official BIN-range directory), and even if they did: how to find the right person and contact details?

Equally important is the communication in the other direction, enabling a bank to alert the merchant when a transaction stands out from normal behavior and handing out the product (shipment for physical or issuing of digital goods) should be held off until the cardholder was contacted. Again, the pickle is in getting in contact with the right person or system at the merchant and on time (which is increasingly challenging now that most goods are being shipped within hours after the purchase was completed). 

Let's take a look at what's used in todays market.*

Available solutions

The most logical way would probably be for merchants to contact the bank directly. Interestingly, there’s only one serious solution for this in the market. FACT is used to report suspicious transactions directly to the right bank, based on the BIN range. The bank receives an e-mail alert containing all details of the case (including tokenized card details) and the option to indicate if the transaction was fraudulent or not. Upon confirmation from the bank, which is within the hour in 55% and within 12 hours in 75% of the cases, the merchant can accept or decline the transaction. The system works the other way around as well: banks can contact the right person at the right merchant to alert on compromised cards or fraudulent transactions. The rapidly expanding application is used by 900 merchants and supported by 6 card schemes in 90 countries, currently still free of charge for all users. 

Another well known system is Ethoca, recently acquired by MasterCard, traditionally focused on preventing the substantial costs associated to chargeback processing. Once the bank has identified a fraudulent transaction (either through their own monitoring, or alerted by the customer), it has the option of contacting the merchant by e-mail to cancel the transaction or settle the dispute between them, avoiding the customer to initiate an official chargeback with all related costs. 

Cardinal Commerce, Chargebacks911 and a small number of other companies operate in the same space, all including a type of cooperation with the issuing bank in some way, enhancing transaction checks in order to increase conversion and decrease chargebacks. 

Powers at play

So although there are a few options for merchants and banks to contact each other, none seem to be exhaustive or scaled to an extent of being an industry standard. Why not? “I still think banks and schemes should have more responsibility, should check more data. Not just the credit card number, expiration and funds. It should check most of the credit card holder's data for authorization, not just above 3 most of the time”, says Anna Stelmach, Senior Financial Specialist Fraud, LOT Polish Airlines. In sum: not just enhanced checks and communication between merchant and bank, but full responsibility to the bank. The three main important factors that obstruct full roll-out:

Data protection

To start off, there’s the data sharing restriction, that severely limits the opportunity for sharing details about a transaction between stakeholders. “We have to be aware of the PCI compliance rules” explains Christelle Brenin, Payment Fraud Manager at Swiss International Airlines. “For example, how to communicate a full credit card number?” Not alone are they not allowed to just share transaction details with the bank, merchants that are not PCI compliant won’t even have access to the full card information, making it nearly impossible to verify the transaction with the bank. 

And in all fairness, although this seems an annoying hurdle in light of this article, it was created for a reason. Because thinking from our private, consumer’s point of view: to what point do we wish our spending detailes to be shared between merchants and banks? As customers, we want them to have enough information to protect us against fraud and assuring the optimal payment experience, while still maintaining our privacy. 

Responsibility

Logically, banks and merchants having been trying to push around the responsibility and therefore liability of verifying transactions. The issue is the divergence of interests: merchants want to sell; banks want to protect. Extrapolating this would result in a 100% acceptance rate for merchants, or a 100% rejection rate for banks, with devastating affect on customer experience. It’s a Mexican standoff: the only way is to maintain the equilibrium until some outside effect changes the system. 

And so the result is that merchants accept as much as they can, until a fraud rate of X% alerts the card scheme that sees its brand compromised by the increasing number of chargebacks, and threatens to penalize the merchant and/or the issuing bank. 

Customer Experience
Just a quick note on customer experience. Yes, we want to make sure our money is safe. But do you really want to be called by the bank all the time to verify transactions? Not only would it significantly delay the purchasing process, it would simply be annoying. And if there is one thing that’s important for merchants, it’s to keep their clients happy by providing them with the best service possible.

Market dynamics and expected changes

Summarizing, both merchant and bank don’t have access to all the information to automate decisions because of privacy regulations, none of the parties could take full responsibility because it would be devastating to the other’s goals, and we as customers are pretty high demanding when it gets to our user experience, blocking application of the full range of safety measures. So what’s to be expected?

PSD2. In the end, EU regulators stepped in to simply obligate all merchants and issuers to enroll in a series of safe payment requirements, including Strong Customer Authentication (SCA). First of all, because 3DS will now be obligatory, merchants won’t have the fear that by enrolling to 3DS, customers will be repelled by the payment experience and go to their competitors. Equal competition, in a way. Secondly, by automating the verification with the customer, in the long haul this decreases the workload on both merchant and bank for all credit card transactions. The process will be quite seamless: we will simply confirm our payment with our fingerprint. How’s that for an alternative for being called by your bank? 

In the end it could just be the solution for our system: have the customer him/herself confirm that the transaction was indeed genuine. Although the theory is good, we have to acknowledge the chaotic roll out and limitation of the new standards. Let’s face it: nobody really seems to know how PSD2 will work out, let alone when, as the deadline for implementation is approaching faster than any type of structure or clarity to guide it. Secondly, we have to acknowledge that PSD2 is mainly a European solution: it only applies when the entire payment chain is enrolled, so on EU transactions with EU issued cards. For cards from other regions, or EU card transactions with merchants in other regions: PSD2 doesn’t apply. So, if and when PSD2 will be implemented, an initial drop in fraud might occur in the EU segment. The problem (as always) is expected to just shift, not disappear. 

To play safe, merchants and banks should still aim for direct cooperation in any way they can, to receive alerts on fraud.   

 * By no means do we claim this article to be a complete overview of all available solutions: this is a mere selection of examples.

 


Share this post on

Back to news overview