Case study · Private credit · Loan monitoring

Know which borrower may miss its next interest payment while you can still act.

You're a credit analyst at a fund that lends directly to private companies. Your borrowers hold cash in many currencies. Night’s Watch warns you when one may not have enough usable cash for its next interest payment, and ranks which to handle first, by money at stake.

Open the prototype Delivery deck (PDF, 32 pages) Code Built as a product assignment for Liquidity, a private credit lender. All data is synthetic. No AI model call.

$796Kusable of $9.31M held, in the sample bank file

91%of that cash in currencies it can't convert or send

1.04 → 0.38coverage after a euro freeze in the demo: rank 3 to 1

19 of 19automated checks of the maths pass

For: A fund that lends directly to private companies and collects interest in cash
Users: You, the credit analyst, and your head of credit, who sets the warning threshold
Data: Synthetic borrowers and a sample bank file: 62 accounts, 22 currencies
Built with: Static web pages, a simulated CRM and bank connector

TechniquesData scienceLiquidity at risk: P10 / P40 / P50 rangeData engUsable cash by currency convertibilityData scienceRisk tiers and P1 to P4 prioritisationData engMedallion data model, raw to cleanData engField-level lineage to CRM and bank fieldsData engEvent replay over a simulated connectorEval19 automated checks of the maths

01 · VISION

No missed interest payment arrives without a warning.

Today you learn a borrower is short of cash on the payment date, when the easy fixes are gone. The vision: every borrower's usable cash forecast to its next payment date, ranked by money at stake, with every number one click from its source.

02 · THE PROBLEM

Five things go wrong today.

1 · A borrower looks safe when it isn't

The cash total you watch includes currencies the borrower can't convert or send. In the sample file, $9.31M is held and $796K can pay you.

2 · You see the shortfall too late

Cash on the payment date is unknown today, and a single guess hides the bad case.

3 · Big losses wait behind small ones

Each analyst handles borrowers in their own order, not by money at stake and recoverability.

4 · Warnings get rebuilt or ignored

A warning you can't check gets rebuilt in a spreadsheet, or set aside.

5 · No history to set the threshold

Actions and outcomes aren't recorded, so nobody can tune when a warning should fire.

03 · THE SOLUTION

Code forecasts usable cash. You decide what to do.

Only usable cash counts. Each balance is converted to dollars and weighted by how convertible its currency is: 1 if free, 0.5 if partly, 0 if blocked.
A range on the payment date. Low, lower-middle and middle guesses of usable cash (P10, P40, P50) set the level: None, Low, Medium or High. Bank data older than 3 days raises it.
Worst first, then money at stake. You get a ranked list with P1 to P4 priority, split by principal and recoverability.
Every number traced, every action logged. Each figure shows its formula and source field. Your action is logged next to the warning.

04 · HYPOTHESES AND IMPACT

One job, one bet, one number each.

Your job	Hypothesis	Metric and target, then result	Expected impact
When bank balances arrive, I want coverage on cash the borrower can actually send, so no one looks safe when they aren't.	If coverage counts only usable cash, fewer borrowers look safe just before a missed payment, because trapped cash can't pay interest owed in dollars, euros or pounds.	Share of missed payments with coverage of 1.0 or more one period before: down. Baseline unobserved. Sample file: 91% trapped	Fewer missed payments that arrive without a warning
When I look ahead, I want the bad case on the payment date, so I warn in time.	If the warning depends on where cash due falls in the range, more misses are flagged in time at the same false alarm rate, because the threshold sits at the bad-case end.	Recall: share of missed payments flagged at least N days before the date: up. Baseline unobserved	More time to fix a shortfall (unobserved)
When I plan my day, I want the most money I can still save on top, so I handle it first.	If the list is sorted by level and principal at risk, more principal at risk gets an action on the day of the warning, because the largest savable loans come first.	Principal at risk with an action within one day: up. Baseline unobserved	More principal protected per analyst hour (unobserved)
When a borrower is flagged, I want every number traced to its record, so I can check it before I call.	If every number shows its formula and source field, you act on warnings sooner, because checking takes a click, not a rebuild.	Time from warning to first action: down. Baseline unobserved	Fewer warnings dismissed as wrong (unobserved)
When I act, I want it logged where I saw the warning, so my head of credit sees nothing was ignored.	If logging sits on the warning screen, more warnings end in a recorded action, because the step costs one click.	Share of High and Medium warnings with an action logged within one day: up. Baseline unobserved	A record to set the warning threshold

