PCI DSS Compliance Blog

Fed Announces Final Durbin Amendment Rule – TSG Analysis

The Federal Reserve announced their final ruling on debit card interchange fees and routing. The finalized rules affect all banks issuing debit cards, pre-paid cards, and payment card networks, as well as merchants who process debit and prepaid card transactions. However, small issuers (banks and networks under $10 billion in assets), government programs and gift cards are exempt form the ruling.

Throughout the years merchants have become increasingly restless over the rising debit card transaction fees and regulations. According to the 2009 Nilson Report, $1.21 trillion in purchases were paid for by debit cards and processed through Visa and MasterCard networks, which generated $19.7 billion in fees paid to debit card issuing banks by merchants. The Durbin Amendment fought to cap these fees and regulate the control that banks and networks have over debit card transactions. 

The Durbin Amendment is a component of the Dodd-Frank Wall Street Reform and Protection Act sponsored by Senator Richard Durbin (D-Ill.). The Amendment was successfully passed to cap debit card fees for merchants. This victory for merchants offers some relief from high fees and creates a competitive market, allowing merchants to shop around for lower transaction prices.

The final ruling on debit interchanges implements a base fee cap of $.21 with an allowance of $.05 to account for fraud protection costs. An additional proposed rule is in discussion that allows banks to charge an additional $.01 per transaction if they meet specific fraud prevention standards.

The final limitations on payment card networks included:

• Disallowing issuers or payment card networks the ability to restrict merchants to route debit transactions over any other network that processes such transactions.

• Networks are not allowed to prohibit setting defaults for PINs or signatures.

In addition, networks cannot prevent merchants from offering payment by cash incentives, and networks cannot prevent merchants from imposing a $10 transaction minimum or prevent merchants from setting maximum transaction amount limits. (TSG Takeaways)

These debit interchange rules and limitations on payment card networks go into effect October 1, 2011. The official document can be found on the federalreserve.gov website.

Element Payment Services is a supportive resource for your payment processing questions. For help understanding how the Durbin Amendment affects your business, contact Element today. 

Visa Releases Data Security Best Practices for Software Vendors

 On August 25, 2010, Visa released a top ten list of best practices for payments application companies. This is part of Visa’s continued effort to help secure the industry from the recent trends of card data theft. This set of best practices was created to help those companies who install or manage payment-application software, similar to that used in point-of-sale terminals. 

The ten best practices recommended are as follows:

1.    Perform background checks on new employees and contractors prior to hire;

2.    Maintain an internal and external software security training and certification curriculum;

3.    Adhere to a common software development life cycle across payment applications;

4.    Ensure that newly released payment application versions are Payment Application Data Security Standard (PA-DSS) compliant;

5.    Conduct application vulnerability detection tests and code reviews against common vulnerabilities and weaknesses prior to sale or distribution;

6.    Actively identify payment application versions that store sensitive authentication data and/or retain critical security vulnerabilities, and notify all affected customers;

7.    Maintain customer service level agreements stating that only PA-DSS compliant payment application versions will be sold and supported;

8.    Implement an installer, integrator and reseller training and certification program that enforces adequate data security processes when supporting customers;

9.    Adhere to industry guidelines for data field encryption and tokenization across payment applications that use these technologies;

10.    Support capability of dynamic data solutions across payment applications

Visa encourages others to do their part to help standardize and secure the industry, asking acquirers, merchants and agents to ensure that the payment application companies they use have passed a rigor of mature software processes including the Visa best practices spelled out above. The industry has seen numerous suggestions and implementations around the topic of card data safety to help establish an end-to-end solution that is safe for all parties, with the hope to eliminate the countless card data fraud cases we’ve already encountered.

Though these are solely suggestions to better secure the industry and build awareness around the data theft issue at hand, Visa emphasizes the importance that all payment system participants remain diligent and maintain compliance with the Payment Card Industry Data Security Standards (PCI DSS) at all times. If you are interested in getting more detail on Visa’s best practices, read Visa Top 10 Best Practices for Payment Application Companies, Version 1.0.

