Fintech Payments & PSP Licensing

by Tahmidur Remura Wahid | Sep 5, 2025 | Uncategorized | 0 comments

Fintech Payments & PSP Licensing in Bangladesh — A TRW Law Firm Guide

Prepared by Tahmidur Remura Wahid (TRW) Law Firm — Bangladesh’s cross-border fintech, regulatory, and banking practice with desks in Dhaka, London, and Dubai. This guide is designed for founders, PSPs/PSOs, payment gateways, card acquirers, telco-fintechs, banks, NBFIs, super-apps, and global investors evaluating market entry or scale-up in Bangladesh.

Executive Summary

Bangladesh’s digital payments market sits at the confluence of rapid smartphone adoption, expanding merchant digitization, and a maturing oversight framework by Bangladesh Bank (BB) and allied agencies. On one side are payment institutions (PSPs, gateways, aggregators) that facilitate merchant acceptance and consumer pay-ins/pay-outs; on the other are system operators (PSOs and national rails) that power switching, clearing, settlement, QR standards, and account-to-account flows. Around both are mobile financial services (MFS), agent banking, and card schemes. Together, they create a rich but compliance-sensitive landscape: licensing, AML/CFT, data localization, consumer protection, cybersecurity, and operational resilience are no longer “nice to have” — they are the rails that determine who scales and who stalls.

For foreign companies, three realities dominate:

Bangladesh is a managed FX and data-sensitive jurisdiction; cross-border flows, merchant pay-outs, and data transfers require structured pathways through Authorised Dealer (AD) banks and clearly documented purposes.
Payment licenses here are activity-defined (what you do) and infrastructure-dependent (how you connect to rails and settle). The right license often begins with a candid mapping of your actual flow of funds.
Contracting architecture matters: govern the master stack in English law (London) or DIFC/ADGM law (Dubai) for predictability and netting/safeguarding certainty, but localize regulatory undertakings, settlement accounts, and data controls to meet Bangladesh’s on-shore requirements.

This guide gives you the practical playbook: what license you really need, how to pass scrutiny at BB, what to build in your AML/CFT, cybersecurity, and safeguarding frameworks, how to structure merchant agreements, and how to close gaps between Dhaka operations and your London/Dubai treasury and governance. We also include checklists, a timeline to authorization, and a Bangladesh × London × Dubai comparison table.

Throughout, we include only internal links for deeper TRW context:

1) Glossary & Scope: What Counts as PSP, PSO, MFS, and “Payment Gateway”?

Before you pick a license, define your activity. Bangladesh uses function-oriented categories similar to other markets, but with local nuances.

1.1 Payment Service Provider (PSP)

A PSP facilitates payments without operating a national switch. Typical PSP functions include:

Payment gateway/aggregator acquiring for e-commerce and POS (merchant onboarding, tokenization, routing to acquirer/bank);
Payout orchestration (disbursing to bank accounts, MFS wallets, or cards through partner banks/rails);
QR/pay-by-link initiation at merchants using standard QR protocols;
Value-added services (fraud scoring, BNPL facilitation with partner lenders, split payments, subscriptions).

What PSP is not: PSPs do not normally run interbank switching/clearing — that tends to fall under PSO or national rail.

1.2 Payment System Operator (PSO)

A PSO operates a payment system infrastructure such as a switch, scheme, or clearing system. PSO status brings heavier prudential, governance, and operational resilience expectations (uptime SLAs, business continuity, incident reporting).

1.3 Mobile Financial Services (MFS) & e-Money

MFS is a regulated model (often bank-led) enabling wallet-based services, agent networks, cash-in/out, P2P, merchant payments, and bill pay. An e-money issuance capability changes the license perimeter materially (safeguarding, float treatment, redemption). Many newcomers discover they do not need to issue e-money; partnering with MFS banks or issuing banks while holding a PSP authorization is often faster and capital-lighter.

1.4 Card Acquiring vs. Gateway

