Where SentiLink Fits in Your System: the First Step Before Credit Evaluation

Building an ID 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. 

Building a system like this requires balancing the user experience with fraud and other credit risks. 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 tools like SentiLink are built to aid in this process, identifying 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 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 fraud intelligence signals into your system. 

Types of fraud intelligence

While different 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 system, in increasing order of granularity:

• Scores — A single number indicating a calculated risk level. 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 applicant identity.
• 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 applicant’s 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 applicants have provided:

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.

Let’s take a look at these three ways of leveraging external fraud intelligence from a tool such as SentiLink, and how each can fit into the ID verification step that comes before credit decisioning.

Note that each of these architecture diagrams are just basic examples of a few ways a company might approach building a real-time ID verification system. While the diagrams are based on our on-the-ground experience working with our 300+ partners, every company does things differently. Our intent here is simply to demonstrate how and where SentiLink fits in these sorts of systems.

Score-based fraud detection system

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. Here is a simple example of how an ID verification flow leveraging SentiLink scores might look:

(Click to view larger diagram in a new tab)

Here, SentiLink scores are called via the SentiLink API immediately after the user submits their application. In this case, there are three possible outcomes of this API call, depending on where the returned SentiLink scores fall in comparison to the company’s predetermined score thresholds:

1. SentiLink’s ID Theft Score and Synthetic Fraud Score both fall below the company’s risk thresholds, in which case the application passes and is moved on for credit evaluation. 
2. The Synthetic Fraud Score falls above the threshold and the application is passed to SentiLink’s eCBSV service to check (with the applicant’s consent) whether the name, date of birth, and SSN match the Social Security Administration’s records, leading either to a pass or to further review.
3. The ID Theft Score falls above the threshold, in which case the applicant is asked to upload some kind of additional identity verification.

Rules-based fraud detection system

Rules-based fraud detection involves pulling in third-party signals, often scores and flags, and then routing an applicant through the process according to a logical series of rules based on the values the scores and flags return. Here is a simple example of how a credit decisioning architecture leveraging SentiLink scores and flags might look:

(Click to view larger diagram in a new tab)

Here, the application is passed through CIP and KYC checks before SentiLink’s API is called, in this case to request Scores, Insights, and Facets. 

Insights are flags that relate to specific data connected to the applicant identity, such as “The application DOB appears typoed” or “The application SSN likely belongs to someone else.” Facets are even more granular data points, such as the length of time since a phone number was last ported, or the number of times a particular IP address has appeared in applications that day.

The Scores and these more granular Insights and Facets can then be used to build a series of logical rules, allowing the company to arrive at a risk determination that is more closely customized to the needs and specifics of their business.

In this case, the application is passed through this logic-based flow and will ultimately be determined to be either low risk, synthetic risk, or ID theft risk. Depending on that determination, the application will be passed onto the next step, which in this example would be eCBSV verification (with customer consent) if a synthetic identity is suspected, or some kind of identity document verification or liveness check if identity theft is suspected.

Model-based fraud detection system

Model-based fraud detection 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. Here is a simple example of how an architecture leveraging SentiLink data within an internal model might look:

(Click to view larger diagram in a new tab)

This approach is essentially the same as the rules-based approach described above. The only difference is that instead of using a series of logic-based rules informed by SentiLink data to make a risk determination, this company has built a bespoke machine learning model that processes SentiLink data to determine the potential risk. 

However, it's worth keeping in mind that building a bespoke model also means keeping it updated if you want it to remain accurate. SentiLink's models are maintained and updated by SentiLink to improve performance and account for new fraud patterns. Partners who build bespoke models will have to maintain and update those models internally, which can require significant resources. 

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 company and industry. 

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 can make it worth the extra time and effort in some cases.

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 there’s no guarantee that an ML model will offer more precision than a simpler, rules-based or score-based approach.

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 solution for you.