Pulling SME and entrepreneur ledgers out of UKRSIB business

UKRSIBBANK BNP Paribas Group put its SME and individual-entrepreneur portal on phones with UKRSIB business, and what sits behind the screens is a Berlin-Group-shaped account ledger plus a Ukrainian QES-signed payment-document pipeline. The route to that data changed in 2026: NBU Resolution No. 80 came into force 1 August 2025, and payment service providers had until 1 January 2026 to be open-banking-compliant. The integration question stopped being "if" and turned into "which mix of AIS, authorized interface work, and QES handling fits the company you actually need to wire up".

The shortest honest summary: the read side (balances, statements, account list across multiple companies a user controls) belongs on the AIS rail. The write side that this app actually exposes — UAH payment documents drafted, copied, adjusted, e-signed with QES, then released by joint actions, and FX applications submitted on the side — is mostly served by authorized interface integration of the app's own session, because that is how the company's QES rights and the multi-company switcher actually behave.

What the app holds, surface by surface

Authorized routes to that data

1. AIS under the NBU Open Banking Regulation

This is the spine for the read side. The Ukrainian regime is modelled on PSD2 and the technical interfaces follow Berlin Group NextGenPSD2 (RESTful, JSON, OAuth2, request signing) per the AUB / UPC industry positioning. UKRSIBBANK has fallen under the 1 January 2026 compliance window for account-servicing payment service providers, so an authorized third party with consent from the company can pull balances and transactions on the same standard shape used across other Ukrainian banks. Durability is the strong point — once the rail stabilizes, the bank cannot quietly take it away.

2. Authorized interface integration of the UKRSIB business app session

The mobile and web app surface a richer set of operations than AIS will ever cover: the UAH payment document lifecycle, the joint-actions signing queue, the multi-company switcher, and the FX application screens. Where the customer authorizes it and provides a real signing account, we reverse-engineer the app's authenticated traffic, model the request/response shapes for those flows, and ship a typed client. Effort is higher than AIS, the durability follows the app's release cadence, and that is exactly what the maintenance line is for.

3. User-consented credential access for read-only mirroring

For companies that want a quick read-only mirror into a data warehouse and do not yet want to register as an AIS-route consumer, the consenting principal of the company provides scoped credentials. We run the read loop on a schedule under their identity, log every fetch, and stop on the first refusal. This is a stop-gap that buys time; we usually deprecate it once the AIS route is live for the relevant accounts.

Native export as a fallback

UKRSIB business exposes statement export inside the app (the on-device share for posted transactions). For one-off reconciliations this is enough; it is not a wire for any continuous integration and we do not pretend otherwise.

On most UKRSIB business builds we put AIS underneath the read side and the authorized interface layer alongside it for the company's UAH payment-document queue and FX applications. The interface layer is where the joint-actions rule and the QES handshake get to behave the way the bank actually behaves, which a generic AIS adapter does not understand.

Resolution 80, consent scope, and what we keep clean

Resolution No. 80, adopted by the NBU Board on 25 July 2025 and effective from 1 August 2025, sits under the Law of Ukraine "On Payment Services" and aligns Ukraine with PSD2 mechanics: standardized APIs, strong customer authentication, payment-initiation rules, and explicit client consent for both data and payment scopes. In March 2026 the NBU simplified the list of mandatory details a PISP must include when initiating a payment, which reduces friction on the write side for any future PIS work over this app.

Consent in this regime is the company's, granted by an authorized signatory of the legal entity or by the individual entrepreneur themselves, and is revocable. We carry consent identifiers and expiry through every call, refresh inside the published window, and stop the loop on the first revocation rather than letting a stale token quietly fail. For interface-integration work outside AIS scope, the company signs an authorization letter and our build runs under that — calls are logged, data is minimized to what was asked for, NDAs are in place where the customer needs them.

Request shape we hand over

Illustrative — the exact paths firm up against the bank's published AIS endpoints during the build. Berlin Group NextGenPSD2 is the shape Resolution 80 points at, so this is what an AIS call against UKRSIBBANK looks like in practice:

