How to Spot the Same Device Behind Multiple Loan Applications

Lenders spot the same device behind multiple loan applications by linking applications through a device identifier rather than through the data the applicant types. A device intelligence solution assigns each device a probabilistic ID built from hardware, software and connection signals, then tracks how many applications, identities and loan outcomes attach to that ID over a set window. Shared family phones, velocity bursts, emulators and reset devices each need their own rules.

Key takeaways

• Applicant-entered data can miss linked applications, because names, phone numbers and document numbers change between attempts while the device often stays the same.
• A device linked to several applications is a risk signal, not a verdict: shared family phones, assisted onboarding and kiosks also produce legitimate multi-application devices.
• The useful measures are how many distinct identities appear on one device, within what time window, and how the earlier loans on that device performed.
• Factory resets, app reinstalls, emulators and browser randomization are the usual ways to break a device link, so detecting those manipulations is part of device linking.
• Device linking works alongside bureau data: the bureau shows reported obligations across lenders, while device data shows connections inside the lender’s own application flow.

Why do lenders link loan applications by device instead of by applicant data?

Lenders link loan applications by device because the applicant supplies the application data and can change it at will, while the device used to apply is harder to change without leaving traces. Loan stacking, synthetic identities and repeat attempts after a decline all tend to vary the declared data between submissions.

A common pattern is a run of applications with small changes in data: a new phone number, a transposed digit in a document number, a different email address, a slightly altered employer name. Fuzzy matching on applicant fields catches some of these runs. It misses runs built from entirely different identities, as in synthetic identity fraud.

The device sits outside the applicant’s declared data. A phone or computer keeps most of its hardware, operating system, software and connection characteristics between applications unless someone changes them on purpose. That makes the device a link key that applicant data cannot provide, and a complement to identity checks at the application fraud stage.

How does a device intelligence solution recognize the same device across applications?

A device intelligence solution recognizes the same device by comparing many device and environment parameters and estimating the probability that two sessions come from one device. The result is a probabilistic device ID, which tolerates changes in individual parameters instead of breaking on them.

A single stored identifier is a weak link key on its own. Cookies and local storage disappear when browser data is cleared or a private window is used. App-level identifiers have documented reset conditions too: Android’s reference for ANDROID_ID states that on Android 8.0 and higher the value is scoped by app-signing key and user, and may change after a factory reset.

A probabilistic device ID combines hardware traits, operating system and build details, installed software, browser configuration and connection characteristics, so one changed value does not create a new device. The trade-off sits in the matching threshold. Set too loose, distinct devices merge into one ID; set too tight, one device splits into several IDs and the link is lost. The mechanics are covered in our introduction to device fingerprinting.

JuicyScore’s overview of the future of device ID describes three generations of device ID:

1. IDs built from user data, such as an email address or phone number, which an applicant can vary at will.
2. Statistical IDs, such as browser hashes and persistent cookies, which can change when a few parameters or the browser change.
3. Probabilistic device IDs, which estimate how similar two devices are across many parameters and their combinations.

JuicyScore’s own probabilistic device ID, JuicyDeviceID, is a probabilistic device identification model built to return a single stable identifier across different browsers and private browsing modes on the same physical device. The uniqueness rate of JuicyDeviceID reaches 99%+. Device ID calculations run at the server level rather than on the user’s device, which reduces the impact of possible manipulations and the load on the device.

Devices linked to past fraud cases are investigated to identify new risk indicators and refine detection methods. The service works with 65,000+ parameters collected from every device and 250+ parameters used for device scoring, without relying on direct user identifiers such as names, phone numbers, or email addresses.

As with any device identifier, results depend on the platform and the signals available. Our comparison of device intelligence solutions covers how other providers approach device identification.

Lenders can check where a device ID falls on the merge-or-split trade-off with the 8-browser test. On one physical device, open four browsers in normal mode and the same four in private mode, and record the device ID each session returns. A strong solution resolves the eight sessions to one ID in the large majority of runs, though not every time, because new browser versions can briefly shift the signal set.

Which signals show that one device is behind multiple high-risk applications?

The signals that show one device behind multiple high-risk applications are counts and combinations attached to a single device ID: how many distinct identities applied from it, how quickly, and with what outcomes. No single count settles the case. The combination of several signals is what separates a risky device from a busy one.

Signals lenders commonly track per device ID:

• Distinct identities per device – different names, document numbers or phone numbers submitted from the same device ID.
• Application velocity – the number of applications from the same device ID within an hour, a day or a week.
• Outcome history – earlier applications from the same device that were declined, flagged for fraud or went into first-payment default.
• Declared versus observed context – a declared city that does not match the device’s time zone, language settings or connection location.
• Manipulation markers – emulators, virtual machines, remote-access tools, rooting or randomized browser parameters on the device.
• Shared infrastructure – several devices applying through the same proxy, IP range or hosting network within a short window.

Shared infrastructure answers a different question from the other five signals. When multiple applications are driven from a single infrastructure, each application may come from a different device, and the link appears only at the level of the network or the device cluster.

How do you tell a shared family phone from organized application fraud?

A shared family phone and organized application fraud both put several identities on one device, and they usually differ in what surrounds those identities. Legitimate sharing tends to show few identities, a stable device, a consistent location and applications spread over time. Patterns associated with organized fraud tend to show many identities, short intervals, manipulation markers and weak outcomes on earlier loans.

Device sharing is part of everyday life in many markets where digital lending is growing. One smartphone may serve several members of a household, and in assisted onboarding an agent or a kiosk submits applications on behalf of customers. Declining every multi-identity device would turn away legitimate thin-file borrowers who have no other way to apply.

