Manual processes - Fraud Investigation

The goal is to have the most accurate algorithm / rule-set in place that works with the least amount of false positives and negatives possible.

To achieve this, an up-to-date rule-set and properly maintained blacklists are essential. All transactions of fraudulent customers should be marked in the system as declined and with the proper label / fraud reason and all suspected genuine transactions should be marked as approved. There should be the least amount of transactions in the review state as possible.

When you investigate a transaction, the point is to put it in the right state. Approve if you think the customer or its action is legitimate, or if you believe it is a false positive (if the fraud score is high and shouldn't be) or decline if the transaction seems suspicious/fraudulent or it is a false negative (if the fraud score is low and shouldn't be). Review transactions should also be set to the right state.

How to make sure you're looking at a real fraudulent transaction, in case there is a suspicion.

Questions to ask yourself:

• What is the customer action? Trying to purchase an expensive easy re-sellable item? Registering the account to apply for promotions/bonuses? Make sure to first validate if the action is suspicious or not.
• Look at the IP: is it from an unusual country or a strange ISP / using VPN, Web/Public proxy or is the IP type DCH (datacenter)?
• Check the email: no social media profiles, free provider, disposable domain?
• Is there any suspicious ring of people sharing the same IP in some time period of browser hash or cookie hash, maybe address details or some more simple data points?
  •  Look at the behaviour: is the customer trying different cards with different names/ different countries?

Confirmation of fraud cases must be followed with these actions:

• Blacklist directly related data points:
  • User ID
  • Phone number
  • Email address
  • Cookie hash, browser hash - recommended for desktops, and if connected customers are all suspicious
  • IP (recommended for a maximum of 90 days)
• Identify the fraud ring and clones. Mark all transactions of the customer and connected accounts (clones) as declined and assign the right label to it. Make sure to analyse all customers of a suspected fraud ring.
• Create rules to match patterns based on the found clones or connected similar transactions based on indirect related data points, some example data fields to combine: 
  • IP country, IP ISP, IP score > 7
  • BIN number, card issuer bank, card country
  • Useragent, canvas hash, webgl vendor
  • Number of found online profiles, email domain, data breach existence, email score > 7
  • Transaction amounts exceeding a specific limit
  • Item name or type 
• Think about rules that cover fraudulent attempts using parameters from these indirect data points with the highest coverage and least amount of false positives. 
  Rule tester and filtering with statistics information can be very efficient. 
  Make sure to avoid duplication of rules and try to use rule tester and filter functions. 
  Keep an eye of new transactions to turn off unnecessary rules.
• See if any default velocity rules have been triggered, if yes, worth consideration to finetune to uplift score, or copy it to a new rule with more parameters as other suspicious data points from indirect related data points.
  • Contact SEON’s team of experts for more insight and help.

Tip: You'll get the most out of IP lookups if you compare a user's geolocation to their billing and shipping address or information about their bank card. Use the Transaction tab to run checks with multiple data points.

What to do if you think the transactions are legitimate and the score is still high (= false positives)

Questions to ask to determine whether the applied score should be decreased:

• Which rules have applied?
• Is there any rule (especially velocity rules) that makes no sense or seems duplicated?

Note: It can be also useful to create rules, which decrease the fraud score to cover legitimate or low risk patterns. This can be tied to an item name, transaction amount, payment method (e.g. not reversible payment), or in case hard KYC / 3D Secure was passed, etc.