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.

The financial institution — the deployer

Governing body

BOARDA×1

1st line — own & run

BIZA×6PRODA×4INFOSECA×2USER

2nd line — oversee & challenge

AIGOVA×6TRMCOMP

3rd line — assurance

AUDIT

▲ build / provide

MDEVPLATSYSTOOLVENDOR

Where the single A lands, by dimension

1. Assess & bound the risks upfront→BOARDAIGOVBIZINFOSEC

2. Make humans meaningfully accountable→AIGOVBIZ

3. Implement technical controls & processes→BIZPROD

4. Enable end-user responsibility→BIZ

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

All dimensions1234

Show provider roles (external value-chain roles — mostly inferred)

Governance activity	BOARD	AIGOV	BIZ	PROD	TRM	INFOSEC	COMP	USER
1. Assess & bound the risks upfront §2.1
Define permitted use cases & data-access limits	C	A	R	C	C	I	C	I
Use-case risk assessment (incl. system complexity & third-party)	I	A	R	R	C	C	C	I
Threat modelling / taint tracing	I	C	I	C	C	A	I	I
Define agent limits — tools, autonomy, least-privilege	I	C	A	R	C	C	I	I
Define agent identity & authorisation	I	C	C	R	C	A	I	I
Evaluate & accept residual risk	A	R	C	I	R	C	C	I
2. Make humans meaningfully accountable §2.2
Allocate responsibilities across the value chain — contracts / T&Cs	I	A	C	I	C	C	R	I
Define significant approval checkpoints & action boundaries	I	A	C	R	C	C	I	C
Perform runtime human approvals		I	A	C	I	I		R
Audit oversight effectiveness (override rate, response time)	I	A	C	R	C	C	I	C
Develop internal capabilities for adaptive governance	I	A	R	R	R	R	R	R
3. Implement technical controls & processes §2.3
Design & implement technical controls (prefer structural over prompt-layer)	I	C	C	A	C	R	I	I
Pre-deployment testing (accuracy, policy, tool use, multi-agent)	I	I	C	A	C	R	I	C
Gradual / phased rollout	I	C	A	R	C	C	I	I
Continuous monitoring & incident response (deny-by-default, fallback)	I	C	I	A	C	R	I	I
Change management & version control	I	C	C	A	C	C	I	I
4. Enable end-user responsibility §2.4
End-user transparency (UI disclosure, range of actions, escalation)		C	A	R	I	I	C	C
End-user education & training		C	A	R	I	C	I	C/R
Maintain tradecraft / business continuity	C	I	A	C	C	I	I	R

A — Accountable (one per row)R — ResponsibleC — ConsultedI — Informeddotted = inferred

Select a cell for its meaning and basis. Every row has exactly one A — but here it distributes across functions (use-case → the business owner; AI risk & governance → the AI Governance Office; security → Information Security). It still never leaves the deployer.

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.

---

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.