Cash Management

Learning outcomes

Every business that touches money has to answer one brutally simple question many times a day: do I have enough cash, in the right account, at the right moment, to pay what I owe? Cash management is the discipline of always being able to say yes. It is the difference between a fintech that runs for a decade and one that misses a settlement window, breaches a regulatory reserve, or quietly lends out customer money it was supposed to be holding. The ledger tells you what you owe and what you hold. Cash management is what makes sure the actual dollars are where the ledger says they should be, on time, every time.

After studying this page, you can:

• Explain what cash management is, why a profitable company can still fail from a cash problem, and why holding the right total is never enough if it sits in the wrong account at the wrong time.
• Build and read a cash position and a cash forecast, and say what each input contributes and where the uncertainty lives.
• Describe nostro and vostro accounts, FBO accounts, and reserve and segregation requirements, and explain whose money sits where and why the law cares.
• Walk a sweep and a concentration structure, and contrast physical pooling with notional pooling, naming who bears the risk in each.
• Reason about the economics of idle cash: float, interest, sweep programs, and money market funds, and the trade-off between yield and instant availability.
• Explain intraday liquidity: why a day that nets to zero can still run dry at noon, and how an institution funds the gap.
• Name the major failure modes (overdraft, missed settlement, a liquidity crunch, a reserve breach) and the engineering and operational controls that catch each one.

Before we dive in

You do not need a treasury background. We will define each term the first time it appears and keep the vocabulary small.

Cash here means immediately spendable money sitting in a bank account that you control, not an accounting abstraction and not a receivable you are still waiting on. Liquidity is the broader idea of being able to meet obligations as they fall due: cash is the most liquid form, but a line of credit you can draw in minutes is liquidity too. A cash position is a snapshot of how much spendable cash you hold right now, account by account. A forecast is the projection of that position forward in time. Treasury is the function inside a company that owns all of this: positioning cash, funding obligations, investing the surplus, and managing the risk that the money is not where it needs to be.

A few more terms you will meet below. A settlement obligation is a payment you are contractually committed to make at a specific time, for example funding your side of an ACH batch or wiring cash to a card network. A nostro account is an account your institution holds at another bank (think of it as “our money over there”); a vostro account is the mirror, an account another bank holds with you (“your money over here”). An FBO account (“for benefit of”) is a single bank account a fintech holds that pools many customers’ money, with the bank and the fintech tracking who owns which slice. A sweep is an automated transfer that moves cash between accounts on a rule, for example concentrating balances overnight or moving idle cash into something that earns interest.

Hold one picture above all the detail: cash management is logistics, not accounting. Accounting tells you the truth about what is owed and owned. Cash management is the warehouse-and-trucks problem of getting the actual dollars to the actual loading dock before the truck leaves.

Mental Model

The wrong model, and it is seductive because it is how a personal bank account feels, is that cash is a single number. You have a balance, the balance goes up and down, and as long as it is positive you are fine. Under this model “managing cash” means “keep the balance above zero,” and a company with plenty of money in the bank has nothing to worry about.

That model fails for two reasons that matter enormously in practice. First, cash is not one number; it is many numbers in many accounts, at many banks, in many currencies, each with its own access rules and cut-off times. You can be flush in aggregate and unable to pay, because the dollars you need are in the wrong account behind a wire cut-off that already passed. Second, the balance you see is not the balance you can spend. Some of it is owed to customers and is not yours to touch. Some of it is committed to a settlement that has not cleared. Some of it is a credit your bank may claw back. The number on the screen is a starting point, not an answer.

Here is the model to hold instead. Think of cash like water in a system of tanks connected by pipes, where the pipes only open at certain hours and some of the water in the tanks is already promised to someone else. Managing cash is not about the total volume of water. It is about making sure that at every moment a valve has to open, the right tank has enough free water, that is, water not already owed to a customer or pledged to a settlement, to fill the pipe before it closes. A company drowns not when it runs out of water overall, but when the right tank runs dry at the wrong minute while full tanks sit elsewhere behind closed valves. Every technique below, positioning, forecasting, sweeps, pooling, intraday funding, is a way of getting free water into the right tank before the valve opens.

Breaking it down

