Open banking stopped being an innovation conversation and started being a regulatory one. In Peru, the SBS has been working the framework for several years; the central bank also plays a role in the payments system. The question for a financial institution is no longer “open banking yes or no?” but “what institutional stance do we take before they ask us?”
This article is not a technical guide. It’s what we expect the board of a credit union or bank to be able to answer when the inspection arrives or when a partner fintech knocks on the door.
The four questions the board should be able to answer
Regardless of the degree of regulatory progress at any given moment, there are four questions that are already reasonable today. If the board cannot answer in clear institutional terms, the institution is in a reactive position.
1. What’s our stance on API exposure?
Three legitimate options exist and all are defensible:
- Early enablers — we open up before being required, capture positioning, accept the cost of more expensive infrastructure.
- Compliers when the regulation requires it — we wait for the final framework, execute on time, don’t take a leader’s positioning.
- Minimum viable defensives — we expose only what’s strictly required, prioritize minimizing attack surface and operational load.
The three are valid postures. What’s not valid is not having chosen. “We haven’t discussed it” tells the regulator there’s no governance over the decision.
2. What data are we willing to share and under what conditions?
Open banking is not “sharing everything.” It’s an exercise in granularity: which client data, under what consent, with which third parties, for how long, under what auditability.
A well-governed institution has this explicit even before exposing the first API. The typical taxonomy:
- Basic client data — for which the law already defines consent.
- Transaction data — more sensitive, requires finer and revocable consent.
- Behavior and inference data — the most sensitive, normally not exposed.
Without this taxonomy, each API request becomes a new conversation. With it, decisions are taken on reasonable time.
3. How do we manage the risk of third parties consuming our APIs?
The naïve assumption is: “the regulation defines who can consume, we simply expose.” Reality is more complex: even if the regulator licenses third parties, the reputational risk of an incident at one of them touches the institution that exposed the API.
The concrete questions that should be answered:
- What kind of due diligence will we do on each third party before enabling them?
- What SLAs and contractual obligations will we require?
- Under what conditions do we revoke access?
- How do we monitor usage to detect anomalies?
This isn’t solved with a committee. It’s solved with written policy, board-approved.
4. What does an incident at a third party look like, and how do we respond?
The scenario: a fintech consuming your APIs suffers an incident and your data —technically, your clients’ data— is exposed.
Who declares the incident to the regulator, you or the third party? How do you notify your clients? How long do you have to cut off access? What happens to public trust when they see your credit union’s name associated with the incident, even if you didn’t fail?
A response plan for this scenario must exist and must have been simulated, not just drafted.
The technical comes after the institutional
It’s tempting to start with technology: “we buy an API gateway, implement OAuth 2.0 FAPI, set up consent management.” That conversation is legitimate but arrives late if the four questions above have no answer.
The reasonable order:
- Institutional stance — board, written, dated.
- Governance framework — who decides what, in what timeframe, with what evidence.
- Data taxonomy — what’s shared, under what consent.
- Technical architecture — API gateway, identities, consent, observability.
- Operations — third-party onboarding, monitoring, incident response.
Starting with technical architecture without the four prior steps is exactly the cause of open-banking projects that get stuck halfway at many institutions in the region.
What to do this quarter, regardless of the regulatory calendar
Even if the compliance date is next year or the year after, there are three things the board can do now:
- Convene a board session dedicated to the topic. One, with pre-read material. Leave with written institutional stance.
- Assign an executive owner. Not a committee, a person who reports quarterly to the board.
- Request a maturity assessment. Know where the institution is today vs. where it needs to be at the regulatory deadline. With prioritization and cost.
The institutions that arrive at the deadline with three quarters of accumulated work are the ones that execute in order. The ones that arrive with three months are the ones that improvise and inherit long-term technical debt.
At 2PSECURE we accompany boards of financial institutions in defining institutional stance toward open banking, and in the technical roadmap that derives from it. If your institution still doesn’t have a clear answer to the four questions above, let’s talk.
Found it useful? Share it: