Getting account and transfer data out of UCB One

United Commercial Bank's UCB One puts linked accounts, debit and credit cards, dated statements, and four transfer rails — BEFTN, NPSB, RTGS and MFS wallet payouts — behind a single authenticated session. For a fintech, an accounting tool, or a lender that needs that data in a normalized shape, the question is not whether it exists but how to read it cleanly and keep reading it as the app changes. This page maps what is reachable, the authorized route we use, and what the finished integration looks like.

The bottom line: nearly everything a UCB One user sees after logging in is structured, per-user, server-held state — exactly the kind of data a third party wants to query or sync. The route that returns it live is authorized protocol analysis of the app's own authenticated traffic, run against a consenting account. Where document-level detail is enough, the app's built-in statement and certificate downloads cover it at lower effort. We build for both and keep the design ready for Bangladesh Bank's consent API once it lands.

What sits behind a UCB One login

Each row below is a real surface in the app, mapped to where it originates and what an integrator typically does with it.

Routes in, and which one we run

Three approaches genuinely apply to UCB One. They differ in what they return, how durable they are, and what we set up to operate them.

Authorized interface integration (protocol analysis)

We work against a consenting account, capture and document the token and session chain the app uses, and build a normalized client over the surfaces above. This is the route that returns live balances and transfer status. Effort is moderate; durability is tied to the app's releases, which we account for in maintenance. Access to a consenting account or a sponsor environment is arranged with you during onboarding.

Native export

UCB One already generates statement and certificate downloads. We parse and normalize those into the same schema as the live client. Low effort, durable, but coarse — document granularity, not a real-time feed. It pairs well with the live route for historical backfill.

Regulated open-banking consent (forthcoming)

Bangladesh Bank has signalled Open Banking Guidelines and a standardized API, with a working committee and a 2026 target reported in the press. When that issues, a consent-based route comparable to AIS elsewhere becomes available. It does not exist as a usable channel yet, so we treat it as something to design toward, not to wait on.

For UCB One as it stands today, the authorized-traffic route is the one we would actually build on, because it is the only one that returns live account and transfer state; the app's own downloads fill in history at low cost, and the consent API is wired into the design so it can take over the dynamic surfaces the day Bangladesh Bank publishes it.

What lands at the end of the build

The deliverables are concrete and tied to UCB One's actual surfaces, not a generic package.

• An OpenAPI/Swagger specification for the normalized endpoints — accounts, balances, card register, dated statements, transfers, eLoan status.
• A protocol and auth-flow report documenting the OTP-to-token exchange, the bearer/refresh chain, and how the session ages out mid-pull.
• Runnable source for the key calls in Python and Node.js, structured around the rail-tagging the transfer data needs.
• Automated tests run against a consenting account, covering balance reads, statement ranges, and a transfer-status round trip.
• Interface documentation plus consent and data-retention guidance written against the Personal Data Protection Ordinance.

A statement pull, sketched

The paths and host below are illustrative — the real endpoints and field names are confirmed during the build against a consenting account, not lifted from any published schema. The shape is what matters: authenticate, list accounts, read a dated statement, recover from an aged token.

# Illustrative UCB One client: balances + a dated statement.
import requests

BASE = "https://unet.ucb.com.bd"            # authenticated app host (observed)
s = requests.Session()

# 1) Auth. UCB One does a device-bound exchange after OTP, returning
#    a short-lived bearer plus a refresh token.
auth = s.post(f"{BASE}/auth/token", json={
    "username": USER, "device_id": DEVICE, "otp": OTP,
}).json()
s.headers["Authorization"] = f"Bearer {auth['access_token']}"

# 2) Linked accounts and live balances (the dashboard surface).
accounts = s.get(f"{BASE}/accounts").json()["accounts"]

# 3) Per-account statement over a date range; mirrors the in-app download.
def statement(acct, frm, to):
    r = s.get(f"{BASE}/accounts/{acct}/statement",
              params={"from": frm, "to": to})
    if r.status_code == 401:                # token aged out mid-pull
        refresh(s, auth["refresh_token"])
        return statement(acct, frm, to)
    r.raise_for_status()
    # normalized rows: {date, amount, rail, counterpart, ref, status}
    return r.json()["transactions"]
      

Keeping the feed honest

Real-time balances and a cached statement document age differently, and the integration treats them differently. Live reads carry their fetch timestamp; statement downloads are stamped with the period they cover. Transfers across BEFTN, NPSB and RTGS settle on different clocks, so a record's status is read from the rail, never assumed from the request time. We also pace requests to match how a normal session behaves, so the pull stays well inside sensible limits rather than hammering the host.

Consent and where Bangladesh's rules stand

