Integrate UKRSIB business: balances, transactions and the payment-document queue

Every UKRSIBBANK BNP Paribas Group company that opens UKRSIB business sees the same handful of surfaces: UAH and FX account balances, the running list of booked transactions, and a queue of UAH payment documents waiting on a qualified electronic signature. Those are the records a treasury system, an accounting feed, or a cash-position dashboard wants out — usually as a one-time pull of history first, then a steady trickle of what changed. What follows is the data the app actually carries, the authorized way to reach it, and the runnable code we hand over.

The short version: balances and the transaction list ride the consented open-banking read, which is the durable surface the National Bank of Ukraine has been standardizing. The payment-document queue and the FX applications, which a basic open-banking interface is not built to carry, we reach through authorized interface work against a consenting company's session. Most engagements use both.

What the app actually holds

Mapping the app's own feature list onto where each record originates and what it is good for downstream:

Authorized routes to the data

Three routes apply here. We scope which combination fits during onboarding and arrange the access with you.

Consented open-banking read (NBU)

Ukraine's open-banking provisions went live on 1 August 2025. A duly registered account-information provider obtains a qualified open-banking certificate and a user consent grant, then reads balances and the booked-transaction list through the bank's standardized interface. This is the most durable surface for the two domains it covers, because the rules behind it are now law rather than a private arrangement. We handle the certificate, the consent flow, and the registration questions with you.

Authorized interface integration of the app's session

For surfaces the standardized read does not carry — the QES payment-document queue, the FX sale and conversion applications, multi-company switching — we analyze the app's own client-to-server traffic under the client's authorization and against a consenting company's account. This reaches everything a logged-in user sees. Because it follows the app's own client, we pin the captured contract to a release and re-check it whenever UKRSIB business ships an update.

User-consented export as a fallback

Where a finance team can pull a statement out of the app for a defined window, we can parse that export to seed a backfill before the live feed takes over. It is a stop-gap, not the spine, but it shortens the first delivery.

The backfill, against the consented interface

The first job on almost every UKRSIB business engagement is history: walk each account's booked transactions oldest-first, page by page, into a one-off load, then hand the same account to a delta reader keyed on the last cursor. The sketch below uses a Berlin Group-style account-information shape — paths and headers are illustrative and get pinned against the live consented interface during the build.

# Backfill one account's booked history, then page forward on a cursor.
# access_token comes from the open-banking OAuth2 consent grant;
# requests are signed per the NBU open-banking certificate.

GET /ob/v1/accounts/{accountId}/transactions
    ?bookingStatus=booked
    &dateFrom=2022-01-01
    &dateTo=2024-12-31
    &page=0
Authorization: Bearer {consent_access_token}
X-Request-ID:   7f3a9c2e-...
Signature:      keyId="ob-cert",algorithm="rsa-sha256",headers="...",signature="..."

200 OK
{
  "account":  { "iban": "UA...", "currency": "UAH" },
  "balances": [ { "balanceType": "interimAvailable",
                  "balanceAmount": { "currency": "UAH", "amount": "184220.55" } } ],
  "transactions": {
    "booked": [
      { "transactionId": "tx_...",
        "bookingDate": "2024-03-04",
        "transactionAmount": { "currency": "UAH", "amount": "-15400.00" },
        "creditorName": "...",
        "remittanceInformationUnstructured": "invoice 2041" }
    ],
    "_links": { "next": "/ob/v1/accounts/{accountId}/transactions?page=1" }
  }
}

# FX accounts return currency != UAH and pair with the FX-application feed.
# The QES payment-document queue is a SEPARATE state machine, not a /transactions row:
#   draft -> awaiting_signature -> approved -> executed
# We read it through the authorized-interface route and emit it as its own record type.

What we hand back

The deliverable is code you can run, not a slide deck. In order:

• Runnable source for the key reads — a Python or Node.js client covering the backfill loop, cursor-based delta sync, balance snapshots, the FX-application feed and the QES document queue, with retry and pagination handled.
• A notification handler that turns the app's PUSH events (a declined payment, a certificate nearing expiry) into sync triggers and ops alerts, so the feed reacts instead of only polling on a timer.
• An automated test suite that runs the client against a sandbox or a consenting account and asserts the parsed balances, transactions and document states match known fixtures.
• A normalized schema (below) and a mapping layer from the bank's field names to it.
• An OpenAPI description of the surfaces we integrate, and a written auth-flow note covering the OAuth2 consent grant, certificate signing and token refresh as they behave here.
• Interface documentation plus data-retention and consent-logging guidance for the records you keep.

Normalized records

Two of the shapes we hand over, so a UAH transaction and a UAH payment document never get confused for each other:

// Posted, settled money movement
Transaction {
  entity_id, account_id, currency,        // currency: "UAH" or an FX code
  booked_at, amount,                       // signed minor units
  counterparty, purpose, source_ref        // source_ref = bank transactionId
}

// A payment instruction still moving through the signing queue
PaymentDocument {
  entity_id, account_id, currency: "UAH",
  state,                                    // draft | awaiting_signature | approved | executed
  amount, beneficiary, created_at,
  signatures_required, signatures_present   // QES; group signing supported
}

