High-Risk Merchant Account Bangladesh: Onboarding, Reserves and Settlement
By PayEurasia Team · 11 August 2026 · 11 min read
Last updated 11 August 2026

Getting approved is the easy half. This guide covers the documentation, reserve mechanics and operating discipline that keep a high-risk Bangladeshi merchant account open.
Most merchants treat a high-risk merchant account as a one-off approval gate. Providers treat it as an ongoing relationship they can withdraw from at any time. That asymmetry explains almost every unpleasant surprise in this category: the reserve that appears later, the limit that does not rise, the account that closes after a dispute spike. This guide describes what Bangladeshi onboarding actually requires and what keeps the account alive afterwards.
What this guide covers
- The document pack, in the order it is reviewed
- Why applications are rejected
- Reserves and limits: the arithmetic
- Settlement mechanics in BDT
- Compliance obligations that stay with the merchant
- Disputes and refunds
- Reasons accounts get closed after approval
- Multi-provider structure and why it is not disloyalty
The document pack, in the order it is reviewed
Certificate of incorporation and current corporate registry extract for the operating entity. Ownership structure down to ultimate beneficial owners, with identification for each. Director identification. A live, working URL for the product, with the terms, refund policy and contact details already published. Bank details for the settlement account, in the entity's name.
Then the commercial layer: expected monthly volume, average and maximum ticket size, target markets, refund rate history, chargeback or dispute history, and prior processing statements if you have them. Providing prior statements voluntarily is the strongest positive signal available to a new applicant.
Why applications are rejected
The recurring causes are mundane. A website that does not describe what is being sold. A refund policy that contradicts the checkout. An entity registered in one jurisdiction while the traffic and the bank account sit in two others, with no explanation. A volume forecast that does not match the site's apparent scale. Beneficial ownership that cannot be traced.
Note what is not on that list: being in a high-risk vertical. Providers underwrite high-risk verticals routinely. What they will not underwrite is a business they cannot describe accurately to their own compliance committee.
Reserves and limits: the arithmetic
A rolling reserve holds a percentage of each settlement for a defined period before releasing it. At 10% held for 90 days, a merchant settling BDT 10,000,000 per month has roughly BDT 3,000,000 permanently in transit at steady state. That is a working-capital decision, and it should be modelled before you sign, not discovered in month four.
Limits work the same way. Launch limits are deliberately conservative — per-transaction caps, daily caps, sometimes per-customer caps. They rise on evidence: clean settlement, low dispute rate, accurate forecasting. Ask at onboarding exactly what evidence triggers a review, and diarise the review date yourself.
Settlement mechanics in BDT
Collections happen in BDT on local rails. Your settlement statement should itemise gross volume, provider fees, refunds, reserve withheld, reserve released and net transferred, per settlement period. If a statement does not let you reconstruct the net figure line by line, ask for one that does before you go live.
Where conversion happens — and against which rate source and at what time of day — is the term most often left vague. Fix it in writing. The cross-border payments guide for Bangladesh covers the treasury side in more detail.
Compliance obligations that stay with the merchant
KYB sits with the provider, but the merchant retains obligations: sanctions screening of its own counterparties where relevant, honest marketing, an accessible refund process, secure handling of customer data, and record retention adequate to answer questions months later. Providers pass regulatory pressure through to merchants; being unable to respond is itself a risk finding.
Appoint a named person responsible for payments compliance, even in a small team. Accounts that survive scrutiny tend to have one owner who can answer questions without convening a committee.
Disputes and refunds
On wallet and bank rails the dispute mechanics differ from card chargebacks, but the commercial effect is the same: reversed value, provider attention and reputational cost. Keep the refund path fast and visible. A customer who can get a refund in one click does not escalate to the wallet operator, and escalations are what damage a merchant's standing.
Track a dispute ratio weekly and treat any upward trend as an operational incident, not a finance line item. Providers act on trend, not on absolute numbers.
Reasons accounts get closed after approval
Volume materially exceeding the declared forecast without notice. A product change that moves the merchant into a different risk category — adding a trading feature, adding user-to-user transfers, adding a new geography. A dispute spike. Structuring transactions to stay under limits. Payouts to destinations unrelated to the depositing customer.
All of these are avoidable with one habit: tell the provider before the change, not after. A merchant who calls ahead about a 4x volume month gets a temporary limit increase. A merchant who simply pushes the volume gets a hold.
Multi-provider structure and why it is not disloyalty
Serious merchants in this market maintain more than one route. It is not a signal of bad faith and providers know it; it is standard operational resilience in a market where a single wallet maintenance window can stop a day's revenue. Structure it explicitly — a routing layer with health-aware failover — rather than by quietly keeping a spare integration in a drawer.
The engineering requirement is modest: one internal transaction model, provider-agnostic references, a single signed webhook contract that your handlers already understand, and per-provider health signals.
Frequently asked questions
How long does high-risk onboarding take in Bangladesh?
Typically a few weeks from a complete document pack to production credentials, with most delay caused by incomplete ownership documentation rather than by underwriting itself.
Is a rolling reserve negotiable?
The starting percentage rarely is. The review date usually is. Agree in advance what evidence triggers a reduction, then produce it.
Can I use a personal bank account for settlement?
No. Settlement goes to an account in the operating entity's name; a mismatch is a hard stop in underwriting.
What happens if my dispute rate rises?
Expect a limit reduction or a reserve increase before any closure. Respond with a written remediation plan; providers respond well to merchants who diagnose their own problem.
Do I need a local Bangladeshi entity?
Not necessarily. Foreign entities are underwritten through providers holding the local relationships, though the documentation and settlement structure will be examined more closely.
Where PayEurasia fits
PayEurasia operates local collection and payout rails across Bangladesh, India, Pakistan and Nepal behind one API, one reconciliation model and one settlement relationship, with provider redundancy so a single acquirer incident degrades performance instead of stopping payments. The high-risk payment solution for Bangladesh page describes the local coverage, the API documentation covers authentication, webhooks and errors, and merchant onboarding lists what underwriting requires.
Related guides
Talk to PayEurasia
Working in a high-risk vertical across South Asia? We can probably help.
Request integration →