A revenue line that is not a subscription, off the sellers you already have.
Most marketplaces serving Indian exporters monetise the same two ways: a recurring fee per seller, or a take rate on goods. Both are charged against the listing, not against what the seller is actually doing. Duty credit is the rare third thing. Your exporters are already accruing it, they already have to go elsewhere to sell it, and putting that transaction inside your product needs no licence, no balance sheet and no money passing through your systems.
The step they currently leave your product to take.
A firm on your marketplace that exports accrues RoDTEP and RoSCTL credits against shipments it has already made. Today it sells those through a broker it found by asking around, at a price it cannot check, with paperwork it will be asked about at audit. That is the whole opportunity, and it happens entirely outside whatever you built.
One all-in number for a specific credit, priced for that specific credit and firm for sixty seconds. The rate is held firm for sixty seconds, so the seller can check the number rather than take it. No listing, no bidding, no waiting for someone to take the other side.
The other half of your base imports. Credits bought below face can cover an assessed customs bill, capped at face value. This side is in preview and enabled per desk on request, and we would rather write that here than let you scope around it.
Settlement is delivery versus payment. The buyer's funds are secured before the transfer is initiated and released to the seller only once it is confirmed, the same business day. A failure unwinds and returns the secured funds, so a bad trade in your product is an event rather than a dispute between two of your users.
A screen, a connect flow, and a webhook handler.
REST, JSON, one header. Money is integer paise, price is basis points of face value, time is ISO IST. Notably absent from this list: an escrow account, a settlement reconciliation job, a payouts integration, a KYC vendor, and a credential store. None of those are yours, because none of that flows through you.
The inventory read returns scheme, face value, remaining balance, expiry and whether the credit is sellable. The detail read adds a stage timeline, so a seller sees a status tracker in your product rather than a number with no story attached to it.
Brand name, logo, support contact and accent colour are set per firm through the API and carry onto the pages, receipts and documents your users receive. A trade that starts in your product does not arrive looking like it came from somewhere else.
A sandbox key is bound to a test IEC and returns simulated inventory in exactly the production shape. The rate endpoints are public and need no key at all. Between them, the interface and the demo are finishable with no agreement in place.
Deliveries are signed so you can prove they came from us, retried with backoff, and dead-lettered rather than dropped. You can list what failed and replay it. Orders take an idempotency key, so a timeout on your side is a repeat and not a second trade.
The question your legal team asks first.
Before a scrip category is a roadmap item it is a risk review, and the review is short. Title, customer money, credentials, KYC, and what happens when a trade fails. Here is each one, stated so it can be checked rather than trusted.
ScripX trades as principal. It buys the credit into its own name and sells it on, so it is the counterparty on both legs. That is two transfers and two sets of documents, and your platform is party to neither. Nothing lands on your balance sheet, there is no chain of title running through you, and you are not an intermediary facilitating a trade between two other people.
Settlement is delivery versus payment. The buyer's funds are secured before the transfer is initiated and released to the seller only once the transfer is confirmed. If a leg fails, the settlement unwinds and the secured funds go back. Every rupee of that runs between ScripX and the firm, so you are not a payment intermediary and you hold no float.
Registering a firm on the API rejects any credential-shaped field outright and tells you to use the separate verification call instead. Verification and authorisation are their own steps, and the firm completes them with a one-time code sent to its own registered contacts. A credential your product never receives is one it can never be asked to have leaked.
Because ScripX is the counterparty to each leg, the seller is verified by ScripX and the buyer is verified by ScripX. Your users are not relying on each other and they are not relying on you to have checked. Provenance on a credit is screened before it is offered, so nobody in your product is vouching for a stranger's instrument.
A key is bound to one engagement and one firm. A party identifier sent in a request body is ignored and forced to the key's own firm, so a key cannot act for a firm it is not mandated on even by mistake. Another desk's resource answers 404 rather than 403, so an id cannot be probed for existence. Child keys inherit the same tenant with a strict subset of scopes.
The credit itself is an exempt supply, and the documents for both legs are ScripX's to issue because both legs are ScripX's supply. What we will not do is tell you how your own revenue share should be treated. That belongs on your partner agreement and in front of your own advisers, and a marketing page that answered it confidently would be doing you a disservice.
The full position, including how failed settlements unwind and how provenance is screened, is on compliance and trust.
Variable revenue on a base you monetise flat.
Commercial terms sit on the partner agreement, so there is no rate for us to publish here. The part worth deciding on is the shape, and how much of it you will be able to see.
A spread on trades that settled. Nothing accrues on a quote, a browse or an order that did not complete, so there is no revenue you have to reverse and no receivable you have to chase.
An earnings read returns spread captured gross and net, volume, a per-client breakdown and the balance still withdrawable, read from the same double-entry ledger the money posted to. There is no second tally kept for a dashboard to drift away from.
Every seller with an IEC that has exported is a candidate, and you already know which those are. This is one of the few attach opportunities where the trigger is a fact in your own data rather than something you have to go and generate demand for.
The things that will change your design, said up front.
- The buy side is in preview. If your pitch internally is two-sided, know that the sell side is generally available and the buy side is enabled per desk on request. Scoping a two-sided launch without raising it first is the most likely way this goes wrong.
- Credits do not divide. A scrip transfers for its whole amount, so a seller cannot part-sell one to raise a particular figure. Any slider in your interface that implies otherwise will have to come out.
- A firm registers as one side. Exporter or importer, not both on one registration. A firm that genuinely does both is not yet supported as a single record.
- Your users' data will need a processing agreement. IEC and firm details cross from your systems to ours to make any of this work. Expect your privacy counsel to want that papered, and raise it early rather than at signature.
Asked, answered.
The design intent is that it cannot, because no customer money moves through you. Funds are secured from the buyer and released to the seller between ScripX and those firms directly. You hold no float, you operate no escrow, you collect nothing from your user and you settle nothing to them. Your own counsel still has to reach that conclusion on your facts, which is why the section above sets out precisely what does and does not pass through your systems.
We are not in a position to advise you, and any page that told you no without qualification would be selling rather than informing. What we can state is the shape of the thing: a duty credit scrip is transferable credit recorded on a government customs ledger and moved between two verified IEC holders. Offering it is not lending, not deposit taking and not dealing in securities, and you take neither title nor custody. That is the fact pattern your counsel will be assessing.
The sell side, where an exporter turns a matured credit into cash, is generally available. The buy side, where an importer funds customs duty with credits bought below face, is in preview and enabled per desk on request. If your case for the category rests on the buy side, raise it in the first conversation rather than after a design review.
It is a different line rather than a competing one. A subscription is charged whether or not the firm transacts; this earns only on a trade that settled. For a platform whose revenue has always been recurring and flat per seller, it adds a variable line that scales with what the seller actually does, without introducing anything you have to underwrite or collect.
Yours. The interface is yours to build and the relationship stays with you. The branding a firm sees on the pages, receipts and documents it receives is configurable per firm through the API, so a trade started in your product does not arrive looking like it came from somewhere else.
A read-only panel showing the current reference rate by scheme. The rate endpoints need no API key and no agreement, are cacheable, and publish their methodology and history. If nobody in your product clicks it, you have learned that cheaply and committed to nothing.
Not quite your product?
Trade-finance platforms
The one thing you can put beside a working capital line that is not a loan: no tenor, no first loss, no recovery, no title on your books.
See the seat →Broker softwareCHA and broker software
Your users already work every client IEC in your product. Scrips are the one thing in that workflow they still have to leave it for.
See the seat →ERPs and neobanksERPs and neobanks for EXIM
You already hold the ledgers and the accounts. A scrip balance is an asset your users own that your product does not currently show them.
See the seat →Background reading: what building this yourself actually involves, and what a duty credit scrip is.
Talk to a human.
A question about a quote, a settlement, or the API: write to us and a real person replies, usually within a day.
- Exporters: offers, payouts, Autopilot guard-rails.
- Importers and brokers: duty cover, the desk, API access and sandbox keys.
- Anything else: we read everything that arrives.
Prefer email? amin@eximfiles.io
Your sellers already do this. Somewhere else.
Ship the rate panel with no key. Build the rest against the sandbox. Go live on a partner agreement.