> ## Documentation Index
> Fetch the complete documentation index at: https://docs.scripxhq.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Scrip transfer on ICEGATE explained

> How duty credit scrip transfer works on ICEGATE: the e-scrip ledger, what a transfer moves, the once-only transfer rule, why validity does not reset, what the transferee must have in place, and how delivery versus payment removes the trust gap.

A duty credit scrip is not a piece of paper. It is a balance in an electronic ledger maintained by Indian Customs, reached through **ICEGATE**, the CBIC portal that exporters and importers use for customs filings. Transferring a scrip means moving that balance from one IEC holder's ledger to another's. Nothing physical changes hands, and nothing about the credit itself changes except who owns it.

<Note>
  **In one line:** a scrip transfer is a ledger movement between two ICEGATE-registered IEC holders, permitted once, with the expiry date unchanged.
</Note>

## The e-scrip ledger

Under the electronic scrip framework, a RoDTEP or RoSCTL claim becomes a real instrument in three stages:

<Steps>
  <Step title="Scroll">
    Customs sanctions the claim from the filed shipping bills and generates a scroll. The amount appears against the exporter's IEC, but it is not yet a scrip and cannot be transferred or used.
  </Step>

  <Step title="Scrip creation">
    The exporter converts scrolled amounts into an **e-scrip**. The scrip is created in the ledger with a scrip number, a face value, and a validity date running from the date of creation.
  </Step>

  <Step title="Transfer or utilisation">
    From creation onward the holder can either apply the scrip against duty on its own imports, or transfer it to another party.
  </Step>
</Steps>

The scrip number is the identity that follows the credit through its whole life. On the ScripX API it is the `scrip_no` you quote and trade against.

## What a transfer moves, and what it does not

| Moves                                      | Does not move                                |
| ------------------------------------------ | -------------------------------------------- |
| Ownership of the remaining balance         | The scrip number                             |
| The right to apply the credit against duty | The validity date                            |
| The right to see the scrip in your ledger  | The underlying scheme (`RODTEP` or `ROSCTL`) |
|                                            | The right to transfer again                  |

Three consequences follow, and they drive most of the practical behaviour in this market.

### Transfer is permitted once

Under the e-scrip framework, a duty credit may be transferred **once**, from the holder to another party with a valid IEC registered on ICEGATE. A scrip that has already been transferred cannot be transferred onward. So the market is structurally exporter to importer, with intermediaries arranging trades rather than warehousing paper on their own ledgers. Buyers buy to consume.

### Validity does not reset

The scrip's expiry runs from the date it was **created**, not from the date it was transferred. A buyer inherits whatever remains of the original window. This is why time to expiry is a pricing input rather than a footnote. See [Scrip validity and expiry](/concepts/scrip-validity-expiry).

### The transferee must be ready to receive

The receiving party needs a valid **IEC** and a registered ICEGATE account in good standing before a transfer can land. An unregistered or inactive counterparty is the most common reason a nominally agreed deal cannot execute.

## The trust gap, and how it is closed

The portal moves the scrip. It does not move money. That is the entire problem with a privately negotiated scrip trade:

* If the **seller transfers first**, it holds an unsecured claim on a buyer who now has the asset.
* If the **buyer pays first**, it holds an unsecured claim on a seller who still has the asset.

Nothing in the ledger arbitrates that. Whoever goes first carries the risk, and in practice the weaker party goes first.

**Delivery versus payment (DvP)** removes the choice. On ScripX:

1. Buyer funds are locked **before** the scrip moves.
2. Title transfers from seller to buyer on ICEGATE.
3. The seller payout fires **on confirmation of the transfer**, by IMPS, with a bank **UTR** on the receipt, in minutes, same business day (T+0).
4. A settlement that cannot complete unwinds safely and refunds in full the same day.

Title and money move together, or neither moves. Your integration reads the result rather than driving the rails: subscribe to [webhooks](/webhooks) for `order.matched`, `settlement.settled`, `settlement.failed` and `payout.sent`, or poll [positions](/api-reference/trading/positions).

## Provenance: why the ledger is not enough

The ledger tells you a credit exists and who holds it. It does not tell you whether the shipping-bill chain behind it is clean, whether the selling IEC has a history, or whether the credit is subject to a live dispute. That history follows the credit into the transferee's ledger.

On ScripX no scrip is listed until it clears **provenance screening**: the shipping-bill chain the credit derives from, the seller's IEC history, KYC on the selling firm, and the credit's live status in the customs ledger. A credit that shows `sellable: true` on [a firm's credits](/api-reference/firms/credits) has already passed. In a private trade, that diligence is the buyer's to run.

## Utilisation after transfer

Once a scrip is in the buyer's ledger, it is applied against duty payable when a Bill of Entry is filed, up to the balance available and only against the heads it is permitted to pay, in practice **basic customs duty**. Each utilisation reduces the balance. A scrip ends its life either at zero balance or at expiry.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="Can a scrip be transferred more than once?">
    No. Under the e-scrip framework the transfer of a duty credit is permitted once, from the owner to another IEC holder registered on ICEGATE. Plan purchases around consumption, not resale.
  </Accordion>

  <Accordion title="Does transferring a scrip extend its validity?">
    No. Validity runs from the date the scrip was created in the ledger and is unaffected by transfer. The buyer inherits the remaining window.
  </Accordion>

  <Accordion title="Can I transfer part of a scrip?">
    No. Scrips move whole. A buyer's requirement is covered by a bundle of whole scrips, with the uncovered remainder reported separately.
  </Accordion>

  <Accordion title="What does the transferee need before a transfer can happen?">
    A valid IEC and an active, registered ICEGATE account. Without both, the credit has nowhere to land.
  </Accordion>

  <Accordion title="Who bears the risk between transfer and payment?">
    In a private deal, whoever moves first. Under delivery versus payment there is no gap to bear: funds are locked before title moves and the payout fires on confirmation of the transfer.
  </Accordion>

  <Accordion title="What is the proof that a trade completed?">
    Two records. The ledger shows the credit under the buyer's IEC, and the seller's payout carries a bank UTR. Both are carried into the tamper-evident [audit export](/api-reference/account/audit-export).
  </Accordion>
</AccordionGroup>

<Note>
  Procedural detail on the customs side is set by notification and can change. Treat [ICEGATE](https://www.icegate.gov.in) and [CBIC](https://www.cbic.gov.in) as the primary sources for anything you rely on operationally.
</Note>

## Related

* [How to sell RoDTEP scrips](/concepts/sell-rodtep-scrips)
* [How to buy duty credit scrips](/concepts/buy-duty-credit-scrips)
* [Scrip validity and expiry](/concepts/scrip-validity-expiry)
* [Delivery versus payment settlement](/core-concepts#delivery-versus-payment-settlement)
* [Webhook events](/annexure/webhook-events)