Open banking readiness for product teams

Open banking promised a simple story: one API, every bank, instant account access and payment initiation. The reality that product teams encounter after their first few bank integrations is considerably messier — every Account Servicing Payment Service Provider (ASPSP) implements the underlying standards slightly differently, consent flows vary in ways that affect conversion, and failure modes multiply the moment you move beyond a handful of well-behaved banks.

Consent is not a one-off OAuth divert

Many open banking implementations treat consent as a single redirect at the start of a session: send the user to their bank, get a token back, done. In practice, consent has a full lifecycle. Users need clear visibility into what has been shared, an easy way to revoke access, and a re-authentication flow that does not feel like starting over when a consent naturally expires after the regulatory maximum period.

Products that treat consent expiry as an edge case discover it is actually a routine, recurring event that needs first-class UX — not an error state that dumps users back to a generic login screen with no explanation of why they are being asked again.

AIS data quality is a product feature, not a pass-through

Account Information Services (AIS) payloads vary wildly by ASPSP: transaction categorisation differs, merchant name formatting differs, balance types (available versus cleared) are represented inconsistently, and some banks omit fields that others treat as mandatory. Passing this data through unmodified to end users produces a visibly inconsistent, unpolished experience.

Normalisation — mapping every ASPSP's quirks into a single consistent internal data model — is genuine product work, not a footnote in the integration. Teams that budget for this properly ship a noticeably better experience than teams that treat AIS as "just an API call".

PIS failure modes deserve equal design attention

Payment Initiation Services (PIS) introduce a different category of complexity: partial failures where a payment is initiated but its final status is unknown for an extended period, delayed settlements that vary by bank and rail, and bank-specific quirks in how authorisation and confirmation steps are sequenced.

Status communication matters as much as the API call

A payment initiation API call that returns "pending" is not the end of the engineering work — it is the start of a status-tracking obligation. Webhooks, polling fallbacks, and clear customer-facing messaging about what "pending" actually means and how long it might last are just as important as the initiation call itself. Customers who do not know whether their payment succeeded will contact support, and support teams without visibility into bank-side status cannot resolve the query.

A pragmatic rollout strategy

Start with a narrow corridor of well-understood, well-behaved banks. Measure consent completion rates, AIS data quality, and PIS success rates for that corridor before expanding. This is the opposite instinct to "connect everything on week one" that many roadmaps default to, but it consistently produces a more reliable product, because problems surface with a small, manageable set of integrations rather than across dozens simultaneously.

An open banking readiness checklist

• Design consent UX for the full lifecycle: grant, view, revoke, and graceful re-authentication.
• Build a normalisation layer for AIS data rather than passing ASPSP payloads through directly.
• Track PIS success rates, partial-failure rates and settlement delay by bank, not just in aggregate.
• Invest in clear customer messaging for pending and delayed payment states.
• Roll out bank coverage in measured corridors, expanding only once success metrics are healthy.

Open banking coverage is a curve you climb deliberately, not a switch you flip on launch day.

Working with aggregators versus direct ASPSP connections

Many teams choose an open banking aggregator specifically to avoid building and maintaining dozens of direct ASPSP connections themselves, trading some margin and a degree of control for significantly reduced integration and maintenance burden. This is often the right choice for early-stage products, but it is worth understanding exactly which normalisation, consent handling and status tracking responsibilities the aggregator actually takes on versus which remain yours to build.

Aggregator documentation sometimes implies more normalisation than is actually delivered in practice, so it is worth testing with real sandbox accounts across a representative sample of banks before committing fully, rather than assuming uniform behaviour across every ASPSP in the aggregator's advertised coverage.

Whichever path you choose, keep the option to renegotiate open by avoiding deep, aggregator-specific assumptions in your own data model. A normalisation schema designed around your own product's needs, rather than mirrored exactly from one aggregator's response format, transfers far more easily if you later add a second aggregator or move toward direct ASPSP connections for your highest-volume corridors.

Key takeaways

• Consent needs a full lifecycle design, including graceful re-authentication after expiry.
• AIS normalisation across ASPSPs is genuine product work that directly affects perceived quality.
• PIS partial failures and delayed settlements need explicit status tracking and customer messaging.
• Expand bank coverage corridor by corridor, measuring success rates before scaling further.
• Treat open banking readiness as an ongoing operational discipline, not a one-time integration.