Reaching statements, cards and transfers inside BRAC Bank Astha

Astha carries more than nine lakh BRAC Bank customers, going by Business Standard's reporting, and behind its login sit the records a third party actually wants: account statements you can view and download, a credit-card ledger that splits home and abroad transactions, and a transfer log spanning BEFTN, NPSB and mobile-wallet rails. The app is the customer-facing front end for an active BRAC Bank account; the integration question is how to read those records out reliably, with the account holder's permission, and hand back something a system can consume.

That is the work this page describes. We map the surfaces, build the consented access path, normalize what comes back, and deliver runnable code or a hosted endpoint. The client gives us the app and what they need pulled from it; the access, the protocol work and the compliance handling are ours to arrange.

Data surfaces worth reading

These are the records Astha exposes to a logged-in user, named the way the app names them. The route into each is consented protocol access against the mobile or web client, then normalization on our side.

Routes to the data, and the one we take

User-consented interface integration

With the account holder's authorization, we drive the same authenticated paths the Astha app and the astha.bracbank.com web client use, capture the request and response shapes for statements, card ledgers and transfer history, and turn them into a stable interface. This is the route that works today in Bangladesh because it depends on the customer's own permission rather than a scheme that has not launched. It reaches everything a logged-in user sees.

Protocol analysis of the mobile client

Where the mobile app surfaces something the web client does not, we document the app's traffic — auth handshake, token lifetime, the device-bound session — and implement against it directly. Effort here is higher and the work needs re-validation when the app ships a new front end, but it gives the most complete coverage and the freshest data.

Native statement export as a fallback

Astha lets a user download a statement and, for tax purposes, a dedicated statement document. Where a one-time or low-frequency pull is all that is needed, parsing that export is the cheapest path and avoids any session handling at all. It is bounded by what the export format carries.

For a recurring sync that has to stay current, the consented interface route is the one we would build on; protocol analysis fills the gaps it cannot reach, and the export parser is reserved for occasional bulk pulls where standing access is not worth maintaining. We say which mix fits once we see your data target.

What lands on handover

Each deliverable is tied to a real Astha surface, not a generic template.

• An OpenAPI/Swagger spec covering the endpoints we expose for statements, card ledger, and transfer history, with request and response schemas.
• A protocol and auth-flow report: the login handshake, token refresh, and the one-device-per-account binding, written up as it behaves during the build.
• Runnable source for the key calls in Python or Node.js — statement retrieval, card-ledger pull, transfer-history paging — with error handling for OTP challenges and session expiry.
• A normalized schema that tags every transfer with its rail (BEFTN, NPSB, MFS) so downstream systems read one consistent shape.
• Automated tests against representative responses, plus interface documentation.
• Compliance and data-retention guidance: consent records, data minimization, and what to keep versus discard.

A look at the wiring

Illustrative only — field names and the exact auth chain are confirmed during the build against the consenting account. It sketches a statement pull on a device-bound session.

# Consented statement read on a registered Astha session.
# Device binding: first login on a new device needs an OTP;
# later calls reuse the bound session. We register once.

session = AsthaClient(consent_token=CONSENT, device_id=BOUND_DEVICE)

if session.requires_otp():           # new/unbound device path
    session.submit_otp(otp_from_holder())   # account holder supplies it once

stmt = session.statement(
    account=ACCT_ID,                 # one of the holder's accounts/joint accts
    date_from="2026-01-01",
    date_to="2026-03-31",
    fmt="json",                      # download path also yields a PDF document
)

for tx in stmt["transactions"]:
    emit({
        "account": ACCT_ID,
        "posted": tx["date"],
        "amount": tx["amount"],
        "direction": tx["dr_cr"],
        "rail": classify_rail(tx),   # BEFTN | NPSB | MFS | internal
        "counterparty": tx.get("beneficiary"),
    })
# BEFTN clears in scheduled batches; a same-day item before the
# ~12:30 cut-off may read 'pending' — we hold, not fail, on that.

Consent and the Bangladesh picture

Bangladesh does not yet have a live open-banking regime. Bangladesh Bank has indicated open-banking guidelines and a unified API standard aimed at mid-2026, with a working committee expected to form first; until that exists, there is no statutory data-sharing channel to point an integration at. The country also lacks a comprehensive data-protection statute in force, with a draft act still pending. So the basis we work from is direct and unambiguous: the account holder authorizes access to their own records, and we operate on that consent.

