What Cashora stores per borrower, and how we integrate it

A finished Cashora application leaves a structured trail behind the login: a signed electronic contract, an installment schedule that can run anywhere from 91 to 240 days, and a KYC bundle pinned to a Bangladeshi national ID card. That trail is what a lender, a collections team, or a partner super-app actually wants — and none of it leaves the authenticated app on its own. Reaching it is an interface-integration job, not a download.

The bottom line is short. Cashora's value as an integration target is the per-borrower record set, and the practical way to that record set in Bangladesh is to rebuild the app's authenticated calls under your authorization. There's no consumer open-banking consent rail here to connect through, so the work is documented interface analysis rather than a regulated data pull — and that is exactly the kind of build we ship.

What a Cashora account holds

These are the surfaces the app exposes to a logged-in borrower, named the way Cashora's own flow describes them. An integration maps each to a clean field set.

Getting to the data: the authorized routes

Two or three routes genuinely apply to Cashora. We scope which one fits your use case during onboarding, and arrange the access that goes with it alongside you.

Route 1 — protocol analysis of the app session

We capture the authenticated traffic the Cashora client makes after login, under your authorization, and rebuild those calls as a documented, typed API. This reaches every surface in the table above, because it is the same path the app itself uses. Durability is moderate: when the client front end shifts, captured calls need re-checking, which we cover in maintenance.

Route 2 — borrower-consented access

For per-borrower pulls, the borrower consents and we drive their own authenticated session headlessly, returning only that person's applications, schedule and contract. Consent scope is narrow and revocable, which suits a partner app showing a user their own loans.

Route 3 — native export

If the app hands a borrower a downloadable contract or statement, we parse it as a low-frequency secondary feed. It is cheap to add but covers less than the session route.

What carries this one is route 1. Cashora's records live entirely behind the app login and Bangladesh has no consumer open-banking consent framework a third party could connect through, so reconstructing the app's own session is the route that reaches the data at all. Route 2 is the cleaner choice when the job is a single borrower pulling their own history; route 3 only earns a place if there's a download worth parsing.

What lands at the end of the build

Everything is tied to the surfaces above, not a generic template:

• An OpenAPI/Swagger specification for the reconstructed endpoints — auth, applications, credit decision, repayment schedule, contract, disbursement.
• A protocol and auth-flow report documenting the OTP-to-token-to-session chain, token lifetime, refresh behaviour and the error codes the app returns.
• Runnable source for the key endpoints in Python and Node.js, ready to drop into your own service.
• Automated tests — including a check that the reconstructed repayment math matches the app's own worked example.
• Interface documentation plus compliance and data-retention guidance written for Bangladesh's data rules.

The auth and repayment-schedule calls

Illustrative shape of the two calls most integrations start from — a phone/OTP session, then the repayment schedule. Exact paths and field names are confirmed by traffic capture during the build, against a consenting account; the numbers below mirror the app's own fee example.

POST /api/v1/auth/otp/verify          # phone + OTP -> session token (illustrative)
  { "mobile": "+8801XXXXXXXXX", "otp": "######" }
  -> 200 { "access_token": "…", "expires_in": 3600, "borrower_id": "bd_…" }

GET  /api/v1/loan/applications        # Authorization: Bearer <access_token>
  -> 200 [ { "application_id": "ap_…", "amount": 10000, "currency": "BDT",
             "term_days": 100, "status": "APPROVED",
             "apr": 0.104, "daily_rate": 0.00028 } ]

GET  /api/v1/loan/ap_…/schedule
  -> 200 { "principal": 10000, "interest": 280, "due_total": 10280,
           "installments": [ { "seq": 1, "due_date": "2026-…", "amount": … } ] }

# error handling: 401 re-runs the OTP/session step before retry;
# 429 backs off; the daily-accrual model rebuilds 'interest' rather than trusting it.

Where teams put this to work

• A collections desk syncing every borrower's installment schedule and days-past-due each night into its own dashboard.
• An accounting reconciliation that pairs disbursements with repayments in a single BDT ledger.
• A partner app showing a consenting borrower their Cashora contract and remaining schedule inside another wallet.
• A risk export feeding approved-amount, APR and term distributions into a portfolio model.

Things we account for in the Cashora build

The judgment calls that decide whether the integration holds up. We handle these as part of the work.

