Reaching the account data inside SmartBank By NUBank

Behind SmartBank By NUBank sits a white-label banking backend built by Sarab Tech, the development shop whose project page describes the same product and which also publishes a near-identical build as SmartBank by MeditBank (package tech.sarab.meditbank). The brand on the icon reads NUBank, but this is not Nu Pagamentos of Brazil. It is a configurable banking client, and the account holder's records live on Sarab Tech's servers. That single fact decides everything below: the data is real and per-user, no national open-banking regime governs this build, so the working route is authorized interface integration of the app's own traffic.

What a buyer usually wants from a build like this is one normalized feed of balances, statements and transfers across however many of these branded deployments they touch. The app exposes all of that to its own screens. We reproduce those calls under authorization and hand back source you can run.

What account data the app actually holds

Each row below is a surface the app names in its own listing and on the Sarab Tech project page. Granularity is what an integrator can expect to read per call.

Getting at the data: the routes that apply

Three routes genuinely fit this build. Onboarding for each — a consenting account, the deploying institution's sign-off, sandbox access where one exists — is arranged with you as part of the project, not something you line up first.

1 — Authorized interface integration of the app's traffic

We observe and reproduce the REST/JSON calls the app makes for login, account list, statements, transfers and QR. This reaches everything the screens render, because it is the same backend the screens read. Effort is moderate. Durability is tied to app releases, so we version the integration to this build and re-check it when an update ships. This is the route that actually covers the full data set here.

2 — User-consented credential access

Where an institution sign-off is not on hand but the account holder authorizes it, we run the app's own authenticated session on the user's behalf to aggregate their data. Same per-user scope. Durability depends on the session and second-factor model, which we map up front.

3 — Regulated Open Finance consent

If the bank behind a given deployment turns out to be a CBUAE Licensee, the UAE Open Finance channel is the cleaner, consent-managed path and ages well. That participation is not disclosed on the white-label app itself, so we treat this route as conditional and confirm it per deployment rather than assuming it.

For this build the recommendation is plain: route 1 reaches the whole data set today because the records sit on Sarab Tech's backend, route 2 covers the same ground when only the account holder is in the loop, and route 3 only becomes the better option once a specific deployment is confirmed to ride a live open-finance regime.

What you receive at handoff

Everything is scoped to the surfaces above, not a generic banking stub.

• An OpenAPI/Swagger description of the endpoints we reproduce — auth, accounts, statement-by-date-range, transfers, QR, cards.
• A protocol and auth-flow report covering the login exchange, the bearer/JWT token model, refresh behaviour and how the QR payload is encoded.
• Runnable source for the key calls in Python or Node.js, including the date-ranged statement pull and pagination.
• Automated tests against a consenting account, plus normalisation so transaction rows come out in one consistent shape.
• Interface documentation and data-retention guidance — what we log, what we keep, what we strip.

A date-ranged statement pull, sketched

Field names and host are illustrative; the exact contract is confirmed during the build against the live deployment, not asserted from the store listing. The shape mirrors the app's own “pick specific dates” statement screen.

# 1. Session — login returns a short-lived bearer token
POST /api/v1/auth/login
{ "identifier": "<account-login>", "password": "<secret>", "device_id": "<uuid>" }
-> 200 { "access_token": "<jwt>", "refresh_token": "...", "expires_in": 900 }

# 2. Statement for a date range, paginated
GET /api/v1/accounts/{accountId}/statement?from=2026-01-01&to=2026-03-31&page=1
Authorization: Bearer <jwt>
-> 200 {
  "account_id": "...", "currency": "...",
  "opening_balance": 0.00, "closing_balance": 0.00,
  "entries": [
    { "id": "...", "ts": "2026-01-04T09:12:00Z", "type": "transfer_out",
      "counterparty": "Saved: <name>", "amount": -25.00, "balance_after": 0.00 }
  ],
  "page": 1, "has_more": true
}

# 3. Walk pages until has_more is false; refresh the token on 401.
# We stamp every row in one timezone so a backfill does not double-count.

Where teams plug this in

• A bookkeeping tool that imports a client's SmartBank statements on a schedule instead of by manual CSV.
• A treasury view that reads balances across several Sarab-built deployments a group operates under different brands.
• A payments product that initiates and confirms transfers, reusing the same QR encoding the app's scanner accepts.

The consent this rides on

