RACI — FI calibration

An applied calibration — read Topic 03 first

Even more of an interpretation than Topic 03. This takes the Topic 03 template — same four dimensions, same activities — and calibrates it to a financial institution, splitting IMDA’s four illustrative teams into a fuller role set organised by three lines of defence. interpretation

It is one worked example of the “map the columns to your real org” step, not a prescription. Re-derive every cell for your actual structure.

Two things make this more than guesswork. The paper’s PwC worked example already uses a granular split — Use-case owner, Technology Risk Management Team, AI Factory (≈ product/engineering), End users §2.2.1, pp.27–28 — and Topic 03’s own calibration note suggests adding “a dedicated AI Governance Office, Legal/Compliance, or DPO.” The accountability logic follows MAS MindForge interpretation: assign each row’s single A to the function with the most control over that activity — while accountability never leaves the institution.

The FI role set — three lines of defence

The deployer is the institution; internally it is split across the governing body and the three lines of defence, plus the external provider roles (unchanged from Topic 03):

Lines of defence — who executes vs who challenges. The split follows the IIA’s Three Lines Model: the 1st line owns and runs the agent, the 2nd line oversees and challenges, and the 3rd line (Internal Audit) gives independent assurance. Two distinctions matter here:

• Information Security (1st line) vs Technology Risk Management (2nd line). INFOSEC is the front line — it executes technical controls, threat defence and incident response (“how we protect it”). TRM is independent oversight — it challenges the 1st line and runs risk assessments to test whether those controls are adequate (“why we do it”), following MAS’s Technology Risk Management Guidelines. TRM is the inherited technology-risk discipline that predates AI as a distinct concern. interpretation
• The AI Governance Office (2nd line) is the newer function, stood up to give explicit focus to GenAI and agentic-AI risk — model behaviour, autonomy, agentic harms, AI policy, and AI-related third-party risk — as those risks become more material.

Operational risk is not shown here for simplicity; some firms run it as a separate Operational Risk Management function.

Frameworks referenced (not IMDA): the lines-of-defence structure follows the IIA Three Lines Model (2020); the technology-risk lens follows the MAS Technology Risk Management Guidelines (Jan 2021). RACI itself is defined in PMI’s PMBOK Guide (see Topic 03).

The diagram maps those roles onto the three lines of defence and shows, with an A×N badge, how many activities each is Accountable for; the providers feed in from outside the institution boundary. Click a role for its duties and the rows it owns.

3rd-line Internal Audit is shown but sits outside the matrix for width; add it as an assurance column that is I on most rows and C on governance design. interpretation

The matrix

How the A redistributes

In Topic 03 the single A always sat with one team (the deployer’s Key decision makers). Splitting the org makes the A land with the function that has the most control over each activity:

• BIZ — use-case appropriateness & limits, phased rollout, end-user transparency, education, and business continuity.
• AIGOV — AI-specific use-case risk assessment, permitted-use-case policy, approval checkpoints, oversight-effectiveness audit, adaptive-governance capability, and value-chain responsibility allocation.
• PROD — technical controls, pre-deployment testing, monitoring & incident response, change management.
• INFOSEC — threat modelling and agent identity & authorisation.
• BOARD — accepting residual risk against risk appetite.

TRM and COMP hold no single A here — as 2nd-line functions they consult and challenge across the rows rather than own them. Every row still has exactly one A, and accountability never leaves the institution — the A just sits with the right internal function. interpretation

MindForge alignment

Cross-reference — MAS MindForge (not IMDA text). This calibration follows MindForge’s rule: assign final accountability to the party with the most control over an action (MindForge p.128). That is exactly why the A distributes across functions here rather than sitting on one team.

For a financial institution, accountability stays with the FI regardless of build-vs-buy, and MindForge points FIs to this IMDA framework for implementation detail — so the two are complementary. interpretation

Calibrate further — FI open decisions

Decide these for your own structure rather than inheriting the defaults: interpretation

