Sometimes the money is all there, and the trouble is already in the room. In fintech the first question is rarely how much cash a company holds. Founder of the School of Troubleshooters Oleg Braginsky and student Maksim Golub examine how one balance snapshot turns into a stress score.

Risk in lending does not arrive as an event. It accumulates. A borrower drifts for weeks, then one payment is missed and the whole picture appears at once. Periodic reporting shows the drift a quarter late, by which point the repayment buffer is already thin. The signal existed earlier, in the balances, but nobody read it.

Product teams feel the same lag from the other side. You ship a feature meant to prevent losses, and the proof arrives one year later, once the whole loan book has turned over. Anything that shortens that loop is worth building. An early signal is cheaper than late but crisp certainty, even when it is a little less precise.

Data does not help by default. Numbers arrive incomplete, stale, or in a schema nobody has seen before. Often there is no history to compare against, so no delta can be computed at all and no trend exists. The decision still must be made today, on the fragment of the picture that reached the one who analyses it.

Setting the Task

The task is to read borrower cash risk from a single hourly balance snapshot. Balances only: no transactions, no repayment schedule, no flag marking an account restricted. The output is one graded stress level plus the alerts an analyst opens first.

Before the mechanics, one question decides the shape of the product. Who acts on the number? A score built for a portfolio committee and a score built for a single deal owner are different products with the same arithmetic inside. Three roles touch borrower risk, and each reads the number differently.

Defining Personas

First persona: the monitoring analyst. Watches a set of borrowers, reads positions daily, decides whether to escalate or wait for the next file. Wants a filter that removes noise, not another dashboard, and resists any alert he cannot explain to the deal owner.

Second persona: the deal owner. Follows the companies she brought into the book and answers for them personally. She does not monitor the portfolio and does not want to. She wants a notification the moment her own borrower becomes fragile. Narrow and deep, the opposite of the analyst’s wide and shallow view.

Third persona: the credit committee. Looks above the individual deal at the health of the whole book. Needs a roll-up: how many borrowers sit in each stress tier, which way the count moved, and where it moved fastest. Detail matters less than comparability across borrowers and across the quarters behind them.

Measuring the Cash

Three numbers carry the mechanism:

• Total available cash: every account summed into one currency at a snapshot rate.
• Concentration: the share held by the top institution and the top three countries.
• Currency risk: value that devaluation removes, access that controls block.

Total cash answers the first question any lender asks and then settles nothing at all. For instance, two borrowers holding an identical balance are not in an identical position. One spreads the money across four banks in hard currency. The other keeps eighty per cent of it in one local institution under capital control.

Concentration measures that difference. One counterparty freezing, one authority imposing controls, removes the largest share of the buffer without warning. A share, not a sum, works with no history behind it.

Currency risk has two faces. First: value, how much can evaporate on a devaluation with no outflow at all. Second: access, how much is legally unavailable for repayment while it still sits on the balance sheet and shows up in the total. Both reduce what the lender can really collect, and neither is visible in the sum.

Naming the Constraints

The frame is narrow, and every later decision refers to it:

• Schema is unknown: the next borrower exports a file we have never parsed.
• Data arrives incomplete: institution keys and country codes go missing.
• The signal comes late: the snapshot lags the event that caused it.
• No history at cold start: no trend, no burn rate, no runway.
• Values float: rates move after economic news.
• One borrower per view: portfolio sits above.

One more constraint sets every threshold. A missed signal costs the principal, a false alarm costs ten minutes and a call. We are tolerant of false positives, intolerant of false negatives, and the weights say so.

Think of the smoke detector in the kitchen. It goes off when you fry fish, and everyone knows why it still hangs there. The night it matters pays for every false alarm before it. A cash score sits on the same wall.

Designing the Flow

Money becomes a decision in five stages:

1. Source: pull the hourly balance snapshot from the borrower’s banking systems.
2. Normalise: map any borrower schema onto the fields the product needs.
3. Compute: derive total cash, concentration and currency risk.
4. Score: turn the metrics into one graded stress level.
5. Act: escalate, call, or label.

A feedback loop closes the chain from Act back to Score: every alert marked true or false calibrates the next threshold. Without it the score freezes, and the analyst argues with a number that cannot learn.

Building the Score

Each stage needs its own green check before the next may run: normalisation that silently drops three accounts produces a clean-looking score computed on half the money. The chain is monitored, not assumed.

The score is a weighted sum: each component normalised to a fixed scale, multiplied by an expert-set weight, added up. Narrow scales are a trap: five points force distinct borrowers into one bucket.

