Open Banking, API Data-Sharing & Embedded-Finance Arrangements in Bangladesh

by Barrister Tahmidur Rahman | Oct 14, 2026

Technology, IP & DataConnected finance, clear contracts9 min read

Open Banking, API Data-Sharing & Embedded-Finance Arrangements in Bangladesh

Open banking, API data-sharing and embedded-finance agreements for banks, payment providers, aggregators, e-commerce platforms and foreign fintechs in Bangladesh: we allocate consent, data use, security, liability and exit so every connected party knows exactly where it stands.

Open Banking, API Data-Sharing & Embedded-Finance Arrangements in Bangladesh: Open banking with TRW & Co
Matter planTechnology, IP & Data
  1. Scope the data flows
  2. Agree the structure
  3. Draft and negotiate
  4. Launch and adapt
Overview

How open banking and embedded finance work in Bangladesh

Open banking describes arrangements in which a bank or payment institution lets authorised third parties access account data or initiate payments through secure application programming interfaces, usually with the customer's permission. Embedded finance goes a step further, placing loans, wallets, insurance or payments inside non-financial apps such as marketplaces, ride-hailing or supply-chain platforms. Bangladesh does not yet have a single open banking statute, so these relationships rest mainly on contract, Bangladesh Bank directions and data protection law. We draft and negotiate the agreements that hold them together, as part of our technology practice in Bangladesh.

The backdrop is layered. Banks act under the Bank Company Act 1991 and Bangladesh Bank's guidance on outsourcing and ICT security. Payment initiation and wallet features may engage the Payment and Settlement Systems Act 2024 and the licensing regime for payment system operators and payment service providers. The Personal Data Protection Act 2026 now governs the handling of customer personal data. An open banking or embedded finance agreement must work within each of these regimes at once, which means the contract has to identify which party is regulated for which activity and how each one evidences compliance to the regulator.

Consent is central but rarely enough. A customer consent screen may authorise a third party to view balances or transaction history, yet the agreement still has to define the purpose of access, what data fields are shared, how long they are kept, whether they may be used for analytics or credit scoring and what happens when consent is withdrawn. Many open banking disputes arise because the commercial team assumed consent covered a new use that the customer never saw. We draft purpose limitation, data minimisation and withdrawal mechanics that operations teams can implement in the product and audit later.

Technical dependence creates legal exposure. When several parties rely on one interface, an outage, a security breach or a faulty data feed can cause losses for customers, the bank and the platform at once. Open banking agreements therefore need clear API specifications, service levels, security standards, incident notification timelines, testing rights and rules for planned changes and version retirement. We work with in-house technology teams to translate these into enforceable obligations, and coordinate with our data protection team on breach response, cross-border hosting and access by group companies abroad.

Embedded finance also raises commercial and consumer questions. A marketplace offering instalment credit through a partner lender must manage disclosure, pricing, complaints, collections and branding so customers understand who provides the service. Revenue sharing, data monetisation and exclusivity terms must reflect competition and foreign exchange rules where a foreign platform is paid from Bangladesh. Barrister Tahmidur Rahman and Barrister Remura Meheruba Mahbub lead our open banking and embedded finance work, drawing on banking, finance and foreign investment experience, and we coordinate with counsel in the UK, US, UAE, Singapore and India for regional and group-wide programmes.

01 · What we handle

Core workstreams

  • Participant map and agreement design
  • Consent, purpose and access rules
  • Security, API standards and service levels
  • Personal data protection compliance
02 · How it runs

Four clear stages

  1. 01Scope the data flows
  2. 02Agree the structure
  3. 03Draft and negotiate
  4. 04Launch and adapt
03 · Start here

Talk to a partner

Consultations in Dhaka or by video. Scope, team and fees are agreed in writing first.

Book →
How we help

What our API and embedded-finance work covers

Workstream 01Technology, IP & Data

Participant map and agreement design

  • Scope the data flows
  • Agree the structure
  • Draft and negotiate
  • Launch and adapt
Workstream 02Technology, IP & Data

Consent, purpose and access rules

  • Scope the data flows
  • Agree the structure
  • Draft and negotiate
  • Launch and adapt
Workstream 03Technology, IP & Data

Security, API standards and service levels

  • Scope the data flows
  • Agree the structure
  • Draft and negotiate
  • Launch and adapt