Visa’s Global Best Practices Mark First Step Toward Standardizing Tokenization

 Last month Visa released its Global Best Practices for card data tokenization to provide guidance to merchants, vendors and service providers. With Visa’s expertise and experience in the card data industry, they are able to provide great insight into the requirements and necessary steps to bring security to the industry. In the Best Practices, Visa emphasizes the practice of tokenization, which takes a credit cards primary account number (PAN) and replaces the numbers with proxy numbers. This use of tokens in accordance with best practices limits PAN storage greatly reducing risk of theft. 

Visa’s best practices highlight four key components of effective tokenization:

•    Token generation - process for how a token is generated

•    Token mapping - process for associating a token to its original PAN value

•    Card data vault - central repository of cardholder data that is used by the token mapping process

•    Cryptographic key management - process for how cryptographic keys are managed and used to protect cardholder and account data

Visa’s Best Practices Version 1.0, marks the initial step in standardizing tokenization across the industry. This document will undoubtedly encounter several amendments, as Visa solicited feedback from the industry before an August 31, 2010 deadline. 

It seems that a portion of the industry has a few issues with this Visa’s initial draft, primarily around their decisions for tokenization, and the lack of standardization around this security strategy. Though this is a legitimate concern and one that will be analyzed by the industry, this is still a step in the right direction. Visa made the necessary push to begin development of a formalized approach to card data security and recognized tokenization as a valuable approach. It should be noted that tokenization is intended as a complement to, rather than a replacement for, the Payment Card Industry Data Security Standard (PCI DSS).

We are still a ways away from implementing an industry-wide standard or set of tokenization requirements, but we are heading in the right direction. Industry pundits now have until August 31, 2010 to collaborate and provide feedback to these Best Practices, as the industry moves toward a greater level of card data security.  

Third Party Agent Registration and PCI DSS Compliance for Software as Service (SaaS) Providers

By Susan Kohl

As a software vendor, do you know what is required for your application to accept payments and be compliant with industry regulations? In order to understand the requirements independent software vendors (ISVs) need to determine which category is applicable to their business model.

Table 1:  Software Provider Categories 

As illustrated in the table above the requirements vary based on the business model which is representative of the types of services a software vendor provides to their customers.  This article focuses on clarifying the requirements for SaaS and hybrid models and can best be summarized with the following steps.

Registration with Credit and Debit Card Brands

The card brands (Visa, MasterCard, STAR, etc.) require “Registration” of all entities providing the following services to the payment industry (referred to as Third Party Service Providers or Agents (TPAs)):

• Solicitation of payment activities
• Chargeback, fraud and settlement management services
• Enabling authorization and/or settlement activities (gateway and hosting services)
• Performing payment encryption management services
• Payment program processing, managing, monitoring and/or reporting (such as loyalty programs)

SaaS ISVs provide services that hosts the software that stores, processes, and/or transmits cardholder data on behalf of their merchant therefore they qualify as a TPA. 

The purpose of Registration is to clearly identify all parties that handle payment transactions and/or cardholder data in any way.  TPAs must be registered by a card brand sponsor Member.   A Member must be a financial institution (aka bank) that meets the criteria of the card brand to sponsor TPAs.  We will refer to these Members as a “Sponsor Bank” for purposes of this article.  There are many other types of Members not relevant to this article.  TPAs can select their own Sponsor Bank or work through their payment processors’ Sponsor Bank to complete the proper Registration.  

The table below highlights key information required, at a minimum, from you for the Sponsor Bank to properly complete Registration.  Each Sponsor Banks’ Registration program requirements may vary, however some basic information standards are required by all Sponsor Banks as dictated by the card brands operating rules and bank regulations.

Table 2: Registration Information Required

	You Provide	Sponsor Bank Performs	Result
