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

POST /api/v2/user/kyc

Headers: X-User-Id: <user_id>

Field	Description
`legal_name`	Full legal name, as printed on the ID document
`dob`	Date of birth (`YYYY-MM-DD`)
`nationality`	Nationality, ISO 3166-1 alpha-3
`id_document_type`	Type of ID document (e.g. passport, national ID, driver’s license)
`id_document_number`	ID document number
`id_country`	Country that issued the ID document, ISO 3166-1 alpha-3
`id_expiry`	ID document expiry date (`YYYY-MM-DD`)
`address.line_1`	Address line 1
`address.town`	Town or city
`address.country`	Country of residence, ISO 3166-1 alpha-3

{
  "legal_name": "Rahim Uddin",
  "dob": "1990-01-31",
  "nationality": "BGD",
  "id_document_type": "PASSPORT",
  "id_document_number": "BR1234567",
  "id_country": "BGD",
  "id_expiry": "2032-05-14",
  "address": {
    "line_1": "House 12, Road 5, Dhanmondi",
    "town": "Dhaka",
    "country": "BGD"
  }
}

Response:

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

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

Bank Account Linkage

POST /api/v2/user/bank_account

Headers: X-User-Id: <user_id>

{
  "account_number": "1234567890123",
  "routing_code": "090260619"
}

Field	Description
`account_number`	Bangladeshi bank account number
`routing_code`	9-digit bank routing code identifying the branch

Both fields are mandatory.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