MAS-aligned fintech in Singapore: the architecture conversation

The Monetary Authority of Singapore (MAS) regulates Singaporean financial services with a posture that is precise, principles-based, and operationally exacting. The Technology Risk Management Guidelines (TRMG) and the Outsourcing Guidelines together define a set of expectations that every Singapore-licensed fintech CTO needs to internalise before architecture decisions are made — not after.

This post is the architecture-level view of what MAS-alignment requires for a Singapore wealth-tech, payments, or licensed fintech operator. It is not legal advice; legal counsel is non-negotiable. It is what we ship into MAS-regulated environments after consulting with that legal counsel.

The TRMG framing

TRMG is structured around five high-level domains: governance, identification of critical systems, security controls, monitoring + incident response, and resilience. The architectural implications are concentrated in three of those:

1. Critical-system designation. Some systems in your stack are MAS-critical (customer money, customer data, customer-facing interfaces). These get heightened scrutiny — change control, access logging, vulnerability management, recovery time objectives. Designation is a documented decision, not an inference.
2. Outsourcing governance. Cloud providers (AWS / GCP / Azure) and third-party SaaS are outsourcing arrangements under MAS rules. They require documented due diligence, contractual provisions matching MAS templates, and ongoing monitoring. Sub-outsourcing — your SaaS vendor’s vendors — is also in scope.
3. Resilience. Recovery time objectives (RTO) and recovery point objectives (RPO) for critical systems must be defined, tested, and demonstrably achievable. “We’re on AWS” is not a resilience strategy; it’s an input to one.

The architecture decisions that matter most

Five decisions a Singapore-licensed fintech CTO makes that are MAS-shaped:

1. Cloud region. AWS ap-southeast-1 (Singapore) is the default. Multi-region for resilience requires another approved region with documented data flow controls. US regions for a Singapore fintech are usually not viable for production workloads touching customer money.
2. Sub-processor visibility. Every SaaS in the stack is a sub-processor. The list is maintained, the contracts are MAS-aligned, and the data flows are mapped. SaaS that doesn’t offer ap-southeast-1 hosting or MAS-aligned contractual terms is increasingly removed from production stacks.
3. Logging and audit retention. MAS expects 5+ years of audit log retention for critical systems, queryable on demand. Logging architecture (CloudWatch + S3 Glacier, OpenSearch + S3 archive) is designed for this from day one. Retrofitting it later is painful.
4. Identity and access. MAS expects MFA on production access, justified-access logging, periodic access review, and segregation of duties. The IAM architecture (Okta + AWS SSO + per-environment role boundaries) is non-trivial and is best designed early.
5. Change management. MAS expects documented change controls for production releases — peer review, testing evidence, rollback plans. A trunk-based deployment model with pre-merge review and post-merge canary deployment satisfies this; ad-hoc hotfix culture does not.

The outsourcing mistake

The most common mistake we see Singapore fintechs make on outsourcing: treating SaaS contracts as standard procurement, not as outsourcing arrangements under MAS guidelines. The remediation is expensive — re-papering vendor contracts at scale, often with vendors who don’t have MAS-aligned templates.

The correct posture from day one: every SaaS contract that touches customer data or customer-facing systems is reviewed against MAS outsourcing requirements before signing. The vendor list is reviewed quarterly. New vendors require a documented onboarding decision.

This adds friction to SaaS adoption. That is the intent of the MAS framing: friction is a feature, not a bug.

What we ship

For MAS-regulated clients, our default deliverables include:

• Architecture in ap-southeast-1. Production workloads, encrypted at rest and in transit, with documented data flow diagrams.
• Sub-processor register. Maintained in the client’s internal repo, updated as part of the change-management process.
• Audit logging. CloudTrail + service-specific audit logs to S3 with Glacier archive after 90 days, retention 5+ years. Queryable via Athena.
• IAM architecture. Okta SSO + AWS SSO with role-based access, MFA enforced, periodic access review documentation.
• Change management. Trunk-based dev with pre-merge review, post-merge canary, documented rollback. MAS-aligned by construction.
• Resilience documentation. RTO/RPO per critical system, tested via documented disaster-recovery exercises.

We work with the client’s MAS counsel on the contractual and governance layer. We don’t substitute for them. The architecture is designed to make their job tractable — clear data flows, documented controls, demonstrable evidence.

A representative engagement

A recent Singapore wealth-tech client engaged us during their MAS licensing process. Their existing stack had grown organically and had multiple gaps against TRMG: no audit-log retention strategy, ad-hoc IAM, US-region SaaS in the data path, no documented sub-processor register.

We rebuilt the production architecture in 14 weeks. The MAS submission used the new architecture diagrams. The licence was granted on first submission. Total engagement cost was a small fraction of what a failed first submission would have cost in time-to-market.

The lesson: MAS-aligned architecture is cheaper to design from the start than to retrofit. For pre-licence Singapore fintechs, the architecture conversation should happen before the licensing application is drafted.

---

Read more: /markets/singapore · /sectors/financial-services · /strategy/