Open Banking Regulations Pakistan: How SBP’s Draft 2026 Rules Turn Raast Consent Into Code

Key Takeaway

• The open banking regulations Pakistan published in draft form in late October 2026 would require banks, microfinance banks and electronic money institutions to share customer-approved data and payment access with authorised third parties through standardised APIs.
• Raast is proposed as the central hub for consent, routing and audit, which means consent stops being a signed disclosure and becomes a machine-readable object that systems enforce.
• Screen scraping and credential sharing end because API access replaces them, removing the practice of handing bank passwords to apps.
• The draft is open for public consultation and is not yet binding; liability allocation and compliance cost remain unresolved.

Introduction

The open banking regulations Pakistan has been waiting for arrived in draft form in late October 2026, when the State Bank of Pakistan released its proposed Open Banking Regulations 2026 for public consultation. The draft matters less for what it permits than for where it puts enforcement: consent moves out of a disclosure document and into a structured record that systems read before releasing a single field. Consequently, privacy outcomes under this framework will be decided by API design and consent schema choices rather than by the wording of a terms-of-service page — the same shift visible across AI governance and data standards, where compliance is increasingly specified in code rather than in policy prose. The draft applies to banks, microfinance banks and electronic money institutions as data holders. This article covers the scope, the Raast request flow, how consent-as-code works, why credential sharing ends, how Pakistan compares with three mature regimes, the unresolved risks, what each stakeholder must do, and how to file feedback.

About this analysis: Written by The Verge PK’s digital policy desk, which covers fintech regulation, telecom rules and digital payments for readers in Pakistan and South Asia. Every clause-level claim below is attributed to the State Bank of Pakistan’s consultation document.

5 Critical AI Governance Challenges in Multi-Institution Research Labs – theverge.pk

Transparency note: This article analyses a consultation draft, not enacted law. No statistic, date or clause has been estimated. Where the draft is silent, the article says so rather than filling the gap. Readers should verify deadlines and clause numbering against the notice on sbp.org.pk before acting.

What SBP’s Draft Open Banking Regulations 2026 Actually Require

The open banking regulations Pakistan released in draft by the State Bank of Pakistan in October 2026 require banks, microfinance banks and electronic money institutions to share customer-approved account data and payment access with SBP-authorised third parties through standardised APIs, with Raast proposed as the central consent and routing hub, according to SBP’s public consultation document.

SBP moved at this point because digital payment volumes have outgrown the bilateral integrations that previously connected banks to fintechs. Those arrangements were commercial contracts, negotiated one at a time, with access terms and security conditions that varied by counterparty and that supervisors could not inspect consistently. A supervised standard replaces them, which means the regulator reviews one architecture instead of auditing dozens of private agreements.

The obligation and the right sit on different parties, and the distinction decides who gets in. The duty to expose compliant endpoints falls on the data holder — the institution that holds the account. The right to request data sits with authorised third-party providers only. As a result, an unlicensed aggregation app has no lawful route into the system at all, because there is no credential to borrow once APIs are the only door.

Who and what the draft covers at a glance

• Data holders: commercial banks, microfinance banks and electronic money institutions
• Data users: SBP-authorised third-party providers only
• Data categories: identity and account profile, balances, transaction history, product and pricing terms
• Permission types: read-only data access and payment initiation
• Technical route: standardised APIs, with Raast proposed as the consent and routing hub
• Status: consultation draft, not yet enforceable

Which institutions are covered: banks, microfinance banks and EMIs

Three licence categories carry the data-holder obligation: commercial banks, microfinance banks and electronic money institutions. Coverage therefore follows the licence rather than the business model, which means a small EMI with a narrow wallet product sits inside the same perimeter as a large commercial bank. Third-party providers must hold SBP authorisation before submitting a request. Whether obligations phase in by institution size remains a draft-stage question rather than a settled one, and it is one of the clauses consultation responses should address directly.