Must not get worse: the false alarm rate (warnings where the borrower then paid in full) stays under the limit your head of credit sets. No analyst has used the tool, so every result is still unobserved.

05 · THE VALUE

What it's worth, and what it asks of you.

In the sample bank file, a borrower holds $9.31M. Only $796K is in currencies it can use to pay you.

You, the credit analyst

You get: "I open the list and the borrower most likely to miss its interest payment, with the most money at stake, is on top. I can show why in one click."
Will you believe it?: Medium. Every number is traced. The forecast assumes cash falls by the same amount each day. It hasn't been tested against real missed payments.
How fast: Low delay. The demo recalculates every borrower when bank data changes. Time from real bank data to warning is unobserved: no live connection yet.
What it takes: Medium. No spreadsheet to rebuild. The CRM must stay up to date: next payment date, cash or PIK interest, recoverability.
What you give up: Medium. Your own order of work, for a shared rule. One more screen next to the CRM.

Your head of credit

They get: "No borrower defaults without us seeing it coming, and the team works on the most money at risk each day."
Will they believe it?: Low to medium. Depends on how many borrowers' bank data is connected, how complete the CRM is, and a threshold set on few known missed payments.
How fast: High delay. Missed payments are rare, so recall takes quarters to measure.
What it takes: High. Bank and CRM connectors, data quality checks, access control and a data protection review.
What they give up: Medium. Borrower bank data sits in one more system. Catching every miss first means accepting more false alarms.

The weak link is belief, for both of you. For you: test the forecast on past data. If actual cash on the payment date lands above P10 about 90% of the time, the forecast is well set. For your head of credit: sit with two analysts and compare their order of work with the tool's list on the same day.

06 · LIMITATIONS

What this doesn't prove yet.

Data: the borrowers are made up. The sample bank file is one snapshot in time, so spending rate and months of cash left can't be computed from it.
Users: untested. Every "before" is assumed.
Accuracy: unmeasured. The forecast assumes cash falls by the same amount each day, with bell-curve swings.
Discounts: counting partly convertible cash at 50% is assumed. The currency categories need checking with the team and the currency (FX) desks.
Money at stake: principal at risk is the full principal, not an expected loss.
Demo: one loan per borrower, fixed exchange rates, and everything resets on reload.

07 · SCOPE AND NEXT STEPS

What it won't do, and what comes next.

Non-goals

A real CRM or bank connector. The connector is simulated.
A full recoverability view. You enter a rough Strong, Partial or Weak score. No balance sheet or loan condition data.
A learned threshold. Fixed cut-offs: no past missed payments to learn from.
Automated actions. You keep every decision.
Forecasting money coming in, credit lines, borrowers with several loans, access control.

Test the forecast on past snapshots once their payment dates pass. This costs data, not users.
Sit with two analysts and compare their order of work with the tool's list.
A Salesforce connector in place of the simulated one.
A four-week pilot to count warnings that end in a logged action.

RESOURCES

Go deeper.

Try the demo, step by step three steps, in order

Open the prototype. Your portfolio is ranked worst first, by cash coverage and money at risk.
Click a company. You see its cash story: usable versus stuck cash, the trend, and why it's flagged. Each number traces to its source file.
Log your action on the same page. Then open the connector simulation: edit a balance and watch your ranking change.

Also: agent view · data roadmap · data model

Main learnings what the sample bank file and the demo showed

Sample bank file: 62 accounts, 22 currencies, $9,311,675 total. Only $795,714 (8.5%) sits in US dollars, euros or pounds (USD, EUR or GBP). This supports hypothesis 1. The deck said 82% was trapped; the file shows 91%.
Missing IDs: 17 of 62 rows have no account ID and hold $2,573,737 (28%). Without a way to build an ID, that cash drops out of the count.
Tests: demo/test.js runs 19 checks on 3 fixed borrowers plus 2 bank data events. 19 pass.
Demo event: a euro freeze at Agri A moves coverage from 1.04 to 0.38, Low to High, rank 3 to 1. This shows how the logic of hypotheses 1 and 2 works, not whether it's accurate.
Recall-first (warn early, accept more false alarms): Telecom C has coverage 1.02 but level Medium, because cash due sits above P40. The warning fires before coverage drops below 1.
Users: nothing observed. No analyst has used either the prototype or the demo.

Hypotheses in full before and after, and the test for each

1 · TRAPPED CASH

