Are the CBSL technology risk directions mandatory?

Yes. They are issued by the Monetary Board under sections 46(1) and 76(J)(1) of the Banking Act, No. 30 of 1988, and apply to licensed commercial banks and licensed specialised banks, including operations through agents and third-party service providers. The framework sets compliance deadlines in its Table 4, as amended in December 2023.

Do the CBSL texts mention mobile apps?

Yes, in two places. The technology risk directions require pre-implementation security testing, quarterly vulnerability assessments and penetration tests of critical information systems and systems exposed to customer data, which include electronic delivery channels. The payment guideline applies specifically to payment related mobile applications and covers the app, web services, server-side infrastructure and network communication.

What do we need before launching a payment app in Sri Lanka?

Guideline No. 01/2020 requires a compliance report approved by the Board of Directors and submitted to the Director of the Payments and Settlements Department before the commercial launch, plus a report for the preceding year before 31 January each year. An information system audit and an information security audit by an independent third-party auditor are strongly recommended, covering static and dynamic analysis, source code review, hardcoded sensitive information and vulnerability assessment and penetration testing reviews.

How often are penetration tests required?

Critical information systems must be tested by independent external experts at least annually. Other systems exposed to customer data, and repositories of customer data at the bank, agents and third-party providers, at least once every two years. Tests should be threat intelligence-based and run on live production systems; the amended deadline for production testing is 31 December 2028. Black box and gray box testing with bank-provided user credentials are both required.

Does Ostorlab run our red team exercise or TLPT?

No. Red team exercises are run by the bank and its chosen external provider, extend beyond technology into human and physical layers, and are required once every two years for D-SIBs and once every three years for other licensed banks. Ostorlab does not run red team exercises and does not replace them. It keeps the app and API items of your remediation plan tested and retested before and after a red team cycle.

Does Ostorlab make our app meet the CBSL requirements?

No tool does that on its own. The framework covers governance, the Board's approvals, a 24x7 SOC, incident response planning and reporting, disaster recovery, vendor procurement and customer consent. Ostorlab helps you test the controls in your app and its APIs, and gives you evidence for each result, which you can attach to your compliance and audit files.

Can our data stay in the region?

Yes. On the Enterprise plan you can choose Asia-Pacific data residency, or run scans on-premises. Sri Lanka does not ban processing abroad, but the directions require Board approval for third-party infrastructure locations and explicit customer consent when customer data is exposed to third-party service providers, and consent for the location when that infrastructure is outside Sri Lanka. The Personal Data Protection Act adds cross-border rules from 1 January 2027. Ostorlab is SOC 2 Type II audited, and the details are in the Trust Center.

What do you need to run a scan?

At a minimum, you can search for your application on the App Store or Google Play and run a free, fast scan on ostorlab.co with no login required. Or provide the mobile artifact (APK, AAB or IPA). For deeper coverage of authenticated flows, add test credentials before running a full scan.

CBSL technology risk directions: assess your mobile banking app before and after every release.

The Central Bank of Sri Lanka requires licensed banks to run pre-implementation security testing, vulnerability assessments at least quarterly and penetration tests by independent external experts. The guideline for payment related mobile applications adds device registration, multi-factor authentication, session controls, tamper detection and certificate pinning. Ostorlab tests your app and the APIs behind it, behind login, on every release.

Assesses the mobile app and the APIs it calls, on the build your customers download
Tests login, one-time codes, MFA, account lockout and session handling with your test accounts
Checks root and jailbreak detection, anti-tampering, debugger and emulator checks and certificate pinning at runtime
Lists the SDKs and native libraries in each release and maps them to known vulnerabilities with fix deadlines

Scan your own app Book a demo

Free scan of your app from the App Store or Google Play. No login required.

Who it applies to: Licensed commercial and specialised banks under the technology risk directions, and payment service providers that run or facilitate payment related mobile applications
Key dates: Directions No. 16 of 2021 issued 9 December 2021 and amended on 8 December 2023; production penetration tests due by 31 December 2028; Personal Data Protection Act Parts I and III from 1 January 2027
Focus: Pre-implementation testing, quarterly vulnerability assessments, annual penetration tests and mobile payment app controls
Main references: Banking Act Directions No. 16 of 2021 and Guidelines on Minimum Compliance Standard for Payment Related Mobile Applications No. 1 of 2020

