Account, payroll and currency data inside Uzum Business

Every corporate account and card a company holds with Kapitalbank lands in one section of Uzum Business, and that section is mirrored between the mobile app and the internet bank — a payment drafted on the web turns up in the app to be signed, and back again. That shared back end, not the screen, is what an integrator actually wants to reach. A finance team using this app sees balances across all accounts, a full incoming/outgoing history, generated statements, interbank and government transfers, SWIFT and currency-contract operations, and a payroll run that credits employees the same day. All of it is per-organization, behind an authenticated session.

The bottom line for this app: the data is rich and well-structured, but it sits behind a corporate login with signing and step-up authentication, and there is no PSD2-style mandated open interface in Uzbekistan to ride. So we reach it the way a consenting corporate user does — through an authorized session against the same back end the app and internet bank share — and normalize what comes back into something a third-party system can query.

What sits behind a corporate login

These are the surfaces the app exposes to a signed-in business, mapped to where each one originates and what a consuming system would do with it.

Authorized routes into the account data

Three approaches genuinely apply to this app. Each is run under the corporate client's authorization, with access arranged as part of the work.

Authorized session integration (protocol analysis)

We study the traffic between the app, the internet bank and their shared back end on a consenting account, then implement clean clients for the calls that carry the data above. Reachable: effectively everything a signed-in finance user sees. Effort: medium. Durability: tied to the front end, so we re-validate when Kapitalbank changes it. Setup: we work against a corporate login or test account you provide during onboarding.

User-consented credential access

Where the goal is an ongoing sync for one organization, we drive the corporate's own consented session, scoped to the accounts they name. This is the path most affected by the Central Bank's April 2026 verification tightening, so we build the step-up and biometric-unlock handling in from the start rather than bolting it on.

Native statement export

The app and internet bank generate statements a user can pull directly. For bulk historical data this is the lowest-touch option — coarser than the live feed, but stable and cheap to maintain.

For Uzum Business we would build the ongoing integration on the consented corporate session, since that is the only route that reaches payroll, signing state and currency contracts together, and keep native statement export wired alongside it for the heavy historical backfills that don't need to be live.

What lands at handover

• OpenAPI specification covering the endpoints we implement — accounts, history, statements, payments, currency operations, payroll.
• Protocol and auth-flow report: the login, access-code/biometric session, token lifecycle and signing chain as they behave on this app.
• Runnable source in Python and Node.js for the key calls, with a normalized model that reconciles a payment whether it was signed in the app or on the web.
• Automated tests against recorded responses, including the FX/contract shape and the step-up path.
• Interface documentation a developer can follow without us.
• Compliance and retention notes tied to Uzbek bank-secrecy and consent rules.

A statement pull, sketched

Illustrative shape only — exact paths, headers and the signing step are confirmed during the build against a consenting account, not asserted here.

# 1) Establish an authorized session (access-code / biometric unlock on device)
POST /auth/session
  { "login": "<corp-user>", "device_token": "<bound-device>" }
-> 200 { "session": "...", "expires_in": 600, "step_up": false }

# step_up=true -> pause, satisfy OTP / biometric, resume (CBU rules, Apr 2026)

# 2) List the organization's accounts
GET /accounts            Authorization: Session ...
-> [ { "account_id": "UZxx…", "currency": "UZS", "balance": "..." }, ... ]

# 3) Pull a dated statement for one account
GET /accounts/{account_id}/statement?from=2026-05-01&to=2026-05-31
-> { "lines": [
       { "ts": "2026-05-04T09:12Z", "dir": "out",
         "counterparty": "...", "amount": "...", "purpose": "...",
         "doc_state": "signed" }, ... ] }

# normalize -> { account, currency, balance, lines[] }; FX contracts modeled separately

Where integrators put this to work

• An accounting platform pulling dated statements and history across every corporate account for automated reconciliation.
• An ERP posting transfers to other banks and government bodies, then reading back the draft/signed/sent state.
• A payroll or HR system pushing a run and confirming same-day credit per employee.
• A treasury tool tracking UZS balances next to SWIFT transfers and open currency contracts.

Authorization under Uzbek bank-secrecy and data law

This is a Uzbek bank, so the framework is Uzbek. The Law on Personal Data, No. ZRU-547, has been in force since 1 October 2019 and makes the data subject's consent the central basis for processing and for any disclosure to a third party. Account information also sits under the Law on Bank Secrecy, which binds the bank to protect it; a 2025 financial-sector decree reportedly adds cyber-protection liability on top. There is no mandated open-banking API regime in Uzbekistan comparable to PSD2 — the Central Bank's published roadmap puts fintech and a sandbox on the 2025–2028 agenda rather than a live mandate. The dependable basis for our work is therefore the corporate client's own authorization for its own data. We operate authorized and logged, take only the fields an integration needs, keep consent records, and sign an NDA where the work touches live accounts.