A gateway provides technical connectivity and merchant UX; the acquirer underwrites merchant risk and settles funds. In Bangladesh, a PSP can deliver gateway/aggregation while settlement occurs via an acquiring bank. If you want to acquire directly, expect additional conditions (capital, PCI DSS, chargeback/ADR processes, fraud ops).

2) Do You Need a PSP or a PSO? (Decision Map)

Use this “activity-to-license” map:

I only onboard merchants and route transactions to banks/MFS: PSP (gateway/aggregator) with acquiring partnerships.
I provide account-to-account or card switch infrastructure across institutions: PSO (system operator).
I issue stored value/e-money and run a wallet with agents: MFS/e-money permission (bank-anchored or as otherwise allowed).
I only build software for merchants (no handling of funds): no payment license, but outsourcing/security and merchant contracts still matter.

Foreign groups frequently combine: a Bangladesh PSP OpCo + London/Dubai holding/treasury + on-shore settlement with AD banks. That tri-hub set-up lets you leverage global governance and capital while respecting local flow-of-funds rules.

3) The PSP Licensing Journey in Bangladesh — What Actually Happens

Licensing is not just a form; it’s proof that your company can safely handle money, data, and consumers at scale. Expect four tracks to run in parallel:

3.1 Corporate & Shareholding Preparation

Incorporate a Bangladesh company, align objects in the Memorandum to payments/technology, and finalize shareholding that passes “fit & proper” muster.
Set board composition (independent director expectations may arise by policy), designate CEO/CTO/CISO/MLRO (or equivalents), and adopt initial policies (AML/CFT, Risk, IT, Data, Outsourcing).

3.2 Pre-Application with Bangladesh Bank (recommended)

A structured pre-filing helps you validate scope: PSP vs PSO; whether any MFS/e-money capabilities creep in; which settlement rails and partner banks you will use; and whether a pilot/sandbox is advisable.
Present a target state architecture: gateways, switching partners, tokenization, MDR logic, merchant KYC, fraud stack, data centers (primary & DR), and incident response.

3.3 The Formal Application

Typical core components include:

Business plan with clear use-cases (e-commerce, POS, QR, subscription, payouts), five-year financials, and risk appetite.
Capitalization & safeguarding model (client funds segregation; settlement/escrow account mandates; reconciliation and break treatment; insolvency estate protections).
IT & Cybersecurity: PCI DSS posture (if card data touches you), ISO 27001/ SOC2 trajectories, encryption at rest/in transit, HSM strategy, VAPT cadence, SIEM/SOC plans, key management, DR/BCP with RTO/RPO targets.
AML/CFT framework: end-to-end KYC (merchant + payer where relevant), sanctions screening, transaction monitoring scenarios, STR/SAR escalation to BFIU, threshold reporting, EDD for high-risk sectors, PEP handling, and documented risk assessment (ML/TF risk by product, channel, geography, customer).
Consumer protection: disclosures, opt-in/opt-out, complaints handling with SLAs, refunds/chargebacks, transparent fees, and data privacy notices.
Outsourcing & third parties: processor/host/cloud due diligence, data localization commitments, incident notification clauses, and audit/inspection rights for you and BB.

3.4 Inspections & Go-Live Conditions

Expect a technology and security inspection and a review of pilot results (if any).
BB typically conditions go-live on settlement bank arrangements, final operating policies, signed merchant T\&Cs, and a go-live migration plan with rollback procedures.

TRW manages these confluently, aligning regulatory arguments with contract drafting (merchant/acquirer agreements, data processing addenda, bank settlement mandates). See our pages on Regulatory (Bangladesh Bank) and Loan Documentation for related documentation styles and closing packs.

4) Safeguarding, Settlement & Flow of Funds (The Heart of PSP Compliance)

A PSP succeeds or fails on how it holds, protects, reconciles, and releases money. Build these blocks early:

4.1 Segregated Accounts & Escrow

Maintain client money accounts and settlement/escrow with an AD bank. Settlement rules (daily/ T+1/T+2) must be codified.
Hold surplus funds and reserves per policy; do not commingle with operating cash. Define break scenarios (merchant disputes, refunds, partial captures).

4.2 Reconciliations

Daily three-way reconciliation: PSP ledger ↔ bank statements ↔ processor/scheme reports. Exceptions tracked, aged, and escalated.
Unclaimed balances: time-bound treatment (return to source, escheatment equivalent if prescribed).

4.3 Chargebacks & Disputes

Define liability allocation (merchant vs acquirer vs gateway). Keep clear refund windows and evidence packs (proof of delivery, AVS/3DS data, payer consent).

4.4 Fraud & Risk Controls

Velocity rules, device fingerprinting, behavioural analytics, bot detection, and MCC blacklists for merchants. Monitor synthetic identities, brute-force token testing, and friendly fraud.

4.5 Data Protection

Data minimization: avoid storing PANs unless strictly necessary (tokenize). Encrypt sensitive fields, segregate keys, and audit access. Establish data residency posture compliant with BB expectations (primary DC in Bangladesh and DR posture consistent with policy).

5) AML/CFT for PSPs (Design Once, Prove Daily)

The central bank and BFIU expect risk-based AML:

Onboarding
■ Merchant KYC with UBO verification; enhanced due diligence for high-risk MCCs (gaming, adult, crypto, high-chargeback verticals).
■ Payer due diligence where you hold balances or provide payout wallets (e.g., P2P/B2C payouts).
■ Sanctions/terrorist list checks at onboarding and continuously thereafter.
Monitoring
■ Rules for structuring, suspicious velocity, mule activity, chargeback sweeps, refund abuse, collusive merchant rings.
■ Periodic segmentation reviews (low/medium/high risk) and scenario tuning (precision/recall feedback loops with manual review).
Reporting
■ STR/SAR workflows to BFIU; training calendars; compliance testing; independent audits.
■ Recordkeeping horizons and data retention mapped to product risk.
Governance
■ Appoint a MLRO with authority to halt onboarding, freeze payouts, and escalate.
■ Quarterly AML/CFT reports to the board; annual enterprise-wide AML risk assessment.

TRW aligns AML text with your merchant T\&Cs, privacy policy, and acquirer mandates, ensuring contract language supports real-world holds, reversals, and KYC re-checks.

6) Information Security & Operational Resilience (What Examiners Test)

Frameworks: Adopt ISO 27001-aligned ISMS; for card data, PCI DSS scoping with clear data flow diagrams; SOC 2 reporting for major enterprise clients.
Controls: MFA for all admin access; PAM for privileged accounts; key rotation and HSMs for cryptographic operations.
Vulnerability Management: Quarterly VAPT, monthly patch windows, asset inventory, SBOM for critical components.
Monitoring: SIEM with alert runbooks, DDoS strategy, WAF/CDN shields; table-top exercises for fraud spikes and processor outages.
BCP/DR: Secondary site (DR) with tested RTO/RPO; quarterly failover drills; incident notifications to BB and affected counterparties within policy timelines.
Third Parties: Outsourcing register; right-to-audit clauses; uptime SLAs; incident co-ordination obligations.

7) Contracts That Make or Break a PSP

Merchant Agreement

KYC warranties; prohibited uses; refund/chargeback protocols; rolling reserves; MDR and fee schedules; data protection; IP and branding; audit/inspection; termination; set-off; liability & indemnity; law/venue.
For subscriptions/recurring: explicit consent capture, mandate management, and stop-charge protocols.

Acquirer/Bank Agreement

Settlement SLAs; reserve mechanics; scheme compliance; chargeback liability; fraud thresholds; data sharing; incident reporting; termination events.

Processor/Cloud Contracts

