Your users already do this by hand. They just do not bill for it.
A customs broker running a client's IEC sees the credits land. Clients ask about them, brokers get drawn into finding a buyer, and the whole conversation happens over a phone call and a spreadsheet with none of it recorded anywhere in your software. It is the one part of the job that your product, which already carries the checklist, the filing and the out-of-charge, does not carry at all.
Every client IEC, with its credits visible and actionable.
The broker is already the person who knows which client has what. This turns that knowledge into something they can act on inside the job workflow rather than beside it, and into something the client can see was done properly.
For each connected client firm, what it holds by scheme, face value, remaining balance and expiry, and whether each credit is sellable. Each one carries a stage timeline your product can render like the job trackers your users already read.
One all-in figure per credit, priced for that specific credit and firm for sixty seconds. The rate is held firm for sixty seconds, so a broker quoting a client is quoting a firm number rather than defending a figure they were given.
A broker files for the buyer and for the seller and is visibly close to both. Every trade leaves an event log readable in sequence with a running hash chain and a final digest anyone can recompute, which is the difference between a relationship that looks close and one that looks arranged.
Nothing that touches your filing pipeline.
This is the part worth reading closely before you scope anything. A scrip transfer is a movement on a customs credit ledger, not a declaration. There is no message type to generate, no document to upload, no additional signing step, and no change to the checklist. Everything you built for Bills of Entry and Shipping Bills stays exactly as it is, because none of this goes through it.
Registering a firm takes its IEC and its details and rejects any credential-shaped field outright. The client completes the connection itself with a one-time code sent to its own registered contacts. Your users collect nothing new and store nothing new.
A desk registers, connects and acts per client firm, and everything stays scoped firm by firm. A resource belonging to another desk answers as though it does not exist rather than as though access was refused, so an identifier cannot be probed.
Mint scoped child keys under your own, one per integration or internal tool, each holding a strict subset of the parent's permissions, and revoke any of them instantly. A rotated key keeps working through a grace window so a rotation is not an outage.
A sandbox key is bound to a test IEC and returns simulated client inventory in exactly the production shape. The reference rate endpoints are public and need no key at all, so a rate panel can ship before any agreement exists.
The question your legal team asks first.
Before a scrip module 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.
A variable line beside a per-seat one.
Your revenue today is a licence or a subscription, charged whether the account had a busy month or a quiet one. This earns on settled trades, which means it moves with the same thing your customers' own agency billing moves with.
A spread on trades that completed. Nothing accrues on a quote, a browse or an order that did not settle, so there is no revenue you have to reverse and nothing to chase.
Spread captured gross and net, volume, and a per-client breakdown that maps onto the way your customers already bill their clients, read from the same double-entry ledger the money posted to.
A vendor whose product carries a revenue event for the broker is a different kind of vendor from one that carries a compliance obligation. That is a retention argument as much as a revenue one.
What will come up in your customers' review.
- A broker asked to act needs to have been asked. Each client firm completes its own connection with a code sent to its own registered contacts, and can end it. That is deliberate: a broker acting on a client position should be able to show they were authorised to, and a design where the software could do it quietly would be the wrong one.
- The sell side is the generally available side. An exporter client turning a matured credit into cash is live. Funding an importer client's customs duty with credits bought below face is in preview and enabled per desk on request. Raise it early if your case depends on it.
- Credits do not divide. A scrip transfers for its whole amount, so a broker cannot part-sell one to hit a client's number. Any interface implying otherwise will have to come out.
- We do not surface Bill of Entry or Shipping Bill status. You already do that better than we would, and we are not going to describe a capability here that your product owns and ours does not.
Asked, answered.
Not your software firm, on any reading. You are not in the chain of title, you are not the counterparty to either leg, and you do not hold the instrument. For the broker's client, the counterparty is ScripX rather than an unknown seller, and provenance is screened before a credit is ever offered, so nobody is buying a stranger's problem on trust. The statutory position on a transferee is a real question with real case law behind it, and it belongs with your counsel and on the partner agreement rather than in a paragraph on a marketing page.
No. A scrip transfer is a movement on a customs credit ledger, not a declaration. There is no new message type to generate, no additional document upload, no extra signing step and nothing new in your checklist. Whatever you built for Bills of Entry and Shipping Bills is untouched, because none of this passes through it.
That is your customer's counsel's call and we will not pretend otherwise. What we can tell you is the fact pattern they will assess: this is not a customs filing, not a declaration and not an authorisation application. It is a transfer of freely transferable credit between two verified IEC holders, and the broker's role in your product is to see it and act on it for a client who has asked them to.
The intent of the design is that your product passes through the client identity it already holds and nothing more. Registering a firm takes its IEC and its details; it rejects any credential field outright. The connection is completed by the firm itself with a one-time code sent to its own registered contacts, so your users are not collecting anything new and not storing anything new.
That is the shape it was built for. A desk registers its client firms, connects each one, reads what each holds, and acts per firm. Quotes, orders, positions and the event log stay scoped and separate firm by firm, and a resource belonging to another desk answers as though it does not exist rather than as though access was denied.
A line that scales with what your customers' clients actually trade, beside a subscription that does not. Terms sit on the partner agreement, so there is no rate for us to publish, but the reporting is worth knowing about in advance: spread captured gross and net, volume, and a per-client breakdown, read from the same ledger the money posted to rather than from a separate tally kept for a dashboard.
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 →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 →Your users' own view of this is on the desk for brokers and CHAs, and how a scrip desk runs today is worth reading before you scope.
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
The one part of the job your product does not carry.
Build the rate panel with no key. Build the rest against the sandbox. Go live on a partner agreement.