SFC Colombia: assess your mobile banking app twice a year and on every release.
The SFC's Circular Básica Jurídica asks supervised entities to test the internet channel at least twice a year, with an extra test after changes that affect channel security, and to run two-factor authentication on mobile banking operations. The cybersecurity chapter requires apps and web services that handle confidential data to be secured across the software lifecycle. 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 two-factor authentication, one-time codes, step-up flows and session cut-off with your test accounts
- Lists the SDKs and native libraries in each release and maps them to known vulnerabilities
- Proves each finding with a replayable exploit or request and response evidence
- Who it applies to
- Entities supervised by the SFC, including banks and other financial entities, and PILA information operators, under the Circular Básica Jurídica
- Key date
- Mobile banking and internet channel requirements applied from 1 December 2018; the Circular Básica Jurídica was re-issued on 25 June 2025 by Circular Externa 006 de 2025
- Focus
- Vulnerability assessment and penetration testing of the internet and mobile banking channels, two-factor authentication, and open finance API security standards
- Main reference
- Circular Básica Jurídica, Part I (Circular Externa 006 de 2025)
The SFC texts behind your mobile channel
The cybersecurity chapter and the channels chapter sit in Part I of the Circular Básica Jurídica. The dates below are for the texts cited on this page.
- 17 October 2012
Law 1581 of 2012
Colombia issues its general personal data protection regime: prior, express and informed authorisation, security duties for controllers, and rules on international transfers of personal data.
- 5 June 2018
Circular Externa 007 and 008 de 2018
Circular Externa 007 de 2018 adds the cybersecurity chapter to Part I of the CBJ; Circular Externa 008 de 2018 amends the channels, security and quality chapter, including the mobile banking requirements. The channel amendments apply from 1 December 2018.
- 17 November 2020
Circular Externa 033 de 2020
The SFC adds the Single Taxonomy of Cyber Incidents (TUIC), the Traffic Light Protocol and Formato 408 for security metrics; the first official metrics report follows with cut-off 31 March 2021.
- 7 February 2024
Circular Externa 004 de 2024
The SFC instructs on open finance and adds the open finance chapter to the CBJ, with the FAPI 2.0, OAuth 2.0 and mutual TLS standards for the APIs that carry consumer data.
- 25 June 2025
Circular Básica Jurídica re-issued
Circular Externa 006 de 2025 re-issues the CBJ, consolidating the channels, cybersecurity and open finance chapters cited on this page.
- 3 February 2026
Transition regime extended
Circular Externa 001 de 2026 extends the transition regime for the open finance architecture, security and technology standards that Circular Externa 009 de 2025 had set.
- 7 April 2026
Mandatory open finance
Decreto 368 de 2026 replaces the voluntary open finance framework with a mandatory system, and requires the SFC to publish the common standards and a work schedule, and to open the participants directory.
The SFC 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. The Circular Básica Jurídica is summarised from its Spanish text.
- Circular Básica Jurídica, Part I, Title IV, Chapter V, numeral 3 (chapter added by Circular Externa 007 de 2018; Spanish text)
Govern cybersecurity risk and report to the board
What the text says
Supervised entities must have policies, procedures and technical and human resources to manage cybersecurity risk. The policy must be approved by the board, and an information security and cybersecurity unit must report to the board and senior management at least every six months on confidentiality, integrity and availability, cyber threats, programme effectiveness and incidents. Security budgets must be managed separately from operations and technology. In the prevention stage, entities must manage access controls and identities, prevent data leakage, measure emerging cyber risks and consider a security operations centre (SOC).
What it means for your mobile app
A mobile banking app is one of the services your security unit has to watch, and the board report needs current evidence on the app and its APIs, not only on servers.
How Ostorlab helps
Ostorlab gives continuous, per-release results for the app and its APIs, rated by severity and tracked to closure, so the figures your unit reports are backed by scan evidence.
What stays with you
The policy, the security unit, board reporting, budget decisions and whether to contract a SOC.
- Circular Básica Jurídica, Part I, Title IV, Chapter V, numeral 3.8 (Spanish text)
Build security into the software lifecycle of apps and web services
What the text says
The cybersecurity chapter requires entities to take information security into account throughout the software development lifecycle, including web services and apps that process confidential information of the entity or of financial consumers, from the initial requirements stage through security testing and production.
Source:Circular Básica Jurídica, Part I, Title IV, Chapter V, numeral 3.8 (Spanish text)
What it means for your mobile app
The app and its backends are explicitly named. Security testing has to be part of the lifecycle, not a one-off exercise before an audit.
How Ostorlab helps
Mobile SAST analyses the APK, AAB or IPA with no source code needed, and the AI-agent pentest tests the running app and its APIs; both can run in CI/CD on every build.
What stays with you
Security requirements, secure coding standards, code reviews and release approval.
- Circular Básica Jurídica, Part I, Title IV, Chapter V, numerals 4.1.4 and 4.2.2 (Spanish text)
Manage vulnerabilities on systems exposed to the internet
What the text says
Entities must identify and measure emerging cyber risks and set controls to mitigate them, and they must manage the vulnerabilities of the platforms that support critical information assets and are exposed in cyberspace. The prevention, protection and detection stages include access control and identity management, data leakage prevention, continuous monitoring, and tools such as a SIEM to correlate events.
Source:Circular Básica Jurídica, Part I, Title IV, Chapter V, numerals 4.1.4 and 4.2.2 (Spanish text)
What it means for your mobile app
The mobile backend, and the app itself as a component you distribute, are exposed platforms. Vulnerabilities need an owner, a severity and a fix deadline, release after release.
How Ostorlab helps
SCA fingerprints statically compiled libraries in the app and maps them to known vulnerabilities; findings are rated and tracked as tickets in the platform or in Jira and ServiceNow, and retested after the fix.
What stays with you
Server and infrastructure patching, SIEM, monitoring, and accepting or rejecting the residual risk.
- Circular Básica Jurídica, Part I, Title II, Chapter I, numerals 2.3.4.9.2 and 2.3.4.11.6 (Spanish text)
Test the internet channel at least twice a year
What the text says
Entities that offer operations over the internet must carry out vulnerability and penetration tests on the equipment, devices and communication media used for monetary operations at least twice a year, and an additional test whenever changes are made to the platform that affect the security of the channel. Sessions that start from a mobile device and use the internet must meet the same requirements, and services delivered through mobile browsers are treated as internet banking.
What it means for your mobile app
Two tests a year is the floor, not the ceiling: every release changes the app, and platform changes trigger an extra test. Store builds are part of the internet-facing channel.
How Ostorlab helps
Ostorlab runs automated scans on every build from your CI/CD pipeline and monitors store releases without manual triggers, so app and API findings arrive between the scheduled tests. It does not replace a manual penetration test where one is required.
What stays with you
Scoping and commissioning the twice-yearly test, the change assessment that decides when an extra test is needed, and the report to the board.
- Circular Básica Jurídica, Part I, Title II, Chapter I, numerals 2.3.4.11.1, 2.3.4.9.8 and 1.2.2.1.2.16 (Spanish text)
Require two factors on every mobile banking operation
What the text says
Mobile banking is the channel in which the phone is used to perform operations, whether the line is linked to the service or an app is used. Entities must have two-factor authentication mechanisms for monetary and non-monetary operations, and operations over the internet must offer customers strong authentication mechanisms. For operations performed from mobile banking, the strong authentication mechanism must take place at the origin of the transaction.
What it means for your mobile app
The second factor has to be enforced by the server for monetary and non-monetary operations, including balance inquiries and profile changes, not only at login.
How Ostorlab helps
Authenticated testing completes login, one-time codes and step-up flows with your test accounts, and checks that the API calls behind each operation enforce the second factor.
What stays with you
Choosing and deploying the authentication methods, and the customer support process when the second factor fails.
- Circular Básica Jurídica, Part I, Title II, Chapter I, numerals 2.3.4.11.2, 2.3.4.11.4 and 2.3.3.1.6; Part I, Title IV, Chapter V, numeral 3.4 (Spanish text)
Encrypt confidential operations data end to end
What the text says
For individual monetary operations, or those that accumulate above 2 monthly legal minimum wages per customer, entities must use strong end-to-end encryption to send and receive the confidential data of the operation, such as passwords, account numbers and card numbers; this data must not be known to telecom network providers or any party other than the financial entity. Below that threshold, entities must adopt measures to mitigate the risk, considering the security of the places where information is not encrypted, and the SFC may suspend the channel if it finds failures that affect information security. Confidential information must also be protected at rest and in transit, and access keys must be protected: shared, generic or group keys are not allowed.
What it means for your mobile app
The threshold is in the regulation: above 2 SMMLV end-to-end encryption is required, and below it the app still needs mitigations. Keys and tokens must not be shared between users or sit in clear text.
How Ostorlab helps
Ostorlab inspects local storage, caches, logs and screenshots for confidential data in clear text, finds API keys, tokens and credentials in the app package and validates whether they work, and intercepts traffic even with TLS pinning to check transport protections.
What stays with you
Choosing the encryption scheme and key management, contract terms with telecom providers, and the risk decision for lower-value operations.
- Circular Básica Jurídica, Part I, Title IV, Chapter V, numerals 3.9 and 3.10; Part I, Title I, Chapter IX, numeral 2 (Spanish text)
Control critical third parties and the components you ship
What the text says
Contracts with critical third parties must include the measures and obligations needed to adopt and comply with information security and cybersecurity policies, and entities must periodically verify that those obligations are met. For open finance, the CBJ lists what data-receiving third parties must have: registration in the National Database Registry or personal data policies, security and privacy risk management using frameworks such as ISO 27001, the NIST Cybersecurity Framework or OWASP ASVS, encryption with AES or RSA at least, monitoring systems, vulnerability management, PCI-DSS attestation when card data is involved, and prompt notification of security events. Entities must verify these requirements periodically and keep the evidence for the SFC.
What it means for your mobile app
Third-party SDKs inside the app and the backends they call are part of the supply chain, and in open finance every data receiver is a third party you must vet and monitor.
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 what the app and its SDKs exchange with backends over the network.
What stays with you
Due diligence, contracts, the register of receivers, PCI-DSS attestations and the periodic verification file.
- Circular Básica Jurídica, Part I, Title I, Chapter IX, numerals 3, 4 and 5; Decreto 368 de 2026, 7 April 2026 (Spanish text)
Meet the open finance API standards
What the text says
In open finance, entities must implement automatic information-exchange protocols over REST APIs with JSON, ISO 20022 for financial data fields, FAPI 2.0 security profiles, OAuth 2.0 authorisation (client credentials, authorisation code, PKCE or refresh token), access tokens in JWT signed with algorithms such as PS256 or stronger and the private_key_jwt authentication method, and TLS with mutual authentication using the specified cipher suites. Systems related to open finance must sit in a logically separate internal network, repositories must not be publicly exposed, and audit logs for each data request must be kept for five years, masked or encrypted according to criticality. Consent must be authorised, updated and revoked by the customer with strong authentication. Decreto 368 de 2026 made the system mandatory and requires the SFC to publish a schedule for the common standards.
What it means for your mobile app
If your bank shares or consumes consumer data, the API layer that carries it has its own authentication, authorisation and transport requirements, and the customer's consent has to be enforceable from the app.
How Ostorlab helps
Ostorlab tests the APIs behind login for broken authorisation (BOLA, BFLA, IDOR), token and session misuse, and abuse such as enumeration and replay, with request and response evidence. It does not implement FAPI, OAuth or certificates: it tests your implementation.
What stays with you
Implementing FAPI 2.0, OAuth 2.0 and mutual TLS, issuing certificates, participant registration, consent screens and the five-year audit log.
- Circular Básica Jurídica, Part I, Title IV, Chapter V, numerals 4.3 and 5; Circular Externa 033 de 2020, 17 November 2020 (Spanish text)
Report incidents with the TUIC and TLP
What the text says
Significant incidents that affect the confidentiality, integrity or availability of information must be reported to the SFC using the Single Taxonomy of Cyber Incidents (TUIC), and to the authorities of the national cyber incident model. All communications, incident reports, early warnings and bulletins related to information security and cybersecurity must be labelled with the Traffic Light Protocol (TLP). Entities must also establish incident response procedures, including disconnecting equipment, changing passwords, blocking IP addresses, recovering systems and preserving digital evidence.
What it means for your mobile app
The duty to report stays with the bank, under a defined taxonomy and labelling protocol, and incident response needs evidence about what happened in the app and the APIs.
How Ostorlab helps
Ostorlab does not monitor or report incidents. Its findings, replayable exploits and scan history help your team reconstruct what happened and show the state of the app before and after the incident.
What stays with you
The CSIRT, SOC monitoring, the TUIC and TLP submissions to the SFC and ColCERT, and preservation of digital evidence.
Summary of public SFC texts, checked on 27 September 2026. Circular Básica Jurídica items are summarised from the Spanish text of the consolidated CBJ re-issued by Circular Externa 006 de 2025. This page is not legal advice.
SFC rules, control by control
The controls the SFC 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 |
|---|---|---|
| Vulnerability assessment of the mobile and internet channelsCBJ 2.3.4.9.2, 2.3.4.11 | 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 |
| Twice-yearly testing and change-triggered retestCBJ 2.3.4.9.2 | Automated scans from CI/CD on every build and store release monitoring, so findings arrive between the scheduled tests. Details | Scan results per build and per store release |
| API authorisation, tokens and abuseCBJ P.I T.IV C.V 3.8; P.I T.I C.IX 3.2.3 | Intercepts traffic even with TLS pinning and tests authorization, token misuse and abuse such as enumeration and replay. Details | Request and response evidence for each API finding |
| Two-factor authentication on monetary and non-monetary operationsCBJ 2.3.4.11.1 | Logs in with one-time codes and tests MFA enforcement and step-up flows, and the API calls behind them. Details | Findings on login and step-up flows, with reproduction steps |
| Session cut-off and last-login noticeCBJ 2.3.4.9.4, 2.3.4.9.5 | Tests login and logout, token refresh, inactivity timeouts and session invalidation. Details | Session and token findings, with request and response logs |
| Keys and credentials in the app packageCBJ 2.3.3.1.6; P.I T.IV C.V 3.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 |
| Components, versions and fix deadlinesCBJ P.I T.IV C.V 4.2.2 | 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 |
| Security across the software lifecycleCBJ P.I T.IV C.V 3.8 | Mobile SAST on the binary and DAST on the running app, in CI/CD on every build. Details | Static and dynamic scan results per build |
| Runtime protections where data is not end-to-end encryptedCBJ 2.3.4.11.4 | Tests root and jailbreak detection, anti-tampering and pinning at runtime, and shows which protections held and which were bypassed. Details | A record of the protections tested and the bypasses observed |
| Incident reporting with the TUIC and TLPCBJ P.I T.IV C.V numeral 5; CE 033 de 2020 | Ostorlab does not report incidents: it keeps the app and API findings, exploits and scan history your team can use in the incident file. | Exportable findings and scan history for the incident report |
Ostorlab tests controls in the app and its APIs. Governance, the security unit, SOC monitoring, incident response and reporting with the TUIC and TLP, certificate and DNS monitoring, the twice-yearly test's logistics, and legal and contract work stay with your teams.
SFC controls to test in your mobile app
A practical list for security and system risk teams, based on the channels and cybersecurity chapters of the Circular Básica Jurídica.
Put the mobile app in the test plan
Add the app and its APIs to the internet-channel testing you already run twice a year, with a pre-release step for every release.
Two factors everywhere
Verify that monetary and non-monetary operations require the second factor on the server, including balance inquiries and profile changes.
Encryption and the 2 SMMLV threshold
Check which operations cross 2 SMMLV, confirm end-to-end encryption, and document the mitigations used below the threshold.
Sessions and last login
Test the inactivity cut-off, re-authentication and the last-login notice, including what happens when the app is backgrounded.
Secrets and keys
Check the app package for API keys, tokens and credentials, and rotate any that work. No shared, generic or group keys.
Components and deadlines
Keep a versioned list of the SDKs and native libraries in each release, and set fix deadlines by severity.
Open finance APIs
If you participate in open finance, test the consent flows and the API layer against the FAPI 2.0, OAuth 2.0 and mutual TLS standards, and keep the five-year audit log.
Report and retest
Report significant findings to the board, report incidents to the SFC with the TUIC and TLP, and keep retest results as evidence.
A suggested list, based on the Circular Básica Jurídica. 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, payments and open finance.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 and jailbreak 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.
- Circular Básica Jurídica (Circular Externa 006 de 2025), Part ISFC, re-issued 25 June 2025. Part I, Title II, Chapter I (channels, security and quality, including mobile banking 2.3.4.11 and internet 2.3.4.9), Title IV, Chapter V (minimum requirements for information security and cybersecurity) and Title I, Chapter IX (open finance). Spanish text
- Circular Externa 007 de 2018SFC, 5 June 2018. Adds the cybersecurity chapter to Title IV of Part I of the CBJ; applied six months after publication, with one-year and eighteen-month deadlines for some numerals. Spanish text
- Circular Externa 008 de 2018SFC, 5 June 2018. Amends the channels, security and quality subnumerals of Title II, Chapter I of Part I, including mobile banking; the amendments apply from 1 December 2018. Spanish text
- Circular Externa 033 de 2020SFC, 17 November 2020. Adds the Single Taxonomy of Cyber Incidents (TUIC), Formato 408 for security metrics and the Traffic Light Protocol (TLP); mandatory transmission tests in January 2021 and first official report with cut-off 31 March 2021. Spanish text
- Circular Externa 004 de 2024SFC, 7 February 2024. Instructs on open finance and the commercialisation of technology and infrastructure; adds the open finance chapter to the CBJ, with the FAPI 2.0, OAuth 2.0 and mutual TLS standards. Spanish text
- Circular Externa 001 de 2026SFC, 3 February 2026. Extends the transition regime for the open finance architecture, security and technology standards set by Circular Externa 009 de 2025. Spanish text
- Decreto 368 de 2026Ministry of Finance and Public Credit, 7 April 2026. Replaces the voluntary open finance framework with a mandatory system, and requires the SFC to publish the common standards and a work schedule, and to open the participants directory. Spanish text
- Ley 1581 de 2012Congress of Colombia, 17 October 2012. General regime for personal data protection: prior, express and informed authorisation, security duties of controllers, and rules on international transfers of personal data. Spanish text
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 SFC 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.