Where SentiLink Fits in Your System: Verify Identities Before Credit Evaluation

Building an identity verification and credit evaluation model is challenging, particularly if — like many modern businesses — you’re trying to automate as much of the process as possible to provide real-time or near-real-time decisions. 

A system like this requires balancing the user experience with fraud and other credit risks as well as regulatory requirements. Build a system that’s fast but imprecise, and you’ll please customers but end up losing millions to fraud. Build a system that’s precise but slow or that presents too much friction for users, and you’ll lose millions in potential customers who turn to competitors for an easier and faster process.

Real-time fraud intelligence and identity verification tools like SentiLink's are built to aid in this process, identifying customers and highlighting potential fraud risks with high precision in real time. But how are these tools best implemented into the overall architecture of your system? What does that look like?

In this article, we’ll take a look at where identity and fraud intelligence signals can fit within the broader context of credit systems. But first, we need to take a closer look at the choices that are available when it comes to pulling external identity verification and fraud intelligence signals into your system. 

Identity verification and compliance

To remain in compliance with CIP regulations, financial institutions must identify their customers, which often means leveraging third-party identity verification tools such as SentiLink's CIP Match product to ensure applicants are who they claim to be and that the institution can legally do business with them.

This typically happens relatively early in the funnel, so to reduce the number of applications that are eliminated due to the inability to find a match, it often makes sense to leverage multiple CIP providers for identity verification – a second provider may be able to verify identities that the first cannot. This typically ends up being cheaper than simply denying the unmatched applications or forwarding them to high-friction step-up processes from which many will drop off, and it also ensures your system can remain online in the event that one of your CIP providers has a service outage.

Fraud intelligence and prevention

Simply verifying that the identity on an application exists is typically not enough to determine whether the application presents a significant risk of fraud, so the identity verification process generally also includes anti-fraud measures designed to assess the level of risk the application presents. While different identity and fraud intelligence tools may offer different product options, in general we can think about three different types of data we might want to pull into our anti-fraud system, in increasing order of granularity:

• Fraud scores — A single number generated by a machine learning model indicating the calculated risk level associated with an application. For example, SentiLink’s Synthetic Fraud and ID Theft Scores calculate the probable risk that a given identity is synthetic or stolen (respectively) based on all of the information available within SentiLink’s system.
• Flags — Boolean (true/false) values that are returned by the fraud tool based on its own assessment of the data. For example, among many others SentiLink offers a flag that will return `TRUE` if it appears the SSN provided on the application is not the best-matching SSN for the application identity. In some cases, these flags may come from the same tool you’re using for CIP – SentiLink's CIP Match, for example. 
• Raw data — Specific data points from a SentiLink's records that can be fed into your system as part of your own identity verification model, or as part of a rules-based system. For example, SentiLink Facets can provide granular data points such as how long it’s been since a phone was ported, how often the IP address associated with the application appears in other applications on the same day, and much more. 

In some cases, using raw fraud intelligence data such as what you’d get from SentiLink Facets to inform a custom-built model can offer a high level of precision, because that model can be tightly tuned to unique specifics of your business. Sometimes, however, pulling flags, scores, or both will offer a higher level of precision because of the broader view they can take when searching for patterns related to your application identity that indicate a potential fraud risk. And of course, in some cases, doing _all_ of the above is the best way to achieve precision.

In all cases, if our aim is to build a system that can make decisions in real-time, we’ll need to pull this data via API. While SentiLink and similar tools offer a variety of ways for partners to input application data and receive intelligence such as scores in return, a simple API call is always going to be fastest, and thus the preferred option for any business that is concerned with keeping latency low to reduce customer drop-off. 

Here’s an example of some JSON you might get back from SentiLink’s Insights REST API, which flags potential issues with the identity information provided on applications:

Note: the API response is provided as an example only; SentiLink partners should refer to the official SentiLink documentation for the most current information on API responses.

Approaches for identity verification systems

Broadly speaking, there are three common approaches to building an identity verification system that can leverage data from third-party solutions to provide accurate real-time identity verification and fraud scoring:

• Score-based fraud detection
• Rules-based fraud detection
• Model-based fraud detection