No national open-banking badge is printed on this app, so we do not pretend one governs it. The footing that always holds is consent: the account holder authorizes access to their own records, and the institution deploying the brand authorizes the integration. Consent is scoped to the data domains a project needs, recorded, and revocable, and we minimise what is pulled to that scope. Where a particular deployment's bank is a CBUAE Licensee, the Open Finance Regulation the UAE central bank gazetted in April 2024 (per DLA Piper's analysis and the CBUAE rulebook) supplies a formal, revocable consent channel with its own authorisation manager — and we route through it when it is available. NDAs are signed where the engagement needs them, and access is logged throughout.

Engineering details we plan around

Two things about this specific build shape the work, and we handle both rather than hand them to you.

• One template, many brands. NUBank and MeditBank are the same Sarab Tech codebase wearing different labels. We pin the integration to this deployment's own host and API version, and schedule a contract check tied to app releases so a white-label update that renames a field does not quietly break the sync.
• QR payload decoding. The scan-to-pay feature only works if the encoded payee is parsed correctly. We decode the QR schema this build uses — routing string versus tokenised reference — and reproduce it so generated transfers pass the same validation the app's scanner applies.
• Login and token lifetime. The app pairs a password login with biometric sign-in and short-lived tokens. We design the sync's refresh around that session model so it re-authenticates cleanly instead of silently expiring mid-backfill.

Screens we map against

The published screenshots are the reference for which surfaces a build has to cover. Tap to enlarge.

Comparable apps in the same orbit

Same category, each holding per-user records a unified data layer would want to reach. Named for context, not ranked.

• SmartBank by MeditBank — the sibling Sarab Tech white-label build; same template, different brand and backend deployment.
• neo by Bank Audi — Lebanese digital banking with multi-currency accounts and QR-coded statements.
• YAP — wallet-style banking with QR send, card controls and spending analytics.
• Chime — fee-free US banking with early paycheck access and overdraft features.
• Revolut — multi-currency accounts, transfers and cards in one app.
• Monzo — UK app-first current accounts with rich transaction metadata.
• Wise — multi-currency balances and cross-border transfers.
• NEO — Saudi mobile banking covering accounts, cards and transfers.

Questions integrators ask about this app

Is this the Brazilian Nubank?

No. Despite the name, this is a Sarab Tech white-label banking build published as SmartBank By NUBank (package tech.sarab.nubank, per its Play Store listing), not Nu Pagamentos of Brazil. The same template also ships as SmartBank by MeditBank. We integrate against this specific deployment's backend, so the brand label does not change the work.

What does the QR-transfer feature mean for an integrator?

The app advertises QR Code Transfers, where a payee is encoded in a scanned code rather than typed. For integration we decode that QR payload, work out whether it carries a routing string or a tokenized reference, and reproduce it so a programmatic transfer validates exactly the way the app's own scanner does.

Which market's rules apply to a white-label app like this?

There is no single regulator stamped on the build. The dependable basis is the account holder's own authorization and the deploying institution's authorization. Where the bank behind a given deployment is a CBUAE Licensee, the UAE Open Finance Regulation gazetted in April 2024 becomes the cleaner, consent-driven channel; otherwise the route is authorized interface integration of the app's own traffic.

Can you pull date-ranged statements the way the app shows them?

Yes. The Detailed Account Statements screen lets a user pick a from/to date range, which means the backend exposes a date-filtered statement call. We mirror that call, handle pagination and the server's timestamp timezone, and normalise the rows so a backfill does not drop or double-count entries.

How this brief was put together

Checked in June 2026 against the app's own store listings and the developer's site, plus the UAE Open Finance materials referenced for the consent channel. Primary sources opened:

• Google Play — SmartBank By NUBank (tech.sarab.nubank)
• App Store — SmartBank By Nubank (id6738052774)
• Sarab Tech — SmartBank project page
• CBUAE Rulebook — Open Finance Regulation
• DLA Piper — UAE Open Finance Regulation analysis

Mapped by OpenBanking Studio's integration desk; notes current as of 2026-06-11.

If you want this, the start is small: send the app name and what you need out of its data — accounts, statements, transfers, the lot — and we arrange access and any compliance paperwork with you from there. Source-code delivery starts at $300: we hand over runnable source plus the spec, tests and interface docs, and you pay only once it is delivered and you are satisfied. Or skip hosting entirely and call our endpoints instead, paying per call with nothing upfront. Either way the cycle runs one to two weeks. Tell us about your SmartBank By NUBank integration and we will scope it.