1.	Memo describing your business activities related to payments and provide a process flow that outlines incoming and outgoing activity (authorization pass through, settlement points, etc.), third party service touch points. If possible, request a face-to-face meeting with the Sponsor Bank and/or Processor.	Review to determine Registration category and how to underwrite the risk and identify what third party companies handle cardholder data (TIP: Sponsor Banks may not request this, however to avoid confusion on what category you should be Registered as and the risk associated with your business it is prudent to provide such documentation)	The more clear and concise the business overview and operations the less frustrating and misclassification will occur during your Registration process.
2.	Application for Registration	Information used for underwriting and to prepare the card brand specific forms	In some cases, the TPA may be requested to complete all of the card brand forms rather than a single application. Each Sponsor Bank may differ on their procedures. Inaccurate and/or in complete information may be grounds for denying an application.
3.	Registration and Application Fee(s) (Fee range is $10,000 to $25,000)	Submits fees to card brand and maintain a small portion for the administrative process	Fees along with submission of the required documents to the card brands yields “Registration”, if approved.
4.	List of all principal owners (for non-public entities only) (TIP: Run a federal and state background check on each of the principal owners first and be prepared to address any known issues.)	Background checks (criminal, credit, financial)/tax liens	Ensure the results do not violate company policy for items such as federal offenses and related financial crimes.
5.	Financial statements and tax returns (most recent year and 1 -2 previous years)	Financial analysis to determine credit and financial risk	The analysis may yield a required reserve and/or principal owner guarantee to cover risks that may exceed credit and financial ability.
6.	W-9 (Tax ID)	Run a company background check	May be denied Registration if the company Tax ID and business existence cannot be validated
7.	Business License, Declaration of Corporation (non-public entities only)	Validate business existence and purpose of conducting business	May be denied Registration if the company existence and business purpose cannot be validated
8.	Credit check authorization form (non-public entities only) (TIP: Review credit bureau reports for all principal owners first and be prepared to address any known issues.)	Perform a credit check	Derogatory credit information may either pend the Registration process requiring more information from the TPA or a higher requested reserve. The TPA may be denied if bankruptcy or poor credit scores were noted.
9.	PCI compliance status/validation (Estimated costs range from $250,000 - $2.5 million, includes implementation)	Review the list of approved service providers and the PCI status (Global List of PCI DSS Validated Service Providers) If not listed and/or a Report on Compliance (ROC) has not been provided by the TPA, they will request an action plan to achieve PCI DSS.	Entities not PCI validated may be denied Registration unless they can provide evidence that cardholder data is not “handled” (stored, processed and/or transmitted) in the TPA environment.
10.	Other information/forms specific to the Sponsor Bank (e.g. business insurance verification)	Varies depending on the information requested; ensure proper liability coverage	Will vary depending on the information requested. If insurance coverage is insufficient to cover the risk

PCI Data Security Standards (PCI DSS)

The PCI DSS applies to any entity that stores, processes, and/or transmits cardholder data. It covers technical and operational system components included in or connected to cardholder data. If your business accepts or processes payment cards, it must comply with the PCI DSS.

PCI DSS is an important component of the Registration process, one not taken lightly by a Sponsor Bank and the card brands. TPAs are not only required by the card brands to be Registered; they must also be PCI DSS compliant if they store, process and/or transmit cardholder data. PCI validation requirements vary slightly based on the Service Provider PCI Level as noted in the table below.

Table 3:  Service Provider PCI Levels and Requirements Summary

Service Provider PCI Compliance Level	Criteria (varies per card brand)	Requirements
Level 1	All third party agents that store, transmit, or process greater than 300,000 transactions annually (evaluated by individual card brand)	1. Annual Onsite Assessment by a Qualified Security Assessor 2. Quarterly Network Scan by an Approved Scanning  Vendor
Level 2	Includes all service providers that store, transmit, or process less than 300,000 transactions annually (evaluated by individual card brand)	1. Annual Self-Assessment Questionnaire (SAQ) – Version D 2. Quarterly Network Scan by an Approved Scanning Vendor

For more information about specific card brand PCI requirements review the following websites:

• Visa Third Party Agent or Service Provider(“CISP” Program)
  
• MasterCard Service Provider (“SDP”)
• American Express Service Providers
• Discover Service Provider (“DISC”)
  

Registration and PCI DSS Costs

