Skip to main content
Droplinked’s lender layer doesn’t assume every lender does the same thing. Some do revenue-based finance, some do receivables, some do payables, some do invoice discounting, some run a Sharia-compliant interest-free variant. The Lender Product Catalog is the in-code list of the 6 financial-instrument types Droplinked currently supports; each lender opts in via LenderProductOffering rows that attach a product type to a (lenderId, productType, jurisdiction) triple, with their own yield band + ticket envelope. Routing then matches a merchant’s funding request against the active offerings — pre-filtered by the lender’s excludedSectors[] so a jewelry shop never sees a lender that has opted out of jewelry, even if the envelope would otherwise match.

​
At a glance

​
The 6 product types

These are the catalog typicals — defaults sourced from public UAE / GCC SME-credit market data. They are not what a given lender will offer; each lender’s actual band is set on their LenderProductOffering rows and overrides the catalog typical at routing time. Yield is denominated in basis points (100 bps = 1%). Ticket envelopes are denominated in USD in the catalog, then translated per jurisdiction at the offering level (e.g. AED for CredibleX-UAE rows).

​
For lenders: how to opt in

A lender doesn’t appear in any routing response until they have at least one LenderProductOffering row marked status: 'ACTIVE'. The opt-in flow:
  1. Lender (or their onboarding rep) browses GET /v2/lender-product-catalog to see the 6 product types and their typical bands.
  2. Lender picks the products they want to support and, per product, the jurisdictions they want to lend into (often a single jurisdiction per lender; can be multi).
  3. Operator runs POST /admin/lender-product-offerings once per (lenderId, productType, jurisdiction) triple with the lender’s actual yield band + envelope. The lender can override every catalog typical with their real numbers — and the routing layer uses those numbers, not the catalog defaults.
Example admin body for one offering:
When lenderYieldBpsMin/Max are supplied they override the catalog typical. When omitted they fall through to the catalog default. Same applies to the ticket envelope and tenor. status flips between ACTIVE (visible to routing) and PAUSED (hidden, kept for audit). Deleting an offering is rare — operators prefer PAUSED so the lender can re-enable without re-onboarding.

​
For merchants: how routing matches

A merchant doesn’t talk to the catalog directly. They request credit through the FE, which calls the lender-routing recommendation endpoint:
The routing service walks four filters in order:
  1. Jurisdiction — only lenders that have offerings in the merchant’s jurisdiction.
  2. Product — only offerings whose productType matches the request (when supplied — the productType filter is opt-in, legacy callers without it are unchanged).
  3. Envelope — only offerings where monthlyRevenueAed >= minMonthlyRevenue and requestedTicketAed falls inside [ticketMin, ticketMax] and the merchant’s merchantIndustry is in supportedIndustries (or the offering’s industry list is empty).
  4. Sector — any lender whose Lender.excludedSectors[] contains the merchant’s merchantSector is dropped, regardless of envelope match.
The response carries a matchingOfferings[] list so the FE can render per-lender competitive quotes:
The FE can then render “CredibleX competes on RBF at 17 – 22% yield, ticket AED 2Mn – 10Mn, tenor 6 – 12 months.” If multiple lenders match, each one is its own row and the merchant picks.

​
Excluded sectors

Lender.excludedSectors[] is a free-string array on the lender document — a hard filter applied after envelope match. The catalog ships a list of 9 common sector strings as a UX hint so operators can pick from a consistent vocabulary, but lenders are free to add custom strings outside the suggested list. The catalog list is suggestion only. Routing only checks string equality against Lender.excludedSectors[]; the source of truth is the lender’s own array. Operators edit a lender’s exclusions via PATCH /admin/lenders/:lenderId/excluded-sectors with the full replacement array — not a delta.

​
CredibleX-UAE reference example

CredibleX is the launch FSRA-licensed lender in jurisdiction AE. They are seeded on production with 4 ACTIVE offerings and 9 excluded sectors (all of the common 9 above), sourced from the UAE Qualifying Business Terms 2026 public underwriting policy. A merchant in AE doing AED 1.5M / month in revenue, asking for AED 3M of RBF, will not match CredibleX’s RBF offering (revenue floor is AED 20M). They will match the INTEREST_FREE_RBF offering (revenue floor AED 2M) — and the routing response will show that competitive line.
  • Inventory MCP — catalog discovery for agents; mostly orthogonal to lender routing but worth knowing
  • Lender Trinity MCP Tools — verify_lender / recommend_lender / recommend_service_provider; this catalog feeds the recommender
  • Trust fabric — Schema A / B / C / D EAS attestation chain context; the LenderRegistry is the entity layer this catalog sits on top of
  • Merchant Discovery Rules — KYB visibility rules for the discovery surface; same verifiedTier gate applies before a merchant can request credit through the routing layer