MAS Technology Risk Management: test your mobile banking app the way MAS describes it.
The MAS Technology Risk Management Guidelines set out specific measures for mobile banking apps: anti-hooking and anti-tampering, certificate pinning, blocking rooted and jailbroken devices, multi-factor authentication and transaction signing. They also expect blackbox and greybox penetration testing of online financial services at least once a year. Ostorlab tests those controls in your app and the APIs behind it, on every release.
- Checks root and jailbreak detection, anti-tampering, anti-instrumentation and pinning, and what the app does when they trigger
- Tests login, one-time codes, step-up checks and session handling with your test accounts
- Follows the app into its APIs, even with TLS pinning
- Proves each failure with bypass evidence or a replayable exploit
- Who it applies to
- Banks in Singapore, and other MAS-regulated financial institutions for the TRM Guidelines
- Legal basis
- Notices FSM-N05 and FSM-N06 under the Financial Services and Markets Act 2022, in force since 10 May 2024
- Focus
- Online financial services, mobile app security and penetration testing
- Main reference
- MAS Technology Risk Management Guidelines, January 2021
How the MAS rules for digital banking took shape
The TRM Guidelines set the technical baseline. Binding notices and anti-scam measures have been added on top since then.
- 18 January 2021
Revised TRM Guidelines
Technology risk practices for financial institutions, including a chapter on online financial services and an annex on mobile application security.
- 19 January 2022
Anti-phishing measures
MAS and ABS announce measures for retail banks, including no clickable links in emails or SMS, and a delay of at least 12 hours before a new soft token is activated on a mobile device.
- 10 May 2024
Notices FSM-N05 and FSM-N06
The technology risk management and cyber hygiene notices for banks take effect under the Financial Services and Markets Act 2022, replacing Notices 644 and 655.
- 16 December 2024
Shared Responsibility Framework
The framework and the revised E-Payments User Protection Guidelines take effect, with duties such as a cooling-off period and real-time alerts that decide who bears losses from phishing scams.
- 10 June 2026
Consultation on TRM Notices
MAS proposes amendments to the TRM Notices, including an inventory of IT assets that covers open-source and third-party components. Comments closed on 31 July 2026.
- Every year
Penetration testing
For systems directly accessible from the Internet, MAS expects penetration testing at least once annually, or whenever the systems undergo major changes or updates.
The MAS rules, applied to your mobile app
For each rule: what the text says, what it means for a mobile banking app, how Ostorlab helps, and what stays with your team.
- MAS TRM Guidelines, 14.1.4 and Annex C
Address the risks unique to mobile apps
What the text says
An FI offering online financial services on mobile devices should put in place specific measures for the risks of mobile applications. Annex C lists them: avoid storing or caching data in the app, protect private cryptographic keys, implement anti-hooking or anti-tampering mechanisms, integrity checks and code obfuscation, certificate or public key pinning, a secure in-app keypad and device binding for the software token.
What it means for your mobile app
Annex C reads like a test plan for your app. Each measure can be checked against the build your customers download.
How Ostorlab helps
Mobile Shielding Scan attempts bypasses of root and jailbreak detection, anti-tampering, anti-instrumentation and TLS pinning, and shows whether the app blocks the workflow, refuses to start or keeps running. Ostorlab also looks for tokens and personal data in local storage, caches, logs and screenshots.
What stays with you
Choosing and configuring your shielding product, the in-app keypad and device binding design.
- MAS TRM Guidelines, 14.1.7 and 14.2.8
Keep rooted and jailbroken devices away from transactions
What the text says
Rooted or jailbroken devices should be disallowed from accessing the FI's mobile applications to perform financial transactions, unless the app is secured within a sandbox or container that insulates it from tampering and interception by malware. Soft token provisioning should include measures such as verifying the customer's identity, detecting and blocking rooted or jailbroken devices, and device binding.
What it means for your mobile app
Detection alone is not enough. The app has to stop the transaction or the token set-up when the device is compromised, and the check should not be easy to switch off.
How Ostorlab helps
Mobile Shielding Scan runs the app in rooted and jailbroken environments, attempts to bypass the detection and shows what the app does next. You get a hardening score and bypass evidence.
What stays with you
The policy for compromised devices and the choice of sandbox or container technology.
- MAS TRM Guidelines, 14.2.1 to 14.2.5
Use MFA at login and sign high-risk actions
What the text says
Deploy multi-factor authentication at login for online financial services. Encrypt customer passwords end to end between the mobile app or browser and the system that verifies them. Implement transaction signing for high-risk activities, such as changes to contact details, registering a third-party payee, high value funds transfers and changes to transfer limits. Keep time-based OTP validity as short as practicable.
What it means for your mobile app
Payee changes, limit increases and contact-detail changes are what scammers go after. The signing step has to hold on the server, whatever the app sends.
How Ostorlab helps
Ostorlab completes SMS, email or TOTP one-time codes with your test accounts and tests MFA enforcement and step-up flows, including how attackers try to manipulate them, together with the API calls behind account changes.
What stays with you
Choosing authentication and signing methods, and setting OTP validity and limits.
- MAS TRM Guidelines, 14.2.6, 14.2.9 and 14.2.11
Protect sessions and credentials
What the text says
Keep the authenticated session and its encryption intact throughout the interaction, detect and terminate hijacked sessions, and end online sessions automatically after a pre-defined period of inactivity. Encrypt biometric data and credentials in storage and in transit, and store credentials in a form that resists reverse engineering.
What it means for your mobile app
Session expiry, token invalidation on logout and how credentials sit on the device are concrete, testable behaviours of the app and its backend.
How Ostorlab helps
Authenticated testing covers login and logout, token refresh, timeouts, session invalidation and MFA enforcement, and traffic analysis shows how credentials travel from the app to the backend.
What stays with you
The timeout values, biometric calibration and credential revocation process.
- MAS TRM Guidelines, 6.4.4 to 6.4.7
Secure and test your APIs before production
What the text says
Set security standards for APIs that protect API keys and access tokens, with a reasonable, enforced expiry for access tokens. Use strong encryption for sensitive data sent through APIs. Perform robust security screening and testing of an API before it is deployed into production, monitor API usage for suspicious activity, and be able to revoke keys or tokens promptly after a breach.
What it means for your mobile app
The APIs your app calls carry the same data as the app. Their access control and token handling need testing before each release, not only once.
How Ostorlab helps
Ostorlab intercepts the app's traffic, even with TLS pinning, and tests the APIs for broken authorization (BOLA, BFLA, IDOR), misuse of tokens and sessions, and abuse such as enumeration, replay and automation, with request and response evidence for each finding.
What stays with you
API design, third-party vetting, real-time API monitoring and key revocation.
- MAS TRM Guidelines, 6.1 to 6.3 and Annex A
Test application security as you build
What the text says
Adopt standards on secure coding, source code review and application security testing. Review and test third-party and open-source code before it is integrated, and track its updates and reported vulnerabilities. Use a mixture of static, dynamic and interactive testing methods. Track all issues found, and remediate major issues before production deployment. Apply the same standards in Agile and DevSecOps.
What it means for your mobile app
Each release of the app should go through automated security testing before it reaches the store, including the SDKs and libraries it bundles.
How Ostorlab helps
Mobile SAST analyses the APK, AAB or IPA directly, with no source code needed, including taint analysis across embedded SDKs. Mobile DAST runs the app, and SCA fingerprints statically compiled libraries. All of it runs from your CI/CD pipeline on every build.
What stays with you
Secure coding standards, developer training, manual code review and segregation of duties.
- MAS TRM Guidelines, 13.1, 13.2 and 13.6
Run vulnerability assessments and penetration tests
What the text says
Conduct regular vulnerability assessments, with a frequency that matches the system's criticality and exposure, including application vulnerabilities. Combine blackbox and greybox penetration testing for online financial services; greybox means testing with the same rights as a normal customer. For systems directly accessible from the Internet, conduct penetration testing at least once annually or whenever they undergo major changes or updates. Track and resolve issues with severity ratings and remediation timeframes.
What it means for your mobile app
Your mobile banking app and its APIs are Internet-facing. Plan at least one penetration test a year, test again on major releases, and include logged-in testing.
How Ostorlab helps
An AI-agent pentest tests the app and its APIs behind login, on the build you ship, with a working exploit you can replay for each AI-agent finding. Findings are rated critical, high, medium or low, tracked as tickets and retested once the fix ships.
What stays with you
Choosing who runs your annual penetration test, testing in production, bug bounty and red team exercises.
- MAS Notice FSM-N05, paragraph 9; MAS Notice FSM-N06, paragraphs 4.2, 4.3 and 4.6
Meet the binding notices for banks
What the text says
Notice FSM-N05 requires banks to implement IT controls to protect customer information from unauthorised access or disclosure. Notice FSM-N06 requires security patches to be applied within a timeframe commensurate with the risk of each vulnerability, a written set of security standards for every system, and multi-factor authentication for all accounts on any system used to access customer information through the internet.
Source:MAS Notice FSM-N05, paragraph 9; MAS Notice FSM-N06, paragraphs 4.2, 4.3 and 4.6
What it means for your mobile app
These are obligations, not guidance. The app and its APIs are where customers reach their information, so their controls are part of the evidence.
How Ostorlab helps
Ostorlab tests the controls that protect customer information in the app and its APIs, and SCA maps the components in each release to known vulnerabilities and tracks their closure.
What stays with you
Patching servers and infrastructure, security standards for every system, and administrative accounts.
- Guidelines on Shared Responsibility Framework, 4.2 and 6.2
Build the anti-scam duties into the app
What the text says
Under the Shared Responsibility Framework, a responsible FI must impose a cooling-off period of at least 12 hours, during which high-risk activities cannot be performed, when a digital security token is activated on a device. It must send real-time alerts for token activation and high-risk activities, provide a self-service feature to block mobile and online access, and run real-time fraud surveillance. The FI is expected to bear losses that arise from not meeting these duties.
Source:Guidelines on Shared Responsibility Framework, 4.2 and 6.2
What it means for your mobile app
Several of these duties live in the app: the cooling-off period, the alerts and the kill switch. If they can be bypassed through the app or its APIs, the loss may be yours.
How Ostorlab helps
The AI-agent pentest tests the business logic of payment and account flows, and API testing checks authorization and replay on the calls behind account changes.
What stays with you
Fraud surveillance, alert delivery, the reporting channel and loss assessments.
Summary of public MAS texts, checked on 27 September 2026. The TRM Guidelines are guidance, and MAS considers the degree of observance with their spirit when supervising an FI. This page is not legal advice.
MAS rules, control by control
The controls the MAS texts point to, how Ostorlab tests them in your app and its APIs, and the evidence you can keep.
| Control | How Ostorlab helps | Evidence you keep |
|---|---|---|
| Anti-hooking, anti-tampering and pinningTRM Annex C | Modifies the binary, injects debuggers and hooks, and attempts to bypass TLS pinning. Details | Evidence of which protections held and which were bypassed |
| Blocking rooted and jailbroken devicesTRM 14.1.7, 14.2.8 | Runs the app in rooted and jailbroken environments and attempts to bypass root and jailbreak detection. Details | Hardening score, and bypass evidence for each protection that failed |
| No sensitive data stored or cached in the appTRM Annex C | Looks for tokens and personal data in storage, caches, logs and screenshots, and checks transport protections. Details | File system evidence showing what was written, where and when |
| Protection of keys and credentials in the appTRM Annex C, 14.2.11 | Finds API keys, tokens and credentials in the app package and validates whether they work. Details | Validated secrets, with the permissions and services they expose |
| MFA at login and signing of high-risk actionsTRM 14.2.1 to 14.2.5 | Logs in with one-time codes and tests MFA enforcement and step-up flows, and the API calls behind them. Details | Findings on login and step-up flows, with reproduction steps |
| Session time-outs and hijacked sessionsTRM 14.2.9 | Tests login and logout, token refresh, timeouts and session invalidation. Details | Session and token findings, with request and response logs |
| API tokens and testing before productionTRM 6.4.4 to 6.4.6 | Intercepts traffic even with TLS pinning and tests authorization, token misuse and abuse such as enumeration and replay. Details | Request and response evidence for each API finding |
| Static and dynamic testing before releaseTRM 6.1.6, 6.1.7, Annex A | Mobile SAST on the binary and Mobile DAST on the running app, before release. Details | Findings with decompiled source context, traffic, stack traces and screenshots |
| Third-party and open-source codeTRM 6.1.3, 6.1.4 | Fingerprints statically compiled libraries and maps them to known vulnerabilities, release to release. Details | Mapped vulnerabilities with upgrade or replace recommendations, and closure tracked across releases |
| Greybox testing and remediation trackingTRM 13.2.1, 13.6 | AI-agent pentest of the app and its APIs, behind login, with tickets and retests. Details | A working exploit you can replay for each AI-agent finding, and retest results |
Ostorlab tests controls in the app and its APIs. Fraud surveillance, SOC monitoring, recovery objectives, incident reporting to MAS, cyber exercises, red teaming and board oversight stay with your teams.
MAS controls to test in your mobile app
A practical list for security and technology risk teams, based on the TRM Guidelines and the anti-scam duties.
Compromised devices
Run the app on rooted and jailbroken devices and check that transactions and soft token set-up are blocked.
Annex C protections
Test anti-hooking, anti-tampering, integrity checks and pinning against a modified build and runtime hooks.
Data left on the device
Look for tokens and personal data in storage, caches, logs and screenshots, and for keys and credentials in the app package.
Transaction signing
Check that adding a payee, raising limits and changing contact details all require signing, enforced by the server.
Sessions and OTPs
Verify inactivity time-outs, session invalidation, OTP validity and replay protection.
APIs before production
Test authorization and token expiry on every API the app calls, before each release reaches production.
Yearly greybox test
Plan penetration testing of the app and its APIs at least once a year and on major changes, including testing with customer credentials.
Anti-scam duties
Confirm that the cooling-off period, real-time alerts and the kill switch cannot be bypassed through the app or its APIs.
A suggested list, not a MAS template. This is not legal advice.
The capabilities behind this page
Each one has its own page with the details.
- Mobile Shielding ScanTest root and jailbreak detection, anti-tampering and pinning at runtime, and see which protections held and which were bypassed.Learn more
- Mobile Agentic Deep ScanAI agents pentest the store build on every release, with a working exploit you can replay for each AI-agent finding.Learn more
- Authenticated testingTest login, one-time codes and step-up flows with your test accounts.Learn more
- API and backend testingIntercept app traffic even with TLS pinning, then test the APIs and backends behind accounts and payments.Learn more
- Mobile SASTBinary-based static analysis of APK, AAB and IPA files, with taint analysis across the app and its embedded SDKs.Learn more
- SCA and SBOMFind vulnerable dependencies, including statically compiled native libraries, and track their closure release after release.Learn more
- Bring your own AI keyRun AI-agent scans on your own AI provider key with a spend cap per scan, so usage follows your internal policies.Learn more
- On-premises scanningScan staging apps, APIs and repositories behind your firewall or VPN, on infrastructure you control.Learn more
Trusted by banks and fintechs, including
Sources
The official texts this page is based on, checked on 27 September 2026.
- Guidelines on Risk Management Practices: Technology Risk (Technology Risk Management Guidelines)MAS, January 2021, published 18 January 2021. Chapters 6 (software development and APIs), 13 (cyber security assessment) and 14 (online financial services), and Annexes A and C
- MAS Notice FSM-N05: Notice on Technology Risk ManagementMAS, issued 9 May 2024 under section 29(1) of the Financial Services and Markets Act 2022, effective 10 May 2024. Applies to all banks in Singapore
- MAS Notice FSM-N06: Notice on Cyber HygieneMAS, issued 9 May 2024, effective 10 May 2024. Replaces Notice 655, which was cancelled with effect from 10 May 2024
- Guidelines on Shared Responsibility FrameworkMAS and IMDA, issued 24 October 2024, effective 16 December 2024. Duties of banks and major payment institutions against phishing scams, and loss allocation
- E-Payments User Protection GuidelinesMAS, version with effect from 16 December 2024. Duties of responsible financial institutions and account users for protected accounts
- MAS and ABS Announce Measures to Bolster the Security of Digital BankingMAS media release, 19 January 2022. Anti-phishing measures for retail banks, including the 12-hour delay before soft token activation
- Additional Measures to Strengthen the Security of Digital BankingMAS media release, 2 June 2022. Further measures, including a kill switch and a default online transfer limit of S$5,000 or lower, in full effect by 31 October 2022
- Consultation Paper on Proposed Amendments to Notices on Technology Risk Management (P012-2026)MAS, 10 June 2026, closed 31 July 2026. Proposed requirements only, not yet in force
Frequently asked questions
Straight answers on coverage, setup, and how results reach your team.
Can't find your answer? Book a demo or contact us.
Test your mobile banking app against the MAS controls
Start with a free scan of your app from the store, or book a demo to run shielding and logged-in tests with our team.