The standard explanation for why so much export trade goes unfinanced is that banks are cautious about cross-border risk — currency exposure, buyer default in a jurisdiction they can't easily chase, political risk, the usual list. It's a plausible story, and it's not wrong exactly. It's also not the binding constraint for a meaningful share of the gap, because a lot of that gap sits with exporters a bank would gladly finance on risk grounds alone, if the bank could economically establish that the trade behind the invoice is real.
The global trade-finance gap was estimated at $2.5 trillion in 2025 — roughly 10% of global trade (Asian Development Bank, Global Trade Finance Gap Survey, January 2026). That is not a gap made entirely of deals banks have looked at and declined on risk. A meaningful share of it is deals banks never got to a risk decision on at all, because establishing the facts a risk decision requires — is this shipment real, does this exporter hold a valid IEC, did the goods actually leave, has the foreign exchange actually come back — costs more, in analyst hours and document-chasing, than a mid-sized trade-finance deal is worth to underwrite.
Provenance and risk appetite are different questions, and only one of them is expensive
Risk appetite is a policy question: given a real trade with these characteristics, will we finance it, and at what rate. Provenance is a factual question: is this a real trade with these characteristics. The two get bundled together in how trade finance gets discussed, but they don't get bundled together in how much they cost to answer. Risk appetite is set once, at the policy level, and applied cheaply, deal after deal. Provenance has to be re-established on every single deal, from primary documents that live in different systems, held by different authorities, in formats that don't talk to each other.
A Certificate of Origin sits with one authority. A Bill of Lading sits with the shipping line. An e-BRC — the electronic Bank Realisation Certificate confirming export proceeds actually landed — sits with the bank that processed the inward remittance. IEC status sits with DGFT. None of these systems were built to hand a lender one clean, verifiable answer to "is this trade real." A lender has to go get each piece separately, and for a mid-sized exporter on a deal that doesn't clear a large-ticket threshold, that document-chasing is where the deal dies — not on a credit committee's risk view, on an analyst's desk, before it ever reaches one.
Where this bites hardest
It bites hardest exactly where the growth is supposed to come from: deep-tier and mid-sized exporters, not the large, established names every bank already has a relationship with and a standing document trail for. A first-time or infrequent exporter presents a bank with a stack of documents the bank has no prior pattern for, from counterparties and shipping lines the bank has no history with, on a ticket size that doesn't justify the manual document-verification effort a first-time relationship demands. The gap isn't distributed evenly across exporters. It concentrates precisely on the businesses without an existing paper trail a bank already trusts — which is also, not coincidentally, where a large share of India's actual export growth potential sits.
India's own infrastructure for proving trade is, in fact, reasonably mature — an unauthenticated DGFT public API already returns IEC status, entity name and PAN on demand; e-BRC and CoO processes already exist. The infrastructure to establish provenance is mostly there. What's missing is the layer that pulls each piece together into one verifiable answer, fast enough and cheaply enough that checking it doesn't become the reason a deal never gets to a risk decision at all.
What a tamper-evident provenance bundle actually changes
A Trade-Provenance Pack does exactly that pulling-together: IEC and DGFT status, e-BRC forex realisation, Certificate of Origin and shipping documentation, assembled into one tamper-evident bundle with a public verification URL a counterparty or lender can check independently, without taking the exporter's word for any piece of it. The point isn't a new source of truth — every underlying fact already has an authoritative source. The point is that a lender no longer has to go collect each piece separately, on every deal, from scratch.
That collapses the cost that was killing mid-sized and first-time exporter deals before they reached a risk decision — not by changing anyone's risk appetite, but by making the provenance question answerable at a cost that no longer eats the deal's economics. A bank that was risk-tolerant all along, but couldn't justify the document-chasing hours on a smaller ticket, now can.
Why this needs to be agent-reachable, not just analyst-reachable
The exporters this helps most are, by definition, higher-frequency and lower-ticket than the large names every bank already has a relationship with — which means the provenance check has to run at a volume and speed that manual document review was never going to reach. An AI agent working a pipeline of export-finance applications can pull provenance status the moment an application lands, the same way it can pull a duplicate-financing check or a pre-credit signal — surfacing a verified answer before a human analyst's time gets spent chasing documents that, for most applications, check out cleanly and don't need a human's attention at all.
That's why Export Provenance sits inside the same MCP access model as every other family here: a scoped agent key, deny-by-default discovery, the same audit trail a REST call would produce. The agent pulls the provenance status. The lender's own team decides what the risk view is once the facts are no longer the bottleneck.
The trade-finance gap will not close because banks decide to tolerate more cross-border risk. It closes when proving a trade is real stops costing more, per deal, than the deal is worth — and that's a provenance problem, not an appetite problem.
See a Trade-Provenance Pack verified live, or read the developer overview.