What a SmartBank By NUBank account holds — and the authorized way to pull it

Behind SmartBank By NUBank sits a Sarab Tech core-banking backend that keeps every account, statement line and saved payee server-side — none of it lives only on the handset. That is the part worth integrating. Treat the app's transaction history less as a screen and more as a replayable feed: each entry has a stable reference, a posting time and a counterparty, which means a new account can be backfilled from the start and then followed live without the two passes fighting each other. The brief below maps that feed, names the authorized way to consume it, and says exactly what we hand over.

One thing to be clear about up front. This is not the Brazilian Nubank. The package id is tech.sarab.nubank per its store listing, and “NUBank” here is the institution this white-label SmartBank build was branded for, published by the studio Sarab Tech.

Bottom line: the data is rich and clearly per-user, and the dependable way to it is the account holder authorizing us to work the app's own interface. Where the bank behind this deployment turns out to be a licensed participant in a formal open-finance scheme, a regulated read can sit alongside that. The route we would actually lead with is protocol analysis of the mobile client, because it reaches everything the user can see and does not wait on a scheme rollout.

The data inside a SmartBank account

Surfaces are taken from the published feature list on the Play and App Store pages and the SmartBank product page. Field names are confirmed against this deployment during the build, not assumed.

How we'd reach it

Three routes apply here. They are not equal, so the recommendation is in the prose, not a label.

Protocol analysis of the mobile client (recommended)

The app authenticates a device, holds a short-lived token, and reads accounts, statements and transactions from the Sarab Tech backend. We capture that token flow against a consenting account, map the request and response shapes, and rebuild them as clean client code. Reach is everything the user sees. Effort is moderate. Durability is tied to the app version, so we re-validate when the client updates — that maintenance is ours to carry, not yours to police.

Account-holder-consented live access

For a continuous feed rather than a one-off pull, the same authorization is held open and refreshed so the stream keeps flowing. This is the path for ongoing sync into a ledger or dashboard.

Regulated open-finance read (conditional)

If the issuing institution is a licensed bank inside a formal scheme, an account-information read can run through that scheme's consent and infrastructure instead of the app surface. It is the most durable option and the most consent-governed — but it depends on the issuer being identified and in scope, which the public listing does not settle. We confirm it during onboarding.

The calls

Illustrative shape of the work, not a copy-paste contract. Exact host, paths and field names are pinned during the build against this NUBank deployment.

# 1) Device authenticates -> short-lived bearer + the account list
POST  {tenant_host}/auth/login
      { device_id, credential }
  ->  { token, refresh, accounts: [ "AC-1029", "AC-7741" ] }

# 2) Dated statement, exactly like the in-app date picker
GET   {tenant_host}/accounts/AC-1029/statement?from=2026-01-01&to=2026-03-31
      Authorization: Bearer {token}
  ->  { page: 1, has_more: true,
        entries: [
          { ref:"TX-88f0", posted_at:"2026-01-04T09:12Z",
            amount:-42.50, currency:"AED", kind:"transfer",
            counterparty:{ type:"saved_payee", name:"Layla H." } }
        ] }

# 3) Ingestion: each entry replayed onto a stream keyed by `ref`.
#    A backfill window that overlaps the live tail lands on the same
#    keys, so the two passes merge into one clean ledger instead of two.

Transfers arrive in three shapes — own-account, saved-payee-by-name, and QR scan — each carrying a different counterparty reference. The client we ship normalizes them to a single counterparty object so a downstream system never has to branch on which transfer flow produced a row.

What ships at the end

The headline deliverable is code that runs against your consenting account on day one:

• Runnable client source in Python and Node.js for login, the dated statement query, the transaction pull and balance reads, with paging handled for you.
• A stream/queue ingestion handler that replays entries by reference and reconciles an overlapping backfill against the live tail without double-posting.
• An automated test suite that exercises the auth refresh, an empty window, a multi-page window, and the three transfer counterparty shapes.
• A normalized transaction schema so transfers, card activity and statement lines land in one shape.

Then the supporting set: an OpenAPI description of the surfaces we mapped, a short protocol and auth-flow write-up covering the token and refresh chain, interface documentation, and data-retention guidance for whatever you keep.

What this particular build has to handle

Two things about this app shape the engineering, and we plan for both rather than treating either as your problem to pre-solve.

It is multi-tenant. The same SmartBank client is shipped to several institutions — the MeditBank build is the visible sibling. Host, tenant id and branding differ per deployment, so we pin every call to this NUBank instance instead of assuming a single shared backend. A change on a sibling tenant does not silently move this one.

Statement windows can be long. The date picker lets a user request an arbitrary range, and a wide range paginates. We map how the backend bounds and pages a long history so a year-long pull comes back whole; a truncated statement would quietly under-report, which is the failure mode we design against.