Workstream 04Technology, IP & Data

Personal data protection compliance

  • Scope the data flows
  • Agree the structure
  • Draft and negotiate
  • Launch and adapt
Workstream 05Technology, IP & Data

Embedded lending, payments and insurance

  • Scope the data flows
  • Agree the structure
  • Draft and negotiate
  • Launch and adapt
Workstream 06Technology, IP & Data

Liability, disputes and exit

  • Scope the data flows
  • Agree the structure
  • Draft and negotiate
  • Launch and adapt
01

Participant map and agreement design

We identify each participant, from account provider and aggregator to platform, lender, processor and cloud host, and design an agreement structure that reflects real data and money flows. That may include a master API access agreement, product schedules, data-sharing terms, technical specifications and operating manuals, with a clear hierarchy so conflicting documents are resolved predictably and quickly. Each document has a named owner on both sides.

02

Consent, purpose and access rules

We define who obtains customer consent, how it is recorded, what each party may access and for which purposes. Our open banking drafting covers scope of data fields, frequency of access, secondary use for analytics or credit decisions, consent dashboards, withdrawal, and how changes to the product are tested against the consent customers originally gave in the app. Consent records are kept in an auditable form.

03

Security, API standards and service levels

We translate technical expectations into contract terms: authentication and encryption standards, penetration testing, vulnerability management, uptime and response commitments, rate limits, change notices and version retirement. We also cover incident reporting, cooperation with Bangladesh Bank and other authorities, and audit or assessment rights proportionate to the sensitivity of the data and payments involved. Obligations are matched to realistic technical capacity.

04

Personal data protection compliance

We align each data flow with the Personal Data Protection Act 2026, identifying controllers and processors, lawful bases, retention periods and cross-border transfer requirements. For open banking platforms with regional infrastructure, we address offshore hosting, group access, subcontractors and the documents a sponsoring bank will need before it allows customer data to leave Bangladesh. Transfer documents are kept ready for bank review.

05

Embedded lending, payments and insurance

For embedded finance features we draft distribution, referral and programme agreements between platforms and licensed providers, covering disclosure, pricing display, complaints, collections, marketing approvals and brand use. We check that the platform does not drift into regulated activity it is not licensed to perform, and that customers can see clearly which entity is responsible for the service. Each disclosure is reviewed against the live product.

06

Liability, disputes and exit

We allocate liability for data errors, unauthorised access, payment failures and fraud according to each party's control, with caps, carve-outs and indemnities that reflect regulatory exposure. Exit provisions cover suspension for security reasons, regulatory intervention, change of control, data return or deletion, customer notices and orderly migration to a replacement partner where the service continues. These terms are tested against realistic incident scenarios.

RecognitionThe Legal 500Asia Pacific ranks Tahmidur Remura Wahid (TRW) Law Firm for dispute resolution in Bangladesh.
Cross-border reach6 jurisdictionsMatters coordinated with counsel in the UK, US, UAE, China, India and Singapore.
Bar and admissionsDhaka and LondonBarristers and advocates in Bangladesh, with a solicitor of England and Wales (non-practising).
HeadquartersDhakaHouse 410, Road 29, Mohakhali DOHS. Consultations in person or by video.
Who leads this work

Partner-led, on every matter.

Technology, IP & Data matters at TRW are led by partners, supported by associates, with one responsible lawyer from first advice to final outcome.

Meet the firm →
01

Is there an open banking law in Bangladesh?

There is no single open banking statute equivalent to the regimes in the UK or EU. Instead, open banking style arrangements in Bangladesh are shaped by Bangladesh Bank's directions on banking, payments, outsourcing and ICT security, the Payment and Settlement Systems Act 2024 where payments are involved, and the Personal Data Protection Act 2026 for customer data. Bangladesh Bank continues to issue guidance on digital finance, so we check the current position for each product and build regulatory change provisions into the agreement so it can adapt without full renegotiation. We revisit this as new guidance is issued.

02

Can a bank share customer data with a fintech through an API?

