System design deep dive: nostro account management systems

Each record holds the account number, the correspondent, the currency, the current balance, the available balance, and the intraday limits agreed with the correspondent. Every payment that uses that nostro posts a debit or credit to the account in real time, and the balance is updated in the same transaction as the payment status change, so the two can never drift apart. A large international bank may hold 200 to 500 nostro accounts across 50 or more currencies, and the core system must keep every balance accurate to the cent at all times. The nostro account master data is therefore a controlled reference table, and changes to it require approval, because a wrong account number or a wrong currency on a nostro record will send payments to the wrong place. Real time balance tracking relies on event driven updates and a fast balance cache. When a payment is released, the system reserves the funds immediately, reducing the available balance even before the payment leaves the bank. When the correspondent confirms settlement, the reservation becomes a final debit. This two step approach prevents the bank from overcommitting funds on a busy morning when hundreds of payments compete for the same account. The balance cache is updated in milliseconds and is replicated to a standby site, so a failure in one data centre does not lose the latest position. Treasury teams watch a dashboard that shows every nostro balance, the reserved amount, and the headroom left for the rest of the day. Liquidity forecasting predicts how much money each nostro will need before the day ends. The forecast combines the payments already queued, the expected receipts from incoming payments, the cut off times of each currency, and historical patterns for the day of the week and the month. A forecast run every 15 minutes projects the balance at each cut off and flags any account that will fall below its minimum threshold. If a shortfall is predicted, treasury can move funds between accounts, draw on a credit line, or delay lower priority payments. A typical forecast covers 5,000 to 20,000 expected payments per currency per day, and accuracy within 5 percent is considered good enough to act on with confidence. Choosing a correspondent is a routing decision based on cost, speed, cut off time, and the relationship with the correspondent. The routing table ranks correspondents per currency and destination, with the cheapest and fastest option first, and the payment engine picks the best available option that can meet the value date. If the preferred correspondent has low liquidity or is approaching its cut off, the engine falls through to the next option automatically. The decision is logged with the reason, so operations can explain why a payment went through one bank rather than another. This dynamic routing keeps costs down, improves settlement speed, and spreads volume so no single correspondent becomes a bottleneck. The nostro reconciliation engine matches the bank's own records against the statements received from each correspondent, usually once a day and intraday for high volume currencies. It matches on amount, currency, value date, and reference, and it auto matches 95 to 98 percent of items without human help. Unmatched items fall into exception queues, such as a payment the bank sent but the correspondent has not yet reported, or a charge the correspondent deducted that the bank did not expect. The engine also enforces cut off times across time zones, so a payment sent at 4 in the afternoon London time for a New York nostro must respect the US cut off, not the UK one. A shared cut off calendar, stored in UTC, keeps every team working from the same clock. The system must also handle the messages that carry nostro information. The MT950 statement and its camt.053 equivalent arrive daily, the MT940 balance report and camt.052 arrive intraday, the MT942 interim report shows transactions since the last statement, and the MT900 and MT910 advise individual debits and credits as they happen. The system parses each message, validates the format, stores the entries, and feeds them to the reconciliation engine. A message that fails validation goes to an exception queue, because a statement that cannot be parsed cannot be reconciled, and a day without reconciliation is a day without control. Reporting and control sit on top of all of this. Treasury needs a dashboard showing every nostro balance, the forecast low point, and the headroom. Operations needs an exception queue showing every unmatched item with its age. Finance needs a report of nostro charges by correspondent and by currency, so that pricing can be reviewed. Compliance needs a report of blocked and rejected payments, and audit needs a record of every change to nostro master data. The analyst who writes the requirements for a nostro management system should specify each of these reports, who uses it, and how often, because a system that moves money without reporting on it is a system that nobody controls. If the balance cache is stale, the engine may release a payment against funds that are no longer there, so the cache must be refreshed from the core ledger at defined intervals and on demand. If the correspondent's statement is late, reconciliation must still run against the previous statement and flag the delay, not silently skip the day. If the routing table has no available correspondent for a currency, the payment must queue with a clear reason rather than fail silently. If a nostro account is closed by the correspondent, the system must block new payments on that corridor immediately and alert treasury. Each of these is a real incident that has happened at a real bank, and the analyst who designs for them is the analyst who prevents the next one.