What It Takes to Offer Scrip Trading Inside Your Own Product

There is a strange pattern in Indian trade software. Almost every product serving exporters and importers has published a guide to duty credit scrips. Almost none of them lets a user do anything about one. The explainer is there, the button is not. This page is about why that gap has stayed open, what closing it actually costs, and what changes when the hard part is somebody else's problem.

The pattern, and what it tells you

Go and look. Invoice discounting products, cross-border payment products, working capital lenders, receivables exchanges, spend management, even a global marketplace's India seller programme. Between them they have written a small library on what a RoDTEP scrip is and how to sell one. We checked the ones we could reach and none of them offers scrip trading as a product.

That is not laziness. Those are capable teams who understood the opportunity well enough to write about it, priced the build, and declined. The interesting question is what they saw.

What the build actually contains

Four problems, and they are not the same problem in different clothing.

1. Liquidity. Your users hold credit or need credit, rarely both in matching amounts on the same day. Without the other side of the market you have built a noticeboard. And the credit cannot be divided: under Regulation 7(2) of the Electronic Duty Credit Ledger Regulations, a scrip transfers for its entire amount and transfer in part is not permitted, so lot sizes are fixed by whatever the exporter happened to generate and matching is genuinely hard rather than notionally hard.
2. Price. DGFT publishes the scheme rates that decide how much credit an export earns. Nobody publishes what the credit then sells for. There is no benchmark to quote against, so either you invent one and defend it, or every quote in your product is a number your user cannot check.
3. Counterparty risk. There is no public lookup that lets a buyer verify a scrip before paying for it. The authoritative view appears only once the credit is in a ledger you control. Whoever moves first is unsecured, and if that happens inside your product, your user believes it is you who arranged it.
4. The settlement leg. The transfer itself runs on the government's system, initiated by the seller with a one-time password to their own registered contact details and approved by the buyer with one of their own. And programmatic access to that system is gated: licence keys flow through cloud service providers holding agreements with the department, not through a public developer portal.

Problem four is the one that stops the project. It is also the reason to treat any claim of portal integration with polite curiosity, and the reason a great many products that started building this quietly stopped.

The State built a rail and declined the market

This is worth reading directly, because it is the clearest official statement of where responsibility sits. When DGFT re-operationalised the scrip transfer recording module for the older schemes, its trade notice recorded that the owner transfers the scrip as per the negotiated terms and conditions between buyer and seller, and that DGFT and Customs are not responsible for any lapse by the old or new owner, or any dispute between them.

Issuance: public. Transfer rail: public. Discovery, price, credit, settlement and recourse: not provided, by design. That vacancy has been filled for twenty years by brokers doing skilled work with nothing underneath it, and it has never once been filled by software.

Your three options today, stated honestly

Refer it out. Send the user to a desk you know. This is what most products do and it works until it does not. You have lent your brand to a settlement process you cannot observe, cannot audit and will not hear about until it fails, and the support ticket still arrives at your desk. You also never see the transaction, so you never learn anything from it.

Build it. Solve all four problems above, and then run an operations function that keeps solving them daily, in a market where the venues that tried have had a hard time of it. Of the online scrip venues we could find, one is a small live app, one publishes rates and carried a notice in July 2026 that it had paused pending purchases over portal synchronisation problems, and two are simply gone, one domain no longer resolving and another serving a hosting suspension page.

Do nothing. The most common choice, and not an irrational one. The cost is that a revenue event your data can already see happens somewhere else, and the user learns to go somewhere else for it.

What we could not verify, and are not going to invent

• Revenue in the category. No venue publishes volumes, take rates or fees. We found no funding announcements for the players we identified. Any market-size figure we quoted would be a guess with a decimal point on it.
• Integration claims by others. Where a venue describes itself as portal integrated, we could not verify what that means technically, and we are not going to characterise someone else's architecture from the outside.
• Escrow arrangements offered elsewhere. Several intermediaries describe holding funds in the middle. None that we could find publishes the terms or names who holds the money.

What changes with ScripX

The proposition is narrow on purpose: you keep the user, the interface and the relationship, and the four problems above stop being yours. Outcomes only.

• One REST API and one key. Onboard a firm under your account, take a firm quote benchmarked to the published reference rate and held for sixty seconds, place the order against that quote, and receive settlement webhooks as the trade progresses. Sandbox by default.
• Neither of your users has to go first. Settlement is delivery versus payment: funds are locked before the scrip moves, and the payout releases against confirmation of the transfer, the same business day. A failed settlement unwinds and refunds in full the same day, so a bad trade inside your product is an event rather than a dispute.
• You never take title. ScripX trades as principal and is the counterparty on both legs, so the instrument never sits on your books and you never stand between two firms.
• Provenance is screened before a scrip lists, so the credit your user buys was checked before it was offered, and you are not the one vouching for it.
• Every trade leaves a record you can hand over. A per-trade audit pack, a GST invoice and a net-realisation statement, with a request ID echoed on every API response, so a support conversation starts with a fact.

That is the bridge. The market has never lacked demand or supply. It has lacked a settlement layer that two strangers can trade across, and a product that already serves those strangers is the natural place to put one. See the embedded seat, or read what a settled trade costs.

Common questions

Where this came from

The transfer rules and the whole-scrip constraint are from the Electronic Duty Credit Ledger Regulations, 2021 and the ICEGATE e-scrip advisory. The position that Customs and DGFT take no responsibility for commercial terms is from DGFT's own trade notice on the scrip transfer recording module. The gated nature of programmatic access to the customs system is from published material on how that integration is provisioned. The observations about other venues are from their own public sites as they stood in July 2026, and everything we could not verify is named above.