Double Financing & Receivables Fraud in Supply-Chain Lending

The Oldest Trick in Trade Finance

A receivable can only be paid once. So if a borrower can persuade two lenders to each advance against the same purchase order or invoice, the borrower walks away with double the cash — and at least one lender is left with a claim on money that has already gone to the other. This is double financing, and its quieter siblings — multiple and partial financing — are among the most persistent frauds in supply-chain lending. India has seen large, well-publicised cases where the same receivables or warehouse stock were pledged across a syndicate of lenders.

Why It Persists

The fraud survives not because lenders are careless, but because of a structural blind spot: no lender can see what the others have already financed. Each underwrites in isolation. Three things have to be true to stop it, and historically none of them held across the market:

• A canonical identity for the receivable.If lender A records the deal as "PO-4471 from Acme" and lender B records "Acme order, Mar", no system can tell they are the same thing. Without a shared key, collision is undetectable.
• A place to look before lending. Even with a canonical key, a lender needs a registry to check against — and to write to — at the moment of disbursement.
• Coverage of every lender. A registry only a few lenders consult leaves the fraud a clear run through everyone else.

The Building Blocks India Already Has

The good news: two of the three pieces now partly exist.

• GST e-invoice (IRN). The Invoice Reference Number issued by the IRP gives a genuine, government-anchored canonical identity for an invoice — a far stronger key than a free-text PO number. It is the natural backbone for de-duplicating receivables.
• CERSAI. The Central Registry of Securitisation Asset Reconstruction and Security Interest of India records security interests over assets, originally to stop the same property being mortgaged to multiple banks. Its remit has widened over time toward security interests more broadly.
• TReDS. Within a single TReDS platform, an invoice financed there cannot be financed again on that platform — a real, if bounded, dedup.

The Gaps That Remain

Each building block stops short of the full problem:

• TReDS is siloed. Dedup holds within a platform, but an invoice discounted on one platform — or financed bilaterally, off-platform — is invisible to the others. The off-platform bilateral deal is exactly where pre-shipment PO finance lives.
• CERSAI was built for charges, not real-time trade receivables. It is not, today, a real-time, every-lender, check-at-disbursement registry for the high-velocity receivables that supply-chain finance turns over.
• Pre-shipment has no invoice yet. The IRN exists only once an invoice is raised. For a purchase order financed before shipment, the canonical key has to be derived from the PO and the buyer acknowledgement, not an IRN.

Side by side, each block covers a real slice of the problem and stops at the same edge — the off-platform, pre-shipment, cross-lender deal:

The net effect: the market has the raw materials for a universal receivables-lien registry, but not yet the registry itself. That is the structural reason double financing remains the weakest-covered risk in trade finance — a point we are deliberately honest about.

The Architecture That Closes It

Preventing double financing reliably needs a layered design, and the order matters. We set it out in full in our design notes; in brief:

1. Canonical identity (L1). Pin every receivable to a stable key — the GST IRN where it exists, or a buyer-acknowledged PO key pre-shipment.
2. Amount-aware ledger (L2). Track cumulative financed amount against a cap, so partial stacking — not just exact duplicates — is caught.
3. Disbursement integrity (L3). The decisive moment. Before funds release, the lender runs a registry check and registers the lien in the same step— "no funds leave until the PO is cleared and the lien is registered." After money moves, it is too late to prevent anything.
4. Shared lien registry (L4).The centrepiece — a registry every lender (or their technology service provider) can check and write to, ideally as an open standard on common public infrastructure so it is independent of any one vendor. This is the only thing that closes the off-platform gap, and it is an ecosystem / regulatory undertaking, not a single company's product.
5. Immutable anchor (L5). Record registry entries in a tamper-evident registry so the record of who registered what, and when, cannot be quietly rewritten.

Honest Limits

It is worth stating plainly: no private platform can stop a determined off-platform lender who checks nothing. A universal guarantee requires either a regulatory mandate or near-universal voluntary adoption of a shared registry. What a technology service provider cando now is provide the canonical key, the amount-aware check, the disbursement-time register/check hooks, and operate an open registry node that others can join — turning "we couldn't see it" into "we checked, and registered our lien."

Where AssureLocker Fits

AssureLocker treats double financing as a synthesis problem first and a registry problem second. AssureSignal surfaces the canonical-key and cumulative-amount checks at underwriting; the platform exposes the disbursement-time register-and-check hooks for a lender to wire into its own release step; and AssureFirst is the shared, lender-side registry layer this points toward — a network lenders join and check independently, forming now with design partners.AssureLocker aims to own the synthesis, not to be the gatekeeper of the registry — it should belong to the market.

This article is an educational overview of fraud patterns and mitigation architecture in supply-chain finance. Descriptions of CERSAI, TReDS and GST e-invoicing are summarised for clarity; consult the relevant authorities for authoritative scope. Nothing here is legal, regulatory or financial advice.