Registration as a TPA typically costs between $10,000 and $25,000. Becoming PCI DSS compliant can add up anywhere from $250,000 to over $2 million. As a SaaS provider, you have the option of outsourcing your payment processing, which would eliminate the need (and cost) for registering as a TPA and decrease the burden of PCI DSS compliance.

Susan Kohl is CEO of ThoughtKey, a payment industry boutique consulting firm focused on PCI, regulatory compliance, risk management and expert testimony serving all parties of the payment industry value chain. You can reach Susan via email or phone (678)522-2466 or on Twitter @PCISK.

PA-DSS and PABP

One common point of confusion for software vendors when it comes to PCI Compliance revolves around this question:

What’s the difference between PA-DSS and PABP?

Here’s the low down.  In 2005, Visa developed the Payment Application Best Practices (PABP). The purpose of the program was to guide software vendors in creating secure payment applications that prevent storage of sensitive cardholder data and mitigate cardholder data compromises.

Three years later, in 2008, the PCI Security Standards Council – made up of the major payment card brands — adopted Visa’s PABP and released it as the Payment Application Data Security Standard, or PA-DSS for short. In doing so, the PA-DSS replaced PABP for the purpose of the Visa’s payment application compliance program.  In other words, think PA-DSS, not PABP! 

The PCI SSC is transitioning all 555 products previously validated under Visa’s PABP over to a consolidated list located at the PCI SSC website, comprised of the validated PABP applications and newly validated PA-DSS applications. All new payment application assessments should undergo PA-DSS validation by a Payment Application Qualified Security Assessor (PA-QSA) and listing with the PCI SSC.  Another option is to go out of scope for PA-DSS by transferring the responsibility of handling sensitive cardholder data to a third party.

Each payment card brand has different requirements and deadlines for PA-DSS compliance.  At least up to this point, Visa has the most stringent deadlines for PA-DSS.  View them as well as other PCI compliance deadlines for each payment card brand in our blog post, PCI Compliance Deadlines. 

PA-DSS in 2010 – Are you Prepared?

2010 marks an important year for PA-DSS compliance.  On July 1 Visa’s fifth PA-DSS security mandate takes effect.  While the first four Visa mandates allowed various PA-DSS workarounds, the Visa Phase 5 Security Mandate clearly will not.  Up until this mandate, merchants using payment applications before the adoption of PA-DSS and who have not switched processors since its adoption were grandfathered in and not required to update to a PA-DSS compliant application.  This is no longer the case as of July 1: all merchants will be required to use only PA-DSS compliant applications.

With these fast approaching PA-DSS 2010 deadlines and the effort required to achieve compliance, Independent Software Vendors (ISVs) are finding themselves faced with major resource constraints.  It’s tough enough for ISVs to keep up with the competition and customer demand to build feature rich functions much less plan for compliance mandates requiring significant development time and effort.  However, ISVs that don’t take these deadlines seriously or remove their applications from the scope of compliance will lose customers that they worked hard to get and will ultimately be forced out of business. 

Most ISVs should have a PA-DSS compliance plan in place by now.  If you don’t, start by reading our post on PA-DSS implementation and get moving fast.  For those with PA-DSS plans in place, be sure that you are reaching out to merchants using your software and informing them of the upcoming July 1 deadline.  If they haven’t upgraded to a PA-DSS compliant version of your application by this date, they risk losing the ability to process credit and debit card transactions. 

Visa and PCI Compliance

Visa PCI compliance can seem like the veritable fast-moving train upon which you should already be seated, ticket in hand.  Fortunately, the conductors of the train (Visa), have chosen to bring the train out of the station slowly enough to give everyone a fair chance to board it or, in some cases, catch up.

By implementing PA-DSS in distinct phases, Visa has afforded merchants and software vendors the opportunity to meet security standards at a gradual and manageable pace.  Rather than implementing wholesale security compliance mandates all at once, Visa’s compliance program has evolved through various phases.

As we wrote a post about recently, Visa’s Phase 4 Security Mandate for software vendors is quickly approaching.  While this is an important deadline, next year’s Visa Phase 5 Security Mandate represents the final stage in PA-DSS compliance.  All previous Visa security mandates have focused on identifying and phasing out payment applications that are not PA-DSS compliant.  The Visa Phase 5 Security Mandate, effective July 1, 2010, goes beyond removing non-compliant applications to require that only PA-DSS compliant applications be used:

