Business Problem:
Long standing PCI – Payment Card
Industry Standard aims to solve the problem around security related to
accepting, handling, transmitting and ultimately storing cardholder data. Thus
high risk that is associated with Merchants that employ lax security practices.
The obvious solution to this problem is to eliminate some cardholder data
handling and processing by the merchants. If Merchants do not process cardholder
data, the probability of theft of the data outside of secure channels is
drastically reduced, which is directly proportional to the risk associated with
compromise and fraud related to cardholder data. Additionally PCI compliance
and audit costs are exorbitant including the security exposure of storing
credit card information.
EMVCo Standard:
Visa, MasterCard and Europay (EMVCo) published a new
specification on Payment Tokenization.
The idea is to provide a specification with proven technology to
minimize fraud by reducing and eliminating exposures that may compromise the
financial transaction. EMVCo has introduces in their Payment specification to
ensure standardization around token solutions and more importantly to address
fraud exposures (and financial loss) with existing and newly emerging payment
systems. Below are salient features of the Payment Tokenization specification:
a.
Token
Format – The data format needs to be exactly similar to current day credit
card numbers
b.
Token to
Initiate Payments – This is one unique requirement that differentiates
itself from the traditional financial tokens – which essentially masked the
data for privacy.
c.
Network
Specificity – Token are Merchant or Payment network specific.
d.
Token as
a payment Object - The PAN – Personal Account number is the data that is
between the issuer and end consumer. The rest of the ecosystem gets this
payment object, which is token. Potentially a Token service provider may emerge
to provide domain specific services.
e.
Token
Assurance level – A suggested mechanism to associate risk with the type of
token. Risk analysis tools based on token issuer etc, will generate risk to a
domain, and either a high cost or denial of transaction based on token
assurance level.
f.
Token
Metadata – additional “Data Elements” assigned to the payment object that
describes the domain, cryptography, payment network data and assurance level.
Metadata can be further utilized for threat analysis and KYC (Know your
customer) applications.
g.
And more…
Each of the implementable items have a
ramification on the Payment ecosystem, but needless to say these are to be
designed to work with current system to ensure adoption and limit the costs of
expensive upgrade of payment and POS systems.
Payment Tokenization Technology:
Tokenization
its simplest form means data substitution. This technology is used in many
areas including enterprise security systems, Middleware services, Cloud
application and services. Token is essentially a substitute in place of some
meaningful data or policy. The idea behind token is to protect the data, and
device a system to ensure that if the token are lost or stolen the data is
preserved or uncompromised. This also paved way to many other qualities of services
included in toke metadata such as time of expiry, other policies if access etc.
The concept of Token has found a wide application in many areas of enterprise
across many industries.
EMVCo Payment Tokenization takes
into consideration the emerging payment technology and Mobile Payments. The specifications
include PAN Privacy, elements of Mobile Payments, and use cases with Card
present and card-not-present transactions. This standard makes sense as it
ensure and address the technology and privacy implications around Near Field
communication (NFC), Host card Emulation (HCE), Cloud based Security (SE) and
Mobile Wallets/mPOS systems.
The Payment tokenization standard
has the potential to move away form two variables namely Card present and card
not present transactions to several creative ways to set the base rate of all
type of Omni-channel transactions. This is due to elimination of traditional risk model and
adaption of new risk models. The risk in this new model is induced by “Token
assurance level” which assess risk of token authenticity by various mechanisms
such as validation (with a token service provider), identification at various times
such as issuance, and transaction processing. This implies the new base rates
based on the risk assurance levels. For instance token with lowest risk score
will incur lowest rates. This could potentially induce new roles of token
service providers and token requestor. These new roles could also provide new
business or service monetization opportunity by new or existing ecosystem
players.
Technology
Components:
1.
Token and
Card Data Vault -- This component is a storage for PAN, Token and
personalized data. This can be on-premise of the service provider or in an
off-site or secured public cloud environment. Because these sub-system stores
personalized information this component needs to be PCI-DSS compliant.
2.
Tokenization
Provider: This is a service provider and often times called a Token service
provider. The service provider
should implement services with minimal impact to the merchant for ubiquitous
adoption. Below are a few services that can be expected from a Token service
provider.
a.
Data
Discovery – Should assist with data inventory and Asses the location of
sensitive data. This also helps with determination of token assurance level
that indicates risk.
b.
Data
Conversion – This subsystem or service allows for service provider to
accept the data from merchants legacy systems like card on file and other PCI
data and convert them into tokenized information back to Merchant for back
office applications. This is an important step in on boarding merchants to a
new system and reduces their PCI compliance requirements.
c.
Token
Composition - Compose token as prescribed by the EMVCo specifications and
provide the token to merchant for processing by the payment chain ecosystem.
d.
Token
Format – The ability to format the token that mimic the card numbers and
all the restriction imposed by EMVCo specification such, not include bin or
credit card network identifiers, not include possibility of matching with real
card numbers. Etc.
e.
Encryption
– The token when stored with mapped data and other PCI information should be
encrypted with string encryption. The
tokenization provider’s encryption process should fit into the POS without
significant modification.
3.
Token
Generation System – this system includes tokens—bits of data associated
with and used to retrieve cardholder data—is generated. There are many standard
and custom methods to generate tokens, but regardless of the choice of method (such
as non-reversible cryptographic function), PAN or primary account number cannot
be deduced from its associated token.
4.
Token
Mapping system –This is subsystem for managing token service providers
token mapping system. This
component enables authorized personnel to retrieve the stored PAN when it is
needed. This is process involved for dispute resolution.
5.
Cryptographic
key management – This subsystem is involved at many levels to ensure the
management of generating and using cryptographic keys in a tokenization
solution.
Business Opportunity:
Payment Tokenization has been shown to be a highly effective
data security tool with EMVCo and Payment ecosystem players behind this specification;
Payment tokenization is bound to take momentum. Many business owners who
process credit cards remain in the dark about how this process functions. This
leaves a business opportunity to be exploited with by existing payment
ecosystem players or new entrants.
References:
6.
http://files.firstdata.com/downloads/thought-leadership/primer-on-payment-security-technologies.pdf
No comments:
Post a Comment