Which data categories fall in scope

The draft sets scope at the level of broad categories: account identity and profile data, balances, transaction history, and product or pricing information. Those four cover most account aggregation and underwriting use cases. The boundaries are where the ambiguity sits — derived data such as an internal credit score or a bank’s own behavioural risk rating is calculated by the data holder rather than supplied by the customer. Consultation responses should press SBP to state explicitly whether derived fields are in or out, because that line determines competitive balance.

Payment initiation versus data access

Read access and payment initiation carry different consequences and therefore warrant different controls. Read access exposes a financial history that cannot be un-exposed once transferred. Initiation moves money, which means an authorisation failure produces an immediate, quantifiable loss. Authentication strength and consent duration should differ accordingly: a long-lived read consent for a budgeting app is a reasonable design, while a long-lived blanket initiation consent is not. How the final instrument treats each permission type is the fault line along which liability disputes will run.

Why Raast Becomes the Central Hub for Consent and Data Exchange

Routing every request through one supervised rail changes what supervision is. Because each consent grant, access event and data release passes through a single logged path, SBP gains a continuous audit trail it never had over bilateral bank-fintech integrations. The effect is that oversight becomes a data problem — query the log — rather than an inspection problem requiring on-site review of private contracts.

Raast was selected rather than built new because it already operates as Pakistan’s national instant payment rail, with transaction growth documented across successive editions of SBP’s Payment Systems Review, the regulator’s own quarterly statistical publication. Reusing an operational rail removes the cost and delay of standing up parallel infrastructure and gives every participating institution a connection it has already integrated.

The trade-off deserves stating plainly rather than as a footnote. A single hub standardises consent semantics across every institution, so a consent record means the same thing at a microfinance bank as at a large commercial bank. That same centralisation concentrates availability risk in one operator, hands governance power over the consent schema to one body, and creates a technical vantage point from which the pattern of a customer’s data sharing across all institutions is visible in one place.

The request-to-audit sequence under the draft framework

AI – theverge.pk

1. An authorised third-party provider submits a scoped data or payment request
2. The request is routed to the customer’s data holder through the hub
3. The data holder authenticates the customer directly and presents the specific scope requested
4. The customer grants or refuses consent, producing a machine-readable consent record
5. The data holder releases only the fields inside the granted scope, for the granted duration
6. The hub logs the consent reference, the access event and the release for audit

How a data request travels through Raast

The structurally important step is the third one. Authentication happens at the data holder, not at the requesting app, which is the precise reason credential sharing disappears: the third party never sees a password because it never conducts the login. It receives a scoped token issued after the bank has verified its own customer. The second consequence is that scope is presented by the party that holds the data, so the customer sees the request described in the bank’s standardised language rather than in the app’s marketing copy. That removes the mismatch where an app describes a permission generously and the bank honours it literally.

What the hub model fixes and what it concentrates

The hub fixes three documented weaknesses of bilateral access: inconsistent consent wording between institutions, access events that no regulator could reconstruct afterwards, and uneven API quality across counterparties. It concentrates three different exposures: operational availability, control over the consent schema, and dependency on one operator’s technical roadmap. The audit-trail design problem here mirrors the model provenance challenges in multi-institution AI labs — lineage is only trustworthy when every handoff between institutions is logged by a party with no stake in the outcome.

Consent as Code: Turning Permission Into an Enforceable Object

A consent artefact is a structured record naming the requesting provider, the exact data scope, the stated purpose, the validity period and the revocation route. Because those values are machine-readable, a system refuses any request falling outside them without a human reading anything — enforcement happens at the point of access rather than after a complaint.

The enforcement consequence is substantial. When scope lives in a token rather than in prose, over-collection stops being a dispute about what the customer understood and becomes a detectable policy violation visible in the access log. A provider that requests transaction history under a consent covering balances only generates a refusal and a record, not an argument.