# 1. Consent: company grants AIS scope (accounts + balances + transactions)
POST https://obapi.ukrsibbank.example/v1/consents
Authorization: Bearer <tpp_oauth_token>
TPP-Redirect-URI: https://your-app.example/callback
PSU-IP-Address: 198.51.100.7
Signature: keyId="tpp-cert-sn",algorithm="rsa-sha256",headers="...",signature="..."

{
  "access": { "accounts": [{"iban":"UA213223130000026007233566001"}],
              "balances": [{"iban":"UA213223130000026007233566001"}],
              "transactions": [{"iban":"UA213223130000026007233566001"}] },
  "recurringIndicator": true,
  "validUntil": "2027-05-30",
  "frequencyPerDay": 4,
  "combinedServiceIndicator": false
}

# 2. Pull balances (UAH and FX surfaced on the same call shape)
GET /v1/accounts/{accountId}/balances
Consent-ID: c1c3...e1
→ { "account": {"iban":"UA21...", "currency":"UAH"},
       "balances":[{"balanceType":"interimAvailable",
                    "balanceAmount":{"currency":"UAH","amount":"184502.37"},
                    "referenceDate":"2026-05-30"}]}

# 3. Pull a statement window
GET /v1/accounts/{accountId}/transactions?dateFrom=2026-05-01&dateTo=2026-05-30&bookingStatus=booked
Consent-ID: c1c3...e1

# 4. Outside AIS: the interface layer mirrors the QES-signed document queue
GET /internal/ukrsib/companies/{companyId}/payments?state=awaiting_sign
→ [{ "doc_id":"P-2026-05-30-0117", "currency":"UAH", "amount":"42000.00",
        "purpose":"...", "signers_required":2, "signers_collected":1,
        "joint_action":true }]

What we hand over

• OpenAPI specification for the read side (AIS-mapped: accounts, balances, statements) and for the company-context interface layer (UAH payment documents, joint-actions, FX applications, session events).
• Auth and protocol report. The OAuth2 flow for the AIS leg, the request-signing details we use against the bank's TPP gateway, and the separate session/cookie chain for the interface-integration leg with the QES signing handshake written out step by step.
• Runnable source. Python and Node.js clients for every endpoint above, with retry, idempotency keys on payment-document calls, and the company-context selector wired through.
• Automated tests running against a sponsor sandbox or a consenting company account that we set up with you as part of the build, covering the multi-company switch, the joint-actions branch, and a QES-expiry case.
• Interface documentation mapping each integration endpoint back to the exact UKRSIB business screen and state it represents, so a future engineer on your side can re-validate against the live app.
• Compliance pack. Consent records, data-minimization notes, retention guidance, and the authorization letter template — sized to whether the deployment sits on the AIS rail, the interface rail, or both.

Build notes that actually matter on this app

Four things we account for on every UKRSIB business build because they bite if you do not. None of these are barriers to start — they are part of how we scope and how we onboard with you.

• QES is a separate signing flow, not the consent. The OAuth2/AIS consent grants read access; releasing a UAH payment document still requires a Qualified Electronic Signature attached by the signatory, and the in-app QES can be issued through the DIIA.Signature route. We model the document state machine so a payment is never assumed "sent" because the API call returned 200 — it is only released when the QES count matches the joint-actions rule.
• Multi-company context is per session, not per token. A single authorized user routinely holds rights at more than one legal entity, and the app exposes a company switcher for that. We pin every read and every payment-document write to a company-context identifier so balances, statements, and signing rights never cross legal entities. Tests cover the switch.
• UAH and FX use different write flows. The app generates and signs FX sale applications, and lets the company review FX purchase / conversion applications, on screens that are distinct from the UAH payment-document queue. We expose those as their own endpoints in the integration so an FX request is never accidentally constructed as a UAH payment.
• Consent and certificate freshness are watched by the integration, not the customer. The Resolution 80 consent has a validity window; QES certificates expire and the app already pushes a notification on expiry. The maintenance side of our build polls both clocks, refreshes the consent inside the published window, and raises a structured warning before a certificate lapse — so the customer learns about the problem from us, not from a failed payment release.