The teaching runs in ten steps. The first five build the treasury intuition: what cash management is, how you see your position, where the money physically lives, how you move it, and what idle cash is worth. The next five are the fintech reality: the bank-partner and FBO structures that let a non-bank hold money, the unforgiving clock of intraday settlement, how you engineer all of this, how it fails, and how it grows from a seed-stage startup to a regulated institution.

1. Why cash management exists at all

Start with the oldest fact in finance: a business can be profitable and still die. Profit is an accounting result measured over a period; cash is a balance you either have or do not have at a single instant. A company can book a fat profit on a sale and still fail to make payroll on Friday, because the customer pays in sixty days and the employees need paying now. The technical name for this gap is the difference between accrual (revenue and expense recognized when earned or incurred) and cash (money actually in the account). Cash management lives entirely in the second world. Its job is timing, not profitability.

For a fintech the stakes are sharper than for an ordinary business, because much of the cash you hold is not yours. When a customer loads one hundred dollars into your app, you now hold one hundred dollars of cash and simultaneously owe the customer one hundred dollars. That obligation is unconditional and immediate: the customer can ask for it back at any moment, and you must be able to produce it. So a fintech’s cash management carries a duty an ordinary company does not have, the obligation to always be able to cover every customer balance in full, on demand, from segregated funds that were never yours to spend. Get that wrong and it is not a cash-flow inconvenience; it is a failure to safeguard customer money, which is the single fastest way to lose your banking partner, your license, and your company.

Layer on top of that the operational reality that money moves on rails with fixed schedules. ACH runs in batches with submission cut-offs. Wires close for the day. Card networks demand you fund settlement at a set time or you are in default to the network. Real-time rails like instant payments never sleep, which removes the breathing room of an overnight batch and means your funding has to be ready around the clock. Cash management exists because money is not a number you can will into the right place; it is a physical thing that moves on someone else’s timetable, and missing the timetable has consequences that range from an overdraft fee to a regulatory event.

flowchart LR
  P["Profit<br/>(earned over a period)"] -.->|not the same as| C["Cash<br/>(held at an instant)"]
  C --> O["Obligations due<br/>on a fixed clock"]
  O --> S["Settlement<br/>and customer redemptions"]
  C --> D["Duty to cover<br/>every customer balance"]
  D --> S

The takeaway for the rest of the page: cash management is a timing-and-location problem layered on top of a trust obligation. You are not just trying to be solvent on paper. You are trying to have free, spendable dollars in a specific account before a specific clock runs out, while never once dipping into money that belongs to a customer.

2. The cash position and the art of forecasting it

You cannot manage what you cannot see, so the first artifact of any treasury function is the cash position: a current snapshot of how much spendable cash sits in each account, across every bank and currency. The position is harder to produce than it sounds, because bank balances lie in two important ways. The ledger balance is what the bank’s books say at the start of the day. The available balance is what you can actually use right now, after holds, pending debits, and uncleared credits. Treasury cares about available balance, because that is the free water in the tank. A position built on ledger balance will tell you that you can fund a wire that the bank will in fact bounce.

A position is a starting point. The real work is the forecast: projecting the position forward so you can see a shortfall before it arrives, not after. A forecast is built by laying known and expected cash movements onto a timeline: today’s opening available balance, plus expected inflows (customer deposits, incoming settlements, interest), minus expected outflows (customer withdrawals, your settlement obligations, payroll, vendor payments). The near horizon, today and tomorrow, is mostly known with high confidence, because the obligations are already committed and the inflows are largely visible. The far horizon, weeks and months out, is genuinely uncertain and leans on statistical patterns: how much do customers typically withdraw on the first of the month, how does deposit volume move with marketing spend, what is the seasonal shape of the business.

The discipline that makes a forecast honest is variance analysis: every day, compare what you forecast against what actually happened, and study the gap. A forecast that is never checked drifts into fiction. A forecast that is reconciled daily becomes a calibrated instrument, and the size of its typical error tells you exactly how big a safety buffer you need to hold. This is the first place cash management touches engineering: the position and forecast are data products, fed by bank reporting feeds and your own ledger, and their quality is a function of how fresh and complete that data is.

3. Nostro and vostro accounts and the geography of money