Acquirers must ensure their merchants, VNPs and agents use only PA-DSS compliant applications.

While the first four Visa mandates allowed various PA-DSS workarounds, the Visa Phase 5 Security Mandate clearly will not.  Put simply, the advent of Phase 5 will only permit the use of PA-DSS compliant payment applications. 

With less than a year remaining, software vendors should begin planning for the final Visa PCI compliance mandate.

Related Posts and Pages:

Visa PA-DSS

PCI Compliance Deadlines

MasterCard PCI Compliance

VISA PA DSS - Phase 4 Security Mandate

As Ben Rothke wrote in a recent article, the much-ballyhooed debates in regard to PCI Compliance seem to shun the notion that PCI DSS is, effectively, evolutionary.  The PCI DSS “Lifecycle Process” (PDF) is intended to ensure that changes to PCI DSS follow a pre-determined 24-month cycle that allows for a gradual implementation of standards rather than drastic changes that would result in many organizations being suddenly non-compliant. 

Ironically, the very merchants for whom this gradual phasing-in was developed have been among the most vocal critics of PCI DSS.   Given such concern, it is hard to imagine the ferocity with which PCI DSS might be attacked were the entire PCI DSS “lifecycle” condensed and implemented at once; gradual implementation isn’t necessarily ideal for lockstep security, but it makes compliance among retailers far more realistic (and convenient), despite occasional assertions to the contrary. 

Similarly, merchants and software providers are witnessing Payment Application Data Security Standards (PA DSS) compliance continue on an evolutionary path, the ultimate goal being the elimination of vulnerable payment applications.   Accordingly, the payment application security mandates (PDF) set forth by Visa continue to move through the pre-determined five phases.

Visa PA DSS Compliance Deadline Approaching

As of October 1, 2009 merchants and software providers must decertify all known vulnerable payment applications, including those published on Visa's list of vulnerable payment applications. As future vulnerable payment applications are identified, VisaNet Processors, and agents, must decertify these, too, within 12 months.

What this means for merchants and software providers is that the age of relying on anything but compliant payment applications is nearing an end.  With the ability to accept credit cards at stake, trusting non-compliant applications hardly seems like a risk worth taking.

October 1 will be here quicker than you might realize.  Are you ready? 

Related Posts and Pages:

PA DSS Compliant Applications
Payment Application Data Security Standard (PA DSS)
PA DSS and PABP
Integrated Payment Processing
Hosted Payments

PCI Compliance Deadlines

Knowing the critical deadlines for the Payment Card Industry Standards - PCI DSS, PA-DSS, and PCI PED - is vital for any merchant or payment service provider.  But finding all the PCI compliance dates can be tricky: even though the PCI Security Standards Council (PCI SSC) developed these standards, compliance is actually mandated by the individual payment card brands - Visa, Master Card, American Express, Discover and JCB International.

The PCI SSC does not currently maintain a comprehensive list of the PCI compliance deadlines on their site, so we compiled one here for each payment card brand, along with a link to their PCI compliance program section of their sites.  We hope you find this list useful.

Visa CISP (Cardholder Information Security Program)

Merchants

All compliance dates for Visa merchants have passed. Visa's PCI compliance validation requirements for merchants:

Level / Tier	Merchant Criteria	Validation Requirements
1	Merchants processing over 6 million Visa transactions annually (all channels) or Global merchants identified as Level 1 by any Visa region	Annual Report on Compliance (“ROC”) by Qualified Security Assessor (“QSA”) Quarterly network scan by Approved Scan Vendor (“ASV”) Attestation of Compliance Form
2	Merchants processing 1 million to 6 million Visa transactions annually (all channels)	Annual Self-Assessment Questionnaire (“SAQ”) Quarterly network scan by ASV Attestation of Compliance Form
3	Merchants processing 20,000 to 1 million Visa e-commerce transactions annually	Annual SAQ Quarterly network scan by ASV Attestation of Compliance Form
4	Merchants processing less than 20,000 Visa e-commerce transactions annually and all other merchants processing up to 1 million Visa transactions annually	Annual SAQ recommended Quarterly network scan by ASV if applicable Compliance validation requirements set by acquirer

 