The limitation is equally real and should not be softened: a consent artefact constrains systems, not interfaces. A permission screen built with bundled toggles and maximum-duration defaults produces a technically valid, fully auditable consent for data the customer did not intend to share. The artefact records what was granted, not whether the grant was meaningful. That same gap appears whenever purpose limitation and retention are enforced at the data layer, which is why frameworks on how to build a robust AI data governance framework treat interface design as part of the control set rather than as marketing.

Attribute	Paper / click-wrap consent	Consent-as-code artefact
Form of record	Signed document or logged click	Structured, machine-readable record
Data scope	Described in prose, often broad	Listed by field or category
Purpose binding	Stated, not enforced	Carried in the artefact
Duration	Open-ended or until withdrawn	Explicit expiry date
Revocation route	Written request or support ticket	Dedicated endpoint, immediate effect
Auditability	Reconstructed after a complaint	Logged per access against a consent reference

The verdict beneath this comparison is narrow but firm: consent-as-code makes permission auditable, and auditability is the precondition for every other protection in the draft.

The six fields a consent artefact must carry

• Identity of the authorised third-party provider making the request
• Exact data scope, listed by field or category rather than by product name
• Stated purpose the data may be used for
• Validity period and expiry date
• Revocation method and the endpoint that executes it
• A unique consent reference that appears in every access log

The six fields inside a consent artefact

Each field is load-bearing for a different reason, but the disputes will turn on purpose. Provider identity, scope, duration and revocation route are all verifiable against the log after the fact. Purpose is not, because a field transferred for underwriting looks identical to the same field transferred for marketing. Therefore the final regulations need either a controlled vocabulary of permitted purposes or a requirement that the third party records a purpose tag against each internal use — otherwise the purpose field documents an intention nobody audits.

Revocation, expiry and re-authentication windows

Revocation stops future access from the moment it executes, and under a hub model it executes in one place for every institution. What it cannot do is retrieve data already transferred. Consequently, the real protection sits in the third party’s retention and deletion obligations, not in the revocation button. That obligation is weaker in Pakistan than in comparable jurisdictions because, as of November 2026, data privacy Pakistan law has no fully operational general data protection statute equivalent to the UK or EU regimes. The sectoral rules in this draft therefore carry weight that a general privacy law would otherwise share.

Where consent UX can still mislead users

Four failure modes recur across mature open banking markets: bundled scopes presented as a single toggle, maximum validity set as the default, optional data categories pre-ticked, and revocation buried several screens below account settings. Each produces a valid artefact and an uninformed customer. The final regulations should therefore mandate scope-level toggles, a conservative default duration, and revocation reachable within one step from the account home screen, because without those requirements the artefact faithfully records a consent the user did not meaningfully give.

API Access vs Screen Scraping: Why Credential Sharing Ends

Screen scraping is the practice of logging into a customer’s online banking with the customer’s own credentials and reading the rendered page. It persisted because, absent mandated APIs, there was no other route to account data — so aggregation apps asked for net-banking passwords and inherited full account control, including whatever transfer rights the customer held.

Tokenised API access reverses that exposure. The provider receives a scoped, expiring token instead of a reusable credential, which means a compromised third party leaks a limited and revocable permission rather than a key to the account. The customer’s credential never leaves the bank’s authentication boundary.

Dimension	Screen scraping	Mandated API access	Risk if it fails
What the app holds	Customer’s login credentials	Scoped, expiring token	Full account control vs limited scope
Scope of access	Everything the customer sees	Only granted fields	Silent over-collection
Revocation	Change the password	Revocation endpoint	Access persists unnoticed
Audit trail	None at the bank	Logged per access event	Breaches undetectable
Breakage on UI change	Frequent	Versioned contract	Service outages, stale data
Regulatory visibility	Effectively none	Supervised through the hub	Supervision by complaint only