It can, but only within limits. Banks owe customers duties of confidentiality and must comply with data protection law and Bangladesh Bank expectations. Sharing usually depends on clear customer consent or another lawful basis, a defined purpose and adequate security at the receiving end. The open banking agreement should restrict what the fintech may do with the data, prohibit onward sharing without permission, require deletion when consent ends and give the bank audit rights. We review the data fields and use cases before advising on the right structure and consent wording. Clear deletion records also help in later disputes.

03

Who is liable if an open banking API fails or data is breached?

Liability should track control and fault. If the bank's interface goes down, the bank should usually bear responsibility under agreed service levels; if a fintech's systems are compromised, the fintech should bear the consequences. Shared incidents need a process for investigation, customer communication and allocation of losses once the cause is known. We draft indemnities, caps and carve-outs that reflect this, with specific provisions for regulatory fines, customer refunds and third-party claims, so open banking partners are not left arguing about responsibility while customers wait for answers. Customer refunds should not wait for that allocation.

04

Does a marketplace offering instalment loans need a lending licence?

Usually the marketplace does not need its own licence if a licensed bank or financial institution makes the loan and the marketplace only refers or displays the product. Problems arise when the platform starts setting credit terms, collecting repayments or holding funds, which may amount to regulated activity. We review the customer journey, the flow of money and the marketing materials, then structure the embedded finance arrangement so the licensed lender keeps the regulated functions and the platform's role is clearly documented in the agreement and in customer-facing terms. We also review the platform's marketing language.

05

How should customer consent be captured for open banking access?

Consent should be specific, informed and easy to withdraw. In practice that means a clear screen showing which party will access which data, for what purpose and for how long, recorded in a way that can be evidenced later. The Personal Data Protection Act 2026 adds formal requirements that consent wording and records must meet. We draft consent language, privacy notices and record-keeping obligations for open banking journeys, and include contractual duties to update them when the product changes, so consent stays valid as features evolve after launch. Consent records should be retained for the agreed period.

06

Can customer data from an open banking arrangement be stored outside Bangladesh?

Possibly, depending on the data, the regulated status of the parties and the transfer rules in the Personal Data Protection Act 2026. Banks may also face Bangladesh Bank expectations on where certain records and systems are hosted. A foreign fintech using regional cloud infrastructure should expect the bank to ask for detailed hosting information, security certifications and audit rights. We map the data flows and advise on transfer mechanisms, localisation questions and the contractual protections needed before any data leaves the country, coordinating with overseas counsel where group entities are involved. Transfer terms should be reviewed periodically.

07

How are API fees and revenue shares structured?

Models vary: per-call fees, monthly access fees, revenue shares on loans or payments, or free access in exchange for distribution. Where a foreign party is paid, foreign exchange documentation and withholding tax become relevant, and payments for data or technology may be characterised differently for tax purposes. We draft fee mechanics, invoicing, audit and set-off provisions, and coordinate with tax advisers so the open banking commercial model can be implemented and remitted lawfully. We also address price changes, most-favoured terms and any exclusivity requested by either side. Fee changes should require advance written notice.

08

What happens when an open banking partner is suspended or exits?

The agreement should allow immediate suspension for security threats or regulatory instructions, with a defined process for restoring access once the issue is fixed. On exit, it should set out notice periods, customer communications, data return or deletion, continuing confidentiality and cooperation with any replacement provider. For embedded finance products, outstanding loans, wallets or policies must be serviced until they end or are transferred. We draft these provisions so exit does not harm customers or expose either party to regulatory criticism, and so disputes can be resolved through our dispute resolution team if needed.

How a matter runs

From first call to resolution.

  1. 01

    Scope the data flows

    We map the customer journey, API calls, data fields, payment flows and licences of each party, then identify where Bangladesh Bank, payment systems and data protection requirements apply to the open banking or embedded finance model.

  2. 02

    Agree the structure

    We recommend the agreement set, consent design and any regulatory engagement needed, and agree a term sheet covering roles, fees, security standards, liability principles and exit before detailed drafting begins. Open points are tracked in one shared list.

  3. 03

    Draft and negotiate

    We prepare or review the API access, data-sharing and programme agreements, negotiate with counterparties and coordinate with technology teams, tax advisers and foreign counsel on technical schedules and cross-border points. Technical schedules are reviewed line by line.

  4. 04

    Launch and adapt

    We support go-live, consent and privacy documentation, then advise on new features, partners, regulatory guidance and incidents, keeping open banking documents aligned with the live product as it grows. Periodic reviews keep schedules current.

