A Look at Peru: Two Open Finance Paths at Once

An Ozone API & Finerio Connect Article

Peru is a market in the region where the final rulebook hasn’t been shared yet, and that’s precisely what makes it different. Ozone API and Finerio Connect track Chile, Colombia, and Peru as three distinct paths to the same destination, and Peru has only recently finished allowing market players to shape the technical standard before it locks. The outcome is yet to be seen.

But “still being designed” doesn’t mean “no deadlines.” Two separate regulatory clocks are running in parallel, with different scopes, different owners, and very different levels of urgency.

The Short Path: BaaS

Resolución SBS N°01747-2026 establishes the operational framework for Banking as a Service (BaaS) in Peru. Taking effect on 30 December 2026 (180 days post-publication), the regulation applies specifically to institutions choosing to participate in the BaaS segment rather than acting as a mandatory requirement for all banks. Consequently, market leaders are utilizing the second half of 2026 to build out their technical and compliance foundations, setting the stage for accelerated market adoption throughout 2027.

The resolution enables a specific set of use cases: savings, term, and CTS accounts, electronic-money accounts, credit granting, credit and debit cards, bank provided insurance products and embedded finance delivered through third parties. It requires board-approved policies, a prior risk assessment and ongoing monitoring of every third-party recipient, a per-service risk report to the Superintendencia de Banca, Seguros y AFP (SBS), contracts with seven minimum clauses, and a semi-annual published list of active recipients. It explicitly excludes correspondent agents and ATMs, payment aggregation and dispersion, and wallets that only tokenise credentials, all of which fall under other regimes.

The Longer Path: Open Finance

The Sistema de Finanzas Abiertas (SFA) is a different, larger undertaking, and it’s still in design. Guidelines went out for public consultation in July 2026, and contributions closed on 7th August 2026. Final regulation is expected by the end of 2026. First real data exchanges are projected for H1 2028.

The path here has been methodical: a diagnosis phase in February 2026 gathered nearly 70 survey responses and ran more than 60 bilateral meetings across 80 institutions. That fed a 2026 Open Finance Roadmap. The BaaS resolution came out of the same broader process in July 2026, alongside the SFA guidelines themselves.

The Four Waves of Implementation

There’s no official entity count yet. The working estimate is 94 to 128 entities, phased across four waves, with voluntary opt-in open from the very first wave for any entity that meets registration and technical requirements:

• Q1 2028: systemic multiple-operations companies subject to the capital-market concentration-risk buffer. In practice, the four largest banks, which handle roughly 80% of system operations.
• Q1 2029: remaining multiple-operations companies and electronic money issuers (EEDE): mid-size banks, financial institutions, municipal and rural savings banks, and credit companies.
• Q1 2030: insurance companies and private pension-fund administrators (AFP). This wave marks the shift from Open Banking to full Open Finance.
• Q2 2030: financial leasing, factoring, and Level-3 cooperatives (COOPAC), the segments the SBS’s own diagnosis flagged as having the largest capability gap.

Three Roles with One Reciprocity Principle

The SFA defines three roles: EPD (data provider), ERD (data recipient), and PSAC (account-aggregation provider, currently envisioned for supervised entities only). A reciprocity principle runs through all of it: any registered participant can hold both provider and recipient roles at the same time.

Two Gates to Operation

Registration in the SFA does not equal authorisation to operate. There are two separate gates.

• Gate one, registration, requires board or directorate approval, a new-product risk report under Circular G-165-2012, a registration format naming representatives, FAPI 2.0 certification, and an SFA compliance report whose content is still being defined.
  
• Gate two, technical enablement, requires technical registration in the SBS’s centralised directory, technical onboarding covering authorisation servers, metadata, and certificates, and technical certification through sandbox testing across compliance, interoperability, security, and UX.

FAPI 2.0 certification is typically the critical-path item across both gates, since it determines when an entity can even file its registration dossier. Peru is working on its own FAPI 2.0 Profile to provide all the required security to the ecosystem. 

