Payouts to India

Review these India-specific requirements before initiating INR payouts. For the general cross-border
payment flow, see Sending Cross-Border Payments.

Supported configurations

India 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 payouts require a USDC_SOL trading account as the source. Other trading account types
(such as USDC or USDC_NPL) are not supported for INR payouts.

⚠️

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 both business_registration_number and tax_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
• identification_numbers with both business_registration_number and tax_identification_number

ℹ️

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"
  }],
  "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.

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 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

• Sending Cross-Border Payments
• Create Foreign Fiat External Bank Accounts
• Creating a Counterparty
• Verifying a Counterparty
• Create Plan API Reference