How consent and the NBU rules apply here

This is a Ukrainian bank, so the framework is Ukraine's own. The open-banking provisions of the Law of Ukraine “On Payment Services” took effect on 1 August 2025, with the operational detail set by the National Bank of Ukraine's Regulation on Open Banking. Account-information and payment-initiation providers must register, hold a qualified open-banking certificate, and act on an explicit user consent that names its scope and can be revoked. The NBU rules distinguish a basic interface — a defined, free data set — from a commercial one carrying more, which informs which fields the consented read returns versus which we reach through authorized interface work. We operate every engagement on authorized, documented or user-consented access, log the consent records, minimize what we retain to the fields you asked for, and work under an NDA where the company needs one. No personal credentials are ever asked of an end user outside the bank's own consent screen.

What we account for in this build

Specific to UKRSIB business, these are the things that bite if they are not handled, and that we plan for up front:

• UAH against FX. Balances and applications differ by currency. An FX sale or conversion application settles into a UAH leg, so we normalize across currencies and link the application to its settlement movement rather than leaving two unrelated rows.
• The signing queue is not the ledger. A large share of what a company sees is UAH payment documents awaiting a qualified signature or group approval — not posted transactions. We model that lifecycle as its own feed, so a backfill of booked history never absorbs the pending queue.
• One login, several companies. A user with access to multiple companies switches between them in-app. We key every record to its legal entity or FOP from ingestion onward, so multi-entity treasury never collapses two companies into one ledger.
• Consent has a clock. An open-banking grant is time-bounded. We build the re-consent step into the sync schedule and expose its state in the run, so a multi-year backfill running alongside the daily delta always knows whether its grant is still valid.

Interface evidence

Screens from the app's store listing, used during scoping to confirm the surfaces above. Click to enlarge.

What was checked

Scope rests on the app's own Google Play description for the surface inventory, and on the National Bank of Ukraine plus independent legal coverage for the open-banking framework and its timeline. Sources opened while writing this:

• UKRSIB business on Google Play — the feature list this brief maps.
• National Bank of Ukraine — Open Banking — the regulator's own framework page.
• CEE Legal Matters — Open Banking to launch in Ukraine on 1 August 2025 — the launch date.
• Wolf Theiss — AIS/PIS providers and their regulatory status — the certificate and provider-registration detail.

Notes compiled by OpenFinance Lab's interface engineering team — 8 June 2026.

Where UKRSIB business sits among Ukrainian business apps

A unified integration across Ukrainian SME and corporate banking touches most of these. Same data shapes, different banks:

• Privat24 — PrivatBank's app; for business it covers settlements, transfers, currency operations and document flow for legal entities and entrepreneurs.
• monobank — runs on Universal Bank; offers FOP and business accounts with statements and payments inside a mobile-only flow.
• PUMB Online — First Ukrainian International Bank; entrepreneur features include balance and statement views and sharing account details with partners.
• MyRaif — Raiffeisen Bank's app, with business banking for its SME and corporate clients.
• Sense SuperApp — Sense Bank (formerly Alfa-Bank Ukraine); accounts, payments and statements for business users.
• OTP Smart — OTP Bank Ukraine; account access and payments alongside its corporate channels.
• Oschadbank — the state savings bank; corporate and entrepreneur accounts with statement and payment surfaces.
• izibank — a Ukrainian neobank built around smartphone account management.

Questions integrators tend to ask

Can you backfill several years of UAH and FX transactions, not just the current statement?

Yes. We walk each account's transaction history page by page, oldest first, into a one-off backfill, then switch the same account onto a delta read that only pulls what booked since the last cursor. Balances are point-in-time, so we snapshot them on the same schedule rather than reconstructing them from the transaction sum.

Does this run over Ukraine's new open banking regime or against the app directly?

Often both. Balances and the booked-transaction list map cleanly onto the consented open-banking read that the NBU rules standardized from 1 August 2025, which needs a qualified open-banking certificate and a user consent grant. Surfaces the basic interface is not built to carry — the QES payment-document queue, FX applications, multi-company switching — we reach through authorized interface work against a consenting company's session.

How do you handle the payment documents that are still waiting on a qualified signature (QES)?

We model them as their own document-state feed, separate from booked transactions. A UAH payment document moves through draft, awaiting-signature and approved states before it ever settles, so we expose that lifecycle as distinct records — a pending-signature queue is not a posted transaction and we never blend the two.

We have several companies under one UKRSIB business login — can you keep them separate?

Yes. The app lets one user switch between companies, and we key every ingested record to its legal entity or sole-proprietor profile from the start, so two companies under the same login never merge into one ledger downstream.

You give us the company's consent — or the app and your authorization — and a plain statement of what you want out of it; the working integration comes back in one to two weeks. Take the runnable source outright from $300, which you pay only after delivery once it does what you need. Or skip the build entirely and call our hosted endpoints, paying per call with nothing upfront. Access, the open-banking certificate and any compliance paperwork are arranged with you as part of the job. Tell us what you need from UKRSIB business