Insights from Katashe Solutions’ response to MAS Consultation Paper P012-2026 on proposed amendments to the Notices on Technology Risk Management
POLICY & TECHNOLOGY
What MAS’s proposed technology risk rules signal for financial institutions operating across cloud, distributed infrastructure and AI
Singapore’s next phase of technology risk regulation is not simply about adding more controls. It is about redefining the boundary of institutional accountability as financial services become dependent on infrastructure that institutions do not fully own or operate.
On 10 June 2026, the Monetary Authority of Singapore published Consultation Paper P012-2026, Proposed Amendments to Notices on Technology Risk Management. Katashe Solutions submitted a response supporting MAS’s objective of strengthening technology resilience while recommending that the requirements remain proportionate, outcomes-based and applicable across different technical architectures.
This article draws out the broader policy implications of that submission. At its centre is a question that extends beyond the individual amendments: how should institutional accountability be defined when financial services increasingly depend on infrastructure that institutions do not fully own or operate? This changes the practical meaning of operational resilience. An institution cannot directly control every dependency, but it remains accountable for the service it provides. Regulation therefore has to distinguish between control of infrastructure and responsibility for outcomes. That distinction runs through the most important issues raised by the consultation.
The perimeter is no longer the service boundary
Financial institutions increasingly assemble services across internal systems, cloud platforms, software supply chains, external providers, distributed networks and AI-enabled tools. The customer experiences one service, even though the institution may rely on many technical layers to deliver it.
Traditional technology risk frameworks often begin with assets owned or operated by the institution. That is no longer enough. A critical service may depend on proprietary software, open-source components, cloud capacity, identity providers, node infrastructure, oracles or other systems outside the institution’s direct control.
The answer is not to require an institution to inventory an entire external network. It is to require a clear view of the dependencies relevant to its own exposure. For a distributed network, this could include the client software it operates, its node or service providers, the network’s finality model, material concentration risks and upgrade dependencies. For proprietary components, it means taking reasonable steps to obtain dependency information, documenting limitations and applying compensating controls where full visibility is not available.
This is why software and cryptographic bills of materials matter. Recognised machine-readable formats such as SPDX and CycloneDX can improve vulnerability management, incident response and obsolescence planning. The depth of mapping should still reflect criticality. Exhaustive dependency records add little value if they become too large to maintain and quickly go stale.
Consistency does not require identical controls
A durable regulatory framework should define the outcomes that matter while allowing indicators and controls to reflect the service and architecture. A single set of numerical key risk indicators for every financial institution would create superficial consistency. Availability, latency, concentration, cryptographic obsolescence and AI risk do not develop at the same speed or carry the same consequences across different systems.
The stronger approach is to define the risk domains that institutions must address, then require each institution to select, calibrate and document the indicators relevant to its systems and risk appetite. Materiality must be explainable and reviewable, but it need not be reduced to one numerical threshold across the sector.
The same principle applies to capacity planning. Annual review provides a useful baseline, but material product launches, architecture changes, utilisation breaches or changes to critical dependencies should trigger an earlier assessment. A calendar alone cannot keep pace with a service whose risk changes between review dates.
Monitoring must extend across the delivery chain
Continuous monitoring should follow the end-to-end service, not stop at the institution’s infrastructure. That includes applications, security controls, identity and privileged access, transaction and data-integrity flows, and material third-party dependencies.
For distributed or programmable infrastructure, conventional uptime measures may miss material changes in the risk environment. A service can remain available even as its rules or control rights change. Depending on the exposure, monitoring may therefore need to include transaction-inclusion and finality delays, node or provider health, privileged smart contract activity, protocol or governance upgrades, changes to administrative authority, oracle or bridge events and anomalous signing or asset transfers.
These indicators should only be used where they support a decision or response. Early-warning thresholds might trigger investigation or enhanced monitoring. Critical thresholds might trigger exposure limits, higher confirmation requirements, a provider switch, a pause in affected functions or alternative processing arrangements.
Continuous monitoring should describe the detection and response outcome, not prescribe one operating model. Automated tooling and qualified managed services can support that outcome, provided the institution understands the methodology, validates the coverage, can act on alerts and retains accountability. For critical external dependencies, the institution should independently monitor the service it receives, rather than rely solely on the provider’s own status reports. This allows it to detect the delays, failures or degraded performance affecting its operations and customers.
Resilience is demonstrated through recovery, not the existence of a backup
The consultation also raises a foundational question: should backups be immutable, offline, or both? Immutability and offline isolation address overlapping but different failure modes. Immutable storage can protect against alteration and deletion while supporting faster restoration. Offline or logically isolated copies reduce exposure to a production compromise, but may introduce handling complexity and longer recovery times.
The regulatory objective should be a complete and reliable copy of the data required to resume the service, protected from the failure modes affecting production. An immutable backup, an offline backup or an equivalent isolation measure may each achieve that outcome depending on how the architecture is designed and tested.
Frequency should likewise follow the service’s recovery point objective, or RPO, which defines the maximum period of data loss the institution is prepared to tolerate. Importantly, the frequency at which data is captured may differ from the frequency at which it is transferred to, or protected within, an immutable or offline environment. Conflating the two can obscure whether the architecture actually meets the approved RPO.
A backup is not evidence of resilience until the institution has tested its integrity, currency and ability to restore the service within approved recovery objectives.
External causes do not erase customer impact
The treatment of outages exposes the same accountability question. From the customer’s perspective, a service is unavailable regardless of whether the immediate failure occurred inside the institution, at a cloud provider or on distributed infrastructure. Automatically excluding externally caused downtime would therefore understate the service outcome.
Recording the downtime does not mean treating every external failure as if the institution caused it. Service availability and supervisory accountability should be assessed separately. The institution’s control environment can be evaluated against the measures reasonably available to it, including due diligence, concentration-risk management, independent monitoring, contingency arrangements, incident response and customer communication.
Consistent measurement also requires clearer treatment of partial and intermittent disruption. Regulators and industry will need common principles for when downtime begins and ends, how recurring periods are aggregated, when a service is considered stable again and how material degradation should be reflected. Without a shared measurement convention, equivalent service failures can produce different reported results.
Incident reporting presents a related challenge. When forensic evidence or root-cause information sits with an external provider, an institution may not be able to complete a definitive analysis within the reporting period. It should still investigate, assess impact, remediate and pursue the missing information. A staged process, with an initial facts-known report followed by material supplementary findings, can preserve both timeliness and accountability.
AI raises the speed of risk, not a separate category of accountability
AI-enabled threats may increase the speed, scale and sophistication of social engineering, credential compromise, malware development, vulnerability discovery, automated fraud and attempts to evade monitoring. AI can also become part of the critical service itself, including through automated decision-making and agentic systems that initiate actions.
The regulatory response should focus on the resulting operational and security risks rather than create a control framework for each new AI technique. Asset and dependency inventories, risk assessment, monitoring, access controls, incident management and recovery remain relevant. Their application should reflect the AI system’s role, criticality and capacity to affect customers or operations.
Singapore is already developing complementary tools for this task. Project MindForge provides practical guidance on governance, materiality assessment, AI inventories and lifecycle controls across traditional, generative and agentic AI. The Safeguards for Agentic Finance at Runtime, published by MAS and industry, adds a reference approach for declaring, authorising, assessing and recording an AI agent’s proposed actions before execution.
Together, these initiatives point towards a useful regulatory architecture: cross-cutting governance at the institutional level, supported by controls applied at the point where an autonomous system acts. The institution remains accountable, but human judgement moves upstream into the design of mandates, limits, escalation rules and intervention mechanisms.
What implementation should prioritise
A 12-month transition should be workable for institutions with mature technology risk frameworks, particularly because many proposals formalise or strengthen practices already reflected in MAS guidance. The harder work will be mapping dependencies, building cryptographic inventories, consolidating telemetry across external services, calibrating thresholds and modifying backup architectures.
Implementation should therefore begin with the critical services and material dependencies through which disruption could cause the greatest customer or operational impact. Risk-based sequencing should not dilute the final standard. It is a way to direct effort to the highest-consequence gaps first.
The larger policy signal
The proposed amendments reflect a wider shift in technology regulation. Institutional responsibility is increasingly defined by the service delivered, not by ownership of every component beneath it. That approach is capable of accommodating cloud, open-source software, distributed networks and AI without pretending that their architectures are identical.
The most effective framework will hold the line on outcomes while remaining precise about what institutions can reasonably control. It will require visibility without demanding impossible knowledge, continuous detection without prescribing one operating model, and accountability without confusing an external cause with an absence of institutional responsibility.
For financial institutions, the strategic implication is clear: third-party and emerging infrastructure can no longer sit at the edge of the technology risk programme. It is now part of the institution’s operating model, and resilience has to be designed accordingly.
Sources and further reading
• MAS Consultation Paper P012-2026 on Proposed Amendments to Notices on Technology Risk Management
• MAS Technology Risk Management Guidelines
• MAS Advisory on Addressing the Cybersecurity Risks Associated with Quantum
• Project MindForge AI Risk anagement Toolkit announcement
• Safeguards for Agentic Finance at Runtime
• OpenZeppelin Technical Risk Assessment on Blockchain Networks
About Katashe Solutions
Katashe Solutions is an APAC-focused strategic advisory and venture-building firm supporting the responsible adoption of digital assets, artificial intelligence and emerging echnologies.