Cash does not live in the cloud. Every dollar you control physically sits in an account at some bank, and the moment you operate across multiple banks or currencies you have to track the geography of your money explicitly. The vocabulary for this is centuries old and comes from correspondent banking, the system by which banks hold accounts with each other so they can move money in places they have no branch.

A nostro account is an account your institution holds at another bank, denominated in that bank’s local currency. From your point of view it is “our money over there.” If a US fintech needs to make euro payments, it holds a euro nostro account at a bank in the eurozone; that euro balance is its nostro. A vostro account is the exact same account seen from the other side: the bank holding your money calls it a vostro, “your money over here.” Nostro and vostro are not two kinds of account; they are two viewpoints on one account, the way debit and credit are two ends of one movement. The reason the distinction matters operationally is reconciliation: your books say what your nostro should hold, the correspondent bank’s books say what your vostro holds, and those two records must be reconciled continuously, because that is where breaks, fees, and stuck payments show up first.

sequenceDiagram
  participant You as Your bank (US)
  participant Corr as Correspondent (EU)
  Note over You,Corr: One account, two names
  You->>Corr: Hold our EUR here (we call it our nostro)
  Corr->>You: We hold it for you (we call it your vostro)
  You->>Corr: Pay EUR 50,000 from our balance
  Corr-->>You: Statement: vostro debited EUR 50,000
  Note over You,Corr: Your nostro ledger and their vostro<br/>statement must reconcile to the cent

The geography becomes a constraint the instant timing enters. Money in a nostro account in another time zone is subject to that country’s banking hours and cut-offs. A euro payment you need to make at 9am London time has to be funded into the right nostro before the London cut-off, which may be the middle of the night where your treasury team sits. This is why a global firm runs a follow-the-sun treasury operation and pre-positions cash into nostros ahead of need. The deeper lesson is the same one from the Mental Model: aggregate cash is meaningless across geography. Ten million dollars in New York does not help you settle a euro obligation in Frankfurt if it cannot cross the ocean and convert before the Frankfurt valve closes.

4. Sweeps concentration and pooling

Once your cash is scattered across accounts, you need machinery to move it where it is needed and to stop it from sitting idle. The basic tool is the sweep: a standing instruction that automatically moves cash between accounts when a rule is met. A zero-balance account, for example, is configured so that every day its balance is swept to zero, up into a parent account if it is positive, or funded from the parent if it is negative. The point is that the operating accounts are kept lean and a single account holds the consolidated balance.

Cash concentration is sweeping applied across many accounts to pull dispersed balances into one concentration account. A retailer with two hundred store deposit accounts concentrates them nightly into one account so treasury manages a single balance instead of two hundred. Concentration is physical: the money actually moves, an irrevocable transfer leaves the subsidiary account and lands in the concentration account, and afterward the subsidiary account genuinely holds less. Because the money moves, physical concentration creates real intercompany positions: if account A’s cash funds account B’s shortfall, A has effectively lent to B, and that loan has to be tracked and, in many jurisdictions, priced and documented.

Notional pooling is the clever alternative. Instead of physically moving cash, the bank leaves every account’s balance where it is but calculates interest as if the balances were combined. An account that is two hundred thousand positive and another that is fifty thousand negative are pooled notionally: the bank charges or pays interest on the net one hundred fifty thousand, even though no money moved between them. The appeal is that each entity keeps control of its own cash and no intercompany loans are created, which avoids a tangle of legal and tax issues. The catch is that notional pooling requires the bank to extend the credit, since it is honoring a negative balance against a positive one elsewhere, so it depends on the bank’s willingness and on a regulatory regime that permits it. Notional pooling across currencies and across legal entities is restricted or unavailable in some jurisdictions, including a number of US contexts, precisely because regulators are wary of the implicit cross-guarantees.

The animation shows a nightly concentration sweep over its full structure: many operating accounts, a concentration account, and an investment sleeve, with the main path and the funding subpath both visible from the first frame.

5. The economics of idle cash

Cash that sits in a plain operating account usually earns little or nothing, and worse, it loses value to inflation while it waits. The economics of cash management are about squeezing return out of money without giving up the ability to spend it the instant it is needed, and the whole game is the tension between yield and availability. Money that earns the most is usually the least available; money you can spend this second usually earns the least. Treasury’s job is to slice the cash by how soon you will need it and put each slice in the highest-yielding place consistent with that need.