That means scoped consent to specific domains, an expiry and revocation the holder controls, access logging, and data minimization — we read what the integration needs and nothing more. NDAs are in place where the engagement touches sensitive flows. When Bangladesh Bank's framework does land, an integration already built on explicit consent is straightforward to move onto it.

Engineering we plan for

Two things about Astha specifically shape how we build, and we handle both inside the project.

• One device per account. Astha binds a single device per account and challenges a new device with an OTP, then trusts it afterwards, per the app's release notes around version 1.9.2. We design the session handshake to register once with the holder during onboarding and reuse the bound session, so the sync is not tripping an OTP on every run.
• Two transfer rails, two settlement models. BEFTN moves money in scheduled batches with a same-day cut-off near 12:30 pm; NPSB clears in real time, day and night. We reconcile them separately so a batch item still in flight is held as pending rather than marked failed, and we tag each record with its rail.
• Multiple accounts and cards. The app exposes single and joint accounts and several cards, including the newer VISA virtual debit card. We model a stable identifier per account and per card so a multi-account holder maps cleanly instead of collapsing into one blob.
• Front-end churn. Astha ships features often — VISA Direct and the virtual card arrived in recent releases. We build a re-check into maintenance so a changed screen or response is caught and patched rather than silently breaking the feed.

Access to a sponsor sandbox or a consenting account is arranged with you during onboarding; it is part of the work, not something to clear before we start.

Interface evidence

Store screenshots of the surfaces referenced above. Select to enlarge.

How this was checked

Reviewed against the app's own description and store listing, BRAC Bank's Astha material, Bangladesh Bank's payment-systems pages for the BEFTN and NPSB rails, and open-banking coverage for Bangladesh's regulatory timeline. Sources opened:

• Astha listing on Google Play
• The Business Standard — Astha customer and scale reporting
• Bangladesh Bank — payment systems (BEFTN, NPSB, RTGS)
• Open Banking Tracker — Bangladesh status

Mapping put together by the OpenBanking Studio integration desk, June 2026.

Comparable apps

Same-category Bangladeshi banking and wallet apps, each holding account-level data a unified integration could read with the holder's consent. Listed for ecosystem context, not ranked.

• Citytouch — City Bank's internet-banking app; accounts, cards and transfers behind a login.
• NexusPay — Dutch-Bangla Bank's app over its large ATM and card network, with account and wallet flows.
• EBL Skybanking — Eastern Bank's app, known for dual-currency card handling and statement access.
• MTB Neo — Mutual Trust Bank's digital banking app with account and transfer records.
• CellFin — Islami Bank's app combining account access with a wallet layer.
• bKash — the dominant MFS wallet; balances, transaction history and payments, a frequent transfer counterparty for Astha.
• Nagad — MFS wallet with account ledgers and payment history.
• Rocket — Dutch-Bangla's mobile-money service, an MFS destination Astha transfers to.
• OK Wallet — One Bank's wallet, another MFS endpoint in the transfer set.

Questions integrators ask

Which data inside Astha is worth integrating against?

The valuable surfaces are the ones tied to an account login: detailed account information for transaction, loan and term-deposit accounts; statement view and statement download; the credit-card ledger with home and abroad transactions, credit limit, outstanding and reward points; and the transfer and bill-payment history across BEFTN, NPSB and MFS destinations like bKash and Rocket. Those are the records a third party usually wants to sync.

How does device binding affect a programmatic integration?

Astha registers one device per account and asks for an OTP on the first login from a new device, with no OTP on later logins from that same device, per its release notes. We design the session handshake to register once with the account holder's consent and then reuse the bound session, so the integration is not fighting a fresh OTP challenge on every poll.

Is there an open-banking scheme in Bangladesh we can rely on instead?

Not in force yet. Bangladesh Bank has signalled open-banking guidelines and a unified API standard targeted for mid-2026, with a working committee expected first. Until that lands, the dependable basis is the account holder's own authorization, which is what our consented integration runs on.

Can you separate BEFTN batch transfers from NPSB real-time ones in the data?

Yes. BEFTN settles in scheduled batches with a same-day cut-off around 12:30 pm, while NPSB clears in real time around the clock. We reconcile the two differently so a pending batch item is not reported as a failure, and we tag each transfer with its rail in the normalized output.

Putting it to work

A working Astha integration — consented statement, card and transfer reads, normalized and tested — typically lands in a one-to-two-week cycle. Two ways to take delivery: pay from $300 for the source code, runnable with its docs and tests, settled only after we hand it over and you are satisfied; or call our hosted endpoints and pay per call with nothing upfront. Tell us the app and what you need read out of it and we scope it from there — start a conversation here.