Reaching Tez (Tezbank) account and transaction data

A Tez account carries a running card balance in som, a stream of posted card transactions, a Xazina savings pot accruing interest, and a cashback ledger that the app pays out as real money rather than points. The integrator's problem is rarely "can I see one balance" — it is keeping a copy of that transaction stream accurate over days and weeks as posts settle, cashback drops in, and transfers clear. That is the angle this brief takes: read the consented account state, then keep it reconciled with what the customer sees in the app.

Tez is the neobank Fintech Farm built with Hamkorbank, a licensed Uzbek bank, according to reporting around its 2025 launch. So the data sits behind a regulated banking backend, reached on the rails that move money in Uzbekistan — Uzcard, Humo, the Instant Payments system and Visa. We work from the customer's own authorized view of that backend, not from the rails, and deliver code that reads and normalizes it.

What Tez holds, and where it surfaces

Each row below is a real surface the app presents to its user. Figures the app advertises — a credit limit up to 50,000,000 som, 62 interest-free days, Xazina at 12% a year — are quoted here as the app describes them, not independently verified.

Getting to the data — the routes that fit Tez

Three routes are realistic here. They are not mutually exclusive; the right build often leans on one and keeps a second as fallback.

User-consented account access

The customer authorizes reading their own Tez account, and we read exactly the surfaces they see. Reachable: every domain in the table above. This is the durable choice for a regulated banking backend — it ages well because it follows the same session the app does. We arrange the consent flow and the test account with you during onboarding; you do not chase down credentials before we begin.

Authorized interface integration / protocol analysis

We map the app's own client-to-server traffic — the auth handshake, the token lifecycle, the transaction and savings endpoints — and implement a clean client against them under your authorization. Reachable: the same data, with tighter control over paging and field selection. Effort is higher up front; durability depends on how often Tez revises its client, which is why the deliverable includes a contract test that flags drift.

Native export as a fallback

Where a statement or card extract is available to the user, we parse it as a backstop for backfill and for cross-checking the live feed. It is not a primary feed — it is how we seed history and verify the read is complete.

For most Tez work, consented account access is the spine and the protocol-analysis client is what makes paging and freshness controllable; export fills in history. We would build it in that priority for this app.

What lands in your repo

The headline deliverable is running code, not a binder. Concretely, for Tez:

• A runnable client in Python or Node.js that authenticates, lists transactions with cursor paging, and pulls card, savings and cashback state — the endpoints you would actually call in production.
• A normalization layer that maps Tez's som amounts, transaction types and cashback credits into a stable schema, with cashback tagged apart from spend.
• A reconciliation routine that compares the synced ledger against the latest read and the app's notification hints, so a missed or re-posted line is visible rather than silent.
• An automated test harness covering the auth flow, paging edges and the field contract, so a change in Tez's client shows up as a failing assertion.
• An OpenAPI / auth-flow document describing the surfaces and the OAuth-or-token chain as it actually behaves here.
• Interface documentation and short data-retention guidance written against the consent records.

The OpenAPI spec and the auth-flow write-up matter, but they describe code that already runs in your hands first.

A reconciliation call, sketched

Illustrative, and confirmed in shape during a build — not copied from Tez's source. It reads the recent transactions on a cursor, then folds them into a local ledger keyed by the bank's own transaction id so a re-read does not duplicate rows.

# refresh a Tez account: read recent activity, reconcile locally
session = tez.authorize(consent_token)          # user-consented session

cursor = store.last_cursor(account_id)          # resume where we stopped
page = session.get_transactions(
    account_id=account_id,
    since_cursor=cursor,
    limit=100,
)
# page -> { items: [...], next_cursor, balance: {available, credit_free} }

for tx in page["items"]:
    record = {
        "id":        tx["txn_id"],               # bank id = dedupe key
        "amount":    tx["amount_minor"],         # som, minor units
        "kind":      classify(tx["type"]),       # purchase | topup | transfer | cashback | utility
        "rail":      tx.get("rail"),             # uzcard | humo | instant | visa
        "merchant":  tx.get("merchant"),
        "tags":      tx.get("tags", []),
        "posted_at": tx["posted_at"],
    }
    store.upsert(account_id, record)             # keyed on txn_id

store.set_balance(account_id, page["balance"])
store.set_cursor(account_id, page["next_cursor"])

# notification hint? pull again before the scheduled window
if inbox.has_money_event(account_id):
    schedule.refresh_now(account_id)

Authorization and the CBU rulebook