The oldest source of free money in this game is float: the gap in time between when a payment is initiated and when it actually settles. If a customer’s payment to you clears into your account before your payment out clears, you hold both sums briefly, and that overlap is float you can earn on. Historically, slow paper-based clearing created large, exploitable float, and entire business models were built on it. Faster electronic rails have compressed float dramatically, and real-time payments aim to eliminate it, which is a deliberate policy choice: float is, in effect, an interest-free loan extracted from the slowness of the system, and modernizing the rails takes it away.

The modern tools for idle cash are sweep programs and money market funds. A sweep program automatically moves balances above a chosen buffer out of the operating account each night into an interest-bearing vehicle, and back in the morning when operations need them. A money market fund is a mutual fund that invests in very short-term, high-quality instruments (Treasury bills, commercial paper, repurchase agreements) and aims to be redeemable on the same or next day, so it pays more than a checking account while staying close to cash. The trade-off is exactly the yield-versus-availability tension: a government money market fund is extremely safe and liquid but yields the least; a prime fund yields a little more but holds corporate paper that can become hard to sell in a crisis, and that liquidity risk is real, as the runs on prime funds in 2008 and again in March 2020 showed.

There is a discipline in not over-optimizing. The point of cash is to be available, and a treasurer who chases an extra few basis points by pushing the buffer too low or reaching for a less liquid fund is trading a tiny, certain gain for a small chance of a catastrophic shortfall. The right posture is to hold a deliberate buffer sized to forecast error and obligation timing, invest only the genuine surplus above it, and keep that surplus in instruments whose liquidity you trust under stress, not just on a calm day.

6. Bank-partner accounts FBO structures and segregation

This is where fintech departs sharply from a traditional company, and where the most important obligations live. Most fintechs are not banks. They cannot hold customer deposits directly, because holding deposits is a regulated banking activity. So a fintech partners with a chartered bank and holds customer money in an account at that bank, structured so the law recognizes the money as belonging to the customers, not to the fintech.

The standard structure is the FBO account, “for benefit of.” The fintech opens one (or a few) accounts at the partner bank, titled something like “Fintech Inc. FBO its customers.” Into that single pooled account flows the money of thousands or millions of customers. The fintech maintains its own ledger that tracks, customer by customer, who owns which slice of the pooled balance. The bank sees one big balance; the fintech’s ledger sees the breakdown. The legal effect, when the structure is done correctly, is that the pooled funds are the customers’ property held in trust or agency, not an asset of the fintech, so if the fintech fails, the money is not available to the fintech’s creditors and is returned to the customers.

Two obligations sit on top of this structure and they are absolute. The first is segregation: customer money must be kept separate from the fintech’s own operating money, in distinct accounts, never commingled. The fintech’s payroll and its venture funding live in operating accounts; customer balances live in FBO accounts; the two never touch. The second is reserve sufficiency: at all times, the total cash in the FBO accounts must be at least equal to the sum of all customer balances on the ledger. The fintech may never let the pooled cash fall below what it owes customers in aggregate, because the moment it does, some customer’s money has been spent on something else, which is precisely the failure that ends companies and triggers enforcement. For US money transmitters this is reinforced by permissible investment rules: state money transmission laws require the firm to hold eligible assets at least equal to its outstanding customer obligations, and many fintechs sit under exactly that regime.

flowchart TB
  subgraph fintech["Fintech's own money (operating)"]
    OP["Operating account<br/>payroll, vendors, revenue"]
  end
  subgraph customers["Customer money (segregated)"]
    FBO["FBO pooled account at partner bank<br/>titled 'for benefit of customers'"]
    LED["Fintech ledger:<br/>per-customer balances"]
  end
  CUST["Customers"] -->|deposit| FBO
  LED -.->|must always sum to <= FBO cash| FBO
  OP -.->|NEVER commingled| FBO
  FBO -->|sum of balances always covered| CUST

