Guidelines vs. Notices — the Distinction That Actually Matters
MAS publishes both TRM Guidelines and TRM Notices, and conflating the two is the most common mistake we see. The Guidelines are best-practice recommendations. The Notices are legally binding requirements for MAS-regulated financial institutions, with real supervisory consequences for non-compliance. If you're building for a licensed entity, the Notice is what your architecture needs to satisfy — not just the spirit of the Guidelines.
Recovery Objectives, Engineered
Critical systems are required to recover within a 4-hour Recovery Time Objective (RTO), validated through annual disaster recovery testing — not assumed from an architecture diagram. Recovery Point Objectives (RPOs) must be set per system based on a documented business impact assessment, defining exactly how much data loss is acceptable in a disaster for that specific system.
A 2026 development worth knowing before you design your monitoring stack: MAS now measures resilience using unplanned downtime hours as the primary metric, not uptime percentage. A system quoting "99.9% uptime" is not automatically compliant — you need to be tracking and reporting actual outage duration, not an aggregate percentage that can hide a single long outage inside a good annual average.
Incident Reporting Timelines Your Systems Need to Support
- 1-hour notification: MAS must be notified no later than one hour after your institution discovers a relevant incident. Your monitoring and escalation pipeline needs to get a decision-maker the right information fast enough to make that call — this cannot depend on someone noticing an alert during business hours.
- 14-day root cause report: A full root cause and impact analysis must reach MAS within 14 days of discovery. If your incident response process doesn't capture a clean audit trail from the first alert onward, reconstructing that report becomes its own project under time pressure.
What the 2026 Amendments Change
MAS's June 2026 consultation paper proposes amendments across IT asset management, IT risk assessment and monitoring, change management controls, and data backup and recovery. If your architecture already treats these as living operational processes rather than one-time audit deliverables, the amendments are a tightening of scope, not a new category of work.
"Treating TRM as a pre-launch checklist is the same mistake we see with every regulatory framework in this region — the requirement is operational, not a document you produce once and file away."
The Practical Engineering Checklist
- Critical system inventory: A documented, current list of which systems are "critical" under your business impact assessment — this drives which RTO/RPO targets apply.
- DR testing cadence: Annual disaster recovery tests against your stated RTOs, with results and remediation tracked, not just performed.
- Downtime-hours monitoring: Dashboards reporting unplanned downtime in hours per critical system, not blended uptime percentages.
- 1-hour escalation path: An on-call and escalation process that can reach a decision-maker and assess "relevant incident" status within the hour, any day of the week.
- Incident audit trail: Logging from first alert onward, structured so a 14-day root cause report can be assembled from existing records rather than reconstructed from memory.
- Change management log: A documented change process for production systems, with emergency changes captured and reported after the fact.
We build for MAS-regulated and MAS-aspiring fintechs delivering into Singapore alongside our BNM-regulated work in Malaysia — the two frameworks share a lot of engineering DNA but differ in the specifics that matter, and we design to whichever applies rather than treating one region as a template for the other.