Service Providers

Level*	Validation Action	Validated By	Due Date
1	Annual On-Site PCI Data Security Assessment Quarterly Network Scan	Qualified Security Assessor Approved Scanning Vendor	2/1/2009
2	Annual PCI Self-Assessment Questionnaire Quarterly Network Scan	Service Provider Approved Scanning Vendor	2/1/2009

*Visa Service Provider Levels are defined as:
Level 1 - VisaNet processors or any service provider that stores, processes and/or transmits over 300,000 transactions per year
Level 2 - Any service provider that stores, processes and/or transmits less than 300,000 transactions per year

 

Software Applications - US and Canada*

Phase	Compliance Mandate	Effective Date
1	Newly boarded merchants must not use known vulnerable payment applications, and VisaNet Processors (VNPs) and agents must not certify new payment applications to their platforms that are known vulnerable payment applications	1/1/2008
2	VNPs and agents must only certify new payment applications to their platforms that are PA-DSS-compliant	7/1/2008
3	Newly boarded Level 3 and 4 merchants must be PCI DSS compliant or use PA-DSS-compliant applications	10/1/2008
4	VNPs and agents must decertify all vulnerable payment applications	10/1/2009
5	Acquirers must ensure their merchants, VNPs and agents use only PA-DSS compliant applications	7/1/2010

*In Asia Pacific, Central and Eastern Europe, Middle East and Africa, Latin America and the Caribbean (LAC), Visa acquirers must ensure that newly signed merchants use PA-DSS compliant applications by July 1, 2010. By July 1, 2012, those acquirers must ensure existing merchants and agents in the Visa network use PA-DSS compliant applications.

Visa CISP Program Home

Mastercard SDP Program (Site Data Protection)

Merchants

Merchant Definition	Criteria	Onsite Review	Self Assessment	Network Security Scan	Initial Compliance Validation Date
Level 1	Any merchant that has suffered a hack or an attack that resulted in an account data compromise Any merchant having greater than six million total combined MasterCard and Maestro transactions annually Any merchant meeting the Level 1 criteria of Visa Any merchant that MasterCard, in its sole discretion, determines should meet the Level 1 merchant requirements to minimize risk to the system	Required Annually	Not Required	Required Quarterly	6/30/2011
Level 2	Any merchant with greater than one million but less than or equal to six million total combined MasterCard and Maestro transactions annually Any merchant meeting the Level 2 criteria of Visa	At Merchant Discretion	Required Annually	Required Quarterly	06/30/2011
Level 3	Any merchant with greater than 20,000 combined MasterCard and Maestro e-commerce transactions annually but less than or equal to one million total combined MasterCard and Maestro ecommerce transactions annually Any merchant meeting the Level 3 criteria of Visa	Not Required	Required Annually	Required Quarterly	6/30/2005
Level 4	All other merchants	Not Required	Required Annually	Required Quarterly	Consult Acquirer

 

Service Providers

All compliance dates for Mastercard Service Providers have passed. Required validation procedures by level:

Service Provider Definition	Criteria	Requirement
Level 1	All TPPs All DSE’s that store, transmit, or process greater than 1,000,000 total combined MasterCard and Maestro transactions annually	Annual Onsite review performed by a Qualified Security Assessor (QSA)  Quarterly scan by an Approved Scanning Vendor (ASV)
Level 2	Includes all DSE’s that store, transmit, or process less than 1,000,000 total combined MasterCard and Maestro transactions annually	Annual Self-Assessment Questionnaire (SAQ)  Quarterly scan by an Approved Scanning Vendor (ASV)

Mastercard SDP Program Home

American Express Data Security

American Express requires merchants and service providers agree with their Data Security Operating Policy. American Express compliance dates are based on the date of the validation documentation: 90 days from the date of a scan, an updated scan document is due. One year (365 days) from the date of an Annual Onsite Audit, an updated Annual Onsite Audit is due.

