FCA–NVIDIA AI Sandbox: a launch feature shipped in one week

Context

The UK’s Financial Conduct Authority partnered with NVIDIA to give regulated financial institutions a supervised environment for AI experimentation — the FCA AI Sandbox, presented publicly in early June 2025. NayaOne provided the platform layer. The launch date was set by the regulator’s public event, not by our sprint planning.

Problem

A week before the event, the launch still needed its product front door: a module where the programme could present its AI offerings and take structured applications from participating firms, inside the platform’s existing compliance boundary. The marketplace flows the platform already had didn’t model a programme with an application-and-approval intake. Miss the date and the company misses its moment as the platform behind a regulator–NVIDIA launch.

Constraints

• A fixed public date with a regulator and NVIDIA attached to it — no negotiation.
• The module had to land on a live platform serving 80+ financial institutions without putting any of them at risk.
• No special process: the one-week feature went through the same review, tests, and scheduled release train as any other change.

My role

I built the module end-to-end — the GraphQL API and data model, the Vue frontend, and the tenant configuration for the programme’s environment — while leading the five-person product engineering team through the same week.

Approach

Extend, don’t invent. The platform already had primitives for programmes and events; the new module built on them instead of introducing a new subsystem. Institutions publish offerings, firms apply, and applications move through an approval-gated review workflow with an operator-facing table.

Everything shipped dark behind per-module feature flags, rode the normal scheduled release, and sat inert in production while the programme’s environment was prepared through configuration — terminology, disclaimer banners, branding. Launch day was a flag flip, not a deploy.

Key decisions

• Extend existing primitives instead of building a subsystem. One week is enough only if you refuse to build a platform in it; reusing the existing domain model bought the schedule.
• Feature flags decouple deploy from launch. The code merged days early and sat dark in production — the risky moment moved from “deploy under pressure on launch day” to “flip a flag.”
• Tenant-specific behavior through configuration, not code. Programme wording, compliance disclaimers, and branding were config; the module stayed generic instead of becoming one-off event code.
• Cut to the workflow the event demanded. Publish, apply, review — everything else was explicitly scheduled for after the date.

Trade-offs

The day-one version was deliberately thin: UI refinements and secondary affordances landed in the weeks after the event. I accepted visible post-launch iteration in exchange for zero schedule risk — the reverse trade wasn’t available. The flags themselves had a cost too: they multiplied the states to test in a week where testing time was the scarcest resource.

Result

The module shipped on schedule for the June 2025 launch, and NayaOne became an official FCA technology partner. Because it was built as a generic platform capability rather than event scaffolding, it stayed in the product as a standard module for other tenants after the event instead of being thrown away.

What I’d do differently

The week was survivable because the platform happened to have the right primitives to extend — that was as much luck as design. I’d turn the pattern that saved us — ship dark on the release train, launch by flag, brand by config — into an explicit playbook, so the next immovable date doesn’t depend on the primitives happening to fit.