The Roles, Decoded

Staff Data Scientist, Full Stack — fraud / identity

What the fraud/identity company is

This archetype is an identity-verification & fraud-detection platform serving financial institutions. Real-time APIs sit in the credit-application path at banks, fintechs, and lenders — the model says "this application looks legitimate" or "this looks like synthetic identity fraud" in milliseconds, and the lender decides whether to approve, manually review, or decline. Such platforms verify hundreds of millions of identities annually and integrate with regulator services like the SSA's eCBSV.

What this role actually is

"Staff Data Scientist, Full Stack" decodes to: own a fraud model end-to-end as the technical authority on a specific fraud domain. The JD is unusually direct about scope: "You will often work on projects with high visibility and impact that require deep domain understanding, critical thinking and strong technical abilities."

The three sub-teams give you a sense of the work:

• Emerging Products — 0-to-1 model development for new product offerings. Define the data, the labels, the model, the metric, the production deployment. Highest ambiguity.
• Application Fraud — analyze the foundational elements of consumer financial applications to detect every kind of fraud. Iterative model improvement on a mature product.
• Identity — resolve identities across conflicting digital and physical data sources, build risk models with limited information. Closest to entity resolution / graph problems.

The defining sentence of the JD

Decoded: they're not hiring a researcher who'll chase SOTA. They're hiring someone who'll discover non-obvious features about fraud behavior, encode them into models, and ship the result as production code. The lift comes from domain insight, not from XGBoost vs CatBoost.

"Write production-ready code that can be relied on for real-time decision making"

This phrase is doing work. Read as: you're not handing off to an MLE. The Jupyter notebook isn't the deliverable; the deployed Python service is. Expect interview questions on code quality, testing, real-time inference patterns, and monitoring.

a multimodal-sensor AI company — Data Scientist (a.k.a. AI Solutions Specialist)

What a multimodal-AI company is

a multimodal-sensor AI company builds "Newton," a multimodal-LLM platform for the physical world — fusing video, sensor, time-series, and other real-world data into a model that can reason about physical environments. Series A startup, founded by former Google engineers. The customer pitch: build perception systems for industrial, mobility, retail, and IoT applications without having to train custom CV/sensor models per use case.

What this role actually is

Don't be misled by the "Data Scientist" title. The team is GTM / Solutions Engineering, not core research. The work is customer-facing applied AI: a customer brings raw sensor or video data and a business question, you turn it into a working POC on Newton.

Concretely:

• Review incoming customer assets (video, sensor streams) for feasibility.
• Prepare datasets in Python — cleaning, structuring, imputation, filtering, normalization, signal processing.
• Support labeling and annotation workflows end-to-end (Encord-style tools).
• Iterative preprocessing cycles with evaluation and refinement.
• Design and refine prompts (including n-shot examples) for Newton's "lenses."
• Configure lens parameters for POC runs.
• Summarize results in customer-ready reports.

The defining sentence of the JD

Decoded: they need someone who can take ambiguous customer input and produce a working POC in days, not weeks. The on-site requirement and GTM placement reinforce this — you're embedded with Solutions Architects and Sales, expected to move at the speed of customer conversations.

The stacks, decoded

Fraud/identity stack signals

Multimodal-AI stack signals

The shared spine

Strip away the seniority and the domain, both roles share five core competencies:

1. End-to-end ownership. From raw data to shipped artifact. No "ML engineer takes it from here" handoff.
2. Domain insight drives modeling. Both JDs explicitly value depth in their respective domains (fraud / sensor data) over methodological novelty.
3. Iterative preprocessing. The work is in the data, not the model — feature engineering for the fraud-domain archetype, signal processing and prompt iteration for the multimodal-AI archetype.
4. Production discipline. Even the company's notebook-heavy workflow expects results to be reproducible and reliable.
5. Cross-functional fluency. Fraud-domain: work with engineering, risk ops, data acquisitions. Multimodal-AI archetype: support Solutions Architects, Sales Reps, customers.

The seniority delta

The fraud-domain Staff role is senior (6+ yrs PhD / 8+ yrs MS). The multimodal-AI Solutions-Engineering role is mid-level (4+ yrs). The delta shows up in:

• Autonomy and scope. The Staff-DS role expects you to own a fraud domain as the technical authority. The Solutions-Engineering role expects you to own assigned POCs. Both are "ownership," at different scopes.
• Architecture vs application. The Staff DS shapes the modeling approach for an entire fraud product line. The Solutions-Engineering DS applies an existing platform to customer data.
• Influence on the technical bar. Staff-level signal is setting standards for the team; mid-level signal is hitting them.
• Comp. Staff fraud-DS: ~$220–260k + equity. Mid-level multimodal-AI: ~$150–200k base depending on seniority.

Soft signals to expect

• "Deep domain understanding" (fraud-domain JDs) / "thrive in high-ambiguity" (multimodal-AI JDs). Both signal that the work isn't well-scoped. You'll be defining the work as much as doing it.
• "Production code and tests" (Staff-DS JDs) / "bias for action" (Solutions-Engineering JDs). Different framings of the same expectation: ship things, don't deliberate.
• Corporate values lists are common in fraud-domain fintech JDs with phrases like "Follow Through," "Deep Understanding," "Whatever It Takes," "Do Something Smart." Pattern-match your stories to whatever values the company publishes.
• "Startup-ready mindset" appears in Solutions-Engineering JDs. They want someone who's been in early-stage chaos before, not a first-time startup hire.

What to ask them

fraud-domain-flavored

• "How does the staff DS role on Application Fraud differ from the role on Identity? Where do their problems overlap?"
• "What does the average week look like for someone two years into this role?"
• "How do you handle the tradeoff between rigorous experimentation and shipping fast in production?"
• "How does the DS team work with engineering on real-time inference performance?"

Solutions-Engineering-flavored

• "Walk me through a recent POC end-to-end — what came in from the customer, what came out, what took the most iteration?"
• "Where does the boundary sit between platform engineering and the work this role does?"
• "What's the typical cycle time from a customer asset arriving to a testable result?"
• "How do you handle a POC that's looking infeasible — what's the kill or escalate path?"

Universal

• "What does failure look like in this role at 90 days? At a year?"
• "What's the trajectory from this role to the next?"
• "What does the team feel under-resourced on right now?"