“Demonstrates an extraordinary command over both domestic litigation and international arbitration.”

The Legal 500 Asia Pacific, Bangladesh: Dispute resolution, client feedback

FAQ

Questions, answered.

Still unsure? Email info@trw.co with a short outline of the matter.

What is open banking?
Open banking is a model in which banks allow authorised third parties to access customer account information or initiate payments through secure APIs, normally with the customer's permission. It enables services such as account aggregation, faster onboarding, credit assessment and in-app payments. In Bangladesh it operates mainly through contracts and regulatory guidance rather than a dedicated statute, so the quality of the agreement between the bank and the third party matters a great deal in practice. Clear allocation of roles, consent, security and liability is what turns a technical connection into a dependable commercial relationship.
How is embedded finance different from open banking?
Open banking is mainly about access to bank data and payment functions. Embedded finance is about placing a financial product, such as a loan, wallet or insurance cover, inside a non-financial platform's customer journey. The two often overlap, because embedded products usually depend on API connections, but embedded finance raises extra questions about distribution, disclosure, branding, complaints and whether the platform is carrying on regulated activity without a licence. Both models also need clear rules on who owns the customer relationship, who handles complaints and who may use the resulting data.
Do open banking agreements need Bangladesh Bank approval?
Not every arrangement needs approval, but some features may require prior consent, notification or compliance with specific circulars, particularly where payments, outsourcing of material functions or new digital products are involved. Requirements change regularly as Bangladesh Bank develops its digital finance framework. We check the current position for the specific product at the time of structuring and build approval conditions and timing into the agreement and the launch plan. Planning approvals early also helps the parties set a realistic launch date and avoid last-minute changes to the product design or customer journey.
Can a foreign aggregator connect directly to Bangladeshi banks?
Technically it may be possible, but banks will usually require a local contracting entity or a licensed partner, detailed security assurances and clarity on where data will be hosted. Foreign exchange rules also affect how the aggregator is paid. Registration of foreign-owned local entities now runs through Invest Bangladesh. We advise on whether a direct connection, a local subsidiary or a partnership with a licensed provider is the most workable route. Each option has different tax, licensing and operational consequences, which we explain before the commercial negotiation begins in earnest.
What security standards should an open banking agreement include?
It should cover authentication, encryption, access control, logging, vulnerability management, penetration testing and incident response, usually by reference to recognised industry standards and Bangladesh Bank's ICT security expectations. The agreement should also allow the bank to verify compliance through certifications, reports or audits. We draft these terms so they are specific enough to enforce but flexible enough to update as threats and standards change over time. Security obligations should also extend to subcontractors and cloud providers, with flow-down terms and notification duties that match the main agreement.
Can data received through an API be used to build credit scoring models?
Only if the purpose is permitted by the customer's consent or another lawful basis, and if the agreement with the data provider allows it. Using data for model training or scoring is a distinct purpose that customers and banks may not expect. We draft use restrictions, anonymisation rules and model ownership terms, and review consent wording, so that credit analytics built on open banking data are defensible under the Personal Data Protection Act 2026. Clear documentation of how models are trained and validated also helps answer questions from customers, partners and regulators later on.
What should a platform check before embedding a partner's loan product?
It should confirm the partner holds the right licence, understand which customer-facing functions it will perform itself, review disclosure and pricing obligations, and agree how complaints and collections are handled. It should also check revenue sharing, data use, branding and exit terms. A short legal review at the start prevents the platform being treated as the lender or blamed for practices it does not control. The platform should also check how the partner treats customer data and whether it may market other products to the platform's customers.
Can TRW help negotiate with a bank's standard API terms?
Yes. Banks often present standard API access terms that favour the bank, impose broad liability and limit use of data. We review those terms against the fintech's product, highlight provisions that are unworkable or out of market, and propose targeted changes. For banks, we prepare or update standard open banking terms that protect the bank's regulatory position. We can also prepare a short negotiation note for internal approval committees. You can contact our Dhaka office to discuss a project.

Connect your financial services with clear, enforceable agreements

Speak with the partners about Open banking in Bangladesh or across borders.

Book a consultation →
Open banking: TRW & Co, Dhaka
Message TRW on WhatsApp