Data residency; subcontracting; security standards; audit rights; breach notification; exit/portability; escrow of critical code or configuration baselines.

Consumer-Facing Policies

Privacy policy; cookie and tracking policy; consent management; complaints handling; disclosures for fees and FX (if any).

TRW drafts these to dovetail with Bangladesh regulatory expectations and your global governance. For drafting style and risk allocation, see Loan Documentation and Secured Lending & Syndication (methodologies carry over to high-stakes commercial contracts).

8) The PSO Pathway (If You Operate a Payment System)

Operating a switch or scheme triggers heightened prudential and operational duties:

Scheme Rules: membership, certification, settlement cycles, dispute resolution, risk management, default handling, and exit procedures.
Technology: active-active DCs, sub-second failover where feasible, capacity headroom, and formal change-management.
Clearing/Settlement: finality rules, prefunding/guarantee arrangements, collateral standards, and waterfall for default.
Legal Opinions: settlement finality, netting, and collateral enforceability (often English/DIFC law overlays for inter-participant agreements with Bangladesh recognition).
Oversight: regular reporting to BB; third-party audits; resilience metrics (availability, MTTR, incident counts).

If you’re a foreign scheme interconnecting with local rails, structure bilateral gateways through local PSPs/PSOs and document data handling and settlement meticulously.

9) Cross-Border Reality Check — Dhaka × London × Dubai

9.1 London (UK)

Regulatory benchmark: UK Payment Services Regulations (PSD2-aligned), E-Money Regulations, strong safeguarding and SCA doctrines, and open banking APIs.
Practical lesson: Build segregation and reconciliation muscle to UK standards — it will exceed local minima and impress examiners, investors, and partners.
Contracting: English law for master agreements; arbitration or English courts; clear netting and set-off mechanics.

9.2 Dubai (UAE) — DIFC/ADGM & UAE Central Bank

Regulatory benchmark: modern payment service regimes; stored value frameworks; strong outsourcing and cloud expectations; clear incident reporting.
Practical lesson: Use Dubai as a regional ops and governance hub for MENA while keeping Bangladesh data and settlement on-shore per BB expectations.
Islamic finance: Where your merchant base or investors prefer Shariah alignment (MDR as agency fee; no interest on reserves), Dubai offers a familiar ecosystem. See Islamic Finance.

Tri-hub playbook
Seat group-level policies, security architecture, and capital in London/Dubai; run on-shore settlement and data in Bangladesh; connect with AD banks for remittance and client money protection. Let global governance set the ceiling — localize for BB scrutiny.

10) Foreign Entrants: What You Must Be Careful About

■ License fit: Don’t apply for PSO if you only gateway/acquire; over-licensing slows approval and increases scrutiny. Map activities precisely to PSP scope first.
■ Cross-border flows: PSP does not equal automatic cross-border acquiring. For FX receipts and outward pay-outs, design AD bank pathways and include documentary purpose codes and invoices.
■ Data residency & cloud: Expect primary data center in Bangladesh and a policy-consistent DR posture; if you use global cloud, ensure landing zones and data boundaries meet on-shore expectations and are provable to auditors.
■ AML for merchants: High-risk MCCs need EDD, rolling reserves, and enhanced monitoring; under-pricing these segments is a common failure.
■ Chargeback math: Your economics live or die on MDR vs. fraud/chargeback/ops cost. Don’t sell sub-1% MDR to risky MCCs without a reserve/fee model that scales.
■ Contracts: Weak merchant T\&Cs create dispute leakage and uncollectible chargebacks. Use set-off, reserve, termination for fraud, and evidence pack duties.
■ Cyber incidents: Regulators expect prompt notification and lessons-learned with control uplifts; keep an incident runbook and designated spokespeople.
■ Corporate structure: Offshore holding with on-shore PSP is fine — but ensure related-party pricing, IP licensing, and intra-group SLAs stand up to tax and regulatory review.
■ Communications: Overpromising features (e.g., “instant international payouts”) can be marketing misrepresentation if your license and AD banking do not support them.