Merchants

Level	Definition	Validation Documentation	Requirement
1	2.5 million American Express Card transactions or more per year; or any merchant that has had a data incident; or any merchant that American Express otherwise deems a Level 1	Annual Onsite Security Audit Report and Quarterly Network Scan	Mandatory
2	50,000 to 2.5 million American Express Card transactions per year	Quarterly Network Scan	Mandatory
3	Less than 50,000 American Express Card transactions per year	Quarterly Network Scan	Strongly Recommended

 

Service Providers

Compliance Requirements

Comply with the PA-DSS and the American Express Data Security Operating Policy Annual Onsite Security Audit Validation Documentation Quarterly Network Scan Validation Documentation

American Express Data Security Home

Discover Information Security & Compliance (DISC)

Merchants

Discover's Merchant Activity Calendar:

Activity	Date
Assessments started prior to 12/31/2008 may use PCI DSS v1.1 or PCI DSS v1.2	12/31/2008
All new assessments must use PCI DSS v1.2	1/1/2009
Last date that PCI DSS v1.1 assessments will be accepted	12/31/2009
All assessments must use PCI DSS v1.2 – PCI DSS v1.1 assessments no longer accepted	1/1/2010

Discover's Merchant Levels and Compliance Requirements:

Level	Description	Compliance Validation Requirements
1	All merchants processing a total of more than 6 million Discover Network card transactions per year Any merchant Discover Network, in its sole discretion, determines should meet the Level 1 compliance validation and reporting requirements All merchants required by another payment brand to validate and report their compliance as a Level 1 merchant	Complete an annual on-site assessment using the PCI DSS Requirements and Security Assessment Procedures. On-site assessment may be performed by a Qualified Security Assessor OR merchant’s internal auditor Complete Quarterly Network Vulnerability Scans performed by an Approved Scanning Vendor
2	All merchants processing a total of 1 million to 6 million Discover Network card transactions per year All merchants required by another payment brand to validate and report their compliance as a Level 2 merchant	Complete an annual self-assessment using the applicable PCI DSS Self-Assessment Questionnaire ("SAQ") Complete Quarterly Network Vulnerability Scans performed by an Approved Scanning Vendor
3	All merchants processing a total of 20,000 to 1 million Discover Network card-not-present only transactions per year All merchants required by another payment brand to validate and report their compliance as a Level 3 merchant	Complete an annual self-assessment using the applicable PCI DSS SAQ Complete Quarterly Network Vulnerability Scans performed by an Approved Scanning Vendor
4	All other merchants	Validation and Reporting Requirements determined by the merchant's acquirer. Annual self-assessment using the applicable PCI DSS SAQ AND Quarterly Network Vulnerability Scans performed by an Approved Scanning Vendor are recommended

 

Service Providers

All service providers that process, store or transmit Discover Network cardholder data are required to report their compliance status to Discover Network on an annual basis. All compliance reports must be submitted by December 31 for the current year.

Assessment	Requirement
On-Site Assessment	Service providers that completed an on-site assessment using PCI DSS v1.2 are required to submit Appendix E of the PCI DSS Requirements and Security Assessment Procedures v1.2: Attestation of Compliance - Service Providers, as well as the Executive Summary of the Report on Compliance (ROC). Discover Network requires service providers that are not fully compliant with the PCI DSS to also complete the "Action Plan for Non-Compliant Status" section of the Attestation of Compliance.
Self-Assessment	Service providers that perform a self-assessment are required to complete PCI DSS Self-Assessment Questionnaire D and submit the Service Provider Version of the Attestation of Compliance. Discover Network requires service providers that are not fully compliant with the PCI DSS to also complete the "Action Plan for Non-Compliant Status" Section of the Attestation of Compliance.

Discover also strongly recommends that service providers and their agents use payment applications that have been validated as compliant with the PCI Payment Application Data Security Standard (PA-DSS).

DISC Home

JCB International

Contact JCB International directly for PCI compliance deadlines.