Articles / Learning brief
One corporate payment: the full MX lifecycle and its MT migration path
Your notes
In simple terms / 01
What this means in plain language
Follow one fictional CBPR+ corporate payment from pain.001 initiation through pacs.008 execution, pain.002 and pacs.002 status, customer and interbank cancellation, return, investigation, entry notification, intraday reporting, and the end-of-day statement — then see exactly how the legacy MT101, MT103, MT192/196/195/199 and MT9xx world compares.
A corporate cross-border payment is not one message travelling from company to supplier. It is a conversation across three layers. The customer layer begins with pain.001, may receive pain.002 status, can request cancellation with camt.055, and learns what posted through camt.054, camt.052, and camt.053. The interbank layer moves the instruction in pacs.008, reports FI-to-FI status in pacs.002, asks for cancellation in camt.056, resolves the case in camt.029, returns settled value in pacs.004, and can use camt.110/111 for modern investigations. Classic repair and trace cases also explain camt.026 unable-to-apply, camt.027 claim-non-receipt, camt.028 additional-payment-information, and pacs.028 status request; their production use is service- and migration-dependent. The ledger layer is the actual debit, correspondent settlement, beneficiary credit, and any reversal or return. Legacy MT did not mirror every one of these roles: MT101 and MT103 handled initiation and payment, MT192/196 and MT195/199 carried Category 1 cancellation and queries, MT292/296 and MT295/299 handled the Category 2 leg, and MT900/910/941/942/940/950 reported entries and balances. Migration is therefore not a tag swap; it must preserve the business event, case reference, status meaning, UETR, payment leg and actual value movement.
Complete lesson / 02
Understand the full idea, step by step
One cross-border supplier payment can produce a dozen messages, several ledger movements, and more than one legitimate ending. That sounds complicated only when every message is treated as another name to memorise. Put each message beside the business event it serves — initiate, accept, execute, reject, cancel, return, investigate, notify, report — and the lifecycle becomes a readable conversation. This lesson follows one fictional CBPR+ corporate payment all the way through, then lays the legacy MT path alongside it without inventing one-to-one equivalents that never existed.
Three layers — do not collapse them
- Business conversation
- pain, pacs, and camt messages express intent, status, cancellation, return, investigation, notification, and reporting. They describe events; not every message moves value.
- Ledger and settlement
- The corporate debit, correspondent book transfer, supplier credit, and any return credit are the value events. A message can request one without proving it happened.
- Evidence and reporting
- camt.054 gives an entry notification, camt.052 gives intraday reporting, and camt.053 gives the statement. They are different views of booked activity, not three extra payments.
Read the steps as text
- 01MessageTreasury sends the payment instructionAsha Traders treasury → Bank Alfa (debtor agent) · pain.001
Asha Traders asks Bank Alfa to pay one supplier. The pain.001 is a customer instruction, not an interbank payment and not proof that funds moved.
- 02ProcessingBank Alfa validates the instructionBank Alfa (debtor agent)
The bank checks authority, account and address data, duplicate references, available funds, cut-off time, and sanctions-screening results before accepting the instruction.
Screening checkpoint: Customer-payment screening — Debtor, creditor, agents, addresses, and remittance data are screened before release.
- 03MessageTreasury receives an accepted statusBank Alfa (debtor agent) → Asha Traders treasury · pain.002
A pain.002 says the instruction passed the reported checks and was accepted for processing. It does not say the supplier has been credited; banks choose which lifecycle statuses their service reports.
- 04PostingBank Alfa debits the corporate accountBank Alfa (debtor agent)
Bank Alfa books the customer debit. The debit and the interbank settlement are separate ledger events and can occur at different times under the account agreement.
- DR Asha Traders USD operating account — USD 125,000.00
- 05MessageTreasury receives an entry notificationBank Alfa (debtor agent) → Asha Traders treasury · camt.054
Where the service provides it, a camt.054 reports the booked debit promptly and carries structured references for cash application. It reports an account entry; it does not create the entry.
- 06MessageBank Alfa sends the interbank paymentBank Alfa (debtor agent) → Meridian Bank (correspondent) · pacs.008
Bank Alfa turns the accepted customer instruction into a pacs.008. The UETR, end-to-end reference, parties, agents, amounts, and remittance data identify the same business payment on the interbank leg.
- 07ProcessingMeridian validates and screens the paymentMeridian Bank (correspondent)
The correspondent applies CBPR+ validation, sanctions screening, serial-routing checks, and an account-position check before it books or forwards the payment.
Screening checkpoint: Correspondent screening — Every bank in the chain makes its own decision; an upstream pass does not bind a downstream bank.
- 08SettlementThe correspondent settles the interbank legMeridian Bank (correspondent)
Meridian debits Bank Alfa's USD account and credits Nordbank's USD account. This book transfer is the value movement; the pacs.008 is the instruction describing it.
This teaching corridor uses correspondent-book settlement in commercial bank money. Other CBPR+ payments may use different correspondents or market infrastructures.
- DR Bank Alfa USD account at Meridian — USD 125,000.00
- CR Nordbank USD account at Meridian — USD 125,000.00
- 09MessageThe payment reaches NordbankMeridian Bank (correspondent) → Nordbank (creditor agent) · pacs.008
Meridian forwards the serial customer credit transfer with the original UETR and structured payment data so Nordbank can match the instruction to the incoming value on its correspondent account.
- 10ProcessingNordbank validates the incoming paymentNordbank (creditor agent)
Nordbank checks the supplier account, screens the payment, and confirms that the incoming value and instruction can be matched before it credits the customer.
- 11PostingNordbank credits the supplierNordbank (creditor agent)
Nordbank books the credit to Northstar Components. The supplier can now use the funds; any later recovery request must respect that settled and credited state.
- CR Northstar Components USD account — USD 125,000.00
- 12MessageAn interbank status closes the processing loopNordbank (creditor agent) → Bank Alfa (debtor agent) · pacs.002
Where the bilateral service provides a positive pacs.002, ACCC reports that the creditor account was credited against the original pacs.008. A transport acknowledgement and a business payment status are different signals.
- 13MessageTreasury receives the intraday account reportBank Alfa (debtor agent) → Asha Traders treasury · camt.052
If contracted, camt.052 gives Asha an intraday view of balances and entries, including the debit and its references. It is an interim report, not the final daily statement.
- 14MessageThe end-of-day statement closes reconciliationBank Alfa (debtor agent) → Asha Traders treasury · camt.053
Bank Alfa sends the booked statement for the account. Treasury matches the camt.053 entry to its pain.001 transaction using the end-to-end and account-servicer references.
Happy path — instruction to statement
- CUSTOMER
Demo Trading sends pain.001 to Bank Alfa. This is the customer's instruction to its bank, not yet the interbank payment.
- VALIDATION
Bank Alfa validates authorisation, account, compliance, cut-off, and data. A pain.002 ACCP reports customer-side acceptance; it does not by itself prove beneficiary credit.
- LEDGER
Bank Alfa debits Demo Trading and can send camt.054 as a near-real-time debit notification.
- MESSAGE
Bank Alfa sends pacs.008 into the CBPR+ chain. Meridian validates and settles the correspondent leg, then forwards the instruction toward Northstar.
- LEDGER
Northstar validates and credits Example Supplies. Where the bilateral service sends a positive pacs.002, ACCC can report that the creditor account was credited.
- NOTIFICATION
The account owner can see intraday balance/entries in camt.052 and the authoritative end-of-day booked statement in camt.053. The same payment reference must correlate all three reporting views.
ISO 20022 — ILLUSTRATIVE, NON-PRODUCTION
The customer-side cancellation request identifies the original pain.001, payment-information block, end-to-end id, and reason. It asks Bank Alfa to act; it does not reach the beneficiary bank directly and does not guarantee cancellation.
| Business event | MX message | Legacy MT treatment |
|---|---|---|
| Corporate instruction | pain.001 | MT101 |
| Customer-side status | pain.002 | No exact MT equivalent; bank channel, proprietary status, or MT199-style bilateral communication |
| Interbank customer credit transfer | pacs.008 | MT103 |
| FI-to-FI business status | pacs.002 | No standalone twin; legacy payment-message /REJT/ conventions or bilateral status |
| Customer asks its bank to cancel | camt.055 | No exact customer-side MT equivalent; agreed channel or free-format communication |
| Bank asks another bank to cancel | camt.056 | MT192/292 cancellation request family |
| Cancellation/investigation resolution | camt.029 | MT196/296 answer family |
| Settled value returned | pacs.004 | MT103/202 /RETN/ return convention |
| Entry debit/credit notification | camt.054 | MT900 debit advice / MT910 credit advice |
| Intraday reporting | camt.052 | MT941 balance report / MT942 interim transaction report |
| End-of-day statement | camt.053 | MT940 customer statement / MT950 interbank statement |
| Modern investigation request/response | camt.110 / camt.111 | MT195/198 and MT199 query families / MT196/198 and MT199 answer families |
COMMON CONFUSION
“The network ACK, pain.002, pacs.002, camt.054, and camt.053 are all different ways to say the payment succeeded.”
They answer different questions. An ACK says a network or interface received syntax. pain.002 says what the customer's bank did with the customer instruction. pacs.002 says what an FI did with an interbank instruction. camt.054 says an account entry was notified. camt.053 says what the account servicer booked on the statement. Only the right status, on the right account and business layer, answers the question you actually have.
WHAT IF — The instruction fails before value settles.
What happens: Bank Alfa can reject pain.001 with pain.002 RJCT, or a bank in the interbank chain can reject pacs.008 with pacs.002 RJCT. These are rejection paths: the payment never reaches a settled final state on that leg.
How it is handled: Correlate original message id, instruction id, end-to-end id, transaction id, and UETR. Read the reason code. If the customer was already debited before the interbank rejection, reverse that customer ledger entry and communicate the result; do not wait for pacs.004 because there was no settled interbank value to return.
WHAT IF — The payment settled, but the beneficiary cannot keep the funds — for example, the account is closed.
What happens: The creditor side sends pacs.004. This is a new value-carrying return linked to the original payment, not a late pacs.002 rejection.
How it is handled: Reconcile the pacs.004, correspondent settlement movement, corporate re-credit, and reporting entry. The returned amount can differ from the original where permitted fees apply, so a message match without a ledger match is incomplete.
WHAT IF — Asha spots a duplicate after release and asks for cancellation.
What happens: camt.055 carries the customer request to Bank Alfa. If the payment has left the bank, Bank Alfa sends camt.056 through the FI chain. camt.029 says whether the case was accepted or refused. Acceptance is not guaranteed, especially after beneficiary credit.
How it is handled: Keep the customer case, FI case, original UETR, and all original references linked. A positive camt.029 is case resolution; the later pacs.004 plus account entry are the evidence that settled value actually returned. A negative camt.029 closes the recall attempt but leaves the original payment in place.
Read the steps as text
- 01MessageTreasury sends a request for transferAsha Traders treasury → Bank Alfa (ordering bank) · MT101
Asha Traders asks Bank Alfa to execute the supplier payment with an MT101. It is the legacy initiation request, not the bank-to-bank customer payment and not proof of execution.
- 02ProcessingBank Alfa validates the MT101Bank Alfa (ordering bank)
The bank checks the mandate, message fields, funds, cut-off, routing, and sanctions-screening results. A FIN ACK only confirms network acceptance; pain.002-style business status has no MT equivalent.
- 03PostingBank Alfa debits Asha TradersBank Alfa (ordering bank)
Once it accepts the request for execution, Bank Alfa books the customer debit under the account agreement before it releases the interbank MT103.
- DR Asha Traders USD operating account — USD 125,000.00
- 04MessageTreasury receives a debit confirmationBank Alfa (ordering bank) → Asha Traders treasury · MT900
Where contracted, MT900 confirms one booked debit on the serviced account. It is an account-entry advice, not a beneficiary-credit confirmation and not a substitute for payment status.
- 05MessageBank Alfa sends the customer paymentBank Alfa (ordering bank) → Meridian Bank (correspondent) · MT103
The MT103 carries the customer-payment instruction into the correspondent chain. In a serial route the instruction follows the account path used to settle the value.
- 06ProcessingMeridian validates and screens the MT103Meridian Bank (correspondent)
The correspondent validates FIN fields, checks Bank Alfa's account, screens the parties and narrative data, and decides whether it can book and forward the payment.
- 07SettlementMeridian settles across its booksMeridian Bank (correspondent)
Meridian debits Bank Alfa's USD account and credits Nordbank's USD account. The ledger movement is the settlement; the MT103 is the instruction.
- DR Bank Alfa USD account at Meridian — USD 125,000.00
- CR Nordbank USD account at Meridian — USD 125,000.00
- 08MessageNordbank receives a credit confirmationMeridian Bank (correspondent) → Nordbank (beneficiary bank) · MT910
The MT910 advises Nordbank that its account at Meridian was credited. Nordbank uses it to match the incoming value against the customer-payment instruction.
- 09MessageThe MT103 reaches NordbankMeridian Bank (correspondent) → Nordbank (beneficiary bank) · MT103
Meridian forwards the serial customer-payment message with the original references and party details so Nordbank can validate and apply the credit.
- 10ProcessingNordbank validates and matches the paymentNordbank (beneficiary bank)
Nordbank checks the beneficiary account, screens the payment, and matches the instruction to the credited nostro entry before paying its customer.
- 11PostingNordbank credits the supplierNordbank (beneficiary bank)
Nordbank books the credit to Northstar Components. A later cancellation is now a recovery request; the original credit cannot be erased by sending another message.
- CR Northstar Components USD account — USD 125,000.00
- 12MessageTreasury receives an intraday balance reportBank Alfa (ordering bank) → Asha Traders treasury · MT941
Where contracted, MT941 reports balances without the full transaction list. It is one legacy predecessor of the broader camt.052 account report.
- 13MessageTreasury receives intraday transactionsBank Alfa (ordering bank) → Asha Traders treasury · MT942
MT942 reports account movements during the day. Treasury uses the original and account-servicer references to match the payment before the final statement arrives.
- 14MessageThe customer statement closes the dayBank Alfa (ordering bank) → Asha Traders treasury · MT940
Bank Alfa sends the booked customer statement. Asha reconciles the MT940 entry to the original MT101 transaction and its own expected cash position.
- 15MessageBank Alfa reconciles its nostro statementMeridian Bank (correspondent) → Bank Alfa (ordering bank) · MT950
Meridian's MT950 reports the entries on Bank Alfa's correspondent account. This bank-to-bank reconciliation is a different account perspective from the corporate's MT940.
STRICTLY SPEAKING
This MT view is migration guidance, not a recommendation to build a new MT payment chain. Cross-border interbank payment-instruction coexistence ended in November 2025. Swift's current roadmap makes receipt of structured camt.110 investigation requests part of the November 2026 transition with in-flow translation, while the move toward ISO-only structured exceptions, investigations, and cancellation services continues into November 2027. MT101 relay and reporting-message timelines are not identical to the MT103/202 payment-instruction deadline. Always check the current Swift roadmap and your service contracts before turning these dates into a delivery plan.
Important adjacent messages — related, but not interchangeable
- camt.110 / camt.111
- Structured investigation request and response. Use them when information or case handling is the goal. They do not move payment value.
- camt.026 / .027 / .028
- Classic investigation messages for unable-to-apply, claim-non-receipt, and additional-payment-information cases. Their current availability is service- and migration-dependent; they are not interchangeable with Case Management camt.110/111.
- pacs.028
- Requests an FI-to-FI status under an agreed bilateral or scheme service. A request is not the status itself, and a network ACK is not the business answer.
- pacs.007
- A generic FI-to-FI payment reversal used in applicable scheme and message contexts. It is not a universal CBPR+ 'undo pacs.008' button. For a settled CBPR+ credit-transfer return, follow the applicable pacs.004/cancellation rules.
- pacs.002 vs pacs.004
- pacs.002 reports status; pacs.004 returns settled value. A rejection before settlement and a return after settlement must never be merged into one exception state.
- camt.052 / .053 / .054
- Intraday report, statement, and entry notification. Their subscriptions and timing vary by account servicer; design reconciliation so the same entry is recognised across views rather than booked repeatedly.
REMEMBER IT
Ask four questions in order: What was requested? What status was reported? Did value actually move? What account evidence proves it? That sequence keeps pain/pacs/camt messages, case outcomes, and ledger truth in their proper places.
FOR NOW, REMEMBER
- pain.001 begins the customer instruction; pain.002 reports customer-side status; pacs.008 carries the interbank credit transfer; pacs.002 reports FI-to-FI status.
- camt.055 is the customer request, camt.056 is the FI recall, camt.029 resolves the case, and pacs.004 carries returned value after settlement.
- camt.054 notifies an entry, camt.052 reports intraday activity, and camt.053 is the statement. Correlate them; do not double-book them.
- Legacy MT supplies useful semantic predecessors, not a perfect mirror: MT101, MT103, MT192/196, MT195/199, and MT900/910/941/942/940/950 cover much of the lifecycle, while pain.002 and customer-side camt.055 have no exact MT twins.
- camt.026/027/028 explain classic repair and non-receipt cases; camt.110/111 modernise orchestrated investigation conversations, and pacs.028 requests an agreed FI status. None moves value. pacs.007 remains scheme/context-specific and is not placed in this CBPR+ flagship path as a universal reversal.
TRY IT YOURSELF
A bank receives a positive camt.029 after recalling a settled pacs.008. Can operations tell the corporate that its account has been re-credited?
Now go deeper on exception operations: reason codes, case ownership, repair versus reject, recalls, returns, investigations, and the reconciliation controls that stop a message outcome being mistaken for money movement.
KEEP GOINGKey takeaways / 03
Three things to remember
- 01
Read the lifecycle in three layers: instruction/status messages describe intent and progress, ledger entries move or record value, and reporting messages tell an account owner what has posted. A technical ACK is none of those business outcomes.
- 02
Cancellation and return are separate events: camt.055 asks the debtor bank, camt.056 asks another bank, camt.029 answers the case, and pacs.004 moves settled value back. A positive answer alone is not money returned.
- 03
MT-to-MX is not one-to-one: pain.002 and customer-side camt.055 have no exact MT equivalent, while legacy /REJT/ and /RETN/ conventions carried meanings now expressed by pacs.002 and pacs.004.
Practical use cases / 04
Where you would use this
A corporate treasury or channel analyst can locate the exact boundary between pain.001 acceptance, account debit, interbank execution, beneficiary credit, and later statement reconciliation.
An operations investigator can choose the correct exception path: reject before settlement, return after settlement, customer cancellation, FI-to-FI recall, or modern investigation request/response.
A migration team can inventory legacy MT101/103/192/195/196/199 and MT9xx dependencies without pretending every MT message has a direct ISO 20022 twin.
Worked example / 05
Put the idea into a real situation
A fictional Demo Trading Ltd sends EUR 1,250 to Example Supplies Ltd. Bank Alfa accepts pain.001 and reports ACCP in pain.002, debits the corporate account, sends camt.054, and releases a serial pacs.008 through its correspondent. The beneficiary bank credits the supplier and, where the bilateral service supports positive status, may report ACCC in pacs.002; both banks later expose relevant entries through camt.052 and camt.053. If the supplier account is closed after settlement, the creditor side sends pacs.004 and the returned value is booked separately. If the corporate spots a duplicate, it sends camt.055 to Bank Alfa; the bank sends camt.056 onward; camt.029 says whether the request was accepted; only a later pacs.004 and matching account entry prove that the money returned.
Operational sequence / 06
Follow the message and decision path
This compact sequence is a learning model. Exact routing and rulebook behavior can vary by scheme, participant, and implementation.
Read the steps as text
- 01MessageTreasury sends the payment instructionAsha Traders treasury → Bank Alfa (debtor agent) · pain.001
Asha Traders asks Bank Alfa to pay one supplier. The pain.001 is a customer instruction, not an interbank payment and not proof that funds moved.
- 02ProcessingBank Alfa validates the instructionBank Alfa (debtor agent)
The bank checks authority, account and address data, duplicate references, available funds, cut-off time, and sanctions-screening results before accepting the instruction.
Screening checkpoint: Customer-payment screening — Debtor, creditor, agents, addresses, and remittance data are screened before release.
- 03MessageTreasury receives an accepted statusBank Alfa (debtor agent) → Asha Traders treasury · pain.002
A pain.002 says the instruction passed the reported checks and was accepted for processing. It does not say the supplier has been credited; banks choose which lifecycle statuses their service reports.
- 04PostingBank Alfa debits the corporate accountBank Alfa (debtor agent)
Bank Alfa books the customer debit. The debit and the interbank settlement are separate ledger events and can occur at different times under the account agreement.
- DR Asha Traders USD operating account — USD 125,000.00
- 05MessageTreasury receives an entry notificationBank Alfa (debtor agent) → Asha Traders treasury · camt.054
Where the service provides it, a camt.054 reports the booked debit promptly and carries structured references for cash application. It reports an account entry; it does not create the entry.
- 06MessageBank Alfa sends the interbank paymentBank Alfa (debtor agent) → Meridian Bank (correspondent) · pacs.008
Bank Alfa turns the accepted customer instruction into a pacs.008. The UETR, end-to-end reference, parties, agents, amounts, and remittance data identify the same business payment on the interbank leg.
- 07ProcessingMeridian validates and screens the paymentMeridian Bank (correspondent)
The correspondent applies CBPR+ validation, sanctions screening, serial-routing checks, and an account-position check before it books or forwards the payment.
Screening checkpoint: Correspondent screening — Every bank in the chain makes its own decision; an upstream pass does not bind a downstream bank.
- 08SettlementThe correspondent settles the interbank legMeridian Bank (correspondent)
Meridian debits Bank Alfa's USD account and credits Nordbank's USD account. This book transfer is the value movement; the pacs.008 is the instruction describing it.
This teaching corridor uses correspondent-book settlement in commercial bank money. Other CBPR+ payments may use different correspondents or market infrastructures.
- DR Bank Alfa USD account at Meridian — USD 125,000.00
- CR Nordbank USD account at Meridian — USD 125,000.00
- 09MessageThe payment reaches NordbankMeridian Bank (correspondent) → Nordbank (creditor agent) · pacs.008
Meridian forwards the serial customer credit transfer with the original UETR and structured payment data so Nordbank can match the instruction to the incoming value on its correspondent account.
- 10ProcessingNordbank validates the incoming paymentNordbank (creditor agent)
Nordbank checks the supplier account, screens the payment, and confirms that the incoming value and instruction can be matched before it credits the customer.
- 11PostingNordbank credits the supplierNordbank (creditor agent)
Nordbank books the credit to Northstar Components. The supplier can now use the funds; any later recovery request must respect that settled and credited state.
- CR Northstar Components USD account — USD 125,000.00
- 12MessageAn interbank status closes the processing loopNordbank (creditor agent) → Bank Alfa (debtor agent) · pacs.002
Where the bilateral service provides a positive pacs.002, ACCC reports that the creditor account was credited against the original pacs.008. A transport acknowledgement and a business payment status are different signals.
- 13MessageTreasury receives the intraday account reportBank Alfa (debtor agent) → Asha Traders treasury · camt.052
If contracted, camt.052 gives Asha an intraday view of balances and entries, including the debit and its references. It is an interim report, not the final daily statement.
- 14MessageThe end-of-day statement closes reconciliationBank Alfa (debtor agent) → Asha Traders treasury · camt.053
Bank Alfa sends the booked statement for the account. Treasury matches the camt.053 entry to its pain.001 transaction using the end-to-end and account-servicer references.
Read the steps as text
- 01MessageTreasury sends a request for transferAsha Traders treasury → Bank Alfa (ordering bank) · MT101
Asha Traders asks Bank Alfa to execute the supplier payment with an MT101. It is the legacy initiation request, not the bank-to-bank customer payment and not proof of execution.
- 02ProcessingBank Alfa validates the MT101Bank Alfa (ordering bank)
The bank checks the mandate, message fields, funds, cut-off, routing, and sanctions-screening results. A FIN ACK only confirms network acceptance; pain.002-style business status has no MT equivalent.
- 03PostingBank Alfa debits Asha TradersBank Alfa (ordering bank)
Once it accepts the request for execution, Bank Alfa books the customer debit under the account agreement before it releases the interbank MT103.
- DR Asha Traders USD operating account — USD 125,000.00
- 04MessageTreasury receives a debit confirmationBank Alfa (ordering bank) → Asha Traders treasury · MT900
Where contracted, MT900 confirms one booked debit on the serviced account. It is an account-entry advice, not a beneficiary-credit confirmation and not a substitute for payment status.
- 05MessageBank Alfa sends the customer paymentBank Alfa (ordering bank) → Meridian Bank (correspondent) · MT103
The MT103 carries the customer-payment instruction into the correspondent chain. In a serial route the instruction follows the account path used to settle the value.
- 06ProcessingMeridian validates and screens the MT103Meridian Bank (correspondent)
The correspondent validates FIN fields, checks Bank Alfa's account, screens the parties and narrative data, and decides whether it can book and forward the payment.
- 07SettlementMeridian settles across its booksMeridian Bank (correspondent)
Meridian debits Bank Alfa's USD account and credits Nordbank's USD account. The ledger movement is the settlement; the MT103 is the instruction.
- DR Bank Alfa USD account at Meridian — USD 125,000.00
- CR Nordbank USD account at Meridian — USD 125,000.00
- 08MessageNordbank receives a credit confirmationMeridian Bank (correspondent) → Nordbank (beneficiary bank) · MT910
The MT910 advises Nordbank that its account at Meridian was credited. Nordbank uses it to match the incoming value against the customer-payment instruction.
- 09MessageThe MT103 reaches NordbankMeridian Bank (correspondent) → Nordbank (beneficiary bank) · MT103
Meridian forwards the serial customer-payment message with the original references and party details so Nordbank can validate and apply the credit.
- 10ProcessingNordbank validates and matches the paymentNordbank (beneficiary bank)
Nordbank checks the beneficiary account, screens the payment, and matches the instruction to the credited nostro entry before paying its customer.
- 11PostingNordbank credits the supplierNordbank (beneficiary bank)
Nordbank books the credit to Northstar Components. A later cancellation is now a recovery request; the original credit cannot be erased by sending another message.
- CR Northstar Components USD account — USD 125,000.00
- 12MessageTreasury receives an intraday balance reportBank Alfa (ordering bank) → Asha Traders treasury · MT941
Where contracted, MT941 reports balances without the full transaction list. It is one legacy predecessor of the broader camt.052 account report.
- 13MessageTreasury receives intraday transactionsBank Alfa (ordering bank) → Asha Traders treasury · MT942
MT942 reports account movements during the day. Treasury uses the original and account-servicer references to match the payment before the final statement arrives.
- 14MessageThe customer statement closes the dayBank Alfa (ordering bank) → Asha Traders treasury · MT940
Bank Alfa sends the booked customer statement. Asha reconciles the MT940 entry to the original MT101 transaction and its own expected cash position.
- 15MessageBank Alfa reconciles its nostro statementMeridian Bank (correspondent) → Bank Alfa (ordering bank) · MT950
Meridian's MT950 reports the entries on Bank Alfa's correspondent account. This bank-to-bank reconciliation is a different account perspective from the corporate's MT940.
Evidence & review / 07
Evidence & review
A corporate-originated cross-border credit transfer using CBPR+ for the interbank leg, with customer initiation/reporting and the legacy MT equivalents shown for migration understanding.
What this brief simplifies: One correspondent and a serial pacs.008 route stand in for longer chains and cover settlement. Optional status messages and reporting subscriptions vary by bank. Cancellation acceptance is never guaranteed.
Sources for this brief5
- Official requirement
ISO 20022 Catalogue of messages ↗ — ISO 20022 Registration Authority · pain.001, pain.002, pacs.002, pacs.004, pacs.007, pacs.008, pacs.028, camt.026–029, camt.052–056, camt.110 and camt.111
Each message set is described by a Message Definition Report; earlier versions remain available in the ISO 20022 messages archive.
- Market practice
Cross-Border Payments and Reporting Plus (CBPR+) usage guidelines ↗ — Swift (CBPR+ working group) · CBPR+ customer credit transfer, status, cancellation, return, and reporting usage
Full guidelines require MyStandards access. Public guidance states that after 14 November 2026 fully unstructured addresses are removed for in-scope CBPR+ traffic, with explicit message exceptions including admi.024, camt.025, camt.052, camt.053, camt.054 and camt.060.
- Official requirement
ISO 20022 Standards (Swift ISO 20022 adoption programme) ↗ — Swift · Cross-border payments migration and exceptions-and-investigations roadmap
Do not generalise the payment-instruction deadline to every FIN message. Swift publishes differentiated NAK, contingency-conversion, reporting, initiation and exceptions-and-investigations treatment.
- Official requirement
Swift Standards MT (annual standards releases) ↗ — Swift · MT101, MT103, MT192, MT195, MT196, MT199, MT900/910/940/941/942/950
Full field-level specifications live in the Swift Knowledge Centre User Handbook behind a swift.com login. Coexistence for in-scope FI-to-FI payment instructions ended on 22 November 2025, but treatment differs by MT: some instructions are NAKed and selected messages can enter temporary, chargeable contingency conversion. Reporting, initiation, investigations and correspondence follow separate roadmaps.
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
What this simplifies: One serial correspondent route, one corporate account per side, and representative exception paths. The lifecycle is a teaching model, not a single mandatory choreography for every bank or service. All parties, accounts, amounts, and references are fictional.
Used wherever diagrams, scenarios, figures, or example values are didactic constructions rather than sourced facts; every such use carries a simplifications disclosure. All people, companies, banks, and list entries in examples are fictional.