Settlement netting at scale
10,000 transactions, two banks, one wire.
By Solomon Ajayi · Free to read, no signup
Lesson 19 introduced settlement netting in the bilateral case. At scale (NIBSS clearing windows, scheme net settlement, ACH multilateral netting), the same principle applies to thousands of counterparties at once. Every clearing window, a central operator nets every settlement obligation across all participants and produces ONE net debit / credit per participant. A bank with 50,000 inbound transfers and 48,000 outbound ones receives ONE wire for the net difference. Your ledger has to handle the inversion: post 50,000 individual user-facing entries (so wallets credit on time) while booking the SINGLE settlement wire against your bank account at the clearing window. This lesson walks the engineering of that asymmetry.
Netting exists because moving cash is expensive and slow, but bookkeeping is cheap and instant. If your bank has fifty thousand inbound transfers and forty-eight thousand outbound ones in a clearing window, settling each one as its own wire would be insane. So a central operator sums every participant's obligations and produces a single net figure: you receive one wire for the difference, or you pay one. The thousands of underlying transactions still happened, they just collapse into one cash movement.
Your ledger has to bridge two clocks that tick at different speeds. The user side is real-time: every inbound transfer credits a User Wallet the instant it arrives, because that is the experience customers expect. The bank side is batched: the cash only moves when the clearing window fires. To hold the gap, each transaction also touches an in-flight account, Net Settlement Receivable for money owed to you, Net Settlement Payable for money you owe. When the window closes, you receive the net but must clear both gross-position accounts, which is why the settlement entry has the net wire on one side and the full receivable and payable on the other.
The math is trivial, sum the receivables, subtract the payables, per window. The engineering is the hard part: routing fifty thousand per-transaction entries into the right in-flight bucket, then reconciling the rail's net wire against your own computed net at each window. If your number and the rail's number disagree by even a kobo, your sponsor bank's operations team will want a reconciliation report before end of day.
Worked example, step by step
Throughout the day: 50,000 inbound user transfers, ₦500M total
Customers receive money via NIBSS Instant Pay all day. Each transaction credits a user wallet IMMEDIATELY (real-time UX), but the BANK SIDE only nets at clearing windows (every few hours). For each transaction during the day, you book user wallet UP and Net Settlement Receivable UP (you'll get the cash at the next window). Aggregated: ₦500M of inbound user credits, ₦500M of Net Settlement Receivable.
| Account | Debit | Credit |
|---|---|---|
| Net Settlement Receivable (1800) | ₦500,000,000.00 | |
| User Wallet (2000) | ₦500,000,000.00 |
User Wallet UP ₦500M (credit). Net Settlement Receivable UP ₦500M (debit). In practice this is 50,000 separate entries, one per transaction; we show the AGGREGATE here. The user sees their wallet credit instantly; your bank still hasn't received the cash.
Throughout the day: 48,000 outbound, ₦480M total
Symmetric on the other side: 48,000 outbound transfers ₦480M aggregate. User Wallet DOWN, Net Settlement Payable UP (you'll PAY this at the next window).
| Account | Debit | Credit |
|---|---|---|
| User Wallet (2000) | ₦480,000,000.00 | |
| Net Settlement Payable (2800) | ₦480,000,000.00 |
User Wallet DOWN ₦480M (debit). Net Settlement Payable UP ₦480M (credit). User sees instant debit; you don't owe the rail the cash until settlement.
Clearing window fires: net ₦20M comes to your bank
Window closes. Operator nets your inbounds (₦500M) against outbounds (₦480M). NET RECEIVABLE: ₦20M. One wire lands in your bank for ₦20M. Both settlement accounts now clear to zero.
| Account | Debit | Credit |
|---|---|---|
| Bank Account (1200) | ₦20,000,000.00 | |
| Net Settlement Payable (2800) | ₦480,000,000.00 | |
| Net Settlement Receivable (1800) | ₦500,000,000.00 |
Bank Account UP ₦20M (debit). Net Settlement Receivable DOWN ₦500M (credit). Net Settlement Payable DOWN ₦480M (debit). Three lines, balanced: 20M debit + 480M debit = 500M credit. You received the NET difference but had to clear BOTH gross-position accounts.
Takeaway
Settlement netting is what makes high-volume payment rails computationally tractable. The MATH is simple, sum receivables minus sum payables per clearing window. The ENGINEERING is what's hard: real-time wallet updates throughout the day, the settlement accounts as 'in-flight' buckets, the reconciliation between the rail's net wire and your own computed net at each window. Mismatch by even a kobo and your sponsor bank operations team will demand a reconciliation report by end of day. Build the settlement-account schema and the per-transaction routing FIRST; the netting compute is the easy part.
The code behind it
Reference schema
CREATE TABLE settlement_batch (
id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
scheme text NOT NULL, -- e.g. 'NIBSS', 'ACH', 'VISA_NET'
clearing_window_close timestamptz NOT NULL,
inbound_count int NOT NULL,
inbound_total bigint NOT NULL,
outbound_count int NOT NULL,
outbound_total bigint NOT NULL,
net_amount bigint NOT NULL, -- signed: + receive, - pay
journal_entry_id uuid NOT NULL REFERENCES journal_entry (id),
created_at timestamptz NOT NULL DEFAULT now(),
UNIQUE (scheme, clearing_window_close)
);Practice this on a real ledger
Reading is half of it. Open this lesson in the lab to post the entries yourself against a real Postgres-backed double-entry ledger, with the validation on. Free, your sandbox is yours.