What it takes to integrate Agrani's Smart Banking backend

Agrani Bank PLC runs this app across roughly 972 online branches and 600 agent outlets, per its Play Store listing — a state-owned commercial bank putting retail account servicing on the phone. For an integrator the interesting part is not the bank's size; it is the set of authenticated screens a customer sees after login: balance, statement, last 25 transactions, and a transfer log that mixes intra-bank moves, BEFTN to other banks, and pushes to bKash and Nagad. That is the payload worth reaching.

Bangladesh does not yet have a live open-banking rule to ride on, so the working route is interface integration under the account holder's authorization — protocol analysis of the app's own session traffic, turned into a clean API. Below is what the app holds, how we reach it, and what lands in your repository at the end.

Account surfaces and what each one is good for

Each row below is a distinct response the app renders after authentication. Granularity is read from how the app describes the feature; field-level confirmation happens during the build against a real session.

Route to the data

Two routes genuinely apply to this app, plus a fallback. We name which one we would run and why, rather than listing them as equals.

Protocol analysis of an authorized session

The app talks to Agrani's internet-banking backend (the service behind ib.agranibank.org.bd, built by Celloscope per the package name). We observe the login, token and request chain of a consenting account, then reimplement the calls that return balance, statement and transfer data. Reachable: every authenticated screen above. Effort: medium — the auth handshake and the per-rail transfer fields carry most of the work. Durability: good between releases, with a re-check when the bank ships a new app version. Setup we handle: the consenting account, a capture environment, and field validation are arranged with you at onboarding.

User-consented credential access

Where a customer authorizes it directly, the same session is driven on their behalf to pull their own records. Reachable: identical surface, scoped to one consenting user. Effort: lower once route one exists, since it reuses the call map. Durability: tied to the customer's session lifetime and any re-auth the app forces. This is the cleaner basis while Bangladesh has no statutory open-banking consent layer.

Native statement export (fallback)

The statement views are exportable in practice as a customer-facing artifact. It is a reasonable backstop for historical bookkeeping, but it is batch, not live, and it loses the structured per-rail detail the session calls carry. We treat it as a gap-filler, not the primary feed.

For most teams we would build route one and expose route two on top of it: the protocol map is the reusable asset, and consented single-user pulls fall out of it cheaply once the call chain is reimplemented. The export stays as a historical backfill only.

What you get

Deliverables are tied to this app's actual screens, not a generic banking checklist.

• OpenAPI specification covering balance, statement, mini-statement, last-25, transfer-history, beneficiary and profile endpoints as we model them.
• Auth-flow report documenting Agrani's login, token issuance and refresh, and any device/session binding observed during the build.
• Runnable source in Python or Node.js for the key reads, including the transfer-history normalizer that flattens intra-bank, BEFTN and MFS legs into one record shape.
• Automated tests against captured fixtures so a future app release shows up as a failing test, not a silent data drift.
• Interface documentation plus compliance and data-retention guidance for handling Bangladeshi account-holder data.

Statement call, the shape of it

Illustrative — exact field names and the token mechanics are confirmed against a live session during the build, not asserted here.

# Pull a date-ranged statement for a consenting Agrani account
POST /ib/api/account/statement
Authorization: Bearer <session_token>
Content-Type: application/json
{
  "accountNo": "<linked_account>",
  "fromDate": "2026-05-01",
  "toDate":   "2026-05-31"
}

# Normalized response after our mapping layer
{
  "account": "****1234",
  "currency": "BDT",
  "entries": [
    { "postedAt": "2026-05-04T11:22:00+06:00",
      "amount": -1500.00,
      "rail": "BEFTN",            # intra | beftn | bkash | nagad | qr
      "counterparty": "Other Bank A/C",
      "ref": "TXN..." }
  ],
  "fetchedAt": "2026-06-24T09:00:00+06:00"
}

# Token refresh: re-auth is forced on expiry; the client
# retries once, then surfaces a typed AuthExpired error
# rather than silently returning a stale page.

Where teams use it

• A lender pulling a consenting applicant's statement and last-25 to assess cash flow before approval.
• An accounting tool syncing an Agrani business account's transfer history into its ledger nightly.
• A treasury dashboard that reconciles BEFTN and MFS payouts against expected disbursements.

Consent and the rules that actually apply here

Bangladesh Bank regulates this space, and the honest position is that there is no open-banking framework in force to point to. The central bank has signalled Open Banking guidelines and a standardized API for around June 2026, with a working committee expected late 2025, per Business Standard. Separately, NPSB interoperability went live on 1 November 2025 to connect banks, MFS and PSPs for real-time transfers — though bKash and Nagad sat out the launch, per New Age. Neither of those gives a third party a consent-based data right today.

