Tokenisation set to reduce operational costs for credit card merchants

A new method of enforcing data protection in applications promises to reduce both operational costs and security threats for credit card merchants.

Known as tokenisation, the method can be applied across a broad range of industries and applications, such as sensitive financial services information, personally identifiable information for healthcare, and transformation of production data as it moves into development and test environments. To date, however, the most widely adopted use has been to protect payment card information.

Karel Rode, Principal Consultant of RSA, the Security Division of EMC Southern Africa, explains that organisations interested in preventing data breaches or meeting compliance requirements must seek to protect sensitive data in the application layer, where the majority of threats reside.

“Until now, encryption has been the de facto standard for data protection, but the changes required within applications can drive costs up and timelines out, jeopardising efforts to meet regulatory deadlines and capitalise on business opportunities. Lately, tokenisation has gained a lot of traction as an application control, thanks to the benefits it delivers,” Rode says.

Tokenisation works by substituting an arbitrary value of equivalent type and character for an element of sensitive information. In complying with Payment Card Industry (PCI) Data Security Standards (DSS), for example, eliminating the exposure of a credit card number both within and outside the enterprise is of paramount importance. Tokenisation substitutes a different, randomly associated 16-digit number for the credit card number as soon as that credit card number is captured, such as at a point-of-sale device in the retail environment. This is done in such a way that the token cannot be linked back to the original data.

The advantages of tokenisation over traditional encryption include reducing the operational costs and overhead associated with encryption. Tokenised values maintain their original format, reducing or eliminating the amount of database schema or application changes that need to be made before implementation.

In addition, other applications can potentially make use of that data without ever having access to the real information. For example, when an identity number is tokenised, the last four digits of the original number can be preserved in the token. If a call centre needs to verify the user's identity, using the last four digits of the ID number could be sufficient, and it is not necessary to de-tokenise or gain access to the original information.

According to Rode, another business benefit is the ability to reduce the scope of audits.

“If a call centre application needed to get the last four digits of an ID number using an encrypted value, it would need to have access to the key management system and also decrypt the information. This puts the application in the scope of audits for compliance,” he explains.

“If a tokenenised value is used, and the data is never de-tokenised, that application is out of audit scope. This can significantly reduce the amount of effort an organisation devotes to compliance and save a considerable amount of money over encryption solutions. Also, using a token allows applications to remain unchanged. Combine this with the same level of protection as application encryption, and you get a very compelling solution for data security.”