camt.057 Notification to Receive: knowing the money is coming

The camt.057 Notification to Receive is the message a bank sends to its own customer, or to another bank, to say that a credit is expected, before the money actually arrives. It is an ISO 20022 cash management message, and its purpose is to remove the surprise from incoming payments: the beneficiary can see the amount, the currency, the value date and the debtor, and can prepare the ledger, the FX conversion or the onward payment that depends on the receipt. Without it, a treasurer learns about a EUR 2 million receipt only when the camt.053 statement arrives the next morning, which is too late to use the money that day. Source: ISO 20022 camt.057 message definition, and SWIFT CBPR+ usage guidelines for cash management messages. Why camt.057 exists is that a payment instruction and a payment receipt are two different events, and the beneficiary needs to plan around the second, not the first. A debtor may instruct a payment on Monday for value Wednesday, and the creditor bank may know about it on Monday through the interbank chain, yet the beneficiary account is not credited until Wednesday. The camt.057 bridges that gap by telling the beneficiary on Monday that EUR 2 million will arrive on Wednesday, so the treasurer can commit to a Wednesday supplier payment of EUR 1.8 million with confidence. The message is therefore a liquidity planning tool, not a payment, and it must never be confused with a credit advice, which confirms money that has already arrived. The parties are the account servicer, usually the beneficiary bank, which sends the notification, and the account owner, usually the corporate customer, which receives it. The debtor is named in the message but is not a party to it, and the debtor bank is not involved at all, which is a common misunderstanding: camt.057 is a bank-to-customer message, not a bank-to-bank payment message. In a correspondent chain the notification is issued by the bank that holds the beneficiary account, because only that bank knows the account, the expected value date and any charges it will deduct, and an intermediary cannot issue it on the beneficiary bank behalf. How it works in practice follows the payment, not the instruction. A supplier in Lyon expects EUR 850,000 from a buyer in Singapore, value date 14 November. The buyer bank sends the pacs.008 on 13 November, the intermediary confirms the funds are on their way, and on 13 November the Lyon bank sends camt.057. The supplier treasury system matches the notification to the open invoice for EUR 850,000, marks it as expected, and releases a planned payment of EUR 800,000 to its own supplier for 14 November, confident the funds will be there. The notification is matched by reference, so a missing or wrong reference breaks the match and the treasurer must investigate manually. On success the beneficiary plans with certainty, the treasury forecast for the value date is accurate to the euro, and the onward payment goes out on time, which is the whole commercial value of the message. On failure the notification itself can mislead: if the camt.057 promises EUR 850,000 on 14 November and the payment is then delayed, returned or reduced by charges to EUR 849,950, the treasurer has committed EUR 800,000 against money that arrives late or short, and the onward payment bounces or the account goes overdrawn. The failure mode is therefore a planning failure, not a payment failure, and the recovery is a corrected notification or a camt.054 debit and credit notification showing what actually arrived, followed by a revised forecast. The data in a camt.057 is the account identification, the expected amount and currency, the expected value date, the debtor and debtor agent, the remittance information and the end-to-end reference. The reference is the most operationally important field, because the corporate treasury system matches expected receipts to open invoices by reference, and a reference that does not match the invoice number creates a manual exception. A BA writing the requirement must specify the matching rule, what happens on a partial match, and whether the notification is sent per payment or batched per day, because a daily batch of 200 notifications that arrives after the treasury cut-off is useless, while per-payment notifications that arrive in real time let the treasurer act. Edge cases test whether the implementation is real. A camt.057 for a payment that is then cancelled must be followed by a cancellation or a corrected notification, or the treasurer will keep planning around money that will never arrive. A camt.057 for a payment in a currency the beneficiary does not hold must state whether the credit will be converted and at what rate, because EUR 850,000 converted at 1.08 is not the same as EUR 850,000 held in euros. A camt.057 sent to a customer who has no treasury system is noise, so the bank should offer it as an opt-in service with a clear statement of what the customer must do with it, not as a mandatory feed. The effect on the bank is a service that differentiates its cash management offering and reduces customer calls asking where the money is. The effect on the customer is a forecast that can be trusted, which lets the treasurer commit funds earlier and borrow less, so the value is measurable in interest saved. The effect on operations is a new exception queue: unmatched notifications, notifications for cancelled payments, and notifications whose amount differs from the invoice, each needing a defined owner and a defined service level. A bank that sends camt.057 without staffing that queue will create more complaints than it removes. What a BA, PO or SME must understand is that camt.057 is a promise about the future, and promises need a correction path. The requirement must name the trigger for sending it, the matching rule, the correction message when the expectation changes, and the service level for resolving unmatched notifications. The test is to ask what happens when the expected EUR 850,000 becomes EUR 849,950 or 15 November, and if the answer is that nobody tells the customer, the design is incomplete. Further reading: ISO 20022 camt.057 definition; SWIFT CBPR+ cash management usage guidelines; Bank for International Settlements CPMI, payment system glossaries. Last reviewed 7 November 2026.