11) Implementation Timeline (Indicative)

Weeks 0–2 — Scoping & Readiness

Activity mapping (PSP vs PSO vs MFS); product roadmap; flow-of-funds diagrams.
Term-sheet with banks/processors; draft governance and policy stack.
Pre-application note and meeting plan with BB.

Weeks 3–6 — Drafting & Pre-Filing

Corporate resolutions; board/management appointments; CEO/CTO/CISO/MLRO mandates.
Draft AML/CFT, ISMS, BCP/DR, Outsourcing, Data Protection, Fraud, Merchant Onboarding Policies.
Merchant and acquirer/processor agreement templates.
Draft application dossier (business plan, financials, risk assessment, architecture).

Weeks 7–12 — Filing & Clarifications

Submit application; respond to queries; demonstrate settlement/escrow arrangements; provide third-party attestations (e.g., PCI scoping, VAPT).
Integrate feedback into policies and contracts; prepare for inspection/pilot.

Weeks 13–18 — Inspection & Pilot

Limited go-live with pilot merchants under heightened monitoring; polish reconciliations; stress test refunds/chargebacks.
Address inspection findings; finalize go-live conditions.

Week 19+ — Authorization & Launch

Authorization issued with conditions (if any); production cutover; incident simulations; board dashboarding and regulator reporting go active.

TRW keeps the streams synchronized, so regulatory, banking, technical, and legal artifacts evolve together. See Regulatory (Bangladesh Bank) for our BB-facing approach and NBFI Licensing & Compliance for our licensing methodologies (adapted for payments).

12) Sector-Specific Playbooks

12.1 Marketplaces & Super-Apps

Split settlements among sellers, platform fees, and taxes; escrow logic; negative balance and clawback rights.
Seller KYC at scale; mass payouts via bank/MFS; API-based reconciliation.

12.2 Ride-Hailing & Food Delivery

Wallet-lite experiences; pay-in (cards, A2A, MFS) and pay-out to drivers/riders; batch settlement windows; tip handling; instant transfer subject to fraud checks.

12.3 Subscription & SaaS

Recurring mandate management; SCA-equivalent challenge patterns; dunning flows; prorated refunds.

12.4 Cross-Border Freelance & BPO

AD bank evidence packs (invoices, contracts); FX conversion and fee disclosures; compliance with purpose codes; screening for prohibited services.

12.5 BNPL/Consumer Credit

Clarify that you do not lend unless licensed; partner with lenders/NBFIs; data-sharing and consent; dispute/chargeback flow redesigned for instalments.

13) Common Pitfalls (and How We Engineer Them Out)

■ Applying for the wrong license → Map features to activities; start with PSP unless you genuinely run a system.
■ Thin AML → Over-index on merchant KYC and transaction monitoring; document scenario logic and model tuning.
■ Data in the wrong place → Design data residency and backups intentionally; keep Bangladesh primary; document DR locality.
■ Weak reconciliation → Build daily tri-way reconciliations before launch; automate exception queues; audit trails.
■ MDR giveaways → Price by risk; use reserves for high-risk MCCs.
■ Contract gaps → Use robust merchant T\&Cs with set-off, reserve, KYC, and fraud covenants; align acquirer contracts to avoid liability arbitrage.
■ Incident opacity → Notify partners and regulators promptly; publish a post-mortem with controls you’ve strengthened.
■ Marketing vs. license scope → Have legal review for product copy; do not imply cross-border features you can’t lawfully deliver.

14) How TRW Helps (Dhaka • London • Dubai)

