Once my application is accepted, how do I actually start accepting cards?
We work with you through the entire process from application to activation, including the lease or purchase of equipment, programming it to suit your needs, and step-by-step instructions for accepting card payments.
Interchange is the clearing process that card associations such as Visa® and MasterCard® facilitate to settle transactions between banks that issue credit cards and banks or service providers that process card transactions for merchants.
The interchange process makes it possible for customers with credit cards from hundreds of different banks to make purchases at thousands of merchant locations. As part of the interchange process, card associations charge banks or service providers that process card transactions an interchange fee for each transaction.
This fee goes to the cardholder's bank, known as the issuer, as compensation for expenses incurred in providing lines of credit to cardholders. Interchange fees make up a part of your merchant discount rate. The other part of your discount rate—the processing fee—compensates the bank that provides authorization, deposit, and settlement services for your transactions.
How do I find out your prices on point of sale equipment – such as terminals, printers, stackers, etc.?
If you're an existing Bank of America merchant, call your account manager to get pricing information on everything from equipment to value-added services. If you're not currently a Bank of America merchant, complete the online form and include your pricing request in the section labeled "Additional Comments and Questions." A representative will contact you within 1 business day.
What is a chargeback and what do I do if I get one?
A chargeback is a processed credit card transaction that is reversed (charged back) to a merchant because the customer or customer's bank finds something wrong with the transaction.
There are several reasons a transaction can be reversed:
Authorization error—a transaction was allowed even though the authorization was declined
Processing error—incorrect calculation on the sales draft, invalid account number, or expired card
Customer disputes—the customer denies taking part in the transaction, claims purchased merchandise or services were never received and an attempt was already made to resolve the dispute, mail order merchandise was defective, or a promised credit was never processed
If you get a chargeback:
If you're a Bank of America merchant, just follow the steps detailed in your Merchant Guide
If you're not a Bank of America merchant, follow the procedures your processor gave you when you signed up. If you are not able to resolve it to your satisfaction, consider switching to Merchant Card Processing from Bank of America. We provide detailed information on chargebacks, tips on how to avoid them, and instructions on how to handle all common Visa and MasterCard chargebacks.
If you would like a representative to contact you for more information about Merchant Card Processing from Bank of America, go to our online form and complete it as directed.
Why open an online store if I have an existing retail outlet? Won't I be competing with myself?
Selling online offers "brick and mortar" retailers a terrific opportunity to grow their businesses through a cost-effective additional sales channel. Open 7 days a week, 24 hours a day, an online store it is not limited by time or geography. And, electronic commerce offers many new avenues for building a broader customer base.
A chargeback is a transaction returned to the acquirer/merchant from the cardholder's issuing bank. The chargeback cycle is initiated by an issuing bank when it determines, for a given reason, that an account number does not exist or that a transaction presented (posted) to its cardholder's account is in question or is in violation of established credit card processing operating regulations. Before notifying our merchants of a chargeback, we verify that the request is valid and that it has been received within the timeframe defined by the association rules and regulations.
Funds may be deducted from your DDA account for the total amount of the chargeback, plus any applicable processing fees. The chargeback deduction may be reimbursed if you provide proper documentation within the allotted timeframes to remedy the chargeback and the documentation meets the requirements for a reversal/re-presentment. There could still be another chargeback cycle that funds may be deducted (refer to Arbitration chargebacks).
You will need to complete the Chargeback Adjustment Reversal Request form that was mailed to you and attach to it any documentation supporting your case. Please submit by fax or mail as long as it is received by the response date indicated in the chargeback adjustment advice box. Supply a swiped signed sales draft or a signed manual imprint sales draft. Once a chargeback notification has been received, do not issue a credit. You should notify customer service if a credit was issued for the transaction in dispute.
You may fax the form and supporting documentation to 1-800-230-8679 or mail to:
BA Merchant Services Chargebacks/ KY6-200-01-17 P.O. Box 851310 Louisville, KY 40285-1310
A reason code is a two digit number used to identify why a chargeback occurred. Reason codes may vary by VISA, MasterCard and Diners. The reason code is identified on your Chargeback Adjustment Advice. Refer to the list of chargeback reason codes as a reference. Example: Reason code 53 is "Not as described or defective merchandise." This indicates the cardholder purchased an item or service which they were not satisfied with. It is important to address the issue indicated by the reason code and corresponding bank documentation within the time specified. Failure to do so could result in a shorter timeframe to contact you for a response.
An arbitration chargeback is a transaction that has been returned to the acquirer/merchant from the issuing bank/cardholder after it has been represented. The issuing bank is still disputing the chargeback. We will negotiate each arbitration chargeback and attempt an amicable resolution with the issuing bank. If the issuing bank continues their dispute, new information may not be able to be accepted for immediate reversal.
What will happen as a result of an arbitration chargeback?
Funds may be deducted from your DDA account for the total amount of the chargeback, plus any applicable processing fees. This will be determined by the outcome of VISA's or MasterCard's decision to the liable party.
A retrieval request is a request made by the cardholder's bank for a copy of a sales draft. VISA and MasterCard require merchants to fulfill this request within a required timeframe to avoid liability for paying back the sale, due to not providing adequate backup.
What do I need to do in response to a retrieval copy request?
Please return a correct, legible copy of the sales draft referenced, along with the request letter, to the fax number or address below. The sales draft must include: merchant account number, merchant name, address/locator, transaction date, signature (if applicable), expiration date, credit card number, transaction amount and approval/authorization code. If responding to multiple requests via fax transmission, please ensure each sales draft within the transmission is preceded by the appropriate retrieval request letter.
You may fax the form and supporting documentation to 1-800-230-8676 or mail to:
Merchant Services Retrieval Dept/KY6-200-01-30 PO BOX 851310 Louisville, KY 40285-1310
What will happen if I do not respond to the retrieval copy request?
Failure to provide the correct legible copy by the requested date can result in a chargeback for "Non-Receipt of Requested Item." VISA and MasterCard regulations do not allow a reversal of this type of chargeback
Payment Card Industry Data Security Standards (PCI DSS)
General Questions
What is PCI Compliance?
"PCI compliance" refers to compliance with one or more of the Payment Card Industry's (PCI) Security Standards which have been put in place to protect cardholder data against potential compromise. The PCI Security Standards Council (Council) currently maintains three standards:
The PCI Data Security Standard (PCI DSS) is the standard to which merchants and service providers must adhere for the complete protection of cardholder payment data. If a business accepts or processes payment cards, it must comply with the PCI DSS.
The Payment Application-Data Security Standard (PA-DSS) and PIN Entry Device (PED) security requirements support the overall implementation of PCI DSS by allowing merchants to choose from PCI l certified payment applications and PIN entry devices to further cardholder data security.
Cardholder data is defined for the purposes of PCI DSS compliance as any personally identifiable data associated with a cardholder, including the Primary Account Number (PAN), expiration date, customer name, and service code. PCI DSS requirements are applicable if a PAN is stored, processed, or transmitted.
See the PCI DSS table, below, for guidance on which data elements may or may not stored:
Data Element
Storage Permitted
Protection Required
PCI DSS Req 3.4
Cardholder Data
Primary Account Number (PAN)
Yes
Yes
Yes
Cardholder Name*
Yes
Yes*
No
Service Code*
Yes
Yes*
No
Expiration Date*
Yes
Yes*
No
Sensitive Authentication Data**
Full Magnetic Stripe
No
n/a
n/a
CVC2/CVV2/CID
No
n/a
n/a
PIN/PIN Block
No
n/a
n/a
* These data elements must be protected if stored in conjunction with the PAN. This protection must be consistent with PCI DSS requirements for general protection of the cardholder environment. Additionally, other legislation (for example, related to consumer personal data protection, privacy, identity theft, or data security) may require specific protection of this data or proper disclosure of a company's practices if consumer related personal data is being collected during the course of business. PCI DSS, however, does not apply if PANs are not stored, processed, or transmitted. **Sensitive authentication data must not be stored subsequent to authorization (even if encrypted).
Full magnetic stripe data, also called "track" data, and other sensitive authentication data (see table below) are used during the transaction authorization process, but, per PCI DSS Requirement 3.2 must never be retained by you or your service providers subsequent to transaction authorization, even if encrypted. In addition to this PCI DSS requirement, the Visa and MasterCard Operating Regulations prohibit storage of the contents of a card's magnetic stripe data as a unit.
See PCI DSS table, below, for guidance on which data elements may or may not be stored:
Data Element
Storage Permitted
Protection Required
PCI DSS Req 3.4
Cardholder Data
Primary Account Number (PAN)
Yes
Yes
Yes
Cardholder Name*
Yes
Yes*
No
Service Code*
Yes
Yes*
No
Expiration Date*
Yes
Yes*
No
Sensitive Authentication Data**
Full Magnetic Stripe
No
n/a
n/a
CVC2/CVV2/CID
No
n/a
n/a
PIN/PIN Block
No
n/a
n/a
* These data elements must be protected if stored in conjunction with the PAN. This protection must be consistent with PCI DSS requirements for general protection of the cardholder environment. Additionally, other legislation (for example, related to consumer personal data protection, privacy, identity theft, or data security) may require specific protection of this data or proper disclosure of a company's practices if consumer related personal data is being collected during the course of business. PCI DSS, however, does not apply if PANs are not stored, processed, or transmitted. **Sensitive authentication data must not be stored subsequent to authorization (even if encrypted).
Is it acceptable to store card verification values, or PIN and PIN block data?
It is never acceptable for acquirers, merchants, or service providers to retain card verification values, such as CAV2, CVV2, CVC2, or CID numbers, or PIN or PIN block data subsequent to transaction authorization.
The Visa & MasterCard Operating Regulations prohibit such storage, whether encrypted or unencrypted.
Vulnerable third-party payment applications are currently the leading cause of data compromise incidents, particularly for small merchants. Merchants and agents that use payment applications that store prohibited data or have inherent security weaknesses will not be compliant with the PCI DSS and are at high risk of being compromised.
All payment applications must not violate the PCI DSS requirements, but the Card Organizations have additional security requirements called the Payment Application Data Security Standard (PA-DSS) that apply to third party payment applications. Third party payment application software refers to "off the shelf" applications on a merchant's PC, point of sale (POS) system, or other card payment processing systems, e.g. Micros®, Radiant Systems®, HotSauce Technologies®.
It does NOT include:
Stand alone, or "dumb" terminals (such as the Hypercom® T7Plus®, or Verifone® Omni series) that do not provide information to merchants' systems accessible directly or indirectly through the Internet. However, terminals, including dumb terminals have their own security requirements.
In-house applications, i.e. custom-coded for the merchant, or distributed only to captive corporate or franchisee locations. However these applications may not violate the PCI DSS.
Operating systems (e.g. Microsoft Windows®), database systems (e.g. Oracle®), or back office systems which store card data for reporting or customer service purposes but do not process card payment transactions. However, these systems may not retain prohibited Cardholder Data.
Fully hosted payment applications used by the merchant as a service, e.g. Authorize.net's Simple Checkout® hosted payment form, or Cybersource®'s hosted e-Commerce payment fields
Even if a merchant does not offer Internet-based transactions, other services can make systems internet accessible and more vulnerable to data compromise. Basic functions such as e-mail and employee Internet access can result in Internet-accessibility to a company's network and Cardholder Data. These seemingly insignificant paths to and from the Internet can provide unprotected pathways into merchant and service provider systems if not properly controlled.
How can I find out which payment applications are PA-DSS compliant; or which versions are vulnerable to compromise and must be upgraded or replaced?
A list of compliant or validated payment application versions can be found on Visa's website, www.visa.com/pabp. The vulnerable payment application list contains sensitive information and cannot be posted to a public website. If you are a Bank of America merchant, please contact your merchant customer support service number (either on this website, or the number printed on your monthly statement) to request this information.
PA-DSS = Payment Application Data Security Standard maintained by the PCI Security Standards CouncilPASM = Visa's Payment Application Security MandatesPABP = Payment Application Best Practices; the old name for PA-DSS
To address the critical issue of payment application security, in 2005 Visa created the Payment Application Best Practices (PABP) requirements to ensure vendors provide products which support merchants' efforts to maintain PCI DSS compliance and eliminate the storage of sensitive cardholder data. Read more at www.visa.com/pabp.
In April 2008, Visa's PABP requirements were replaced by a new industry-wide standard, the Payment Card Industry Payment Application Data Security Standard ( PA-DSS), version 1.1.
The Payment Card Industry Security Standards Council (PCI SSC) will maintain the PA-DSS and administer a program to validate payment applications' compliance against this standard. In the future, the PCI SSC will begin to publish and maintain a list of PA-DSS validated applications, to replace Visa's PABP validated application list. For more information about the PA-DSS and the transition from PABP to PA-DSS, click here.
On October 1, 2008, Bank of America implemented Phase III of Visa's mandates, the third of five phases aimed at moving all merchants using third party payment applications to use PA-DSS compliant, i.e. secure, applications to guard against cardholder data compromises. Other phases include:
VISA MANDATE PHASE
DEADLINE
1. New PCI Level 4 merchants (including new locations of existing relationships) may not use vulnerable payment application versions – those that store prohibited cardholder data.
January. 1, 2008
3. New PCI Level 4 merchants using third-party payment software must be either PCI DSS-compliant or use PA-DSS validated compliant payment applications.
October. 1, 2008
5. ALL PCI Level 4 merchants (new and existing) using third-party software must use validated applications.
Do I need to comply with the PCI DSS (and Visa CISP and MasterCard SDP)?
Yes. Visa®, MasterCard® and other major card brands require all card accepting merchants to comply with this industry standard, regardless of acceptance channel, processing method, or annual transaction volume.
Visa's Cardholder Information Security Program (CISP, www.visa.com/cisp) and MasterCard's Site Data Protection Program (SDP, www.mastercard.com/sdp) contain PCI DSS compliance requirements.
In addition to mandatory card brand requirements, customers expect you to keep their cardholder account data safe. Complying with the PCI DSS helps you meet this basic expectation.
When is the deadline for merchants to be PCI DSS compliant?
You can't benefit from a deadline for compliance, because all card accepting merchants are required to be PCI DSS compliant at all times, as required by the major card brands.
There are, however, deadlines for certain merchants to validate, i.e. prove, that they are compliant, which vary depending on the merchant's PCI Level. For more information on these deadlines, see the FAQ for "When is the deadline for merchants to validate compliance?"
What is the difference between PCI DSS compliance and validation?
Being compliant means you are handling cardholder data in accordance with PCI DSS requirements. The major card brands require all card accepting merchants to be PCI DSS compliant at all times.
Validating compliance means proving you are compliant. Your validation requirements, deadlines and penalties for non-compliance will vary depending on your PCI Level.
PCI Level 1-3 merchants are required by the major card brands to validate PCI DSS compliance according to a specified schedule. Level 1-3 merchants must also revalidate compliance annually after initial validation. Visa's Compliance Acceleration Program (CAP) features incentives and sanctions to enforce compliance with validation requirements for Level 1 and 2 merchants.
PCI Level 4 merchants currently are not required to submit PCI compliance validation documentation to Bank of America. However, you may be asked for it at any time. Failure to prove PCI DSS compliance could require you to reimburse us for fines and losses from the card organizations and card issuers should your business experience a data compromise.
If you do not comply with the PCI DSS, your business may face significant financial and reputational risks.
If your cardholder data is compromised, you could be required to reimburse us for card brand fines ranging up to $500,000 per incident, as well as subsequent fraud losses incurred by card issuers resulting from the compromised card data, which may exceed fine amounts.
In addition to financial risk, a compromise incident can negatively impact your company's reputation and your relationship with your customers, especially if the compromise results in fraudulent charges on their account, their account being blocked or their payment cards needing replacement.
PCI Level 1 and 2 merchants may also face non-compliance fines assessed by Visa; see below for more details.
You become PCI DSS compliant by meeting all applicable PCI DSS requirements.
As a first step, you should become familiar with the 12, "digital dozen", PCI DSS requirements. This will help you determine which requirements apply to your business.
If you are a PCI Level 2-4 merchant, you should then select and review the correct Self Assessment Questionnaire (SAQ) for your business. The questions in your SAQ will help you remain focused on meeting the requirements most applicable to your business.
Once you understand the requirements that apply to your business, review the Get Started with PCI DSS document, which explains the remaining steps to become and remain compliant:
Assess your cardholder data processing environment to identify any security gaps that do not meet PCI DSS requirements;
Remediate these gaps by making the appropriate changes to your processing environment or security policies;
Report your compliance status by completing the validation steps that apply to your business
Do I need to hire a Qualified Security Assessor (QSA) or Approved Scanning Vendor (ASV) to become compliant?
While it will be necessary for many merchants to use an ASV to validate that they are compliant with the PCI DSS, merchants are not required to use a QSA or ASV in order to be compliant with the Standard.
However, some merchants, especially those with large or complex card processing environments, may choose to hire an outside firm, such as a QSA or ASV, to help assess and remediate their systems and business processes to meet PCI DSS requirements.
How much time and expense will it take for me to become compliant?
The time and cost of becoming and validating PCI DSS compliance will likely vary based on a number of factors, including the scale, complexity, and security of your cardholder data environment.
How can I minimize the time and expense needed to become compliant?
Merchants can take several steps to minimize the time and resources needed to become PCI DSS compliant, including:
Read the PCI DSS's "digital dozen" requirements and applicable sub-requirements, and review the Self-Assessment Questionnaire (SAQ). Doing this will help you understand which requirements do, or do not apply to your business, which may save you valuable time and resources by avoiding unnecessary investments in addressing non-applicable requirements.
When purchasing new or replacement card payment processing solutions, consider those which eliminate or limit the extent of cardholder account data in your possession. These solutions can significantly reduce the number and scope of PCI DSS requirements you must meet, thus reducing the time and cost required to comply with PCI DSS and potentially reducing your risk of experiencing a data compromise.
For example, merchants with e-Commerce operations should consider using a hosted payment page, or hosted payment fields from a PCI DSS compliant service provider (see Visa and MasterCard lists of compliant providers).
When purchasing new or replacement card payment processing equipment, select PCI Approved PIN Entry Devices (PEDs) from the PCI Approved PED list and payment application software from Visa's Validated list (go to www.visa.com/pabp and select "Validated Payment Applications" on right hand menu). These industry approved devices and software are validated against PCI security standards that align with and support merchant efforts to become PCI DSS compliant.
If your card payment processing environment is more extensive than a single, standalone terminal or POS device, you may be able to limit the scope of your cardholder data environment and associated PCI DSS requirements, which in turn may reduce the time and cost required to comply with the PCI DSS, by taking the following steps:
Understand the flow of cardholder data through your network and business processes;
Evaluate whether cardholder data is necessary for each identified network component or business process to perform its proper function;
Eliminate cardholder data from network components or business processes which do not require cardholder data in order to perform their proper functions;
Consolidate cardholder data to be processed, stored, or transmitted only by required network components or business processes;
Use proper network segmentation, where feasible, to isolate the areas of your network which process, store, or transmit cardholder data – doing this can help limit the scope of PCI DSS requirements that apply to your business.
I use a PCI compliant terminal, POS system, or payment application – does that make me PCI DSS compliant?
No, though using PCI compliant devices and software is certainly a good first step towards complying with the PCI DSS.
The term "PCI compliant", when used to describe a specific device or software application, is likely referring to that device or software complying with either the PCI PIN Entry Device (PED) standard or Payment Application-Data Security Standard (PA-DSS), respectively.
These standards support, but do not satisfy merchants' efforts to comply with the PCI DSS by allowing them to choose from PCI certified payment application software and PIN entry devices.
Even if a merchant uses PCI compliant devices or software, it must still actively comply with PCI DSS requirements covering the physical security of cardholder data (Requirement 9) and the need for merchants to maintain an information security policy (Requirement 12).
I use a PCI DSS compliant service provider – does that make me PCI DSS compliant?
No, though using a PCI DSS compliant service provider may simplify your efforts to become and remain PCI DSS compliant. You remain responsible for compliance by your Service Providers who access cardholder data ion your behalf.
If you have outsourced all card payment processing to a PCI DSS compliant service provider and you do not store, process, or transmit any cardholder data either physically or electronically, you must still meet various PCI DSS requirements including:
Establish and implement a security policy (Requirements 12.1-12.6)
Require your service provider(s) to take responsibility for the security of the cardholder data and handle it in accordance with PCI DSS requirements (Requirement 12.8)
Does being PCI DSS compliant ensure I will not experience a data compromise?
No. Unfortunately, criminals are always finding new ways to compromise cardholder data. Complying with the PCI DSS will ensure you meet a baseline level of security practices, which will reduce, but not eliminate, your risk of a data compromise.
Depending on your processing environment, it may also be advisable to implement security measures "beyond" PCI DSS compliance.
Should I consider security measures which go "beyond" PCI DSS compliance?
Yes – especially if you are a large merchant, or possess a complex card processing environment.
You, the merchant, are ultimately responsible for the security of cardholder data in your possession or processed on your behalf. Hence, you should evaluate the security, not just the PCI DSS compliance status, of your cardholder data environment.
Assessing your cardholder data environment from a security and risk management perspective, as opposed to a compliance-only mindset, may lead you to identify risks and implement countermeasures which exceed the baseline requirements contained in the PCI DSS.
No. Compliance with the PCI DSS should be built into the way you do business; it is not a one-time event. The major card brands, including Visa and MasterCard, require merchants to comply with PCI DSS requirements at all times.
While merchants validate PCI DSS compliance once per year, merchants must maintain PCI DSS compliance all year round.
1 – Quarterly network scans apply to merchants whose card processing environments are directly or indirectly connected to the Internet. These scans must be performed by an Approved Scanning Vendor (ASV), as specified by the PCI Security Standards Council. Preferred pricing for these scans is available for Level 1-3 merchants via Security Metrics (www.SecurityMetrics.com or 1.801.705.5656 - request Bank of America rate), and Level 4 merchants via Trustwave (www.bankofamerica.com/trustkeeper, coupon code BA3REF, or call 888.878.7817).
As documented by the major card brands, all card-accepting merchants regardless of acceptance channel (in-person, mail, telephone, e-Commerce) will fall into one of the four merchant PCI levels based on card transaction volume over a 12-month period:
PCI Level
Annual Number of Transactions (Visa® or MC®)*
e-Commerce
All Channels Combined (e-Commerce, retail, phone, mail, etc.)
1
n/a
6,000,000 or more
2
n/a
1,000,000 - up to 6,000,000
3
20,000 or more
Under 1,000,000
4
Under 20,000
Under 1,000,000
* Use the greater of Visa OR MasterCard annual transaction totals for your business. Do not use a combined figure.
Use the following questions and the table, above, to calculate your PCI Level:
1.Does your business have multiple store locations or merchant ID's?
2.If no, use the table, above, to calculate your PCI Level
3.If yes, use the following criteria to determine how to aggregate transaction volumes, then use the table, above, to calculate PCI Level:
a)If your company owns multiple store locations using a common doing-business-as (DBA) name, combine the number of annual transactions across all these locations and use the table, above, to calculate PCI Level.
– Note for franchises:
PCI Level must be determined separately for the franchise corporation, which must combine the annual transaction volume of cardholder data stored, processed, or transmitted itself or on behalf of any of its corporate or independently owned stores, including the volume of cardholder account data available to the corporation via reporting tools;
AS WELL AS for each independently owned store or group of stores.
b)If your company owns multiple store locations or merchant ID's with different DBA names, review the two options, below, and select the option that best describes your business:
All store locations or merchant ID's process card payments independently on separate technology platforms and the cardholder data from their transactions is never shared or aggregated in any way by your company. If your company fits this description, use each location's transaction volume to determine PCI Level using the table, below. Each entity will need to validate compliance independently. If you would like to simplify your stores' compliance validation process, see FAQ "Can I use a single set of compliance validation documents for multiple merchant entities?"
Some store locations or merchant ID's use a common processing platform, or otherwise share or aggregate cardholder data. If your company fits this description, combine the annual transaction volume of all locations and merchant ID's whose transactions are stored, processed, or transmitted via a common, company owned or operated technology platform, then use the table, below, to calculate PCI Level of each resulting entity. Examples of multiple store locations or merchant ID's whose transaction volumes should be combined include, but are not limited to:
– a business using multiple merchant IDs on a single point-of-sale (POS) terminal;
– multiple store locations or merchant IDs transmitting card transactions or transaction reports containing cardholder data to a corporate parent via a common, company owned or operated branch server or network;
– An e-Commerce company with multiple websites and merchant ID's hosted on a common server(s) or network with no logical or physical segmentation between sites.
Using the above criteria, some companies may possess multiple merchant entities with different PCI Levels, which will each need to validate compliance independently. If your company fits this description and would like to simplify your compliance validation process, see FAQ "Can I use a single set of compliance validation documents for multiple merchant entities?"
When is the deadline for merchants to validate PCI DSS compliance?
Compliance validation deadlines vary depending on your PCI Level. PCI Level 1-3 merchants have specific validation deadlines based on the date on which their level was identified by their acquirer and reported to Visa.
Includes merchants previously identified by Visa (including those coming to Bank of America from another acquirer)
In addition to meeting their initial PCI compliance validation deadline, these merchants will be required to revalidate annually
Revalidation documentation (forms) will be due 12 months after:
The "as of" date on a ROC for Level 1 merchants
The "completion" date marked on the SAQ for Level 2 merchants (Attestation of Compliance section, Part 3).
Merchants "Newly Identified" as PCI Level 1 or 2 by Visa (after June 30, 2008)
Includes Level 1 or 2 merchants not previously identified as such by Visa
Includes Level 3 or 4 merchants whose transaction volume growth results in reclassification as a Level 1 or 2 merchant by Visa
The date they are identified by Visa will determine their initial deadlines to attest they are not storing prohibited data (through a PDRA form) and validate PCI compliance, as shown here for the calendar year 2009:
Merchant Level
Date Identified by Visa
Deadline to Attest Merchant is NOT Storing Prohibited Data
Initial PCI Compliance Validation Deadline
1
Prior to June 30, 2009
March 31, 2010
September 30, 2010
1
After June 30, 2009
March 31, 2011
September 30, 2011
2
Prior to June 30, 2009
March 31, 2010
December 31, 2010
2
After June 30, 2009
March 31, 2011
December 31, 2011
Following the first validation for these merchants, Level 1-2 merchants must revalidate PCI compliance each year. Revalidation documentation (forms) will be due 12 months after:
The "as of" date on a ROC for Level 1 merchants
The "completion" date marked on the SAQ for Level 2 merchants (Attestation of Compliance section, Part 3).
Merchants Classified as PCI Level 3 – Level 3 merchants must validate compliance with the PCI DSS 12 months from the date on which their PCI level was first identified by Bank of America, or by the merchant's previous acquirer, and reported to Visa.
No validation deadline has been set for PCI Level 4 merchants. However, Level 4 merchants must be PCI DSS compliant at all times and must be prepared to provide validation documentation (i.e. proof of compliance) to Bank of America upon request.
Do I need to complete a Self-Assessment Questionnaire (SAQ)?
PCI Level 1 Merchants – No, you or your Qualified Security Assessor (QSA) will complete a Report on Compliance.
PCI Level 2-3 Merchants – Yes, you must complete an SAQ in order to validate compliance.
PCI Level 4 Merchants – in order to validate compliance, you must complete an SAQ. PCI Level 4 merchants currently are not required to submit PCI compliance validation documentation to Bank of America. However, you may be asked for it at any time. Failure to prove PCI DSS compliance could require you to reimburse us for fines and losses from the card organizations and card issuers should your business experience a data compromise.
The SAQ may also be completed online via many PCI Qualified Security Assessors (QSA's) and Approved Scanning Vendors (ASV's), which provide PCI DSS compliance validation services to merchants.
For PCI Level 1-3 merchants, Bank of America has secured preferred pricing with Security Metrics, a QSA and ASV (www.SecurityMetrics.com or 1.801.705.5656 - request Bank of America rate).
For PCI Level 4 merchants, Bank of America has secured preferred pricing with Trustwave, a QSA and ASV (www.bankofamerica.com/trustkeeper, coupon code BA3REF, or call 888.878.7817).
How do I select the right Self-Assessment Questionnaire (SAQ) for my business?
Please refer to the PCI Security Standards Council's SAQ selection table, below.
SAQ Validation Type
Description
SAQ: Select the appropriate link below.
1
Card-not-present (e-commerce or mail/telephone-order) merchants, all cardholder data functions outsourced. This would never apply to face-to-face merchants.
Can I use a single set of compliance validation documents for multiple merchant entities?
You may use a single set of compliance validation documents (i.e. a single ROC or SAQ, and scan report) to cover all entities. Note, however, that you must specifically list all covered entities in the ROC or SAQ, and that if you use this consolidated documentation approach, a single non-compliant entity will prevent all entities from successfully validating compliance until that non-compliant entity becomes compliant.
A network security scan involves an automated tool that checks your systems or your service providers' systems for vulnerabilities. The tool conducts a non-intrusive scan to remotely review networks and Web applications based on the internet-facing Internet Protocol (IP) addresses provided by you or your service provider. The scan will identify vulnerabilities in operating systems, services, and devices that could be used by hackers to breach your cardholder data environment and potentially compromise cardholder data.
Scans should be performed by an Approved Scanning Vendor (ASV), a list of which can be found here.
For PCI Level 1-3 merchants, Bank of America has secured preferred pricing with Security Metrics, a QSA and ASV (www.SecurityMetrics.com or 1.801.705.5656 - request Bank of America rate).
For PCI Level 4 merchants, Bank of America has secured preferred pricing with Trustwave, a QSA and ASV (www.bankofamerica.com/trustkeeper, coupon code BA3REF, or call 888.878.7817).
The network security scan is applicable to any merchant who processes, stores, or transmits cardholder data AND whose card holder data environment is connected, directly or indirectly, to the internet.
Even if an entity does not offer web-based transactions, there are other services that make systems internet accessible. Basic functions such as e-mail and employee Internet access will result in the Internet-accessibility of a company's network. These seemingly insignificant paths to and from the Internet can provide unprotected pathways into merchant and service provider systems if not properly controlled.
What happens if I fail to validate PCI DSS compliance?
Non-compliance fines for Level 1 and 2 merchants were announced through Visa's Compliance Acceleration Program (CAP) in December 2006. Since then, it has been renewed and applied to waves of merchant populations, requiring merchants to discontinue storing track, CVV2 and PIN data in card processing, as well as validate full compliance in order to avoid reimbursement by merchants for fines and risk of data compromise. The PCI CAP expands Visa's enforcement efforts to include acquirer fines for these merchants that are delinquent by not validating full PCI DSS compliance by each September 30 (Level 1) or December 31 (Level 2), respectively.
If PCI Level 1 and 2 merchants fail to meet their PCI DSS deadlines, the following may result:
Reimbursement for fines levied by the Card Organizations (as of 2007-2008, $25,000 per month for PCI Level 1 merchants; $5,000 per month for PCI Level 2's). These fines also apply for merchants who do not revalidate annually as required.
Disqualification from benefits of tiered interchange rates
Liability for fraud losses and expenses incurred by issuing banks
Brand reputation risk and inconvenience to their business
Failure to eliminate track data storage may also result in reimbursement for the following fines assessed by month:
(As of 2007-2008, for PCI Level 1's) –
Time Period
Monthly Fines
Month 1-3
$10,000
Month 4-6
$50,000
Month 7 and Subsequent
$100,000
(As of 2007-2008, for PCI Level 2's) –
Time Period
Monthly Fines
Month 1-3
$5,000
Month 4-6
$25,000
Month 7 and Subsequent
$50,000
More potential repercussions may also apply if a merchant does not comply with the PCI DSS. The Card Organizations reserve the right to levy fines for non-compliance at any time.
PCI Level 3 merchants who fail to complete their PCI DSS compliance validation process within one year after becoming Level 3 may also be required to reimburse Bank of America for an initial assessment for non compliance of $5,000, subject to escalation, as determined by MasterCard rules.
PA-DSS = Payment Application Data Security Standard maintained by the PCI Security Standards Council