BDT Offramp

BDT offramp lets your users convert their stablecoin balance into Bangladeshi Taka, settled to a bank account in Bangladesh. Every offramp flow follows the same four steps: Create User → KYC → Bank Account Linkage → Transaction.

Both USDT and USDC are supported for BDT offramp.

Create User

POST /api/v2/user

{
  "email": "user@example.com",
  "phone": "+8801712345678"
}

Response:

{
  "success": true,
  "data": {
    "user_id": "550e8400-e29b-41d4-a716-446655440000"
  }
}

Save user_id — every subsequent call needs it as the X-User-Id header.

KYC

BDT supports two KYC methods:

KYC Sharing
KYC Widget

POST /api/v2/user/kyc

Headers: X-User-Id: <user_id>

{
  "legal_name": "Rahim Uddin",
  "poi": "<proof-of-identity-document-id>",
  "poa": "<proof-of-address-document-id>",
  "dob": "1990-01-31",
  "email": "user@example.com",
  "phone": "+8801712345678",
  "country_iso3": "BGD"
}

Response:

{ "success": true, "data": {} }

Saber may request supporting KYC documents at any time — these must be shared within 72 hours of the request.

Redirect the user to a signed URL:

const sigString = clientId + timestamp + "sdk" + userId
const secret = HmacSHA256(sigString, clientSecret).toString().toUpperCase()
// redirect to: https://app.saber.money/kyc?client_id=...&user_id=...&timestamp=...&secret=...&redirect_url=<url-encoded-url>

The URL is valid for 10 minutes from generation. Append the optional redirect_url as the last query parameter (URL-encoded) to send the user back to your app when they exit the flow. See KYC Hosted Widget for the full parameter reference.

Bank Account Linkage

POST /api/v2/user/bank_account

Headers: X-User-Id: <user_id>

{
  "account_holder_name": "Rahim Uddin",
  "account_number": "1234567890123",
  "bank_code": "090260619",
  "country": "BGD"
}

Mandatory: account_holder_name, account_number, bank_code (routing number), country.Response:

{
  "success": true,
  "data": {
    "bank_id": "550e8400-e29b-41d4-a716-446655440000",
    "account_number": "",
    "account_holder_name": "",
    "name": "",
    "validation_status": "PENDING",
    "created_at": "",
    "updated_at": ""
  }
}

Save bank_id for the sell step.

Transaction

Two variants, both requiring a quote first — a Live Quote (informational, executes at market rate regardless) or a Locked Quote (rate held ~30-60s, supplied as quote_id in the sell request):

Pool Sell (recommended)
External Sell

Get an informational quote:

GET /api/v2/wallet/s/quote?from_currency=USDT&to_currency=BDT&from_amount=100

Then create the sell:

POST /api/v2/wallet/transaction/pool/sell

{
  "source_id": "<bank_id>",
  "fiat_symbol": "BDT",
  "crypto_symbol": "USDT",
  "crypto_amount": 25,
  "payment_method": "bank_transfer"
}

Generate a locked quote (expires in ~30-60s):

GET /api/v2/wallet/w/quote?from_currency=USDT&to_currency=BDT&network=BSC&from_amount=10

Save id from the response as quote_id, then create the sell:

POST /api/v2/wallet/transaction/crypto/sell

{
  "payment_method": "bank_transfer",
  "network": "BSC",
  "destination_instrument_id": "<bank_id>",
  "quote_id": "<quote_id>",
  "sender_wallet_address": "0x318d2aae4c99c2e74f7b5949fa1c34df837789b8",
  "refund_wallet_address": "0x318d2aae4c99c2e74f7b5949fa1c34df837789b8"
}

Then fund deposit_crypto_address on-chain within the settlement expiry, and confirm it:

POST /api/v2/wallet/transaction/crypto/sell/{id}/confirm-onchain-funding

{ "transaction_hash": "0x1234567890abcdef" }

This returns 202 Accepted, not 200 — Saber verifies the deposit asynchronously.

Payment rail: payment_method: bank_transfer resolves automatically to the available local bank transfer rail in Bangladesh.

Checking status

GET /api/v2/wallet/transaction?transaction_type={POOL_SELL|EXTERNAL_SELL}&transaction_id={id}

Transaction Type	Possible `status` values
Pool Sell	`CREATED`, `PROCESSING`, `COMPLETED`, `FAILED`, `CANCELLED`, `APPROVAL_REQUIRED`, `SOURCE_INVALID`, `VERIFICATION_PENDING`, `REFUND_INITIATED`, `REFUND_COMPLETED`
External Sell	`CREATED`, `PAYMENT_INITIATED`, `FUNDS_RECEIVED`, `COMPLETED`, `FAILED`, `REFUND_INITIATED`, `REFUND_COMPLETED`, `REFUND_FAILED`

Poll until the status reaches a terminal state, or configure a webhook URL to receive completion pushes instead — see Order Lifecycle and Webhooks.

User limits and EDD

Each user has a lifetime transaction limit (currently $200,000 USD equivalent — this figure is suggestive and subject to change; confirm current limits with Saber). Once a user’s limit is breached, no further transactions can be created until Enhanced Due Diligence (EDD) is completed to raise it. EDD is completed via the EDD Hosted Widget, with a turnaround time of 2-3 working days.

Getting Started

Client Admin Operations

Offramp

Onramp

User Operations

Checking status

User limits and EDD

Offramp Operations

User KYC

Bank Account

​Checking status

​User limits and EDD

​Related pages

Offramp Operations

User KYC

Bank Account

Checking status

User limits and EDD

Related pages