Brac Ekota and the BRAC Microfinance referral ledger

Every record in Brac Ekota starts the same way: a community agent registers with a name and mobile number, sets a PIN, then files a loan proposal on behalf of someone else — the person's basic details, their location, and the amount they want to borrow from BRAC Microfinance. The app is not a wallet. It is the thin origination layer where referrals are captured, queued for BRAC field staff to verify, and tracked through to a decision. That pipeline, plus the client ledger it can hand off to, is the data worth wiring into.

The honest read: there is no public account-information scheme in Bangladesh to consent through yet, so the working route is interface integration against a consenting agent account, with the build kept ready to swap onto a regulated path if one arrives. Most of the value lives in two places — the referral status feed, and the client loan ledger that the app reaches by switching into Brac Agami. We treat those as one surface and deliver a single normalized feed.

What the app actually stores

These are the surfaces the app exposes to a signed-in agent, named the way the app frames them. Field keys are normalized at delivery; live names are confirmed during the build.

Getting in without tripping the app's own controls

Three routes apply, and most builds use the first two together.

Authorized interface integration and protocol analysis

We capture the app's own traffic against a consenting agent account and reconstruct the auth handshake and the referral endpoints from it. This reaches the full lifecycle — proposal submit, status reads, profile, product list. Effort is moderate; the auth flow is a mobile-plus-PIN token exchange rather than anything exotic. Durability depends on the app's front end staying put, which we handle with a re-validation step. Access to a consenting account is arranged with you at onboarding.

User-consented session access

For production, the durable path is operating inside an agent's own consented session: the agent authorizes, and the integration reads only what that agent can already see, including the Agami ledger reached through the switch. This keeps data access tied to a real, revocable authorization rather than a stored secret.

Native progress export

The app already surfaces progress tracking to the agent. Where that view can be exported or read under consent, it is a low-effort fallback for status-only use cases — narrower than the first two routes, but cheap to stand up.

For most buyers the call is straightforward: map the surface once with protocol analysis, then keep production reads inside the agent's consented session so every pull traces back to a revocable authorization. We only reach for the native progress view when a project needs nothing more than whether a given referral got funded.

What lands in your repo

Everything is scoped to Brac Ekota's real surfaces, not a generic template.

• An OpenAPI/Swagger spec covering the auth exchange, referral submit, the status feed, profile and product reads.
• A protocol and auth-flow report: the mobile-plus-PIN token chain on Ekota, the OTP-and-birth-year step on Agami, token lifetime and refresh, and how the in-app switch hands a session between the two packages.
• Runnable source for the key endpoints in Python and Node.js — login, list referrals, read a referral's status, pull the linked client ledger.
• Automated tests against recorded fixtures, plus a re-validation check that flags when a field or endpoint shifts.
• Interface documentation a non-specialist can follow, with the normalized schema that merges referral status and client ledger.
• Compliance and retention notes: what to keep, what to drop, and how to log consent — written for the third-party PII this app carries.

A referral-status pull, sketched

Illustrative request/response, confirmed against a consenting agent account during the build. Endpoint paths and field names shown here are placeholders normalized in delivery.

# 1) Authenticate the agent (mobile number + PIN)
POST /agami-referrer/v1/auth/login
  { "msisdn": "8801XXXXXXXXX", "pin": "******", "device_id": "<install-id>" }
-> 200 { "access_token": "...", "expires_in": 1800, "agent_id": "..." }

# 2) List this agent's referrals with current lifecycle state
GET /agami-referrer/v1/referrals?status=all
  Authorization: Bearer <access_token>
-> 200 {
     "referrals": [
       { "ref_id": "...", "beneficiary_name": "...", "proposed_amount_bdt": 25000,
         "stage": "field_verification", "submitted_at": "2026-06-10", "branch": "..." }
     ]
   }

# stages seen in tracking: submitted -> field_verification -> feasibility_check -> decision
# 401  -> token expired; re-run login (no silent refresh on this surface)
# 429  -> back off; the agent app holds a single active session, so we serialize reads

Beneficiary fields are third-party PII — the proposal names a person other than the account holder — so the delivered client minimizes and redacts those fields by default and logs every read.

Where this plugs in

• Referral-to-CRM bridge. Push each new proposal into a partner lender's pipeline the moment it is filed, with the agent and proposed amount attached.
• Funding reconciliation. Watch the lifecycle status and reconcile which referrals reached a decision, so an incentive or commission ledger stays accurate.
• Unified client view. Merge referral status with the Agami loan and savings ledger so a support agent sees the whole relationship on one screen.

What we plan around on this build

Two things shape the engineering here, and we account for both rather than handing you a checklist.