All three approaches are similar in terms of their overall architecture, and all three will typically begin with the mandatory CIP process, leveraging tools such as SentiLink's CIP Match and Watchlists to quickly and accurately verify identities. But these three approaches do differ in some ways:

A score-based system, with rules based on a specific score threshold, is one of the simplest ways to implement third-party fraud intelligence to augment your identity verification. After CIP, it simply involves calling risk scores such as SentiLink's Identity Theft Score and Synthetic Fraud Score via API, and then moving forward with an application or proceeding to a step-up verification treatment of some kind based on preset score thresholds.

For example, a very simple score-based system might simply run applications through its CIP tool and then call SentiLink's Identity Theft and Synthetic Fraud scores, passing any applications that score above a present threshold into a step-up verification and/or manual review process.

A rules-based system is slightly more complicated, and typically involves pulling in third-party signals, often scores, flags, and other data points such as the quality of identity verification match found during the CIP process, and then routing an application according to a logical series of rules based on those scores, flags, and other data points.

This approach can be more accurate than a score-based system, but it is also more complex to build, and requires regular re-testing to ensure that the rules logic remains optimized for the best performance (however the company in question chooses to define that) as time passes and new fraud MOs and vectors emerge.

A model-based system involves building a bespoke internal model for identity verification (and potentially also credit evaluation, although that’s a separate step that does not make use of SentiLink data). Such a model could leverage any or all of the above levels of data granularity, potentially calling scores, flags, and raw data via SentiLink’s API.

In practice, this approach is essentially just a more complex version of a rules-based approach, and as such it has the same potential upside (more accuracy) and downside (more complex to build and maintain). 

How do these approaches look in practice?

A reference architecture for identity verification and fraud detection

The above diagram is just a basic example of one way a company might approach building a real-time identity verification system. It is based on our on-the-ground experience working with our 400+ partners, but every company does things differently. Our intent here is simply to demonstrate how and where SentiLink fits in these sorts of systems.

With that said, let's walk through what's happening in the diagram above. At a high level:

1. The application is accepted.
2. The application data passes or fails CIP identity verification using SentiLink's CIP Match. 
3. Third-party fraud signals are called, including SentiLink scores and potentially also flags and facets.
4. The application is assessed for fraud risk based on score thresholds, fraud rules, or the company's internal model, depending on which of those three approaches they've taken.
5. The application is routed according to its risk profile, so (for example) an application that is flagged as high risk for synthetic fraud might be routed to eCBSV to check the provided PII against the SSA's database.
6. The application identity is checked against government watchlists.
7. The application is ultimately either rejected, or passed along to the next step in the onboarding process (such as credit decisioning).

What’s the best approach?

Unfortunately, there’s no one-size-fits-all solution when it comes to identity fraud. The best approach for your company will depend on a wide variety of specifics relating to your business and industry.

CIP is table stakes, at least for financial institutions, and must be a part of every FIs onboarding process, so the only decision to make there is which CIP tool or tools to leverage to ensure accuracy and minimize friction and false positives.

After that, businesses must decide how they want to approach the fraud risk assessment, where they have more options.

A score-based approach is the simplest, and therefore the easiest and cheapest to implement. Using past performance data to fine-tune score thresholds, score-based approaches can still be customized to achieve a high degree of precision when it comes to identifying potential fraud.

Rules-based approaches offer more opportunities for customization and fine-tuning, allowing you to leverage specific data points that may be key to your specific business as part of the rules that lead to risk determination. Building, testing, and implementing a rules-based system is more complex that implementing a score-based system, but the additional precision it may offer, especially when combined with scores, can make it worth the extra time and effort.

Model-based approaches can potentially offer the highest level of precision, as they can assess large amounts of data with a level of sophistication that goes beyond the basic true/false logical flow of rules-based approaches. However, building, testing, and maintaining a bespoke machine learning model is challenging, and to get the best performance, you may still want to combine your model with some rules to capture cases that the model is likely to miss.

If you’re not sure which approach is likely to be best for you, let us help! Book a call with our fraud experts today and we’ll help guide you through the process of finding the right identity verification and fraud detection solutions for you.