BSP IT risk and AFASA rules: test your mobile banking app on every release.
BSP Circular 982 asks supervised financial institutions to test applications with penetration tests, vulnerability assessments and application security tests before loading them into production, and to have an external party perform vulnerability assessment and penetration testing at least annually for digital and electronic financial services. Circular 1213, which implements the Anti-Financial Account Scamming Act, restricts apps on rooted, jailbroken or emulated devices, limits SMS and email one-time PINs and requires a 24-hour pause after key account changes. Ostorlab tests your app and the APIs behind it, behind login, on every release.
- Tests the app and the APIs it calls on the build your customers download
- Logs in with your test accounts, including one-time codes and step-up flows
- Attempts root, jailbreak, emulator and tampering bypasses and shows what held
- Proves each finding with a replayable exploit or request and response evidence
- Who it applies to
- Banks and other BSP-supervised financial institutions, including non-bank financial institutions and payment system operators
- Key date
- Circular 1213 effective 25 June 2025, with its standards to be in place within one year; Circular 982 is in force since December 2017
- Focus
- Application security testing, annual external vulnerability assessment and penetration testing, authentication and anti-fraud controls in mobile channels
- Main reference
- BSP Circular 982, Enhanced Guidelines on Information Security Management, Appendix 75b of the MORB
The BSP texts behind your mobile channel
The information security guidelines sit alongside the IT risk management framework and the AFASA rules. The dates below are for the texts cited on this page.
- 22 August 2013
Circular 808, IT risk management
BSP Circular No. 808 sets the guidelines on information technology risk management for all banks and other BSP-supervised institutions, the framework that later circulars amended.
- 5 December 2017
Circular 982, information security
The Enhanced Guidelines on Information Security Management take effect. Among other measures, they ask for secure coding, application security tests before production, and vulnerability assessment and penetration testing by an external party at least annually for digital and electronic financial services.
- 24 March 2022
Circular 1140, fraud management
Amendments add automated, real-time fraud monitoring and detection systems and a reinforced consumer awareness program, in response to rising electronic fraud.
- 20 July 2024
AFASA signed
Republic Act No. 12010, the Anti-Financial Account Scamming Act, is signed. Section 6 requires institutions to protect access to their clients' financial accounts with adequate risk management systems and controls, such as MFA, fraud management systems and account verification processes.
- 25 June 2025
Circular 1213, AFASA rules
The amendments to the IT risk management regulations take effect, adding the 24-hour transaction pause after key account changes, restrictions on rooted, jailbroken and emulated devices, limits on SMS and email one-time PINs, device fingerprinting, and a ban on clickable links and QR codes in bank messages.
- 27 April 2026
Cybersecurity Maturity Framework
Circular 1232 replaces the IT Rating System with the Supervisory Assessment Framework and introduces the Cybersecurity Maturity Framework and the Cybersecurity Control Self-Assessment, with annual reporting and maturity tiers tied to each institution's IT profile.
- June 2026
The AFASA standards deadline
The Circular 1213 standards were to be in place within one year of its effectivity, a deadline reported as 30 June 2026. The rules include limiting interceptable one-time PINs and moving high-risk transactions to strong authentication.
The BSP 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. Quotes are from the circulars as published by the Bangko Sentral ng Pilipinas.
- BSP Circular 982, Appendix 75b, 3.3.3.4 Application Security
Test applications before they go into production
What the text says
Management should ensure that all applications, whether developed in-house or acquired off-the-shelf, have appropriate controls commensurate to the sensitivity and criticality of the application. Secure coding practices which consider security control requirements early into the development phase should be incorporated in the institution's application systems development and acquisition policies and procedures. New applications, including subsequent enhancements, should be adequately tested using various testing methodologies (e.g., penetration tests, vulnerability assessments, and application security tests) before loading into production. Application systems reviews, penetration testing and vulnerability assessments should be periodically conducted.
Source:BSP Circular 982, Appendix 75b, 3.3.3.4 Application Security
What it means for your mobile app
Every release of a mobile banking app is a new application version heading to production. The app, and the backend it talks to, belong in the release process, not only in an annual exercise.
How Ostorlab helps
An AI-agent pentest tests the store build and the APIs behind it, behind login, with a working exploit you can replay for each AI-agent finding. Mobile SAST and Mobile DAST run from your CI/CD pipeline on every build, on the APK, AAB or IPA, with no source code needed.
What stays with you
Secure coding standards, change approval, the go-live decision and oversight of vendor-built applications.
- BSP Circular 982, Appendix 75b, 3.7.1 and 3.7.2 (c) to (g)
Run vulnerability assessment and penetration testing at least annually, by an external party
What the text says
Vulnerability assessment identifies security vulnerabilities in systems and networks, usually with automated scanners, at a frequency determined by the risk and criticality of the system, and high risk vulnerabilities uncovered should be remediated within a reasonable timeframe. Penetration testing subjects a system or network to simulated or real-world attacks that exploit vulnerabilities under controlled conditions. For BSFIs providing digital or electronic financial services, vulnerability assessment and penetration testing should be performed by an external party at least annually. Testing should also cover extreme but plausible scenarios, and the guidelines list compromise assessments and red-teaming exercises among the types of tests.
Source:BSP Circular 982, Appendix 75b, 3.7.1 and 3.7.2 (c) to (g)
What it means for your mobile app
Your mobile app is part of a digital financial service. Plan at least one external vulnerability assessment and penetration test a year, and keep testing between those cycles because the app changes with every release.
How Ostorlab helps
Ostorlab is an external party that can test the app and its APIs on every release, between your annual tests. Findings are rated critical, high, medium or low, tracked as tickets in the platform or in Jira and ServiceNow, and retested once the fix ships.
What stays with you
Choosing and contracting the external party, production testing arrangements, and the decision on scope and frequency.
- BSP Circular 982, Appendix 75b, 3.3.3.8.3 Patch Management and 3.7.2(c)
Keep patch management and remediation deadlines
What the text says
Management should adopt a patch management process to promptly identify available security patches for technology and software assets, evaluate the criticality and risk of patches, and test and deploy patches within an appropriate timeframe. High risk vulnerabilities uncovered during vulnerability assessment exercises should be remediated within a reasonable timeframe.
Source:BSP Circular 982, Appendix 75b, 3.3.3.8.3 Patch Management and 3.7.2(c)
What it means for your mobile app
The libraries and SDKs bundled in your app are software assets. Each one needs a known version, an assessment when a vulnerability appears, and a fix within a reasonable, documented timeframe.
How Ostorlab helps
SCA fingerprints statically compiled libraries and maps them to known vulnerabilities, release to release. Each finding carries a severity and can be tracked as a ticket, so closure is visible across releases.
What stays with you
Deploying patches to your systems and infrastructure, maintenance windows and risk acceptance decisions.
- BSP Circular 982, Appendix 75b, 3.3.3.8.4 Vendor Management and Outsourcing; BSP Circular 1213, Section 1 (MORB Section 148), shared accountability framework (c)
Manage vendors and third parties
What the text says
Management should conduct appropriate due diligence and consider information security in selecting third party service providers, ensure that effective oversight processes are in place to monitor their activities, and sufficiently detail information security requirements in contracts, particularly for providers that store, transmit, process or dispose of customer information. Cyber-risk exposures from third parties should be assessed and used to adjust the institution's cyber-risk management program. Circular 1213 also directs BSFIs to enforce and regularly evaluate that third-party entities and service providers involved in financial transactions strictly adhere to contractual obligations on availability, information security and cybersecurity.
What it means for your mobile app
A mobile banking app bundles third-party SDKs that talk to their own backends, and the APIs behind it may be run by vendors. They belong in your third-party risk view.
How Ostorlab helps
Ostorlab lists the SDKs and native libraries in each release with their versions and their location in the app bundle, and shows which backends the app and its SDKs exchange data with, so you can see what each third party brings into the build.
What stays with you
Due diligence, contracts, vendor monitoring and exit plans.
- BSP Circular 982, Appendix 75b, 3.3.3.5 Data Security, including 3.3.3.5.1 and 3.3.3.5.2
Protect data on the device and in transit
What the text says
The BSFI should have an information classification strategy and institute controls for information protection in accordance with the classification scheme, protecting information throughout its life cycle from handling, storage or data-at-rest, transmission or data-in-transit, up to the disposal phase. Controls over information stored on portable devices such as laptops, smart phones and tablets should take into account their susceptibility to loss or theft, and include measures such as data encryption, host-provided access controls and remote wiping or deletion capabilities. Policies, standards and procedures should keep data secure while in transit and when shared with third parties.
Source:BSP Circular 982, Appendix 75b, 3.3.3.5 Data Security, including 3.3.3.5.1 and 3.3.3.5.2
What it means for your mobile app
The phone is the portable device. Passwords, tokens and personal data should not sit in clear text on it, in caches, logs or screenshots, or travel unprotected to the backend.
How Ostorlab helps
Ostorlab looks for session tokens and personal data in local storage, caches, logs and screenshots, checks what the app writes to disk, and tests whether transport protections such as TLS pinning can be bypassed.
What stays with you
Data classification, key management, remote wipe and device management policies.
- BSP Circular 1213, Section 1 (MORB Section 148), paragraph (e)(ii)
Restrict the app on rooted, jailbroken and emulated devices
What the text says
Financial accounts must be protected with security measures to mitigate risks such as cyberattacks, unauthorized access, and fraudulent transactions. These safeguards include a restriction on installing mobile applications on unsecured devices, such as, but not limited to, those with outdated systems, rooted or jailbroken devices, or emulators.
Source:BSP Circular 1213, Section 1 (MORB Section 148), paragraph (e)(ii)
What it means for your mobile app
Detection alone is not enough. The app has to stop the session, the enrolment or the transaction 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, jailbroken and emulated environments, attempts to bypass the detection, and shows whether the app blocks the workflow, refuses to start or keeps running. You get a hardening score and bypass evidence.
What stays with you
The policy for compromised and outdated devices, the choice of detection or shielding technology, and support for blocked customers.
- BSP Circular 1213, Section 1 (MORB Section 148), paragraphs (e)(vi) and (k)
Limit interceptable one-time PINs and stop links in messages
What the text says
BSFIs should limit the use of authentication mechanisms that can be shared to, or intercepted by, third parties unrelated to the transaction, such as one-time PINs sent by SMS and email. Institutions engaged in complex electronic products and services and handling high aggregate values of online transactions must adopt strong authentication mechanisms, such as biometric authentication, behavioral biometrics, passwordless authentication including FIDO, or adaptive authentication. The guidelines on the adoption of multi-factor authentication are outlined in Appendix 79. In addition, BSFIs must not send clickable links or quick-response (QR) codes via email, instant messaging apps or SMS, unless the message is prompted by a prior customer action, only provides information, and does not redirect to a website or web application that requires the user to input sensitive information or login credentials.
Source:BSP Circular 1213, Section 1 (MORB Section 148), paragraphs (e)(vi) and (k)
What it means for your mobile app
SMS and email codes are the weakest link in account takeover, and a link in a bank message looks like a phishing message. Login and high-risk transactions should move to app-bound or phishing-resistant methods, and message content should be link-free.
How Ostorlab helps
Authenticated testing logs in with your test accounts, completes SMS, email and TOTP one-time codes, and tests MFA enforcement and step-up flows on key operations, including whether codes can be replayed, reused or bypassed, together with the API calls behind them.
What stays with you
Choosing the replacement authentication methods, the migration plan and customer communications.
- BSP Circular 1213, Section 1 (MORB Section 148), paragraph (e)(i)
Apply the 24-hour transaction pause after key account changes
What the text says
BSFIs must implement a 24-hour transaction pause period after applying key account changes, during which customers are restricted from performing financial transactions. Key account changes refer to modifications in information deemed essential to secure access to a customer's accounts, including updates to the mobile number, email address and the registered or authenticated device used to access the account. A BSFI may shorten the pause or apply transaction restrictions or limits instead, provided that strong authentication mechanisms are in place and the institution is fully accountable for the associated risks.
Source:BSP Circular 1213, Section 1 (MORB Section 148), paragraph (e)(i)
What it means for your mobile app
The pause is business logic. If the app or its APIs let a customer, or an attacker holding a session, skip it, the control has failed. Device registration should also be tested against spoofing.
How Ostorlab helps
The AI-agent pentest tests account change and device registration flows, and API testing checks whether the pause, the limits and the step-up checks hold on the server side, with request and response evidence.
What stays with you
The policy for shortened pauses and limits, customer notifications and the support process during the pause.
- BSP Circular 1213, Section 1 (MORB Section 148), paragraphs (e)(iii), (iv) and (v)
Block unauthorised automation and check device identity
What the text says
BSFIs must prohibit the use of unauthorized scripts or automation tools, such as screen scraping and browser automation, to access financial accounts and execute transactions, through measures such as behavioral analysis, rate limiting, session management and bot detection. They should also adopt strong device fingerprinting and effective mechanisms to prevent spoofing of device identity. Proper authentication and integrity checks should ensure that transactions initiated from front-end applications accessible to customers are not altered prior to, or during, transmission or execution in backend systems.
Source:BSP Circular 1213, Section 1 (MORB Section 148), paragraphs (e)(iii), (iv) and (v)
What it means for your mobile app
These controls sit in the API and the backend. Rate limits, session handling, integrity checks and device binding are testable, and each one can be missing on at least one endpoint.
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
Bot management and WAF operations, fraud surveillance, and the governance of device identity data.
- Republic Act No. 10173, Data Privacy Act of 2012, Section 20
Protect personal data and notify breaches
What the text says
Under the Data Privacy Act of 2012, personal information controllers must implement reasonable and appropriate organizational, physical and technical measures intended for the protection of personal information against accidental or unlawful destruction, alteration and disclosure, as well as against any other unlawful processing. The measures must include safeguards to protect computer networks, a security policy, a process for identifying and addressing reasonably foreseeable vulnerabilities in those networks, and regular monitoring for security breaches. Controllers must promptly notify the National Privacy Commission and affected data subjects when sensitive personal information, or information that could be used to enable identity fraud, is reasonably believed to have been acquired by an unauthorized person and is likely to give rise to a real risk of serious harm.
Source:Republic Act No. 10173, Data Privacy Act of 2012, Section 20
What it means for your mobile app
Customer data in the app and in the API traffic is personal data, and mobile malware, rooted devices and insecure storage are the ways it leaks.
How Ostorlab helps
Ostorlab tests the technical measures in the app and its APIs: storage and logs, transport, authentication and authorization, and access to other customers' data through broken access control, with evidence for each finding.
What stays with you
Privacy governance, records of processing, breach assessment and notification to the NPC and data subjects.
Summary of public BSP texts and the Data Privacy Act, checked on 27 September 2026. Quotes are from the circulars as published by the Bangko Sentral ng Pilipinas. This page is not legal advice.
BSP rules, control by control
The controls the BSP 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 |
|---|---|---|
| Application security tests before productionCircular 982, 3.3.3.4 | AI-agent pentest of the app and its APIs, behind login, on the build you ship. Details | A working exploit you can replay for each AI-agent finding, and a coverage heatmap |
| Annual external vulnerability assessment and penetration testingCircular 982, 3.7.2 (c) and (d) | External testing on every release, with severity ratings, tickets and retests between your annual tests. Details | Dated scan results per release, and retest results for each fix |
| Secure coding and static testing before releaseCircular 982, 3.3.3.4 and 3.3.3.8.1 | Mobile SAST on the APK, AAB or IPA, with taint analysis across the app and its embedded SDKs, run from CI/CD. Details | Findings with decompiled source context for each build |
| Patch management and vulnerable componentsCircular 982, 3.3.3.8.3 | 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 |
| Third-party and SDK oversightCircular 982, 3.3.3.8.4; Circular 1213, (c) | Lists the SDKs and native libraries in each release, and shows which backends the app and its SDKs talk to. Details | Component identity, version and location in the app bundle, per release |
| Credentials and keys in the app packageCircular 982, 3.3.3.4 | 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 |
| Rooted, jailbroken and emulated devicesCircular 1213, (e)(ii) | Runs the app in compromised environments and attempts to bypass root, jailbreak and emulator detection. Details | Hardening score, and bypass evidence for each protection that failed |
| Interceptable one-time PINs and strong authenticationCircular 1213, (e)(vi) | Logs in with one-time codes and tests MFA enforcement and step-up flows, including replay and reuse of codes. Details | Findings on login and step-up flows, with reproduction steps |
| Key account changes, the 24-hour pause and anti-automationCircular 1213, (e)(i), (iii) and (v) | Tests account change and device registration flows, API authorization, session handling and abuse such as replay and automation. Details | Request and response evidence for each finding, and retest results after the fix |
| Data protection on the device and in transitCircular 982, 3.3.3.5; RA 10173, Section 20 | 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 |
Ostorlab tests controls in the app and its APIs. Fraud monitoring systems and the transaction pause as fraud policy, alert delivery, SOC monitoring, incident response and reporting, transaction log retention, governance and the annual CCSA submission stay with your teams.
BSP controls to test in your mobile app
A practical list for security and IT risk teams, based on Circular 982, Circular 1213 and the Data Privacy Act.
Tests before each release
Put application security tests, including penetration tests and static analysis, in the release process before the build reaches production.
Annual external VA and PT
Schedule vulnerability assessment and penetration testing by an external party at least once a year, on top of per-release testing.
Components and patches
Keep a versioned list of the SDKs and libraries in each release, and fix high risk issues within a reasonable, documented timeframe.
Secrets in the app
Check the app package for API keys, tokens and credentials, and rotate any that work.
Compromised devices
Run the app on rooted, jailbroken and emulated devices, and check that access and transactions are restricted.
One-time PINs and strong authentication
Verify that one-time codes cannot be replayed or diverted, and that high-risk transactions require strong authentication.
Account changes and the pause
Test that mobile number, email and device changes trigger the pause period, and that it cannot be skipped through the app or its APIs.
Data on the device
Look for tokens and personal data in storage, caches, logs and screenshots, and test transport protections.
A suggested list, not a BSP template. This is not legal advice.
The capabilities behind this page
Each one has its own page with the details.
- 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
- Mobile Shielding ScanTest root, jailbreak and emulator detection, anti-tampering and pinning at runtime, and see which protections held and which were bypassed.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.
- BSP Circular No. 982, Series of 2017: Enhanced Guidelines on Information Security ManagementBSP, Monetary Board Resolution No. 1854 dated 2 November 2017, effective 5 December 2017. Amends Appendix 75b of the MORB and Appendix Q-59b of the MORNBFI: information security risk management, application security (3.3.3.4), data security (3.3.3.5), patch management (3.3.3.8.3) and testing (3.7)
- BSP Circular No. 808, Series of 2013: Guidelines on Information Technology Risk Management for All Banks and Other BSP Supervised InstitutionsBSP, Monetary Board Resolution No. 1286 dated 1 August 2013, issued 22 August 2013. The IT risk management framework for supervised institutions, amended by later circulars
- BSP Circular No. 1140, Series of 2022: Amendments to Regulations on Information Technology Risk ManagementBSP, Monetary Board Resolution No. 375 dated 17 March 2022, dated 24 March 2022. Adds automated, real-time fraud monitoring and detection systems and a reinforced consumer awareness program
- BSP Circular No. 1213, Series of 2025: Amendments to Regulations on Information Technology Risk Management to Implement Section 6 of the Anti-Financial Account Scamming Act (AFASA)BSP, Monetary Board Resolution No. 521 dated 22 May 2025, issued 30 May 2025 and effective 25 June 2025. Adds the 24-hour transaction pause, restrictions on unsecured devices, device fingerprinting, notification content, the ban on clickable links and QR codes, and limitations on interceptable one-time PINs
- AFASA Booklet with Implementing Rules and RegulationsBSP, June 2025. Republic Act No. 12010, signed 20 July 2024, with BSP Circulars Nos. 1213, 1214 and 1215, Series of 2025. Section 6 requires adequate risk management systems and controls, including MFA, to protect access to client financial accounts
- Republic Act No. 10173: Data Privacy Act of 2012National Privacy Commission, web version of the Act signed on 15 August 2012. Section 20 requires reasonable and appropriate organizational, physical and technical security measures, and breach notification to the NPC and affected data subjects
- BSP Circular No. 1232, Series of 2026: Cybersecurity Maturity Framework (CMF) and Cybersecurity Control Self-Assessment (CCSA) RequirementBSP, dated 27 April 2026. Replaces the IT Rating System with the Supervisory Assessment Framework and adds the CMF and the annual CCSA, with maturity tiers tied to each institution's IT profile
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.
Assess your mobile banking app the way the BSP describes it
Start with a free scan of your app from the store, or book a demo to run logged-in tests of your app and APIs with our team.