Payouts to India (NRE)

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

Supported configurations

India NRE payouts support the following participant types:

• C2C (consumer-to-consumer) — individual customer to individual counterparty
• B2C (business-to-consumer) — business customer to individual counterparty
• B2B (business-to-business) — business customer to business counterparty

All three use the bank_account route. B2B payouts additionally require supporting documents (see Supporting documents).

Trading account requirement

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

⚠️

Use a customer-level trading account

For INR remittance plans, use a customer-level trading account as the source. A bank-level trading account results in an error (for example, invalid_asset or No platform payout symbol configuration found).

Verify INR payout availability

Confirm your bank supports INR payouts for your participant type and the bank_account route.

ℹ️

Bank configuration required

Contact Cybrid support to enable INR 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-USD or INR-USDC_SOL
• country_code: IN
• participants_type: C2C, B2C, or B2B
• route: bank_account

You can also query prices for India:

GET /api/prices?payout_country_code=IN
Authorization: Bearer YOUR_TOKEN

Identity verification requirements

The platform validates all required KYC fields when you create a plan. Requirements differ by participant type.

Originator (Customer)

Individual originator (C2C):

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

Business originator (B2C, B2B):

• name.full
• address.street, address.city, address.country_code
• identification_numbers with one of:
  • business_registration_number
  • tax_identification_number
  • employer_identification_number

Receiver (Counterparty)

Create the counterparty with the standard required fields for the appropriate type.

Individual counterparty (C2C, B2C):

This corridor requires no additional counterparty fields beyond the platform defaults.

Business counterparty (B2B):

• name.full
• address.street, address.city, address.country_code

ℹ️

Counterparty address reflects destination country

For cross-border remittance, the address.city and address.country_code fields for the counterparty should reflect the destination country (e.g., India for INR payouts), not the source country.

⚠️

Self-to-self remittance (NRE accounts)

When the receiver is the same person as the originator and the destination is a Non-Resident External (NRE) account, create the counterparty using the customer's non-Indian residential address (the same address on the customer record) — not an India-based address.

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

Purpose of transaction

Requirements for purpose_of_transaction depend on the participant type:

• C2C — required, and restricted to family_support (personal remittances to family members) or personal_transfer (personal transfers between individuals). Other values are rejected.
• B2C — required. Any standard purpose value is accepted.
• B2B — required. Any standard purpose value is accepted.

Supporting documents

B2B payouts to India require a supporting document of type invoice attached to the plan. You can attach additional documents of other types (purchase_order, delivery_slip, contract, bill_of_lading, or others) as optional extras. C2C and B2C payouts require no supporting documents.

Each B2B plan must include exactly one supporting document that carries a document_reference_number (for example, the invoice number). Attach the reference number to the invoice document.

{
  "supporting_documents": [
    {
      "type": "invoice",
      "file_guids": ["file_guid"],
      "document_reference_number": "INV-1001"
    }
  ]
}

Requirements:

• At least one document of type invoice (required for B2B).
• Up to 3 documents per plan.
• Each file must be uploaded with a type matching the document type (an invoice document references files uploaded with type: invoice).
• Allowed file formats: application/pdf, image/jpeg, image/png.
• Each file must be no larger than 8 MB, with a filename of 64 characters or fewer.
• Exactly one supporting document must carry a document_reference_number.

Upload each file via File Upload and wait for state: "completed" before referencing its GUID. For the full supporting_documents field structure, see Sending Cross-Border Payments.

External bank account setup

India payouts use IFSC (Indian Financial System Code) routing through India's National Electronic Funds Transfer (NEFT) and Real Time Gross Settlement (RTGS) systems.

Requirements:

• IFSC Code: 11-character bank branch identifier
• Account Number: Beneficiary account number

Send a POST request to /api/external_bank_accounts with the following body:

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

ℹ️

API versioning

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

ℹ️

Account designation

For NRE accounts, set account_designation to NRE. If omitted on IFSC accounts, the platform
defaults to NRE.

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.

Reconcile the payout (UTR)

Indian payouts settle with a UTR (Unique Transaction Reference) — the rail-issued reconciliation key for 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, 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 (NRO)
• Sending Cross-Border Payments
• Create Foreign Fiat External Bank Accounts
• Creating a Counterparty
• Verifying a Counterparty
• Create Plan API Reference