Account, card and deposit access for Pivdenny Online under Ukraine's open banking rules

As of 1 August 2025 Ukraine has a live open-banking regime, and that changes how a third party reaches data held inside Pivdenny Online. The app belongs to JSB Pivdennyi Bank, an Odesa bank founded in 1993 (per the bank's own profile) and one of the larger banks operating with Ukrainian capital. Behind the login it holds the things an aggregator, lender or accounting tool actually wants: current and card account balances, full transaction history in hryvnia, deposit positions across the bank's Premium, Profitable Plus and Mobile Deposit programs, and statements the app already renders to PDF and CSV. The question is no longer whether that data can be reached, but which authorized route fits each surface.

Where Ukrainian consent rules put the data

The National Bank of Ukraine adopted its Open Banking Regulation by Board Resolution No. 80 on 25 July 2025, in force from 1 August 2025. It implements the account-access provisions of Chapter 4 of the Law of Ukraine "On Payment Services" and tracks EU Directive 2015/2366 (PSD2). In practice that means a consented account-information service (AIS) connection is now the regulated way for a licensed third party to read a customer's balances and transaction history from a Ukrainian bank — Pivdennyi included. Banks were given a window into early 2026 to bring their APIs into line, so coverage is uneven bank by bank during the rollout, and an active provider market is widely expected to settle through late 2026.

The dependable basis for any integration we build is the account holder's own authorization — the consent they grant, recorded and revocable. The NBU framework sets consent scope, validity and revocation around that. Where a Pivdennyi endpoint is not yet exposed under the new rules, we cover the same data through authorized protocol analysis against a consenting account, so the project does not stall waiting on a rollout date.

What sits behind the login

Three authorized ways in

1 — Open-banking AIS consent (NBU)

The customer authorizes an account-information connection through the NBU regime; we hold the third-party side and pull accounts, balances and transaction history over the bank's consent API. Reachable: the core read surfaces. Effort: moderate, mostly onboarding and consent handling. Durability: high — it rides a published, regulated interface rather than the app's screens. We arrange the provider onboarding and consent flow with you as part of the build.

2 — Authorized protocol analysis of the app traffic

For surfaces the AIS scope does not reach — deposit-program operations, virtual-card issuance and re-issue, currency placement, card controls — we analyze the app's own traffic against a consenting account and rebuild the relevant calls as a clean client. Reachable: nearly everything the app itself does. Effort: higher, and it tracks app releases. Durability: good with maintenance. Access is arranged with you during onboarding; the build runs against an account you consent to.

3 — Native PDF / CSV export

The app already generates statements as documents. We drive that same export and normalize the CSV into a stable schema. Reachable: historical statement data. Effort: low. Durability: high for backfill. This is the cheapest path when you mainly need history rather than a live feed.

For Pivdenny Online specifically, the AIS route is the one we would build on first now that the NBU regime is live — it gives consented, durable read access to accounts and transactions without depending on the app's UI. The deposit programs, card issuance and currency placement come through protocol analysis on top, and the PDF/CSV export covers historical statements with almost no engineering. Most engagements end up combining the AIS read core with one or two protocol-analysis calls for the surfaces clients actually ask about.

What lands in your repo

The output is working software for Pivdenny Online's surfaces, not a feasibility memo. Concretely:

• An OpenAPI / Swagger specification covering the account, transaction, deposit and statement endpoints we wire up.
• A protocol and auth-flow report — the consent handshake for the AIS route, and the token / session / refresh chain for the protocol-analysis calls.
• Runnable source for the key endpoints in Python or Node.js: consent setup, account and balance reads, transaction pulls, statement export and CSV normalization.
• Automated tests against the surfaces, including the UAH amount and date-range edge cases.
• Interface documentation a developer can follow, plus compliance and data-retention guidance fitted to the NBU consent rules.

A consented read, in outline

Illustrative shape of the AIS read and a statement export — exact paths and field names are confirmed during the build against the live connection.

# 1. Register an account-information consent (NBU open-banking AIS)
POST /openbanking/v1/consents
  Authorization: Bearer {tpp_token}
  {
    "permissions": ["ReadAccountsDetail","ReadBalances","ReadTransactionsDetail"],
    "expirationDateTime": "2026-12-06T00:00:00Z"
  }
-> 201 { "consentId": "c-7f3a...", "status": "AwaitingAuthorisation" }

# 2. Customer authorises in Pivdenny Online; then read transactions
GET /openbanking/v1/accounts/{accountId}/transactions?fromBookingDateTime=2026-01-01
  Authorization: Bearer {user_token}
-> 200 {
     "Transactions": [
       { "amount": {"value":"-450.00","currency":"UAH"},
         "bookingDateTime":"2026-05-30",
         "info":"Kyivstar mobile top-up" }
     ]
   }

# 3. Fallback for history: drive the app's own statement export
GET /statements?accountId={accountId}&format=csv&from=2026-01-01&to=2026-05-31
-> 200 text/csv  ->  normalize to {date, amount, currency, counterparty, type}
      

Things we account for on this build

Two details specific to Pivdenny Online shape how we scope the work.

The card surfaces are sensitive. The app issues and re-issues virtual cards and displays the CVV2/CVC2 in-app, which is full PAN-grade data. We keep those endpoints out of any standard data feed and only build card control when you explicitly need it, with tokenized handling and tighter logging around that path. The read core — balances, transactions, statements — stays well clear of it.

Consent expiry is a moving part, not a one-time switch. The NBU regime gives every connection a validity window and a revocation right, so we design the sync to refresh consent before it lapses rather than letting a connection silently go dark. On the protocol-analysis side, the app authenticates with Face ID, Touch ID or PIN over a device-bound session; when Pivdennyi ships a new version and that login flow shifts, the integration needs a fresh look, so we document the token chain up front and build a quick re-check step in from the start. Access — a consenting account or the provider onboarding — is arranged with you during onboarding, not something you hand over before we begin.

Pricing and how it runs

Most clients take the source-code build: a runnable client for Pivdenny Online's account, transaction, deposit and statement endpoints, priced from $300 and paid only after delivery, once you have run it and are satisfied. The other option is our hosted API — you call our endpoints for Pivdenny Online data and pay per call, with nothing upfront. Either way the cycle is one to two weeks. Tell us the data you need from the app and we handle the route, the access and the compliance side from there — start the conversation here.

App screens

Screens from the Play Store listing, useful for reading the actual surfaces. Tap to enlarge.

What was checked

Surfaces were read from the app's Play Store description and listing; the regulatory position from the NBU and Ukrainian legal coverage of the August 2025 open-banking launch; the bank's standing from its supervisory record. Checked June 2026 against these primary sources:

• Pivdenny Online on Google Play — feature and surface list (package com.bank.pivdenny).
• NBU supervisory record — JSB Pivdennyi Bank licensing status.
• Open Banking to launch in Ukraine on 1 August 2025 — NBU Resolution No. 80 and PSD2 alignment.
• Open banking in Ukraine: AIS/PIS providers — provider roles and consent framing.

Mapped by the OpenBanking Studio integration desk · June 2026.

Other Ukrainian banking apps in the same picture

Anyone aggregating Ukrainian retail banking meets the same consent regime across these apps, so they tend to come up together when planning a unified integration. Named for context, not ranked.

• Privat24 — PrivatBank's app, the most-used finance app in Ukraine, holding broad account, card and payment data.
• monobank — branchless neobank with cards, cashback ledgers and transaction feeds delivered entirely in-app.
• Sense SuperApp — Alfa-Bank Ukraine's app covering personal and sole-proprietor accounts, deposits and currency operations.
• PUMB Online — First Ukrainian International Bank, with lending products alongside accounts and cards.
• Oschadbank — large state bank with retail accounts, statements and a wide branch and card base.
• Raiffeisen Bank Ukraine — accounts, cards and transfers from one of the country's larger foreign-owned banks.
• izibank — smartphone-only neobank focused on cards and consumer credit balances.
• A-Bank — consumer-lending-focused bank with cards, accounts and payment history in-app.
• SportBank — digital card-led bank with transaction feeds and in-app card controls.

Integrator questions

Does Ukraine's open banking regime cover account access at Pivdenny Bank?

Yes. The NBU's Open Banking Regulation took force on 1 August 2025 and is aligned with the EU PSD2 directive and Chapter 4 of the Law of Ukraine on Payment Services, so a consented account-information (AIS) connection to a licensed bank like Pivdennyi is the regulated route to balances and transaction history. Banks were given until early 2026 to stand up their APIs, so where a given endpoint is not yet live we cover the same surfaces through authorized protocol analysis against a consenting account.

Can you reach the virtual-card issuance and CVV reveal flows, or only balances and statements?

Balances, accounts and transaction history come cleanly over AIS consent. Card-control surfaces the app exposes — virtual-card issuance, re-issue, PIN and limit changes, and the in-app CVV2/CVC2 display — sit outside AIS and are reached through protocol analysis of the app's own traffic. These are sensitive PAN surfaces, so by default we keep them out of any data feed and only build them when you specifically need card control, with tokenized handling and tighter logging around them.

How do you handle the PDF and CSV statements the app already generates?

Pivdenny Online generates statements server-side in PDF and CSV. We read the same generation request the app issues and normalize the CSV into a stable transaction schema, so a Pivdenny export lines up field-for-field with statements you pull from other banks. For purely historical backfill this is the cheapest path and needs almost no ongoing maintenance.

What happens to the integration when Pivdenny ships a new app version?

The protocol-analysis routes depend on the app's login and token flow, which can shift between releases. We document the token and refresh chain during the build and add a quick re-check step so a new app version is caught and corrected before it breaks a running sync. The AIS route is more stable, since it rides the bank's published consent API rather than the app UI.