Quant Dev - Pricing & Risk Stack

Quant Developer - Curves & Risk

Pricing & Risk Stack

Pricing & VaR platform engineering

6 month contract

£700-£770/day OUTSIDE IR35

Central London, 4 days/week onsite

MUST have experience of oil and/or gas/LNG commodities trading environment

MUST have current authorisation to work unrestricted in UK currently and for the next 12 months without need for sponsorship

MUST be prepared to work onsite in central London 4 days/week

The role

We're hiring a strong engineer — someone who builds, not someone who waits to be told what to build — to work intensively on the core of our pricing stack: market data, the curves platform and the VaR platform. You'll be writing the distributed Python that turns market data and curves into risk at scale on AWS and Ray, with enough functional understanding of commodities to challenge the requirement, not just implement it.

Context

Pricing & Risk Technology owns the chain that turns raw market data into curves, and curves plus positions into P&L and risk. Two platforms sit at the heart of it:

• Curves — the engine that defines and constructs every derived curve we run on, from vanilla forwards through to complex and functional curves built on top of other curves, with real dependency depth.
• VaR / Risk — the platform that takes marks and positions and turns them into risk, at the scale and speed the business needs.

Both are Python, both run on AWS, and both increasingly lean on Ray for distributed compute — parallelising curve construction across large hierarchies and running risk/scenario grids that don't fit on one box. This role is for the engineer who makes that stack fast, correct, and ready to move from end-of-day toward intraday.

What you'll actually do

• Build the curves platform. Engineer the construction engine — the dependency graph / DAG that resolves which curves feed which, incremental and parallel recalculation when a base curve moves, caching, and the abstractions that let complex and functional curves be defined cleanly rather than hard-coded.
• Build the VaR / risk platform. Engineer the distributed risk compute — scenario generation, P&L vectors, aggregation — and make it scale horizontally on Ray clusters without becoming fragile or opaque.
• Make it distributed and fast. Use Ray (Core, actors/tasks, and the right primitives) to parallelise heavy numerical workloads; profile, vectorise, and tune so the grid finishes in the window the business actually has — and so intraday becomes realistic, not aspirational.
• Own it on AWS. Design and run cloud-native services — compute, storage, containers, infra-as-code — with the reliability, observability and cost-awareness of someone who owns production, not someone who throws code over a wall.
• Engineer for correctness. Strong testing, sensible CI/CD, code review, and the discipline that matters when the output is numbers people trade and report on. A wrong-but-fast risk number is worse than no number.
• Partner across the chain. Work shoulder-to-shoulder with the techno-functional / middle-office side of the team, with desk quants and with market-data engineering — turning functional specs into well-architected systems and pushing back when the spec is wrong.
• Push the AI tooling. Use our in-house AI tooling hard — to accelerate development, generate tests and scaffolding, investigate data and performance issues, and compress the build loop. We expect engineers here to set the pace on this, not watch it happen.

What you'll need (must-haves)

• 5–9 years building production software, with a track record of owning meaningful systems end-to-end.
• Strong, idiomatic Python — performance-aware, well-tested, well-structured. Comfortable with the numerical stack (NumPy/pandas or similar) and with what makes Python fast or slow.
• Distributed / parallel compute experience — ideally Ray, but strong experience with another distributed framework (Dask, Spark, Celery, MPI, custom grids) and the appetite to go deep on Ray counts.
• Solid AWS — you've designed and run services in the cloud (compute, storage, containers, IaC) and you understand the trade-offs, not just the buttons.
• Real software-engineering maturity — system design, testing, CI/CD, observability, performance profiling. You care about correctness and maintainability under pressure.
• Functional knowledge of commodities (in particular, oil and gas/LNG) — enough understanding of curves, pricing, P&L and risk (in oil, power and/or gas) to build the right thing and challenge a flawed requirement. You don't need to have run a desk, but you can't be blind to the domain.
• A challenging, ownership mindset — you ask why, you propose better, and you drive it through. We are explicitly not looking for a passive ticket-taker.

Nice to have

• Hands-on Ray at cluster scale (Ray Core, Ray Data, autoscaling).
• Experience with VaR / risk engines
• Experience building curve construction or pricing libraries / DAG-based calculation engines.
• Time-series and market-data pipelines at scale (exchange/broker feeds).
• Intraday / near-real-time risk or P&L experience.
• Hands-on use of AI/LLM tooling in a development workflow.
• A quantitative or numerical background.

Who you are

• An engineer first — you take pride in systems that are fast, correct and clean, and you own them after they ship.
• High energy, dynamic, opinionated — you move quickly and bring a point of view.
• A challenger, not a doer-by-rote — you'll tell us when the design is wrong and bring a better one.
• Curious about the domain — you want to understand the curves and the risk you're computing, not treat them as a black box.
• Bias to build — you'd rather prototype on the cluster this week than write a design doc for a quarter.

What success looks like in the first 12 months

• The curves and VaR platforms are demonstrably faster and more scalable on Ray — grids that were tight now have headroom.
• You own a meaningful slice of the stack end-to-end, in production, with the reliability and observability to prove it.
• At least one concrete step toward intraday curves/P&L/risk has shipped because the compute can now support it.
• The codebase you touch is better engineered than you found it — tested, clear, and easier for the next person.
• AI tooling is visibly accelerating your delivery, and you're raising the bar for how the team uses it.