Key dates

The CBSL texts behind your mobile channel

The technology risk directions sit alongside the payment guideline for mobile applications and the payment circulars that set transaction rules. The dates below are for the texts cited on this page.

1 June 2020
Guideline No. 01/2020 applies
The minimum compliance standard for payment related mobile applications takes effect, replacing the 2018 guideline. It covers the app, web services, server-side infrastructure and network communication.
9 December 2021
Technology risk directions
Banking Act Directions No. 16 of 2021 apply to licensed banks, with information security testing, encryption, access management, SOC and third-party infrastructure requirements.
8 December 2023
Amended deadlines
Directions No. 05 of 2023 amend the framework: revised compliance deadlines, including production penetration tests by 31 December 2028, and quarterly access privilege reviews for critical systems.
17 January 2024
JustPay OTP
Payment and Settlement Systems Circular No. 01 of 2024 requires an OTP from the issuer for JustPay transactions of Rs 10,000 or more, sent to the mobile number registered with the issuer. In operation since 1 April 2024.
3 December 2024
Customer identification for payment apps
Circular No. 02 of 2024 requires payment app providers to identify users with an accepted identity document, verify that identity and match the device mobile number with the account mobile number when linking an account, from 31 March 2025.
7 May 2025
Incident reporting circular
Circular No. 02 of 2025 requires licensed banks to report IT and cybersecurity incidents to the Director of Bank Supervision within 2 hours of detection, with detailed reports within 14 days and quarterly reports after each quarter.
20 January 2026
JustPay limits and registration controls
Circular No. 01 of 2026 caps JustPay transactions at Rs 150,000 and requires mobile payment application providers to apply adequate security controls and procedures when registering customers and linking accounts, in operation from 2 February 2026.
22 July 2026
Data Protection Act commencement order
Extraordinary Gazette No. 2498/16 appoints 1 January 2027 for Section 2, Section 3, Part I and Part III of the Personal Data Protection Act, covering the processing principles and the controller and processor obligations.

What the CBSL asks

The CBSL technology risk 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. Items from the technology risk directions and the payment guideline are summarised from the English texts.