• Single-account enforcement. The listing states multiple accounts are disallowed, so we design capture and reads against one consenting agent session and serialize calls — no parallel logins that would trip the app's duplicate-account controls.
• The Agami handoff. The richer ledger lives in a separate package (com.bracits.progoti) reached through the in-app switch, with its own OTP-and-birth-year sign-in. We map both auth surfaces so a unified feed spans referral status and client balances without a manual second login.
• Bangla-default UI. The app opens in Bangla with an English toggle, so response labels can shift with the user's language setting. We normalize to a stable English schema so field names do not move under you.

Who regulates this, and how consent holds

BRAC's microfinance arm is supervised by the Microcredit Regulatory Authority, which licenses MFIs under the Microcredit Regulatory Authority Act of 2006; the wider payments rail sits under Bangladesh Bank. There is no standing open-banking or account-information scheme to consent through today — commentary in the Bangladeshi press has pressed Bangladesh Bank to publish a roadmap and adopt API standards such as ISO 20022 and FAPI, but that is direction, not a live rail. On data protection, the Draft Personal Data Protection Act received in-principle cabinet approval in late 2023 per local coverage and is not yet enacted, so we work to its direction and to sector confidentiality norms rather than a settled statute.

What that means in practice: access rests on the consenting agent's own authorization, scoped to what that agent can already see, and revocable. We minimize the beneficiary PII the proposals carry, keep consent and access logs, and work under NDA where the engagement calls for it.

Cost, and how the handover works

Source-code delivery starts at $300, and you pay it only after we hand the code over and you have confirmed it runs against your consenting account. That package is the runnable endpoints, the OpenAPI spec, the tests and the interface docs — yours to host. The other model is a hosted API: you call our endpoints and pay per call, with nothing up front and no source to maintain. Either way the cycle is one to two weeks from the point access is arranged. Tell us the app and what you need from its data on our contact page and we will scope it back to you.

Screens we worked from

Store screenshots of Brac Ekota, used to map the referral and tracking surfaces. Click to enlarge.

Adjacent apps a unified feed would touch

These sit in the same Bangladeshi financial ecosystem; integrators rarely want just one. App names are listed for context only.

• Brac Agami — BRAC Microfinance's client app (com.bracits.progoti): active loans, savings, due dates and payment history. This is the ledger Ekota hands off to.
• bKash — the largest MFS wallet; balances, transaction history, and small instant loans in a City Bank partnership.
• Nagad — postal-backed MFS; per-account transfers, payments and balance ledgers.
• Rocket — Dutch-Bangla Bank's MFS; transaction and agent-banking records tied to DBBL accounts.
• Upay — United Commercial Bank's wallet; payment and balance data.
• TallyKhata / TallyPay — MSME bookkeeping plus a licensed wallet; dues, ledgers and bank-linked loan applications.
• iFarmer — agri-financing platform; investor and borrower records around farm lending.
• Dana Fintech — alternative lending; credit-scoring and loan records.
• eRin — salaried personal loans; application and repayment records.
• Drutoloan — collateral-free MSME lending; borrower and disbursement records.

Questions integrators ask about Brac Ekota

Brac Ekota only lets an agent refer other people. Is there per-user data worth integrating?

Yes. Each agent account carries its own referral records, the lifecycle state of every proposal (submitted, field verification, feasibility, decision), the agent profile and location, and the Progoti product list shown on the home screen. Through the in-app switch to Brac Agami it also reaches a client's active loan and savings ledger. That is structured, per-account, server-side state that a third party can sync.

The app switches to Brac Agami for actual loan balances. Can one feed cover both?

Yes. Brac Ekota (com.bracits.agami_referrer) signs in with mobile number and PIN; Brac Agami (com.bracits.progoti) uses a registered mobile number plus birth year with an OTP step, per its store listing. We map both auth surfaces and merge the referral pipeline with the client ledger into a single normalized schema, so balances and referral status arrive together.

Does Bangladesh have an open-banking API we can pull this through?

Not as a live regime today. Bangladesh Bank has been urged to publish an open-banking roadmap and adopt API standards such as ISO 20022 and FAPI, but there is no standing account-information scheme to consent through yet. The dependable basis is the agent's own authorization: we run authorized interface integration and protocol analysis against a consenting account, and keep the design ready for a regulated route if one lands.

We have the agent app and our requirements, nothing else. What does that get us?

That is the starting point we work from. You give the app name and what you want out of its data; access to a consenting agent account, any sandbox, and the compliance paperwork are arranged with you during onboarding. The build then runs against that consenting account and you receive runnable source, tests and interface docs in one to two weeks.

Sources and how this was put together

Drafted from the app's own Google Play and App Store listings, BRAC's microfinance pages for the sibling Agami client, and Bangladeshi reporting on the regulatory picture, cross-checked in June 2026. Primary sources opened:

• Brac Ekota — Google Play listing
• BRAC — Agami microfinance app
• The Business Standard — open banking in Bangladesh
• DataGuidance — overview of Bangladesh's Data Protection Act, 2023

Mapped by the OpenBanking Studio integration desk, June 2026.