How should banks and FinTechs respond when open banking gives new entrants direct access to customer data and payment initiation?

Banks and FinTechs should treat open banking as a distribution and control shift, not just a compliance change. The practical response is to redesign consent, authentication, and API governance around customer choice, while deciding which capabilities to expose, partner on, or defend internally. Organisations that ignore the shift risk losing customer touchpoints to third parties that can own the experience and the relationship.

How open banking changes the operating model for banks and FinTechs

Open banking changes who can initiate access, who owns the customer interface, and how value is captured across the payment journey. The important shift is that consent becomes a product and governance issue, not just a legal checkbox. Banks and FinTechs need to decide whether they are the account holder, the platform, the initiator, or the orchestrator, because each role carries different control obligations.

This matters because the control perimeter moves from a closed channel model to an ecosystem model. That means API exposure, consent handling, customer authentication, and third-party oversight all become part of the business design, not after-the-fact technical controls.

For banks, the practical question is which capabilities to expose safely without surrendering trust. For FinTechs, the challenge is how to build customer-facing services on top of bank APIs without creating brittle dependencies on partner uptime, permissions, or data quality.

What banks should redesign first

The first redesign point is consent and customer journey ownership. In open banking, a customer can authorize a third party to read data or initiate payments, so the bank must make consent understandable, revocable, and auditable across channels. That is where a bank either preserves trust or turns the API into a commodity interface.

Authentication also changes shape. The bank still needs strong customer authentication, but the user experience must support repeated authorization without creating fatigue, fraud openings, or unnecessary abandonment. The point is not to make access harder at every step, but to make each high-risk action explicit and attributable.

API governance is equally important. Banks need to define which endpoints are exposed, how scopes are limited, how partner behaviour is monitored, and what gets throttled or blocked when usage patterns drift from expected customer intent. If the API layer is treated as a simple integration layer, the bank loses control over business flows that now depend on that interface.

How FinTechs should compete without becoming dependent

FinTechs should treat open banking as a distribution and trust strategy. The winning position is usually not “we own the bank data”, but “we deliver the best experience on top of permissioned access”. That requires clear customer value, strong consent framing, and disciplined dependency management with upstream institutions.

They also need to design for partner variability. A payment initiation feature is only as good as the bank connection, the authentication flow, and the error handling when consent expires or an API changes. This means product teams should plan for degraded modes, retries, and user messaging that explains failures without making the service look broken.

FinTechs that rely on open banking should also think carefully about data minimisation and scope control. Requesting broader access than the use case needs creates friction and may reduce authorisation success. Better practice is to ask for the narrowest permission that supports the customer outcome, then build around that constraint.

How to preserve trust when the customer relationship becomes shared

The hardest strategic issue is not technical connectivity, it is customer relationship ownership. Open banking lets a third party sit between the bank and the customer, so the bank must decide whether to compete on experience, specialize in infrastructure, or partner selectively where the economics justify it. FinTechs face the inverse problem: they may own the interface while depending on banks for the actual account relationship.

The best response is to make governance visible to the customer and measurable internally. Consent records, authentication events, API errors, and payment initiation outcomes should all be treated as operating signals, because they show whether the model is building trust or leaking it. A poor consent journey or opaque failure handling will usually show up first as drop-off, complaint volume, or partner escalation.

RFC 6749: The OAuth 2.0 Authorization Framework is useful when teams need a precise model for delegated access, while OpenID Connect Core 1.0 helps separate authentication from authorization in customer journeys.

Risk and Threat Considerations

Open banking expands the number of parties that can touch customer data and payment initiation, which increases the blast radius of weak consent, overbroad scopes, and poorly governed API integrations. The main risk is not only data exposure, but also unauthorised or mistaken payment initiation through a trusted access path.

Failure mechanism: A third party, integration, or compromised credential can abuse a legitimate access path when scopes are too broad, tokens are reused, or customer intent is not tightly bound to the transaction.

Impact: Customer data can be exposed, payment requests can be initiated without the intended level of control, and both banks and FinTechs can lose trust, face fraud losses, or create regulatory exposure.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP API Security Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
OWASP API Security Top 10	API8 — Security Misconfiguration	Open banking exposes API-driven data and payment surfaces that fail when config is too permissive.
Recommendation — Harden exposed APIs and restrict scopes, endpoints, and partner access paths to the minimum needed.
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	Open banking depends on limiting what third parties and apps can access or initiate.
	IA-2 — Identification and Authentication (Organizational Users)	Customer and staff authentication remains central when authorizing sensitive account actions.
Recommendation — Enforce least privilege for partner access, tokens, and payment initiation permissions. Strengthen authentication for high-risk banking actions and session reauthentication.
NIST CSF 2.0	PR.AA-05 — Identity Management, Authentication, and Access Control	Open banking requires controlled access to customer data and initiation functions across parties.
Recommendation — Map access rules to consented data and payment rights, then monitor and revoke them quickly.
ISO/IEC 27001:2022	A.5.15 — Access control	Open banking requires explicit control over who can access customer data and initiate payments.
Recommendation — Define and enforce access rules for APIs, partners, and customer-authorized actions.

Practitioner Guidance

What to prioritise: Start with consent design, scope restriction, and customer authentication flows before launching new partner features. If those three controls are weak, the commercial upside of open banking can be erased by friction, abandonment, or misuse.

What to verify: Confirm that every consent event is auditable, revocable, and mapped to a specific data set or payment action. Also verify that partner APIs cannot quietly expand access beyond the original customer permission.

Practitioner takeaway: The banks and FinTechs that win in open banking are the ones that treat delegated access as a governed product surface, not just a technical integration.