Banking Act Directions No. 16 of 2021, 5.8.1; compliance deadline 31 December 2025 as amended by Directions No. 05 of 2023
Test before implementation and before each change
What the text says
Critical information systems and information systems exposed to customer data must go through pre-implementation information security tests, both before initial implementation and before modifications, unless a board-approved exclusion policy covers the specific minor change. The framework names the tests: static application security testing (SAST) or source code reviews, dynamic application security testing (DAST), hardening checks on computing and networking infrastructure, and infrastructure vulnerability assessments. The tests must be conducted by a team independent of the team that develops or implements the system.
Source:Banking Act Directions No. 16 of 2021, 5.8.1; compliance deadline 31 December 2025 as amended by Directions No. 05 of 2023
What it means for your mobile app
Every mobile release that touches a critical or customer-data system is a modification. The pipeline and the release process need automated, independent security tests on the build customers download.
How Ostorlab helps
Mobile SAST works on the APK, AAB or IPA, with no source code needed, and Mobile DAST tests the running app in CI/CD. The AI-agent pentest tests the app and its APIs behind login, with a working exploit you can replay for each AI-agent finding.
What stays with you
The exclusion policy and its board approval, the independence of the test team, source code access and release approval.
Banking Act Directions No. 16 of 2021, 5.8.2 and 5.2.4 (as amended by Directions No. 05 of 2023)
Run vulnerability assessments at least quarterly
What the text says
Critical information systems and information systems exposed to customer data are subject to vulnerability assessments at least quarterly. The assessments focus on both infrastructure vulnerabilities and application vulnerabilities and are performed on production environments. Vulnerabilities identified must be remediated within a time period approved by the bank's Information Security Committee. The same framework requires user access privilege reviews at least quarterly for critical systems and bi-annually for non-critical systems exposed to customer or confidential non-customer data.
Source:Banking Act Directions No. 16 of 2021, 5.8.2 and 5.2.4 (as amended by Directions No. 05 of 2023)
What it means for your mobile app
Four assessment cycles a year on the production app and its APIs leaves little room for one-off manual testing. The cadence has to be automated and repeatable.
How Ostorlab helps
Ostorlab runs scheduled scans from your CI/CD pipeline and monitors store releases without manual triggers. Findings are rated critical, high, medium or low and tracked as tickets in the platform or in Jira and ServiceNow.
What stays with you
Remediation deadlines approved by the ISC, infrastructure patching and production change management.
Banking Act Directions No. 16 of 2021, 5.8.3; production deadline 31 December 2028 as amended by Directions No. 05 of 2023
Penetration tests by independent external experts
What the text says
Critical information systems, information systems exposed to customer data and repositories of customer data, including those held by agents and third-party service providers, must be tested by independent external penetration testing experts. Critical information systems at least annually, and all other qualifying systems at least once every two years. The tests are threat intelligence-based, conducted on live production systems under normal business conditions, without changing the security measures normally in place, and cover external and internal threats. Both black box tests and gray box tests using bank-provided login credentials for customer, operational and managerial user categories are required. A Penetration Test Scope Specification defines the systems, threat scenarios, targets and time period, the Board of Directors approves the exercise, and an executive summary goes to the Director of Bank Supervision within 60 days of the provider's report.
Source:Banking Act Directions No. 16 of 2021, 5.8.3; production deadline 31 December 2028 as amended by Directions No. 05 of 2023
What it means for your mobile app
The annual penetration test is the deepest assessment in the framework, and the app, its APIs and test accounts are the parts a mobile-focused vendor can cover. Note the timing: penetration tests on production systems are due by 31 December 2028.
How Ostorlab helps
The AI-agent pentest tests the app and its APIs behind login with your test accounts, including grey box flows, and gives you a replayable exploit for each AI-agent finding. Findings are grouped into tickets and retested after the fix ships.
What stays with you
Board approval of the PTSS and the exercise, the leadership team, the external provider's accreditation, background checks and references, and the 60-day report to the Director of Bank Supervision.
Banking Act Directions No. 16 of 2021, 5.8.4
Prepare for red team exercises
What the text says
Red team exercises extend penetration tests to the human and physical layers of security. D-SIBs must conduct them at least once every two years and other licensed banks at least once every three years, based on a Red Teaming Scope Statement approved by the Board of Directors and paired with a penetration test in the same cycle. Where the Board determines that the bank's security maturity is not yet sufficient, exercises are deferred by up to 12 months.
Source:Banking Act Directions No. 16 of 2021, 5.8.4
What it means for your mobile app
Red teaming tests the whole bank, not the app. It is a different kind of engagement from an external penetration test, and it is expected alongside it.
How Ostorlab helps
Ostorlab does not run red team exercises and does not replace them. It keeps the app and API items of your remediation plan tested and retested, so the technology layer is in shape going into a red team cycle.
What stays with you
Scoping and running red team exercises, the RTSS, the Board decisions and the human and physical layer assessments.
Guidelines on Minimum Compliance Standard for Payment Related Mobile Applications No. 1 of 2020, sections 5, 6 and 8
Implement the mobile payment app controls: MFA, device binding, sessions and lockout
What the text says
The payment guideline requires user accounts and devices to be registered with the provider using the mobile number and a unique device identifier, with an account usable only on registered devices and no concurrent use of the same account from multiple devices. Authentication must be processed at the backend, except for methods based on biometrics or chip-based authentication. MFA combines the mobile number, device identifier, password or PIN and an identifier specific to the application. The app must have a configurable account lockout after multiple invalid login attempts, a randomized session ID, automatic user logoff after an idle time period, a clearly visible logoff that erases application specific sensitive data from temporary and permanent memory, server-side detection of simultaneous login attempts, and a procedure to disable the app centrally for a device reported lost or stolen.
Source:Guidelines on Minimum Compliance Standard for Payment Related Mobile Applications No. 1 of 2020, sections 5, 6 and 8
What it means for your mobile app
These are testable behaviours, and they have to hold on the backend, not only in the app interface. An attacker who calls the API directly should meet the same controls.
How Ostorlab helps
Authenticated testing covers login and logout, token refresh, timeouts, session invalidation, account lockout and MFA enforcement with your test accounts, including the API calls behind them.
What stays with you
Identity and access management, device registration records and the lost-device process.
Guidelines on Minimum Compliance Standard for Payment Related Mobile Applications No. 1 of 2020, sections 12, 13, 14 and 15
Harden the app: tamper, root, debugging and pinning
What the text says
The guideline requires server-side integrity checks on hash values or checksums of code blocks, on file sizes and modification timestamps, and on the signature of the package file, with the app disabled if the checks fail. The app must not run on rooted or jailbroken devices. Debugger and emulator detection must be implemented, minification and source code obfuscation must be used, and third parties must not be able to debug the app at runtime. Transport layer encryption is required for all communication, with valid SSL certificates from a trusted certificate authority, certificate pinning implemented with proper exception handling, and controls to mitigate pinning bypass. The app must cease operations until SSL certificate errors are properly addressed.
Source:Guidelines on Minimum Compliance Standard for Payment Related Mobile Applications No. 1 of 2020, sections 12, 13, 14 and 15
What it means for your mobile app
These protections are what an attacker tests first on a payment app. A control that exists in code but can be bypassed at runtime does not count.
How Ostorlab helps
Mobile Shielding Scan tests root and jailbreak detection, anti-tampering, debugger and emulator checks and pinning at runtime, and shows which protections held and which were bypassed.
What stays with you
Obfuscation and code signing infrastructure, app store releases and the app's behaviour in the field.
Guidelines on Minimum Compliance Standard for Payment Related Mobile Applications No. 1 of 2020, sections 11 and 16; Banking Act Directions No. 16 of 2021, 5.8.2
Keep components patched and prove it
What the text says
Payment related mobile applications must not use vulnerable or deprecated components, protocols, libraries or scripts, implementations of those components must not lead to vulnerabilities, and the app must be properly patched if a vulnerability is identified. Cryptographic algorithms and iteration counts must be currently not identified as vulnerable, industry-tested and accepted by institutions such as the FFIEC, ANSI and NIST. Under the technology risk directions, vulnerabilities identified in assessments must be remediated within a time period approved by the ISC.
Source:Guidelines on Minimum Compliance Standard for Payment Related Mobile Applications No. 1 of 2020, sections 11 and 16; Banking Act Directions No. 16 of 2021, 5.8.2
What it means for your mobile app
The SDKs and native libraries in a banking app are shipped software. Each one needs a known version, a severity when a vulnerability appears, and a fix deadline you can prove.
How Ostorlab helps
SCA fingerprints statically compiled libraries and maps them to known vulnerabilities release after release. Closure is tracked as tickets in the platform or in Jira and ServiceNow, and findings are rated critical, high, medium or low.
What stays with you
Patching decisions, vendor maintenance contracts, upgrade planning and risk acceptance.
Banking Act Directions No. 16 of 2021, 5.5.1; Guidelines No. 1 of 2020, sections 9.3, 11.2 and 11.3; Personal Data Protection Act No. 9 of 2022, section 10
Protect customer data on the device and in transit
What the text says
Under the technology risk directions, customer data is protected using encryption: database or file level encryption at rest, encryption for data in transit, and full disk encryption for endpoint devices and removable media that store customer data. Where encryption is not feasible or appropriate, deviations need Board approval, compensating controls and monitoring, and a review at least once every two years. The payment guideline adds that sensitive information such as account numbers and customer credentials in temporary storage on the device must be secured, that sensitive data is encrypted in transit and at rest, that encryption keys are not stored on the mobile device without appropriate security controls, and that sensitive data is not stored on the device. The Personal Data Protection Act requires controllers to ensure the integrity and confidentiality of personal data with appropriate technical and organizational measures, including encryption, pseudonymisation, anonymisation or access controls.
Source:Banking Act Directions No. 16 of 2021, 5.5.1; Guidelines No. 1 of 2020, sections 9.3, 11.2 and 11.3; Personal Data Protection Act No. 9 of 2022, section 10
What it means for your mobile app
Tokens, account numbers and credentials should never sit in clear text in the app's storage, caches, logs or crash reports, and they should not travel unprotected to the backend.
How Ostorlab helps
Ostorlab looks for session tokens and personal data in local storage, caches, logs and screenshots, and checks for misconfigurations that weaken transport and session protections.
What stays with you
Data classification, key management, backups, and the deviation process with the Board.
Payment and Settlement Systems Circulars No. 01 of 2024, No. 02 of 2024 and No. 01 of 2026
Apply the JustPay OTP threshold and payment app onboarding checks
What the text says
For JustPay transactions of Rs 10,000 or more, the mobile payment application that initiates the transaction must request a one-time password from the issuer of the linked account, sent to the mobile number registered with the issuer. This has applied since 1 April 2024. From 31 March 2025, providers must identify users with an acceptable identity document, verify that identity before allowing transactions or linking an account, and, for JustPay, verify that the app user and the account owner are the same by matching the mobile number of the device with the mobile number registered for the account. Circular No. 01 of 2026 caps JustPay transactions at Rs 150,000 from 2 February 2026 and requires all mobile payment application providers to implement adequate security controls and procedures when registering customers and linking accounts.
Source:Payment and Settlement Systems Circulars No. 01 of 2024, No. 02 of 2024 and No. 01 of 2026
What it means for your mobile app
OTP enforcement and the identity checks are backend behaviours. Test them by trying to complete a transaction or link an account without the required factor or with the wrong device.
How Ostorlab helps
Ostorlab completes SMS, email or TOTP one-time codes with your test accounts and tests OTP enforcement, MFA and step-up flows, together with the API calls behind account linking and payments.
What stays with you
The identity verification process, device registration records and the transaction limits configuration.
Guidelines on Minimum Compliance Standard for Payment Related Mobile Applications No. 1 of 2020, section 25
Audit before launch and report annually
What the text says
Each payment service provider must submit a compliance report, approved by its Board of Directors, to the Director of the Payments and Settlements Department before the commercial launch of each payment related mobile application, and a report for the preceding year before 31 January each year covering new versions, patches and updates. An information system audit and an information security audit of the whole ecosystem are strongly recommended by an independent third-party auditor, with a scope that includes static and dynamic security analysis, source code review for secure controls, backdoors and hardcoded sensitive information, production and testing environment reviews, and vulnerability assessment and penetration testing reviews.
Source:Guidelines on Minimum Compliance Standard for Payment Related Mobile Applications No. 1 of 2020, section 25
What it means for your mobile app
The compliance file needs evidence, not just claims, and every new version restarts the cycle in practice.
How Ostorlab helps
Ostorlab produces scan results, request and response evidence, exploits you can replay and retest results for each release, which you can attach to the audit file. Ostorlab does not submit reports to CBSL and is not an audit firm.
What stays with you
Board approval of the compliance report, the submissions to CBSL and any opinion you ask a licensed audit firm for.

