AI/ML Engineer, Innovation Lab (AI & Analytics Lab), Business Technology

The lab builds AI-enabled products for the bank. Some are already live; others are still being scoped as POCs. The work whatever the the brings us us: retrieval-augmented systems over internal knowledge, agents that interact with the bank's tools and data, classification and extraction pipelines, decision-support interfaces over ML models, and the frontends and APIs that make all this usable.

You'll build production software with significant AI components, inside a regulated environment. This includes designing services that hold up under load, fail safely, instrument themselves, and remain operable when an AI component is slow, wrong, or upgraded by its provider. AI literacy is a bar requirement: you can call an LLM, integrate with a classifier, and reason about prompt injection and data leakage. But it isn't the headline of the role. The headline is that you build software that survives contact with reality.

We're looking for someone two years into their engineering career who's been building software with system design in mind and is genuinely AI-literate. Not someone whose primary value is integrating AI components, but an engineer who'd have been strong in software engineering and who has since picked up real AI literacy as part of their craft.

• Build Production Software End-toEnd: Take scoped projects from design through ship: APIs, services, frontends, integrations. Own them. Design the small systems within an established architecture, with senior review on the design before you write the code. Document your reasoning clearly enough that an independent reviewer can follow it.
• Design systems that don't fall over: Reason about latency budgets, fault tolerance, graceful degradation, state management, and observability before writing code. Plan for what happens when the LLM is slow, the vector store times out, the foundation model is upgraded by the provider, or the user input is adversarial. The system you ship should still work when those things happen.
• Treat software craft as part of the bar: Write code that meets the team's internal standards for style, maintainability, testability, and review. Treat prompts, schemas, and configs as first-class artifacts under version control. Test what matters. Read and debug other people's code. Engage productively in code review, both giving and receiving.
• Integrate with AI systems literally: Wire up LLM calls, retrieval, structured output, tool use, and consume predictions from ML models built by the ML Engineering team. Know when an LLM is the right tool, and when it isn't. Push back when a use case doesn't fit a foundation model or doesn't justify the operational cost.
• Instrument the systems you ship: Logs, metrics, traces for prompts in and responses out, error budgets, and user-facing quality signals. Catch obvious failure modes before stakeholders do. Catch the subtle ones too: model drift, retrieval-index regressions, latency creep. You do this by designing for it from day one.
• Take prompt injection and data leakage seriously: Treat them as first-class engineering concerns, not security theatre. Think about what an adversarial input could make the system do, what information could leak through outputs, and design defences accordingly.
• Work within model governance: When the system you build includes an AI component, document the components that require MRM (Model Risk Management) review: prompts, retrieval sources,tool surfaces, guardrails, evaluation results, and known failure modes. Document them clearly enough for an independent reviewer. You are not the owner of the model's behaviour or its governance package. That's the ML Engineer's role. You are the owner of the system the model runs in, which has its own documentation burden.
• Teamwork: You'll often work alongside two or three other engineers on the same project for a period, then move on to a different mix. This means strong written communication, clear decision logs, and effective onboarding for teammates cycling in. Solo heroics aren't the model
• Collaborate across functions: Translate between business stakeholders, the AI/ML Engineering team, validators, and downstream production teams. Ask clarifying questions when requirements are ambiguous. Make trade-offs visible: say what your system can and can't do, where you're uncertain, and where the design has limits.
• Grow your craft: Engage thoughtfully in code reviews. Seek out mentorship from senior engineers. Build the habits that compound into staff-level skill over time: reproducibility, testing, observability, and decision logs.

What success looks like in this role

In your first year, we'll know this hire is working if:

• You ship. At least one significant system or feature you've built makes it to live use, with sound design, proper instrumentation, and documentation that holds up under review.
• Your work holds up under scrutiny. Your systems pass governance review without major rework.
  Stakeholders trust what your system does and trust you when you tell them what it can't do. Other engineers can pick up your code and extend it.
• Your judgment grows. By first year, you're scoping projects and small system designs with less guidance, recognising when a simpler approach is the right answer, and pushing back when a use case doesn't fit what AI can do or what the system can sustain.
• You raise the team's bar. Your code reviews are useful to peers. You contribute to internal practices that make the next project easier: design templates, observability patterns, shared tooling.

• Academic Qualifications: Bachelor's in Computer Science, Software Engineering, or a related technical field; equivalent experience considered.
• Working Experience: Minimum 4 years of professional software engineering experience, including at least 2 years focused on hands-on work building systems that integrate with AI components
• Software engineering fundamentals. You've built and shipped real product code in our stack. TypeScript with React on the frontend, and Node.js with Express or Fastify, or Python with FastAPI on the backend. This includes code that real users or internal consumers have depended on, with proper API design, error handling, testing, and deployment. Writes code that meets internal standards for style, maintainability, and testability. Comfortable with Git, code review, CI, and reproducible workflows. Coding-assistant fluency is assumed, not differentiated
• System design. You can design small systems within an established architecture, under senior review. Given a scoped problem, you can sketch the components, design the API contract, identify the failure modes that matter, and justify the choices. You don't write code before you've thought about how the system behaves when things go wrong.
• AI literacy as a bar requirement. You've built things with LLMs at production or near-production quality: RAG, structured output, memory, tool use, basic agentic patterns. You've used and trusted the outputs of an ML model someone else built. You understand prompt injection and data leakage as engineering concerns. You know what an LLM eval is and why it matters, even if eval methodology isn't your speciality.
• Production instincts. You instrument what you ship. You don't trust offline metrics to predict live behaviour. You've supported live systems in production. You've handled an incident, written a postmortem, and shipped the follow-up actions. You've debugged something in production that wasn't reproducible locally.
• Ownership and curiosity. You confidently ship small features with minimal guidance and collaborate well in larger projects. You take responsibility for the quality of your work and don't wait to be told what to fix. You ask for help when you're stuck rather than spinning. You read papers and try things, and you also know when not to.
• Communication. You write design docs people can follow. You can explain what your system does and where it might fail in plain language to a stakeholder, and in technical detail to a peer reviewer. You can disagree productively when the requirements don't match what the system can sustain.

Nice to have

• Prior exposure to banking, fintech, or another regulated industry.
• Familiarity with model risk management concepts and how they apply to non-deterministic systems.
• Hands-on experience with LLM orchestration frameworks (LangChain, LlamaIndex, DSPy, or comfortable without one) and vector stores.
• Exposure to LLM observability and tracing tools (Langfuse, Arize, or equivalent)
• Awareness of prompt injection, jailbreaking, and data exfiltration patterns; defensive design experience.
• Familiarity with cloud AI platforms (AWS Bedrock, Azure OpenAI, GCP Vertex AI) and self-hosted inference.
• Experience with SQL on production data warehouses; comfort with the bank's data shape.
• A track record of refactoring or rescuing systems someone else built. A strong signal of software craft.