I've seen some emails about this. Does anyone understand what it all means?

If you mean PCI compliance for handling any credit/debit card details. With regards to call recording, I understand for PCI compliance it is necessary to switch extension side recording off when credit/debit card details are given.

Hi,

PCI DSS is basically a standard endorsed by major Credit/Debit card providers and should be adhered to if your company accepts or stores Credit/Debit card information.

It's not a law kind of more like industry compliance guidelines.

Here's a link to the website.

PCI SECURITY

I've read that VISA and other card providers are set to charge "fine" Companies heavily if there is a case where cardholder data laxity is traced back to a company and that the company may lay itself open to being sued for large amounts by the cardholder.

Has anyone heard of software to avoid this?

A previous post from Paul Miller mentioned PCI DSS and recording of telephone calls. Recording is not required to stop during the taking of the actual credit card number itself (1234 1234 1234 1234), but companies are not allowed to store (in any form including audio) the 3- or 4-digit security code from the back of a card.

(With the disclaimer that I work for Veritape), you may be interested in some further information related to PCI DSS and recording telephone calls we posted recently here .

CR.

Companies are likely to pay higher charges to the card companies if they are not PCI DSS compliant.

The standards also call for encryption (depending on your recording architecture) and a strong audit trail capability to be able to review who has listened to what and when. If you use screen recording then some data needs to be masked at the point of recording.

This has become a hot topic for any organisation that handles card transactions - but the big companies are going to be hit the hardest and first.

With respect to Jeremy Jackman's question - all of the major call recording solution providers have claimed PCI-DSS compliance. I beleive that some are further down the line than others but if you stick with a major player you should have a solution available shortly. Despite what Cam's article says - you can be PCI compliance in a trunkside recording solution.

If you were running on a hosted platform, which Company would you go to to obtain a compliant package?

A year on from the previous post in this topic, and the world of PCI DSS has become a lot clearer, and most organisations are now compliant. Or are they?

According to The Logic Group, a company which researches this market, only 15% of companies taking credit card payments are compliant, and that's not increased much since last year (see here for the report). It's not stated, however, how many companies were surveyed, and how the mix between the larger Level 1 Merchants and smaller companies is represented.

I suspect that there are still a lot of contact centres with questions about how PCI DSS applies to them.

So, in the spirit of trying to encourage some conversation, here's a few thoughts for us to consider:

1. Do you know what PCI DSS is?
1b. Does it apply to your company?

2. How is it impacting your business at the moment?
2b. How has it impacted your business in 2008 as a whole?

3. What (if anything) remains unclear for you, about PCI DSS?

4. In 2009, what do you think will change in your company to address PCI DSS?

CR.

Just a note that last Friday the PCI DSS clarified their position on storing credit card details in recorded telephone conversations.

If you are able to log in to the PCI's Talisma server (you'll know what that means if you can), then here is the new text.

If you can't log in, then we've repeated the text on PCI DSS and call recording here

CR.

Thanks for posting that,

It makes things slightly clearer now, although there's
still mud in the water :-)

Regards

DaveA

Once again (twice within a month) the "Frequently Asked Questions" on call recording have been changed by the governing body of the payment card industry, the PCI SSC. We have a summary here: http://www.veritape.com/2010/02/pci-dss-compliant-call-recording-in-call-centres-latest-changes-to-faq-by-pci-ssc-on-18-feb-2010/

CR.

It seems obvious to me that call recording must be switched off or DTMF tones that the caller creates entering a number of any kind will be recorded and therefore could be hacked.
The NewVoiceMedia PCI DSS compliant IVR switches off call recording during the IVR and then if the call centre requires recording it can be switched on again afterwards before the call is returned to the agent.
There is no agent on the line to listen to the DTMF.

Based on the revised statment from the council is it a requirement that the call recording server be encrypted?

It is a violation of PCI DSS requirement 3.2 to store any sensitive authentication data, including card validation codes and values, after authorization even if encrypted.
It is therefore prohibited to use any form of digital audio recording (using formats such as wav, mp3 etc) for storing CAV2, CVC2, CVV2 or CID codes after authorization if that data can be queried; recognizing that multiple tools exist that potentially could query a variety of digital recordings.
Where technology exists to prevent recording of these data elements, such technology should be enabled.