In Nigeria, a single smartphone may be shared among several family members or even households. As the CashExpress case describes, this makes borrower identification harder and raises the risk of repeat loan applications from the same device. CashExpress (CashX) combines the device’s unique technical parameters with the number of credit applications in the last 1, 7 and 30 days and an NPL 90 Plus marker, and filters out up to 25 percentage points of potential fraud risk within the high-risk segment.

Three questions, asked together, usually separate the two cases: how many identities, how fast, and how clean the device is. Two applicants in one household, weeks apart, on an unmodified phone look nothing like twelve identities in an afternoon on an emulator.

Agent and kiosk channels need separate rules. A device in an assisted channel is expected to carry many identities, so the more useful signal there is how loans originated through that device perform over time.

How do fraudsters try to break the device link, and what does that leave behind?

Fraudsters try to break the device link by changing what the device reports, through factory resets, app reinstalls, emulators, anti-detect browsers or device farms. Each technique can leave its own traces, which is why detecting manipulation is part of linking applications rather than a separate task.

• Factory resets and reinstalls clear stored identifiers but leave the hardware as it was. A long-used device model presenting with no history at all is worth weighting, though second-hand phones produce the same picture legitimately.
• Emulators and virtual machines can generate many apparent devices from one computer. Virtualization artifacts are covered in virtual machine detection.
• Randomizers and anti-detect browsers change parameters from session to session. Parameters that would normally agree with each other and no longer do can indicate device spoofing.
• Rooted or jailbroken devices allow apps to alter the values a device reports. See jailbreak and root detection.

Device farms spread applications across many real handsets, so no single device carries a suspicious count. Linking then moves to infrastructure and cluster level.

What should a lender do when a new application links to earlier applications or defaults?

A link between a new application and earlier applications should change how the new application is handled, without deciding it on its own. A device carrying a declined or defaulted history, now presenting new credentials, is a case for review or a stricter decision. A device carrying one earlier, well-performing loan most likely belongs to a returning customer.

Device links work best as inputs to an existing decision process: as triggers for manual review, as variables in fraud or credit-risk models, and as the basis for separate rules for repeat borrowers. Repeat lending is where the value shows most clearly, because a returning borrower on a known, clean device is a different risk from a “new” applicant whose device carries an earlier default.

In a pilot focused on secondary loans in the Philippines, UnaFinancial developed a set of device-level markers for its anti-fraud model. Mikhail Koromyslov, Risk Director at UnaFinancial: “Judging by the primary results after the pilot launch, we managed to develop a set of comprehensive markers and variables that enriched our company’s anti-fraud model in the Philippines. It helped to reduce the risk level in the early re-loan portfolio by several percentage points.”

How do the main ways of linking loan applications compare?

Each way of linking loan applications covers part of what the others leave open, which is why most lenders combine several of them.

Where does device linking fit less effectively?

Device linking fits less effectively where devices are shared by design, where volumes are too low for counts to mean much, and where repeated applications happen at other lenders. In each of these situations device data still contributes, but it carries less of the decision.

• Assisted and branch channels. Agent and staff devices carry many identities by design, so device-level counts describe the agent rather than the applicant.
• Very low application volumes. Counts per device rarely build up, and a manual review may already see the same overlaps.
• Stacking across lenders. Device data shows the lender’s own application flow, widened only where the vendor observes devices across its client base. Applications at other lenders become visible through bureau inquiries and reported obligations, which is where device data and bureau data complement each other.
• Device farms. When every application comes from a different real handset, single-device counts stay low and the link has to be found at infrastructure level.
• Data-protection requirements. Device, IP and cookie data can count as personal data under several privacy regimes, and consent and retention rules differ by market. Check them with legal and compliance teams before device rules go live. How limiting personal data collection shapes fraud-prevention design is covered in Privacy by Design in fraud prevention.

FAQ

How can I detect if a supposedly new customer is just a returning defaulter using new credentials?

Check whether the new application’s device ID matches a device linked to an earlier default. A returning defaulter can change the name, phone number and documents and still apply from the same phone or computer. Combine the device match with manipulation markers, because a reset or emulated device is a common way to hide that link.

Which tools help detect high‑velocity application bursts from newly seen devices?

Device intelligence solutions and fraud rule engines, used together. The device layer recognizes many applications arriving from devices with no history, or from one device under several identities. The rule engine sets the time windows and thresholds. A burst from many new devices at once can point to emulators, device farms or shared infrastructure.

What’s the best way to detect high‑risk patterns across many applications over a short time window?

Aggregate applications by device ID, by network and by device configuration over rolling time windows, then compare the counts with your normal baseline. A sudden rise in new devices, repeated configurations or shared proxies within a few hours is easier to see in aggregate than application by application. Review flagged clusters as a group.

Is one device with several loan applications always fraud?

No. Families share phones, and agents and kiosks submit applications for customers in assisted channels. Several identities on one device become a stronger risk signal when they arrive close together, come with emulators or other manipulation markers, or sit alongside earlier defaults. Treat the device link as an input to the decision rather than a decline rule.

Can device linking detect loan stacking across different lenders?

Partly. Device data from a lender’s own application flow catches repeated attempts at that lender, and some device intelligence vendors also observe devices across their client base, which widens the view. Applications at other lenders also surface through bureau inquiries and reported obligations, so device data and bureau data complement each other.

Does device linking require personal data?

Device linking can work without relying on direct user identifiers such as names, phone numbers, or email addresses. Device, IP and cookie data can still count as personal data under several data-protection regimes, so lenders should check consent, retention and processing requirements in each market before device rules go live.