Before -> after: coverage on all cash -> coverage on usable cash only
Hypothesis: If coverage counts only cash the borrower can send, then fewer borrowers look safe just before a missed payment, because trapped cash can't pay interest owed in dollars, euros or pounds.
Metric: Share of missed payments where coverage was 1.0 or more one period before. Down. Baseline unobserved. Guardrail: false alarm rate (warnings where the borrower then paid in full) stays under the limit the head of credit sets.
Test: On past data with known outcomes, compute coverage on all cash and on usable cash. Count the misses each one flagged.

2 · FUTURE CASH

Before -> after: today's cash vs the payment -> P10, P40, P50 range on the payment date
Hypothesis: If the warning depends on where cash due falls in the range, then more misses are flagged in time at the same false alarm rate, because the threshold sits at the bad-case end, not the middle.
Metric: Recall: share of missed payments flagged at least N days before T1 (N set by the credit team). Up. Baseline unobserved.
Test: Test on past snapshots kept aside. Check the range (actual cash above P10 about 90%, above P40 about 60%), then recall vs precision at each cut-off.

3 · ORDER OF WORK

Before -> after: each analyst's own order -> worst first, then P1 to P4 by money x recoverability
Hypothesis: If the list is sorted by level and principal at risk, then more principal at risk gets an action on the day of the warning, because the largest loans that can still be saved are handled first.
Metric: Principal at risk with an action logged within one day of the warning. Up. Baseline unobserved.
Test: Watch two analysts sort their day's work, then run the same day's list in the tool. Compare order and principal covered in the first hour.

4 · TRUST

Before -> after: numbers rebuilt in a spreadsheet -> each number traced to its CRM or bank field
Hypothesis: If every number shows its formula and source field, then analysts act on warnings sooner, because checking takes a click, not a rebuild.
Metric: Time from warning to first action. Down. Baseline unobserved. Also: share of warnings dismissed as wrong.
Test: Five flagged cases. Time to check with raw files only vs with the trace.

5 · FOLLOW-THROUGH

Before -> after: actions in email and memory -> logged with level and coverage at the time
Hypothesis: If logging sits on the same screen as the warning, then more warnings end in a recorded action, because the step costs one click. Each record also becomes data for setting the threshold.
Metric: Share of High and Medium warnings with an action logged within the agreed time (deck: e.g. one day). Up. Baseline unobserved.
Test: Count over a four-week pilot.

All sub-problems the 8 found, and the 5 this build tackles

Trapped cash. The cash total includes currencies the borrower can't convert or send, so coverage looks fine when it isn't.
Future cash. Cash on the payment date is unknown today, and a single guess hides the bad case.
Order of work. Each analyst handles borrowers in their own order, not by money at stake x recoverability.
Trust. A warning nobody can check gets rebuilt in a spreadsheet or ignored.
Follow-through. Actions and outcomes aren't recorded, so there's no history to set the threshold.
Data plumbing. Bank balances and loan terms sit in separate systems, updated at different times.
Recoverability. Whether a borrower can fix a shortfall, and what the lender gets back if not, needs financial statements, the lender's place in the repayment queue and the loan's conditions.
Calibration. Setting the threshold needs past missed payments to learn from, and few exist.

This build tackles 1 to 5.

How it's built inputs, usable cash, range, level, rank

Input. Simulated bank data (account, currency, balance in local currency, exchange rate, and how convertible the currency is) and a simulated CRM loan record (principal, interest rate, payments per year, share paid in cash, next payment date, recoverability).
Usable cash. Local balance x exchange rate x a factor: 1 if freely convertible, 0.5 if partly convertible (assumed discount), 0 if blocked.
Range on the payment date (T1). P50 = usable cash minus daily spending x days to T1. Spread = the usual daily swing in cash (standard deviation) x square root of days. P40 and P10 sit 0.25 and 1.28 spreads below P50.
Cash due. Principal x interest rate / payments per year x cash share. A loan with all interest added to the loan (full PIK) owes no cash at T1.
Coverage and band. Coverage = P50 / cash due. Band = P10 / due to P40 / due. This is the liquidity-at-risk method from the assignment deck: how low usable cash could fall in a bad case.
Level. Cash due at or below P10: None. Up to P40: Low. Up to P50: Medium. Above P50: High. If bank data is more than 3 days old, the level is raised to at least Low.
Rank and priority. Worst level first, then principal at risk, then coverage. High and Medium get P1 to P4, split by principal of $2M or more and recoverability score of 0.5 or more.
Output. A ranked list, a trace of every number to its source field, and an action log.

How success is tracked five layers, from signal to business result

The assignment deck sets five layers of success. Each layer builds on the one before.

