Gives
Permissioned access to purchase orders and contracts already issued to tier 1.
Gets
A mapped deeper supply base with financial-health and criticality signals — and suppliers who stay solvent enough to deliver.
The mechanics
One invoice. Three companies. A story a funder can underwrite.
Nothing here requires a new commercial arrangement between the tiers. The documents that prove the transaction already exist — they're just scattered across three ERP systems that don't talk to each other. Our job is to assemble them into one verified record, and stand behind it.
The chain
Demand cascades down. The invoice comes back up.
Before the invoice we finance ever exists, a chain of commitments has already formed. Each link leaves a document behind, and each document is the evidence for the next one.
Step A
Anchor → Tier 1
The OEM issues a purchase order or contract to its tier 1 supplier against a build programme. Documented, investment-grade demand.
PO / contract in the ERP
Step B
Tier 1 → Tier 2
To fulfil it, tier 1 issues its own purchase order to tier 2 for parts, castings or material — derived from the anchor's order.
PO in the ERP
Step C
Tier 2 → Tier 1
Tier 2 delivers the goods and raises an invoice on tier 1 against that purchase order. This is the financeable event.
Invoice — financed
Why the link matters
Read on its own, a tier 2 invoice is a claim on a small company's word. Read in the chain, it is a claim traceable to an OEM's build programme, acknowledged by a tier 1 that received the goods. Same invoice, entirely different risk.
And what closes the loop
What tier 1 machines or assembles from those parts flows onward to the anchor under Step A. The output is tied back to the demand that started it — which is what makes the chain a loop rather than three unrelated trades.
End to end
Following one transaction from order to disbursement
AnchorTier 1
Data access is granted, once
The anchor and tier 1 grant permissioned, read-only access to the trade documents they already exchange, scoped to an agreed programme. This is the only thing they are asked for — no facility, no guarantee, no treasury programme.
Anchor PO / contract
Tier 1 PO to tier 2
Master data
Tier 2
Tier 2 delivers and applies
Having shipped the goods, tier 2 raises its invoice on tier 1 and submits a funding application through the platform — uploading the invoice, the purchase order it answers, and proof of delivery.
Us
We assemble and verify the story
We match the invoice to tier 1's purchase order, that purchase order to the anchor's demand, and the delivery to the invoice lines. Quantities, parties, dates and values have to agree. Where they don't, the application stops here.
Invoice ↔ T1 PO
T1 PO ↔ Anchor PO
Delivery ↔ invoice lines
Counterparty identity
Funder
The funder underwrites the transaction
The verified record goes to the funder bank, which assesses the transaction with the credit quality of the anchor and tier 1 in view — not the tier 2's balance sheet in isolation. It lends into the transaction directly; there is no program facility standing between them.
Tier 2Funder
Terms offered, funds disbursed
If approved, the funder issues terms — intended to be better than what tier 2 could contract directly with a high-street bank on its own standing. Tier 2 accepts and receives funds against the invoice.
Tier 1
Settlement on the original due date
Tier 1 pays the invoice when it always would have, on unchanged terms. Nothing about its working capital position or DPO moves.
AnchorTier 1
Intelligence flows back up
Every verified transaction sharpens the map. The anchor and tier 1 receive supply-chain health analysis on the deeper tiers: who is there, which operations are critical, whose funding demand is accelerating, and where financial stress is building before it becomes a missed delivery.
The exchange
Data for liquidity, liquidity for resilience
The model only works because each party gives something it already has and gets something it can't buy elsewhere.
Gives
Permissioned access to purchase orders issued to tier 2, and acknowledgement that goods were received.
Gets
A funded, more stable sub-tier at no cost to its own cash, terms or credit lines — plus visibility on which sub-tier firms are straining.
Gives
Its invoice, the purchase order behind it, proof of delivery, and company identification.
Gets
Cash at delivery on terms priced off the chain above it, with no facility to negotiate and no programme to join.
Compared with conventional SCF
Why this reaches where programs can't
| Conventional SCF program | Commercial lending to tier 2 | Deep-tier financing | |
|---|---|---|---|
| How deep it reaches | Tier 1 only | Any tier, at any price | Tier 2 and beyond |
| What is underwritten | Confirmed payables of the anchor | The borrower's balance sheet | The verified transaction and the demand behind it |
| Setup required | Treasury-run program, legal & onboarding per supplier | Facility negotiation, collateral, guarantees | Permissioned data access, then per-transaction application |
| Anchor / tier 1 obligation | Payables confirmation, facility, accounting treatment | None — and no benefit either | Data only. No facility, no guarantee, no terms change |
| Pricing driver | Anchor credit | Tier 2's own rating and size | Chain credit — anchor and tier 1 in view |
| Visibility produced | Tier 1 payables only | None | Deep-tier map, health and criticality signals |
FAQ
The questions we get first
Does the anchor or tier 1 have to set up a funding program?
No. That is the point of the model. Neither party contracts a facility with the
funder, confirms payables, or runs a program inside treasury. Their contribution is permissioned
access to trade documents they already exchange.
Does anyone's payment terms change?
No. Tier 1 pays the invoice on its original due date. The anchor's terms with
tier 1 are untouched. The financing sits between tier 2 and the funder.
What ERP data do you actually need?
The documents that evidence the chain: the purchase order or contract from the
anchor to tier 1, the purchase order from tier 1 to tier 2, and enough master data to identify
parties and parts. From tier 2 we need the invoice and proof of delivery. Access is read-only and
scoped to an agreed programme under a data agreement — we are not asking anyone to share their
general ledger.
Who takes the credit risk?
The funder. It lends directly into the transaction and assesses it with the
anchor's and tier 1's credit quality in view. We are the verification layer that makes that
assessment possible; we do not take the credit position.
What if the documents don't reconcile?
The application stops. Our value to the funder is that a verified story is
genuinely verified — quantities, parties, dates and values have to agree across the chain. A
mismatch is surfaced rather than smoothed over.
Why would terms be better than a commercial bank's?
Because the funder is not pricing a small company in isolation. It is pricing a
documented transaction whose demand originates with an investment-grade anchor and whose delivery has
been acknowledged by a tier 1. Better information and better-quality underlying demand should mean
better terms than tier 2 can contract on its own standing.
What does the anchor learn about its suppliers?
Who sits beneath its tier 1s on a given programme, which of those operations are
critical or single-sourced, and financial-health indicators derived from verified trade activity and
funding demand — including early signals such as accelerating funding requests or deteriorating
payment behaviour. It is supply-chain intelligence, produced as a by-product of financing.
Does tier 2 need its customer's permission to apply?
Tier 2 applies on its own initiative with its own documents. Verification does
depend on the tiers above having granted data access for that programme, which is why we start by
onboarding an anchor and its tier 1s before opening applications beneath them.
Get started
Where you start depends on where you sit
Anchors and tier 1s start with a data conversation on one programme. Tier 2 suppliers start with a single invoice.