RMiT Source Code Review: What BNM Requires, How to Prove It

Say a developer on a Kuala Lumpur bank's payments team merges a change to the DuitNow transfer service on a Thursday. Six months later, the technology auditor picks that change out of the release log and asks one question: where is the source code review for it?

If the honest answer is that someone looked at it but nobody kept a record, then for audit purposes the review did not happen.

RMiT (Risk Management in Technology) is Bank Negara Malaysia's technology risk policy for financial institutions. Below, each RMiT rule that touches code is turned into the evidence an auditor will ask for. That is what RMiT source code review means in practice.

It is written for the people who answer the auditor at a bank, insurer or fintech, and for the vendors who build their systems.

Paragraph numbers are from BNM's RMiT policy document issued 25 September 2026 (BNM/RH/PD 028-98). It states an effective date of 28 November 2025, except where a paragraph sets its own. Check bnm.gov.my for a newer issue.

This is a plain-language reading of public regulatory text, not legal advice. Confirm your obligations with your compliance team.

The short version

Here is what RMiT asks of your code, in plain terms. The rest of the article explains each line and the evidence behind it.

How to read RMiT references

RMiT numbers its rules by paragraph, and marks each one "S" or "G". An S paragraph is a mandatory standard; a G paragraph is guidance. Appendices hold detailed checklists. For example, Appendix 5 lists cyber-resilience controls, including API security in Part E, and paragraph 11.5 makes it mandatory.

In this article, "paragraph 10.10" means RMiT paragraph 10.10. We say when a paragraph is only guidance.

What RMiT says about source code

RMiT's own wording is precise about the split. An S paragraph "must be complied with", and non-compliance "may result in enforcement action". A G paragraph holds recommendations that are "encouraged to be adopted".

Keep that split in mind. Several of the clauses people quote about code scanning are guidance, not standards.

What is mandatory for your own code

Review every change before it goes live. Changes to the source code of critical systems must be "subject to adequate source code reviews" (paragraph 10.10). The review checks that the code is secure and "developed in line with recognised coding practices". It must happen "prior to introducing any system changes".

A critical system is any application system that supports critical banking, insurance, takaful, payment, investment or trading services.

Get each change independently approved. You may see paragraph 10.10 summarised as requiring an "independent" code review. The current text says "adequate", not "independent". Independence comes in the next paragraph, which requires procedures to "independently review and approve system changes" (paragraph 10.11).

In practice you need both: a review of the code, and an independent approval of the change.

Test your APIs regularly. Institutions must "conduct periodic security assessments on APIs, including penetration testing and static / dynamic security testing" (Appendix 5, Part E 1(h)). This is mandatory, because paragraph 11.5 makes Appendix 5 mandatory.

Check third-party code in your APIs. API development must also follow secure coding, including "validating security of third party code and libraries" (Appendix 5, Part E 1(c)).

If you build software for a bank or insurer

This is where vendors come in. RMiT does not bind you directly; it binds the institution, which then binds you by contract.

When a third party develops or maintains a critical system, the institution must require that vendor to "demonstrate that it adopts secure by design principles in IT system development methodology" (paragraph 10.12(b)). The vendor must also ensure "the source code continues to be readily accessible" (paragraph 10.12(c)).

Separately, the institution's vendor due diligence must consider a set of listed risks (paragraph 10.47). That list includes a "secure system development lifecycle" and "vetting of third party or open source software" (Appendix 8).

Automation is mandatory; tools and SBOM are guidance

Fast-moving teams must automate security checks. Where an institution uses rapid development methods such as DevOps, it "shall automate the IT security compliance review" (paragraph 10.6). That includes finding and testing security vulnerabilities.

Code-scanning tools are suggested, not required. An institution "may deploy automated tools" for development, testing, change management, "code scanning and software version control" (paragraph 10.14, guidance).

An SBOM is suggested, not required. An institution may consider "adopting Software-Bill-of-Materials (SBOM)" (paragraph 10.15, guidance). An SBOM is a list of every third-party component in your software. The same paragraph suggests an open-source software security policy.

These two guidance paragraphs show what BNM considers good practice. They do not create a separate obligation to buy a scanner.

If you are national critical information infrastructure

Some institutions are designated as NCII (national critical information infrastructure) entities. For them, RMiT includes the banking-sector Code of Practice under the Cyber Security Act 2024 (Appendix 12).

It asks for secure coding guidelines aligned with the OWASP Top 10, the standard list of the most common web application weaknesses. It also asks for pre-deployment testing that includes "Validation of compliance with secure coding guidelines." It takes effect once the Chief Executive of NACSA, Malaysia's National Cyber Security Agency, endorses it.

What auditors and BNM ask to see

Read the mandatory paragraphs as evidence requests and a working list falls out. It is the list we would prepare before an internal technology audit or a vendor due-diligence review.

• A review record for every change to a critical system. Show who reviewed it, against which coding rules, and the result, dated before release (paragraph 10.10).
• An independent approval of each change (paragraph 10.11). RMiT also expects "appropriate segregation of duties throughout the SDLC", so in practice the approver is not the author.
• API test results. Keep periodic static and dynamic security test results and penetration test reports (Appendix 5, Part E).
• Your written coding standard. It gives "recognised coding practices" something concrete to point at (paragraph 10.10). NCII entities also need one aligned with the OWASP Top 10 (Appendix 12).
• Vendor evidence. Collect the vendor's secure SDLC description and proof it is followed (paragraph 10.12). Confirm the source code stays accessible, and keep your due-diligence answers (Appendix 8).
• An inventory of open-source and third-party components, ideally an SBOM, with vetting results (Appendix 8). The SBOM itself is guidance (paragraph 10.15).
• Known-vulnerability status. Systems must be "not running with known security vulnerabilities" (paragraph 10.17).
• Your gap analysis. Institutions must submit a gap analysis and action plan to BNM "no later than 90 days after the issuance date of this policy document" (paragraph 18.1). Those that submitted under an earlier version must keep identifying "any new gaps against the enhanced or revised requirements". They must also make the annual assessment available to BNM on request.

