Payouts to India (NRO)

Review these India NRO-specific requirements before initiating INR payouts to Non-Resident Ordinary
(NRO) accounts. For the general cross-border payment flow, see
Sending Cross-Border Payments.

C2C restriction

India NRO payouts support consumer-to-consumer (C2C) only. Business customers and business
counterparties are not supported. Both the customer (originator) and counterparty (receiver) must
be individuals.

Trading account requirement

India NRO payouts require a USDT_TRX trading account as the source. Other trading account types
(such as USDC, USDC_SOL, or USDC_NPL) are not supported for this corridor.

Minimum amount

The minimum source amount for India NRO C2C payouts is 11 USDT_TRX.

Verify INR payout availability

Confirm your bank supports INR NRO payouts for C2C and the bank_account route.

ℹ️

Bank configuration required

Contact Cybrid support to enable INR NRO payouts and configure India as a supported corridor for
your bank.

GET /api/banks/{bank_guid}
Authorization: Bearer YOUR_TOKEN

Look for an entry in supported_payout_symbols where:

• symbol: INR-USDT_TRX
• country_code: IN
• participants_type: C2C
• route: bank_account

Identity verification requirements

The platform validates all required KYC fields when you create a plan for India NRO payouts.

Originator (Customer)

Required fields for the customer (individual):

• name.first, name.last
• address.city, address.country_code

Receiver (Counterparty)

Create an individual counterparty with the
standard required fields.
This corridor requires no additional counterparty fields beyond the platform defaults.

The counterparty must be in verified state before you can create the external bank account and
plan.

Purpose of transaction

For India NRO C2C payouts, purpose_of_transaction is required, and restricted to
family_support (personal remittances to family members) or personal_transfer (personal
transfers between individuals). Other values are rejected.

External bank account setup

India NRO payouts support two rails: UPI (VPA) and IFSC (account number).

Send a POST request to /api/external_bank_accounts with one of the following formats.

UPI

Uses account_identifier_type: "VPA" with a virtual payment address (account_identifier) and payment_rail: "UPI". Omit bank_code and bank_code_type. Set account_designation to NRO.

{
  "account_kind": "raw_routing_details",
  "name": "Indian NRO beneficiary account",
  "counterparty_bank_account_details": [{
    "account_identifier": "username@bankhandle",
    "account_identifier_type": "VPA",
    "payment_rail": "UPI",
    "account_designation": "NRO"
  }],
  "counterparty_guid": "counterparty_guid",
  "customer_guid": "customer_guid",
  "asset": "INR"
}

IFSC

Uses bank_code_type: "IFSC" with an 11-character IFSC (bank_code) and bank account number (account_identifier). Set account_designation to NRO.

{
  "account_kind": "raw_routing_details",
  "name": "Indian NRO beneficiary account",
  "counterparty_bank_account_details": [{
    "bank_code_type": "IFSC",
    "bank_code": "HDFC0000123",
    "account_identifier": "012345678901",
    "payment_rail": "IFSC",
    "account_designation": "NRO"
  }],
  "counterparty_guid": "counterparty_guid",
  "customer_guid": "customer_guid",
  "asset": "INR"
}

ℹ️

Routing preference

If both UPI and IFSC details are configured on the same NRO external bank account, the platform uses UPI.

ℹ️

API versioning

Creating external bank accounts with foreign raw routing details requires Accept-Version: 2025-10-01 or later.

For the full account model and field reference, see
Create Foreign Fiat External Bank Accounts.

Plan expiration

When a plan is created, the response includes an expires_at field (ISO8601 datetime format)
indicating when the plan will expire. Once a plan expires, it cannot be executed and attempting to
execute it will result in a plan_expired error. The default expiration is 30 seconds.

Reconcile the payout (UTR)

Indian payouts settle with a UTR (Unique Transaction Reference) — the rail-issued
reconciliation key for UPI, IMPS, NEFT, and RTGS transfers. After the payout settles, the UTR surfaces
on the executed Stage under identifiers[]:

GET /api/executions/execution_guid
Authorization: Bearer YOUR_TOKEN

{
  "guid": "execution_guid",
  "state": "completed",
  "stages": [
    {
      "guid": "stage_guid",
      "type": "payout",
      "state": "completed",
      "identifiers": [
        { "type": "utr", "value": "HDFC0123456789" }
      ],
      "links": []
    }
  ]
}

The UTR appears only after the payer settles. While the stage is in earlier states, identifiers
is present but empty. Filter identifiers by type: "utr" and ignore other entries to remain
forward-compatible as new corridors add their own reference types.

Common validation errors

Retryable error codes

Only certain remittance errors should be retried automatically. Only external_server_error and
market_volatility are valid for automated retries. Other errors, such as invalid_destination or
invalid_destination_account_exception, should not be retried automatically and typically indicate
an issue with the counterparty or bank account details that must be resolved before attempting
again.

Related resources

• Payouts to India (NRE)
• Sending Cross-Border Payments
• Create Foreign Fiat External Bank Accounts
• Creating a Counterparty
• Verifying a Counterparty
• Create and Execute a Trade
• Create Plan API Reference