Answer:
No, it does not quite work that way. The PAN is typically not masked in the reader, it is masked in the TSV collector, after TSV rules and PAN lists are applied.
So in short unmasked PAN lists are still usable using the LIST-LOC parameter, independent of PAN masking.
There are a few primary challenges today with using this parameter though:
1) The biggest challenge of doing this though, is that you must apply adequate controls on your PAN list sitting on your system unencrypted in a plain text file.. which to be thorough PCI does not allow you to do unless you put appropriate access controls and monitoring on it. This included File Integrity Monitor (FIM) and ensuring only processes/user that are allowed read only access to it are allowed via systematic controls with auditing to start. These controls are important because we have seen these lists have a few PANs in a file and we have seen tens of thousands of PANs in them. Alternatively though if Prognosis is receiving a Tokenized PAN and not the true PAN in the first place.. these additional controls may not be neccessary on the Tokenized Pan list specified in the LIST-LOC parameter.. but to be clear TSV will not bridge Tokenized / Untokenized PANs.
2) There are exceptions to this answer such as with Postilion & Base24eps IBM or Linux where we receive transactions over a Realtime TCPIP Feed (where the PAN is masked before it gets to prognosis), or where the Payment System either masks, encrypts or tokenizes the PAN at source in the data made available to Prognosis. This is common in Financial Transaction Manager (FTM) solutions where we read a trace or another data source..but if it is made available the above answer will stil be applicable.
3) Then with both challenge your data must be an exact match to the source data Prognosis is receiving. In the case of having masked data if you give it a LIST-LOC file that is masked to avoid putting these controls in place.. then it will not match a masked PAN to a unmasked PAN, as it goes for an exact match. In the case of the source being masked you still can use the LIST-LOC in the TSV rules, but yes you then must use a MASKED pan that matches the Prognosis source (not your TSV setting) to get a match as it looks for an exact match. Like with any masked data situation you will then get some false positives due to the lack of uniqueness usually associated with First 6 Last 4 masking on a 16-19 digit pan.
A few other related answers related to the LIST-LOC parameter in Transaction Surveillence (TSV)?
Q2) Can it read an existing Negative File in Base24
A2) No, it just reads plain text files, and the transactions would be flagged by the system with response code anyway if they were in the NEG file.
Q3) Can we point it to an encrypted file?
A3) No, not unless there is some underlying decryption that goes that as far as Prognosis is concerned it is unencrypted.
Q4) Can we point it to a HotCard List in our Fraud System?
A4) No, not unless it is located in plain text on the same system (or via Nonstop Expand). We cannot get it over the network. Though you can schedule most of these fraud systems to export that Hotcard list out to plain text format.
Q5) Does Prognosis provide an editor for the TSV rules off the Payments system or the LIST-LOC file?
A5) No there is not rules editor, but we are aware of the common request and there is a roadmap item for it but it has not been specifically scheduled but this will likely not include a generic text editor to edit the path defined in a LIST-LOC.
If my answer helped you today, please be sure to mark the resolved button to assist others.
Christopher R Souser - Solution Architect – MSci. PA, CISSP, ITIL.
