Evidence boundary: any present-tense QNSI product wording below describes source-declared contracts, architecture targets, or vendor-run artifacts-not independently observed production behavior. Conformance artifacts prove only their stated algorithm scope. End-to-end production execution is NOT VERIFIED.
MAS Technology Risk Management examinations now reach directly into your cryptography, and the quantum clock does not care about your audit calendar: an adversary recording your encrypted traffic today decrypts it the day a cryptographically-relevant quantum computer exists. For the data a Singapore financial institution holds longest - custody records, mortgages, insurance files with 10-25 year confidentiality horizons - 'harvest now, decrypt later' puts the exposure inside the current planning window. And when your team shortlists post-quantum vendors, it hits a second problem: most are US-headquartered, their trust pages enumerate SOC 2 / ISO 27001 / FedRAMP, and MAS TRM is at best a passing mention - leaving your vendor-risk team to derive the control mapping itself and defend it in examination.
Built in Singapore by HEOSSI (PTE.) LTD, QNSI source maps ten MAS TRM controls to KMS, CBOM, Audit, and evidence-pack contracts. Source mapping and service health do not prove control effectiveness; complete deployment behavior remains NOT VERIFIED.
MAS TRM in 60 seconds - and why PQC is now inside it
The MAS Technology Risk Management Guidelines (January 2021) define the technology-risk posture MAS expects of the institutions it regulates - banks, insurers, capital markets services licensees, payment service providers. Thirteen sections; Section 8 addresses cryptography head-on, and Sections 7, 9, 10 and 11 reach it indirectly through system security, data protection, access control and security operations. Compliance is not optional.
What changed is the global overlay now converging on the same message - retire classical public-key cryptography on a deadline:
- NIST finalised FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) in August 2024; FN-DSA remains draft. The algorithms are settled.
- US Executive Order 14412 (June 2026): federal High-Value Assets must use PQC key establishment by 2030 and PQC signatures by 2031, with CBOM minimum elements due within 270 days.
- NSA CNSA 2.0: ML-KEM-1024 and ML-DSA-87, required for new national-security systems from January 2027.
- EU DORA, in force since January 2025, demands encryption and key-lifecycle policy plus demonstrable operational resilience - and PCI DSS 4.0 pushes continuous validation of cryptographic controls.
A Singapore FI inside a global group will be measured against all of it. The practical question is no longer 'do we need a quantum-safe plan' - your examiner already assumes you do. It is which platform turns those obligations into running, provable controls. That is precisely what QNSI is built to be.
The 10 MAS TRM controls QNSI implements for you
The ten bullets below are source-level control mappings, not proof of control effectiveness. Complete enforcement, evidence provenance, and deployment behavior remain NOT VERIFIED:
- TRM 4.1 - IT governance and oversight: compliance evidence packs generated on demand from the portal give your board and senior management a current, defensible view of cryptographic risk - not last year's questionnaire.
- TRM 5.1 - Technology risk management framework: per-tenant crypto policy tiers (default / strict / maximum / government) make algorithm governance enforceable platform policy - which KEMs, which signatures - instead of a document nobody executes.
- TRM 6.1 - Security-by-design: the CBOM crypto inventory defines 11 cloud-vendor connector families and 36 inventory source types plus CycloneDX export. Complete connector execution and estate coverage remain deployment-specific.
- TRM 7.1 - System security: the required design maps PQC-native transport and genuine KEM envelopes to transit, keys, and secrets. Public-edge and data-envelope execution remain NOT VERIFIED.
- TRM 8.1 - Cryptography: the headline control - 87 PQC algorithms (24 KEMs + 63 signatures) with dual-implementation cross-verification, BYOK, 8 capability-gated BYOHSM connector implementations, and per-key rotation policies. Deep dive below.
- TRM 9.1 - Data and infrastructure security: source contracts map SSE-X, encrypted search, Vault versioning, and dynamic credentials to the control. End-to-end protection remains NOT VERIFIED.
- TRM 10.1 - Access control: dual-control maker-checker approvals on crypto-policy changes, tenant deletion and root/master key revocation - no single administrator can weaken your cryptographic posture.
- TRM 11.1 - Cyber security operations: source defines service-health inputs, but liveness does not prove control effectiveness. Complete control evaluation remains NOT VERIFIED.
- TRM 12.1 - Cyber incident management: source defines an ML-DSA audit-chain contract. Complete event ingestion, reconstruction, and forensic suitability remain NOT VERIFIED.
- TRM 13.1 - Audit logging and monitoring: source maps cryptographic and administrative events to the audit contract. Complete event coverage remains NOT VERIFIED.
Inside TRM 8.1 - the cryptography control itself
Section 8 asks for robust, sound cryptographic algorithms and key management practices. On QNSI that translates to specifics: the KMS runs 87 PQC algorithms across 13 families, with the NIST-finalised set - FIPS 203 ML-KEM, FIPS 204 ML-DSA, FIPS 205 SLH-DSA - as the production backbone. Your crypto policy tier pins what is allowed: strict narrows KEMs to ML-KEM-768/1024, and the government tier runs ML-KEM-1024 under FIPS-finalised algorithms only - the same posture CNSA 2.0 mandates.
Key management includes BYOK, 8 capability-gated BYOHSM connector implementations, the current escrow route, which is not threshold recovery and is not presented as available, and per-key rotation policies. Named custody backends require live qualification, and vendor certification remains limited to the qualified device and configuration.
Dual control: change management an examiner can trust
QNSI source defines maker-checker contracts for crypto-policy changes, tenant deletion, and root/master key revocation, plus audit events for requests and approvals. Complete enforcement, identity separation, event ingestion, and deployment behavior remain NOT VERIFIED.
Five lines to a MAS-TRM-aligned secret
The snippet illustrates a source-linked TypeScript SDK call shape. Route reachability, genuine PQC envelope execution, and equivalent behavior across other SDKs remain NOT VERIFIED:
// pnpm add @heossihq/qnsi
import { QnsiClient } from "@heossihq/qnsi";
const qnsi = new QnsiClient({ apiKey: process.env.QNSI_API_KEY! });
// PQC-enveloped secret - ML-KEM-768 (FIPS 203), enforced by your tenant's crypto policy
await qnsi.vault.createSecret({
name: "core-banking-db-credential",
payloadB64: Buffer.from("s3cr3t").toString("base64"),
algorithm: "ml-kem-768",
});Why a Singapore-headquartered platform wins procurement
A vendor without an MAS TRM mapping shifts control-mapping work onto the buyer. QNSI source includes mappings and tier-activation contracts for PDPA, MAS TRM, SOC 2, HIPAA, GDPR, PCI DSS, and ISO 27001. Complete activation and effectiveness remain NOT VERIFIED.
The mapping is inspectable source, but source presence, service health, and generated output do not independently prove tenant-specific control effectiveness or evidence provenance; those remain NOT VERIFIED.
Start now
A workspace can be used to inspect the published surfaces at https://cloud.qnsi.heossi.com/auth?mode=signup. Successful UI or API responses do not independently prove PQC primitive execution or control effectiveness.
MAS-regulated and planning a PQC program? Talk to a QNSI architect at /contact - bring your examiner's questions; we have the control mapping ready.