Bangladesh now has a dedicated data law. The Personal Data Protection Ordinance 2025 was approved on 9 October 2025 and gazetted on 6 November 2025 (per The Daily Star), and it makes the individual the owner of their personal data, requiring consent that is freely given, specific, informed and revocable. That is the frame our consent handling is written to: scoped access, an explicit revocation path, erasure on request, and data minimization so we read only the surfaces the engagement needs.

The open-banking rulebook itself is still being drafted — guidelines and a standardized API are reported as a 2026 goal, not a settled regime — so we do not lean on obligations that have not been published. The dependable basis is the account holder's own authorization. Everything we run is authorized, logged with consent records, and covered by an NDA where the client needs one.

Engineering realities we account for

These are the things that actually shape a UCB One build, handled on our side rather than handed to you as conditions.

• The app spans four transfer rails with separate state machines. We model BEFTN, NPSB, RTGS and MFS payouts independently, so a pending RTGS instruction is never reported as a settled NPSB transfer and reconciliation stays correct.
• UCB rebuilt onto a microservices backend and reported moving to Oracle's Open API 14.7 (per the Business Standard). Internal endpoints and token flows shift between releases, so we schedule a recheck of the captured flows after each app update and version the client against them.
• eLoan surfaces credit-scoring insight and Cash by Code issues one-time withdrawal codes. We classify both as sensitive, keep them out of logs, and gate them behind the consent scope rather than pulling them by default.
• MFS payouts route through third-party operators (upay, bKash, Nagad, Rocket), each with its own response shape and timing. We map each operator's payload so the normalized transfer record is consistent regardless of which wallet was paid.

Screens we worked from

The UCB One store screenshots, for reference. Select one to enlarge.

Other Bangladeshi banking apps in the same orbit

A unified integration usually has to read more than one app. These are the peers that come up alongside UCB One; the names are listed for context, not ranked.

• bKash — BRAC Bank's mobile financial service, holding wallet balances, send-money and merchant-payment history at large scale.
• Nagad — the Bangladesh Post Office wallet, with cash-in/out, send-money and recharge records per user.
• Rocket — Dutch-Bangla Bank's MFS, carrying transfers, bill payments and ATM cash-out history.
• Nexus Pay — Dutch-Bangla Bank's app banking front end over accounts and cards.
• CellFin — Islami Bank's app with EFT/NPSB transfers, add-money and QR payments.
• Astha — BRAC Bank's retail app for accounts, cards and QR-based transactions.
• City Touch — City Bank's internet-banking app over balances, statements and transfers.
• MTB Neo — Mutual Trust Bank's digital banking app for accounts and payments.
• upay — UCB's own MFS wallet, holding payout and bill records that often sit next to UCB One in the same group.

Questions integrators ask about UCB One

Can you keep UCB One's BEFTN, NPSB and RTGS transfers as separate records, or do they arrive as one stream?

Separate. Each rail carries its own status model and settlement timing, so the normalized client tags every transfer with the rail it ran on and tracks its state independently. A pending RTGS is never collapsed into a settled NPSB entry.

Does the work cover the eLoan credit-scoring view and Cash by Code, or only plain account data?

Both are reachable from the authenticated session. eLoan exposes score-derived insight and Cash by Code issues short-lived withdrawal codes, so we treat those as sensitive: minimized, kept out of logs, and only surfaced where the consent scope covers them.

Bangladesh's open-banking rules are not finalized yet. Does that hold up a UCB One integration?

No. The dependable basis today is the account holder's own authorization, which is what the build runs on. Bangladesh Bank has signalled Open Banking Guidelines and a standardized API for 2026; we design the consent flow so it can switch onto that route once it issues, without a rewrite.

How quickly can you stand up a UCB One balance-and-statement client?

A focused client over accounts, balances and dated statements lands in one to two weeks, including the auth-flow report and tests against a consenting account. Wider coverage such as transfers and eLoan extends the same build rather than restarting it.

How this brief was put together

Drafted against UCB One's Play Store listing and the launch coverage from June 2026, cross-checked against Bangladesh Bank's open-banking signalling and the 2025 data ordinance. UCB's move to a microservices backend and ISO/IEC 27001:2022 certification are taken from the Business Standard report; the data-law dates from The Daily Star. Primary sources opened:

• UCB One on Google Play — feature list and package ID.
• The Business Standard — UCB's microservices banking platform.
• The Business Standard — Bangladesh open-banking plans.
• The Daily Star — Personal Data Protection Ordinance 2025.

Mapping compiled by the OpenBanking Studio integration desk · 19 June 2026.

Starting a UCB One build

Source-code delivery starts at $300: you receive the runnable client, the OpenAPI spec, the auth-flow report, tests and interface docs, and you pay only after delivery once it does what you need. If you would rather not host anything, the same UCB One surfaces are available as a pay-per-call hosted API with no upfront fee. Either path runs in one to two weeks. Tell us the app and what you want out of its data at our contact page, and access and compliance are arranged with you from there.

Mapping reviewed 2026-06-19.