10. Corporate Treasury and Cash Management Services
The previous chapters looked at treasury from inside the bank. This chapter looks at the bank's customers: the treasury departments of large companies, who manage working capital, cash and payments across dozens of entities, currencies and banks, and the cash management and trade finance products banks sell them to do so. For a bank, these services bring fee income and stable operational deposits, which are valued highly in funding and liquidity metrics. For engineers, they bring some of the largest flows a bank processes: millions of payments, statements, sweeps, virtual account postings and trade documents that must be routed, reconciled and reported correctly every day.
<a id="101-corporate-treasury-operations"></a>
10.1 Corporate Treasury Operations
This subchapter explains what a corporate treasurer is trying to achieve (enough cash in the right place at the lowest cost) and the operating models used to get there: working capital management, cash visibility, payment factories, in-house banks and intercompany netting.
Working Capital Management
Why it matters. A company can be profitable on paper and still run out of cash. It pays suppliers and staff before customers pay it, and it holds stock in warehouses that has already been paid for but not yet sold. The money tied up in this gap must be financed, either from the company's own cash or from borrowing. Working capital management tries to shrink the gap, so that the business needs less financing for the same level of sales. It is the first question a corporate treasurer asks, and most bank cash management and trade finance products exist to help answer it.
What it is. Net working capital is the operating part of the balance sheet that turns over in the normal course of business:
Net working capital = Accounts receivable + Inventory - Accounts payable
(owed by customers) (stock) (owed to suppliers)
Treasurers measure it in days, because days are comparable across companies of different size and translate directly into cash:
| Metric | Formula | Meaning |
|---|---|---|
| DSO (days sales outstanding) | Receivables / Revenue x 365 | How long customers take to pay |
| DIO (days inventory outstanding) | Inventory / Cost of goods sold x 365 | How long goods sit in stock |
| DPO (days payables outstanding) | Payables / Cost of goods sold x 365 | How long the company takes to pay suppliers |
| CCC (cash conversion cycle) | DSO + DIO - DPO | Days between paying for inputs and collecting cash from sales |
The cash conversion cycle.
Day 0 Day 40 Day 50 Day 100
| | | |
Goods received Supplier paid Goods sold Customer pays
|<---- DPO 40 -->| | |
|<-------- DIO 50 ------------------->|<------ DSO 50 ------->|
|<----------- CCC = 50 + 50 - 40 = 60 days ->|
cash out cash in
Example: what a day is worth. A distributor has annual revenue of EUR 365 million (EUR 1 million per day) and cost of goods sold of EUR 292 million (EUR 0.8 million per day).
Receivables EUR 50m -> DSO = 50 / 365 x 365 = 50 days
Inventory EUR 40m -> DIO = 40 / 292 x 365 = 50 days
Payables EUR 32m -> DPO = 32 / 292 x 365 = 40 days
CCC = 50 + 50 - 40 = 60 days Net working capital = 50 + 40 - 32 = EUR 58m
Reduce DSO by 10 days -> releases 10 x EUR 1.0m = EUR 10m of cash
Extend DPO by 10 days -> releases 10 x EUR 0.8m = EUR 8m of cash
At a 5% borrowing rate, EUR 18m less debt saves EUR 0.9m interest per year
Levers and the bank products behind them.
| Lever | Corporate action | Typical bank product |
|---|---|---|
| Collect faster (lower DSO) | Electronic invoicing, direct debits, automatic matching of incoming payments, dunning | Virtual accounts, direct debit collection, lockbox, receivables finance (factoring) |
| Hold less stock (lower DIO) | Better demand planning, just-in-time supply | Inventory finance |
| Pay later (higher DPO) | Negotiate longer payment terms | Supply chain finance (Chapter 10.3), commercial cards |
| Finance the remaining gap | Short-term borrowing | Overdrafts, revolving credit facilities, commercial paper programmes |
Early payment discounts. A supplier offering "2/10 net 30" gives 2% off if the invoice is paid within 10 days instead of 30. Skipping the discount means paying 2% to keep the money 20 extra days, an annualized cost of:
Cost = d / (1 - d) x 365 / (N - D) = 0.02 / 0.98 x 365 / 20 = 37.2% per year
Unless the company's cash is worth more than 37% a year, taking the discount is the better choice. These trade-offs are why treasury, procurement and sales argue about payment terms.
Tension between levers. Every day gained by one company is lost by its counterparty. Extending DPO from 40 to 90 days helps the buyer and hurts small suppliers, who may fail or raise prices. This is why aggressive payment terms are often combined with supply chain finance, which lets suppliers get paid early at the buyer's credit cost.
Engineering view. Working capital metrics are computed from ERP data: receivables and payables ledgers, ageing reports (invoices grouped by days past due) and inventory valuations. Treasury systems pull these for cash forecasting (Chapter 5.2). Common data issues are average versus period-end balances (period-end figures are often "window-dressed" by delaying payments around the reporting date), intercompany invoices that must be excluded, and multiple currencies.
Analogy. Working capital is like the water sitting in a long pipe between a reservoir and a tap. The longer the pipe (the cash conversion cycle), the more water is stuck in it at any time, and the more you must pump in before anything comes out.
Key takeaways
- Net working capital = receivables + inventory - payables; it is cash tied up in operations that must be financed.
- The cash conversion cycle (DSO + DIO - DPO) measures that gap in days; each day multiplied by daily sales or costs gives cash released.
- Banks sell a product for each lever: collections and receivables finance, inventory finance, supply chain finance and short-term credit.
- Gains for one company are losses for its counterparty; payment terms are a negotiation, not a free lunch.
🧪 Practice
- Beginner: A company has revenue of EUR 730 million, receivables of EUR 120 million, cost of goods sold of EUR 500 million, inventory of EUR 70 million and payables of EUR 90 million. Compute DSO, DIO, DPO and the cash conversion cycle.
- Intermediate: A supplier offers "1/10 net 45". The company can borrow at 6% per year. Should it take the discount? Show the implied annual cost of not taking it.
- Interview: "Our treasury wants a dashboard that shows how much cash would be released by improving working capital in each subsidiary. What data do you need and what pitfalls do you foresee?" Hint: per-entity receivables, payables and inventory from the ERP, revenue and COGS on the same period basis, currency conversion, removal of intercompany balances, averaging versus period-end, and translating days into cash using daily sales and costs.
Cash Visibility
Why it matters. A treasurer cannot manage what they cannot see. A multinational may hold several hundred bank accounts at twenty or more banks in forty countries. If treasury does not know each morning how much cash sits where, it borrows in one place while idle cash sits in another, misses payments, and cannot answer basic questions from the board or rating agencies. Cash visibility is the ability to see, at a defined time each day, the balances and transactions of all accounts in the group, in one place.
What it involves. Visibility is built by collecting bank statements from every bank and loading them into a treasury management system (TMS) or a data platform:
Bank A (DE) --EBICS-------> camt.053 / camt.052 --+
Bank B (US) --SWIFT FileAct--> BAI2 / MT940 --+
Bank C (UK) --Host-to-host SFTP--> camt.053 --+--> Normalize --> TMS cash position
Bank D (SG) --API (REST)--> JSON balances --+ dedupe, by entity, currency,
Bank E (BR) --manual portal download--> CSV --+ convert FX bank, account
Types of statement.
| Report | Timing | Content | Formats |
|---|---|---|---|
| Prior-day (end-of-day) statement | Early morning, for the previous day | Opening and closing booked balance, all booked transactions | MT940, camt.053, BAI2 |
| Intraday report | Several times per day or on request | Interim balances and transactions booked so far | MT942, camt.052, BAI2 intraday |
| Debit/credit notification | Per transaction, near real time | Single booking on an account | camt.054, webhooks |
| API balance query | On demand | Current booked and available balance | Bank-specific JSON, open banking APIs |
ISO 20022 statements carry typed balances, for example OPBD (opening booked), CLBD (closing booked), CLAV (closing available) and ITBD (interim booked). The difference between booked and available balance matters: a cheque credited today may be booked but not yet available for use. Message formats are covered in Chapter 12.2.
Connectivity channels. Corporates reach their banks through SWIFT (as a corporate member, often through a service bureau), EBICS (a file transfer standard widely used in Germany, France, Austria and Switzerland), host-to-host links over SFTP (Chapter 12.4), bank APIs and, as a last resort, downloads from the bank's web portal. A company with many banks often uses several channels at once.
Example: a morning cash position.
Group cash position, 19 Oct 2026, 08:00 CET, reporting currency EUR
Entity Bank Account Ccy Closing booked FX rate EUR equiv. Status
---------------------------------------------------------------------------------
DE GmbH Bank A DE..0011 EUR 12,400,000 1.0000 12,400,000 received 06:10
DE GmbH Bank A DE..0029 EUR -1,800,000 1.0000 -1,800,000 received 06:10
US Inc Bank B ..4471 USD 8,250,000 0.9150 7,548,750 received 07:45
UK Ltd Bank C GB..9920 GBP 2,100,000 1.1600 2,436,000 received 05:30
SG Pte Bank D ..7713 SGD 3,000,000 0.7000 2,100,000 received 02:15
BR Ltda Bank E ..0505 BRL 15,000,000 0.1650 2,475,000 MISSING (last: 17 Oct)
---------------------------------------------------------------------------------
Visible today 22,684,750
Visibility ratio = visible balances / total known balances = 22.68 / 25.16 = 90%
The Brazilian statement did not arrive, so the position uses a stale balance or excludes it. Treasury must decide which, and the report must say so clearly.
Common problems.
- Time zones: "end of day" in Singapore is early morning in Europe and the previous evening in New York, so a group position mixes balances taken at different moments.
- Missing or late statements: connections fail, banks change formats, holidays differ by country.
- Format variety: the same MT940 field is filled differently by different banks; camt.053 has many optional elements.
- Duplicates and gaps: a statement may be resent, or one day may be skipped.
- Restricted countries: some markets (with capital controls) allow balance reporting but not moving the cash, so visible cash is not always usable cash.
Engineering view. A robust statement-loading pipeline checks continuity (today's opening balance must equal yesterday's closing balance, and statement sequence numbers must have no gaps), balance arithmetic (opening balance plus the sum of transactions equals closing balance), and duplicates (by statement ID, account and date). It records the time each statement was received, flags stale accounts and keeps the raw file for audit. Intraday reports should be replaced, not added, when the final end-of-day statement arrives, otherwise transactions are counted twice.
Analogy. Cash visibility is like air traffic control. Each bank is a radar station reporting the aircraft it sees; the controller needs one screen combining all stations, with a clear mark on any area where a radar has gone silent.
Key takeaways
- Cash visibility means seeing all group balances and transactions in one place at a defined time each day; it is the basis of every other treasury decision.
- Data arrives as prior-day statements (MT940, camt.053, BAI2), intraday reports (MT942, camt.052) and notifications or API calls, over SWIFT, EBICS, host-to-host and APIs.
- Visibility ratio, statement timeliness and continuity checks are the key quality measures.
- Visible cash is not always usable cash: time zones, value dates and capital controls matter.
🧪 Practice
- Beginner: What is the difference between a camt.053 and a camt.052 message, and when would a treasurer use each?
- Intermediate: Yesterday's closing balance on an account was EUR 4,000,000. Today's statement shows an opening balance of EUR 3,950,000, credits of EUR 1,200,000, debits of EUR 900,000 and a closing balance of EUR 4,250,000. Which checks fail, and what could explain each failure?
- Interview: "Design the ingestion service that loads bank statements from 30 banks into our TMS." Hint: channel adapters per bank, a canonical statement model, parsers per format and per bank variant, continuity and balance arithmetic checks, idempotent loading keyed on statement identity, handling of intraday versus final statements, monitoring of late statements per bank cut-off, and retention of raw files.
Payment Factories
Why it matters. In a decentralized group, every subsidiary runs its own payments: its own bank accounts, its own e-banking tokens, its own formats and its own approval rules. The result is hundreds of bank connections, inconsistent controls, duplicated fees and payments that headquarters only discovers on the statement. Fraud often enters through the weakest subsidiary. A payment factory centralizes the processing of outgoing payments for the whole group into one hub with one set of controls and connections.
What it is. A payment factory receives payment files from the ERP systems of all group entities, validates, enriches and approves them centrally, and sends them to the banks in standard formats. Two models exist:
| Model | How payments are made | Accounts needed | Bank sees as debtor |
|---|---|---|---|
| In the name of (routing model) | The factory sends payments from each subsidiary's own bank account | Each subsidiary keeps local accounts | The subsidiary |
| On behalf of (POBO) | The factory pays from its own (or the in-house bank's) account on behalf of the subsidiary | Subsidiaries can close most accounts | The central entity, with the subsidiary as ultimate debtor |
The mirror image for receipts is collections on behalf of (COBO): customers pay into a central account, and the receipts are allocated to the subsidiary that issued the invoice.
Flow.
ERP DE ---+ Payment factory
ERP FR ---+--> pain.001 / CSV --> 1. Validate format, mandatory fields, IBAN/BIC
ERP US ---+ 2. Enrich (bank routing, charges, purpose codes)
ERP SG ---+ 3. Sanctions and fraud screening, duplicate check
4. Approval workflow (four-eyes, limits)
5. Netting / POBO conversion where applicable
6. Route to bank and channel, respect cut-offs
|
+-------------------+-------------------+
v v v
Bank A (EUR) Bank B (USD) Bank D (SGD)
| | |
+---- pain.002 status reports ----------+--> back to factory and ERPs
Example: POBO payment in ISO 20022. The French subsidiary owes a supplier EUR 25,000. Under POBO, the payment factory pays it from the group's central account in Germany:
pain.001 (simplified)
Debtor: Group Treasury GmbH <- account holder
DebtorAccount: DE89 3704 0044 0532 0130 00
UltimateDebtor: Group France SAS <- on whose behalf
Creditor: Fournisseur SARL
CreditorAccount: FR76 3000 6000 0112 3456 7890 189
Amount: EUR 25,000.00
RemittanceInfo: INV-2026-4471
Booking: Group Treasury pays external supplier;
Group France's internal account at the in-house bank is debited EUR 25,000.
The UltimateDebtor field lets the supplier and its bank see who the payment is really from, which helps reconciliation and satisfies payment transparency rules.
Benefits and constraints.
| Benefits | Constraints |
|---|---|
| Fewer bank connections and accounts, lower fees | Some countries restrict or forbid POBO (for example markets with capital controls or local currency rules) |
| One set of controls: segregation of duties, sanctions screening, fraud rules | Tax and legal questions: who is the payer for VAT, withholding tax and invoices |
| Standard formats (pain.001) instead of many local ones | Suppliers and authorities may reject payments not coming from the invoiced entity |
| Better cash visibility and forecasting, since all payments pass through one point | Central cut-off management across time zones is complex |
| Enables netting and in-house banking | Single point of failure: the factory needs high availability |
Engineering view. A payment factory is a high-volume, high-risk workflow system. Key design points are: a canonical payment model mapped to and from many input and output formats; idempotency and duplicate detection (the same invoice must not be paid twice if an ERP resends a file, Chapter 12.4); routing rules by currency, amount, urgency and country; bank cut-off calendars; immutable audit trails of approvals; and end-to-end status tracking by matching pain.002 status reports and bank statements back to the original instruction.
Analogy. A payment factory is like a central post office for a company: instead of each department buying its own stamps and driving to different post offices, all letters go to one mailroom that checks addresses, applies postage and hands them to the right carrier.
Key takeaways
- A payment factory centralizes outgoing payment processing for all group entities, with one set of formats, controls and bank connections.
- "In the name of" keeps subsidiary accounts; "on behalf of" (POBO) pays from a central account and lets subsidiaries close local accounts.
- COBO is the receipts equivalent; POBO and COBO usually rely on an in-house bank to record who owes whom.
- Legal, tax and local regulatory constraints limit POBO in some countries.
🧪 Practice
- Beginner: What is the difference between the Debtor and the Ultimate Debtor in a POBO payment?
- Intermediate: A group wants to move 12 countries to POBO. List three questions you would ask about each country before including it.
- Interview: "An ERP resends yesterday's payment file after a network timeout. How does the payment factory make sure no payment is executed twice?" Hint: file-level and payment-level identifiers (message ID, end-to-end ID), hash of key fields as a fallback, a persistent store of processed IDs, behaviour for partial overlaps, and an operator queue for suspected duplicates rather than silent dropping.
In-House Banks
Why it matters. Once payments and receipts are centralized, someone must keep track of who owes whom. If headquarters pays a French supplier on behalf of the French subsidiary, France now owes headquarters money. Multiply this by thousands of payments a day and dozens of subsidiaries, add lending of surplus cash from one entity to another and FX trades, and the group needs a bank inside itself. An in-house bank (IHB) is a group treasury entity that acts as the bank for its own subsidiaries.
What it is. The in-house bank holds an internal account for each subsidiary, posts every intercompany flow to these accounts, pays and charges internal interest, and is the only entity dealing with external banks for most purposes:
External banks
(few accounts, owned by the IHB)
^
| external payments, FX hedges, deposits, borrowing
|
+----------+-----------+
| In-house bank |
| (Group Treasury) |
| |
| Internal accounts: |
| DE +5.2m EUR |
| FR -1.4m EUR |
| US +3.0m USD |
| UK -0.8m GBP |
+---+------+------+----+
| | |
internal statements, interest, FX
v v v
Sub DE Sub FR Sub US ...
Services an IHB typically offers.
| Service | What happens |
|---|---|
| Internal current accounts | Each subsidiary has an account at the IHB; balances are intercompany loans or deposits |
| POBO / COBO | External payments and receipts are routed through IHB accounts and posted to subsidiaries' internal accounts |
| Internal interest | Credit and debit interest on internal balances at a reference rate plus or minus a margin |
| Intercompany loans and deposits | Term funding of subsidiaries, priced at arm's length |
| FX | Subsidiaries trade FX with the IHB; the IHB nets the group's exposures and hedges only the net externally |
| Internal statements | Daily statements, often in the same formats as bank statements (camt.053, MT940), so subsidiaries' ERPs can reconcile them automatically |
Example: FX netting through the IHB. In one week, Sub US needs to sell USD 10 million (export receipts) and Sub DE needs to buy USD 7 million (to pay US suppliers):
Without IHB: Sub US sells USD 10m to Bank A; Sub DE buys USD 7m from Bank B
Two trades, total USD 17m, each pays the bank's spread (say 5 pips)
Spread cost ~ 17m x 0.0005 = USD 8,500
With IHB: Sub US sells USD 10m to IHB, Sub DE buys USD 7m from IHB
IHB sells only the net USD 3m externally
Spread cost ~ 3m x 0.0005 = USD 1,500
Example: internal interest. Sub FR has an average internal overdraft of EUR 1.4 million for October (31 days). The IHB charges €STR + 1.00%, with €STR at 2.00%, on an ACT/360 basis:
Interest = 1,400,000 x 3.00% x 31 / 360 = EUR 3,616.67 charged to Sub FR
Legal and tax considerations. An IHB is usually not a licensed bank, because it only deals with group companies, but some jurisdictions treat certain intragroup activities as regulated, so local legal advice is needed. Internal interest rates must be at arm's length under transfer pricing rules (OECD guidelines), otherwise tax authorities may reallocate profit between countries. Thin capitalization rules limit how much a subsidiary can be funded by intercompany debt, and withholding taxes may apply to cross-border internal interest.
Engineering view. An IHB is a small core banking system: it needs an account ledger with value dating, interest calculation (Chapter 11.1 day counts), statement generation in bank formats, limit management for internal credit lines and an audit trail. The internal account postings must always mirror the external flows: every external payment made on behalf of a subsidiary must create exactly one internal debit, and the sum of all internal balances must reconcile to the IHB's external bank balances plus its intercompany loans and investments.
Analogy. An in-house bank is like a family where one parent manages the money: the children keep "accounts" with the parent rather than with the bank, the parent deals with the outside world, and at the end of the month everyone knows exactly how much they have borrowed from the family pot.
Key takeaways
- An in-house bank is a group treasury entity acting as bank to its subsidiaries, with internal accounts, internal interest and statements.
- It enables POBO/COBO, internal lending, FX netting and fewer external bank accounts.
- Internal pricing must follow arm's-length transfer pricing rules; tax and local legal rules constrain the design.
- Internal ledgers must reconcile exactly to external flows; the IHB is effectively a small core banking system.
🧪 Practice
- Beginner: Why does an in-house bank make it easier for a group to reduce its number of external bank accounts?
- Intermediate: In one month, four subsidiaries trade with the IHB: Sub A buys EUR 4m, Sub B sells EUR 9m, Sub C buys EUR 2m, Sub D sells EUR 1m (all against USD). What external EUR/USD trade should the IHB do to stay flat, and how much gross volume is avoided?
- Interview: "Design the data model for an in-house bank's internal account ledger." Hint: accounts per entity and currency, postings with booking and value dates, links to the external transaction that caused each posting, interest conditions with effective dates, statement generation, and a reconciliation view between internal and external positions.
Intercompany Netting
Why it matters. Group companies buy from and sell to each other all the time: a manufacturing subsidiary ships components to an assembly plant, which sells to distribution companies in other countries. If every intercompany invoice is paid separately, the group pays bank fees, FX spreads and float on money that simply circulates inside the group. Intercompany netting replaces many gross payments with one net payment or receipt per entity per cycle.
What it is. In multilateral netting, all participating entities submit their intercompany payables and receivables to a netting centre (usually group treasury or the IHB). The netting centre computes each participant's net position and settles only those nets. Bilateral netting only offsets flows between two entities and achieves less.
Example: three entities, amounts in EUR millions.
Payables matrix (row pays column)
to DE to US to UK | Total payable
DE - 10 4 | 14
US 6 - 3 | 9
UK 5 2 - | 7
-----------------------------------------------
Total recv. 11 12 7 | 30
Net position = receivable - payable
DE: 11 - 14 = -3 -> pays 3 to netting centre
US: 12 - 9 = +3 -> receives 3 from netting centre
UK: 7 - 7 = 0 -> no payment
Gross: 6 payments, EUR 30m moved Net: 2 payments, EUR 3m moved
The sum of all net positions is always zero, which is a useful consistency check. In real systems each participant settles in its own currency, so the netting centre also converts the nets at an agreed rate and hedges the residual FX positions.
The netting cycle. Netting runs on a fixed calendar, usually monthly:
Day -10 Participants submit intercompany invoices (payables and receivables)
Day -7 Matching: payer and receiver amounts compared; mismatches flagged
Day -5 Dispute resolution deadline
Day -3 FX rates fixed; net positions calculated in each participant's currency
Day -2 Netting statements sent to participants
Day 0 Settlement date: payers pay the centre, centre pays receivers
(or postings to internal accounts at the IHB)
Benefits and constraints.
| Benefits | Constraints |
|---|---|
| Far fewer payments and FX trades, lower fees and spreads | Some countries with exchange controls restrict or require approval for netting |
| Predictable settlement dates simplify forecasting | Invoice mismatches must be resolved before the cutoff |
| Intercompany balances cleared regularly, cleaner accounts | Accounting and tax still need the gross invoices; netting only changes settlement |
| Central FX management of group exposures | Participants need discipline to submit on time |
Engineering view. A netting engine is a matrix calculation surrounded by workflow: invoice upload from ERPs, two-sided matching (the payer's payable against the receiver's receivable, with tolerances), dispute handling, a rate snapshot taken at a defined time, rounding rules so that nets still sum to zero in each currency, and generation of settlement instructions or IHB postings. Mismatches are the operational pain point: they arise from different invoice dates, currencies, partial payments and unrecorded credit notes.
Analogy. Netting is like friends splitting the bill after a trip. Instead of everyone paying back everyone else for each dinner and taxi, they add it all up and only the people who are net out of pocket get paid, by those who are net ahead.
Key takeaways
- Multilateral netting replaces many gross intercompany payments with one net settlement per participant per cycle.
- Net positions always sum to zero; the netting centre settles nets and manages the resulting FX.
- The netting cycle has fixed steps: submission, matching, dispute resolution, rate fixing and settlement.
- Exchange controls, invoice mismatches and participant discipline are the main constraints.
🧪 Practice
- Beginner: What is the difference between bilateral and multilateral netting?
- Intermediate: Four entities have these intercompany payables (EUR millions): A pays B 8, A pays C 2, B pays C 5, B pays D 3, C pays A 6, D pays A 4, D pays B 1. Compute each entity's net position and the reduction in number of payments and amount moved.
- Interview: "Our netting run shows that the sum of net positions in EUR is not zero after FX conversion. What could cause this and how would you fix it?" Hint: rounding of converted amounts per participant, inconsistent rate snapshots or cross rates, invoices included on one side only, and the need for a defined rounding difference allocation rule.
<a id="102-bank-cash-management-products"></a>
10.2 Bank Cash Management Products
This subchapter turns to the bank's side: the products banks sell to concentrate, offset and report corporate cash, and why banks value them. Cash management relationships bring fee income and operational deposits, which under the LCR receive a 25% outflow rate instead of the 40% for other non-financial corporate deposits (Chapter 9.2), so they are cheaper liquidity for the bank and are rewarded in funds transfer pricing (Chapter 6.4).
Physical Cash Pooling (Zero Balancing)
Why it matters. A group with many accounts at the same bank will typically have some accounts in credit and some overdrawn. The bank pays little interest on credit balances and charges much more on overdrafts, so the group pays the spread on money it effectively already has. Moving the cash physically into one account each day removes the problem, and gives treasury one balance to invest or fund.
What it is. In physical cash pooling, the bank automatically transfers balances between subsidiary accounts (participant or sub-accounts) and a header account (also called master or concentration account), usually at the end of each business day:
- Zero balancing (ZBA): every participant account is brought to exactly zero. Credit balances are swept up to the header; overdrafts are covered from the header.
- Target balancing: each participant is brought to a defined target balance (for example EUR 50,000 left for local payments).
- Threshold balancing: a sweep happens only when the balance passes a threshold, to avoid many small transfers.
Example: end-of-day zero balancing.
Before sweep (17:30) Sweep After sweep
Sub DE +4,000,000 --- 4,000,000 ---> Sub DE 0
Sub FR -1,500,000 <-- 1,500,000 ---- Sub FR 0
Sub NL + 700,000 --- 700,000 ---> Sub NL 0
Header 100,000 Header 3,300,000
Intercompany positions created (header owner = Group Treasury):
Sub DE lent 4,000,000 to Group Treasury
Sub FR borrowed 1,500,000 from Group Treasury
Sub NL lent 700,000 to Group Treasury
Interest effect. Assume the bank pays 1.0% on credit balances and charges 6.0% on overdrafts, on an ACT/360 basis, for one day:
Without pooling: (4.0m + 0.7m + 0.1m) x 1.0% / 360 - 1.5m x 6.0% / 360
= 133.33 - 250.00 = EUR -116.67 per day
With pooling: 3.3m x 1.0% / 360 = EUR +91.67 per day
Benefit: EUR 208.33 per day, about EUR 76,000 per year
Intercompany loans and interest allocation. Every sweep is a real transfer of money between legal entities, so it creates an intercompany loan. The pool leader must record these loans, pay interest to lending subsidiaries and charge interest to borrowing ones, at arm's-length rates. This is usually done by the in-house bank or the TMS, sometimes by the bank as an additional reporting service.
Variants and timing.
| Feature | Description |
|---|---|
| Single-currency pool | The normal case; each currency has its own pool |
| Cross-border pool | Participants in several countries sweep to one header; subject to local rules on cross-border lending |
| Multi-level pool | Country headers sweep to a regional header, which sweeps to a global header |
| Reverse sweep | Next morning, balances are moved back to restore the subsidiaries' positions (used where intraday funding of subsidiaries is needed) |
| Intraday sweeps | Sweeps run several times per day, not only at end of day |
Legal constraints. Because each sweep moves money out of a legal entity, directors must be sure the entity can get it back. Some jurisdictions have capital maintenance rules that restrict a subsidiary from lending to its parent if this endangers its capital, and insolvency of the pool leader puts subsidiaries' swept cash at risk. Cross-border sweeps may need central bank reporting and can trigger withholding tax on interest.
Engineering view. The bank's sweep engine must run after the last payment cut-off of the day and process accounts in hierarchy order (lowest level first), using the value-dated closing balance. Each sweep produces two bookings and is reported on the statements of both accounts, often with a specific transaction code so the corporate can reconcile it automatically. On the corporate side, the TMS reads these bookings from statements and updates the intercompany loan ledger.
Analogy. Zero balancing is like a household where every family member empties their wallet into a shared jar each evening, and anyone who spent more than they had is topped up from the jar, so no one pays overdraft fees while others hold idle cash.
Key takeaways
- Physical pooling moves cash between participant accounts and a header account daily (zero, target or threshold balancing).
- It removes the interest spread between credit and debit balances and gives one consolidated balance to invest or fund.
- Every sweep creates an intercompany loan that must be recorded and charged interest at arm's length.
- Capital maintenance, insolvency and cross-border tax rules constrain physical pools.
🧪 Practice
- Beginner: What is the difference between zero balancing and target balancing?
- Intermediate: Three accounts end the day at +EUR 2.0m, -EUR 3.0m and +EUR 0.5m, with a header at EUR 0. The bank pays 0.5% on credit and charges 7.0% on debit balances (ACT/360). Compute the daily interest with and without zero balancing.
- Interview: "Design the end-of-day sweep engine for a bank offering multi-level cash pools." Hint: a tree structure of pools, bottom-up processing, using value-dated closing balances after the last cut-off, target and threshold rules, atomic booking of both legs, idempotent reruns if the batch fails halfway, holiday calendars for cross-border pools, and specific transaction codes on statements.
Notional Pooling
Why it matters. Physical pooling creates intercompany loans, legal complications and many bank transfers. Some groups would prefer to keep each subsidiary's cash in its own account and simply get the interest benefit as if it were pooled. Notional pooling does exactly that: the bank calculates interest on the combined balance of all accounts without moving any money.
What it is. In a notional pool, the bank adds up the credit and debit balances of all participating accounts every day (notionally, in its interest calculation only) and pays or charges interest on the net. Each account keeps its own balance and its own legal owner. Because the bank is effectively lending to the overdrawn entities on the strength of the others' deposits, it requires:
- cross-guarantees between participants (each entity guarantees the others' overdrafts), and
- rights of set-off, letting the bank use credit balances to cover debit balances if a participant defaults.
Example.
Accounts at end of day Physical balance Notional pool view
Sub A (EUR) +10,000,000
Sub B (EUR) - 6,000,000
Sub C (EUR) + 2,000,000
-----------
Net pool balance + 6,000,000
Interest without pool (credit 1%, debit 5%, ACT/360, 365 days):
credit: 12m x 1% x 365/360 = 121,667
debit: 6m x 5% x 365/360 = 304,167 -> net cost EUR 182,500
Interest with notional pool:
6m x 1% x 365/360 = EUR 60,833 earned
Annual benefit = EUR 243,333
The bank then allocates the pool interest back to participants according to an agreed method (for example in proportion to their contribution).
Comparison with physical pooling.
| Aspect | Physical pooling | Notional pooling |
|---|---|---|
| Cash movement | Yes, daily sweeps | None |
| Intercompany loans | Created by every sweep | None (balances stay in each entity) |
| Entity autonomy | Subsidiaries lose their balance each night | Subsidiaries keep their own balances |
| Legal requirements | Intercompany loan agreements | Cross-guarantees and set-off agreements |
| Multi-currency | Separate pool per currency | Possible: balances converted notionally into a base currency |
| Bank balance sheet | Net (one balance per pool) | Gross unless strict offsetting criteria are met |
| Availability | Widely offered | Restricted or unavailable in some jurisdictions (for example the United States), offered by fewer banks |
| Cost to the bank | Low | Higher capital and liquidity cost |
Why banks are cautious. Under accounting and prudential rules, the bank can only show the net pool balance on its balance sheet if it has a legally enforceable right of set-off and actually settles net. The IFRS Interpretations Committee (2016) confirmed that without regular physical settlement, offsetting under IAS 32 is generally not allowed, so the bank reports the deposits and overdrafts gross. Gross reporting inflates the balance sheet, which increases the leverage ratio exposure; in the EU, CRR Article 429b only permits netting of cash pooling arrangements under strict conditions. Overdrafts also consume credit limits and capital. As a result, many banks either withdrew notional pooling, limited it to their best clients, or require periodic physical sweeps to settle the pool.
Engineering view. A notional pooling engine is an interest calculation layer on top of normal accounts: it needs daily value-dated balances for all participants, FX rates for multi-currency pools, the pool's interest conditions and an allocation algorithm. Reporting must show both the individual account view (for the subsidiaries) and the pool view (for group treasury). The bank's regulatory reporting must treat the balances according to whether they qualify for netting, which requires a reliable flag on each pool.
Analogy. Notional pooling is like a family mobile phone plan with shared data: each phone keeps its own usage record, but the operator only bills the family for its total consumption, so one person's unused data covers another's overage.
Key takeaways
- Notional pooling gives the interest benefit of pooling without moving money; balances stay in each entity's account.
- It requires cross-guarantees and set-off rights, and the bank allocates the pool interest back to participants.
- Without physical settlement, banks must usually report the balances gross, which raises leverage and capital costs.
- As a result, notional pooling is less widely available and more expensive than physical pooling.
🧪 Practice
- Beginner: In a notional pool, what happens to the individual account balances at the end of the day?
- Intermediate: A multi-currency notional pool holds +EUR 5m, -USD 4m (EUR/USD 1.10, so USD 1.10 per EUR) and -GBP 1m (EUR/GBP 0.85). Compute the net pool balance in EUR. If the bank pays 1.5% on positive pool balances and charges 4.0% on negative ones, what is one day's interest (ACT/360)?
- Interview: "Why would a bank's balance sheet look larger because it offers notional pooling, and why does that matter?" Hint: gross versus net presentation under IAS 32 offsetting criteria, leverage ratio exposure, capital consumption of the overdrafts, and the role of periodic physical sweeps.
Virtual Accounts
Why it matters. Large corporates receive thousands of incoming payments a day, and matching each one to the right invoice and customer is slow when all customers pay into the same account and type the remittance reference in their own way. Groups also want each subsidiary, business unit or customer to have its own account without opening hundreds of physical accounts, each with KYC, fees and statements. Virtual accounts solve both problems.
What it is. A virtual account is an account number (often a virtual IBAN, vIBAN) that does not hold money itself. Every payment to it is booked on a real physical account at the bank, but tagged with the virtual account number, so the owner can see which virtual account was paid. A bank's virtual account management (VAM) platform lets the corporate create, close and organize virtual accounts in hierarchies, often through an API.
Customer 1042 pays ---> vIBAN DE12 5001 0517 9000 0010 42 --+
Customer 1043 pays ---> vIBAN DE65 5001 0517 9000 0010 43 --+--> Physical account
Customer 2001 pays ---> vIBAN DE33 5001 0517 9000 0020 01 --+ DE89 5001 0517 0000 1234 56
(holds all the money)
Statement line (camt.053/054):
Amount EUR 12,500.00 Credit
Account identifier: vIBAN ...001042 -> customer 1042 identified, invoice matched
Two main uses.
| Use | How it works | Benefit |
|---|---|---|
| Receivables reconciliation | Each customer (or invoice, or contract) gets its own vIBAN | Near 100% automatic matching, even if the customer omits the reference |
| Account structure rationalization | Each subsidiary or business unit gets virtual accounts on a central physical account, combined with POBO/COBO | Fewer physical accounts, simpler KYC and fewer statements, while keeping a per-entity ledger |
Example: receivables matching rates. A utility with 200,000 business customers paying by bank transfer:
Before (one collection account, match on reference text):
Auto-matched 82% -> 36,000 payments per month to match manually
After (one vIBAN per customer):
Auto-matched 98% -> 4,000 payments per month to match manually
Unmatched cases now mostly: wrong amount, overpayment, combined payments
Regulatory issues. Virtual accounts create transparency questions for anti-money laundering. The payer's bank sees a vIBAN, but the money ends up in a physical account that may belong to a different legal entity than the one the payer believes it is paying. Banks must know the owner of each virtual account and the purpose of the structure, apply KYC to entities using virtual accounts, and make sure the beneficiary name in payments matches. EU AML rules adopted in 2024 extend national bank account registers to include virtual IBANs. A further issue is IBAN discrimination: some vIBANs carry a country code different from the payer's country, and some payers have wrongly rejected them, which is prohibited for SEPA payments.
Engineering view. A VAM platform is a ledger of virtual accounts mapped to physical accounts, with a hierarchy, owner, status and validity dates. Incoming payment processing must look up the vIBAN at booking time, reject or return payments to closed virtual accounts according to the agreed rules, and carry the vIBAN through to statements (camt.053/054) so the client can reconcile. vIBAN numbers must have valid IBAN check digits and come from a reserved range of the bank's account numbering, so they cannot collide with real accounts.
Analogy. Virtual accounts are like apartment numbers in a building with one street address: the mail all goes to the same building (the physical account), but the apartment number tells the concierge exactly whose letter it is.
Key takeaways
- A virtual account is an account identifier (often a vIBAN) without its own balance; payments are booked on a linked physical account and tagged.
- Uses: automatic receivables matching (one vIBAN per customer) and fewer physical accounts in a centralized treasury structure.
- Banks must apply KYC to virtual account owners and ensure payment transparency; EU rules bring vIBANs into account registers.
- Systems need a vIBAN ledger, lookup at booking time, rules for closed accounts and vIBAN detail on statements.
🧪 Practice
- Beginner: Does money "sit" in a virtual account? Explain where the balance is held.
- Intermediate: A customer pays EUR 10,000 to a vIBAN that was closed last month. List the options the bank and the corporate could choose from, and the trade-offs.
- Interview: "Design an API that lets corporate clients create virtual IBANs in real time." Hint: number generation from a reserved range with valid check digits, uniqueness guarantees under concurrency, owner and hierarchy attributes, KYC checks on the owning entity, idempotent create requests, status changes, and propagation to payment booking and statement systems.
Sweeps
Why it matters. Cash pooling is one example of a broader idea: rules that move money automatically between accounts, so that treasury does not have to send manual transfers every day. Banks offer sweeps to concentrate cash, to fund accounts before payments go out, to invest idle balances overnight and to repay credit lines automatically.
What it is. A sweep is a standing instruction for the bank to transfer funds between two accounts when a condition is met. Its parameters are the source and target account, the trigger (time of day, balance threshold), the amount rule and the direction.
| Sweep type | Rule | Typical use |
|---|---|---|
| Zero balance | Move the full balance to/from the header | Physical cash pooling |
| Target balance | Keep a fixed balance on the source, move the rest | Leave cash for local payments |
| Threshold | Sweep only above (or below) a threshold, in round amounts | Avoid many small transfers |
| Investment sweep | Move excess over a target into an overnight deposit or money market fund, and back next morning | Earn interest on idle cash |
| Credit (loan) sweep | Use excess cash to repay a credit line, draw on the line to cover deficits | Minimize interest on borrowings |
| Funding sweep | Fund a disbursement account just before payments are released | Keep payment accounts at zero except when needed |
Example: a rule configuration.
sweep_id: SW-0042
source: DE..0011 (Sub DE operating account, EUR)
target: DE..9000 (Group header account, EUR)
schedule: business days, 17:45 CET, after last EUR payment cut-off
rule: target_balance = 50,000
min_transfer = 10,000
direction = two-way
Evaluation at 17:45:
balance = 1,234,567 -> transfer 1,184,567 to header (source left at 50,000)
balance = 55,000 -> excess 5,000 < min_transfer, no sweep
balance = -200,000 -> transfer 250,000 from header (source restored to 50,000)
Investment sweeps and history. In the United States, Regulation Q prohibited banks from paying interest on business demand deposits until it was repealed in 2011 (Dodd-Frank Act). Banks responded with sweep accounts that moved balances overnight into interest-bearing products such as money market funds or repos, and moved them back the next morning. Investment sweeps remain common for excess cash, but swept funds are no longer bank deposits, so they have different risk and deposit protection, and the bank loses those deposits from its own funding.
Engineering view. Sweeps look trivial but have many edge cases: which balance is used (booked, value-dated, available), the order in which dependent sweeps run, what happens if a payment is booked after the sweep (late returns, back-valued corrections), holidays where the source and target currencies or countries have different calendars, and how to rerun safely if the batch fails halfway. Sweeps must be idempotent per account and business date and must leave a clear audit trail of the rule version applied.
Analogy. A sweep is like a smart thermostat for money: you set the target level once, and the system adds or removes cash automatically when the balance drifts away from it.
Key takeaways
- A sweep is a standing rule that moves money between accounts based on time and balance conditions.
- Types include zero, target and threshold balancing, investment sweeps, credit sweeps and funding sweeps.
- Investment sweeps move cash out of deposits, which affects the bank's own funding and the client's deposit protection.
- Engineering challenges are balance definition, ordering, late bookings, holiday calendars and idempotent reruns.
🧪 Practice
- Beginner: What is the difference between an investment sweep and a credit sweep?
- Intermediate: Using the configuration above, what transfers happen for end-of-day balances of EUR 59,999, EUR 60,000, EUR 40,001 and EUR -5,000? State any assumptions about how
min_transferapplies to funding transfers.- Interview: "A sweep batch crashed after processing 60% of accounts. How do you restart it without double-sweeping?" Hint: a unique key per sweep rule and business date, persisted status per sweep, atomic booking of both legs, re-reading balances only for unprocessed sweeps, and reconciliation of booked sweeps against the rule run log.
Liquidity Reporting Services
Why it matters. Pools, sweeps and virtual accounts only help if the corporate can see what the bank did. Treasurers need to know their balances, the sweeps performed, the intercompany positions created and the interest allocated, in a form their systems can load automatically. Banks therefore sell reporting as a product in its own right, and the quality of reporting is often what decides whether a corporate keeps a bank as its main cash management bank.
What it involves.
| Report | Content | Typical formats and channels |
|---|---|---|
| Balance and transaction reporting | Prior-day and intraday balances, transactions | camt.053, camt.052, camt.054, MT940/942, BAI2; SWIFT, EBICS, host-to-host, API |
| Cash pool reports | Pool structure, sweeps per account, header balance | Bank-specific reports, camt.053 with sweep transaction codes |
| Intercompany position reports | Cumulative position of each participant towards the pool leader | Bank portal, CSV/XML files |
| Interest allocation statements | Interest credited and charged per participant, rates and day counts | Bank portal, PDF and data files |
| Payment status reports | Acceptance, rejection and execution of submitted payments | pain.002, camt.054, API callbacks |
| Fee reporting | Charges per account and service | camt.086 (Bank Services Billing), bank-specific files |
| Forecast and dashboard tools | Projected balances, cash positions across banks | Bank portals and APIs |
Example: a sweep visible in a camt.053 entry (simplified).
<Ntry>
<Amt Ccy="EUR">1184567.00</Amt>
<CdtDbtInd>DBIT</CdtDbtInd>
<Sts><Cd>BOOK</Cd></Sts>
<BookgDt><Dt>2026-10-19</Dt></BookgDt>
<ValDt><Dt>2026-10-19</Dt></ValDt>
<BkTxCd><Domn><Cd>CAMT</Cd> <- cash management domain
<Fmly><Cd>ACCB</Cd><SubFmlyCd>ZABA</SubFmlyCd></Fmly> <- account balancing, zero balancing
</Domn></BkTxCd>
<NtryDtls>... counterparty: header account DE..9000 ...</NtryDtls>
</Ntry>
The bank transaction code tells the corporate's TMS that this is a sweep, so it can update the intercompany loan ledger instead of treating it as an ordinary payment.
Real-time reporting. Instant payments (Chapter 2.2) and APIs have raised expectations: corporates increasingly want balances and transactions within seconds, pushed by webhooks or event streams, rather than once a day in a file. This matters for intraday liquidity decisions and for fast confirmation that a customer has paid.
Engineering view. For the bank, reporting is a data distribution problem: the same bookings must feed several output formats, for many clients, through several channels, each with its own schedule and cut-off. Consistency across reports is critical: the intraday camt.052 and the final camt.053 must agree, statement sequence numbers must be continuous, and corrections must be reported as reversals rather than silent changes. Format variations by client (and the bank-specific use of optional fields) are a constant source of integration work.
Analogy. Liquidity reporting is the dashboard of a car. The engine (pools, sweeps, payments) does the work, but without a reliable dashboard the driver cannot tell how fast they are going or how much fuel is left.
Key takeaways
- Banks provide balance, transaction, pool, intercompany, interest, status and fee reports as part of cash management.
- Standard formats are camt.052/053/054, MT940/942 and BAI2, with pain.002 for payment status and camt.086 for fees.
- Bank transaction codes let corporate systems recognise sweeps and other special bookings automatically.
- Consistency, continuity and timeliness across channels are the core engineering requirements; real-time APIs raise the bar.
🧪 Practice
- Beginner: Which ISO 20022 message would a corporate use to confirm that a payment it submitted was rejected by the bank?
- Intermediate: A corporate's TMS books a sweep twice: once from the camt.052 intraday report and again from the camt.053 end-of-day statement. Explain why this happens and how the loader should prevent it.
- Interview: "Design a statement generation service that produces camt.053, MT940 and BAI2 for 50,000 corporate accounts every morning." Hint: a canonical booking model, format-specific renderers, client-specific profiles, scheduling per time zone and channel, sequence numbering, balance arithmetic checks before release, reprocessing of corrections, and monitoring of delivery confirmations.
<a id="103-trade-finance-basics"></a>
10.3 Trade Finance Basics
This subchapter covers the instruments banks use to make trade between companies that do not trust each other possible, and to finance the time goods spend in transit and on credit terms: letters of credit, bank guarantees, supply chain finance and documentary collections.
The underlying problem is the same in all of them. An exporter does not want to ship goods before being paid; an importer does not want to pay before receiving goods. The four standard payment methods in international trade sit on a spectrum of risk:
Safest for exporter Safest for importer
<------------------------------------------------------------------------------------>
Cash in advance Letter of credit Documentary collection Open account
(importer pays (bank promises (bank exchanges (exporter ships,
before shipment) to pay against documents for payment importer pays
documents) or acceptance, no later on invoice)
bank promise)
Most world trade today runs on open account terms, often supported by supply chain finance; letters of credit and collections remain important for new relationships, high-risk countries and large one-off contracts.
Letters of Credit
Why it matters. A Korean electronics exporter is asked to ship USD 500,000 of goods to a Spanish importer it has never dealt with. If it ships first, it may never be paid. If it asks for payment in advance, the importer may refuse, worried that the goods never arrive. A letter of credit (LC, also documentary credit) replaces the importer's promise to pay with a bank's promise: the exporter knows that if it ships and presents the right documents, a bank will pay.
What it is. An LC is an irrevocable undertaking by a bank (the issuing bank), on behalf of its client (the applicant, the importer), to pay the beneficiary (the exporter) a stated amount, provided the beneficiary presents documents that comply with the LC's terms by a stated expiry date. Most LCs are issued under the ICC's Uniform Customs and Practice for Documentary Credits (UCP 600).
| Party | Role |
|---|---|
| Applicant | Importer who asks its bank to issue the LC |
| Issuing bank | Bank that issues the LC and is obliged to pay |
| Advising bank | Bank in the exporter's country that authenticates and forwards the LC |
| Confirming bank | Bank (often the advising bank) that adds its own payment undertaking, removing the exporter's risk on the issuing bank and its country |
| Beneficiary | Exporter who ships goods and presents documents |
| Nominated bank | Bank authorized to pay, accept or negotiate under the LC |
Flow.
Importer (Spain) Exporter (Korea)
| 1. Sales contract agreed: payment by LC |
| 2. Apply for LC |
v |
Issuing bank (Spain) --3. LC issued (SWIFT MT700)--> Advising/confirming bank (Korea)
^ | 4. LC advised
| v
| Exporter ships goods,
| obtains documents
| | 5. Presents documents
| 7. Documents forwarded, v
| reimbursement claimed <------------------ Confirming bank checks documents,
| 6. pays exporter if compliant
| 8. Issuing bank checks documents, reimburses confirming bank
v
Importer pays issuing bank (or is debited), receives documents,
uses bill of lading to collect goods from the carrier
Banks deal in documents, not goods. Under UCP 600 (Article 5) banks examine only the documents, not the goods or the underlying contract. Typical documents are the commercial invoice, the bill of lading (the carrier's receipt and document of title for goods shipped by sea), an insurance certificate, a packing list and a certificate of origin. Each bank has a maximum of five banking days following presentation to decide whether documents comply (Article 14). If documents contain discrepancies (wrong dates, amounts that do not match, missing signatures), the bank may refuse them, and the exporter loses the bank's guarantee unless the importer waives the discrepancies. A large share of first presentations contain discrepancies, which is why document preparation is a skill in its own right.
Types of LC.
| Type | Feature |
|---|---|
| Sight LC | Payment as soon as compliant documents are presented |
| Usance (deferred payment or acceptance) LC | Payment at a later date, for example 60 or 90 days after the bill of lading date; gives the importer credit |
| Confirmed LC | A second bank adds its undertaking; used when the issuing bank or its country is risky |
| Transferable LC | Beneficiary (often a trader) can transfer it to its own suppliers |
| Revolving LC | Amount reinstates after each drawing, for repeated shipments |
| Standby LC (SBLC) | Paid only if the applicant fails to pay or perform; works like a guarantee, often under ISP98 |
Example: costs and cash flows of a 60-day usance LC.
LC amount USD 500,000
Issuing commission (importer) 0.15% per quarter x 1 quarter = USD 750
Confirmation fee (exporter) 0.40% p.a. for 4 months (risk on bank) = USD 667
Discounting of the acceptance Exporter wants cash now instead of in 60 days:
rate 5.50% p.a., ACT/360 500,000 x 5.50% x 60 / 360 = USD 4,583
Exporter receives at shipment 500,000 - 667 - 4,583 = USD 494,750
Importer pays at day 60 USD 500,000 + USD 750 commission
Bank risk and capital. For the issuing bank, an LC is an off-balance sheet contingent exposure that becomes a claim on the importer once the bank pays. Short-term, self-liquidating trade LCs arising from the movement of goods get a 20% credit conversion factor under the Basel standardized approach, much lower than a loan, because the bank holds the documents of title and the transaction is short. Banks also run sanctions and trade-based money laundering checks on goods, ports, vessels and parties, because LCs can be abused to move value disguised as trade.
Digitization. LC processing has long been paper heavy. The ICC's eUCP covers electronic presentation, and laws such as the UK Electronic Trade Documents Act 2023, based on the UNCITRAL Model Law on Electronic Transferable Records (MLETR), allow electronic bills of lading to have the same legal effect as paper ones.
Engineering view. Trade finance systems manage the LC lifecycle: issuance, amendments (MT707), advice, presentations, document examination, discrepancy handling, payment and reimbursement, with SWIFT MT7xx messages between banks. They must link each LC to the applicant's credit limit, track expiry dates and tolerances (for example "about" allowing +/-10% under UCP 600 Article 30), and screen every party, vessel and port. Optical character recognition and rule engines are increasingly used to pre-check documents.
Analogy. An LC is like an escrow agent at a property sale: the buyer's money is promised in advance, and the agent releases it the moment the seller hands over the correct papers, without anyone needing to trust the other side.
Key takeaways
- An LC is a bank's irrevocable undertaking to pay the exporter against presentation of complying documents, usually under UCP 600.
- Banks deal in documents, not goods; discrepancies remove the payment undertaking unless waived.
- Confirmation removes issuing bank and country risk; usance LCs give the importer credit and can be discounted for the exporter.
- Trade LCs carry a 20% CCF, require heavy sanctions and AML screening, and are moving towards electronic documents.
🧪 Practice
- Beginner: Name the issuing bank, applicant and beneficiary in an LC where a German importer's bank promises to pay a Brazilian exporter.
- Intermediate: An LC requires shipment no later than 30 June and presentation within 21 days of shipment, with expiry on 15 July. The bill of lading is dated 28 June and documents are presented on 20 July. Do the documents comply? Explain.
- Interview: "Why would an exporter pay for confirmation of an LC that is already irrevocable?" Hint: the issuing bank's credit risk, country and transfer risk (the issuing bank's country may block foreign currency payments), the ability to be paid locally by a known bank, and how the confirmation fee reflects these risks.
Bank Guarantees
Why it matters. Many contracts depend on one party doing something in the future: a construction company finishing a bridge, a supplier delivering goods to specification, a buyer paying for a service. The counterparty wants protection if this does not happen, but suing a company in another country takes years. A bank guarantee gives the beneficiary a bank's promise to pay a fixed amount on demand if the principal fails to perform.
What it is. A demand guarantee is a bank's undertaking to pay the beneficiary up to a maximum amount upon presentation of a complying demand, usually a written statement that the principal has failed to meet its obligations. It is independent of the underlying contract: the bank does not investigate whether the failure actually happened. This "pay first, argue later" principle is what makes it valuable. International demand guarantees are commonly issued under the ICC's Uniform Rules for Demand Guarantees (URDG 758). In the United States, banks historically could not issue guarantees, so standby letters of credit fill the same role.
| Party | Role |
|---|---|
| Principal (applicant) | Party whose performance is guaranteed, and who asks its bank to issue |
| Guarantor | Bank that issues the guarantee |
| Beneficiary | Party protected by the guarantee |
| Counter-guarantor | In indirect guarantees, the principal's bank, which counter-guarantees a local bank that issues to the beneficiary |
Common types.
| Type | Protects against | Typical amount |
|---|---|---|
| Bid bond (tender guarantee) | Winning bidder withdrawing or not signing the contract | 1-5% of bid value |
| Performance guarantee | Contractor not completing the work as agreed | 5-10% of contract value |
| Advance payment guarantee | Supplier receiving an advance and not delivering | Equal to the advance, reducing as work is delivered |
| Warranty (maintenance) guarantee | Defects appearing after completion | 2-5% of contract value |
| Payment guarantee | Buyer not paying for goods or services | Up to the amount owed |
| Customs and rental guarantees | Unpaid duties, rent or other obligations to authorities and landlords | Set by the beneficiary |
Example: a construction contract.
Contract: EUR 20m road project, awarded to a Spanish contractor by a public authority in Poland
Required: performance guarantee 10% = EUR 2.0m, valid until 30 days after completion
advance payment guarantee = EUR 3.0m (advance 15%), reducing with each invoice
Structure (indirect, because the authority wants a local Polish bank):
Contractor --> Spanish bank (counter-guarantee EUR 5.0m) --> Polish bank (guarantee) --> Authority
Fees to contractor:
Spanish bank 1.0% p.a. on EUR 5.0m = EUR 50,000 per year
Polish bank 0.5% p.a. on EUR 5.0m = EUR 25,000 per year (passed through)
If the contractor abandons the project:
Authority presents demand -> Polish bank pays EUR 2.0m (+ unreduced advance guarantee)
-> claims on Spanish bank under counter-guarantee -> Spanish bank debits contractor
Lifecycle events. Guarantees are issued, amended (amount, expiry), reduced (advance payment guarantees step down as work is delivered), claimed, extended and released. A frequent event is the "extend or pay" demand: the beneficiary demands payment unless the expiry is extended, forcing the principal to decide quickly.
Bank risk and capital. A guarantee is a contingent exposure: the bank pays only if the principal fails, but then must recover from the principal. Under the Basel standardized approach, performance-related guarantees (transaction-related contingent items) receive a 50% credit conversion factor, while guarantees that substitute for credit (financial guarantees, such as a guarantee of a loan repayment) receive 100%. Guarantees consume the client's credit limits and the bank's capital, so they are priced like credit.
Engineering view. Guarantee systems must track each instrument's amount, currency, expiry type (fixed date, event-based, open-ended where local law allows), reduction schedule and claim history, and feed limits and capital calculations with the correct CCF. Expiry monitoring is critical: an expired guarantee must be released to free limits and stop fees, while a guarantee with no fixed expiry may stay on the books for years. Claims must be processed within strict time limits (URDG 758 gives the guarantor five business days to examine a demand).
Analogy. A demand guarantee is like an insurance policy that pays when the policyholder's counterparty says there was damage, without an adjuster inspecting it first. The insurer (the bank) then recovers its money from the policyholder (the principal).
Key takeaways
- A demand guarantee is a bank's promise to pay the beneficiary on a complying demand, independent of the underlying contract.
- Common types are bid bonds, performance, advance payment, warranty and payment guarantees; URDG 758 governs many international ones.
- Standby LCs fulfil the same role, especially in the United States.
- Performance guarantees carry a 50% CCF and financial guarantees 100%; systems must track reductions, expiries and claims.
🧪 Practice
- Beginner: Why does a beneficiary prefer an independent demand guarantee to a guarantee that requires proof of default?
- Intermediate: A bank has issued a EUR 4m performance guarantee and a EUR 1m guarantee of a client's bank loan. Using the Basel standardized CCFs, what credit-equivalent exposure does each produce?
- Interview: "Design the expiry and release process for a bank's guarantee portfolio." Hint: expiry types (fixed date, event, open-ended), local law rules on expiry, beneficiary release letters, automatic versus manual release, limit and fee updates, handling of claims received close to expiry, and audit trails.
Supply Chain Finance
Why it matters. Large buyers want long payment terms (high DPO); their suppliers, often smaller companies with weaker credit, want to be paid quickly and pay high interest on their own borrowing. Supply chain finance (SCF) bridges this gap by letting the supplier be paid early at a financing cost based on the buyer's stronger credit, while the buyer still pays on the original due date.
What it is. The most common form is payables finance, also called reverse factoring because it is initiated by the buyer:
1. Supplier delivers goods and issues invoice EUR 1,000,000, due in 90 days
2. Buyer approves the invoice on the SCF platform
(irrevocable undertaking to pay the full amount on the due date)
3. Supplier chooses to be paid early Bank / funder
Bank pays supplier the discounted amount <--- purchases the receivable
4. On day 90, buyer pays EUR 1,000,000 to the bank
Supplier <----- early payment (day 10) ----- Bank
| ^
| goods, invoice | full payment (day 90)
v |
Buyer ---- approval of invoice on platform ---+
Example: pricing. The buyer is rated A and can borrow at SOFR + 0.80%; the supplier is unrated and borrows at 9%. With SOFR at 4.20%, the SCF discount rate is 5.00% (ACT/360). The supplier is paid on day 10, 80 days before the due date:
Discount = 1,000,000 x 5.00% x 80 / 360 = EUR 11,111
Supplier receives = EUR 988,889 on day 10
Alternative: supplier borrows EUR 1,000,000 for 80 days at 9%
= 1,000,000 x 9.00% x 80 / 360 = EUR 20,000 interest
Supplier saves about EUR 8,900, and the receivable leaves its balance sheet
Buyer: payment terms extended from 60 to 90 days on this supplier
-> DPO up, working capital improved (Chapter 10.1)
Related techniques.
| Technique | Initiated by | Credit risk taken by funder | Funding source |
|---|---|---|---|
| Payables finance (reverse factoring) | Buyer | Buyer | Bank or investors |
| Factoring / receivables finance | Supplier | Supplier's customers (debtors), often with recourse to the supplier | Bank or factor |
| Dynamic discounting | Buyer | None (no third-party funder) | Buyer's own cash; discount grows with days paid early |
| Inventory finance | Holder of stock | Borrower, secured on inventory | Bank |
| Pre-shipment finance | Supplier | Supplier, based on confirmed purchase orders | Bank |
Risks and disclosure. SCF can hide borrowing. If a buyer extends payment terms far beyond industry norms and relies on banks paying its suppliers, its trade payables behave like debt, but appear as operating liabilities. If the funding is withdrawn, suppliers demand shorter terms and the buyer's liquidity can collapse quickly. The 2021 collapse of Greensill Capital, a large SCF provider that financed some receivables of doubtful quality and relied on insurance and securitization to fund itself, showed these risks. In response, the IASB amended IAS 7 and IFRS 7 (effective 2024) and the FASB issued ASU 2022-04, requiring companies to disclose the terms and amounts of their supplier finance programmes. Rating agencies increasingly treat part of these payables as debt.
Engineering view. SCF platforms (run by banks or fintechs) ingest approved invoices from the buyer's ERP, onboard suppliers (KYC, agreements), let suppliers select invoices for early payment, compute discounts, execute payments and collect from the buyer at maturity. Critical controls are invoice authenticity, detection of double financing (the same invoice financed by two funders), handling of credit notes and disputes after approval, buyer limit monitoring and the true sale analysis that allows the receivable to be derecognized from the supplier's balance sheet.
Analogy. Payables finance is like a well-known employer vouching for its contractors at the bank: because the bank trusts the employer to pay the invoice, it lends to the contractor at the employer's rate rather than the contractor's own.
Key takeaways
- Payables finance lets suppliers be paid early at a rate based on the buyer's credit, while the buyer pays on the due date.
- It improves both parties' working capital: the supplier gets cash early and cheaply, the buyer can extend payment terms.
- Factoring, dynamic discounting and inventory finance are related techniques with different initiators and risk takers.
- SCF can disguise debt; Greensill showed the risks, and IFRS and US GAAP now require disclosure of supplier finance arrangements.
🧪 Practice
- Beginner: In reverse factoring, whose credit rating determines the discount rate, and why?
- Intermediate: A supplier holds an approved invoice of USD 250,000 due in 120 days. The SCF rate is SOFR (4.00%) + 1.20%, ACT/360. How much does the supplier receive if it requests payment on day 30? What annual rate would make borrowing cheaper than SCF for this supplier?
- Interview: "How would you detect that an invoice on our SCF platform has already been financed elsewhere?" Hint: invoice fingerprints (supplier, buyer, number, amount, date), cross-checks with buyer approval records, shared industry registries or networks, notice of assignment, anomalies in invoice patterns, and the limits of what a single platform can see.
Documentary Collections
Why it matters. Letters of credit give strong protection but are expensive and slow. When an exporter trusts the importer enough not to need a bank's promise of payment, but does not want to hand over the goods before being paid, a documentary collection offers a cheaper middle ground. Banks act as intermediaries that release the documents controlling the goods only against payment or a commitment to pay.
What it is. In a documentary collection, the exporter ships the goods and gives the shipping documents to its bank (the remitting bank), with instructions. The remitting bank sends them to a bank in the importer's country (the collecting or presenting bank), which hands them to the importer only if the importer:
- Documents against payment (D/P): pays the amount immediately, or
- Documents against acceptance (D/A): accepts a bill of exchange (draft), a written promise to pay on a future date, for example 90 days after sight.
Collections are commonly governed by the ICC's Uniform Rules for Collections (URC 522). Crucially, the banks do not promise to pay: they only follow instructions on handling the documents.
Flow (D/P).
Exporter Remitting bank Collecting bank Importer
| 1. Ships goods, | | |
| hands over documents | | |
|------------------------->| 2. Sends documents and | |
| | collection instruction | |
| |-------------------------->| 3. Presents documents |
| | |---------------------->|
| | | 4. Importer pays |
| | |<----------------------|
| | | 5. Releases documents |
| | 6. Remits payment |---------------------->|
| 7. Credits exporter |<--------------------------| importer collects |
|<-------------------------| | goods from carrier |
Comparison with a letter of credit.
| Aspect | Letter of credit | Documentary collection |
|---|---|---|
| Bank payment undertaking | Yes (issuing and, if confirmed, confirming bank) | No |
| Main risk for exporter | Document discrepancies, issuing bank or country risk if unconfirmed | Importer refuses to pay or accept; under D/A, importer fails to pay at maturity |
| Exporter's fallback if unpaid | Bank pays if documents comply | Exporter still controls goods (D/P) but they sit in a foreign port, must be resold, stored or shipped back |
| Cost | Higher (issuance, confirmation, examination fees) | Lower (handling fees) |
| Speed and complexity | Slower, strict document examination | Simpler, banks do not examine documents for compliance |
| Credit line needed by importer | Yes, the LC uses the importer's credit limit | No |
| Rules | UCP 600 | URC 522 |
Example: D/A with financing. An Italian machinery exporter sells EUR 300,000 to a Turkish buyer on D/A terms, 90 days after sight:
Day 0 Documents presented; buyer accepts the bill of exchange for EUR 300,000 due day 90
Buyer receives documents and collects the machine
Day 1 Exporter wants cash now: its bank discounts the accepted bill
(with recourse, i.e. the exporter repays if the buyer defaults)
300,000 x 6.00% x 90 / 360 = EUR 4,500 discount -> exporter receives EUR 295,500
Day 90 Buyer pays EUR 300,000 through the collecting bank
If the buyer does not pay: the bill is protested; exporter's bank recovers from exporter
Optional: bank avalises (guarantees) the bill to remove buyer risk, for a fee
Under D/A, the exporter has given up control of the goods at day 0 and relies only on the buyer's signature on the bill, so D/A is much closer to open account than D/P is.
Engineering view. Collection processing in a bank tracks each collection with its instructions (D/P or D/A, tenor, charges, what to do on non-payment, such as protest or storage of goods), the movement of documents between banks (SWIFT MT4xx messages for collections, for example MT400 advice of payment and MT410 acknowledgement), tracers sent when the importer delays, and the maturity of accepted bills. Because banks do not take credit risk unless they discount or avalise bills, systems must clearly separate handling-only collections from those financed by the bank.
Analogy. A documentary collection is like a cash-on-delivery parcel service: the courier hands over the parcel only when the recipient pays (D/P) or signs a binding IOU (D/A), but the courier does not promise the sender that anyone will actually pay.
Key takeaways
- In a documentary collection, banks exchange shipping documents for payment (D/P) or acceptance of a bill of exchange (D/A), under URC 522.
- Banks give no payment undertaking, which makes collections cheaper and simpler than LCs but riskier for the exporter.
- D/P keeps the exporter in control of the goods until payment; D/A gives up control in exchange for a signed promise to pay.
- Accepted bills can be discounted or avalised by banks, turning a collection into a financing product.
🧪 Practice
- Beginner: What is the main difference in risk for the exporter between D/P and D/A?
- Intermediate: An exporter sells to a long-standing customer in a country with stable political conditions but occasional foreign currency shortages. Compare an unconfirmed LC, a confirmed LC and a D/P collection for this sale, and recommend one.
- Interview: "An importer has not paid a D/P collection presented 30 days ago and the goods are incurring storage costs at the port. What should the collecting bank's system do?" Hint: follow the collection instruction (tracers, protest, storage, insurance of goods), status reporting to the remitting bank, charge handling, the bank's lack of payment obligation, and escalation and audit of each action.
<a id="11-quantitative-building-blocks-for-treasury-software"></a>