Skip to main content
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.
In one line: a scrip transfer is a ledger movement between two ICEGATE-registered IEC holders, permitted once, with the expiry date unchanged.

​
The e-scrip ledger

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

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

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

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

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.

​
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 for order.matched, settlement.settled, settlement.failed and payout.sent, or poll 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 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

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.
No. Validity runs from the date the scrip was created in the ledger and is unaffected by transfer. The buyer inherits the remaining window.
No. Scrips move whole. A buyer’s requirement is covered by a bundle of whole scrips, with the uncovered remainder reported separately.
A valid IEC and an active, registered ICEGATE account. Without both, the credit has nowhere to land.
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.
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.
Procedural detail on the customs side is set by notification and can change. Treat ICEGATE and CBIC as the primary sources for anything you rely on operationally.