The prototype above runs on 0 to 100 because a reader holds those numbers without effort. In production the same arithmetic runs on 0 to 1000: ten times the resolution costs nothing, keeps neighbouring borrowers apart, and leaves room for new components without recutting every threshold in the book.

Weights are visible and contestable: concentration 35%, currency risk 30%, liquidity buffer 25%, data quality 10%. An analyst who disagrees points at the line, not at the tool, and a black box would not survive.

Data quality earns 10% by limiting the other three components. Missing institution keys and country codes reduce confidence in concentration, and the sample file has seventeen such gaps across 62 rows. The score reports its own reliability instead of presenting a confident result from incomplete data.

One number then splits into four tiers:

1. Healthy: nothing to do, the position is boring and should stay that way.
2. Watch: look again at the next snapshot before saying anything.
3. Elevated: raise the flag and call the deal owner.
4. Stress: escalate now.

Assumptions and Validation

Three assumptions carry the product. Cash fragility today predicts repayment trouble later. A single snapshot carries signal without a per-borrower baseline behind it. The credit team can act on an early warning rather than merely receive it and file it away. If the third one fails, the first two stop mattering.

Validation runs cheapest first. Face-check: push known borrowers through the score, some the team escalated last year, some healthy, and see whether the number agrees with what the analysts already know. Half a day of work, and it kills the obvious errors before a line of production code exists.

Cohort backtest comes next. Take the cases the team managed manually (restructuring, covenant breach, escalation) and ask whether the score would have lit up in advance of the call that started them. This is the first honest measure of catch rate, and it runs only if historical snapshots were kept. Nobody keeps them by accident, so the question is asked before the project starts.

The labelling loop is expensive: it exists only in production. The analyst marks each alert agree, disagree or needs review, and writes why. A bare label says the number is wrong; the comment says which component.

Engineering Collaboration

The building is split into three layers by who owns the work:

1. PM builds, AI-assisted: prototype, metric and weight logic, known schemas.
2. PM specs, engineering builds: unknown schemas, alerting, feedback loop.
3. Engineering and security only: banking connection, storage, compliance.

The prototype is the specification, not the production code. Engineers run the calculation and read the weights straight from the source instead of reconstructing them from a document. Then they rebuild it to the reliability and security requirements, and the numbers stay identical on both sides of that line.

Security joins before the building, not at the review. Banking connections and financial-data storage carry compliance requirements that reshape the schema and the retention rules. Discovering them after the alerting service is written costs a rewrite, so they are priced in while the design is still cheap to change.

Rolling Out

Adoption counted in users is a vanity number: a tool reaches every analyst on the floor and catches nothing. Each phase is gated by the trust earned so far, on borrowers the team knows well.

1. Shadow: runs in parallel, drives no decision and carries no risk. Exit reading matches analyst judgement.
2. Assist: the score enters the decision. The analyst may overrule it and label each alert.
3. Operate: embedded in the workflow. Deal owners notified, labelling still running.

The first user should be a sceptical, experienced analyst working a difficult borrower. Convince the sceptic and the rest of the floor follows without a memo. A failure also surfaces on one person first, inside a conversation, instead of spreading across a department and landing in a support queue nobody reads.

Measuring Impact

• Adoption as action: 70% of alerts escalated, called on, or labelled by an analyst.
• Alert trust: a 60% floor on alerts later confirmed as real stress.
• Labelling coverage: 80% of alerts labelled after review.
• Catch rate: real stress events caught in advance.

Alert trust and catch rate are read as a pair, never one at a time. Optimise trust alone and the tool fires only on the obvious cases, staying silent everywhere else. Optimise catch alone and it fires on everything, and the analyst mutes it within a week. Neither number carries any meaning when it is read on its own.

None of the four is a target on its own. Adoption without trust means analysts click through; trust without coverage means the labels stop arriving and the score stops learning. The set is read as one instrument, and the weakest of the four sets the pace.

Inside the Product

The dashboard leads with the score and its tier, coloured so the state registers before a word is read. The sample borrower opens at 73 out of 100, Elevated. Under it sit three metric cards: $9.31M of total cash, 31.6% concentration, 91.5% currency risk, then the open alerts and an events panel.

Context is what prevents a wrong reading of that total. The events panel shows a $2.00M repayment due against $0.80M of hard currency available, next to a $0.62M payroll run and a $0.28M VAT payment in the same week. Nine million looks comfortable right up until those three lines sit beside it.

The alerts view names the rule that fired, the observed value, and the threshold it crossed. Here that reads as $2,941,538 parked in one institution against a 30% ceiling, four of the eight alerts still open. The analyst answers agree, disagree, or needs review, and the comment goes into calibration, not a support ticket.

