Four Merchant Safeguards for Protecting Customer Data

Business-to-customer (B2C) applications are the glue that keep companies connected to their clients.  These B2C applications provide a plethora of services that include customer account management, payment processing, loyalty programs, and customer support, as well as other functions that customers need for engaging with their favorite vendors or service providers.


Because we support thousands of these B2C applications for our clients in over 80 countries, Teleperformance is in a unique position to assist with fraud detection and prevention.  As part of the service we deliver to our clients, we execute more than 900 risk assessments annually to evaluate these applications and provide recommendations for hardening their B2C applications.


At the end of the day, our goal is to protect customer information (PII, Credit Card, personal health information) from being compromised – whether perpetrated by an external threat or from an unscrupulous employee on the inside.  Below are some of the trending issues we’ve seen during client risk assessments.  Many of these considerations should be incorporated early in the application development process in order to avoid expensive, post-deployment fixes.

 
1. Ensure Correct Customer Identification

While this application flaw has become less common, it is still the first line of defense for preventing threat actors from engineering a path into your customer’s account.  Your B2C support employees should have a fool proof way to positively identify the customer before they perform any services.  This is especially critical when handling payment processing or banking transactions. 

Some of the best solutions we’ve seen include:  

• Voice fingerprinting
• One-time passcode sent to the mobile phone registered to the account
• Confirmation that the mobile phone number connected with the account is identified as the device being used
• Browser cookies and computer fingerprinting for non-voice B2C services. 
• A less effective control, but easier to engineer post application deployment, would be the infamous -- and rarely remembered -- security questions and a fixed account PIN. 

The least secure option is to have the customer verify their mailing address or provide some other, easily accessed reference.


2. Send Customer Notifications When Account Info is Changed

If an outsider is able to socially engineer their way past security control #1 above, their next step will be to change the customer’s account information. This is what will allow them to perpetrate their fraud.  Often, this includes changing the mailing address, email address, and phone number so the threat actor can gain unrestricted access to the customer’s account and even lock the true customer out of their own account. 

There are many ways to tackle this problem. The simplest option is to send a notification when important account information is changed.  The most effective notification approach is to send an SMS message to the mobile phone listed on the account with a link requiring the customer to approve or decline the change with a simple “YES” or “NO” response.  Email is an effective means as well, but not as real-time as the mobile SMS message.

3. Avoid Exposing Payment Information to Support Staff

There should never be a situation where a customer contacting a company should need to verbally provide their full credit or debit card information over the phone or during a support chat session.  The technology needed to provide this information “out of band” from the customer support employee has been available for years.  For voice support calls, Interactive Voice Response (IVR) allows the service agent to connect the customer to a server that will take the input of the payment information directly from the keypad of their phone.  For the B2C support functions that are chat-based, you can simply put a link into the secure payment website in the chat session that allows the customer to connect and input their payment information without disclosing anything directly to the support employee.  An additional recommendation is to have a message in the standard greeting recording that your support employees will never ask for your payment information over the phone, to further protect against insider threats.


4. Minimize the Customer Data Needed for Employees to Provide Support

Your customer database may have 50 data elements of information you use to enhance the customer experience.  When designing the B2C application, careful attention should be placed on exactly what data elements are needed to accomplish the B2C service.  Case in point -- if you are delivering technical device support, the customer service employee delivering that service should not need to see payment information (or other PII) that might be in-scope of GDPR. 

In some cases, even if a customer service employee needs to see some data, they may not need to see all of it. Tokenization can be used to obfuscate that data element and reduce the exposure risk.  Additionally, always remember that “idle hands are the devil’s workshop” – meaning that your B2C service employees should never have access to the customer accounts when not on a call with that customer.  The application should lock service employees out of the application and prevent access to the customer accounts once the connection (call or chat) is terminated. 

With these four security protocols applied to your B2C service delivery applications, you’ll make it very difficult for a threat actor to have any success in attempting account fraud.  And, many of these recommendations are simple if applied early on in the application development.


So, application developers should incorporate these features as baseline security and privacy elements because your customers are counting on you to protect them -- especially during the holiday rush.