Interface evidence

Screens used during the surface mapping. Click to enlarge.

Sources we read for this mapping

Surface mapping is from the Play and App Store listings for com.ukrsibbank.ukrsibbusiness and the UKRSIB business user manuals published by the bank, cross-checked against the NBU's open-banking page and a recent industry write-up. Regulatory dates are quoted from the NBU and from law-firm briefs published after Resolution 80.

• National Bank of Ukraine — Open Banking page
• UKRSIBBANK — UKRSIB business Internet Banking System (corporate clients)
• UKRSIBBANK — UKRSIB business mobile application user manual (PDF, EN)
• Lexology / Asters — Open Banking launches in Ukraine (Resolution 80 explainer)

OpenBanking Studio · integration desk mapping, 2026-05-30.

Peer apps in the same integration neighborhood

Same-country, same-customer-shape apps an integrator usually wants normalized into one schema alongside UKRSIB business. Plain text, not links — cross-references are added by the build only where a sibling page exists.

• Privat24 Business (PrivatBank). Largest SME footprint in the country; UAH and FX accounts, payment documents, FX operations.
• Monobank for Business. Universal Bank's neobank surface for sole proprietors and SMEs; lighter document workflow, strong push and notification model.
• Oschad 24/7 Business (Oschadbank). State-bank corporate channel covering accounts, payments and tender deposits.
• Raiffeisen Business Online (Raiffeisen Bank Aval). European-group corporate banking with the standard balance, statement and payment-signing surfaces.
• FUIB Business (PUMB). Mid-market corporate channel from First Ukrainian International Bank.
• Sense Bank for Business. Successor surface of the former Alfa-Bank Ukraine corporate channel.
• Pravex Business (Pravex Bank, Intesa Sanpaolo). Smaller Italian-group corporate channel with a similar QES-driven document model.
• ProCredit Mobile Business. Niche SME-focused bank with a comparable payment-document and FX-application surface.

Questions an UKRSIB business integrator asks

Does the AIS route reach both UAH and FX accounts on UKRSIB business?

Yes. Under NBU Resolution 80 the AIS scope covers accounts held by the legal entity or individual entrepreneur regardless of currency, so the same consent grants balance and statement access for the UAH account and any FX account the company holds at UKRSIBBANK. Currency is carried per-account in the response, not as a separate consent.

Where does the QES (qualified electronic signature) sit relative to a payment-initiation integration?

QES is the signing step on a UAH payment document, not the consent itself. We model it as a separate flow after PIS authorization: the document is generated and submitted, then a QES (issued via the bank or DIIA.Signature) is attached to move it from drafted to signed. Joint-actions documents collect more than one QES before they are released.

Can the integration follow the multi-company switching shown in the app?

Yes. A single authorized user may have access to several companies; we expose a company-context selector on the integration side and scope every subsequent call to that company so balances, statements and signing rights do not cross-contaminate.

Are FX sale and purchase applications handled through the same endpoint as UAH payments?

No. The app keeps these on a distinct flow (generation, signing, and submission of FX sale or purchase / conversion applications), and the integration mirrors that. We expose separate endpoints for FX application lifecycle so they are not conflated with UAH payment documents.

If you want the read side on the AIS rail, the QES-signed UAH payment-document queue mirrored through authorized interface integration, and an OpenAPI spec plus runnable Python and Node.js source for both — that is the typical UKRSIB business build, and it ships in one to two weeks. Source-code delivery starts at $300 and is paid only after delivery once you are satisfied; if you would rather not host anything, the same endpoints run on our infrastructure on a pay-per-call basis with no upfront fee. Tell us the company name, the data and operations you actually need, and we take it from there — start at /contact.html.