IVINSKAS DAILY NEWSFEED RESEARCH LIBRARY
Deep-dive library
AI banking tool

Socure Sigma Synthetic: turn a fraud signal into a tested policy

Understand the score, validate the intervention and distinguish synthetic-identity risk from ordinary credit risk.

September 26, 2026
Current version

Initial source-linked research article with operating analysis and illustrative examples.

What the product targets

Socure describes Sigma Synthetic Fraud as a tool for identifying synthetic identities, including manipulated and fabricated identity patterns. Its scope documentation identifies U.S. onboarding and portfolio use cases. This is an identity-risk product description, not evidence that every high-risk result represents fraud.

Analysis: a bank should distinguish identity confidence from ability and willingness to repay. A synthetic-identity signal can inform verification or investigation, but it is not an interchangeable credit score. The operational question is what additional evidence should be obtained and what action is justified when the signal is strong, weak or unavailable.

Read the score correctly

The product documentation describes a score ranging from 0.001 to 0.999 and explains the ranking relative to identities in its network. Its example of 0.800 indicates a higher synthetic-risk ranking than 80% of that population. Do not interpret this automatically as an 80% probability that the applicant is fraudulent. The response also includes model information and reason codes.

Analysis: the meaning of a threshold depends on the population, fraud prevalence and the cost of each possible action. A threshold that works for an existing-account review may be unsuitable for a new-account application. Keep the model version with the result so changes in score distribution are not confused with changes in customer behavior.

A base-rate example

Assume a fictional set of 10,000 applications contains 100 genuinely synthetic identities. A screening policy identifies 80 of those but also flags 198 legitimate applicants, a 2% false-positive rate among the 9,900 legitimate applications. Of 278 flagged applications, only about 28.8% are synthetic under these assumptions.

This is a teaching example, not a Socure performance estimate. It demonstrates why a high detection rate can still create substantial customer friction when the underlying event is uncommon. It also shows why “percent detected” is insufficient without false positives, prevalence and the denominator used.

Design the response as carefully as the detection

A high score could route a case to an additional identity check or human review rather than immediately ending the application. Socure’s documentation discusses additional verification options. The appropriate action depends on the product, legal obligations and the evidence available.

StageProposed measureWhy it matters
InputsCompleteness and source qualityMissing or incorrect data can distort the signal
DetectionRecall and precision at chosen thresholdsBalances missed fraud against false alarms
InterventionCompletion rate and review timeMeasures legitimate-customer friction
OutcomeConfirmed fraud loss and appeal resultsTests whether the policy improves results
Change controlModel version and threshold historyMakes results comparable over time

A new architecture is a testable claim

Socure announced Sigma V4.5 in July 2026 and described a shift to a transformer-based architecture. The company’s announcement makes claims about improved identity-fraud detection. Those are vendor claims; the architecture’s name alone does not establish better performance for a particular bank.

Analysis: evaluate the proposed version against the existing version on a common population and outcome definition. Separate changes attributable to the model from changes in available data, thresholds or review capacity. If the new score distribution differs, copying the old threshold can silently change the intervention rate. Require a planned transition and a way to investigate unexpected outcomes.

The evidence challenge

Fraud labels are often delayed and imperfect. A rejected application may never produce an observable loss, and a successful verification may change the outcome. Analysis: document how confirmed fraud is defined, how long outcomes are observed, and how sampled investigations reduce uncertainty in unreviewed populations.

Test differences across relevant customer groups and data-availability conditions. A model can appear strong overall while producing excessive friction for a smaller segment. Review appeals and customer complaints as evidence about false positives, while recognizing that neither an appeal nor its absence proves the original decision was correct.

What would justify deployment or revision

A credible business case would show lower confirmed loss or better review efficiency after accounting for verification costs, abandonment and customer harm. It should also establish reliable inputs, access controls, retained decision records and a workable fallback if the service is unavailable. No specific license price or guaranteed return is assumed here.

Revisit this profile when technical documentation, model versions or independently interpretable results change. The permanent topic page should retain the earlier analysis so readers can distinguish an actual improvement in evidence from a new marketing claim or a renamed model.

Sources