Hamkorbank is supervised by the Central Bank of the Republic of Uzbekistan, and Uzbekistan's payments law was amended in late 2024 (the ZRU-964 changes, in force from 22 December 2024 per the Central Bank) to tighten information-security obligations. Personal data sits under Uzbekistan's data-protection law. None of that is a wall to clear before work starts — it is the posture we build to. Access stays user-consented and documented; we log each read against the consent it relied on, scope the consent to the domains a given use case needs, and honor revocation by stopping the sync. We retain the minimum fields the integration needs and nothing decorative. NDAs are signed where the engagement calls for one.

Build notes specific to Tez

Two things about Tez change how the code is written.

First, cashback is money, not points. Because Tez credits it to the account as cash, it appears in the same stream as purchases and can arrive after the purchase that earned it. We model cashback as a distinct credit that references its originating transaction, so reporting can show earned cashback and net spend without one contaminating the other, and so a late credit reconciles cleanly against an already-synced purchase.

Second, money moves on more than one rail. A single Tez account touches Uzcard, Humo, the Instant Payments system and Visa, and the same transfer can look different depending on the rail it cleared on. We tag each line with the rail it settled on during normalization, which keeps phone-number P2P, card-to-card top-ups and Visa purchases from collapsing into one undifferentiated "transfer" bucket. Access to a consenting account or a sponsor test profile is arranged with you as part of onboarding, so the build runs against real shapes rather than guesses.

Keeping the ledger in sync

Tez surfaces card posts and incoming transfers as in-app notifications. We use that: a notification is a hint to refresh sooner than the scheduled read, while the cursor read remains the source of truth. The consent has a finite lifetime, so the sync re-reads on a window tied to that lifetime instead of waiting for a read to start returning empty. The reconciliation routine is what catches the awkward cases — a transaction that re-posts with a new status, a cashback credit that lands days later — and surfaces them as a diff against the stored ledger rather than letting the copy quietly drift from the app.

Where Tez sits among Uzbek money apps

Tez competes in a crowded Uzbek market, and a buyer integrating one of these usually wants several read the same way. Named neutrally:

• Uzum Bank — digital bank inside the Uzum e-commerce ecosystem; holds accounts, installments and marketplace-linked activity.
• TBC UZ — the Georgian-backed digital bank, among the largest in Uzbekistan by downloads; accounts, deposits and payments.
• Payme — payments app in the TBC ecosystem; transfers, bills and a transaction history.
• Click — long-running payments super-app; wallet balance, P2P and a wide biller catalog.
• Anorbank — retail digital bank; cards, deposits and transfers.
• Alif — fintech offering installments and banking services with its own transaction records.
• Xazna — consumer finance app holding card and payment data.
• AVO Bank — digital bank with card and savings products.
• Hamkor — Hamkorbank's own established mobile bank, alongside Tez under the same group.

The shared trait is per-user balances and a transaction stream behind an authenticated session. A unified integration normalizes them onto one schema so a downstream product does not care which app a line came from.

Screens we worked from

Public Play Store screenshots, used to read the app's surfaces. Tap to enlarge.

Questions integrators ask about Tez

Tez balances are in UZS and it rides Uzcard, Humo and the Instant Payments rail — which of those can an integration actually read?

What you read is the customer's own view inside Tez: card balances, posted card transactions, the Xazina savings account, cashback credits and transfer history, all denominated in UZS. The underlying rails (Uzcard, Humo, Instant Payments, Visa) are how the money moves; the integration does not touch the rail directly, it reads the consented account state the app already presents to the user, then maps each line back to the rail it settled on.

How does the Tez feed stay current — does the app push transaction events, or do you poll for them?

We design around how Tez itself notices money movement. Card posts and incoming transfers surface as in-app notifications, so the practical model is to read the recent-transactions surface on a short cursor and treat each notification as a hint to refresh sooner. We anchor a freshness window to the consent's validity and re-read before it lapses, so the synced ledger does not drift from what the customer sees in the app.

Hamkorbank is a licensed Uzbek bank — does the Central Bank framework get in the way of consented access?

It shapes the work rather than blocking it. Hamkorbank operates under the Central Bank of the Republic of Uzbekistan, and the 2024 amendments to the payments law raised the bar on information security. We keep access user-consented and documented, log what was read against the consent record, and minimize the fields we retain. The regulatory posture is something we account for in the build, not a form we hand you to fill in.

Can you separate Tez's cashback ledger from ordinary card spend?

Yes. Tez treats cashback as real money credited to the account rather than points, so it lands as its own transaction type. We tag those credits distinctly from purchases, top-ups and transfers during normalization, which lets you report earned cashback, effective discount rate and net card spend as separate figures instead of a single muddied balance.

One engagement gets you running code for Tez in one to two weeks. Take the source-code route from $300 — runnable client, normalization, tests and docs delivered to your repo, paid only once you have it and you are satisfied — or use the hosted API and pay per call with nothing up front. Tell us the app and what you want out of its data, and we handle the access and compliance from there: Start a Tez integration

Last checked 2026-06-07