Skip to content

7.2 Allocation engine

When only one co-lending partner exists, every co-lent loan is split per the fixed ratio in the Master Co-Lending Agreement (typically 80:20).

For each co-lent loan:
partner_share_pct = 80
originator_share_pct = 20
partner_share_amount = loan_amount * 0.80
originator_share_amount = loan_amount * 0.20

Once 2+ partners are live, the engine needs to choose which partner gets each loan. Common strategies:

Each partner has a monthly funding capacity (negotiated in the agreement). The engine tracks running disbursement per partner and allocates next loan to the partner with most remaining capacity.

For each new co-lent loan:
eligible_partners = filter by:
- product match
- risk-grade match
- geographic / sector match
- exposure-cap remaining
- capacity remaining for current period
if no eligible partners → OWN BOOK or DECLINE
selected_partner = max(eligible_partners, key=remaining_capacity_pct)
ratio = agreement(selected_partner).ratio

Simple alternative — cycle through eligible partners. Risk: partner with lower appetite gets disproportionate share if not filtered.

Each partner has a priority score (cost-of-funds-equivalent, strategic preference). Higher priority first; fall through to lower as capacity exhausts.

eligible_partners = filter as above
sort by (priority_score DESC, remaining_capacity_pct DESC)
selected_partner = first

When a repayment lands, it splits between lenders per agreement. Typical waterfall:

OrderComponentAllocation to partnerAllocation to originator
1Penal chargesper ratio (or 100% to originator per agreement)per ratio
2Late feesper ratioper ratio
3Servicing feesusually 100% to originator (as servicing income)rest if any
4Interestper ratioper ratio
5Principalper ratioper ratio

Some agreements specify “interest first, partner first” sequencing for partner protection in stress. Pre-agreed and documented.

When the partner ratio changes (mid-relationship adjustment), allocate new loans at the new ratio; existing loans continue at their original ratio. The system records allocation_version on each loan to make the rule explicit.

Application
[Engine: run originator's policy]
originator_decision = APPROVE / DECLINE / REFER
[Engine: run partner(s) policy]
For each partner: partner_decision = APPROVE / DECLINE
┌──────────────────────────────────────────────┐
│ Combined outcomes: │
├──────────────────────────────────────────────┤
│ originator APPROVE + ≥1 partner APPROVE │ → CO-LEND
│ originator APPROVE + all partners DECLINE │ → OWN BOOK
│ originator REFER + any → manual │ → REFER
│ originator DECLINE │ → DECLINE
└──────────────────────────────────────────────┘
▼ (CO-LEND path)
[Allocator: choose partner]
[Allocator: compute split]
[Booker: book on both lenders]
[Disburser: escrow funding + disbursement]

If the LSP / originator provides DLG to a third-party RE (rare for inter-RE co-lending; common for LSP arrangements):

  • DLG cap of 5% of the LSP’s portfolio with this RE.
  • DLG monitored separately — see 7.5.
  • DLG does NOT change allocation logic — it’s a contractual side arrangement.
  • Partner approval API down at submission time → queue with retry; SLA tracked; if partner cannot approve in window, fall to own book or REFER.
  • Allocation exceeded partner’s cap mid-batch → next loans go to fallback partner or own book.
  • Originator policy approves but no eligible partner → own book if allowed; else REFER for manual review.

LoanApplication state machine extension for co-lending:

APPLIED
→ UNDERWRITING
→ DECISION_AVAILABLE (with originator outcome + per-partner outcomes)
→ ALLOCATED (partner chosen, ratio set)
→ AGREEMENT_GENERATED (co-lending disclosure embedded)
→ AGREEMENT_EXECUTED
→ BOOKING_INSTRUCTED (partner notified)
→ PARTNER_BOOKED (ack received)
→ ESCROW_FUNDED
→ DISBURSED
→ ACTIVE (LMS)
→ ... (regular LMS lifecycle, with share-level postings)