It is obvious therefore that Call Recording should be turned off during the presentation of the Cardholder Data. Encryption of the call recording is not valid.

(Disclaimer: I work for Veritape. We provide PCI compliant call recording systems to contact centres.)

As an update to the above discussion, you may be interested to know that we have just launched Veritape CallGuard - a generic 'bolt-on' which brings full PCI DSS compliance to any existing call recording system. Customers keep their existing telephony, call recorder, CRM systems, payment processes and (critically) payment provider. Nothing changes in a customer's critical IT and telephony systems, and PCI compliance for call recording is achieved incredibly quickly.

Veritape CallGuard also dramatically reduces the potential for internal data theft, since customers never tell their card details to a contact centre agent, and the agent never sees the card details on screen.

For more information, please see our blog post announcing the launch, here.

CR.

Just been asked to look into this as we will be taking card payments and came across this excellent thread.

We do record all calls currently although not PCI compliant.

As a company which is only receiving payment from customers (not regulated by FSA) are we required to actually required to record these calls or can we just route this type of call to bypass the call recorder?

Any help advice or direction would be appreciated.

Thanks

There are various issues involved in telephony to take card payments. Among them are:

1. Storing of card holder details.
2. Creating an environment in which to function that is as secure as possible.

We have a Hosted Call Centre (ContactWorld) and provide a multi-tenant environment that is complemented by a PCI DSS Level 1 compliant payment taking application.
To do this we have had to build an environment that is restricted to taking payments. We take multiple millions of pounds annually for our customers. We have developed applications that are web based, IVR based - both stand alone and mid call.

It is very clear in the guidance that call recording must not be used in that part of the call that is involved with the input of card data by the caller. We turn call recording off routinely just before the caller is instructed how much to pay and to input their details.

To be absolutely safe, the logging of the systems must also disguise the figures input by the caller.

If you store card data as well, you are up against a completely new tranche of regulations to comply with.

Just bypassing the call recording for specific calls in no way makes you PCI Compliant.

The NewVoiceMedia PCI Compliant system prevents agents obtaining card details by removing the caller from the agent and returning them after the payment has been made.

The level of PCI Compliance required is dependant on the amount of traffic and the sums of money involved.

The best thing to do before embarking upon any spend, if you cannot self certify, is to consult a QSA - a list of whom can be found at

https://www.pcisecuritystandards.org/pdfs/pci_qsa_list.pdf

They will advise about Compliance. If you wish to discuss this in person, please call 0800 280 2888 and ask for me. Please wait until the end of the month though, because we are going through our annual PCI DSS audit!

Many thanks for your comprehensive reply.

I am aware that bypassing the call recording of such calls will not make you compliant and there are downsides to not recording such calls. The question is are we legally oblidged to record card payment calls?

As receiving payments in this way is relatively new to the business (predominantly a monitoring centre for the elderly & infirm) and at the moment the requirement is only very limited and does not warrant any meaningful investment at this time, however that is not to say the volume of card payment via the telephone will not increase over time which will may then warrant such investment, so if there is no legal requirement to record the calls this may be the route taken for the interim.

Hello,

we have a a PCI compliant IVR site in our company where we can perform credit card transactions.

In a new business case, we're looking to handle just payment functionality for other call centres, whereas the call centre itself is hosted by other companies (or on local pabx).

Case: You call Company A, and you get "for customer service press 1, for support press 2, to pay your bill press 3". Then on the press 3, the call is transferred from Company A to our IVR which resides in a PCI compliant environment.

You then have the call from the customer, through an ivr system of Company A and then forwarded to our PCI compliant environment.

Would you think this is within the PCI requirements to handle things like this, or do you think that we're required to disconnect the call, and then initiate a new call directly from our PCI environment to the end customer (and thus not going through Company A)?



Thanks in advance for your points of view on this issue,

Kjetil Johannesen