You already hold the record. You just cannot act on it.
An EXIM ERP tracks the credit: the scheme, the accrual against a shipment, the expiry. A business banking product holds the account the money would land in. Between them they hold every part of this transaction except the one that matters, which is the disposal. So the number sits in a module, the balance sits in an app, and the actual trade happens on a phone call to somebody neither of you has ever heard of.
A balance that turns into a button.
Your users are exporters. They accrue RoDTEP and RoSCTL credits against shipments they have already made, those credits expire on a fixed clock, and until they are sold they are worth exactly nothing to the business. This is what changes for the firm inside your product.
Scheme, face value, remaining balance, expiry, and whether each credit can be sold, per firm. Each one carries a stage timeline you can render alongside the ledgers and accounts you already show, so it reads as part of the position rather than a bolted-on tile.
An all-in number for a specific credit, benchmarked to the firm quote for that specific credit, held for sixty seconds and history so the firm can check it. Settlement completes the same business day, with the money secured before the credit moves.
A credit has a fixed life and firms routinely let one lapse because nothing in their software ever mentioned it. A product that already sends them numbers is the natural place for the one that says this expires and is still unsold.
A balance read, a quote, an order, a webhook.
REST, JSON, one header. Money is integer paise and price is basis points of face value, which matters more in an accounting product than in most places. Nothing here asks you to open an account, hold a float, run a payout rail, or add a reconciliation job, because none of that is yours.
Money is integer paise and price is basis points of face value, so nothing is a percentage applied to a total and nothing rounds on the way through. In a product whose users reconcile to the rupee, that is not a detail.
Deliveries are signed so you can prove they came from us, retried with backoff, and dead-lettered rather than dropped, with endpoints to list what failed and replay it. Orders take an idempotency key, so a timeout is a repeat and not a second trade.
The event export returns your own log in sequence with a running SHA-256 chain and a final digest you can recompute independently. Earnings are read from the same double-entry ledger the money posted to, not from a separate tally kept for a dashboard.
The rate endpoints are public and unauthenticated. A sandbox key is bound to a test IEC and returns simulated inventory in the production shape. Between them, the screens and the internal demo are finishable with no agreement in place.
The question your legal team asks first.
Before a scrip balance 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.
Where the ERP review and the fintech review differ.
The build is the same for both of you. The internal conversation is not, so it is worth separating rather than averaging.
- You very likely already carry this credit as a record. Licence and scheme tracking, incentive accrual against a shipment, expiry dates: that module exists in this market and in many cases you already sell it.
- What has never existed is a way to dispose of a credit from inside the system that tracked it, which is why the figure lives in your product and the transaction does not.
- Your review is therefore mostly a data and vendor question rather than a regulatory one. It is the shortest conceptual leap of anything on this site.
- Your review is a perimeter question, and it deserves a precise answer rather than reassurance. You take no title, you handle none of the funds, and no credit is extended at any point.
- It is also entirely domestic. A scrip sale is a rupee transaction between two Indian firms, so it never appears in your cross-border, realisation or advice workflows.
- Expect your normal vendor and outsourcing due diligence to apply. Ask us for what it needs at the first conversation rather than the fifth.
A line that is not in the price war you are already in.
Commercial terms sit on the partner agreement, so there is no rate to publish here. What is worth saying is where the revenue comes from, because for one half of this page it is a genuinely different place from where the rest of it comes from.
A spread on trades that completed. Nothing accrues on a quote, a balance view or an order that did not settle, so there is no revenue to reverse and no receivable to chase.
Cross-border products for exporters have converged on flat per-transaction fees with thin or no margin, published openly and competed on directly. This is a different transaction entirely, on the same customer, so it does not have to win that argument to earn.
Spread captured gross and net, volume, a per-client breakdown, and the balance still withdrawable, read from the same ledger the money posted to. One set of numbers, not two that drift.
The boundaries, stated rather than discovered.
- There is no advance against an unsold credit. A firm sells an asset it owns and is paid for it. If what you actually want is to lend against a credit before it is sold, that is a different product with a different perimeter and we do not have one. Better to know that now than after a roadmap review.
- The sell side is the generally available side. Funding an importer's customs duty with credits bought below face is in preview and enabled per desk on request. If your case depends on it, raise it in the first conversation.
- Credits do not divide, and a firm registers as one side. A scrip transfers for its whole amount, so no part sale to reach a figure. A firm registers as an exporter or an importer, not both on one record.
- Firm data will cross a boundary. IEC and firm details move from your systems to ours for any of this to 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, and the reason is that nothing regulated moves through you. You take no title to the credit, you handle none of the funds, and no credit is extended to anyone at any point. A technology provider that does not handle funds is a different thing from an entity that does, and that distinction is the one your compliance team will be testing. They still have to reach the conclusion themselves on your facts; what we can do is state the facts precisely enough for that to be a short exercise.
No, and we would rather be clear about the boundary than leave it flattering. ScripX does not advance funds against a credit. A firm sells an asset it owns and is paid for it. If your roadmap wants an advance against an unsold credit, that is a lending product with a different perimeter and a different conversation, and it is not what this is.
Not at all, and this catches people out. A scrip sale is a domestic rupee transaction between two Indian firms. It is not an export receipt, it does not produce an inward remittance, and it does not appear anywhere in your realisation, purpose-code or advice workflows. It sits beside them rather than inside them.
Your product passes through the firm identity it already holds and nothing more. Registering a firm takes its IEC and its details and rejects any credential field outright. The firm completes the connection itself with a one-time code sent to its own registered contacts. You are not collecting anything new and you are not storing anything new.
It is the right one. EXIM ERPs in this market already carry the credit as a record: licence and scheme tracking, incentive accrual against shipments, expiry. What has never existed is a way to dispose of one from inside the system that tracked it, so the number sits in a module and the transaction happens on a phone call. That is a shorter conceptual leap than anything else on this site.
REST, JSON, one header. Register a firm, connect it, read what it holds, take a firm quote, place an order, handle a webhook. Money is integer paise and price is basis points of face value, so nothing rounds where it should not. The smallest useful version is a read-only rate panel, which needs no key and no agreement at all.
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 →MarketplacesExporter and importer marketplaces
A revenue line that is not a subscription, off the sellers you already have, with no customer money through your systems.
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 →Your users' own view is on the app for exporters, and what a duty credit scrip is is the page to send anyone who has not met one.
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
No title, no funds handled, no credit extended.
Build the rate panel with no key. Build the rest against the sandbox. Go live on a partner agreement.