VakıfBank Mobil Bankacılık inside Turkey's open-banking scheme

Türkiye Vakıflar Bankası is one of Turkey's three large state-owned banks, and its retail app sits inside a national data-sharing scheme that, unusually, fixes the integration route in regulation rather than leaving it to a vendor's discretion. That changes the conversation. For most apps an integrator has to discover the path; for VakıfBank the path is named, certified and supervised. The question is which parts of what the app holds travel down that regulated path and which need authorized interface work alongside it.

The short version: account, balance and transaction data — including the cross-bank accounts the app already aggregates — moves through the regulated ÖHVPS channel and is the durable backbone. The investment portfolio, card installment detail, the Benim Yerim tax and utility flows, and the commercial approval workflow are richer than the standardised account set, so we reach those with authorized interface integration that runs next to the regulated feed. Both, normalised into one schema, are what you actually want.

The ÖHVPS scheme and where consent sits

Turkey runs a single national framework for sharing payment-account data, ÖHVPS (Ödeme Hizmetleri Veri Paylaşım Servisleri — Data Sharing Services in the Field of Payment). Operating permits for account information service are issued by the Central Bank of the Republic of Türkiye (CBRT); the technical plumbing is BKM's API Gateway, against the ÖHVPS API Principles and Rules. The legal base is Law No. 6493, amended in 2019 to add account information and payment-initiation services, with the operative sub-regulations published in December 2021 and a clarifying CBRT guide in late 2022.

It is mid-transition. A regulation amendment was published in the Official Gazette on 28 March 2025 and, as summarised by Esin Attorney Partnership, the compliance deadline was extended to 31 December 2025, with ÖHVPS 2.0 still circulating as a draft and certifications expected to begin after August 2025. We treat that as a planning fact, not a blocker: the build pins to whatever certified version VakıfBank has in production at the time, and we account for the cutover. Consent under this scheme is explicit, scoped, logged and revocable by the account holder. Data minimisation and consent-record keeping are how we run, not extras.

What the app holds, screen by screen

Routes to the data

Regulated AIS through the BKM gateway

Accounts, balances, transactions and the cross-bank aggregated set come through ÖHVPS in BKM's standardised shapes. This is the durable spine — it is the supervised, certified path and it survives app redesigns because the contract is the regulation, not the screen. Onboarding to the BKM gateway and the CBRT permit position are arranged with you during the engagement; that is our step, handled, not a hurdle put in front of you.

Authorized interface integration

The investment portfolio, card installment breakdowns, Benim Yerim, and the commercial approval workflow are not part of the standardised account set. We map the app's own traffic for these under your authorization, normalise the responses, and add a re-validation step keyed to app updates so a redesign does not silently break the feed.

User-consented account access

Where a consenting account is the cleanest path — early in the build, or for surfaces not yet in regulated scope — we run against that account under explicit authorization, logged, and decommission the credentials on handover.

What we would actually recommend: take the regulated ÖHVPS channel as the backbone for everything account- and transaction-shaped, because it is stable and supervised, and run authorized interface integration alongside it only for the investment and commercial surfaces ÖHVPS does not cover. One schema over both, so the consumer never sees the seam.

The build you receive

Concretely, for this app:

• An OpenAPI specification covering the ÖHVPS account, balance and transaction resources as VakıfBank exposes them, plus the interface-integrated investment and commercial endpoints, under one normalised model.
• A protocol and auth-flow report: the BKM gateway client-certificate / mutual-TLS handshake and the ÖHVPS consent-token lifecycle, alongside the app's own session and SMS step-up chain for the non-regulated surfaces.
• Runnable source for the key endpoints in Python and Node.js — account list, balance, transaction history, investment positions, card detail — with retry and consent-expiry handling.
• Automated tests against recorded fixtures, including the consent-refresh and version-cutover paths.
• Interface documentation and data-retention guidance written for an auditor, not just an engineer.

A statement query, sketched

Illustrative only; resource and field names are confirmed against the certified version during the build. ÖHVPS resources use Turkish names (hesap = account, bakiye = balance, hareket = transaction).

# Regulated AIS read via the BKM API Gateway
# Transport: mutual-TLS, client cert registered with BKM
# Authorization: ÖHVPS consent token bound to the account holder's rıza (consent)

GET /ohvps/hesaplar/{hspRef}/hareketler?fromDate=2026-04-01&toDate=2026-04-30
Host: gateway.bkm.example            # BKM gateway, per certified ÖHVPS version
Authorization: Bearer <consent_access_token>
PSU-Initiated: false                  # background sync, no user present
X-Request-ID: 6b1c...e2

200 OK
{
  "hspRef": "TR93-****-4417",
  "paraBirimi": "TRY",                 # currency
  "bakiye": { "tutar": "18432.55" },   # balance.amount
  "hareketler": [                      # transactions
    { "islemId": "9f02a1", "tutar": "-540.00", "aciklama": "Kart taksit",
      "tarih": "2026-04-12T09:51:00+03:00", "yon": "BORC" }
  ]
}

# Error handling we ship:
#   401 / consent expired -> trigger re-consent flow, do not retry blindly
#   429                  -> honour Retry-After from the gateway
#   TR-version mismatch  -> fall through to the pinned certified version,
#                           raise a cutover alert for the 2.0 transition
      