Licensing & Regulatory Strategy (Dhaka): end-to-end PSP/PSO applications, pre-filings, inspection readiness, policy drafting, bank settlement arrangements, and regulator liaison. See Regulatory (Bangladesh Bank).
Contracts: merchant/acquirer/processor/cloud; data sharing; privacy; incident coordination; escrow and safeguarding mandates. See Loan Documentation.
Governance & Controls: AML/CFT, ISMS, BCP/DR, fraud ops, risk dashboards; board education and audit preparation.
Cross-Border Architecture (London/Dubai): English or DIFC/ADGM law master stacks; intercompany SLAs; tax/transfer pricing alignment; global incident playbooks; Islamic structuring where needed.
Capital & Banking: introductions and term-sheet negotiation with settlement banks, processors, and acquirers; reserve mechanics; collateral or comfort arrangements. See Secured Lending & Syndication.
Scale & M\&A: share/asset acquisitions of local gateways, PSO interconnects, strategic JV structuring; regulatory change-of-control counsel.
Remediation: if you’ve grown before formalizing compliance, we design retrofit programs that pass inspection without interrupting revenue.

15) FAQs

Q1: Can a foreign company be 100% owner of a Bangladesh PSP?
Foreign ownership is common in tech and payments structures, subject to BB scrutiny and sectoral policies. Expect fit & proper reviews, source-of-funds checks, and comfort around control persons and management.

Q2: Do we need a PSO to do QR?
Not necessarily. PSP models can support merchant QR acceptance if you connect to the relevant rails and acquirer/bank partners. If you plan to operate switching/clearing for QR across institutions, that’s PSO territory.

Q3: Are cross-border merchant receipts allowed?
They require specific pathways through AD banks with documentation (contracts/invoices) and permitted purpose codes. A PSP authorization alone does not guarantee cross-border settlement rights.

Q4: Do we need PCI DSS?
If cardholder data touches your environment (beyond tokens), PCI DSS applies. Even if you tokenize, card schemes and acquirers may require SAQ-A/SAQ-A-EP evidence and routine scans.

Q5: What’s the difference between gateway and acquirer liability?
Gateways provide connectivity and UX; acquirers underwrite merchant risk and handle chargebacks. Your contracts must state who bears losses and when reserves or rolling holds apply.

Q6: How fast can we go live?
With a prepared team, realistic scope, and bank partners, ~5–6 months from scoping to authorization and initial pilot is achievable. Complex PSO builds or wallet features take longer.

16) Structured Summary Table — Bangladesh vs. London vs. Dubai (Fintech Payments & PSP)

Dimension	Bangladesh (Dhaka)	London (UK)	Dubai (UAE: DIFC/ADGM)
License Perimeter	Activity-based: PSP (gateway/aggregation), PSO (switch/scheme), MFS/e-money via separate path.	Payment Services & E-Money regimes; SCA & open banking standards.	Payment services framework; SVF-style and scheme regimes; strong outsourcing rules.
Settlement & Safeguarding	Client money segregation with AD banks; on-shore settlement priority.	Safeguarding accounts; daily reconciliations; auditors test controls.	Safeguarding and client money controls; regional banking depth.
Data & Cyber	Data residency expectations; primary DC in Bangladesh; VAPT/ISMS; incident reporting.	Mature privacy/security posture; PCI & SOC baselines; regulator notifications.	Cloud/outsourcing aligned to regulator; modern incident response expectations.
AML/CFT	Merchant KYC/UBO; sanctions; STR/SAR to BFIU; high-risk MCC controls.	PSD2-aligned AML with open banking consents; advanced analytics common.	Robust AML; regional screening tools; Shariah-compliant structures commonplace.
Contracts	Merchant/acquirer clarity; chargeback/refund rules; reserves; data clauses.	Mature templates with SCA, ADR, and scheme overlays.	DIFC/ADGM law contracts, Islamic options; cross-border enforceability.
Cross-Border	Managed FX; AD bank pathways & purpose codes required.	Full suite of cross-border options; strong scheme connectivity.	Regional hub for MENA; practical treasury/ops bridging to South Asia.

17) Copy-Paste Checklists

Licensing Readiness (PSP)