• Session and token lifecycle. Bangladeshi lending apps typically authenticate by mobile OTP into a short-lived session. We build the sync around that lifecycle so it re-establishes the session cleanly when the token (illustratively about an hour) lapses, rather than failing quietly mid-run.
• Daily interest accrual. Cashora accrues interest daily — a rate at or below 0.028% a day, per its listing — across terms from 91 to 240 days. We reconstruct the schedule as a daily-accrual ledger so reconstructed balances reproduce the app's own example (10,000 BDT to 280 BDT interest to a 10,280 BDT payoff) instead of assuming monthly periods.
• Sensitive KYC payloads. The onboarding step carries a national ID image and a selfie. We data-minimize by default: the standard extraction pulls application and repayment metadata and leaves the document blobs out unless your use case needs them, in which case they are handled under the Ordinance's consent rules.
• Front-end drift. When the client app changes field names or paths, we re-validate the captured calls as part of ongoing maintenance, so a silent app update does not break your feed.

Consent and the data rules in Bangladesh

Cashora operates under Bangladesh Bank's oversight of digital lending, and lending decisions in the market lean on the central bank's Credit Information Bureau. For data access, the governing concern is privacy. Bangladesh's Personal Data Protection Ordinance 2025 recognises each citizen as the owner of their personal data and makes explicit consent mandatory before personal data is collected, stored or transferred; some sections take effect well after gazette notification, so the framework is still phasing in rather than fully settled. We do not treat any unsettled provision as a present-tense obligation.

Because there is no consumer open-banking consent rail in Bangladesh, the dependable basis we rely on is the person's own authorization — the borrower consenting to a pull of their own records — and, for institution-side integrations, the client's written authorization. Access is logged, data is minimized to what the use case needs, consent records are kept, and an NDA covers the engagement where required. That is how the studio operates, not a checklist handed to you.

Interface evidence

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

How this was put together

This mapping reads Cashora's Play Store listing for the product mechanics — loan range, term, the interest worked example, the KYC requirements — then checks the Bangladesh regulatory backdrop against primary sources: the central bank's Credit Information Bureau, its recent digital-lending guidance, and the Personal Data Protection Ordinance 2025. Reviewed June 2026 by the OpenBanking Studio integration desk.

• Cashora — Google Play listing
• Personal Data Protection Ordinance 2025: key takeaways — The Daily Star
• Credit Information Bureau — Bangladesh Bank
• Banks cleared to launch digital e-loans — The Daily Star

Other lending and wallet apps in the same map

A unified integration usually spans several of these. Neutral notes on what each holds:

• bKash Loan — small instant loans inside the bKash wallet via City Bank; holds loan status and repayment data alongside wallet transactions.
• BBL Shubidha — BRAC Bank's end-to-end digital retail-loan app; application, assessment and disbursement records per customer.
• Nagad — large mobile financial service; wallet balances, transfers and any linked credit lines.
• eRin — salary-based personal loans for professionals; income verification and repayment schedules.
• Phandora Credit — short-term personal loans with flexible repayment; application and ledger data.
• Mr Loan — fast small-ticket loans; short-term repayment plans and applicant records.
• iPay — e-wallet with loan integration; stored-value balance plus small credit lines.
• Aamartaka — loan and credit-card comparison marketplace; quotes and application status across lenders.

Questions an integrator tends to ask

Cashora terms run 91 to 240 days at a daily interest rate — can you reconstruct the exact installment schedule and payoff?

Yes. We model the loan as a daily-accrual ledger and the automated tests check our figures against the app's own worked example — 10,000 BDT over 100 days produces 280 BDT interest and a 10,280 BDT payoff, per its listing. Schedules across the full 91-to-240-day range reconstruct the same way.

With no consumer open-banking regime in Bangladesh, what is the legal basis for pulling Cashora records?

The borrower's explicit consent. Bangladesh's Personal Data Protection Ordinance 2025 recognises the individual as the owner of their personal data and makes consent the operative basis for collection and transfer. For institution-side work we operate under the client's written authorization, with access logged and an NDA where needed.

Do you have to pull the national-ID image and selfie, or can the integration skip them?

It can skip them. The default extraction pulls application, decision and repayment metadata and leaves the KYC document blobs out. Where a use case genuinely needs the documents, we treat them as sensitive personal data and handle them under the same consent rules.

How do the loan applications, schedules and contracts join together — what is the key?

They key off a borrower account id established at registration; the mobile number is the login handle, not the join key. We map those id relationships during the build so applications, decisions, schedules and signed contracts line up per borrower without guesswork.

Working with us on Cashora

The build runs one to two weeks. At the end you either take the runnable source for Cashora's reconstructed endpoints — the code plus the OpenAPI spec, the auth-flow report, tests and interface docs, from $300 and billed only after delivery once you have checked it works — or you skip running anything yourself and call our hosted endpoints, paying per call with no upfront fee. Tell us the app name and what you want out of its data and we will scope it: start a Cashora integration.