The SBS runs the centralised directory, the technology sandbox, an automated compliance engine for pre-production verification, and a developer portal. What the SBS doesn’t build, the entity has to: the exposure platform itself, conforming to the Peru FAPI profile, the authorisation server, mTLS, data quality and traceability, the categorisation layer, and the consent journey.

The Data-Categorisation Trap

The Peruvian Open Finance System (SFA) is structured around a gradual implementation strategy. Rather than mandating the exposure of all financial data at once, the Superintendency of Banking, Insurance, and AFP (SBS) has established a phased rollout that initiates the ecosystem with two primary groups of data.

International experience has proven that launching multiple, complex data groups simultaneously creates significant technical and operational bottlenecks. By splitting the initial rollout into two distinct data groups, the SBS aims to mitigate systemic risks, incorporate early operational learnings, preserve system stability, and provide financial entities the necessary time to build robust technological capabilities (such as secure APIs and consent management systems). This phased approach is a recognized best practice to ensure a smooth transition toward a fully operational ecosystem.

The selection of these initial groups is directly driven by the market’s prioritized use cases, specifically focusing on improving alternative credit evaluation and enabling personal and business financial management (PFM/BFM). Drawing on the regulatory guidelines established by the SBS (as discussed in our previous conversations), the two phased groups are structured as follows:

• Group 1 (Targeted for late 2027): This group focuses on transactional data from savings accounts and electronic money. It provides the foundational data needed for basic cash-flow analysis. For instance, accessing at least three months of transactional history from these accounts is critical to enabling microcredit scoring and basic treasury management tools.
• Group 2 (Targeted for mid-2028): This group introduces credit card data. It provides the complementary liabilities data required for comprehensive credit capacity evaluations (which often require longer historical horizons, such as for mortgages) and complete financial visualization

Here’s the detail that catches teams late in a project: the regulator wants already-classified, categorised transactions, not raw extracts. Most core banking systems don’t output data in that form natively. Building the categorisation layer is a real engineering task, not a formatting step, and it needs to be planned for from day one.

History requirements start at 6 months of transaction data from H1 2028, extending to 12 months from H2 2028.

Consent as a Three-Step Journey

Consent runs through three distinct steps, each its own product surface rather than a backend flow: entry into the ERD, where the user identifies purpose, selects data, and sets an expiry; authentication and confirmation at the EPD; and a return to the ERD to execute the now-authorised exchange. Ambiguous contract terms, pre-marked boxes, presumed consent, and friction patterns designed to induce abandonment are all explicitly prohibited. The ERD must offer at least check, revoke, renew, and modify. The EPD must offer at least consult and revoke.

Monetisation is contemplated in the draft guidelines, backed by a technical and economic report, but isn’t yet in force, unlike Colombia’s already-live cost-recovery scheme.

What a First-Wave Project Actually Looks Like

For an entity in the first wave, the practical timeline runs 12 to 18 months: 2026-2 for deciding build versus buy, responding to the consultation, and setting the 2027 budget; 2027-1 for platform selection and starting the FAPI 2.0 certification path alongside a data-quality diagnosis; 2027-2 for building the consent journey, the categorisation layer, and sandbox testing; and 2028 for technical authorisation, directory inclusion, and first exchanges.

How Ozone API and Finerio Connect Can Help

Ozone API and Finerio Connect are supporting institutions across Peru to implement open finance. Ozone API supplies the standards-compliant, FAPI-certified platform, built by the original architects of the UK Open Banking standard, giving an entity a head start on the FAPI 2.0 certification that sits on the critical path for both SFA gates. Finerio Connect brings the operational experience of live deployments in several markets, such as Colombia, Chile, and Guatemala, three markets that had to solve the same categorisation and consent-journey problems Peru is now designing for, and applies that experience to a market still writing its own rules. Together they help an entity run the BaaS clock and the SFA clock at once: meeting the 30 December 2026 hard deadline while building the categorisation layer and FAPI certification path the first wave needs by 2028, inside the 12 to 18 month window a first mover actually has.

Speak to the team today to start moving.