"Introduction to Fraud Prevention" Course Preview: Data Usage Considerations
🎓 FULL "3-in-1 Fraud Prevention, Dispute Resolution, PCI-DSS Masterclass" Course 🎓
https://bit.ly/fraud-dispute-course
Including:
✅ 11.5 hours of video
✅ 112 lessons (with PDF slides + quizzes)
✅ Instructor support with Vasco via message
🎥 ALL Preview Lessons on YouTube (Single Playlist) 🎥
https://bit.ly/fraud-dispute-yt
------
Partial transcript (characters limited):
Let's cover some considerations, in terms of the data usage. Because, just because you have a high-performing fraud monitoring system, doesn't mean that it's going to run well. Data is very important, and enforcing the use of correct data is as well. Let's take a look. Assuming that you have a model-based system, that scores fraud (but even if you have an older, rules-based one), data is crucial.
And, for systems that leverage artificial intelligence, in order to learn, this is even more important. Some guidelines for data usage include: First of all, you have to enforce that fraud scoring is used. What I mean by this is: Fraud scoring is useless if it's not respected. If a transaction is flagged as a 950, for example - which is very high! - but the analyst decides to override the score, then, the fraud monitoring system is pretty much useless. In other words, fraud scoring is not a recommendation. It's something that is sacred, and that analysts must obey. And they can make operational decisions afterwards, but that don't contradict the score. In short, if people don't obey the scores, it's useless to have them in the first place. The second consideration is that scores and reason codes must be recorded. Both the reason codes for chargebacks - for example, the VISA and MasterCard ones - and the fraud scoring must be used and recorded by all team members.
If the previous point was about what an analyst takes in, this point is about what they output. Many analysts are not strict in terms of documenting the reason codes, and the fraud scores, so you end up with fraud cases where there is no documentation! Or at least, that information is not granular enough to use in the future. You have to consider this from an IT point of view. A database point of view. It doesn't matter how good the analyst's intentions are, if the database field is not saved - if the information isn't there - then this case doesn't exist.
The fraud monitoring system will learn nothing from it. This is why recording both the fraud scores and the reason codes is so important. It must be a process, happening in every case, so that the monitoring system can learn from every case. And, finally, fraud data must always be reported. There are some cases where it's not even a matter of the scores, or the reason codes - it's even worse! The actual case is not documented in the system. And this happens for both fraud and just transactions themselves. All transactions, including fraudulent ones, must be recorded. And if there is any database issue, be aware of the faulty or deleted data as well. Document the losses. So, recording fraud data must not be an option, but a mandatory process. Both in terms of what is present, but also, what is missing. Everyone in the team must know exactly what transactions are in the database, and which are missing. Period.
You may think that these guidelines may seem so obvious, and even naive, but you would be surprised at how many institutions don't follow them! You have fraud cases that are not reported, that have missing scores, or there's a system blackout, that doesn't record transaction information for a couple of hours, or even days, and nobody knows about this!! So, for example, maybe the bank uses fraud scoring, but only as a recommendation. So, the analysts are the ones that end up defining how serious a transaction is - including those that have no experience. Or, in many cases, the reason codes are just not recorded. This results in having multiple transactions where the merchant doesn't provide - or can't provide - the documentation, because they don't even know what type of dispute it is in the first place. And if your bank has to do representment with the other bank, that's even worse. That's a problem for you as well.
In many cases, transaction data is not even recorded. Seriously. Sometimes data problems occur, and there is no indication of what data is missing, or how many transactions. This makes historical reviews difficult - or even impossible.
What are some examples of data usage considerations? The first is having absolute trust in the system.The institutions with the highest fraud detection rate assemble a good system, and then put absolute trust into the score. And they leave it be. Analysts should never try to outsmart the system - or override it. Then, recording data and usage of scores and codes should be a systematic process. The only way to make sure that it's always done is to enforce it automatically, as a process, time after time.
And finally, data integrity is another example.