MAS TRM Guidelines Checklist for Crypto and Fintech Firms
Quick answer. The January 2021 TRM Guidelines expect board oversight, secure development, never-alone access, sound key management and yearly pentests of internet-facing systems. Binding MAS Notices add a 4-hour recovery objective and 1-hour incident reporting for licensed crypto firms.
Video transcript
The MAS TRM Guidelines are principles, not rules. The binding duties for crypto firms sit in MAS Notices.
Two pairs of Notices bind crypto firms: FSM N13 and N14 for digital payment token providers, and N30 and N31 for digital token service providers.
Both technology risk Notices require a recovery time objective of four hours or less. Firms must also notify MAS within one hour of discovering a relevant incident.
The guidelines expect board oversight, secure development, never alone access and sound key management. Internet-facing systems should be pentested at least yearly.
Before a DTSP license is granted, applicants must pentest their proposed services, fix all high risk findings, and have the fixes independently validated.
The guidelines never mention smart contracts. The DTSP assessment does, and for custodial wallets it looks for multi-party computation or threshold signatures.
Our checklist pairs each chapter with our own crypto example: smart contract audits for software, multisig quorums for access, onchain monitoring for cyber operations.
More may come. Consultation P012 proposes amending FSM N13, though not N30, adding an IT asset inventory with cryptographic assets, immutable or offline backups, and partial disruptions counted as downtime.
Guardian's regulatory readiness assessment works out which provisions reach your business and tests you against each one. Read the full checklist, or talk to Guardian at guardian.security.
MAS published its Technology Risk Management (TRM) Guidelines on January 18, 2021. Its website lists no later revision as of November 6, 2026.
The guidelines set out principles and best practices, not rules. MAS says the degree to which a firm observes their spirit is "an area of consideration" in supervision.
The hard duties sit in MAS Notices. MAS's licensing guidance for digital token service providers also points back to the guidelines by section number.
This article explains the technical and security side of the MAS Technology Risk Management Guidelines and the related MAS Notices. It is not legal advice; confirm how it applies to you with counsel.
Which Texts Apply
MAS lists major and standard payment institutions among the firms the guidelines apply to. Two pairs of Notices bind crypto firms directly.
| Firm | Technology risk Notice | Cyber hygiene Notice |
|---|---|---|
| Digital payment token service provider (Payment Services Act) | FSM-N13, from November 6, 2024 | FSM-N14, from May 10, 2024 |
| Digital token service provider (DTSP) | FSM-N30, from June 30, 2025 | FSM-N31, from June 30, 2025 |
What the Notices require
Both technology risk Notices set the same duties. A firm must:
- identify its critical systems;
- keep unscheduled downtime to 4 hours per critical system in any 12 months;
- set a recovery time objective of 4 hours or less, validated every 12 months;
- notify MAS within 1 hour of discovering a relevant incident;
- send a root cause and impact analysis report within 14 days;
- protect customer information with IT controls.
Both cyber hygiene Notices require:
- secured administrative accounts;
- security patches applied on a risk-based timeline;
- written security standards for every system;
- network perimeter controls and malware protection;
- MFA on critical systems' admin accounts, and on accounts reaching customer information over the internet.
Extra checks for DTSPs
Before a DTSP license is granted, the applicant must pentest its proposed services, fix all high-risk findings and have the fixes independently validated.
After in-principle approval, an independent external auditor assesses its technology and cybersecurity controls. The scope cites TRM sections 11 and 13.2, custodial wallet keys and smart contracts.
What is pending
MAS consultation P012-2026, published June 10, 2026, proposes amending FSM-N13 and other technology risk Notices. FSM-N30 is not on its list.
It would add:
- an IT asset inventory, cryptographic assets included;
- change controls and continuous monitoring;
- immutable or offline backups;
- partial and intermittent disruptions counted as downtime.
It closed on July 31, 2026, with no response published by November 6. Changes would apply 12 months after the final Notice.
Stablecoin issuers face a separate proposal, covered in our post on MAS consultation paper P015-2026.
Governance and Risk
Chapter 3 puts technology risk on the board. Board and senior management should include members who understand it, cyber threats included (3.1.2).
A CIO or head of IT, and a CISO or head of information security, should be appointed (3.1.3).
Security training should run at least annually for everyone with access to information assets, contractors included (3.6.2).
Chapter 4 asks for a risk management framework with named risk owners, and a risk register to track significant risks (4.1.3, 4.5.2).
Banks are in scope too. See digital asset security for banks for what changes when a bank holds crypto.
Software and DevSecOps
Chapters 5 to 7 cover how systems are built and changed.
- Security built into every phase of the development life cycle (5.4.2).
- Security design reviewed by specialists or qualified consultants (5.6.3).
- Secure coding, code review and security testing, with major defects fixed before production (6.1.1, 6.1.7).
- Third-party and open-source code reviewed before use, and tracked for vulnerabilities (6.1.3, 6.1.4).
- Segregation of duties, so no one person can develop, compile and release code (6.3.2, 7.6.1).
- Changes assessed, tested and approved, with a rollback plan (7.5.1, 7.5.5).
The guidelines never mention smart contracts. MAS's DTSP assessment does, checking smart contract development, DevSecOps and testing.
Access and Cryptography
Chapter 9 applies three principles to access: never alone, segregation of duties and least privilege (9.1.1). Its examples of sensitive functions include creating cryptographic keys.
MFA should protect sensitive system functions and remote access (9.1.5, 9.3.1). Privileged account activity should be logged and reviewed (9.2.1).
Chapter 10 covers keys. It expects:
- a key management policy from generation to expiry (10.2.1);
- seeds of sufficient length and randomness (10.1.3);
- sensitive keys in tamper-resistant systems such as HSMs (10.2.4);
- one purpose per key (10.2.6);
- compromised keys revoked and replaced, with any keys they expose (10.2.7);
- protected key backups (10.2.10).
MAS's DTSP assessment goes further for custodial wallets. It looks for multi-party computation or threshold signatures, network isolation, and at least two people on every key operation.
Resilience and Testing
Chapter 8 asks for recovery time and recovery point objectives, and a disaster recovery plan reviewed at least annually (8.2.1, 8.2.2).
Recovery plans should be tested, and backups restored, on a regular basis (8.3.1, 8.4.3).
Chapter 12 expects a security operations center or managed security services, threat intelligence and a cyber incident response plan (12.1.2, 12.2.1, 12.3.1).
Chapter 13 sets the testing program:
- regular vulnerability assessments (13.1);
- blackbox and greybox pentests of online services (13.2.1);
- pentests of internet-facing systems at least annually, and on major change (13.2.4);
- a bug bounty to complement pentests, as an option (13.2.2);
- cyber exercises and adversarial attack simulations (13.3, 13.4);
- remediation tracked with deadlines by severity (13.6).
The Checklist
One line per chapter. The checks follow the guidelines; the crypto examples are ours.
| Chapter | Check | Crypto example |
|---|---|---|
| 3. Governance | CIO and CISO appointed; yearly security training | Signers trained on phishing and blind signing |
| 4. Risk framework | Risk register with named owners | Admin key loss and contract exploit on the register |
| 5. Projects | Security design reviewed by specialists | Protocol design review before the build |
| 6. Software | Secure coding, code review, security testing | Smart contract audit and fuzzing before deployment |
| 7. IT service | Change approval, rollback, release segregation | Upgrades reviewed and tested on a fork first |
| 8. Resilience | RTO, RPO, yearly plan review, restore tests | Failover between RPC providers tested |
| 9. Access | Never alone, least privilege, MFA | Multisig quorum on every admin role |
| 10. Cryptography | Key policy, HSMs, single-purpose keys | Hot wallet keys separate from admin keys |
| 11. Infrastructure | Data loss prevention, segmentation, hardening | Signing systems on an isolated network |
| 12. Cyber operations | SOC or managed service; incident plan | Onchain monitoring of roles and large transfers |
| 13. Assessment | Yearly pentests of internet-facing systems | Exchange web app, APIs and wallet backend tested |
| 14. Online services | MFA at login, signing of high-risk actions, fraud monitoring | Withdrawal address changes signed and alerted |
| 15. IT audit | Independent IT audit, frequency matched to risk | Audit scope includes wallet and key controls |
How Guardian Helps
Guardian's regulatory readiness assessment works out which provisions reach your business and tests you against each one.
Its evidence ledger maps a pentest report with retest to MAS TRM 13.2, and access reviews with MFA coverage to Cyber Hygiene 4.1 and 4.6.
Guardian's operational resilience assessment names critical business services as MAS does, then tests scenarios such as key compromise and a chain halt.
Guardian's pentests cover web apps, APIs, cloud and SDKs, tested for exploitable paths to funds.
Frequently Asked Questions
Are the MAS TRM Guidelines legally binding?
Not in the way Notices are. MAS calls them principles and best practices, and weighs how far a firm observes their spirit. The binding duties sit in Notices such as FSM-N13 and FSM-N30.
How fast must a crypto firm report an incident to MAS?
Under FSM-N13 and FSM-N30, within 1 hour of discovering a relevant incident, then a root cause and impact report within 14 days. A relevant incident has a severe and widespread impact on operations, or materially affects customer service.
How often does MAS expect pentests?
For internet-facing systems, at least once a year or whenever they undergo major changes, under paragraph 13.2.4 of the TRM Guidelines. DTSP applicants must also pentest before a license is granted.
Have the MAS TRM Guidelines been updated since 2021?
MAS lists no revision as of November 6, 2026. Its consultation P012-2026 proposes amending the technology risk Notices instead. It closed on July 31, 2026, with no response published yet.
Sources
- MAS: Technology Risk Management Guidelines (January 2021)
- MAS: Guidelines on Risk Management Practices, Technology Risk (TRM Guidelines page; published January 18, 2021; accessed November 6, 2026)
- MAS: Notice FSM-N13 Technology Risk Management (May 9, 2024)
- MAS: Notice FSM-N14 Cyber Hygiene (May 9, 2024)
- MAS: Notice FSM-N30 Technology Risk Management (May 30, 2025)
- MAS: Notice FSM-N31 Cyber Hygiene (May 30, 2025)
- MAS: Guidelines on Licensing for Digital Token Service Providers (May 2025)
- MAS: Frequently Asked Questions on the Notice on Cyber Hygiene
- MAS: Consultation Paper on Proposed Amendments to Notices on Technology Risk Management, P012-2026 (June 10, 2026)
- Guardian: Regulatory and Compliance Assessments
- Guardian: Penetration Testing Services
Get your MAS evidence ready with Guardian
Guardian tests your systems against the TRM Guidelines and MAS Notices, and maps every pentest, access review and recovery test to the paragraph it answers.