Getting a Progoti client's loan and savings records out of Brac Agami

Every registered Progoti borrower opens Brac Agami with a mobile number and birth year, and behind that login sits an active loan and savings ledger held on BRAC Microfinance's servers. Brac Agami is, per BRAC's own description, the first financial app built exclusively for registered Progoti clients, giving 24/7 read access to loan and savings information. That is the integration target: not a marketing surface, but the per-client record set a borrower, a partner lender, or a reconciliation system would want to read programmatically.

Bangladesh has no live open-banking or account-aggregation scheme to plug into — Bangladesh Bank is still at the framework stage with its interoperable transaction platform. So the dependable basis here is the account holder's own authorization over their own records, and the working route is documented protocol analysis of the app's authenticated traffic under that mandate. The recommendation for almost every caller is to build directly against the loan-summary and transaction-history surfaces, because that is where the data a Progoti integration actually needs lives, and treat any native in-app export as a convenience layer on top rather than the primary feed.

What the app actually holds

These are the surfaces a logged-in client sees, mapped to where they originate and what an integrator does with each.

Authorized routes to the data

Consent-based protocol analysis (recommended)

A registered client consents to access of their own records; we document Brac Agami's request/response chain — login, OTP issuance, session token, the loan and savings endpoints — and implement a clean client against it. Reaches everything in the table above. Durable as long as the app's backend contract holds; the front end can change without breaking a well-isolated client. This is the route we set up for the large majority of Progoti work.

User-consented credential access

Where a client prefers to delegate, the OTP and PIN path is driven through them at enrolment and the resulting session is used for scoped, read-only pulls. Lighter to stand up, narrower in what it touches, and well suited to a single-borrower reconciliation rather than a fleet sync.

Native export as a fallback

If a usable in-app export or statement download exists for a given record type, we fold it in as a lower-effort top-up. It rarely covers the full transaction history at the granularity a reconciliation needs, so it sits alongside the protocol route, not in place of it.

The auth chain, in code

Illustrative shape of the login-to-token flow as the app describes it — mobile number and birth year, an OTP, then a session used for record queries. Field names are confirmed against the live contract during the build.

# Illustrative — Brac Agami / Progoti consent-based client
POST /auth/otp/request
  { "msisdn": "8801XXXXXXXXX", "birth_year": "1987" }
  -> 200 { "txn_id": "a1b2", "otp_channel": "sms", "expires_in": 120 }

# OTP entered by the consenting client at enrolment
POST /auth/otp/verify
  { "txn_id": "a1b2", "otp": "######" }
  -> 200 { "session_token": "", "refresh": "", "pin_set": true }

GET /accounts/loans/summary        # Authorization: Bearer 
  -> 200 {
       "loans": [
         { "loan_id": "...", "principal": 0, "outstanding": 0,
           "next_due_date": "YYYY-MM-DD", "status": "active" }
       ],
       "savings": [ { "account_id": "...", "balance": 0 } ]
     }

# Normalized output we hand downstream
{ "client_ref": "...", "loans": [...], "savings": [...],
  "transactions": [...], "as_of": "2026-06-27T00:00:00+06:00" }

Error handling covers OTP expiry, session refresh, and the PIN-backed quick-access path, all of which the app exposes. We do not store the client's PIN; it stays a credential the client controls.

What lands at handover

Each deliverable is tied to a real Brac Agami surface rather than a generic checklist:

• An OpenAPI/Swagger spec describing the loan-summary, savings, and transaction-history endpoints as a normalized read API.
• A protocol and auth-flow report: the msisdn + birth-year login, OTP issuance, session-token lifetime and refresh, and PIN handling.
• Runnable source in Python or Node.js for the key endpoints — authenticate, pull a client's loans and savings, page the transaction history.
• Automated tests against captured sample responses so a backend change is caught, not discovered in production.
• Interface documentation plus data-retention and consent-record guidance sized for sensitive financial data.

Things we account for on this app

Two specifics shape the build for Brac Agami, both handled on our side:

• OTP is in the critical path. A naive poller would trigger an OTP on every run and fail. We design the sync so the OTP and PIN are established once with the consenting client at enrolment, then ride the session token and its refresh — the re-auth cadence is matched to how long BRAC's backend keeps a session alive.
• Progoti products vary by loan type and branch. Eligibility, installment math, and due-date rules are not uniform across the catalogue, so we map them per product rather than assuming one schema, which keeps an installment forecast correct when a client holds more than one loan.
• The UI ships in Bangla and English. We pin parsing to stable field identifiers, not display strings, so a language toggle or label change in the app does not silently break extraction; a re-validation pass is part of maintenance for when the portal front end shifts.