So the dependable basis is the account holder's own authorization. We integrate against a consenting account, keep consent scope and access logs on file, minimize what is pulled to the fields a use case needs, and sign an NDA where the engagement calls for one. Bangladesh's general data-protection statute is still in draft, which is exactly why the consent record and retention discipline matter rather than a checkbox. As and when the June 2026 guidelines land, a consent-based route can be migrated onto them; the integration is built so that is a swap, not a rewrite.

Engineering notes we plan around

Two things about this app shape the build, and we handle both on our side.

First, the transfer log is multi-rail: one screen mixes intra-Agrani transfers, BEFTN to other banks, QR cash-out, and pushes to bKash and Nagad, and each rail carries different counterparty and reference fields. We design the normalizer so all of them collapse to one typed record with a rail tag, so a downstream system never has to special-case where a payment went. With NPSB now widening the range of counterparties an account can transact with, that normalization is the part we keep deliberately flexible.

Second, the app is built on a vendor internet-banking platform (Celloscope) and ships regular version updates — version strings on the store listing move over time. We wire fixture-backed tests so a changed response or a new app release surfaces as a failing check, and we schedule a re-validation pass against maintenance so the feed does not drift quietly. Account activation also needs a one-time in-person branch signing; that is a property of the account, so we arrange an already-activated consenting account with you at onboarding rather than building it into the running integration.

Interface evidence

Store screenshots of the surfaces described above. Click to enlarge.

How this was checked

Read the app's Play Store listing for its feature set and operator claims, then the regulatory picture from primary Bangladeshi reporting on open-banking plans and NPSB interoperability, in June 2026. Feature names are taken as the app describes them; field-level structure is confirmed during the build, not assumed here. Sources opened:

• Agrani Smart Banking App — Google Play listing
• The Business Standard — Bangladesh plans to introduce open banking
• The Business Standard — bank–MFS transfers via NPSB from 1 Nov
• New Age — NPSB interoperability starts without bKash, Nagad

Mapping reviewed 2026-06-24 by the OpenBanking Studio integration desk.

Comparable apps in the same ecosystem

Other Bangladeshi banking and wallet apps an integrator often touches in the same project — listed for ecosystem context, not ranking.

• Sonali eSheba — Sonali Bank's e-service app for account opening and government fee payments; holds account and payment records behind login.
• Islami Bank iSmart — internet-banking app with balance, statement and transfer surfaces similar in shape to Agrani's.
• CellFin — Islami Bank's wallet app covering fund transfers, add money and QR payments, with its own transaction ledger.
• bKash — the largest MFS wallet; holds wallet balance, send/cash-out history and merchant payments.
• Nagad — second-largest MFS provider; wallet balance and transaction records per user.
• Rocket — Dutch-Bangla Bank's mobile financial service with wallet and transfer history.
• Citytouch — City Bank's internet-banking app with balances, statements and bill payments.
• AB Direct — AB Bank's app offering balance checks, transaction history and transfers.

Questions integrators ask about this one

Which transfer records can be read from an Agrani account, and where do they live?

The app surfaces account balance, full and mini statements, the last 25 transactions, and transfer history that spans intra-Agrani moves, BEFTN transfers to other banks, and pushes to bKash and Nagad wallets. Each of these is a distinct backend response in the session; we map them to typed records so a downstream system gets one consistent transaction shape regardless of which rail produced the entry.

Bangladesh has no live open-banking rule yet — so what is the lawful basis for the integration?

Correct, there is no formal framework in force; Bangladesh Bank has signalled Open Banking guidelines and a standardized API around June 2026. Until then the dependable basis is the account holder's own authorization. We integrate against a consenting Agrani account under that authorization, with access scope, consent records and logs kept on file, and an NDA where the engagement needs one.

Does the NPSB interoperability launch change how you reach the data?

It changes context, not method. NPSB went live on 1 November 2025 connecting banks, MFS and PSPs for real-time transfers, per Business Standard reporting, though bKash and Nagad did not join at launch. We read what the Agrani app itself shows the customer; NPSB matters because it makes transfer descriptors and counterparties more varied, which we account for in normalization.

The app requires branch verification to activate — how do you build around an account that has to be set up in person?

Activation needs a one-time branch signing, as the listing describes. We arrange a consenting, already-activated test account with you during onboarding and build against that; the in-person step is a property of the account, not something the integration repeats, so it does not block the work.

Source delivery for this integration starts at $300 — you get the runnable code, the spec, the tests and the docs, and you pay after delivery once it works to your satisfaction. Prefer not to host it? Call our endpoints on a pay-per-call basis instead, with no upfront fee. The build cycle is one to two weeks either way, and you bring only the app name and what you need from its data — tell us what you are building and we handle the rest.