Summary of public CBSL texts and the Personal Data Protection Act, checked on 27 September 2026. The payment guideline items are summarised from the English text. This page is not legal advice.

Mapping

CBSL rules, control by control

The controls the CBSL texts point to, how Ostorlab tests them in your app and its APIs, and the evidence you can keep.

CBSL rules, control by control
Control	How Ostorlab helps	Evidence you keep
Pre-implementation security testing of the appDirections 16/2021, 5.8.1	Mobile SAST on the APK, AAB or IPA and Mobile DAST in CI/CD, on every change, with no source code needed. Details	Scan results per build and per change, attached to the release record
Quarterly vulnerability assessments on productionDirections 16/2021, 5.8.2	Scheduled scans from your pipeline on the production build, and monitoring of store releases without manual triggers. Details	Assessment results per quarter, with severity and remediation status
Annual penetration test by independent external expertsDirections 16/2021, 5.8.3	AI-agent pentest of the app and its APIs behind login, including grey box flows with your test accounts. Details	A working exploit you can replay for each AI-agent finding, and a coverage heatmap
Login, MFA and account lockoutGuideline 01/2020, 6	Logs in with one-time codes and tests MFA enforcement, step-up flows and lockout after invalid attempts. Details	Findings on login and lockout flows, with reproduction steps
Device registration, sessions and lost-device disableGuideline 01/2020, 5 and 8	Tests session randomization, idle logoff, session invalidation and the API calls behind device registration. Details	Session and token findings, with request and response logs
Tamper, root and emulator detection, certificate pinningGuideline 01/2020, 12 to 15	Tests root and jailbreak detection, anti-tampering, debugger and emulator checks and pinning at runtime. Details	Bypass evidence showing which protection failed and what it exposed
Vulnerable components and patch deadlinesGuideline 01/2020, 11 and 16	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
Hardcoded keys and sensitive configurationGuideline 01/2020, 16.5	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
Customer data on the device and in transitDirections 16/2021, 5.5.1; Guideline 11	Looks for tokens and personal data in storage, caches, logs and screenshots, and checks transport protections.	File system evidence showing what was written, where and when
Third-party SDKs and infrastructure in the releaseDirections 16/2021, 9.9; Guideline 23	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