The invariant to burn into memory is this: the sum of the per-customer balances on the ledger must always be less than or equal to the actual cash in the segregated FBO accounts. That single inequality is the engineering and legal heart of running a fintech that holds money. A reconciliation that proves it holds, every day, against the bank’s own statement, is not a nice-to-have; it is the control that keeps you out of an enforcement action and keeps customer money safe. When it breaks, even by accident, even briefly, you have a reportable problem.

7. Intraday liquidity and meeting settlement on time

Here is a fact that surprises engineers new to treasury: a day whose cash flows net to exactly zero can still leave you unable to pay at noon. Intraday liquidity is the management of cash within a single day, hour by hour, and it matters because obligations and receipts do not arrive at the same instant. If a large settlement obligation is due at 11am but the offsetting receipt does not land until 3pm, you are short between 11 and 3 even though the day ends flat. The forecast that matters for funding is not the closing balance; it is the intraday low point, the deepest trough the balance hits during the day.

Institutions cover that trough in a few ways. They hold a buffer of free cash sized to the expected intraday gap. They arrange an intraday credit line from their bank, the ability to go temporarily negative during the day as long as it is squared by the close, which the bank may price or require collateral for. And in systems with central bank accounts, they use intraday credit from the central bank, often collateralized, to bridge the gap inside the operating day. The discipline of measuring this became a formal supervisory expectation after the 2008 crisis, when regulators saw that firms which looked liquid on an end-of-day basis could still seize up intraday; the Basel Committee published monitoring tools for intraday liquidity in 2013 in direct response.

The clock is the enemy and it is unforgiving. Each rail has a funding deadline, and missing it is not a soft event. Miss the card network’s settlement funding window and you are in default to the network, which can suspend your ability to process. Miss a wire cut-off and the payment simply does not go today, with whatever contractual consequences that triggers downstream. The shift toward real-time payment rails removes the overnight grace period entirely: when settlement is instant and around the clock, your funding has to be pre-positioned and continuously available, because there is no batch window in which to scramble.

stateDiagram-v2
  [*] --> Opening: day opens with a buffer
  Opening --> Drawdown: large obligation due at 11am
  Drawdown --> Trough: balance hits intraday low, receipts not yet in
  Trough --> Bridge: cover the gap with buffer or credit line
  Bridge --> Recovery: receipts land in the afternoon
  Recovery --> Squared: line repaid, day closes flat
  Squared --> [*]
  Trough --> Failed: gap not covered, funding deadline missed
  Failed --> [*]
  note right of Trough
    A day that nets to zero can still
    run dry at the intraday low.
    Fund the trough, not the close.
  end note

8. Engineering cash positioning and liquidity monitoring

Now connect all of this to systems, because at any real scale cash management is a software problem. The core data product is a near-real-time view of the cash position assembled from two sources that must agree: the bank side (balances and transactions pulled from each bank, historically via batch statement files such as the BAI2 and MT940 formats, increasingly via APIs that report intraday) and the internal side (your own ledger, which knows what you believe you hold and owe). The treasury system continuously reconciles these two, because the gap between what the bank says and what your ledger says is where every cash problem first becomes visible.

On top of the position sits the liquidity monitor: a service that computes the forecast, projects the intraday low against committed obligations, and raises an alert before a buffer is breached rather than after. The most important property of this system is timeliness. A position that is a day stale is useless for intraday decisions; the monitor has to be fed fresh balance data and the live ledger so it can flag a looming shortfall while there is still time to act, by accelerating a sweep, drawing a line, or delaying a discretionary payment.

The single most important invariant the system enforces is the coverage check from section six: segregated cash must always cover customer obligations. This is a continuous reconciliation, not a monthly report.

-- Coverage check: segregated cash must always cover what customers are owed.
-- Run continuously; alert the instant it is violated.

WITH customer_liabilities AS (
  SELECT currency,
         SUM(balance_minor_units) AS owed_to_customers   -- from the internal ledger
  FROM   customer_balances
  GROUP  BY currency
),
segregated_cash AS (
  SELECT currency,
         SUM(available_minor_units) AS cash_held          -- from bank reporting feeds
  FROM   fbo_account_balances
  GROUP  BY currency
)
SELECT c.currency,
       s.cash_held,
       c.owed_to_customers,
       s.cash_held - c.owed_to_customers AS coverage_gap   -- MUST be >= 0