⬛ Activity map (gateway/aggregation/payouts/QR).
⬛ Org chart with CEO/CTO/CISO/MLRO and board approvals.
⬛ Business plan & five-year financials; risk appetite.
⬛ Settlement bank term-sheet; escrow mandates; daily recon process.
⬛ AML/CFT framework with risk assessment and STR/SAR runbooks.
⬛ ISMS (ISO 27001), PCI scoping, VAPT plan, SIEM/SOC.
⬛ Merchant, acquirer, processor, and cloud contracts.
⬛ Data residency and DR runbook; incident notification policy.
⬛ Complaints/chargeback policy; consumer disclosures.
⬛ Application dossier and pre-filing deck for BB.

Operations Day-1

⬛ Daily three-way reconciliations automated.
⬛ Exception queues and aging dashboards.
⬛ Fraud rules and manual review playbooks.
⬛ Reserve/hold logic by MCC and risk score.
⬛ Refund and chargeback timelines with evidence packs.
⬛ Quarterly DR drills; annual AML/ISMS audits.
⬛ Board dashboards (KPIs: approval rate, fraud, chargeback ratio, uptime).

18) How TRW Engages

Scope & Strategy: We map your features to the correct license and create regulator-ready flow-of-funds diagrams.
Banking & Settlement: We secure AD bank arrangements and escrow mandates, aligning client money and reconciliation design.
Policy & Controls: We draft AML/CFT, ISMS, BCP/DR, Outsourcing, and Fraud policies you can actually operate.
Contracts: We paper merchant/acquirer/processor/cloud agreements that allocate risk cleanly and support enforcement.
Authorization: We prepare and file your application, manage clarifications, and ready you for inspection and pilot.
Scale & Governance: We align Dhaka ops with London/Dubai governance, intercompany SLAs, and (if you wish) Islamic overlays.

Related TRW pages for deeper context:

Contact TRW (24/7)

Tahmidur Remura Wahid (TRW) Law Firm — Fintech, Payments & PSP Licensing
Phones: +8801708000660 | +8801847220062 | +8801708080817
Emails: [email protected] | [email protected] | [email protected]

Global Law Firm Locations

Dhaka: House 410, Road 29, Mohakhali DOHS
Dubai: Rolex Building, L-12 Sheikh Zayed Road.

Summary Table — Fintech Payments & PSP Licensing (Bangladesh • London • Dubai)

Topic	Bangladesh	London	Dubai
Primary License	PSP (gateway/aggregator); PSO (switch); MFS/e-money via separate path	Payment Services / E-Money	Payment services; SVF/scheme frameworks
Supervision Focus	Safeguarding with AD banks; AML for merchants; data residency; consumer protection	Safeguarding, SCA, open banking, incident reporting	Client money, outsourcing/cloud, incident reporting
Data Posture	Primary DC in Bangladesh; DR consistent with policy; encryption & VAPT	Mature privacy & PCI; strong audit trails	Regional cloud with residency control; audit rights
AML/CFT	Merchant KYC/UBO; sanctions; STR/SAR to BFIU; high-risk MCC EDD	PSD2-aligned KYC; advanced monitoring	Robust KYC/EDD; Shariah-compatible structures
Contracts	Merchant & acquirer clarity; reserves; chargebacks; data clauses	English-law templates; SCA & scheme overlays	DIFC/ADGM law; Islamic structuring options
Cross-Border	Managed FX via AD banks; purpose codes & documentation	Broad cross-border capabilities; scheme depth	MENA hub; practical treasury link to South Asia

Disclaimer

This article is a general overview and not legal, tax, or accounting advice. Regulations evolve, and each business model differs. For a tailored roadmap — from pre-filing to authorization, from bank settlement to production go-live — TRW’s fintech team in Dhaka, London, and Dubai can deliver a complete, regulator-ready build-out.

Loading…

Loading… | 5 MIN READ | BY TAHMIDUR REMURA WAHID