Back to jobs

Data Scientist, Antifraud

Almaty, Kazakhstan

Pay
Pay not listed
Work setting
On-site — work setting source
Location type: On-site
From the employer’s posting
Employment
Full-time — employment source
Employment type: Full-time
From the employer’s posting
Team
Engineering & Product — team source
Department: Engineering & Product
From the employer’s posting

Before you apply

Sponsorship
Visa sponsorship not confirmed — sponsorship source
Will you now or in the future require visa sponsorship? If yes, select the type of sponsorship.
From the employer’s application form
Apply at Higgsfield

What you’ll work on

Full posting
  • Own the account-abuse scoring system: signals, weights, thresholds, monitoring and recalibration

  • Find fraud rings through shared payment instruments, IP concentration and registration bursts

  • Design graduated, reversible enforcement actions matched to confidence, with an appeal path

  • Quantify the system's worth in money, net of lost revenue and support cost, and run holdouts

From the employer’s posting
Own the account-abuse scoring system end to end: signals, weights, thresholds, the scoring job, the monitoring, and the recalibration when it decays.
Find rings, not just accounts: shared payment instruments, IP and ASN concentration, email-stem families, synchronised registration bursts
Design graduated, reversible actions — throttle, rate-limit, step-up verification, hold, pre-grant refusal, manual review queue, ban — and match the severity to the confidence.
Quantify what the system is worth in money — COGS avoided, net of the revenue you destroyed and the support cost you created.

Tools in this posting

  • Python
  • SQL
  • BigQuery
Source — Tool mentions in context
- Produce evidence that survives outside the company. Our abuse work has already been used in an external audit and in Terms-of-Use enforcement; write for that standard. - Work in SQL, Python and BigQuery on raw event, payment and generation data. We use AI heavily — resourcefulness beats syntax. Who We're Looking For
- Genuine understanding of the adversarial setting: that your counterparty responds, that your training labels are generated by your own past decisions, and that offline AUC on a censored label set is close to meaningless. - Strong SQL and Python on raw event data without help: joins across payments, usage and identity, window functions, cohort replay. Gradient boosting, and the judgment to know when a two-condition rule beats a model. - Comfort with graph and linkage thinking — connected components, shared-attribute clustering, and an instinct for when a link is evidence and when it is coincidence.

Posting record

Report an error
Status in our records
Live
First seen by us
Sep 30, 2026 · 22 days ago
Recorded sightings
42
Last seen by us
Oct 23, 2026

These dates show when we found the listing. Check the employer’s website to confirm it is still accepting applications.

Your next step

  • Have your resume and examples of relevant work ready.
  • Check the listed location, eligibility and core experience before starting.
  • Ask the employer about the pay range before committing time to the process.

Complete your application on jobs.ashbyhq.com. The employer’s form will show what is required.

Already applied? Track this application

Job description

View original posting ↗

Why work at Higgsfield AI?

Higgsfield AI is the fastest-scaling generative AI company in history, hitting $1B in annual revenue run rate, 30M+ users worldwide, 6M+ generations per day, and powering 390 of Fortune 500 brands.

We're building at the absolute frontier of AI-powered video creation and next-generation creative tools. Joining Higgsfield means becoming part of a high-impact team shaping the future of AI-native experiences, at a company that isn't just moving fast, but rewriting what fast looks like.

What This Role Means at Higgsfield

Generative video has a problem most subscription businesses don't: every unit we sell costs us real compute. A stolen password costs a streaming service nothing. An account farm on an unlimited generation plan costs us GPU-seconds, at scale, every hour it runs.

We have found organised operators running hundreds of accounts on a single card, reselling unlimited generations, and harvesting per-account promotional grants at industrial scale. We have also found that most of our negative-margin accounts are not abuse at all — they are ordinary heavy users on an unlimited plan, which is a pricing problem wearing a fraud costume. Telling those two populations apart, at account level, before the money is gone, is this job.

You own the question of who is taking value they did not pay for, and the system that stops them.

You make sure:

  • We catch abuse before the compute is burned, not in a post-mortem that reconciles the loss

  • Every enforcement action has a measured precision, a measured cost of being wrong, and a way back for the customer we got wrong

  • The difference between fraud and unprofitable pricing is a number we can defend, not a vibe

  • When operators adapt — and they will, within days — we find out from a monitor, not from the monthly margin review

What You Will Do

Detection & scoring

  • Own the account-abuse scoring system end to end: signals, weights, thresholds, the scoring job, the monitoring, and the recalibration when it decays.

  • Build detection that fires early. A rule that catches 88% of the money on day 11 is worth far less than one that catches 60% at checkout, and you should be able to say why in dollars.

  • Work the two halves that actually matter together: linkage (who is connected to whom) and economics (what are they consuming). Either one alone produces a system nobody can switch on — linkage without economics flags families sharing a card, economics without linkage flags our best customers.

  • Treat cost as a gate, not a label. On an unlimited plan, being gross-margin negative is normal.