Every alert is a hypothesis: analysts weigh the evidence, record their reasoning and compare the warning with the eventual outcome. Even a confirmed alert deserves scrutiny: the right answer for the wrong reason fails on the next borrower. In lending, trust is earned through evidence.

Distribution answers the question the total hides: where exactly the money sits. Cash by institution, by country, by currency type, plus the account table sorted by value, 62 rows across 29 institutions and 22 currencies. One glance shows that 41.7% of the whole buffer sits in a single country, Cameroon.

The point applies across the entire model. Each stage needs multiple layers of control, straightforward evidence, and auditable rationale for every decision. Where a rule still relies on expert judgement, that judgement should be captured explicitly, evaluated, and converted into measurable logic over time.

The data tab keeps the raw snapshot visible and read-only, all 62 rows of it. Any alert can be traced back to the rows that produced it, and any number on the dashboard can be checked against its source. A score that nobody can audit gets overruled once in a meeting and quietly ignored.

Customers should be able to trace every metric to its source, inspect supporting details, and see where data or analysis is incomplete without asking the team. Due diligence may allow time for review, but human judgement should remain in the loop wherever the evidence cannot support an automated decision.

What Comes Next

Five gaps separate this prototype from a portfolio-grade product:

1. Account-level flags for restricted, escrow and payroll cash. They change the liquidity denominator.
2. Alert lifecycle, covenant-aware thresholds. Calibrated score, limits bind to terms of each facility.
3. Ingest with human-in-the-loop mapping. Any format, schema confirmed once, reused then on.
4. Counterparty risk across borrowers. One bank holding cash for several companies.
5. From snapshot to trend. Trajectory, burn rate, runway in days.

Trend sits last on that list by length and first by value: trajectory, burn rate and runway remove the constraint the whole design was built around, the absence of any history.

Counterparty risk is invisible by construction: one bank can hold cash for four portfolio companies, and each scores acceptably read alone. The exposure appears only at the portfolio layer above this product.

What to Remember

1. Concentration and currency risk read a single snapshot; a share needs no history.
2. Weights stay visible: concentration 35%, currency 30%, buffer 25%, data 10%.
3. A missed signal costs the principal, a false alarm costs ten minutes.
4. Data quality caps what the other three components may claim.
5. A score with no labels stops learning the day it ships.

The lesson is general: a score is not a calculation you ship once and leave on a dashboard. It improves while the analyst argues with it, and the whole chain must stay healthy. Build the feedback path first.

It’s especially handy when I’m traveling, out and about, or just want to keep working on the move. Even in bed, I’ll sometimes review what I’ve been working on and add a few notes by voice.

P.S: the first funny case was actually trying to speak with someone on Telegram on behalf of myself, a lot of things to work on, but will improve it over the time :)

I am writing this for myself too. I was checking my backlog and saw the item “Try Orca” (it is a new ADE with thousands of stars on GitHub). I was about to install it and give it a go, but then thought - ok, if I proceed, what won’t I be doing? And apparently, that thing is far more important. Of course, of course, I will go ahead and play with this thing later, but it was a good exercise just to make sure I don’t build a fancy hangar while the airplane still cannot soar in the sky ✈️✈️

When I delegate something to an agent and it needs to access credentials, I still run the action manually and approve it.

The cool part is that this isn’t just a habit or a prompt instruction. The policy is embedded directly into the app. It keeps sensitive actions behind an explicit approval step and reduces the chances of credentials or other sensitive data being compromised. Yeah, manual work to lock and unlock, but hey - peace of mind it gives outweights the hustle 🤓

P.S. You can switch the language to English on YouTube, and it will translate the talk in real time. What a time to be alive, right? 😊

A simple example is PDFs: I work with them a lot, and instead of writing another parser from scratch, I can plug in something like Firecrawl’s pdf-inspector. It can classify PDFs, extract structured text and tables, convert content to Markdown, and help decide when OCR is actually needed. The interesting part for me is not the library itself, but the pattern: today you add better PDF handling, tomorrow browser automation, payments, vision, audio, research, logistics, whatever your work requires.

This is one of the things I always liked about Linux: you start with the core and install the pieces you actually need. I think AI assistants are moving in the same direction. The useful question becomes less “what can my assistant do?” and more “what capability should I plug in next?” 🤖🤖

The second lesson was selling myself. Talking to people, negotiating, hearing “too expensive,” handling objections. It can be uncomfortable and sometimes painful, but that is exactly why it works. It is like the gym: muscles grow because you put them under load. The next day everything hurts, but after enough repetitions, you become stronger.

The photo is from a full day at a local fair: sales, conversations, questions, mini-interviews, and a notebook packed with customer feedback by the end of the day (my legs were soring as hell!)

