Hey there Hmm 100,000 unique PANs is too much for a where clause. Do those PANs have something in common in the other fields in that Prognosis record that you can use in the where clause? Or another field you can bring in from the source data?
If you need further assistance make sure to open a Support case so that our team can consider in more depth. HTH
A couple things to consider: 1) Prognosis by default, unless you have changed the configuration, does not store the full PAN. We only show the first 6 and last 4 digits of the PAN. This is for general security and compliance with PCI. Changing this setting will bring your Prognosis infrastructure into the scope of PCI and is not recommended to be done adhoc and only be done under specific deployment conditions. 2) It sounds like you are trying to use the functions within TSV configuration. The TSV configuration allows you to essentially flag transactions based on very specific criteria and puts them in the "Transaction Exception" record when there is a hit and a label with what rule it was flagged for. You would NOT want to create a rule on an entire BIN range by itself. Though if you are looking at a specific BIN range under a specific set of circumstances so any rule is only hitting far less than 1% of your transactions then maybe that is something to consider using to generate a list. If you have a small list of very specific pans you can also put them in this configuration for flagging as a watchlist but TSV is not really designed to be a HOTCARD system will thousands or hundreds of thousands of pans. Out of the box displays then provide a list of any transaction flagged by the TSV rules. You have this functionality if you have TSV in your license. 3) Your payment switch or the system it offloads transactions is more suited to generating a list of ALL transactions that occurred on a BIN, though technically this and full transaction search is technically possible with Prognosis plus Prognosis Business Insight/Reporting.
If my answer helped you today, please be sure to mark the resolved button to assist others.
Christopher R Souser - Sr. Services Solution Engineer, Payments & Infrastructure – MSci. PA, CISSP, ITIL.
I've already followed this up with you but for the benefit of people searching this topic, this could be achieved in TSV (Transaction Surveillance) using a card list.
To use a card list, you need to include a LIST-LOC entry into your card rule. This tells TSV where to look for the card list. (i.e. NonStop subvolume to look in) The actual card list can be in one or more files in the subvolume. The file(s) must be named TSVLxxxx, where xxxx can be any four characters.
Once LIST-LOC is specified, the rule is restricted to only match PANs in the list(s) found in LIST-LOC. (i.e. your set of cards) Since you want to match any of the cards, your rule can be very simple, with just a ‘WHERE ALL’ where clause. (or you could make more complex rules that matched the card list when other conditions are met)
Full details in the Prognosis Online Help sections: ' Prognosis for Payments > ACI BASE24 and BASE24-eps > Transaction Surveillance > Setting Rules > Rules Syntax' and 'Prognosis for Payments > ACI BASE24 and BASE24-eps > Transaction Surveillance > Setting Rules > Rule Examples' (Card Exception List paragraph)
Note, that as Christopher touches on above, performance will need to be tested and benchmarked first when using that many cards in the list. You should do this using a transaction rate similar to the maximum expected in production. There should, however, be no problem with masked PANs (although they would need to be in the clear in the card list) as this processing is done prior to masking in the collector.