A mandated standard delivers these gains only where latency, uptime and error handling are specified and supervised, because a slow or unreliable endpoint pushes developers toward workarounds that reintroduce the risks the mandate removed. The UK’s experience is instructive here: the Open Banking Standard API specifications maintained by Open Banking Limited reached version 3.1 and beyond through repeated iteration on exactly these operational details. On the security layer, the FAPI 2.0 Security Profile published by the OpenID Foundation is the financial-grade authorisation benchmark the final Pakistani technical standard should map to — and mapping to an established profile rather than drafting a bespoke one also limits the interoperability and lock-in problems described in what are open standards in AI.

Page not found – theverge.pk

On security grounds alone, the move from credential sharing to tokenised API access is the draft’s least contestable improvement.

How Pakistan’s Draft Compares With CFPB 1033, UK Open Banking and India’s Account Aggregator

The open banking regulations Pakistan has drafted sit architecturally closest to India’s Account Aggregator model, because both route consent through a central licensed intermediary, whereas the UK and US regimes push consent management out to the data holder.

That design choice produces different outcomes rather than different features. A central hub standardises consent semantics faster and gives customers one dashboard, but it concentrates operational and governance risk in a single operator. Distributed consent scales more slowly and produces uneven user experience across institutions, yet no single failure stops data sharing nationally.

The maturity gap should be stated honestly. The UK standard has accumulated years of iteration on dispute handling and API performance. The CFPB’s final rule on Personal Financial Data Rights under Section 1033 is a finalised US federal rule with staged compliance dates. Pakistan’s instrument is a consultation draft. It is therefore best read as a starting standard whose operational detail is still unwritten.

Dimension	Pakistan (SBP draft 2026)	US (CFPB Section 1033)	UK (Open Banking)	India (Account Aggregator)
Legal status	Consultation draft, not enforceable	Final rule with compliance dates	In force, multiple standard iterations	In force under RBI Master Directions
Consent model	Hub-mediated via Raast (proposed)	Data-holder managed	Data-holder managed	Licensed aggregator intermediary
Who holds the consent record	Hub consent register (proposed)	Data provider and authorised third party	Bank and third-party provider	Aggregator consent artefact
Covered institutions	Banks, microfinance banks, EMIs	Depository and non-depository data providers	Largest banks mandated; wider PSD2 scope	Regulated financial information providers
Payment initiation included	Yes	No initiation mandate	Yes	No — data sharing only
Fees for data access	Not stated	Fees barred for covered data	No charge for mandated access	Fee to aggregator permitted
Supervisor	State Bank of Pakistan	CFPB	FCA, with Open Banking Limited standards	Reserve Bank of India

Consent models side by side

Hub-mediated consent, used in Pakistan’s draft and in India’s framework under the RBI Master Directions for NBFC Account Aggregators, gives the customer a single place to see and withdraw every active permission across all institutions. That is a genuine usability advantage, not a technicality, because most consent abandonment happens when a user cannot find what they granted. Data-holder-managed consent in the UK and US fragments that view across every bank app the customer uses, which means the practical burden of tracking permissions shifts onto the individual.

Who pays for the APIs

Pricing decides adoption, and the four regimes diverge sharply. The UK mandated access without charge for in-scope APIs. The CFPB rule bars fees for covered data. India’s directions permit the aggregator to charge for its intermediation. Pakistan’s draft does not state a fee position. That silence is the single clause fintechs should contest in consultation, because a build obligation on banks without a settled revenue route — and an access cost on fintechs without a ceiling — stalls participation on both sides of the rail.

Enforcement and supervision gaps

Supervision quality depends on three answers: who investigates a customer complaint, what penalty attaches to non-compliance, and whether there is a defined dispute resolution path between bank and provider. The UK and US regimes have named supervisors with established enforcement histories. Pakistan’s draft names SBP as supervisor but leaves redress mechanics to be specified. Hub logging makes continuous, telemetry-based oversight technically feasible, which is the distinction drawn in AI vs traditional data governance between rule-based checks and monitored enforcement.