Ostorlab tests controls in the app and its APIs. SOC monitoring, incident response and reporting, red team exercises, TLPT, disaster recovery, governance, vendor procurement and Board approvals stay with your teams.

Action plan

CBSL controls to test in your mobile app

A practical list for security and technology risk teams, based on the CBSL technology risk directions, the mobile payment guideline and the Personal Data Protection Act.

Pre-release testing
Put SAST or source code review and DAST in the pipeline for every change to the app and its backend, as the pre-implementation tests require.
Quarterly vulnerability assessments
Schedule app and API assessments on production at least quarterly, with remediation deadlines approved by the Information Security Committee.
Annual penetration test
Plan the Board-approved scope specification and the external test: black box and grey box, threat scenarios, production systems, and the 60-day executive summary to the Director of Bank Supervision.
App hardening
Test root and jailbreak detection, anti-tampering, debugger and emulator checks, obfuscation and pinning, and confirm the app disables itself when integrity checks fail.
Authentication, OTP and sessions
Verify MFA at the backend, account lockout, randomized session IDs, idle logoff that erases sensitive data, lost-device disable, and the JustPay OTP threshold.
Components and secrets
List the SDKs and libraries in each release, set fix deadlines by severity, and check the package for hardcoded keys and configuration.
Data protection
Check storage, caches, logs and crash reports for tokens and personal data, and keep encryption and the data protection measures documented.
Report and retest
Keep the pre-launch compliance report, the 31 January annual report and retest evidence for every fix.

