Rupee Export Proceeds Now Count for FTP Benefits: What to Re-Check in an ECGC or Trade Credit Policy

DGFT Notification No. 30/2026-27, dated 20 August 2026, amends paragraphs 2.52 and 2.53 of the Foreign Trade Policy. The substance is short and consequential: qualifying export proceeds realised in Indian rupees through prescribed banking channels are to be treated at par with proceeds realised in foreign currency for the purpose of export benefits, incentives, and the fulfilment of export obligations.

Before this amendment, rupee realisation sat in an awkward position. The wider settlement framework under FEMA and RBI regulations already permitted Indian exporters to invoice and be paid in rupees through authorised channels, including the special rupee accounts opened for that purpose. The Foreign Trade Policy, though, still carried restrictions and carve-outs around when rupee realisation counted for FTP purposes. An exporter could therefore be fully compliant on the FEMA side and still find that the same receipt did not cleanly support an advance authorisation discharge or an incentive claim.

The notification closes that gap. As analysis of the change put it, it aligns the Foreign Trade Policy with the INR settlement framework already permitted under FEMA and RBI regulations, giving FEMA-compliant rupee realisation the parity that was previously subject to restrictions or exceptions under the FTP.

Export credit insurance and the Foreign Trade Policy converge on one document set: the evidence that money came back from the buyer, in what amount, and by what date.

A trade credit or ECGC policy pays on non-payment. To establish non-payment, the insurer has to establish what payment would have looked like. That means the insured contract, the invoice, the credit terms, the declaration filed with the insurer, and the banking record of what was actually received. The Foreign Trade Policy uses the same last item to test whether an export obligation has been discharged or an incentive has been earned.

When the currency of that realisation changes, both files change at once. The FTP side is now settled: rupee realisation through the prescribed route counts. The insurance side is not settled by anything DGFT publishes. A policy schedule that denominates the credit limit, the maximum liability, and the premium base in US dollars keeps doing exactly that after 20 August 2026. Nothing in Notification No. 30/2026-27 amends a policy wording.

That is the practical problem this notification creates for brokers. It removes a reason not to invoice in rupees, so more exporters will invoice in rupees, and their cover was underwritten on the assumption that they would not.

The difference between an ECGC policy and a commercial trade credit policy matters here, because the two respond differently to a currency switch, and the re-check below is not identical for both.

Every insured export receivable carries three separate currency decisions, and exporters routinely assume they are one decision.

1. The contract and invoice currency, meaning what the buyer owes. This is the slot the DGFT amendment touches, by removing the FTP penalty for choosing rupees.
2. The insured currency, meaning the currency in which the credit limit, the maximum liability, and any per-buyer sub-limit are expressed in the policy schedule.
3. The claim settlement currency, meaning what the insurer actually pays, which the policy's conversion clause decides and which need not match slot two.

A rupee-invoiced shipment covered under a dollar-denominated limit puts a floating rupee receivable against a fixed dollar cap. If the rupee weakens against the dollar between the shipment declaration and the claim assessment, the dollar limit stretches further than the exporter needs, which is harmless. If the rupee strengthens, the same limit covers fewer rupees of receivable than it appeared to at inception, and the shortfall is uninsured.

Neither outcome is a defect in the cover. It is the arithmetic of insuring a receivable in one currency under a limit expressed in another. The same basis problem shows up on Gulf corridor placements where the trade has moved to local currency settlement while the policy currency has stayed in dollars.

ECGC covers are structured around declared shipments and buyer-wise credit limits, so a currency switch touches several fields at once.

Limits and maximum liability. Check the currency in which the buyer-wise credit limit and the policy's maximum liability are expressed, then check whether the shipments now being declared against that limit are rupee-invoiced. If the answer is dollars against rupee invoices, ask the underwriter to either restate the limit in rupees or agree a documented conversion basis in writing. A limit that is silently converted at the underwriter's rate on the day of assessment is a limit the exporter cannot plan against.

