A question for contact centres
What do you think of when you hear the term ‘PCI’?
Do you think of Peripheral Card Interconnect; bus standards such as PCI and PCI Express (PCIe) associated with computers and peripheral interface cards?
Or does your mind turn to Payment Card Industry standards?
If the latter, chances are you’re involved in the call or contact centre business, in which case, you’ll be acutely aware of the Payment Card Industry Data Security Standard (PCI DSS) and the associated Payment Application Data Security Standard (PA-DSS).
Anyone looking to develop a business application to serve the contact centre sector will be aware of the need to comply with the PCI DSS and PA-DSS standards.
Payment card security
You’ll know that the global PCI DSS mandates that any business, of any size, that stores, processes or transmits payment cardholder data, and/or sensitive authentication data (SAD), adheres to its information security best practices. Those practices are identified in a framework – a minimum set – of 12 specific requirements for protecting cardholder data. The requirements are supported by the three-step process of assess, remediate and report, facilitating an ongoing process for continuous compliance.
The PCI DSS applies to all entities involved in payment card processing, including merchants, payment card processors, financial institutions, and service providers. It also applies to an application developer implementing a contact centre solution. Therefore, if you’re in that situation, you’ll need to ensure ongoing compliance with the PCI DSS.
An essential technology for developers of contact centre applications is media processing for telecommunications; what are often referred to as telephony resources. As many credit card transactions are conducted via telephone, whether through the legacy PSTN or over a next generation, IP-based network, the processing, storage and transmission of payment cardholder data naturally occurs during telecommunications.
The sections of the PCI DSS relevant to a telephony-based transaction refer to SAD, which includes magnetic-stripe data (or the equivalent on a chip), the 4/3-digit card security code, and personal identification numbers (PINs) or PIN blocks. The requirements include the common sense obligation to protect stored cardholder data. Specific requirements go further in that they require that cardholder data must not be stored after authorisation, even if encrypted.
The security requirements apply to all system components included in or connected to the cardholder data environment (CDE). Those system components include network devices, application servers, and contact centre applications, whether internally provisioned or provided as a service by a third party. And the implications extend to components or devices located within or connected to the CDE.
A classic example of one such device is the call recorder. Those are used to monitor and record conversations between calling (or called, in the case of an outbound dialler application) customers and call centre agents. The practice of call recording is widespread, not least in the financial services sector, and is governed by other legislation and requirements, such as the Sarbanes-Oxley Act (in the United States), and the Regulation of Investigatory Powers Act 2000 (RIPA) and the Telecommunications (Data Protection and Privacy) Regulations 1999 (in the [still] United Kingdom).
When a call, during which a customer enters a PIN using the telephone keypad, is recorded, the dual-tone, multi-frequency (DTMF) digital signature that represents the PIN is captured together with the audio voice signal. That is, unless deliberately, something is done to remove or extract the DTMF digits from the recording.
The need to eliminate the DTMF in the recording is explicit in the PCI DSS standard. So if you’re involved in contact centre solutions, you’ll need a technology solution that will enable their system to suppress DTMF tones in recordings, and so comply with the PCI DSS.
In a telecommunications environment, which means any call centre, the solution involves telephony resources, which can be implemented in two ways. If you’re prepared to integrate third party telephony resources into your solution, typically by means of a vendor API, the result will be a seamless, built-in system option that can be readily activated by the end user organisation. If you’d rather shy away from such activity, the alternative is to employ an in-line, intermediary device as part of your solution.
Technology platforms such as Aculab’s Prosody S and Prosody X offer APIs that enable developers to readily integrate the functionality needed to suppress DTMF signals. Aculab’s vast experience in telephony signal processing, and its knowledge and expertise in the field of DTMF handling (generation and detection), is second to none. Many contact centre systems and solutions are underpinned by Aculab’s Prosody X DSP boards and chassis, or its SIP-based Prosody S host media processing software.
Aculab also offers an intermediary solution, which is based on an application of its ApplianX IP Gateway. Its tone elimination (or DTMF clamping) feature is a user configurable option that can be applied to suppress DTMF signals, in real-time, during a call that is being recorded. By installing the gateway in-line, between the transaction processing system and the call recorder, you can ensure that DTMF signals are prevented from reaching the recorder.
Get ahead, get a gateway!
An application note on this topic is available on Aculab's website.
Publish Date: October 29, 2014 8:08 AM