A suggested list, not a CBSL template. This is not legal advice.

Platform

The capabilities behind this page

Each one has its own page with the details.

Trusted by banks and fintechs, including

4.8/5 on Gartner Peer Insights SOC 2 Type II audited

Sources

The official texts this page is based on, checked on 27 September 2026.

Guidelines on Minimum Compliance Standard for Payment Related Mobile Applications (Guideline No. 01/2020)CBSL, issued 29 May 2020, in effect from 1 June 2020, replacing Guideline No. 01 of 2018. Device registration, authentication, sessions, data storage, cryptography, tamper detection and pre-launch compliance reporting for payment related mobile applications and their ecosystem (English text)
Banking Act Directions No. 16 of 2021, Regulatory Framework on Technology Risk Management and Resilience for Licensed BanksCBSL, 9 December 2021. Applies to licensed commercial banks and licensed specialised banks, including operations conducted through agents and third-party service providers. Information security testing, encryption, access management and infrastructure requirements (English text)
Banking Act Directions No. 05 of 2023, Amendments to the Banking Act Directions No. 16 of 2021CBSL, 8 December 2023. Revised compliance deadlines, including production penetration tests by 31 December 2028, quarterly access privilege reviews for critical systems, and head-office penetration test teams for banks incorporated outside Sri Lanka
Payment and Settlement Systems Circular No. 01 of 2024, Facilitating safer and more secure transactions via mobile payment applicationsCBSL, 17 January 2024, in operation from 1 April 2024. One-time password from the issuer for JustPay transactions of Rs 10,000 or more, sent to the mobile number registered with the issuer
Payment and Settlement Systems Circular No. 02 of 2024, Strengthening Customer Identification Process to Safeguard Funds in Current Accounts/Savings Accounts linked to Mobile Payment ApplicationsCBSL, 3 December 2024, applicable from 31 March 2025. Identity document checks, verification before transactions, and matching the device mobile number with the account mobile number when linking an account
Payment and Settlement Systems Circular No. 01 of 2026, Maximum per transaction limit and fees for JustPay transactionsCBSL, 20 January 2026, in operation from 2 February 2026. JustPay transactions capped at Rs 150,000, and adequate security controls and procedures required when registering customers and linking accounts
Circular No. 02 of 2025, Reporting of Information Technology and Cybersecurity Incidents of Licensed BanksCBSL, 7 May 2025. Immediate reporting to the Director of Bank Supervision within 2 hours of detection, detailed reporting within 14 days and quarterly reporting within 15 days of each quarter
Personal Data Protection Act No. 9 of 2022Certified on 19 March 2022, amended by the Personal Data Protection (Amendment) Act No. 22 of 2025, certified on 30 October 2025. Extraordinary Gazette No. 2498/16 of 22 July 2026 appoints 1 January 2027 for Section 2, Section 3, Part I and Part III, covering the processing principles and controller and processor obligations (English text)

