October 2, 2026
October 2, 2026
Most guides to building a banking app answer from a Western regulatory position, citing PSD2 and GDPR. If you are launching in Singapore or Malaysia, a different set of rules writes part of your backlog for you, and some of it has to be done before you are allowed to launch at all. This guide covers what those rules require, and where the money goes.
In short: a banking app in Malaysia must satisfy BNM RMiT Appendix 4, which bans storing authentication credentials on the device, requires a tamper-proof runtime, and requires monitoring app stores for fake copies. New digital services must be notified to BNM before launch, with independent external security assurance. Singapore adds the Shared Responsibility Framework and the CSA Safe App Standard.
What the regulator writes into your backlog
Read that list as a product backlog rather than as compliance paperwork. Roughly a third of it constrains architecture, a third is engineering work, and the rest is process that runs after go-live.
The published guides on this topic are substantial and mostly accurate for the markets they address. The problem is the market they assume. Reviewing the pages currently ranking for this topic, the frameworks cited are PSD2, GDPR, CCPA, PCI DSS, ISO 27001 and OWASP MASVS. None of them mention the Monetary Authority of Singapore, Bank Negara Malaysia or the Cyber Security Agency of Singapore.
That matters because the Southeast Asian requirements are not a subset of the European ones. PSD2 shapes payment initiation and strong customer authentication. It says nothing about monitoring app distribution platforms for counterfeit versions of your app, which Malaysia requires explicitly. Building to a European checklist and assuming regional coverage is how teams discover a gap during pre-launch assurance, which is the most expensive moment to discover one.
If you are building for both Europe and Southeast Asia, treat them as overlapping sets with different edges, and map the union before you estimate.
Before estimating anything, establish what you are in the eyes of the regulator, because the obligations are addressed to licensed entities rather than to apps.
In Malaysia, RMiT applies to licensed banks, investment banks, Islamic banks, insurers, takaful operators and development financial institutions. The November 2025 revision widened this to include non-bank merchant acquirers and intermediary remittance institutions above a 5 percent share of transaction value or volume, which brought a group of payment companies into scope that were previously outside it.
In Singapore, the Shared Responsibility Framework guidelines apply to full banks, both locally incorporated and branch, and to major payment institutions.
Three situations come up often and are worth resolving early. If you are the licensed institution, the obligations are yours directly. If you are building on a partner's licence, the obligations sit with that partner, but they will flow to you through the contract, and the partner's assurance provider will examine your work. If you are a vendor building for a licensed client, you are not the regulated party, yet your deliverable has to pass an assessment whose criteria are published, so you can design against them from the start.
The mistake worth avoiding is assuming that being a technology company rather than a bank puts the requirements out of scope. The requirements land on the product regardless of which company employs the engineers.
Feature lists in most guides mix three very different kinds of item. Separating them makes estimation far more reliable.
Table stakes. Balance and transaction history, transfers, bill payment, card controls including instant freeze, statements, and support access. Users expect these and competitors have them. They carry little differentiation and their cost is well understood.
Regulator-mandated. The items in the table above. These are not negotiable, they are frequently underestimated because they are invisible in the interface, and several of them constrain architecture rather than adding screens. Host-centralised credential verification is the clearest example: decided late, it forces rework of the authentication layer.
Differentiating. Budgeting insight, savings goals, in-app onboarding for new products, spending analytics, personalised offers. This is where product teams want to spend, and where the budget goes if the second category was underestimated.
The common failure is planning categories one and three, then discovering category two during a security review. Sequencing matters more than totals here.
For general background on scoping and process, our guide to mobile app development covers the fundamentals that apply to any app, and our piece on custom mobile app development covers build decisions.
Bank Negara Malaysia's revised Risk Management in Technology policy document took effect on 28 November 2025 and includes an appendix dedicated to mobile applications and devices. It is unusually concrete for a regulatory text, which makes it usable directly as engineering acceptance criteria.
The customer-facing requirements sit in paragraph 2. The application must be designed to operate in a secure and tamper-proof environment within the device, protecting users against threats such as malware and unauthorised access, where the footnote defines that environment as one not compromised, jailbroken or rooted. Applications are prohibited from storing customer authentication information such as PIN and passwords, and authentication and verification of unique key and PIN must be centralised at the host. Activation of the application must be subject to robust authentication by the institution. Provisioning and deprovisioning on the customer's device must both be secure.
Three further requirements concern distribution rather than code. The institution must perform due diligence to ensure the app distribution platforms it uses are reputable, must control access for maintaining and uploading the app to those platforms, and must monitor those platforms to identify and address the distribution of fake applications in a timely manner.
That last one deserves emphasis because it is an operating cost, not a build cost. Somebody has to watch the stores after launch, and takedown processes have to exist before they are needed.
Paragraph 3 covers devices used by the institution, its agents or intermediaries to process customer information: hardened devices, the capability to wipe data remotely if a device is reported lost or stolen, compliance with card payment industry standards, masking of sensitive information on screen, and a 30 day limit on storing customer information used for soliciting insurance and takaful business.
Two general clauses apply to the app as well. S 10.55 requires multi-factor authentication that can defend against social engineering, combining two or more of knowledge factors, inherent factors such as biometrics, or possession factors such as tokens. S 10.57(c) requires user activity in critical systems to be logged, with logs maintained for at least three years and reviewed regularly.
Singapore approaches the same problem from a different direction, and the distinction between binding and advisory matters.
The Guidelines on Shared Responsibility Framework were published by MAS on 24 October 2024 and implemented on 16 December 2024, applying to full banks, locally incorporated and branch, and to major payment institutions. The framework allocates responsibility for losses from a defined scope of phishing scams between consumers, financial institutions and telecommunications companies, and requires payouts where duties are breached. Among the institution duties is real-time fraud surveillance aimed at detecting unauthorised transactions that drain an account, where the institution either blocks the transaction until it can reach the customer for confirmation, or notifies the customer and holds the transaction. MAS allowed a transition period for that particular duty.
The product consequence is that fraud detection is not an optional analytics feature. It is a capability with a defined behaviour and a liability attached to getting it wrong.
The Safe App Standard is different in status and often misreported. It is published by the Cyber Security Agency of Singapore, not by MAS, and version 2.0 was published on 15 October 2024. It covers eight areas: authentication, authorisation, data storage at rest, anti-tampering and anti-reversing, network communication, cryptography, code quality and exploit mitigations, and platform interactions. CSA strongly encourages adoption, particularly for apps both developed and hosted in Singapore, and for high-risk apps handling transactions that could cause significant financial loss.
It is a recommended standard rather than a legal obligation. Treat it as a well-specified security baseline and a useful acceptance checklist, and do not tell your board it is mandatory, because it is not.
Here is an uncomfortable observation about the published cost guidance. Two of the most visible guides on this topic put a basic banking app at 50,000 to 150,000 US dollars and at 40,000 to 80,000 US dollars respectively. Those are descriptions of the same tier that differ by nearly a factor of two. A third set of figures elsewhere puts the same tier somewhere else again.
The ranges are not dishonest. They are the result of averaging across markets, team rates, scope definitions and integration assumptions that are never held constant. Quoting a tenth range here would add nothing, so this section does something more useful and covers what changes the number in a regulated Southeast Asian build.
General cost drivers for any mobile app are covered in our existing guides on what affects mobile app price and cost and on mobile app development cost in Singapore. What follows is the banking-specific difference on top of those.
Three points follow from that table, and they are the useful part.
First, several of the largest items are recurring rather than one-off. A build quote that ends at launch has not priced counterfeit monitoring, log retention or fraud surveillance staffing. When comparing vendor proposals, ask explicitly which of these are in scope and for how long.
Second, one item is a schedule dependency rather than a line item. Pre-launch notification and external assurance sit on the critical path, so a launch date set without allowing for them is a date that will move.
Third, the architectural constraints are the cheapest to satisfy early and the most expensive to retrofit. Host-centralised credential verification decided in week two costs a design discussion. Decided after a security review, it costs an authentication rebuild and a retest.
Because the independent assurance sits on the critical path in Malaysia, it is worth knowing what it covers before you plan around it. RMiT Appendix 7 sets this out, and the detail changes how you schedule.
The assurance must be performed by an independent external service provider engaged by the institution. That provider is expected to understand the proposed services, the data flows, the system architecture, the connectivity and its dependencies, which rules out a superficial review. Its job is to examine how comprehensive the institution's own risk assessment was and to validate whether the control measures implemented, or planned, are adequate.
The resulting Risk Assessment Report must state the scope of review, the risk assessment methodology, a summary of findings and any remedial actions. Appendix 7 Part D lists the minimum areas the provider must assess, where applicable: access control, physical and environmental security, operations security, communication security, information security incident management, and the information security aspects of business continuity management.
One requirement in Part C reshapes the whole schedule. The report must confirm that no exception was noted, described in the text as a negative attestation. That is a clean-report standard, not a findings-with-a-remediation-plan standard.
The practical effect is that open findings block the notification, and therefore the launch. Teams used to shipping with a prioritised backlog of accepted security findings will not get that here. Plan the assurance early enough to run a remediation cycle and a retest before the date you intend to notify, and treat the first pass as diagnostic rather than final.
Note also that the assessment scope reaches past the app itself into operations, incident management and business continuity. An assurance engagement scoped only as a mobile penetration test will come back incomplete.
The ordering below reflects where the dependencies actually sit rather than a generic waterfall.
Start by confirming which regime applies and at what level, since the obligations differ between a licensed bank, a payment institution and a partner building on someone else's licence. Write the regulator-mandated items into the backlog before the differentiating features, because they constrain architecture. Fix the authentication and credential-handling design early, since it is the constraint with the widest downstream reach. Commission the independent assurance engagement with enough lead time that its findings can be fixed before the notification, not after. Then plan the post-launch operating duties, which include store monitoring, fraud surveillance and log retention, and assign them to a named owner.
A workable rule of thumb is that anything the regulator requires and cannot be seen in the interface should be scheduled earlier than it feels necessary, because those are the items that fail late and loudly.
Where the app depends on systems that must stay available, the same regulators set separate thresholds for downtime and incident reporting, which sit outside the scope of this article but should be planned alongside it.
Conclusion
Before requesting quotes, write the regulator-mandated list as user stories with acceptance criteria and put it in front of any vendor you are considering. It is a fast filter. A partner who has built in these markets will recognise the items and tell you which ones constrain your architecture. A partner who has not will treat them as a security workstream to be scheduled later, which is the answer that becomes expensive.
Serdao has built software for eighteen years from a French head office with delivery in Ho Chi Minh City, which puts European regulatory practice and Southeast Asian working hours in the same team, and we are members of CCI France Vietnam and French Tech. Our mobile application development page sets out how we scope this work, and you can contact our team to review your feature list against the requirements above.
Is the Safe App Standard mandatory in Singapore?
No. It is published by the Cyber Security Agency of Singapore as a recommended standard, and CSA strongly encourages adoption, particularly for apps developed and hosted in Singapore and for high-risk financial transactions. It is not a MAS regulation, and it is frequently misdescribed as one. Its eight control areas are still a sensible acceptance baseline.
Can we store a PIN on the device for faster login in Malaysia?
No. RMiT Appendix 4, paragraph 2(b) prohibits mobile applications from storing customer and counterparty information used for authentication with the application server, such as PIN and passwords, and requires that authentication and verification of unique keys and PINs be centralised at the host. Fast re-entry patterns have to be designed around that constraint.
Do we need to tell the regulator before we launch?
In Malaysia, yes. RMiT S 16.1 requires a financial institution to notify the Bank before introducing new digital services or enhancements to existing ones. For enhancements not covered by the simplified notification route, S 16.4 also requires independent external assurance on the technology risks and security controls, and a readiness confirmation from the CISO, a senior management officer or the board chair.
How long do we have to keep app activity logs?
RMiT S 10.57(c) requires user activity in critical systems to be logged and the logs maintained for at least three years, with regular review. Budget for retrieval as well as storage, since a log you cannot search within a reporting deadline does limited good.
Does biometric login satisfy the MFA requirement?
Not by itself. RMiT S 10.55 requires two or more factors drawn from knowledge, inherent and possession categories, and requires the combination to defend against social engineering. A fingerprint alone is one inherent factor. What pairs with it, and whether that pairing survives a coached victim scenario, is the real design question.
We already comply with GDPR and PSD2. Is that enough?
No. The requirement sets overlap but neither contains the other. Counterfeit app monitoring, pre-launch regulator notification and the three year log retention have no PSD2 equivalent. Map the union of both regimes rather than assuming the stricter-sounding one covers the other.
Conclusion
Before requesting quotes, write the regulator-mandated list as user stories with acceptance criteria and put it in front of any vendor you are considering. It is a fast filter. A partner who has built in these markets will recognise the items and tell you which ones constrain your architecture. A partner who has not will treat them as a security workstream to be scheduled later, which is the answer that becomes expensive.
Serdao has built software for eighteen years from a French head office with delivery in Ho Chi Minh City, which puts European regulatory practice and Southeast Asian working hours in the same team, and we are members of CCI France Vietnam and la French Tech. Our mobile application development page sets out how we scope this work, and you can contact our team to review your feature list against the requirements above.