FROM   customer_liabilities c
JOIN   segregated_cash      s USING (currency)
WHERE  s.cash_held < c.owed_to_customers;                  -- any row here is an incident

Two engineering points make or break this. First, money is stored as integer minor units, never as a floating-point number, for the same reason a ledger does: a binary float cannot represent most decimal cents exactly, so the coverage check would drift off by rounding noise and either cry wolf or, worse, miss a real shortfall. Second, the position and the coverage check are only as trustworthy as the freshness and completeness of the bank feeds: a missing or delayed statement file silently makes the position wrong, so the system has to treat a stale or absent feed as an alertable condition in its own right, not as “no news.” Cash management engineering is, at bottom, the discipline of keeping two independent records, the bank’s and yours, continuously and provably in agreement, and shouting the instant they are not.

9. Failure modes and the controls that catch them

A treasury operation fails in a small number of recognizable ways, and the mark of a senior practitioner is knowing exactly which control stops each one and that no single control stops them all.

The pattern across the list is that cash failures are rarely about being poor; they are about being in the wrong place, at the wrong time, or believing a wrong number. Overdrafts and missed settlements are timing-and-location failures. Reserve breaches and reconciliation breaks are wrong-number failures. A liquidity crunch is the one genuine not-enough-money failure, and even there the damage is usually determined by whether the invested surplus was truly liquid when the run hit. The controls split the same way: positioning, forecasting, and intraday monitoring defend against timing and location; continuous reconciliation defends against wrong numbers; buffers and stress tests defend against the genuine shortfall.

10. Scaling from a startup to an institution

Cash management looks completely different at three points on the growth curve, and a good engineer or operator can tell which stage a company is in by how it handles cash.

At the seed stage, the fintech has one bank-partner relationship and one FBO account, customer volumes are small, and the position can almost be eyeballed. The forecast is a spreadsheet, the reconciliation is a daily manual check, and a single buffer covers all the uncertainty. This is appropriate; do not build a treasury management system for ten thousand dollars of float. The one thing that must be solid even here is segregation and the coverage invariant, because the legal obligation to cover customer balances is binding from the very first deposit, not from some later scale.

At the growth stage, volume and the number of accounts climb, and the manual approach breaks. Now the firm needs multiple bank partners for redundancy (so a single bank’s outage or offboarding does not freeze the business), real bank feeds rather than hand-keyed balances, an automated forecast with variance tracking, sweep programs to stop idle cash from piling up, and a liquidity monitor that watches the intraday low. The coverage reconciliation moves from a daily manual check to a continuous automated control. Multi-currency arrives, bringing nostro accounts and the geography problem, and with it the need to pre-position cash ahead of cut-offs in other time zones.

At the institution stage, the firm runs a true treasury function: a centralized view across many banks, currencies, and entities; physical concentration and where permitted notional pooling to optimize the consolidated position; formal intraday liquidity monitoring against supervisory expectations; stress testing against runs and market dislocations; and access to central bank facilities or committed credit lines to bridge intraday gaps. The same invariants from the seed stage still hold, segregation, coverage, fund the trough not the close, but they are now enforced by systems and teams rather than by one person watching a spreadsheet.

flowchart TB
  subgraph seed["Seed: one bank, one FBO"]
    A["Spreadsheet forecast,<br/>manual daily reconciliation,<br/>single buffer"]
  end
  subgraph growth["Growth: many accounts"]
    B["Multiple bank partners,<br/>bank feeds, automated forecast,<br/>sweeps, continuous coverage check"]
  end
  subgraph inst["Institution: many banks, currencies, entities"]
    C["Centralized treasury, pooling,<br/>intraday liquidity monitoring,<br/>stress testing, central bank / credit lines"]
  end
  seed --> growth --> inst
  A -.->|same invariants throughout:<br/>segregate, cover, fund the trough| C

The thread that runs through every stage is that cash management is where the abstractions of the ledger meet the physical reality of money moving on someone else’s clock. The ledger says what you owe and hold. The settlement rails say when money can move and by when it must. Cash management is the function that stands between them and guarantees that, at every moment a valve has to open, the right account has free, spendable, fully-segregated cash to fill the pipe before it closes. Get that right and the rest of the money-movement stack has solid ground to stand on. Get it wrong and nothing above it can be trusted.

