# Phase 6 — Give funding partners a complete view

## From one opportunity to a portfolio

Phase 2 introduced one funding partner reserving the principal of one accepted case. That is a useful teaching slice, but a real product story needs to explain what happens when a partner has several commitments, different preferences and a portfolio to understand.

This phase is about confidence in the funding view. A partner should know what they declared as available, what is reserved, what has actually been deployed, what has been received and what remains uncertain. The application must not turn a forecast into a promise or a reserved amount into cash that can be withdrawn.

The commercial model remains an open decision. Direct lending, pooled investment and fractional participation have different ownership, allocation and payout rules. We will describe those alternatives honestly rather than quietly choosing one in code.

## The funding partner’s questions

A partner needs answers in a sensible order:

1. What capacity have I declared and what has been verified?
2. Which opportunities fit my permitted mandate?
3. What amount would be reserved if I commit?
4. Has the opportunity become deployed exposure, or is it still awaiting a release condition?
5. Which receipts are confirmed, which are projected and which are unresolved?
6. What action is required from me, and what information am I allowed to see?

These questions should be answered by a consistent portfolio model, not by adding numbers from several screens that use different definitions.

## Capacity, reservation and exposure

| Figure | Meaning | Example |
| --- | --- | --- |
| Declared capacity | What the partner says they could provide. | £100,000. |
| Verified capacity | What checks permit the platform to consider. | £75,000. |
| Available capacity | Verified capacity less active reservations under the agreed policy. | £50,000. |
| Reserved commitment | Capital held for an accepted opportunity. | £5,000 reserved. |
| Deployed exposure | Capital confirmed as released under the agreement. | £5,000 deployed. |
| Projected return | A calculation based on future assumptions. | £5,250 projected. |
| Confirmed receipt | Money the platform has authoritative evidence of receiving. | £450 received. |

The labels and calculation dates must be visible. “Balance” on its own is too ambiguous for a funding partner.

## Mandates and allocation

A mandate describes the opportunities a partner is permitted or willing to consider: product type, amount range, term, geography, risk policy and concentration limits. It does not grant access to every borrower document.

Allocation rules answer how available capital is assigned when several partners are eligible. Possible approaches include partner choice, a defined priority order, proportional allocation or a pooled rule. Each has consequences for fairness, explainability, capacity and withdrawal.

The website project will treat the allocation rule as a product decision with a version and effective date. A change to the rule should not retroactively make an earlier allocation look as though it followed a policy that did not exist at the time.

## Protecting borrower information

Funding partners need enough evidence to make an authorized decision, but they should not automatically see every identity document, internal reviewer note or support conversation. Access should be scoped to the opportunity, the partner’s mandate and the permitted information category.

The API should enforce this boundary on every query. Hiding a field in Angular is not sufficient. A partner’s portfolio endpoint should return a purpose-built projection and should be covered by tests proving that borrower and internal fields are absent.

## Performance without misleading speed

A portfolio view may contain thousands of commitments. The ASP.NET application should use stable pagination, indexed queries, defined reporting dates and a clear indication when figures are calculated asynchronously. A fast screen that quietly mixes yesterday’s receipts with today’s reservations is worse than a slower screen that states its freshness.

For larger reports, a read model or governed reporting store may be appropriate. The source event and calculation definition must remain traceable. Caching should not make a confirmed receipt disappear or show an old available-capacity figure during a commitment decision.

## Projected, accrued and received

A projection is an estimate based on assumptions. Accrued value may be calculated under an agreement but not yet received. A confirmed receipt is supported by evidence. A partner may see all three, but the interface must not present them as interchangeable.

Losses and exceptions need their own event, policy and explanation. A borrower missing a payment is not automatically a final loss. A written-off amount is not proof that the borrower never paid. These distinctions protect both the partner’s understanding and the integrity of reports.

## A partner portfolio story

Imagine Cedar has three fictional commitments. One is reserved but not deployed. One is deployed and has two confirmed receipts. One has a payment with an Unknown outcome.

Cedar’s dashboard should show three separate positions and an investigation notice. It should not add the Unknown payment to received money, should not treat the reserved case as deployed exposure and should not show a projected return as withdrawable cash.

The operations team needs the detailed underlying events. Cedar needs a concise but trustworthy explanation. The borrower sees only their permitted loan information. One domain history supports all three views.

## How this demonstrates senior ASP.NET engineering

This phase shows the value of a senior engineer who can connect product rules to data access and user experience. The implementation would use explicit read models, policy-aware query handlers, pagination, concurrency checks around capacity, versioned mandates and tests for information scope.

The difficult work is not drawing a portfolio card. It is defining every number, identifying its source and ensuring that an allocation cannot exceed capacity when two commitments arrive together. It is also knowing when a product decision remains open and refusing to hide that uncertainty behind a convenient default.

## Evidence for completion

We should be able to demonstrate that:

- capacity cannot be reserved twice under concurrent requests;
- available, reserved, deployed and received figures have definitions and dates;
- allocation follows a versioned rule;
- a partner cannot see another partner’s portfolio or restricted borrower evidence;
- projected values are clearly labelled and never presented as confirmed cash;
- Unknown and loss events remain visible in partner and operations views;
- large portfolio queries are paged, indexed and freshness-aware.

## Guided practice

Create a portfolio summary for three synthetic loans: one reserved, one deployed with receipts and one with an unresolved payment. Explain every total, state its as-at date and identify which figures must not be presented as cash available to withdraw.