The Unresolved Risks: Fraud, Liability and Compliance Cost

Open banking relocates fraud more than it creates new categories of it. Because credentials stop circulating, attackers shift toward consent manipulation and toward compromising authorised providers that hold already-transferred data. The attack surface narrows at the login and widens downstream.

The liability problem is concrete and unresolved. When a breach occurs at an authorised third party, the customer’s contractual and emotional relationship is still with the bank. Therefore the final regulations need to name who reimburses first and who recovers from whom afterwards. Absent that clause, disputes will default to the party with the most reputational exposure, which distorts both pricing and risk appetite.

Compliance cost concentrates in a way that works against the draft’s stated purpose. A smaller microfinance bank or EMI faces largely the same fixed API build, security certification and logging cost as a large bank, spread across a far smaller customer base. An undifferentiated deadline therefore consolidates the market rather than opening it, which argues for obligations phased by institution size. On the risk-management side, the NIST AI Risk Management Framework and related cybersecurity guidance model continuous, documented assessment of authentication and access controls — an approach stronger than point-in-time certification, because API risk changes with every release.

Risk, consequence and mitigation

• Consent phishing — a fake permission screen harvests a valid consent; mitigate with data-holder-side authentication and a single hub consent dashboard
• Over-broad scopes — apps request more fields than the feature needs; mitigate with scope-level toggles and purpose validation at the hub
• Third-party breach — shared data leaks downstream of the bank; mitigate with mandatory retention limits, deletion-on-revocation and breach notification deadlines
• Liability ambiguity — customer caught between bank and provider; mitigate with a named first-reimburser and a statutory recovery route
• API degradation — slow or unreliable endpoints push developers to workarounds; mitigate with published uptime and latency standards
• Compliance cost concentration — smaller institutions priced out of the build; mitigate with size-tiered phase-in dates
• Hub dependency — one outage halts all data sharing; mitigate with published availability targets and a documented fallback

What Changes for Banks, Fintechs and Customers Before 2027

The open banking regulations Pakistan is consulting on bind nobody in 2026, which means the work between now and the final instrument is preparation rather than compliance. Reading the draft as a deadline misreads it; reading it as a specification of the engineering backlog does not.

The largest commercial consequence is in lending. Permissioned transaction history gives lenders a repayment signal on customers who have no formal credit file, so thin-file underwriting becomes workable at scale and is the clearest route to new lending volume. It is equally the clearest route to new exclusion, because the same data supports adverse inference, and weak scope limits let a lender see far more than the credit decision requires.

Indicative timeline from consultation to compliance

1. Late October 2026 — SBP publishes the draft Open Banking Regulations 2026 for public consultation
2. Consultation window — banks, EMIs, fintechs and the public file written feedback with SBP
3. Post-consultation — SBP revises the draft and issues the final regulations with effective dates
4. Technical standards phase — API specifications, security profile and consent schema published
5. Authorisation phase — third-party providers apply for and receive SBP authorisation
6. Phased go-live — data holders expose live endpoints, with larger institutions expected first

Every step after the consultation window is an expected sequence rather than a confirmed date, because the draft does not fix them.

Banks and EMIs: build obligations

Data holders must build, not merely document. The work comprises standardised endpoints for each in-scope data category, customer authentication and scope-presentation screens, a consent register, per-access logging tied to a consent reference, and a revocation endpoint that takes effect immediately rather than at the next batch cycle. Almost all of that is engineering rather than policy drafting, which means the relevant budget line is development and testing capacity, and the relevant constraint is release schedule rather than legal review.

Fintechs: authorisation pathway

Third-party providers must obtain SBP authorisation before requesting anything, meet the security and governance conditions attached to it, map every requested field to a stated purpose, and implement deletion-on-revocation before launch rather than retrofitting it after a complaint. Products currently built on scraped data need re-architecting, because credential-based access ends when API access becomes the mandated route. Treating authorisation as a launch-week formality is the most expensive planning error available here.