Mastery Questions

1. A founder shows you the company’s bank statements: thirty million dollars across all accounts, comfortably more than the twenty-two million of customer balances on the ledger. They conclude the company is in great shape on cash. What three distinct questions would you ask before agreeing, and why does each one matter?

   Answer. Aggregate cash exceeding aggregate obligations is necessary but nowhere near sufficient, so I would probe the three dimensions that aggregate hides. First, segregation and composition: how much of the thirty million is in segregated FBO accounts versus the company’s own operating accounts? If only twenty million sits in segregated accounts, then customer balances of twenty-two million are not fully covered by segregated cash, which is a reserve breach regardless of how much operating cash exists, because operating cash is not the customers’ to draw on. Second, availability and timing: is the relevant cash available (not ledger) balance, and where is the intraday low? A company can be flush at open and close yet go negative at noon when a settlement deadline lands before its offsetting receipt, so I want the intraday trough against each funding deadline, not the snapshot total. Third, location and access: across how many banks and currencies is the thirty million spread, and can each slice reach the account where an obligation is due before that account’s cut-off? Ten million in New York does nothing for a euro settlement in Frankfurt that closes before it can convert and cross. Healthy total cash that fails any one of these, under-segregated, mistimed, or stranded, is not health; it is a failure waiting for the wrong minute.

2. Your firm operates in three currencies. A treasurer proposes notional pooling across all entities and currencies to maximize interest and avoid intercompany loans, citing how cleanly it works in your European operation. What is your response, and what governs whether it is even available?

   Answer. The instinct is right that notional pooling avoids the intercompany loans and the legal and tax tangle that physical concentration creates, since no cash actually moves and the bank simply offsets balances when computing interest. But three constraints govern whether it is available, and they are why it works in Europe but may not elsewhere. First, the bank must be willing to extend the implicit credit, because honoring a negative balance against a positive one in another account means the bank is lending against the offset; that appetite is not guaranteed and is priced. Second, the legal and regulatory regime must permit it: cross-currency and cross-entity notional pooling is restricted or unavailable in a number of jurisdictions, including several US contexts, precisely because regulators are wary of the implicit cross-guarantees between entities that pooling creates. Third, the entities must be able to grant those cross-guarantees, which raises real questions about whether one entity’s regulators or creditors permit its balance to backstop another’s overdraft. So my response is: pursue it where it is permitted and the bank supports it, likely keeping the clean European structure, but do not assume it ports to the US or across currencies. Where it is barred, fall back to physical concentration within each permitted boundary and accept the intercompany accounting that comes with it. The right answer is usually a hybrid, not one structure everywhere.

3. An engineer building your liquidity monitor proposes computing the coverage check (segregated cash versus customer obligations) once a day from the internal ledger alone, storing money as a double for convenience, and treating a missing bank feed as no change since the last update. Identify every flaw and give the correct design.

   Answer. All three choices are wrong in ways that defeat the control’s entire purpose. Daily from the ledger alone fails because the coverage invariant is about whether the actual bank cash covers obligations, and the internal ledger is your belief about cash, not the cash itself; checking the ledger against itself can never reveal that real cash has fallen short, which is exactly the failure the control exists to catch. The check must reconcile the ledger against the bank’s own statement, and it must run continuously, not daily, because a reserve breach is a reportable event you need to detect in minutes, not at tomorrow’s batch. Storing money as a double fails because a binary float cannot represent most decimal cents exactly, so summing millions of balances accumulates rounding error and the coverage gap drifts off by noise, which either fires false alarms or, far worse, masks a genuine shortfall just under the threshold; money must be integer minor units so the arithmetic is exact. Treating a missing feed as no change fails because the most dangerous state is not a known shortfall but an unknown position: if a bank’s statement is late, the system is computing coverage on stale numbers and will confidently report everything is fine while the real balance may already be short. A stale or absent feed must be an alertable condition in its own right. The correct design is a continuous reconciliation of integer-minor-unit balances from the live ledger against fresh bank reporting feeds, with the coverage gap required to be non-negative per currency, and with feed staleness itself treated as an incident, so the monitor is never silently blind.