Protect Your Lending App with Device Fingerprinting, App Behavioral Data, and Face Recognition
Lending apps face fraud and identity theft. Protecting customer data, and keeping credit underwriting reliable, matters. Device fingerprinting is a practical place to start.
Device Fingerprinting and Profiling: Collecting Unique Technical Information
Device fingerprinting means collecting distinct technical details about a device, including its make and model, operating system, and hardware specifications.
Use that profile to identify and track the device across sessions. This makes impersonation and multi-account abuse harder.
Detecting Potential Abuse with App Behavioral Data
Start with the app flow. Record when each screen or step starts and ends.
Then flag unusual patterns, including exact repeated timings or navigation that appears nonhuman. These patterns can suggest bots or other automated tools.
Collecting IP Addresses and Tracking Network Changes
Capture IP addresses. Monitor network changes as well.
This can help you spot suspicious access and block unauthorized use of the lending app. Add context with third-party sources such as AbuseIPDB, including information about the connection and whether an IP address is known for bot activity.
These signals improve detection. They also speed up investigation.
Detecting Potential Abuse with Mobile Device Information
Gyroscope data and battery level can expose automation across many devices. A stationary device that stays plugged in for long periods may be part of a device farm generating fraudulent applications.
Monitoring Signal Strength and Network Information
Monitor signal strength and network details for additional context. A cluster of devices on the same Wi-Fi network can indicate coordinated activity.
Reading Wi-Fi scan results requires the app to have location permission, which the customer must grant. Android Wi-Fi permissions.
That should trigger a review.
Using App-Scoped Device Identifiers to Detect Potentially Fraudulent Activity
On iOS, an app can use the vendor-scoped device identifier, identifierForVendor, which changes when the user removes all of that vendor’s apps. The device’s own MAC address is not available to apps. Android returns the constant value 02:00:00:00:00:00 for hardware identifier requests through Wi-Fi and Bluetooth APIs, and iOS returns the same constant for MAC address requests. Android documentation and Apple documentation.
Improving Security with Face Recognition and Liveness Detection
Face recognition can support identity verification. Compare the applicant’s face with the portrait on their identification document to verify the applicant’s identity and confirm that the applicant is the person applying.
A face template used to identify a person is biometric data under GDPR Article 9, and processing it requires the applicant’s explicit consent.
Add liveness detection to prevent spoofing. Confirm that a real person is present, rather than a replayed video or static photo.
Validate depth and natural movement during capture. Check the photo metadata received by your API endpoint, then cross-reference it with the device profile.
Inconsistencies can indicate a spoofed or manipulated image.
Conclusion
The goal is to protect the lending app and its customers from fraud. Combine device fingerprinting, app behavioral data, and face recognition with liveness detection to support accurate, reliable underwriting.
Track IP addresses, network changes, and signal strength. Collect Wi-Fi network details only where the customer has granted the required permission.
Frequently asked questions
What should trigger a manual review rather than an automatic decline?
Use a single weak signal to add scrutiny, not to decline an application. Reserve automatic declines for a high-confidence fraud indicator or a combination of independent signals your tested policy treats as decisive. A new device, shared IP address, or unusual battery reading can have innocent causes. Check thresholds against confirmed fraud and legitimate applications lost.
How much weight should device fingerprinting carry in an application decision?
Treat a device profile as one input, not proof of identity or fraud. Test its added value against your existing signals before assigning it a fixed weight. Shared devices, device changes, and missing attributes can all produce misleading results. Keep the profile’s influence limited if it does not improve fraud detection enough to justify the effect on legitimate applicants.
Can MAC-address scanning reliably identify a device farm?
No. Mobile operating systems restrict access to MAC addresses, and address randomization makes them unreliable as persistent identifiers. Do not build a block rule around a MAC address or manufacturer prefix. Treat network clustering as a reason to investigate alongside stronger evidence, and check platform and privacy requirements before collecting device data.
How should we test device and behavioral signals before using them to decline applications?
Test them on historical applications with confirmed outcomes, then run them in shadow mode before they affect decisions. Compare fraud losses, false declines, application completion, and review volume against your current approach. Use a time-based holdout where possible, since fraud patterns change, and allow enough time for repayment or investigation outcomes to mature.
What should happen when face matching or liveness checks are inconclusive?
Offer a retry or staffed review rather than treating an inconclusive capture as proof of fraud. Set retry limits and provide another verification option for poor lighting, camera problems, or document mismatches. Track failure and referral rates across devices and applicant groups. Check applicable privacy and biometric rules before collecting or retaining face data.
