Open banking APIs: consent, data sharing, and the account aggregator pattern

Three ways to see it

1. 1

   Open banking is a regulatory pattern in which a bank is required to expose customer data through standardised APIs, with the customer's consent, to other licensed parties. The bank does not own the customer's data; the customer does. The bank holds it. Open banking turns that distinction from a polite philosophy into a daily operational reality. In Pakistan, the framework has been moving forward since SBP's 2023 consultation paper on Open Banking, with formal API specifications and a sandbox window opened in 2025.

2. 2

   Three actor roles structure every open banking ecosystem. The Account Servicing Payment Service Provider (ASPSP) is the bank holding the customer's account; it must build and operate the APIs. The Account Information Service Provider (AISP) reads data from the bank with consent, useful for budgeting apps, lending decisions, and accountancy tools. The Payment Initiation Service Provider (PISP) instructs payments out of the customer's account directly, bypassing the card networks. Most Pakistani fintechs will start as AISPs because reading is simpler than initiating money movement.

3. 3

   The consent flow is the heart of the design. The customer starts in your app, taps 'Connect HBL', and is redirected to HBL's hosted authentication page. The customer logs in to HBL with their existing credentials, sees a screen describing exactly what your app is asking for (account list, 90-day transactions, balance), picks an expiry (30 days, 90 days, one year), and approves or denies. Your app never sees the customer's HBL password. The bank issues an OAuth-style access token, scoped to the consent the customer just gave, and your app uses that token to make API calls.

The why-tree

Try this with Claude

AI-edge prompt: 'I am a product lead at a Pakistani fintech preparing an open banking AISP application for the SBP sandbox. Draft a one-page consent screen, an OAuth scope list, a 12-month roadmap, and a list of the five technical risks I will get questioned on. Then play the role of an SBP review officer and grill me on the weakest part of the proposal.' Save the SBP critique; rewrite your proposal until you can survive it.