Customers: what to check in your app permissions

Four checks cover most of the risk. Confirm the named provider is the company you intend to deal with. Read the exact data categories, not the summary headline. Check the stated purpose against the feature you wanted. Note the expiry date. One practical instruction matters more than all four: revoke through the bank or hub consent dashboard, because deleting an app from a phone does not revoke the consent that app holds.

How to File Feedback on the Draft Regulations

Consultation is the only stage at which fee treatment, phase-in dates and liability allocation remain changeable. After the final instrument issues, the same argument becomes a compliance complaint with far less leverage. A two-page submission filed now therefore carries more weight than a letter filed in 2027.

Verify the exact deadline and the designated submission address in the consultation notice on sbp.org.pk before writing, because this article cites that notice rather than replacing it, and the channel named in the notice governs.

On substance, three habits raise the odds of influence: cite the clause by number, state the operational or cost consequence in specific terms, and propose replacement wording. Regulators act more readily on a drafted alternative than on a registered objection, because the former reduces their work and the latter adds to it.

Filing a consultation response, step by step

1. Download the draft Open Banking Regulations 2026 consultation document from sbp.org.pk
2. Confirm the stated submission deadline and the designated email or portal in the consultation notice
3. Identify the specific clauses that affect you, by number
4. For each clause, state the operational or cost consequence in two or three sentences
5. Propose alternative wording rather than only registering an objection
6. Submit through the designated channel and keep a dated copy of the submission

Frequently Asked Questions

What are SBP’s draft Open Banking Regulations 2026?
They are a State Bank of Pakistan consultation draft published in late October 2026. The draft would require banks, microfinance banks and electronic money institutions to share customer-approved account data and payment access with SBP-authorised third parties through standardised APIs, with Raast proposed as the central consent and routing hub. It is not yet enforceable.

What does “consent as code” mean in open banking?
It means permission is stored as a structured, machine-readable record rather than a signed disclosure. The record names the provider, the exact data fields, the purpose, the expiry date and the revocation route. Therefore systems automatically refuse any request falling outside the granted scope, and every access event is logged against a consent reference.

Which institutions must comply with the SBP open banking rules?
Commercial banks, microfinance banks and electronic money institutions act as data holders and must expose compliant APIs. Third-party providers must hold SBP authorisation before requesting data, which means unlicensed apps have no access route. Whether obligations phase in by institution size remains a draft-stage question rather than settled policy.

How do customers revoke consent under the draft regulations?
Revocation happens through the bank’s or hub’s consent dashboard and stops future access immediately. The limit matters: revoking does not retrieve data already transferred, so deletion and retention obligations on the third party carry the real protection. Deleting an app from your phone does not revoke the consent that app holds.

Is Raast data shared with fintech apps without permission?
No — under the draft, no data moves without an active customer consent record. The customer authenticates with the bank rather than with the app, which removes credential sharing entirely. The residual risk is manipulated consent through misleading permission screens rather than silent transfer, which is why scope-level toggles matter.

How does Pakistan’s open banking framework compare to the CFPB 1033 rule?
The CFPB’s Section 1033 rule is a final US rule with compliance dates that locates consent management with the data holder and bars fees for covered data. Pakistan’s draft instead routes consent through a central hub. That standardises the user experience faster but concentrates operational and governance risk in one operator.

Who is liable if a third-party provider leaks shared bank data?
The draft does not settle this, which is its most consequential gap. Because the customer’s relationship is with the bank, disputes will land there first unless the final regulations name a first reimburser and a statutory recovery route against the provider at fault. Consultation responses should press for that clause.

When will the open banking regulations take effect in Pakistan?
No date is fixed. The open banking regulations Pakistan released in late October 2026 are a consultation draft, therefore effective dates follow only after SBP reviews feedback, issues the final instrument and publishes technical standards. Readers should verify all dates against the notices on sbp.org.pk rather than relying on secondary summaries.