• Add 3rd-line Internal Audit as an independent-assurance column (I / C), and decide whether BOARD or a delegated risk committee holds the residual-risk A.
• Senior management vs board. Large or higher-risk use cases may escalate the residual-risk A from BIZ to BOARD — calibrate by autonomy tier and materiality (see Topic 03’s Dayos / MSD / OCBC tiering).
• Where AIGOV (AI risk) and TRM (technology risk) overlap. The two risk lenses meet on the same use case — have them co-assess rather than contend, with AIGOV leading the AI-specific risk and TRM the technology-risk challenge.

Onboarding scenarios — the FI calibration

The matrix above calibrates the general scaffold. The three tables below calibrate the onboarding lifecycle — intake → due diligence → security & data → build & guardrails → testing & red-teaming → approval → deploy & monitor — for a financial institution, across the same functions and three lines of defence. interpretation

The key rule you asked for: there is always an internal corresponding party for accountability. However many external providers are in the chain, and however much work they do, the single A is always an internal function — providers only ever consult or are responsible within their remit (C / R), never A. The A lands by who has the most control:

• BIZ — use-case intake, scope, user training & rollout.
• AIGOV — risk-tiering, autonomy bounding, model-behaviour / bias / safety red-teaming, agentic & systemic risk, process guardrails, and behaviour/drift/agent monitoring.
• TRM — vendor & model-risk evaluation, independent validation, supply-chain/SBOM, vendor-version & third-party governance, performance/drift monitoring, audit.
• INFOSEC (1st line) — security & data config, provenance/weights integrity, technical guardrails, the security / injection / exfiltration / tool-misuse red-team rows, and security & abuse monitoring.
• PROD — tech-stack, model config, RAG, the build, functional testing & deployment.
• COMP — licence, contracts/DPA & outsourcing-regulatory review.
• BOARD — risk acceptance & sign-off.

So when a model developer, platform or tooling provider does the work, the matching internal owner above carries the A and the provider sits as C (or C/R on contracts). Toggle the provider columns on to see the external party against its internal owner.

Scenario A · external proprietary model

Onboarding a closed vendor model (Claude / Claude Code, OpenAI / Codex, Gemini). For an FI this is squarely an outsourcing / third-party arrangement — and outsourcing the technology does not outsource accountability. You can’t validate the model, so assurance is contractual, configurational and monitoring-led; the vendor (VENDOR / MDEV / PLAT) supplies disclosures and contract terms as C / C/R, while TRM, AIGOV, INFOSEC, COMP and the BOARD hold every A.

Scenario B · open-source / self-hosted model

Self-hosting an open-weight model makes the institution the developer-deployer — accountability sits wholly with the FI, with no vendor to share risk. The extra activities (licence clearance, provenance & weights integrity, AI-SBOM, infrastructure hardening, in-house model-risk & guardrail build, fine-tuning/adapter governance) all resolve to an internal A — mostly INFOSEC (provenance, weights, infra, guardrails), TRM (validation, SBOM, drift) and AIGOV (bias/safety, change management) — while MDEV / TOOL appear only as upstream C.

Scenario C · integrated agentic solution + tools

A multi-provider chain — model developer, platform/orchestration provider and several tool/MCP providers inside one agent — yet the FI stays fully accountable for the whole chain. Diligence is per-provider and per-tool; the new seam-risks (tool poisoning, identity/privilege abuse, multi-agent cascades) make INFOSEC A for vetting, containment and the agentic red-team rows, and AIGOV A for systemic risk and agent-behaviour monitoring; TRM owns chain-wide third-party governance and exit; each external provider (MDEV / PLAT / TOOL / VENDOR) sits as C / C/R.

Frameworks referenced (not IMDA). These onboarding tables draw on the MAS Guidelines on AI Risk Management and MAS TRM Guidelines, the NIST AI RMF + GenAI Profile, ISO/IEC 42001, OWASP LLM & Agentic Top 10s, the GovTech ARC framework, and model-risk discipline from SR 11-7. Accountability allocation follows MAS MindForge (the party with most control).

End of the R&R track. Topic 01 mapped what an agent is and where its boundaries sit; Topic 02 mapped who the parties are; Topic 03 turned that into a calibratable allocation; and this topic calibrated it for a financial institution. The natural next step is to pressure-test the matrix against one or two concrete agents — a coding assistant, a customer-service agent — and record where the A and the cells move.