Two of these are the hardest to produce after the fact: the per-change review record and the component inventory. Both are cheap to keep if the tooling writes them on every pull request. Both are painful to rebuild six months later.

How SonarQube supports that evidence, by edition

SonarQube does not make you RMiT-compliant. What it does well is write much of your RMiT source code review evidence automatically, on every change. Which evidence depends on the edition.

What each edition gives you

A review record for every change: Developer edition and up. Every pull request is analysed before merge. A quality gate can block the merge if new code breaks your rules. The analysis history supports your evidence for the per-change review (paragraph 10.10). The quality profile is your coding standard, written down.

The free Community Build analyses only the main branch, so it cannot give you a per-change record. Our comparison of SonarQube Community vs Developer vs Enterprise covers what each edition adds.

Files an auditor can keep: Enterprise edition. SonarQube Server Enterprise adds the artefacts a due-diligence team or an auditor can file:

• compliance reports against the OWASP Top 10, the CWE Top 25 (MITRE's list of the most dangerous software weaknesses) and PCI DSS (the card-industry security standard);
• PDF reports;
• a regulatory report, a ZIP with quality-gate status, ratings and quality profiles;
• audit logs.

One practical point: audit-log housekeeping deletes entries monthly by default, so raise retention before an audit period starts.

Component inventory and SBOM: the Advanced Security add-on. This supports the open-source vetting in vendor due diligence (Appendix 8). SonarQube Advanced Security, a paid add-on from Server Enterprise, adds software composition analysis (scanning your third-party dependencies). It also exports an SBOM in CycloneDX or SPDX, the two standard SBOM file formats. The SBOM is not stored, so export one per release.

Closing findings: the Remediation Agent. The SonarQube Remediation Agent proposes fixes and opens them as pull requests for your review, re-running Sonar's analysis on each fix.

Logic and access-control flaws: the Hunter Agent. The SonarQube Hunter Agent looks for broken access control and business-logic flaws, the attack classes PCI DSS 6.2.4 names (below), as well as authentication flaws.

Both agents are separate subscriptions. On SonarQube Server they need the Enterprise edition, version 2026.5 or later. The Hunter Agent on SonarQube Cloud needs the Enterprise plan. Neither replaces your reviewer or the independent approval (paragraph 10.11).

Where the code runs. For a regulated institution, this can decide the edition. SonarQube Cloud stores data in the EU or the US only (as of October 2026), and the region cannot be changed after sign-up. There is no Asia Pacific region.

SonarQube Server is self-managed, so you decide where it runs, including on your own infrastructure. Licences are priced by lines of code; see how SonarQube pricing works.

What it does not cover. SonarQube's core is static analysis. It does not replace the dynamic and penetration testing that RMiT also asks for on APIs (Appendix 5, Part E). It does not replace the independent approval of each change either. Treat it as one control in your evidence, not all of it.

Also applies if you handle card data: PCI DSS

PCI DSS v4.0.1 asks for much the same evidence from a different angle:

• Review custom code before release. Bespoke and custom software must be "reviewed prior to being released into production or to customers" (requirement 6.2.3). Its applicability notes state that "Code reviews may be performed using either manual or automated processes, or a combination of both."
• Defend against logic and access-control attacks. Your engineering methods must address attacks on business logic and on access control mechanisms, among others (requirement 6.2.4). That is where the Hunter Agent fits.
• Keep a software inventory. You need "An inventory of bespoke and custom software, and third-party software components" (requirement 6.3.2). An SBOM from Advanced Security supports it.

SonarQube Server Enterprise includes a PCI DSS compliance report, which Sonar maps to PCI DSS versions 4.0 and 3.2.1 as of October 2026. It supports your evidence; your QSA (the Qualified Security Assessor who signs off PCI DSS) still decides.

Also applies if you are regulated in Singapore: MAS TRM

MAS's Technology Risk Management Guidelines (January 2021) cover the same ground:

• Set coding and review standards. A financial institution "should adopt standards on secure coding, source code review and application security testing" (paragraph 6.1.1).
• Mix your testing methods. It "may use a mixture of static, dynamic and interactive application security testing" (paragraph 6.1.6).
• Fix major issues before release. Issues should be tracked, and "Major issues and software defects should be remediated before production deployment" (paragraph 6.1.7).

A quality gate that blocks the merge on new major issues is a direct way to show that last point working. Our SonarQube Singapore page maps each MAS TRM paragraph to a SonarQube feature.

Frequently asked questions

Sources

• Bank Negara Malaysia, Risk Management in Technology (RMiT), issued 25 September 2026, BNM/RH/PD 028-98.
• Monetary Authority of Singapore, Technology Risk Management Guidelines, January 2021.
• PCI Security Standards Council, PCI DSS v4.0.1, June 2024.
• Sonar documentation on compliance reports, Advanced Security and SonarQube Cloud regions, checked October 2026.

Related reading: SonarQube for banks and financial institutions in Malaysia, and checking AI-written code with SonarQube AI Code Assurance.