Data is useful. Frameworks are useful. But they are still a proxy. Every now and then, leave the dashboard, go where the customer actually is, and sell something yourself 😎

It reminds me a lot of loops in software: the system doesn’t need a new command every time. It keeps checking the environment, finding unfinished business and pushing things forward. This is where an AI assistant starts feeling less like a chatbot and more like an actual Chief of Staff 🤓

P.S: The text on screen is not from a real message, I do religiosly check screens I post hehe

I run my own backup system. Even my clipboard has a long history (yups). Still, an agent managed to delete an important document. I pushed it hard, checked what it could recover, and the answer was basically: nothing. That was an unpleasant moment. It also made me think about the scarier version of the same story. What if this happened quietly, and nobody noticed until much later?

Backups and version history saved me from turning one bad action into a real disaster. But the lesson was bigger than recovery. In systems where agents can act on your behalf, guardrails are not bureaucracy. They are common sense. Approval layers, action logs, protected areas, clear policies. All the things that feel excessive right up until the moment something goes wrong.

As a proper computer nerd, I spend a lot of time sitting in front of a screen. But if you opened my Obsidian notes, you’d see that most of them were written on my phone, usually while walking somewhere. There is a separate story here about how I work in tech but still don’t trust clouds. Everything is self-hosted, homemade, following the old family recipe.

Most notes appear while I’m moving. I like walking, looking at nature, and letting my brain wander. This morning, I spent about twenty minutes standing on a bridge and staring into the water. My inner voice said: “jump in, it’s August after all” (haha, just kidding). There was a whole other world down there: ducks floating on the surface with bodies perfectly designed for it, small fish below them, bigger fish deeper down, all moving through a forest of algae slowly waving in the sunlight. Dragonflies flew above the water. I imagine something like this once helped Frank Herbert think of the ornithopters in Dune. 🌕 Sport works in a similar way. You focus on one thing and simply try to do it. You learn how your body works, or in my case, how it mostly doesn’t. You practise a serve, test different movements, and naturally think: I’m smart, I’ll figure this out immediately. Usually you don’t. Then suddenly you find one small physical clue: “Ah, that’s what the body was supposed to do.” And something clicks. That is the point I keep returning to: rest is also work. It is the work of defragmenting and reorganising your thoughts. You can stare at your screen for hours, but after a certain point, the return becomes very small 🤓🎾

The day starts, and before you know it, you are already inside the flow: messages, meetings, requests, updates, follow-ups. You become very good at processing everything, while the important things quietly drift away:

• goals; - promises; - key relationships; - strategic priorities; - projects that actually need attention.

That is why I like the idea of a brief. Nice and neat one pager that tells you what deserves attention today or this week:

• what is blocked; - what matters most; - what you promised; - what you may be missing; - who you need to talk to; - which decisions are waiting;

Part two. Then comes the debrief. This is where you add back the things the system cannot fully see from Slack, email, or meetings: what shipped, what changed, what moved a metric, what brought revenue, what got stuck, what you learned. Even a few short notes at the end of the day are useful. Brief gives you direction. Debrief gives the system memory. Together, they create a much better operating rhythm.

And the last part, which is similar to debief is a weekly report. Now, here is the trick, you don’t need to see what you did, but instead - what excatly changed because of your actions. This is, in fact, a powerplay - you will see the impact, not list of the tasks, and it will launch this loop and help with focusing on things that matter.

Cheers! 💚

The same approach works for people too. If you’re evaluating a founder,candidate or competitor, the job is similar: collect the right signals and turn them into something readable ~ actionable.

The interesting part starts after the collection. Raw research is only the base layer. The real value appears when you put a lens on top of it. In one case, that lens is competitive intelligence: where they are strong or weak, what share of the market they might control, what they do better than you, what can be borrowed, and where they are exposed. Suddenly the output is no longer “here is a dossier.” It becomes “here is what matters, here is what to watch, and here is what to do next.”

That is why I like building these systems as living maps. A company should be seen in context: against other companies, people, markets, and places. Once you do that, research stops being a background task and becomes an operating tool. Good intelligence is not about admiring the data. It is about making better moves from it.

Anyways, the problem is rarely a lack of care -> It is rather volume and confidence. When you handle enough files, reports, commits and screenshots, sooner or later you stop checking every detail as carefully as you think you do.

That is why I like the idea of a Gatekeeper: a final layer that scans outgoing information, flags sensitive content and asks for a second look before anything becomes public. It will never replace human judgement, and it should not. Its job is simpler: catch the things you missed. The more information you produce, the more useful that last checkpoint becomes.