By NHI Mgmt Group Editorial TeamBased on Prove Identity: “Case Study: How a Growing Fintech Eliminated Bot Fraud & Made Onboarding Faster and Easier” (March 19, 2026)

TL;DR: Spark Wallet said bot fraud was draining rewards spend and slowing onboarding, with fake accounts bypassing earlier identity checks until it used Prove identity verification and authentication tools to block bots and simplify sign-up. The case shows that fraud controls must reduce abuse without creating avoidable customer friction.


At a glance

What this is: Prove Identity’s case study says Spark Wallet used identity verification and authentication controls to stop bot fraud that was exploiting rewards onboarding.

Why it matters: It matters because fintech onboarding controls must block scripted abuse without turning legitimate sign-up into a higher-friction process for customers and operations teams.

By the numbers:

  • The article says Prove Identity serves 2,500+ leading companies.

Context

Bot fraud in onboarding is a governance problem as much as a fraud problem. When scripted sign-ups can imitate real users, identity checks become the control boundary between growth and abuse, and weak customer journeys can actually help attackers blend in. In fintech, that boundary is especially important because rewards, incentives and account-opening flows create immediate value for bad actors.

This case study centers on the tension between stronger verification and lower user friction. Spark Wallet’s experience is typical of consumer-facing digital finance: the more attractive the offer, the more likely it is to attract automated abuse, and the real challenge is distinguishing legitimate customers from synthetic or scripted ones without slowing down conversion.


Key questions

Q: What breaks when bot fraud controls add friction but still miss fake sign-ups?

A: The onboarding funnel breaks because the business pays twice: it loses legitimate users to friction and still funds fraudulent accounts that slip through. That is why identity verification has to be measured against both attacker success and customer abandonment, not just by how hard the flow feels.

Q: Why do rewards programmes attract more bot fraud in fintech onboarding?

A: Rewards programmes create immediate economic value for attackers, so bots target sign-up paths where fake accounts can capture incentives quickly. When that happens, the identity layer becomes part of revenue protection, and weak proofing turns customer acquisition spend into a fraud subsidy.

Q: How can teams tell whether onboarding fraud controls are actually working?

A: They should look for falling fake-account creation, lower incentive leakage, fewer bot attempts reaching full registration and less legitimate-user abandonment. If abuse drops only when friction spikes, the control is trading one problem for another rather than reducing risk cleanly.

Q: What is the difference between identity verification and authentication in a digital finance app?

A: Identity verification establishes who a person is by checking evidence such as documents, biometrics, or trusted credentials. Authentication confirms that the same person is present again when they return. In a digital finance app, verification usually happens at onboarding, while authentication protects later sessions, account access, and transaction approvals after identity has already been established.


Technical breakdown

Bot fraud in onboarding: how scripted sign-ups evade controls

Bot fraud in onboarding usually relies on automation that mimics a normal registration journey closely enough to pass weak checks. Scripts can cycle through names, phone numbers, devices and form submissions at scale, while the business sees only apparently successful sign-ups. The technical weakness is not just authentication, but the gap between initial identity proofing and ongoing trust decisions. If controls only check for obvious abuse after account creation, the attacker has already succeeded in creating a plausible foothold.

Practical implication: move bot detection into the sign-up decision path rather than treating it as a post-registration cleanup exercise.

Identity verification versus authentication in fraud controls

Identity verification answers whether the applicant looks like a real, acceptable user. Authentication answers whether the same user can be trusted on a later session or device. In fraud-heavy onboarding, those are different problems and should not be collapsed into one control. Spark Wallet’s case shows why document checks, liveness checks and face matching can still fail when the attacker’s goal is simply to create many accounts, while passive authentication and device-linked trust signals can raise the cost of repeat abuse.

Practical implication: separate proofing from session trust, and require controls that evaluate both account creation and return visits.

Trust score and behavioural signals for fraud prevention

A trust score is a risk signal built from identity and device reputation, such as phone tenure, SIM change events, velocity and behavioural anomalies. This is not a static identity attribute. It is a dynamic estimate of how likely a session or applicant is to represent legitimate human activity. In fraud operations, that matters because bot actors often share low-tenure, high-velocity and high-churn characteristics that differ from established customers. Used well, these signals allow the business to block abuse without forcing every user through the same heavy verification path.

Practical implication: feed device tenure, velocity and change-event data into risk decisions so low-trust traffic is challenged before account creation completes.


Threat narrative

Attacker objective: The attacker objective was to create fraudulent accounts at scale and capture onboarding incentives without genuine customer intent.

  1. Entry occurred through automated account creation flows that impersonated real users during onboarding.
  2. Credential or identity abuse followed as bots cycled through fake or manipulated sign-up data to pass earlier verification checks.
  3. Impact came from rewards abuse, fake account creation and a degraded customer experience that still let some bots through before controls improved.
  • Uber breach 2022: A contractor's stolen password and MFA fatigue gave a Lapsus$-linked attacker Uber's internal tools; Uber rotated keys to many services.
  • SonicWall SSL VPN account compromises 2025: Attackers used valid credentials to log in to more than 100 SonicWall SSL VPN accounts across 16 environments in October 2025.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

