camt.087 Request to Modify Payment: fixing a payment after it was sent

The camt.087 Request to Modify Payment is the ISO 20022 message a bank sends to ask another bank to change a payment that has already been sent, and its most common use is to correct the value date. It is not a recall and it is not a cancellation: the payment still goes to the same beneficiary for the same amount, but one of its attributes changes, and the receiving bank must agree to the change and confirm it. It is the structured successor to free-format modification requests, and it exists because a payment that has left the sender can no longer be edited, it can only be changed by agreement with the bank that now holds it. Source: ISO 20022 camt.087 message definition, and SWIFT CBPR+ usage guidelines for payment modifications. Why camt.087 exists is that payments are instructed with details that turn out to be wrong, and the cost of the error depends on how fast it is fixed. A value date that is one day early can leave the debtor account overdrawn, a value date that is one day late can make the beneficiary miss a deadline, and an incorrect remittance reference can leave an invoice unmatched. Before camt.087 the fix was a phone call followed by a free-format message, which a human had to interpret, with no structured confirmation that the change had been made. The camt.087 turns the request into a structured instruction with a structured answer, camt.029, so the sender knows whether the modification was accepted or rejected, and why. The parties are the requester, usually the debtor bank acting on its customer instruction, and the responder, usually the next bank in the chain or the creditor bank, which must decide whether the change is possible. The beneficiary is affected by the change but is not a party to the request, and the debtor is the reason for it, because the debtor asked for the correction. In a chain the request travels hop by hop, and each bank must agree before passing it on, because a value date change that is agreed by Bank B but not by Bank C leaves the payment with two different value dates in the chain, which is worse than no change at all. How it works is shown by a worked example with a value-date correction. A corporate customer in Paris instructs EUR 250,000 to a supplier in Berlin with value date 10 November, then realises the invoice is not due until 12 November and the account will be overdrawn on 10 November. The Paris bank sends camt.087 to its correspondent asking to change the value date to 12 November, naming the original pacs.008, the UETR and the new value date. The correspondent checks that the payment has not yet been settled, agrees, and replies with camt.029. The customer avoids an overdraft of EUR 250,000 for two days, which at a 6 percent overdraft rate is about EUR 82 of interest, and the supplier still receives the money on the correct date. On success the modification is confirmed, the payment proceeds with the new attribute, and both banks hold the same record of what was changed and when. On failure the responder rejects the request, usually because the payment has already been settled or credited, and the camt.029 carries a reason code explaining why, for example that the payment is already settled and cannot be modified. The recovery then is not a second camt.087, it is a different tool: if the money has already been credited, the sender must request a return or a recall with camt.056, and if the value date cannot be changed, the sender must manage the overdraft or the late payment commercially. Sending the same camt.087 twice after a rejection wastes a day and changes nothing. The data in a camt.087 is the original payment identification, the UETR, the modification requested, which is usually a new value date but can also be a change to the remittance information or the charges, and the reason for the request. The new value date is the field that matters most, because a value date in the past is invalid and a value date that falls on a non-business day in the settlement system will be rejected, so the requester must validate the date before sending. A BA must specify the validation rules, the cut-off after which a modification is no longer possible, and the message the customer receives when the modification is rejected, because a customer who is told only that it failed will call the bank. Edge cases test the design. A camt.087 for a payment that has already been returned should be rejected with the return reference, not processed. A camt.087 that changes the value date of a cover payment but not the customer payment creates a mismatch between the two legs, so the requester must modify both legs or neither. A camt.087 sent on a Friday for a value date of Monday must account for the weekend, because the settlement system may treat Monday as the next business day and the modification may be unnecessary. Each of these is a case a 15-year SME should be able to explain to a developer before the developer writes the code. The effect on the bank is a controlled way to fix errors without unwinding the payment, which saves the cost of a return and a resend. The effect on the customer is a payment that arrives on the right day with the right reference, which is what the customer asked for in the first place. The effect on operations is a small queue of modification requests, each needing a decision within hours, because a value-date change requested on Monday for Tuesday is useless if it is answered on Wednesday. A bank that answers camt.087 slowly will see its customers use recalls instead, which are more expensive for everyone. What a BA, PO or SME must understand is that camt.087 is a negotiation, not an instruction, and the responder can say no. The requirement must name the modifications the bank supports, the validation rules, the cut-off, the confirmation message and the fallback when the modification is rejected. The test is to take one payment with a wrong value date and trace the camt.087 from the debtor bank to the bank that holds the funds, and to state what happens if the payment has already settled. Further reading: ISO 20022 camt.087 and camt.029 definitions; SWIFT CBPR+ usage guidelines; EPC SCT Rulebook 2025 on value dates. Last reviewed 7 November 2026.