Entity resolution & ring detection

  • Find rings, not just accounts: shared payment instruments, IP and ASN concentration, email-stem families, synchronised registration bursts, behavioural fingerprints, automation signatures.

  • Do it without a reliable device fingerprint — we do not have one today, and part of this job is telling us what it would be worth and what it would cost.

  • Know where graph methods break. Transitive closure through a shared card will happily merge thousands of unrelated people into one "ring"; we have done exactly that and thrown the result away.

Enforcement, policy & the cost of being wrong

  • Design graduated, reversible actions — throttle, rate-limit, step-up verification, hold, pre-grant refusal, manual review queue, ban — and match the severity to the confidence.

  • Own the false-positive budget explicitly: how many paying customers are we willing to inconvenience to save a dollar of compute, and what is the appeal path for the ones we get wrong.

  • Build the pre-grant gates. The cheapest abuse to stop is the kind we decline to enable in the first place — a trial we do not grant costs nothing to claw back.

  • Partner with Payments on Stripe Radar, chargebacks and dispute economics; with Support on the queue your model creates; with Legal on what our Terms actually entitle us to do.

Measurement & adversarial monitoring

  • Quantify what the system is worth in money — COGS avoided, net of the revenue you destroyed and the support cost you created. Keep that number current.

  • Run holdouts even on enforcement, wherever it is legal and safe to do so, because otherwise you will never know what your rules are worth.

  • Monitor for adaptation, not just drift. Model decay here is caused by an adversary, and it looks different: a signal stops firing, a ring changes shape, a cohort's behaviour shifts inside a week.

  • Watch your own inputs. A detection system that silently loses a feature degrades to a system that cannot reach its own threshold — and reports nothing wrong while doing it.

Making it usable

  • Ship scores and reasons, never scores alone. An analyst, a support agent or an auditor must be able to read why an account was actioned.

  • Produce evidence that survives outside the company. Our abuse work has already been used in an external audit and in Terms-of-Use enforcement; write for that standard.

  • Work in SQL, Python and BigQuery on raw event, payment and generation data. We use AI heavily — resourcefulness beats syntax.

Who We're Looking For

  • Experience building abuse, fraud or trust-and-safety detection that actually took action on real users — payments fraud, promo abuse, multi-accounting, bonus abuse, account takeover, marketplace or gaming abuse. Anti-money-laundering and credit-risk backgrounds transfer if the modelling was yours.

  • Genuine understanding of the adversarial setting: that your counterparty responds, that your training labels are generated by your own past decisions, and that offline AUC on a censored label set is close to meaningless.

  • Strong SQL and Python on raw event data without help: joins across payments, usage and identity, window functions, cohort replay. Gradient boosting, and the judgment to know when a two-condition rule beats a model.

  • Comfort with graph and linkage thinking — connected components, shared-attribute clustering, and an instinct for when a link is evidence and when it is coincidence.

  • Precision-first evaluation instincts: precision at the operating point, cost-weighted error, and why you would take 20% recall at 90% precision over the reverse in an enforcement system.

  • Unit-economics literacy: gross margin per account, what compute actually costs us, why a negative-margin customer may be entirely legitimate.

  • The judgment to escalate rather than act when the evidence is thin, and to say so in writing.

  • Clear written and spoken English, B2+.

Backgrounds that often do well:

  • Fraud / risk data scientists from fintech, payments, marketplaces, gaming or crypto

  • Trust & safety and platform-integrity teams who owned detection and enforcement policy

  • Growth or product data scientists who ended up owning promo-abuse because nobody else would

  • Analysts from payment processors, PSPs or chargeback/dispute operations who moved into modelling

What This Role Is Not

This role is not a fit if you:

  • Want to build content-moderation or NSFW classification — that is a different function here

  • Would ship a ban list without knowing its precision

  • Optimize AUC on a label set your own enforcement created, and call it validated

  • Need a labelled fraud dataset to exist before you can start

  • Treat every negative-margin account as an abuser

  • Are uncomfortable that being right 90% of the time means being wrong about real, paying, legitimate people — and that you own what happens to them

  • Want predictable 9–5 workdays

Hiring Process

We move fast:

  • Screening call (30 min)

  • Hiring-manager screen (30 min)

  • Business case (1 hour)

  • Practical home task (7 days)

  • Team interview (60 min)

  • Paid on-site trial (1 month)

The Deal

  • Competitive salary in USD

  • Equity: participation in the company's stock option program

  • On-site role in Almaty, Kazakhstan

  • Relocation support (flight + temporary housing)

  • Flat structure, high autonomy, fast career growth

Source details

View original posting ↗

Source notes

Source excerpts

Selected passages from the saved posting. Check the full description for conditions and exceptions.

Pay

No pay amount identified in the saved description.

Location & working pattern

Almaty, Kazakhstan

- Team interview (60 min) - Paid on-site trial (1 month) The Deal
More source context
- Equity: participation in the company's stock option program - On-site role in Almaty, Kazakhstan - Relocation support (flight + temporary housing)
Work authorization

No clear work-authorization passage found. Eligibility is unconfirmed.

See how this role fits your experience

Add your resume to compare the role’s scope, tools and requirements with your experience.

Find answers in the posting

AI
How answers work

AI selects complete passages from this posting. Check them for conditions and exceptions.

Uses this posting and your question. No profile needed.