Bot fraud is an identity governance problem, not just a fraud problem. Once scripted sign-ups can enter the customer journey, the control question shifts from blocking obvious automation to deciding how much trust to assign at each step. That is why identity verification, authentication and behavioural risk signals need to work as one governance layer, not as disconnected point controls. Practitioners should treat onboarding trust as a lifecycle decision, not a single gate.

Friction that fails to stop abuse is only operational drag. The article shows the core trade-off clearly: heavier checks can still miss bots while increasing abandonment for legitimate users. That means control design has to be measured against both abuse resistance and customer conversion, otherwise the programme optimises for inconvenience rather than security. Practitioners should evaluate controls on efficacy and user impact together.

Dynamic trust scoring is the right named concept for this pattern. Bot risk is not captured well by static identity evidence alone because the attacker is using repeatable, low-cost automation rather than a one-time breach. Signals such as SIM swaps, device tenure and velocity are more useful because they change with behaviour. Practitioners should build onboarding decisions around dynamic trust rather than one-time proofing.

Fintech onboarding needs stronger separation between proofing and authentication. The Spark Wallet case shows why a user can look acceptable at registration and still represent a bot at scale. That separation matters for account opening, rewards abuse and post-enrolment access alike. Practitioners should design controls so each stage answers a different trust question instead of reusing one check for everything.

From our research library:

What this signals

Dynamic trust scoring is becoming a practical control model for consumer onboarding. Static proofing steps can be bypassed or overused, but risk signals such as device tenure, SIM swaps and velocity give security teams a way to separate likely humans from scripted traffic before full account creation. Practitioners should watch for identity flows that still rely on one-time checks and shift them toward continuous risk evaluation.

For fintech teams, the design question is no longer whether identity verification creates friction. It is whether the friction is buying down meaningful fraud risk or simply pushing legitimate users out of the funnel while bot traffic keeps coming. That makes trust orchestration a programme-level issue, not a point solution choice.


For practitioners

  • Define distinct controls for proofing and authentication Map sign-up, first login and repeat access to separate trust decisions so the same check is not forced to cover both account creation and session trust.
  • Use behavioural and device reputation signals Incorporate phone tenure, SIM swap history, velocity and device churn into the onboarding risk decision before the account is created.
  • Measure friction against bot loss rates Track abandonment, fake-account blocking and rewards leakage together so anti-fraud controls are judged on both protection and conversion.
  • Challenge low-trust traffic earlier in the flow Apply adaptive controls before full form completion when trust scores and anomaly patterns indicate scripted behaviour rather than legitimate customer activity.

Key takeaways

  • Bot fraud in onboarding can drain incentives and distort growth metrics even when teams have basic identity checks in place.
  • The article’s example shows that stronger verification only helps when it blocks scripted sign-ups without driving legitimate users away.
  • Fintech teams should separate proofing, authentication and behavioural risk scoring so each stage addresses a different fraud problem.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-63 and NIST CSF 2.0 set the technical controls, while GDPR defines the regulatory obligations.

FrameworkControl / ReferenceRelevance
NIST SP 800-63SP 800-63A — Enrollment and Identity ProofingThe article is about onboarding trust and whether applicants are real users.
SP 800-63B — AuthenticationSpark Wallet used authentication to distinguish legitimate users from bot-driven traffic.
Recommendation — Apply SP 800-63A to separate enrollment proofing from later authentication decisions. Use SP 800-63B to strengthen authentication after onboarding without adding unnecessary friction.
GDPRArt.32 — Security of ProcessingIdentity verification for consumer onboarding is a processing control that must resist abuse and protect user data.
Recommendation — Assess onboarding controls under Art.32 to balance security, integrity and user impact.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsOnboarding fraud is ultimately about whether the right party gets a valid account entitlement.
Recommendation — Use PR.AA-05 to ensure account issuance is gated by risk-appropriate authorization decisions.

Key terms

  • Bot Fraud: Bot fraud is the use of automated scripts or synthetic accounts to imitate legitimate users and exploit digital services. In onboarding and account-opening flows, it typically aims to extract incentives, distort metrics, or bypass identity checks at scale.
  • Identity verification: Identity verification is the process of confirming that a user, workload, or agent is the entity it claims to be before access is granted. In AI-heavy environments, that verification must include the requester, the system acting on its behalf, and the sensitivity of the action.
  • Authentication: Authentication is the process of proving that an identity is genuine. In practice, it uses credentials, certificates, biometrics, or other factors to establish who or what is requesting access. For NHIs, the key issue is whether the proof is strong enough to resist theft, replay, or misuse.
  • Trust Score: A composite governance indicator that summarises whether an AI system has enough evidence to be reviewed and approved. It typically combines signals such as documentation, lineage, lifecycle maturity, and compliance status, but it should never replace the underlying evidence that produced it.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps practitioners who need to connect identity controls to broader security and fraud outcomes.
NHIMG Editorial Note
Published by the NHIMG editorial team on July 10, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org