Layer	Metric	Type	Tests hypothesis	How measured
Signal + pipeline	Share of warnings sent within the agreed time	Early signal	1, 2 (precondition)	Bank data timestamp vs warning timestamp
Signal quality	Range accuracy; recall and F1 (recall and precision combined) on known missed payments	Early signal	1, 2	Test on past snapshots kept aside
Operation	Share of warnings with an action within the agreed time (e.g. one day)	Early signal	4, 5	Action log timestamps
Decision	Principal at risk handled in the first hour; principal saved over time	Early / late signal	3	Action log joined to outcomes
Business	Near-losses, same or fewer; defaults nobody saw coming	Late signal	All	Credit records, quarterly

Scope in scope and out of scope

In scope	Not in scope (includes sub-problems not tackled)
Usable vs trapped cash, by how convertible each currency is	Data plumbing (6): no real CRM or bank connector. The connector is simulated; a Salesforce connector is next
Range of usable cash on the next payment date	Recoverability (7): a rough Strong / Partial / Weak score the analyst enters. No balance sheet, cash flow or loan condition data
Level rule, worst-first ranking, P1 to P4 priority	Calibration (8): fixed cut-offs and an assumption that daily cash swings follow a bell curve. No past missed payments to learn from
Trace of every number to a simulated source field	Forecasting money coming in (contracts, sales pipeline, interest rates, input costs)
Action log, event replay, field edits	Automated actions. The deck allows them later, only for low-stakes cases that can be undone
Automated test of the maths	Morning summary email, credit lines the borrower can draw and repay, borrowers with several loans, access control

Trade-offs what was chosen, over what, and the cost

Chose	Over	Gain	Cost
warn at P40 (recall-first)	warn at P10	fewer surprise defaults	more false alarms, each costing an analyst hour
usable cash only	all cash	coverage matches what can pay interest owed in dollars, euros or pounds	depends on correct currency categories
rules and a range now	a statistical model now	easy to explain, runs without past outcomes	rougher forecast until outcomes build up
full principal as money at stake	expected shortfall	simple, matches the deck's four priority boxes	overstates small shortfalls on large loans
static page, simulated connector	live CRM link	$0, public, no client data	shows the logic, not the connection
human-logged actions	automated actions	analyst keeps every decision	one manual step per warning

Terms on this page plain definitions

Cash interest payment: interest the borrower must pay in money on a set date.
PIK (payment in kind): interest added to the loan instead of paid.
Usable vs trapped cash: cash the borrower can convert and send / cash stuck behind currency rules.
Coverage: expected usable cash on the payment date divided by the payment due. Below 1 means short.
P10, P40, P50: low, lower-middle and middle guesses of usable cash on the payment date.
Principal: the amount lent, before interest.
Recoverability: how likely the lender gets its money back.
Recall / precision: share of missed payments the tool warned about / share of warnings that were right.

Delivery deck the 32-page assignment deck: signal, workflow, data roadmap, success measures

Night’s Watch has no separate opportunity assessment or PRD. The delivery deck plays both roles. Open the PDF in a new tab.

Related project and links BDC Footnote Tape, prototype, code

Related project: BDC Footnote Tape. It asks the same question (which borrowers are in trouble) from the public filings of BDCs (stock-listed funds that lend to private companies).

Prototype · Deck (PDF) · Code
Connector simulation

How it was built with PM OS the product process, step by step

Stage	Artifact	Repeatable with
Discovery	Questions for the credit team: what counts as distress, how early to warn, recall vs precision	`/interview-guide`
Opportunity	Sample bank file analysis: $9.31M total cash, $796K usable	`/opportunity-analysis`
Strategy	32-page assignment deck: warning signal, workflow, data roadmap	`/write-prod-strategy`
PRD	Requirements and data model: entities, data layers from raw to clean (medallion), phases	`/prd-draft`
Metrics	5-layer success model, from warning on time to business outcome	`/metrics-framework`
Rollout	Staged internal rollout plan with resources per stage	`/launch-checklist`
Build	Static prototype pages with goal files; this demo	`/prototype, /goal-gate`
Showcase	This page, name audit, goals and state files	`/portfolio-case-study, /name-audit`

Skills are mapped from the artifact each stage produced. They show how each stage repeats with PM OS; the original working sessions were not logged.

PM OS skills used

/goal-gate /interview-guide /launch-checklist /metrics-framework /name-audit /opportunity-analysis /portfolio-case-study /prd-draft /prototype /write-prod-strategy