What data categories are banks required to share?
Account identity and profile details, balances, transaction history, and product and pricing information — each released only within the granted consent scope and only for the granted duration. Treatment of derived data such as an internal credit score is one boundary consultation responses should press SBP to define explicitly, because it decides competitive balance.

How can fintechs and the public submit feedback on the draft?
Through the submission channel named in SBP’s consultation notice on sbp.org.pk, before the stated deadline. Effective submissions cite the clause number, describe the operational consequence in specific terms and propose replacement wording, because regulators act more readily on drafted alternatives than on general objections.

Limitations of This Analysis and What Could Still Change

The primary limitation is the subject itself: this analyses a consultation draft. Clause numbering, scope boundaries at the edges, fee treatment and phase-in dates are all capable of changing before the final instrument issues, so nothing here should be treated as a compliance requirement.

The data limitation is narrower. Raast transaction growth is reported in SBP’s own Payment Systems Review and is referenced here as published, with no independent verification available. This article cites no transaction figure it could not attribute to that publication.

The counter-position deserves space because it is a reasonable reading of the same draft. Critics argue that mandated API construction transfers value from incumbent banks — which bear the build cost — to fintechs that monetise the access without compensating the data holder. A second line of criticism holds that a central hub creates a national surveillance capability over data-sharing behaviour that a distributed model structurally avoids. Neither argument is unserious.

Three alternatives remain available: distributed, data-holder-managed consent as used in the UK and US; a fee-bearing aggregator model as in India; or a voluntary-first standard with mandatory obligations phased in by institution size. Published practice on access logging and metadata transparency, as documented in US government open data governance resources, offers one template for what a supervised hub should disclose about its own operations.

How to Build an Automated Data Analysis Pipeline for Physics Research: A Step-by-Step Guide – theverge.pk

Three publications would change this assessment: an API security profile, an explicit liability clause and a fee rule. Until those exist, any judgement about outcomes stays provisional.

Conclusion

The significance of the open banking regulations Pakistan published in draft in late October 2026 is that privacy becomes a technical control rather than a disclosure promise — consent is enforced by systems reading a structured record, not by customers reading a document. That is a real improvement, and the end of credential sharing is a real security gain.

Two gaps decide whether the framework produces competition or consolidation. Liability allocation determines who carries the cost of a third-party breach, and the absence of a fee rule leaves banks with a build obligation and fintechs with an unpriced dependency. Both are still open, which is precisely why they are still winnable.

The single useful action available now is to read the consultation document on sbp.org.pk and file a clause-specific response before the stated deadline. For continuing reporting on the final instrument, the technical standards and the authorisation process, follow our technology coverage.

References

• State Bank of Pakistan — Draft Open Banking Regulations 2026, public consultation document, published late October 2026: https://www.sbp.org.pk/
• State Bank of Pakistan — Payment Systems Review (quarterly official statistics on Raast transaction volumes and values): https://www.sbp.org.pk/publications/PS-Review/index.htm
• Consumer Financial Protection Bureau — Final Rule on Personal Financial Data Rights (Section 1033): https://www.consumerfinance.gov/rules-policy/final-rules/required-rulemaking-on-personal-financial-data-rights/
• Open Banking Limited (UK) — Open Banking Standard, API specifications v3.1 and later: https://standards.openbanking.org.uk/
• Reserve Bank of India — Master Directions on Non-Banking Financial Company Account Aggregator: https://www.rbi.org.in/Scripts/BS_ViewMasDirections.aspx
• OpenID Foundation — FAPI 2.0 Security Profile: https://openid.net/specs/fapi-2_0-security-profile.html
• National Institute of Standards and Technology — AI Risk Management Framework and cybersecurity guidance: https://www.nist.gov/
• Data.gov — US Government open data principles and data governance resources: https://www.data.gov/