Declaration mechanics. Shipment declarations carry a value. Confirm which currency the declaration schedule expects, whether the exporter's own system is now generating rupee figures, and whether the conversion applied at declaration is the same conversion that will be applied at claim. A mismatch between those two conversions produces an under-declaration, and under-declaration is a premium and a coverage problem before it is a currency problem.

Realisation evidence. The proof of realisation is the shared document between the FTP file and the claim file. Post-notification, rupee realisation through prescribed banking channels stands on the same footing as foreign currency realisation for FTP benefits and export obligation discharge. Make sure the banking evidence the exporter retains for the rupee route is filed to the same standard as the foreign currency evidence, because a claims team assessing non-payment will read that record the same way a DGFT authority reads it.

Private market wordings give more room to negotiate than a standard ECGC product, and that room is worth using now rather than at claim.

The currency clause should name the policy currency and state whether declarations may be made in more than one currency. Many exporters discover only at renewal that their wording permits a single currency, which forces every rupee invoice through a conversion the exporter did not choose.

The conversion date is the clause that decides who carries the basis. A conversion fixed at the date of loss, or the date the debt fell due, keeps the movement between default and settlement with the insurer. A conversion fixed at the date of payment pushes it onto the insured. On a protracted default where the waiting period runs for months, that difference is not theoretical.

The definition of non-payment and the waiting period clock should be read against rupee settlement timing. If the prescribed banking route introduces a different value date pattern than the exporter's previous foreign currency route, the day count that triggers protracted default may start or end on a different day than the credit control team assumes.

The premium base matters too. Where premium is rated on declared turnover in a stated currency, a switch to rupee invoicing changes the declared figure without changing the underlying business. Confirm with the underwriter how the adjustment premium will be computed so the year-end reconciliation does not produce a surprise.

Exporters building cover for the first time will find the structural groundwork in the guide to trade credit insurance for Indian exporters and manufacturers.

The strongest argument for tightening documentation now is that the same records serve two audiences with different tolerances.

DGFT reads realisation evidence to test whether an export obligation is discharged or a benefit is due. The insurer reads the same evidence to test whether a receivable was genuinely unpaid. Both readers want the invoice, the shipping documents, the credit terms agreed with the buyer, and the banking record of receipt or non-receipt through the channel actually used.

A practical file for a rupee-realised export should hold:

• The export contract or purchase order showing the agreed currency and credit period.
• The commercial invoice in rupees, matched to the shipping bill.
• The banking evidence of realisation through the prescribed channel, or, on a default, the bank's confirmation that no credit was received.
• The declaration filed with the insurer for that shipment, with the currency and value visible.
• Any correspondence with the buyer on payment delay, dated and preserved.

Where an exporter runs both rupee and foreign currency invoicing to the same buyer, keep the two streams separately traceable. A blended buyer ledger makes it hard to prove which specific invoices the claim relates to, and a claims team that cannot map declarations to invoices will ask for a reconstruction the exporter may not be able to produce months later. The policy wording sets the evidentiary bar, so read it before the file is built rather than after a default.

The change is recent, so most policies in force were placed before it. The cleanest response is one added step at renewal rather than a mid-term scramble.

Ask the exporter's finance or treasury function a single question: which buyer relationships have moved, or are expected to move within the next twelve months, to rupee invoicing under the prescribed banking route. Take that list and compare it, buyer by buyer, against the currency stated on each credit limit in the policy schedule.

Every divergence is one of three things. It is a limit that should be restated in rupees. It is a conversion basis that should be written into the wording rather than left to the assessor. Or it is a genuinely small exposure the client accepts, in which case record the acceptance in the placement file so the advice trail is intact.

Two further items belong in the same conversation. Confirm the insurer can and will settle in rupees where the underlying receivable is in rupees, because an insurer that pays in dollars against a rupee loss reintroduces the basis at the last step. And confirm that the exporter's FTP team and its insurance broker are working from the same shipment data, since the parity granted by the amendment only helps an exporter whose realisation records actually demonstrate the prescribed route was used.

None of this requires a new product. It requires the schedule to describe the business the exporter is now writing rather than the business it wrote when the cover was first placed.