From 4 December 2025, HSBC Bangladesh's Personal Internet Banking and the retail side of the mobile app are scheduled to switch off — that is HSBC's own customer notice, not our guess, and it shapes everything about what an integration here can usefully do. The corporate and institutional side stays put. So this brief is really two integrations in one: a clean, time-bound capture of retail data while the consumer surfaces are still live, and a durable build against the CIB footprint that survives the transition. We do both.
The bottom line is short. Retail integrations are useful but have a deadline. CIB integrations don't. We treat them as separate projects with separate scopes, even when the same client wants both, because the auth chains, refresh windows, and downstream consumers are not the same.
What actually lives in the HSBC Bangladesh app
The app description names a small set of surfaces — accounts at a glance, transfers to HSBC and other banks, device and security management, customer-service requests, and accessibility-tuned views. Mapped against what a typical integrator wants, the table looks like this.
| Data domain | Where it comes from in the app | Granularity | Typical downstream use |
|---|---|---|---|
| Account positions | "View your accounts at a glance" landing surface | Per account, available + ledger balance, currency, as-of timestamp | Cash-position dashboards, treasury reconciliation |
| Statement / transaction history | Account detail drill-down | Per posting, with rail tag (BEFTN / NPSB / RTGS / internal / SWIFT) | Bookkeeping ingest, ledger normalisation, expense categorisation |
| Transfer history | Transfer module — own-bank and other-bank flows | Per transfer: amount, beneficiary, rail, status, fee | Payment reconciliation, exception queue |
| Beneficiary list | "Manage beneficiaries" surface | Per beneficiary, with rail eligibility | Payee-master sync; pre-flight validation for outbound payments |
| Device / security registry | "Manage devices and security settings" | Per device, with provisioning timestamp | Access review; flags re-provisioning events to the pipeline |
| Customer-service requests | Online service-request module | Per ticket, with status and category | Operations queue mirroring, SLA reporting |
Two of those rows do most of the work in practice: statements and transfers. Everything else is supporting context. If a project has to be lean, that is where to lean.
Routes that fit this app
Route A — Authorized interface integration on the app and PIB traffic
Default route for any retail-side capture and for many CIB user-facing tasks. We instrument a sponsored client device and the PIB session, document the auth chain (hard-token provisioning, then PIN or biometric, then a short-lived session bearer), and turn the relevant request / response shapes into a stable interface. Reachable: balances, statements, transfer history, beneficiaries, devices, service requests. Effort: moderate — the hard-token provisioning step adds a one-time onboarding hop. Durability: solid through the wind-down, then constrained to the CIB-side surfaces afterwards.
Route B — User-consented credential access (retail, time-bound)
Where the end customer is the one driving the integration — for example, a personal-finance manager that needs to read this customer's statements until they migrate banks — we use the customer's own credentials under explicit, revocable consent, log every fetch, and minimise what we keep. Genuinely useful, but the calendar is tight: this only makes sense for one-off archives and short-window migrations finishing before 4 December 2025.
Route C — Native export
PIB supports statement download (PDF, and where the customer enables it, OFX / CSV). For a final retail capture, we run the export route in parallel with Route A as a belt-and-braces archive: one machine-readable snapshot plus one human-readable PDF per account, both signed and timestamped. Cheap and reliable, and worth doing even if Route A is the operational pipeline.
Route D — Bangladesh Bank Open Banking, when it lands
Bangladesh Bank has publicly signalled that an Open Banking Guideline and standardised API spec are in the pipeline, with a working committee forming late 2025 and a target window around mid-2026, per local trade press. Real, but unfinished. We track the spec, and when it ships we re-cut whichever pieces of the integration map cleanly onto it — but we do not block delivery on it today.
The recommendation reads like this in practice. For a retail-side need: Route A as the operational pipeline, Route C as the archival belt, Route B only where a specific customer is the driver. For anything CIB-side: Route A against the institutional surfaces, with a placeholder for Route D once the regulator's spec is firm.
What ships at the end of the build
The output is code you can run, not a slideshow.
- Python and Node.js SDKs with one transfer interface, two rail adapters (BEFTN, BD-RTGS), and typed clients for balances, statements, transfers, beneficiaries, and service requests. Both are first-class — neither is a wrapper around the other.
- Webhook handlers for posting events, modelled as idempotent receivers with replay-safe storage; where the upstream has no native push, we expose a polling-to-webhook bridge with deduplication.
- Automated test harness that exercises the full auth chain against a sponsored device profile and replays recorded sessions in CI — so a token rotation upstream surfaces as a failing test, not a silent break in production.
- Batch-vs-realtime sync design: nightly statement reconciliation, intraday balance refresh, on-demand drill-down. Cadence is per-account, configurable, and documented.
- Ingestion idempotency contract: every posting carries a stable composite key, every retry is safe, every late-arriving correction has a defined resolution rule.
- An OpenAPI 3.1 specification for the resulting surface — a secondary deliverable rather than the headline; the spec is what your platform team imports after the code is already running.
- A short auth-flow report covering the hard-token / PIN / biometric / session-bearer chain, and the operator runbook for re-provisioning.
- A compliance memo aligning the build to the Data Protection Act 2023 and to the project's written authorization.
A daily statement pull, sketched
Shapes below are illustrative — the live field set and error model are confirmed during the build against the sponsored device. They show how the SDK surfaces the auth chain and the per-rail tagging without leaking app internals to the caller.
# HSBC Bangladesh — nightly statement pull (Python SDK)
# Auth chain confirmed during the build:
# hard-token-provisioned device → PIN or biometric unlock
# → short-lived session bearer (~10 min, rolling)
from hsbc_bd_sdk import Client, RailTag
client = Client(
device_profile="proj-7821-device-a", # sponsored, per project
credential_source="vault://hsbc-bd/proj-7821",
)
session = client.open_session() # handles token + unlock
positions = session.accounts.positions()
# [{ account_no, currency, available, ledger, as_of }, ...]
for acct in positions:
stmt = session.accounts.statement(
account_no = acct["account_no"],
from_date = "2026-04-01",
to_date = "2026-04-30",
format = "ofx",
)
# Each posting is tagged with the rail it moved on:
# RailTag.BEFTN → same-day batch, finality at session close
# RailTag.RTGS → real-time, settles inside ~30 min, Tk >= 100,000
# RailTag.NPSB → card / IBFT, near-real-time
# RailTag.SWIFT → foreign currency, T+n
ledger.ingest(stmt, idempotency_key=stmt.composite_key)
# Failure modes the SDK surfaces, not swallows:
# 401 → session expired → one silent refresh, then escalate
# 423 → device locked → operator runbook step 3
# 429 → rate-limited → exponential backoff, capped at 4 tries
Things the build accounts for
- Device binding from the hard token. The provisioning step ties a session to a single device. We run the build against one sponsored device profile per project, record its identifier alongside the code, and design the operator side so a re-provisioning event surfaces explicitly — the pipeline never silently re-binds. Device handover and the supporting authorization are arranged with the client during onboarding; nothing about that is on the customer to pre-clear before we start.
- The 4 December 2025 cutoff is a build calendar, not a footnote. Any retail-side capture is scheduled to finish before that date, with the final archival pass run independently of the operational pipeline so a last-minute issue with one does not lose the other. After the date, the integration code stays — the retail-facing endpoints simply stop returning data, the SDK marks them deprecated, and the CIB-side surfaces keep running.
- BEFTN, BD-RTGS, and NPSB behave differently on retry. A transfer that posts via BEFTN with same-day finality should not be reconciled as a real-time settlement; an RTGS transfer that settles inside roughly half an hour for amounts at or above Tk 100,000 should not be polled at BEFTN's batch rhythm. We model each rail explicitly in the ingestion contract so downstream consumers see a single normalised event but accurate timing.
- Foreign-currency accounts and SWIFT messaging. HSBC Bangladesh customers can hold FCY accounts; the statement format and the matching settlement legs differ from the local-currency case. We map currency-specific quirks (FX rate stamp, value-date drift, MT103 reference chains where surfaced) so an FX-aware downstream ledger gets what it needs.
Bangladesh Bank, the DPA, and what consent looks like in practice
For the banking surfaces themselves, Bangladesh Bank is the regulator and the four interbank rails the integration touches — BACPS, BEFTN, NPSB, BD-RTGS — sit under its Payment Systems Department, with published rulebooks for each (the BD-RTGS rules document the Tk 100,000 floor and the half-hour settlement target referenced above). For personal data, the operative law is the Data Protection Act 2023, which requires free, explicit, revocable consent from the data subject and places the burden of proof of that consent on the controller; a Personal Data Protection (Amendment) Ordinance has been reported in early 2026 and we track its scope as it firms up.
How the studio operates against that: written client authorization on file before the build starts; explicit, revocable end-user consent where Route B is in scope; per-request logging; data minimisation against a documented field list; NDA on request. None of that is presented as a checklist the reader has to clear before a quote — it is how the project runs.
How we price this build
Most HSBC Bangladesh projects settle inside 1–2 weeks from kickoff. Source-code delivery starts at $300 and is paid after we hand over the working code and you have signed off — not before. If you would rather avoid an upfront fee entirely, the same surfaces are available as hosted endpoints on a pay-per-call basis, with the meter only running when you call them. Either way, scoping access, sponsored devices, and the supporting authorization is part of our work during onboarding, not a wall you have to climb first.
Tell us the app, the data domains in scope, and the deadline. We come back with a fixed scope and a date. Start an HSBC Bangladesh build →
End-to-end scenarios we have shipped against this shape
- Pre-closure retail archive. One-off, one customer (or a small consenting cohort): every account, every statement back to the earliest available period, every beneficiary, dumped to OFX + PDF, signed, and handed over before 4 December 2025. Useful for migration to a successor bank.
- CIB cash-position dashboard. Continuous intraday refresh of corporate balances, with RTGS-tagged movements flagged separately from BEFTN batches; feeds a treasury workstation.
- Trade-payment reconciliation. SWIFT-leg matching against HSBC Bangladesh's transfer history for an importer / exporter client, with the FX rate stamp and value-date carried through to the ledger.
- Payee-master sync. The beneficiary list flows nightly to the client's ERP, with rail-eligibility tags so the ERP knows which payees can be paid by BEFTN vs RTGS vs NPSB.
Where these notes come from
Notes here were drawn from the app's own description and store listing, HSBC Bangladesh's customer communications about the wind-down, Bangladesh Bank's published rulebooks for the interbank rails, and recent local trade-press coverage of the Open Banking Guideline. Specifically:
- HSBC Bangladesh — Mobile Banking product page
- The Daily Star — HSBC to wind down retail banking in Bangladesh
- Bangladesh Bank — BD-RTGS System Rules (PDF)
- The Business Standard — Bangladesh plans to introduce open banking
Reviewed 27 May 2026 by the OpenFinance Lab integration desk.
Other Bangladesh banking and wallet apps we map
For an integrator working in Bangladesh, the HSBC Bangladesh surfaces rarely stand alone — a unified data feed usually pulls one or two of these in alongside:
- bKash — the largest mobile-financial-service wallet in the country; per-user balance, transaction history, send-money, cash-in / cash-out.
- Nagad — the postal-service-backed wallet; comparable surface to bKash with its own ledger and KYC tier.
- Rocket — Dutch-Bangla Bank's mobile-money brand; the third major P2P wallet in the country.
- Upay — UCB's wallet; payments, top-up, merchant settlement.
- Dmoney — bank-account-linked wallet for utility bills, merchant payments, and airtime.
- NexusPay — Dutch-Bangla Bank's cardless app, with NPSB-based interbank flows and ATM withdrawal QR.
- MTB Smart Banking — Mutual Trust Bank's mobile banking; balances, transfers, statements.
- EBL Skybanking — Eastern Bank's mobile banking; broadly comparable mobile-banking surface.
- SC Mobile Bangladesh — Standard Chartered's local mobile banking; closest direct peer to HSBC Bangladesh on the consumer side.
- BRAC Bank Astha — BRAC Bank's flagship mobile banking; balances, transfers, deposits, card management.
Questions integrators tend to ask about this app
What actually changes for an integration once HSBC Bangladesh retail winds down on 4 December 2025?
Personal Internet Banking and the consumer side of the mobile app are scheduled to switch off on that date, per HSBC's own customer notice. Anything that depends on a logged-in retail customer session — statement pulls, beneficiary lists, transfer history — needs to be captured before then, archived, and treated as a one-off. The HSBC corporate and institutional banking footprint in Bangladesh is unaffected by that decision and remains a durable surface for trade, payments, and account reporting integrations.
The app provisions a hard-token security device — how do you handle that during the build without making it a customer ordeal?
The hard token binds the session to a specific provisioned device. We run the build against one device profile that the client has authorized us to use, record its identifier alongside the rest of the project, and design the resulting code so the operator side knows when a re-provisioning happens. That way, the pipeline does not silently break the next time the token rolls — it surfaces a clean re-bind step instead. The device handover and authorization are arranged with the client during onboarding.
Can a single SDK target both same-day BEFTN and real-time BD-RTGS postings, or do they need separate handlers?
One SDK, two adapters. BD-RTGS settles inside roughly half an hour for amounts at or above Tk 100,000, while BEFTN batches through the day with same-day finality — they behave differently on retry, on timing of the posting webhook, and on reconciliation. We expose one transfer interface to the caller and route to the right adapter underneath, so the client code does not have to care which rail moved the money. Refresh cadence is configurable per account.
Is there an open banking API in Bangladesh we should be waiting for instead?
Bangladesh Bank has signalled an Open Banking Guideline and a standard API specification with a target window around mid-2026, with the working committee expected to form in late 2025, per local trade press. That is a real but unfinished piece of regulation. If your timeline allows, we keep an eye on the spec and re-cut the integration onto it once it lands; if not, the consented interface route described above is what we ship today and is what will keep working through the transition.
About the HSBC Bangladesh app (factual recap)
HSBC Bangladesh is the local mobile banking app published by HSBC for its Bangladesh customers (Android package bd.hsbc.hsbcbangladesh, per the app's Play Store listing; also published on the App Store). Headline features per the app's own description: secure provisioning with a hard-token security device, login via biometrics or a 6-digit PIN, an at-a-glance accounts view, transfers to HSBC and other bank accounts, device and security management, and online service requests; accessibility is called out by the publisher. HSBC has publicly announced that its retail banking operations in Bangladesh are being wound down, with Personal Internet Banking scheduled to end on 4 December 2025; HSBC's Corporate and Institutional Banking footprint in Bangladesh is unaffected by that decision.