We think a properly-designed card processing system should store the last
four digits in a physical file on the local system for access from RPG or
anything. Also, a good design would not use 'Auth Network' Tokenization
service (like TSYS TransArmor), in favor of its own tokenization. This
allows cards on file to be retained if the merchant moves from one network
to another (i.e. First Data to TSYS). In addition, the entire transaction
data set in the transaction Data Structure should be in the local record in
the Physical File, so ALL of the details are available to ERP apps and
queries. And, a good system should support plenty of "User-Defined" fields
that can contain anything you choose to help identify more about the
transaction.
The first 6 digits of the card number are the BIN identifying the bank that
issued to card. The PCI allows for the inclusion of that first 6 digits
with the last 4 for greater identification ability. Some payment
application companies will choose to NOT display or store the first 6, as
providing 10 digits in readable form for card numbers is giving away 5/8ths
of the card data. Personally, I think that is more risk than is necessary,
and in many hundreds of installations, I have found all business use cases
are satisfied with the last 4 and other associated fields.
The exception to this is EMV transactions from an EMV terminal that always
return a token from the auth network. A properly-designed commercial
payment app would allow those tokens for EMV to be used, also, for phone
orders and e-commerce.
Remember, all, "storage" of credit card data is NOT the only issue, you are
"IN" PCI scope if you "process" or "transmit" it. The word "process" means
to "touch" the data, even just in transit. If it is keyed into a
workstation on the LAN, EVERY device on the LAN is now in scope, all
workstations, servers, AS/400s, switches, everything. That is a BIG audit
to perform. If that is the case, you would be required to complete the
ponderous (Self-Assessment Questionnaire) SAQ "D" that has over 500
questions and can take weeks or months to complete. The goal should be to
qualify for the WAY easier SAQ C/VT that has less than 50 probing
questions. This is particularly applicable to phone orders, as e-commerce
and retail are covered under other SAQs (SAQ A and SAQ P2PE-HW
respectively). So you can be "complicant touching the card data so long as
you complete the appropriate SAQ.
To qualify for way more desirable SAQ C/VT requires your entire
infrastructure to be out of scope and not "store, process or transmit"
credit card data. A well-designed commercial Payment Application can
accomplish that, resulting in less exposure to bad actors and better
security. If done with seamless integration to native IBM i apps, this
would be the ideal combination of security and operational efficiency!
*Ira Chandler, PCI QIR*
*CTO, Curbstone CorporationTechnical Services - 888-844-8533*
*
https://curbstone.com/email_disclaimer
<
https://curbstone.com/email_disclaimer>*
midrange.com