FAQ

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.

Yes, in two places. The technology risk directions require pre-implementation security testing, quarterly vulnerability assessments and penetration tests of critical information systems and systems exposed to customer data, which include electronic delivery channels. The payment guideline applies specifically to payment related mobile applications and covers the app, web services, server-side infrastructure and network communication.
Guideline No. 01/2020 requires a compliance report approved by the Board of Directors and submitted to the Director of the Payments and Settlements Department before the commercial launch, plus a report for the preceding year before 31 January each year. An information system audit and an information security audit by an independent third-party auditor are strongly recommended, covering static and dynamic analysis, source code review, hardcoded sensitive information and vulnerability assessment and penetration testing reviews.
Critical information systems must be tested by independent external experts at least annually. Other systems exposed to customer data, and repositories of customer data at the bank, agents and third-party providers, at least once every two years. Tests should be threat intelligence-based and run on live production systems; the amended deadline for production testing is 31 December 2028. Black box and gray box testing with bank-provided user credentials are both required.
No. Red team exercises are run by the bank and its chosen external provider, extend beyond technology into human and physical layers, and are required once every two years for D-SIBs and once every three years for other licensed banks. Ostorlab does not run red team exercises and does not replace them. It keeps the app and API items of your remediation plan tested and retested before and after a red team cycle.
Yes. On the Enterprise plan you can choose Asia-Pacific data residency, or run scans on-premises. Sri Lanka does not ban processing abroad, but the directions require Board approval for third-party infrastructure locations and explicit customer consent when customer data is exposed to third-party service providers, and consent for the location when that infrastructure is outside Sri Lanka. The Personal Data Protection Act adds cross-border rules from 1 January 2027. Ostorlab is SOC 2 Type II audited, and the details are in the Trust Center.

Assess your mobile banking app the way the CBSL 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.

Scan your own app Book a demo

CBSL technology risk directions: assess your mobile banking app before and after every release.

The CBSL texts behind your mobile channel

Guideline No. 01/2020 applies

Technology risk directions

Amended deadlines

JustPay OTP

Customer identification for payment apps

Incident reporting circular

JustPay limits and registration controls

Data Protection Act commencement order

The CBSL technology risk rules, applied to your mobile app

Test before implementation and before each change

What the text says

What it means for your mobile app

How Ostorlab helps

What stays with you

Run vulnerability assessments at least quarterly

What the text says

What it means for your mobile app

How Ostorlab helps

What stays with you

Penetration tests by independent external experts

What the text says

What it means for your mobile app

How Ostorlab helps

What stays with you

Prepare for red team exercises

What the text says

What it means for your mobile app

How Ostorlab helps

What stays with you

Implement the mobile payment app controls: MFA, device binding, sessions and lockout

What the text says

What it means for your mobile app

How Ostorlab helps

What stays with you

Harden the app: tamper, root, debugging and pinning

What the text says

What it means for your mobile app

How Ostorlab helps

What stays with you

Keep components patched and prove it

What the text says

What it means for your mobile app

How Ostorlab helps

What stays with you

Protect customer data on the device and in transit

What the text says

What it means for your mobile app

How Ostorlab helps

What stays with you

Apply the JustPay OTP threshold and payment app onboarding checks

What the text says

What it means for your mobile app

How Ostorlab helps

What stays with you

Audit before launch and report annually

What the text says

What it means for your mobile app

How Ostorlab helps

What stays with you

CBSL rules, control by control

CBSL controls to test in your mobile app

Pre-release testing

Quarterly vulnerability assessments

Annual penetration test

App hardening

Authentication, OTP and sessions

Components and secrets

Data protection

Report and retest

The capabilities behind this page

Sources

Frequently asked questions

01Are the CBSL technology risk directions mandatory?

02Do the CBSL texts mention mobile apps?

03What do we need before launching a payment app in Sri Lanka?

04How often are penetration tests required?

05Does Ostorlab run our red team exercise or TLPT?

06Does Ostorlab make our app meet the CBSL requirements?