Home  ·  Solutions  ·  Open Banking & PSD2/ÖHVPS

Open Banking, PSD2,
and ÖHVPS

Financial data and payments are moving to open APIs. PSD2 in Europe and ÖHVPS in Türkiye define how. Compliance means more than passing an audit. It means building the right architecture from the start.


What Open Banking changes

Open Banking shifts financial services from closed, proprietary systems to a regulated, API-driven ecosystem. Banks open their data and payment capabilities to licensed third parties, with the customer's explicit consent, creating a new layer of financial infrastructure that fintechs, retailers, and platforms can build on top of.

Single access point

Banking services (balances, transactions, payment initiation) accessible through standardized APIs from one integration point.

Account aggregation

Customers can view and manage accounts across multiple banks in a single interface. Balances, transactions, and limits, all in one view.

Standardized security

OAuth 2.0 and strong customer authentication applied consistently. Access is always scoped, time-limited, and revocable by the customer.

Fintech opportunity

Licensed third parties can offer better experiences: financial dashboards, alternative lending, instant payments, without needing a banking license.

Multi-bank payments

Payment initiation directly from any connected account, without card rails or intermediaries. Faster, cheaper, and traceable.

Market competition

Banks compete on service quality, not data monopoly. Customers can move their financial life to wherever they get the best value.


PSD2 — Payment Services Directive 2

In force since 2018 across the EU and EEA, PSD2 mandates that banks provide a secure API interface (XS2A) to licensed third-party payment service providers. The directive defines three categories of service, each with specific access rights and technical obligations.

AIS

Account Information Service

Operated by AISPs. Read-only access to account data (balances, transaction history, account details) with customer consent.

PIS

Payment Initiation Service

Operated by PISPs. Initiate payment orders from the customer's bank account: SEPA credit transfers, one-time and recurring payments.

FCS

Funds Confirmation Service

Used by PIISPs. Confirms whether sufficient funds are available in the customer's account, without accessing full account data.

AISAccount Information APIsIBAN, balances, transaction history
PISPayment Initiation APIsSEPA credit transfers, one-time & recurring payments
CAFFunds Confirmation APIsAvailability check without full account access
SCAAuthentication APIsOAuth 2.0, strong customer authentication
CSTConsent ManagementGrant, track, and revoke user permissions
TOKToken APIsIssue, validate, and revoke access tokens
PSD2 mandates Strong Customer Authentication (SCA): two-factor verification for account access and payment initiation. Exemptions exist, but the default is always verify.

Technical standards

  • Berlin Group NextGenPSD2 framework
  • UK Open Banking standard
  • EBA Regulatory Technical Standards (RTS)
  • OpenAPI 3.0 API specifications
  • eIDAS-based certificate requirements

Third-party obligations

  • Licensed by national competent authority
  • Registered in EBA register of TPPs
  • eIDAS qualified certificates (QSEAL, QWAC)
  • Explicit customer consent for every access
  • Compliance with SCA and RTS requirements

ÖHVPS — Türkiye's Open Banking Framework

ÖHVPS (Ödeme Hizmetleri Veri Paylaşım Servisleri) is the national open banking framework established under the regulation of the Central Bank of the Republic of Türkiye (TCMB). It defines how payment service providers and licensed third parties securely share financial data and initiate payments through standardized APIs, within a centralized national infrastructure.

YÖS

Yetkili Ödeme Hizmeti Sağlayıcı

The licensed third-party provider in ÖHVPS, equivalent to TPP in PSD2. YÖS entities access customer accounts, initiate payments, and retrieve account information, always with explicit customer consent.

  • Account information access (AIS equivalent)
  • Payment initiation (PIS equivalent)
  • Customer consent-based access
  • Licensed by TCMB
HHS

Hesap Hizmeti Sağlayıcı

The account-holding institution, equivalent to ASPSP in PSD2. HHS entities (banks and payment institutions) must expose compliant ÖHVPS APIs and support the consent and authentication flows required by the framework.

  • Exposes account information APIs
  • Accepts and processes payment initiations
  • Manages consent lifecycle
  • Connected via BKM central layer

Unlike PSD2's decentralized model, ÖHVPS routes all interactions through a central infrastructure operated by BKM (Bankalararası Kart Merkezi). This ensures standardization across all participants and simplifies integration for third parties.

BKMCentral API gateway & routingBankalararası Kart Merkezi
AISAccount Information APIsIBAN, balances, transaction history
PISPayment Initiation APIsEFT/FAST, one-time & scheduled payments
SCAStrong AuthenticationOTP / mobile approval via bank channels
CSTConsent ManagementCreate, track, and revoke customer consent
TOKToken & Session APIsOAuth 2.0-based secure API access
EVTEvent / Notification APIsPayment status updates, consent status changes

PSD3 and the road ahead

The European Commission is actively working on PSD3. While the full text is still being finalized, the direction is already clear from public consultations and draft proposals, pointing toward a more rigorous, more consistent, and broader-scoped framework than PSD2.

Stronger fraud protection

Clearer liability rules for unauthorized transactions, closing the gaps that PSD2 left open across member states.

Consistent implementation

PSD2 was interpreted differently across EU countries. PSD3 aims to close those gaps with more prescriptive technical requirements.

Open Finance scope

Beyond payment accounts: pensions, insurance, investments. The open banking model is expanding to the full financial picture.

Improved SCA flows

Better exemption frameworks and more user-friendly authentication, reducing friction without reducing security.

The regulatory landscape keeps moving. Whether you're building for PSD2 compliance today or preparing for what PSD3 will require tomorrow, the underlying architecture needs to be designed to adapt. Not just to pass the current audit.