Identifying good customers in rejected transactions is half the battle, they say. Basic risk assessment rules typically place customers into two groups – good (thumbs up) and bad (thumbs down).
Layering machine learning risk assessment intelligence into a fraud platform can tell you more about the good customers that you are leaving behind. But how can you use that intelligence to increase the approval rates of your customers in the future?
A cherry-picking exercise certainly would not be the most efficient or effective approach, but there are systematic options that you could consider to more confidently place your good customers into the right group and leave the fraudsters behind.
Previously, we discussed how to use third-party data to identify which customers are likely to trigger a false decline by looking at historical patterns. The trouble is, customers were rejected for a particular reason. Simply trusting that those that appeared to be good based on correlations to accepted transactions might be too big of a leap of faith for companies that are risk-averse. In this blog, we will discuss how to test historical findings in a live production environment.
A Low-Risk Way to Prove It Out
Step 0: Look back historically to identify decent accept criteria
The first step is to find a low-risk group in rejected transactions to begin accepting. For ideas on how to do this, see blog 2. For this experiment, we found that when Confidence Score < 300 and Identity Network Score < 0.6, we may accept customers who were previously rejected.
Step 1: Start by reviewing
Many merchants have agents whose sole job is to manually review transactions. If you have access to a senior agent who does reviews, you can use this team to validate third-party findings.
First, begin by running all the rejected transactions through the third-party API in real-time, but do not yet allow the API to influence outcomes.
Then, take an equal sample of rejected transactions that passed the third-party criteria (e.g. 2,000 transactions with a low confidence score and low identity network score) and those that did not (e.g. 2,000 transactions with a high confidence score and low identity network score).
From there, ask the manual review agents to review these transactions (e.g. 4,000 transactions), but do not tell them which passed the third-party acceptance criteria. Taking the labels from the manual review agents, compare them to those that did and did not meet the third-party acceptance criteria.
If those that meet the criteria were deemed to be bad at a lower rate than those that did not meet the criteria, then we have more evidence to move forward.
Step 2: Let a small percentage through
Now that we have some more supporting evidence, we might have the confidence to implement the new acceptance criteria in real-time (to reduce false declines). At this point, many still feel nervous about letting too many through. An alternative to letting everything through is allowing a percentage of the rejections through that met the acceptance criteria.
The proportion needs to be high enough to get a significant number of transactions through, but small enough to keep risk low. We can use the historical test to help figure out what that number should be. In our previous example, we were rejecting 10,000 transactions a month, and 20% (or 2,000) met the acceptance criteria of low confidence score and low network score. If you want to let no more than 500 rejected transactions through, it might be good to say that we will let through every fourth (or 25%) that meet the acceptance criteria.
Step 3: Age and monitor
After some amount of time, the portion of transactions that would have been rejected will begin to mature. Typically, it takes 90 days to be sure that all transactions that will become chargebacks have done so. However, you do not have to wait the full 90 days to begin the inspection. A large percentage of chargebacks will have a dispute label within a few days, so you can begin comparing that to the non-rejected transactions sooner.
The chargebacks among the newly accepted population will probably be higher than that of the normal population. However, the question that should be asked is, “is this low enough?”
Step 4: Increase the percentage
If the risk from the new accepted transactions is low enough to give your workflow confidence, the next logical step is to increase the percentage of rejected transactions that meet the acceptance criteria to be accepted. Go back to step 2, monitor, and decide if you can continue to increase the percentage. Keep going through this loop until you are confident enough to let 100% of transactions through that meet the acceptance criteria.
Step 5: Profit
Sit back and relax. You have done your due diligence and have improved your risk assessment platform while improving customer experiences, reduce false declines and the bottom line. Enjoy the increased revenue that has been made possible by leveraging third-party data!
If you would like to test Ekata APIs in your model to increase revenue, please contact us. We would be happy to help.