Access to a consenting account or a sponsor environment is arranged with you during onboarding. It is part of the engagement, set up together, not a checklist you clear before we start.

Jobs people hire this for

• Sync a SmartBank account's transactions into an accounting or ERP ledger, categorized and deduplicated.
• Pull dated statements automatically each month for bookkeeping or audit, instead of screenshotting the app.
• Confirm outbound transfers — own-account, saved-payee or QR — against an internal payout record.
• Feed balances and activity into a personal-finance or treasury dashboard that aggregates several banks.
• Validate a saved payee's bank details before a transfer is initiated downstream.

Authorization and the regime question

The basis we rely on is the account holder's explicit, recorded authorization to act on their behalf. That holds regardless of which bank deployed the app, and it is what every route above is built on. We log consent, scope it to the data the project actually needs, keep the smallest footprint that does the job, and work under an NDA where the data warrants one.

As for a named scheme: the studio behind SmartBank carries a UAE footprint, and the Central Bank of the UAE gazetted its Open Finance Regulation in April 2024, with mandatory participation for licensees and a phased onboarding that starts with banks. If this deployment's issuer is one of those licensees, a regulated account-information read can ride that framework. The public listing does not name the issuer or its licensing jurisdiction, so we treat the scheme as conditional and confirm it once the institution is known — rather than printing a regulator's name here as if it were settled.

Cost and delivery

A first working pull against a consenting account — token capture, the dated statement and transaction endpoints wired, paging proven, a passing test — typically lands inside one to two weeks. You can take the result as source you run yourself: the runnable client plus docs and tests, from $300, invoiced only after delivery once it works against your account. Or skip hosting entirely and call our endpoints on a pay-per-call basis with nothing upfront. Tell us the data you need from a SmartBank By NUBank account and we will say which fits. Start the conversation

Where this comes from

Checked in June 2026 against the app's own listings and the relevant regulator. The feature set and platforms come from the Google Play listing and the Apple App Store listing; the white-label nature and builder come from the Sarab Tech SmartBank product page; the open-finance framing is taken from the CBUAE Open Finance Regulation in the central bank rulebook. Per the Play listing, the Android build was last refreshed in late February 2026; the iOS build needs iOS 15.5 or later per the App Store.

OpenFinance Lab — interface engineering notes, June 2026.

Banking apps in the same bracket

Other consumer banking apps an aggregation project tends to see alongside this one. Listed as context, not ranked.

• Liv. by Emirates NBD — a digital-only lifestyle bank holding accounts, cards and spend insights behind a single login.
• Mashreq Neo — a long-running UAE digital bank with accounts, transfers and card data in-app.
• Wio — a Central-Bank-of-UAE-regulated digital bank serving personal and business accounts.
• YAP — an app-based account and spend-tracking product layered over a partner bank.
• ADCB Hayyak — a quick-onboarding mobile account with transfers and statements.
• Revolut — multi-currency accounts, cards and transfers with a dense per-user transaction record.
• Wise — multi-currency balances and international transfers with detailed transaction histories.
• Nu (Nubank) — the Brazilian neobank, distinct from this app, holding account, card and statement data per user.

App screens

From the published store gallery. Tap to enlarge.

Questions we get about this one

Can you pull statements for an arbitrary date range, the way the in-app statement screen does?

Yes. The statement view lets a user pick a start and end date, and the same bounded query is what we map. We pin how the backend paginates a long window so a multi-month or multi-year pull comes back complete instead of stopping at the first page, and we hand you a client that walks the pages for you.

Do you keep the transaction feed fresh by re-pulling everything, or by streaming new activity?

Both, and they are designed to meet. New activity is ingested as it appears, keyed on each entry's own reference, while a periodic overlapping backfill catches anything missed during a gap. Because the keys are stable, a backfill that overlaps the live tail resolves to the same rows rather than duplicating them, so a downstream ledger stays clean.

This is a white-label app branded for NUBank — does that change how the integration is built?

It does, and we account for it. SmartBank is a Sarab Tech platform shipped to more than one institution — the MeditBank build is the visible sibling — so the API host, tenant identifier and branding differ per deployment. We pin the integration to this NUBank instance's host and token scheme rather than assuming a single shared backend.

Which regulator covers this, when the bank behind the app is not named on the store listing?

The dependable basis is the account holder's own authorization, which does not depend on naming the issuer. Where the deploying institution is a licensed bank under a formal open-finance regime — the Central Bank of the UAE's Open Finance Framework is the most relevant candidate given the studio's regional footprint — a regulated account-information path can be added once the issuer is identified. We confirm that during onboarding rather than guessing it here.