Peru's SBS cybersecurity rules: test your mobile banking app before and after every release.
Resolution SBS 504-2021 approved the Reglamento para la Gestión de la Seguridad de la Información y la Ciberseguridad, an information and cybersecurity management system for entities supervised by the SBS. It requires periodic testing, strong authentication with two independent factors for payments and transfers, transaction monitoring and specific security measures for APIs. The card regulation adds two authentication factors for card operations, and Law 29733 and its 2024 regulation set security measures for mobile apps that process personal data. 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 and step-up checks with your test accounts, including the calls behind transfers and payee changes
- 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
- Banks, finance companies, CMACs, AFP and other entities supervised by the SBS; the card regulation binds card issuers, and Law 29733 applies to anyone processing personal data in Peru
- Key date
- The SGSI-C regulation is in force since 1 July 2021, with the authentication subchapter applicable from 1 July 2022; the card two-factor deadlines ran through 2025 and 2026
- Focus
- Periodic testing, strong authentication for digital operations, API security and personal data protection
- Main reference
- Resolución SBS N° 504-2021, Reglamento para la Gestión de la Seguridad de la Información y la Ciberseguridad
The SBS texts behind your mobile channel
The cybersecurity regulation, the card rules and the personal data framework apply to the same app and its APIs. The dates below are for the texts cited on this page.
- 1 July 2021
Cybersecurity regulation
Resolución SBS N° 504-2021, dated 19 February 2021, applies the Reglamento para la Gestión de la Seguridad de la Información y la Ciberseguridad. The subchapter on authentication for digital channels had an adequacy deadline of 1 July 2022.
- October and November 2023
Authentication amendments
Resolución SBS N° 3240-2023 of 3 October 2023 and Resolución SBS N° 03797-2023 of 17 November 2023 adjust the exemptions from strong authentication and the rules on enrolment and one-time codes for digital operations.
- 28 June 2024
Card operations, two factors
Resolución SBS N° 2286-2024 amends the card regulation: two authentication factors for card-present and card-not-present operations, EMV 3DS and tokenisation for wallets, and company responsibility for unrecognised operations processed without a second factor.
- 30 November 2024
New data protection regulation
Decreto Supremo N° 016-2024-JUS approves the new regulation of Law 29733, in force 120 calendar days later, in March 2025. It adds security measures for mobile apps and digital platforms, a security document, a data protection officer and a 48-hour breach notification.
- 10 March 2025
Digital channel resilience
Resolución SBS N° 814-2025 amends the Reglamento para la Gestión de la Continuidad del Negocio, approved by Resolución SBS N° 877-2020. It adds recovery times for mobile and internet channels, annual continuity tests, a registry of interruptions and deadlines to report them to the SBS, in force in stages from 1 June 2025 and 1 January 2026.
- 19 September 2025
Card monitoring rules
Resolución SBS N° 3289-2025 rewrites Article 17 of the card regulation: monitoring systems must be separate from the authentication process, with alert procedures, fraud patterns and limits per channel.
- 1 June 2026
Old credit cards, last deadline
Resolución SBS N° 771-2026 of 13 March 2026 extends to 1 June 2026 the double factor for credit cards issued before 1 July 2025, after the first extension to 1 April 2026 by Resolución SBS N° 2220-2025.
The SBS 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 texts are in Spanish and are summarised here.
- Reglamento para la Gestión de la Seguridad de la Información y la Ciberseguridad, Art. 13(b) and 21.1(a), (f) and (j) (Spanish text)
Test the security management system and your app regularly
What the text says
Keep planned activities that include periodic evaluations, reviews and tests of the information security and cybersecurity management system, by internal and external services, according to the complexity of the entity and the threats to its information assets. For APIs used to provide services, run risk analysis, vulnerability analysis and penetration tests, and monitor their security events. Use international standards and frameworks as a reference.
What it means for your mobile app
The regulation expects testing, not only policies. The tests have to cover the systems behind the app, and the APIs the app uses count as systems that need vulnerability analysis and penetration testing.
How Ostorlab helps
An AI-agent pentest tests the app and its APIs behind login, on the build you ship, with a working exploit you can replay for each AI-agent finding. Mobile SAST and Mobile DAST run in CI/CD, and findings are tracked as tickets with retests after the fix.
What stays with you
Setting the frequency and scope of the tests, choosing external providers, and any testing your institution runs beyond the app and its APIs.
- Reglamento para la Gestión de la Seguridad de la Información y la Ciberseguridad, Art. 12.5(b), (c), (d), (e) and (f) (Spanish text)
Build security in and test before production
What the text says
Include information security practices in the planning, development, implementation, operation, support and decommissioning of applications and systems. Keep strict control over changes to source code libraries, review and test critical applications when the operating platform changes, and carry out technical, functional and information security tests before systems go into production. Implement and verify secure development procedures.
What it means for your mobile app
Every app release is a change to a customer-facing system. Security testing before production, on the binary and on the running app, is part of the minimum measures.
How Ostorlab helps
Ostorlab runs automated scans from your CI/CD pipeline on every build and monitors store releases without manual triggers. Mobile SAST works on the APK, AAB or IPA, with no source code needed, and Mobile DAST runs the app.
What stays with you
Secure coding standards, change control, manual review and release approval.
- Reglamento para la Gestión de la Seguridad de la Información y la Ciberseguridad, Art. 21.1 and 21.3 (Spanish text)
Secure the APIs you use to provide services
What the text says
Companies that use APIs to provide services through third parties must implement risk analysis and mitigation, mutual authentication of systems and authentication of users, authorisation of operations by users, encryption of data in storage and in transmission, secure API development practices and secure coding review, vulnerability analysis and penetration testing, security of the supporting infrastructure, fault tolerance and contingency mechanisms, access control, and monitoring of security events. The technical specifications of the APIs must be documented for audit.
What it means for your mobile app
Authorisation has to hold at the API layer, for every call, whatever the app sends. Documented specifications and tested authorisation are both named requirements.
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
API design and documentation, gateway configuration, infrastructure security and contingency engineering.
- Reglamento para la Gestión de la Seguridad de la Información y la Ciberseguridad, Art. 18 (Spanish text)
Enrol users with two independent factors
What the text says
Enrolment of a user in a digital channel requires verifying the user's identity and taking measures to reduce the possibility of impersonation, which includes two biometric factors, or two factors from different and independent categories. Credentials generated for users must be managed across their lifecycle: activation, suspension, replacement, renewal and revocation, ensuring their confidentiality and integrity where applicable.
What it means for your mobile app
Remote onboarding and re-enrolment are high-value flows. The identity check and the credential lifecycle both involve the app and the backend calls behind it.
How Ostorlab helps
Authenticated testing covers onboarding and login flows with your test accounts and tests the API calls behind them, including attempts to skip a step or replay an identity check. Secrets scanning checks what credentials and keys the app package exposes.
What stays with you
The identity verification process itself, including any identity registry checks, and the credential policy.
- Reglamento para la Gestión de la Seguridad de la Información y la Ciberseguridad, Art. 19 (Spanish text)
Use strong authentication for payments and transfers
What the text says
Strong authentication is required for actions that may lead to fraudulent operations or other abuse: payments or transfers to third parties, registration of a trusted beneficiary, changes to savings or investment insurance products, contracting a product or service, and changes to limits and conditions. It means a combination of authentication factors from at least two different, independent categories, a control against man-in-the-middle attacks, including a unique code generated cryptographically from the specific data of each operation and used only once, and a notification to the user when the operation succeeds.
What it means for your mobile app
The second factor and the per-operation code have to be enforced by the server on every listed action, including when the app or an attacker skips a step.
How Ostorlab helps
Authenticated testing completes SMS, email or TOTP one-time codes with your test accounts and tests MFA enforcement and step-up flows, including how attackers try to manipulate them, together with the API calls behind transfers, payee changes and limit changes.
What stays with you
Choosing authentication methods and the operations that need them, and sending the success notifications.
- Reglamento para la Gestión de la Seguridad de la Información y la Ciberseguridad, Art. 20, as amended in 2023 and by Resolución SBS N° 2286-2024 (Spanish text)
Meet the exemptions, and their conditions, carefully
What the text says
Trusted recipients previously registered by the user, and transfers between accounts held by the same customer in the same company, are exempt from strong authentication, except for the notification. Payments with a low fraud risk from an online risk analysis are exempt only if the company uses industry standards such as EMV 3DS and EMV payment tokenisation in their latest versions, defines a threshold amount, measures the fraud ratio per operation type, and updates the risk rules. Operations executed under that exemption, or after the user reported stolen credentials, are the company's responsibility.
What it means for your mobile app
Exemptions are business logic in the app and its APIs. If a flow can be manipulated to look like a trusted-beneficiary or low-risk payment, the loss sits with the bank.
How Ostorlab helps
Ostorlab tests the business logic of payment and beneficiary flows and the API calls behind them, including attempts to manipulate amounts, thresholds and flags, and to replay approvals.
What stays with you
The risk analysis rules, threshold amounts, fraud ratio measurement and the responsibility decisions.
- Reglamento para la Gestión de la Seguridad de la Información y la Ciberseguridad, Art. 17 (Spanish text)
Set the authentication baseline and monitor transactions
What the text says
Authentication processes for digital channels must define the factors required, current cryptographic standards, the deadlines and conditions for re-authentication, including inactivity and long sessions, a baseline of controls against threats that includes a limit on failed authentication attempts and the prevention of message interception and manipulation, and rules for retaining audit logs. Re-evaluate the processes when the technology loses vendor support or new vulnerabilities appear, keep detailed records of enrolments and authentication events, and maintain tools to monitor transactions for known fraud scenarios and compromised authentication elements.
What it means for your mobile app
Attempt limits, inactivity time-outs, log retention and interception protection are concrete behaviours of the app and its backend, and they can be tested.
How Ostorlab helps
Ostorlab tests login and logout, token refresh, timeouts, session invalidation, failed-attempt lockout and MFA enforcement, and analyses how credentials and messages travel between the app and the backend.
What stays with you
Defining the log retention rules, running transaction monitoring, and the security operations around it.
- Reglamento de Tarjetas de Crédito y Débito, Art. 16.7 and Art. 23.10, added by Resolución SBS N° 2286-2024; deadlines extended by Resolución SBS N° 771-2026 (Spanish text)
Meet the two-factor rule for card operations
What the text says
Authentication for card operations follows the cybersecurity regulation with EMVCo technical standards: card-present operations need the chip or its digital representation plus a password (PIN) or another factor; card-not-present operations need the card data plus a dynamic verification code or another factor verified online under EMV 3DS, except where the exemptions apply; third-party mobile wallets based on card tokenisation need the token plus a second factor of a different nature. EMV 3DS and EMV Tokenization satisfy the man-in-the-middle control for those cases. The company is responsible for losses from operations processed without a second factor. The last deadline, for the double factor on credit cards issued before 1 July 2025, was extended to 1 June 2026.
What it means for your mobile app
Card-not-present payments often start inside the banking app. The second factor, the tokenisation and the accept or reject rules when a factor is missing are all part of the app and its APIs.
How Ostorlab helps
Ostorlab tests card and payment flows in the app behind login, the calls to the issuer and 3DS services, and how a missing or failed second factor is handled, with request and response evidence.
What stays with you
EMV and 3DS certification with your processor, the acceptance rules, and the card renewal programme.
- Reglamento para la Gestión de la Continuidad del Negocio, Arts. 18 and 19, added by Resolución SBS N° 814-2025 (Spanish text)
Keep the mobile channel resilient
What the text says
The business continuity regulation, as amended in 2025, requires companies with digital channels to identify the prioritized products and services offered through them and set recovery time objectives, manage the risks of the technological components behind them, monitor the channels against their normal conditions, provide alternative channels, test the continuity strategies annually, and keep a centralized registry of interruptions longer than 30 minutes. Transfers, interoperable payments, payroll and supplier payments through the mobile app cannot be interrupted for more than five hours between 6:00 and 22:00, or three hours for companies with market concentration. Interruption events must be reported to the SBS within a few hours.
What it means for your mobile app
Resilience is about uptime, but security failures are one of its causes. The app, its APIs and their dependencies are named components of the mobile channel.
How Ostorlab helps
Ostorlab tests the app and APIs before release and retests fixes, so known exploitable issues do not become outages. It does not run monitoring, alternative channels or continuity exercises.
What stays with you
Channel monitoring, the alternative channels, the continuity tests, the interruption registry and the reports to the SBS.
- Ley N° 29733, Art. 16; Decreto Supremo N° 016-2024-JUS, Arts. 34, 46 and 47 (Spanish text)
Protect personal data and notify breaches within 48 hours
What the text says
Personal data must be processed with the technical, organizational and legal measures needed to guarantee its security and avoid alteration, loss, unauthorized processing or access. The 2024 regulation spells out what that means for platforms and mobile apps: documented access control with procedures for identification and authentication, privilege reviews at least every six months, periodic monitoring of the measures and staff training, interaction logs with a minimum retention of two years, and controls against unauthorized copies of digital documents. A security document and an inventory of personal data and systems are mandatory. Security incidents that affect large volumes of data or sensitive data must be notified to the national data protection authority within 48 hours, and to the affected data subjects within 48 hours; digital incidents also go to the National Centre for Digital Security.
Source:Ley N° 29733, Art. 16; Decreto Supremo N° 016-2024-JUS, Arts. 34, 46 and 47 (Spanish text)
What it means for your mobile app
The app on the phone and the backend behind it both process personal data. Access control, logs, retention and breach notice times all apply to the mobile channel.
How Ostorlab helps
Ostorlab looks for tokens and personal data in local storage, caches, logs and screenshots, checks transport protections, and finds credentials and keys that should not ship inside the app.
What stays with you
The security document, the data inventory, the data protection officer, log retention systems and the breach notifications.
Summary of public SBS texts and of Peru's personal data framework, checked on 27 September 2026. All texts are in Spanish and are summarised here. This page is not legal advice.
The SBS rules, control by control
The controls the SBS texts and Peru's data protection framework 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 |
|---|---|---|
| Periodic testing of the management system504-2021 Art. 13(b), 21.1(f) | 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 |
| Secure development and testing before production504-2021 Art. 12.5 | Mobile SAST and DAST in CI/CD on every build, and monitoring of store releases. Details | Scan results per build and per store release |
| Software and component inventory504-2021 Art. 12.9, 22 | Lists the SDKs and native libraries in each release with their versions, and maps vulnerable ones to known vulnerabilities. Details | Component identity, version and location in the app bundle, per release |
| Credentials and keys inside the app504-2021 Art. 12.2(c), 18.2 | 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 |
| Security measures for APIs504-2021 Art. 21 | 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 |
| Strong authentication, exemptions included504-2021 Art. 19, 20 | Logs in with one-time codes and tests MFA enforcement and step-up flows, and the API calls behind them. Details | Findings on transfers, payee changes and limit changes, with reproduction steps |
| Attempt limits, sessions and interception504-2021 Art. 17 | Tests failed-attempt limits, token refresh, inactivity timeouts and session invalidation. Details | Session and token findings, with request and response logs |
| Two factors for card operationsCards reg. Art. 16.7, 23.10 | Tests card and wallet flows in the app and the calls to the issuer and 3DS services. Details | Flow evidence for missing or failed second factors, with request and response logs |
| Personal data on the device and in transitLey 29733 Art. 16; DS 016-2024-JUS Art. 46 | 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 |
| Digital channel resilienceContinuity reg. Art. 18, 19; 814-2025 | Ostorlab tests the app and its APIs before release and retests fixes; it does not run monitoring or continuity exercises. | Test and retest results per release, kept as part of your channel evidence |
Ostorlab tests controls in the app and its APIs. SOC monitoring, transaction and fraud monitoring, incident notification to the SBS and the ANPD, continuity and recovery engineering, alternative channels and board reporting stay with your teams.
SBS controls to test in your mobile app
A practical list for security and technology risk teams, based on the SGSI-C regulation, the card rules and Peru's data protection framework.
Testing cadence
Put the mobile app and its APIs in the planned tests of the SGSI-C, with internal or external providers according to your risk.
Before every release
Run automated SAST and DAST on every build and scan each store release, not only the version you tested last quarter.
APIs
Check mutual authentication, user authorization, encryption and access control on every API the app calls, and keep the specifications auditable.
Strong authentication
Verify that transfers, payments, trusted beneficiaries and limit changes require two independent factors and a per-operation code, enforced by the server.
Exemptions
Test the trusted-beneficiary and low-risk exemptions, the thresholds behind them, and confirm that operations without a second factor are treated as the company's responsibility.
Sessions and attempts
Test failed-attempt limits, inactivity re-authentication, log retention and protections against message interception and replay.
Cards
Check the two factors for card-present and card-not-present operations, the dynamic verification code, tokenized wallets and the monitoring rules, and track the renewal deadlines.
Personal data and reporting
Look for personal data in storage and logs, keep the security document and two-year logs, and rehearse the 48-hour breach notification to the authority and to customers.
A suggested list, not an SBS 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, including the calls behind transfers and payee changes.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 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.
- Resolución SBS N° 504-2021: Reglamento para la Gestión de la Seguridad de la Información y la CiberseguridadSBS, dated 19 February 2021, in force from 1 July 2021, with the authentication subchapter applicable from 1 July 2022. Amended by Resoluciones SBS N° 1515-2021, 3240-2023, 03797-2023 and 2286-2024. The Spanish text is the original
- Resolución SBS N° 6523-2013: Reglamento de Tarjetas de Crédito y DébitoSBS, 30 October 2013. General rules for credit and debit cards, including security measures for users, monitoring and liability for unrecognised operations (Arts. 16 to 18 and 23). Consolidated Spanish text
- Resolución SBS N° 2286-2024SBS, dated 26 June 2024, published on 28 June 2024. Adds two authentication factors for card operations, EMV 3DS and tokenisation controls and liability for losses without a second factor, with implementation deadlines in 2024, 2025 and 2026
- Resolución SBS N° 3289-2025SBS, dated 17 September 2025 and published on 19 September 2025. Rewrites Article 17 of the card regulation: monitoring systems distinct from authentication, alert management, fraud patterns and limits per channel. Described by the Diario Oficial El Peruano
- Resolución SBS N° 771-2026SBS, 13 March 2026, published in El Peruano on 18 March 2026. Extends to 1 June 2026 the double factor for credit cards issued before 1 July 2025, the second extension after Resolución SBS N° 2220-2025
- Reglamento para la Gestión de la Continuidad del Negocio (Resolución SBS N° 877-2020) as amended by Resolución SBS N° 814-2025SBS. Resolución 877-2020 approved the regulation; Resolución 814-2025, published 10 March 2025, adds operational resilience for digital channels: recovery time objectives, annual tests, an interruption registry and reporting, in force in stages
- Ley N° 29733, Ley de Protección de Datos PersonalesPublished on 3 July 2011. Articles 9 and 16 set the security principle and the duty to adopt technical, organizational and legal measures to protect personal data. Spanish text
- Decreto Supremo N° 016-2024-JUS: Reglamento de la Ley N° 29733Published on 30 November 2024, in force 120 calendar days later. Article 46 covers security for personal data processed through mobile apps, Article 47 requires a security document, and Article 34 requires a 48-hour notification of security incidents. 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.
Test your mobile banking app against the SBS rules
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.