Engineering realities we plan around

Four things about this app specifically that the build accounts for:

• Two account sources, one view. The app aggregates other Turkish banks' accounts through ÖHVPS, so an "all accounts" call returns VakıfBank-held data and externally aggregated data with different consent scopes and refresh windows. We model them as distinct sources so an aggregated total never blends a stale external feed with a live VakıfBank one.
• The 2.0 cutover. ÖHVPS is moving from a 1.x line to a draft 2.0 with a certification timeline running through end-2025. We pin to the version VakıfBank has certified in production and schedule a re-validation step for the cutover so the AIS feed does not break when BKM moves the gateway forward.
• Commercial authorization levels. The Approval Transactions menu exposes data and actions by mandate, so what a commercial user can read or approve differs by their authorization level. We scope the integration per level rather than assuming a single permission shape.
• SMS step-up and device binding. The auth chain uses SMS one-time codes and device binding. We design token and session handling around that so background sync is stable and re-consent is predictable, not a surprise mid-run.

Where teams use it

• A Turkish accounting platform pulling VakıfBank statements and card transactions to keep SMB books current without manual export.
• A wealth dashboard syncing the investment portfolio — funds, eurobonds, treasury bills, bonds — into a single performance view.
• A corporate treasury tool reconciling commercial accounts and routing items through the right approval level.
• A personal-finance app using the aggregated external-account view so a user sees every Turkish bank in one place.

App screens referenced

Public store screenshots used while mapping the surfaces above.

Other Turkish banking apps in the same surface

Same scheme, comparable data, useful when a project wants more than one Turkish bank behind one interface.

• Ziraat Mobil — T.C. Ziraat Bankası, another large state bank and the most-used finance app in Turkey; near-identical account, transfer and investment surfaces under the same ÖHVPS scheme.
• İşCep — Türkiye İş Bankası's app; broad retail plus investment data, a frequent companion in multi-bank aggregation.
• Garanti BBVA Mobile — strong digital-banking feature set; accounts, cards and investments reachable via the same regulated path.
• Akbank — retail and investment banking with a customizable home and biometric login; comparable account and card data.
• Enpara.com — QNB's branchless brand; deposit and transfer focused, lighter product set, same consent rules.
• Papara — an e-money and wallet service holding prepaid balances and transfer history; sits on the third-party side of ÖHVPS.
• MobilDeniz — Denizbank's app; retail accounts, cards and investment products in the same regulatory frame.
• Vakıf Katılım — VakıfBank's participation-banking sibling; interest-free accounts and financing, separate institution, same scheme.

Sourcing and review notes

Surfaces were taken from the app's own store description and VakıfBank's digital-banking pages; the regulatory route from the CBRT/BKM ÖHVPS materials and a current legal summary, checked in May 2026. Primary sources: BKM — Data Sharing Services (ÖHVPS), VakıfBank — Open Banking, Esin Attorney Partnership — open-banking developments, April 2025, Open Banking Tracker — Turkey.

Mapped and reviewed by the OpenBanking Studio integration desk, May 2026.

Questions integrators ask about VakıfBank data

Does the cross-bank account view inside VakıfBank Mobile change how you would integrate it?

It does. The app already pulls balances and transactions from other Turkish banks through the national ÖHVPS scheme, so those surfaces arrive in the shapes BKM standardises. We model the VakıfBank-held accounts and the aggregated external accounts as separate sources because their consent scope and refresh windows are not the same, and an aggregated balance should never quietly blend a stale external feed with a live VakıfBank one.

Which regulator and scheme govern access to VakıfBank account data?

Operating permits for account information service are issued by the Central Bank of the Republic of Türkiye (CBRT), and the technical path runs through BKM's API Gateway under the ÖHVPS API Principles and Rules. Account, balance and transaction reads happen with the customer's consent, recorded and revocable, against the certified ÖHVPS version VakıfBank has in production.

Can investment holdings — funds, eurobonds, treasury bills — be reached the same way as balances?

Not through the same channel. The portfolio screen (stocks, funds, eurobonds, treasury bills, bonds) is richer than the account-information set ÖHVPS standardises. We reach it through authorized interface integration of the app's own investment surfaces, kept separate from the regulated account feed, with valuation and instrument breakdown normalised into one schema.

We already hold a CBRT account-information licence — does that shorten the build?

Yes, it removes the licensing step from the critical path; the work then concentrates on BKM gateway onboarding and mapping the certified ÖHVPS resources. Where you do not hold a licence, access is arranged with you during onboarding — a consenting account or sponsor route — so the build still proceeds. Tell us where you stand at /contact.html.

Source delivery starts at $300: you receive the runnable code, the OpenAPI specification, the ÖHVPS and auth-flow report and the test suite, and you pay only once it is in your hands and working as described. If you would rather not run anything yourself, the same endpoints are available as a hosted API billed per call, with nothing paid upfront. A typical VakıfBank build runs one to two weeks, depending on how many of the investment and commercial surfaces you want beyond the regulated account feed. Tell us the app and what you need from its accounts at /contact.html and we take it from there. You give us the target and the requirement; the route, the access and the compliance posture are ours to handle.