Senior Python/FastAPI Engineer — Risk Register, Approval Workflows & KRI Monitoring

About the work We are an AI-native GRC (Governance, Risk & Compliance) platform serving regulators, national energy operators and financial institutions across the Gulf. The product is a multi-tenant, bilingual (Arabic/English, RTL-ready) FastAPI + PostgreSQL platform with a React frontend. We are building out our Enterprise Risk Management module and are looking for a senior engineer to take it from a written product definition to a working, audit-ready feature. The module covers the full risk lifecycle: identification, assessment, review and approval, treatment, evidence, KRI monitoring, escalation and scheduled reassessment — with an AI layer that proposes risks, scores, controls and treatment plans for human review. This is substantial, multi-month work on an existing production codebase with an established architecture and conventions. We are not looking for someone to green-field their own design; we are looking for someone who can build carefully inside ours. What you will build The module is delivered in gated milestones. Each is signed off against a demonstrable acceptance criterion before the next begins. Risk data model, roles and permissions. Five distinct actor roles (GRC user, risk owner, control owner, risk reviewer/manager, executive approver) with genuinely different capabilities. Risk records carry a lifecycle stage and a status — draft, pending review, revision requested, approved, treatment pending, under monitoring, reassessment due, accepted, closed/cancelled, rejected — and the permitted transitions between them are not a free-for-all. Risk register, manual entry and bulk import. A register view over the full portfolio, a structured new-risk form, and an importer for organizations bringing an existing risk register with them. Duplicate detection. Incoming risks checked against the existing register on title, category, owner, process and description, with merge / link / update paths rather than a blunt reject. Multi-stage review and approval workflow. Reviewers approve, reject or request revision, always with mandatory justification. Revision requests round-trip to the owner and back. Approval authority is driven by a configurable authority matrix — lower-severity risks clear at manager level, high and critical risks escalate to executive approval — because every client's matrix is different. AI risk intelligence layer. Generating a draft risk appetite statement and risk universe from captured organizational context; proposing inherent scores, controls, key risk indicators with thresholds and measurement criteria, owners and review frequencies; recommending treatment strategies. Everything the AI produces is a proposal pending human approval — never authoritative on its own. Getting that boundary structurally right matters more to us than getting it fast. Treatment management. Treatment strategy and plans with due dates, action tracking, evidence of implementation, reviewer verification of completion, and residual risk recalculation once control effectiveness has been re-evaluated. KRI monitoring and breach handling. Scheduled KRI data collection with a manual fallback, value and trend calculation, green/amber/red threshold evaluation, breach event creation, AI breach analysis, and escalation paths that feed back into reassessment. Reassessment triggers. Scheduled dates plus event-driven triggers — KRI breach, control failure, overdue treatment action, regulatory change, material business change — each routing into the right stage of the workflow. Dashboards, audit trail and reporting. Portfolio metrics, exposure, severity/likelihood/treatment trends, and a complete review and approval history that stands up to an external auditor. Tech stack Python 3, FastAPI, SQLModel, Alembic, asyncpg, PostgreSQL Async-first codebase, hexagonal / ports-and-adapters structure, strict multi-tenant isolation LLM integration for the AI layer React (function components and hooks), Vite; logical CSS properties for RTL readiness pytest, ruff, uv for dependency management Must have 5+ years backend Python, with deep and demonstrable FastAPI and async SQLAlchemy/SQLModel experience Real experience building state machines and multi-stage approval workflows — not just CRUD APIs with a status column Multi-tenant SaaS experience, with a working understanding of why tenant scoping belongs at the data-access boundary rather than in each handler Comfortable writing Alembic migrations against a live schema Production LLM integration: structured output, validation of model output, confidence handling, graceful degradation when the model is wrong or unavailable React competence sufficient to build the workflow UI, not only the API behind it Tests that assert behaviour. Every PR ships with pytest coverage. Nice to have Prior GRC, enterprise risk, internal audit or RegTech domain exposure — ISO 31000, COSO ERM, ISO 27001 or similar Experience with scheduled jobs, event-driven patterns (domain events, transactional outbox) and notification fan-out Arabic language capability, or prior work shipping RTL/bilingual products How we work Fixed-price, milestone-gated. A milestone is not closed until its acceptance criterion is demonstrated end-to-end on a test tenant. Data model, workflow state machine, authority-matrix configuration and AI prompt/judge design are approved by the CTO before implementation starts. We would rather spend a day on the model than a week undoing it. Small, reviewable PRs. Hard stop before any commit touching shared or core modules without prior sign-off. Where documentation and the actual codebase disagree, we expect you to raise it rather than silently reconcile it. We flag unresolved decisions explicitly instead of inventing a default and moving on. We expect the same. Timeline and commitment Milestone dates are set after technical review and effort estimation — we would rather agree a schedule with the engineer who will actually build it than impose one. In your proposal, please give us your own estimate for the first milestone (risk data model, roles, permissions and the register base screens) and tell us how much time per week you can commit. We work Gulf Standard Time (GMT+4) and need meaningful daily overlap. What we share after NDA We have a full internal Process Definition Document for this module, the complete workflow diagram covering every decision point and notification trigger, the risk register field specification, and UI reference designs for the dashboard, control readiness, treatment and KRI screens. Once an NDA is signed we will send across everything needed to scope and build the work accurately. We are not going to ask anyone to estimate blind — but we are also not publishing our product design on a job board, so the detail comes after the NDA.