camt.056 cancellation request: what a bank can actually stop after stablecoin settlement

A camt.056 cancellation request is the message one bank sends another to ask that a payment be stopped. It is the ISO 20022 replacement for the MT 192 request for cancellation, and it is answered by a camt.029. In correspondent banking the request often works, because a payment usually rests in a queue somewhere before it settles. On a stablecoin rail that pause is much shorter. Once the transfer confirms on chain there is nothing left to stop. This article sets out what a cancellation request can achieve when the settlement leg moved to a public blockchain, what the message must carry, how to answer one, and how to run an operation that rarely needs to send one.

What is a camt.056 cancellation request, and who sends it?

camt.056 is the ISO 20022 financial institution to financial institution payment cancellation request. One bank sends it to another to ask that a payment already instructed be stopped and not paid out. It carries the job the MT 192 and MT 292 messages used to do. The answer comes back as a camt.029, the resolution of investigation message, which took over from the MT 196 and MT 296 pair.

There is a customer facing cousin. When the debtor asks its own bank to stop a payment, that request travels as a camt.055. The bank then decides whether to raise a camt.056 to the next party in the chain. Keeping the two apart matters in an audit. A camt.055 records what your customer asked you for. A camt.056 records what you asked of someone else.

The distinction that trips teams up is cancellation against return. A cancellation request asks a party to stop a payment before value reaches the beneficiary. A return moves settled value back, and that travels as a pacs.004. The two are often needed in sequence. You send the camt.056, you learn the payment has already settled, and the outcome becomes a return.

Why can a stablecoin leg not be recalled once it confirms?

One property of a public blockchain drives the whole answer. A confirmed transfer is final. No network operator can debit the receiving address, and no message can reach into the chain and undo a transaction. The token belongs to whoever holds the destination key.

So the useful question is not whether a payment can be cancelled. It is where the payment sits right now. A cross border payment on a stablecoin rail moves through several states. The instruction is accepted. Screening runs. The on chain transfer is signed and broadcast. The transfer confirms. The receiving institution then pays the beneficiary in local currency. A cancellation request can succeed at any point before the broadcast. After confirmation, the only honest answer is a return.

That changes what good looks like. In correspondent banking a cancellation can sometimes be worked for days, because the money is resting with an intermediary. On a fast rail the window is minutes. Your operation should be judged on how quickly it acts on a request, not on how long it can hold one open. Route these messages to a staffed queue with an alerting rule, not to a shared mailbox someone reads after lunch.

What must a camt.056 cancellation request carry?

The request only helps if the receiving team can find the payment at once. So references come first. Quote the original end to end identification, the original transaction identification, and above all the UETR. The UETR is the unique reference that follows a payment across every leg, so it is the single field that joins your request to the right transaction.

Then the original payment detail: the interbank settlement amount and currency, the settlement date, the debtor and the creditor. Receiving teams match on these when a reference has been mistyped, and a request that omits them tends to sit unanswered.

Then the reason, as a structured code rather than a sentence. Free text cannot be routed, counted or escalated. A fraud code should wake somebody up. A duplicate code should not.

Where the settlement leg is on chain, add the settlement detail. Name the token, the chain, the sending address and, if the transfer has already gone out, the transaction hash. Schemes differ on where that detail sits, so many institutions carry it in supplementary data or in the settlement record kept beside the message. Wherever it sits, it has to be in the file, because the first thing the receiver will do is look at the chain.

Which cancellation reason code belongs on the request?

Cancellation reason codes come from the ISO 20022 external code sets, and a short list covers most traffic. DUPL marks a duplicate payment. CUST records a cancellation the customer asked for. FRAD marks a payment believed to have a fraudulent origin. TECH covers a technical problem in the sending system. AM09 covers a wrong amount. AGNT points at an incorrect agent, and CURR at an incorrect currency.

Choose the narrow code. FRAD is not a polite way of saying the customer changed their mind, and using it that way will cost you credibility with the counterparties you most need to answer fast. A book of cancellations tagged DUPL tells you to fix a system. A book tagged CUST tells you to fix a screen.

A cancellation request on a stablecoin rail is a race against confirmation, not a negotiation. The value of the message is that it reaches a named team within minutes, carrying a code they can act on without reading a paragraph.

How should an operations team answer a camt.056?

The reply is a camt.029, and it should go out quickly even when the answer is no. Silence is what turns a cancellation into a dispute. Work the steps below in order, and record the output of each one.

• Locate the payment by UETR first, then by the original references, and confirm the amount, currency and value date all match.
• Establish the exact state of the settlement leg: instructed, screened, broadcast, confirmed, or already paid out in local currency.
• If the transfer has not been broadcast, stop it and place the instruction on hold before you do anything else.
• If the transfer has confirmed, say so plainly in the camt.029 and move the conversation to a return under pacs.004.
• Screen the request itself, because asking a bank to stop a payment is a known social engineering route.
• Never redirect value on the strength of a cancellation request. A new destination address is a new beneficiary and needs new approval.
• Answer with a structured status and reason code rather than a narrative paragraph.
• Log the decision, the person or system that made it and the timestamp, because an examiner will ask how the call was made.

The camt.029 carries a status for each transaction. ACCR records an accepted cancellation request, PDCR a pending one and RJCR a rejection. A rejection then needs its own reason. ARDT says the transaction has already been returned. NOOR says no original transaction was received. LEGL records a legal decision, and INDM says an indemnity is required first. Those codes let the sender's system act without a human reading the reply, which is the whole point of sending a message rather than an email.

One more habit is worth building. When a return does follow a cancellation request, the pacs.004 should carry FOCR as its return reason. The two messages then read as one story rather than two unrelated events, and the sender can close the case without opening an investigation.

What removes the need for most cancellation requests?

Most cancellations are caused upstream. A duplicate release, a mistyped amount, a payment sent to a stale beneficiary record, or an instruction released before a compliance check had finished. Each of those has a control, and the controls are cheaper than the messages.

Four are worth the effort. Enforce idempotency on the instruction, so a retried API call cannot create a second payment. Require a second pair of eyes above a stated amount, set by your own risk appetite. Hold beneficiary records under change control, with a cooling period after any change to an address or an account. Put the final screening decision before the broadcast, so the irreversible step is also the last step.

Then measure. Count the cancellation requests you send and receive, split them by reason code, and review the trend every month. A rising DUPL count is a system defect. A rising FRAD count is a customer problem. Neither one improves on its own, and both are visible long before they become losses.

Where StableNet fits

StableNet, built by SpendTheBits, is a cross border B2B payment and settlement platform for banks, credit unions, licensed money service businesses, exchange houses and remittance fintechs. Settlement runs in regulated stablecoins such as USDC and USDT on public blockchains and completes in minutes with on chain auditability, which is exactly why the cancellation window is short and the message has to reach a staffed queue. The platform is ISO 20022 native, with pacs.008 customer credit transfers, pacs.009 interbank legs, pacs.002 status reports and pacs.004 returns inside head.001 envelopes, tracked end to end by UETR, so a stopped payment and the transfer that returns it sit under one reference an examiner and a counterparty can both follow. Compliance is built in, with KYB and KYC onboarding, KYT, sanctions and PEP screening, FATF Travel Rule data in IVMS101 form, a compliance workbench and a tamper evident audit trail. SpendTheBits is a Bank of Canada registered payment service provider and a named finalist in the Swift Hackathon 2026 Technical Challenge.