Consent and the law that applies

BRAC's microfinance operation sits under the Microcredit Regulatory Authority, the licensing body created by the Microcredit Regulatory Authority Act of 2006, per the public record on the MRA. There is no open-banking or AIS regime in Bangladesh to authorize third-party data access by statute, so the integration runs on the client's explicit consent to access their own records. Bangladesh's data-protection regime — the Personal Data Protection framework still moving through finalization — classes financial records as sensitive data that cannot be collected or shared without explicit consent and adequate safeguards, which is exactly the mandate the build is scoped to. We operate authorized and logged, minimize what is pulled to the records in scope, keep consent records, and work under NDA where the client needs it.

Pricing and how the build runs

Source-code delivery starts at $300 and is billed only after we hand over the working build and you have confirmed it does what you need — runnable client, spec, tests, and the auth-flow report. The alternative is a hosted API: you call our endpoints for Progoti loan and savings data and pay per call, with no upfront fee. Most builds run a one-to-two-week cycle. You bring the app name and what you want from its data; access, consent setup, and compliance posture are arranged with you as part of the engagement. Start the conversation at /contact.html.

Where callers use this

• A partner lender pre-qualifies a Progoti borrower by reading current outstanding balance and repayment regularity before extending a top-up.
• A bookkeeping or PFM app reconciles a client's BRAC installments against their own transaction feed so paid and due amounts stay in sync.
• A field-operations dashboard tracks arrears across consenting clients off the loan-summary surface instead of manual statement collection.

Interface evidence

Store screenshots of the surfaces referenced above — tap to enlarge.

How this was checked

Reviewed June 2026 against the app's own listing and operator pages, plus the regulator and data-protection sources for Bangladesh. We read the Brac Agami Play Store listing, BRAC's Brac Agami program page, the Microcredit Regulatory Authority record, and an overview of Bangladesh's Data Protection Act 2023. Mapped by the OpenBanking Studio integration desk · June 2026.

Neighbouring apps in the same data space

Same broad ecosystem, useful context for anyone planning a unified microfinance or wallet integration:

• bKash — the leading mobile financial service in Bangladesh; holds wallet balances, transaction history, and app-based micro-loans.
• Nagad — Bangladesh Post Office digital financial service with wallet, savings and loan facilities.
• Rocket — Dutch-Bangla Bank's mobile financial service, with transfers and bill-pay records per account.
• Upay — UCB-backed wallet covering payments and merchant transaction records.
• TallyKhata — small-business bookkeeping and digital-payment ledger, with lending built on transaction history.
• Amar Hishab — BRAC Microfinance's companion financial-management app, overlapping the same client base.
• eRin — short-term personal-loan app for salaried users, holding loan and repayment records.
• iPay — digital wallet with stored payment and transfer history per user.

Questions integrators ask

Which Progoti data surfaces can an integration actually reach?

The same records a logged-in borrower sees: active loan accounts with outstanding principal and due dates, savings balances, the running payment and transaction history, the installment schedule the loan calculator works from, and the product catalogue used for eligibility checks. We map each of those to a normalized JSON shape so a downstream system can read them without scraping screens.

Bangladesh has no open-banking regime yet — what is the authorized basis for pulling the data?

Because there is no AIS or account-aggregation scheme in Bangladesh to ride on, the work runs on the account holder's own consent. A registered Progoti client authorizes access to their own loan and savings records, we operate under that mandate, and the Personal Data Protection regime being finalized in Bangladesh treats financial records as sensitive data requiring exactly that explicit consent. Access is arranged with you and the consenting client during onboarding.

How do you handle Brac Agami's OTP and birth-year login in an automated sync?

Login is mobile number plus birth year, an OTP step, then a PIN for return access — per the app's own description. We document that chain as a token-issuance flow, capture the session token and its refresh behaviour, and build the sync so the OTP is requested through the consenting client at enrolment rather than on every poll. The PIN-backed quick-access path is handled as a cached credential the client controls.

We want to reconcile a borrower's BRAC installments against our own ledger — what would you hand back?

An OpenAPI spec for the loan-summary and transaction-history surfaces, runnable Python or Node source that authenticates and pulls a client's installment schedule and paid/outstanding amounts, automated tests against sample responses, and a short report on the auth flow and data-retention handling. You can take the source under the from-$300 model or call our hosted endpoints per request.