Engineering notes we plan around

Two things about this app shape the build, and we handle both rather than hand them to you as conditions.

• Shared mobile/web state. Because a payment created on the web appears in the app to be signed and vice versa, there is one record moving through a sign-state machine, not two parallel feeds. We model that machine — draft, signed, sent — so a status read is accurate no matter which channel acted, and a batch sign reconciles to the right set of payments.
• Step-up authentication. The Central Bank's verification rules from 22 April 2026 layer biometrics, liveness and OTP onto digital banking. We design the session around the access-code and biometric unlock the app already uses, so a re-auth prompt is a checkpoint the sync survives, not a failure.
• FX and contract fields. SWIFT transfers and currency contracts carry data a domestic UZS payment does not. We give them their own normalized object so neither shape is bent to fit the other.

Staying current

Front ends move, and a regulator that has just tightened verification will keep adjusting. We re-validate the integration when Kapitalbank ships app or internet-bank changes, and we watch the Central Bank's published changes so the auth flow stays compliant. A short maintenance pass is part of how we keep a delivered integration working rather than a one-time drop.

Screens we worked from

Other Uzbek business-banking apps in the same picture

A company rarely banks in one place, so an integration desk usually ends up mapping several of these together. Names only, no ranking.

• TBC UZ: Business — business app from Uzbekistan's first digital bank; holds accounts, transfers, loans and monitoring data.
• Anorbank — settlement, business cards, deposits and transfers for companies through its app.
• Hamkorbank — long-standing bank serving both individuals and businesses, with corporate account and payment data.
• Octobank — fintech-leaning entrant with modern corporate digital banking.
• Ipak Yuli — business banking with accounts, payments and statements in-app.
• National Bank of Uzbekistan (NBU) — state bank with a small-business line and corporate account data.
• Aloqabank — corporate accounts, payments and payroll services via its digital channel.
• Uzum Bank — the retail sibling in the same group, holding personal account and card data.

Questions integrators ask about this one

Can you reach payroll and same-day salary status, not just balances?

Yes. The payroll surface carries per-employee payout lines, the sign state of the run, and the credit confirmation Kapitalbank reports back. We pull those as structured records, not just an account total, so an HR or accounting system can match each salary line to the employee and the settlement.

How do the April 2026 Central Bank verification rules affect a Uzum Business integration?

The Central Bank of Uzbekistan tightened digital-banking verification from 22 April 2026, adding biometric checks, liveness and OTP step-up, per reporting on the rule. We design the session flow around the access-code and biometric unlock the app already uses, so a step-up prompt pauses and resumes the sync instead of breaking it.

Do currency contracts and SWIFT transfers come through the same integration as domestic payments?

They share the pipeline but not the schema. SWIFT transfers, currency exchange and currency-contract records carry fields a domestic UZS payment does not, so we model FX and contract data as its own object and normalize it alongside the local-payment feed rather than forcing one shape.

Can the build run without putting live corporate credentials at risk?

Yes. We work against a consenting corporate account or a test login arranged with you, every call is logged, and we keep only the fields the integration needs. Bank-secrecy and consent obligations under Uzbek law shape that handling from the first call, with an NDA in place where the work touches real account data.

What we checked

We read the Kapitalbank corporate page for Uzum Business and the app's store listing for the feature set and identifiers, then cross-read the Central Bank of Uzbekistan's regulatory roadmap, recent reporting on the April 2026 verification rules, and Uzbekistan's personal-data framework for the authorization side. Reviewed June 2026 by the OpenBanking Studio integration desk.

• Kapitalbank — Uzum Business corporate mobile bank
• Central Bank of Uzbekistan — 2025–2028 regulation roadmap
• The Paypers — Uzbekistan digital-banking verification from April 2026
• DLA Piper — Uzbekistan data-protection law (ZRU-547)

Two ways to take delivery, both with the price stated up front. You can have the runnable source built for your own stack — from $300, paid only after we deliver and you're satisfied it works against your accounts — or call our hosted endpoints and pay per call with nothing upfront. Either way the cycle is one to two weeks, and you start by telling us the app and what you want out of its data; access and the compliance paperwork are arranged with you. Tell us what you need from Uzum Business and we'll scope it.

Mapping reviewed 2026-06-07