Testing a Successful Proof of Concept
At Ekata, we continuously perform analysis on proof of concept tests using large identity verification and fraud prevention data sets to show our customers how to leverage Ekata APIs. While running data tests is labor-intensive, when done right, they can yield excellent results. As a senior field data scientist at Ekata, I have a lot of experience – from live integration tests or historical batch tests – with what worked and what did not.
To help people better understand how to best engage with our award-winning APIs and take advantage of award-winning fraud prevention software and identity verification solutions, I’ve created a list of five proof of concept questions that any team should ask before they engage us.
1) Do you have a business problem?
Ekata APIs are meant to solve problems, such as evaluating the likelihood of fraud (fraud prevention), or streamlining the customer experience with well-established digital identities (identity verification).
2) Can you measure the business problem?
If fraud is the business problem and fraud prevention is your requirement, ask yourself: are the transactions or account sign-ups labeled as fraud? If not, can something else be used as a proxy for fraud? For instance, is there too much customer friction or transaction rejection? Is there something to show customers that may have been rejected in error? Linking call center interactions is often a proxy here for identifying the problem.
3) Do you have a detailed test plan?
No matter what kind of test we do, we write a joint test plan. This plan helps us at Ekata understand the goals of the proof of concept – fraud prevention? Identity verification? Something different? – and helps the customer understand what data needs to be pulled. Since a test can take months from an initial conversation to an analysis presentation, the test plan is a useful guide for refreshing everyone’s memory. The best test plans may even include block diagrams for a customer’s workflow.
4) Can you simulate reality?
The reason why we conduct tests in a proof of concept is to answer the question: “if I integrated Ekata into my BLANK workflow at BLANK time, what decisions could I have made using that information and what would have been the outcome?”
Ekata uses five identity verification elements: name, email, IP, phone, and address to provide responses on a customer’s level of risk. These data elements should be tested the same way that they would be sent through in production. Simulating how fraudsters work sounds simple but emulating their attacks often isn’t. For example, one customer attempted to simulate fraud by swapping emails and phone numbers between historical records. It wasn’t a great way to test our fraud prevention API as it’s simply not how fraudsters behave.
5) Communication throughout the test
No matter how well you plan, unexpected things may come up during a test. It could be something as simple as a mismatched API mapping, or a new metric to analyze. Both sides should plan to ask questions and check in with one another throughout the process.
The field data scientists at Ekata are here to provide guidance on how to best integrate fraud prevention software and identity verification solutions to stand out from the pack . The better we can understand a customer’s problem and goals, the better we can tailor our advice.
Get in touch with us today and let’s start a conversation on how to leverage identity verification software and fraud prevention solutions today.