This is a long, reference-depth piece by design. Use the Table of Contents below to jump straight to the flow you need, or read it start to finish if you are building the mental model for the first time.

Why Every Payments Professional Needs to Know the ISO 20022 Payment Lifecycle

If you work in payments, the ISO 20022 payment lifecycle is the map you keep reaching for. Every cross-border payment you will ever trace, whether it completes cleanly, gets rejected, comes back as a return, or gets pulled mid-flight, moves through the same small set of message types, in the same handful of shapes. Once you can see those shapes, you stop guessing and start reading.

This guide builds that map from the ground up, using CBPR+ as the base standard, since it is the version of ISO 20022 that actually governs cross-border payment messaging on the SWIFT network today. We start with a single question, what is a payment? and by the end we have covered the straight-through happy path, every point a payment can be rejected, how a payment gets cancelled mid-flight, what changes when the payer is a bank instead of a customer, the two ways cover funds move, direct debit in both directions, and the reference and administrative messages that sit around the edges of every flow.

For a refresher on the fundamentals before you dive in, see Payment Life Cycle – Banking Transaction, which covers the broader banking transaction life cycle this guide builds on.

The nine parts of this guide, in the order most people find easiest to build the mental model.

Part 0: Foundations, How to Read Every Flow in This Guide

Before we get into any payment flow, we need a shared language. This part sets up the actors, the diagram conventions, and the tracking overlay that every other part in this guide assumes you already know. It is worth reading first even if you are tempted to skip to a specific flow.

What Is a Payment, and Who Is Always Involved?

At the simplest level, a payment moves value from a Debtor to a Creditor, through their respective banks. For background on this fundamental definition, see What is a payment, its brief evolution and key elements.

Every payment, at its core, is two agents moving value on behalf of two principals.

The Seven-Actor Canvas

Every flow in this guide is drawn on the same seven lifelines. Once you know these seven, you can read any diagram that follows.

• Debtor and Creditor – the underlying parties. A retail customer or corporate for customer-initiated payments, or a bank itself when the flow is FI to FI.
• Debtor Agent and Creditor Agent – the banks that actually hold the Debtor’s and Creditor’s accounts.
• Sender Correspondent and Receiver Correspondent – the correspondent banks (also called as intermediary banks) that connect Debtor Agent and Creditor Agent when they have no direct relationship with each other. Longer real chains are possible; we use one on each side as the representative case throughout.
• PMI (Payment Market Infrastructure) – a clearing or settlement system, an RTGS or ACH type rail, that the two correspondents (Debtor agent and Creditor Agent in simple flows) may use to actually exchange funds instead of, or alongside, a direct account relationship.

For a full breakdown of every party that can appear in an ISO 20022 message, including roles this guide does not use, see Detailed Explanation of ALL Agents and Parties involved in an ISO Payment Message. And for the mechanics behind why a Sender Correspondent and Receiver Correspondent exist at all, see Understanding Correspondent Banking: A Comprehensive Guide.

The below visual represents the same basic payment flow in a serial format

The PMI: Present, but Transparent

The PMI appears in every diagram, but it stays in the background on purpose. From a message-flow point of view, the PMI is mostly a pass-through. It settles funds between the two correspondents, but it does not originate a new business message in the CBPR+ chain. We keep it visible so you always know where settlement is happening, without unpacking domestic clearing internals in every single flow.

For the fuller picture of how a payment instruction becomes final settlement, see From Payment Instruction to Finality: Understanding Clearing and Settlement.

🚩 Where useful, we mention how a step compares to a generic domestic payment system, purely for orientation. This guide is not a domestic-scheme guide, and no explanation here is tied to a specific country’s infrastructure.

Reading the Diagrams: Red vs. Black

Every arrow in every diagram is colour-coded:

• Red – mandatory for that scenario. This is the backbone the flow is teaching.
• Black – optional. It may not happen at all, for any reason: a pre-agreed bilateral arrangement between two banks, a conditional outcome that only fires down one branch of a decision, or simply a message not required for straight-through processing. We do not sub-categorise why a black arrow is optional in the legend itself; the surrounding text always explains it.

The gpi Tracker

SWIFT’s gpi Tracker runs as an overlay across the correspondent banking chain, giving real-time visibility into where a payment stands. Two messages drive it, and they come from the SWIFT gpi rulebook, not the core ISO 20022 pain, pacs, or camt catalogue:

• trck.001 (Payment Status Tracker Update) – sent to the Tracker by whichever agent has just finished processing a leg of the payment.
• trck.002 (Payment Status Tracker Report) – broadcast from the Tracker back to every agent upstream that needs visibility.

The rule that repeats across every flow in this guide: an agent updates the Tracker mandatorily after it has finished its own part of the job, meaning it has acknowledged what it received, finished processing the payment instruction and forwarded it onward if it is an intermediary. It can report on bare receipt which is optional but has to report after the process. (Multiple updates is possible). For the final agent, there is no forwarding step, so it reports its status after the payment processing is finished after acknowledging, then notifies the customer.

Note: The above rule mentioned is for the mandatory tracker update. A bank can send multiple intermediary updates when it needs more time to process the payment instruction.

Separately, large corporates can track a payment’s journey visually through a Tracker GUI. This is a different channel entirely from the trck.001 and trck.002 messages, which stay strictly bank to bank.

The final canvas: seven lifelines, a transparent PMI, and the gpi Tracker overlay above the correspondent chain.

Scope of This Guide

• Built on CBPR+ as the base standard for cross-border ISO 20022 messaging.
• Covers the full core payment lifecycle: credit transfers, rejects and returns, cancellations, FI to FI payments, Cover and Advice methods, direct debits, and reference and administrative messaging.
• Cheque-related messages are out of scope.
• camt.110 and camt.111, Investigations, are covered in Part 7, separate from the payment-cancellation messages, camt.055, camt.056, and camt.029, they are sometimes confused with.
• Mandate and authorisation messages for direct debits exist only at the domestic-scheme level, not in CBPR+, and are mentioned only in passing.

Part 1: The Backbone, STP Happy Path

Every payment lifecycle has an ideal version of itself, the path where nothing needs a human and nothing gets questioned. That is Straight-Through Processing, or STP: every message is machine-processed end to end, with no manual intervention at any hop. This is the backbone every other flow in this guide is measured against.

What Happens in a Straight-Through Payment?

Northwind Traders (Debotr) instructs its bank, Meridian Bank, the Debtor Agent, to pay a supplier, Ridgeline Supplies (Creditor), who banks with Crestline Bank, the Creditor Agent. Meridian and Crestline do not hold accounts with each other directly, so the payment routes through Atlas Bank, the Sender Correspondent, and Harbor Bank, the Receiver Correspondent, with a PMI sitting transparently between them.

Step 1 to 2: Initiation

pain.001 (Interbank Customer Credit Transfer Initiation) – this is the customer’s trigger to initiate a payment, sent to the bank where the customer holds its account. Northwind sends this to Meridian Bank. See What Is PAIN.001? for the full field-level walkthrough. Meridian responds with pain.002 (Interbank Customer Payment Status Report) – the bank’s acknowledgment back to the customer, confirming the instruction was received and telling the customer its status. See PAIN.002 Explained for the full guide.

Step 3: The First Leg

pacs.008 (Financial Institution to Financial Institution Customer Credit Transfer) – the actual interbank payment message, carrying the customer’s payment obligation from one bank to the next until it reaches the beneficiary’s bank. Meridian sends this to Atlas Bank. See pacs.008 Initiation Explained for how this message is actually assembled inside a bank.

Step 4: Debit Notification, and a Rule Worth Internalising Early

camt.054 (Bank to Customer Debit/Credit Notification) – a real-time notice tied to one specific transaction. Immediately after sending the pacs.008, Meridian notifies Northwind that the account has been debited, before Atlas Bank has even acknowledged receipt. Meridian books its accounting entry the moment it has a network acknowledgment for the pacs.008, not when it hears back from Atlas. Banks post based on their own control point, the network ACK, not a counterparty’s confirmation. This single rule explains a lot of sequencing that would otherwise look out of order across this guide.

Step 5: Acknowledgment

pacs.002 (Financial Institution to Financial Institution Payment Status Report) – one bank telling another bank how it processed a message it just received. Atlas replies to Meridian. This step is optional in practice, many correspondent relationships do not require it for every leg, so it is pre-agreed rather than mandatory. See The Search for F21’s Replacement for how payment acknowledgements evolved into this message.

Step 6: Through the PMI

Atlas forwards the pacs.008 to Harbor Bank, either directly through a Nostro or Vostro relationship, or through a shared PMI. Either is possible. From here on, every flow in this guide draws this as one arrow between correspondents, and this explanation is the reference for what can sit underneath it.

Step 7: Atlas Reports to the Tracker

Now that Atlas has acknowledged the previous leg and forwarded the payment onward, it sends trck.001 to the gpi Tracker. The Tracker immediately broadcasts trck.002 back to Meridian, upstream in the chain.

Step 8 to 9: Second Leg

Harbor optionally acknowledges Atlas with pacs.002 at step 8, then forwards the pacs.008 to Crestline Bank at step 9, the final leg.

Step 10: Harbor Reports to the Tracker

Same pattern: acknowledge, process, forward, then report. The Tracker broadcasts trck.002 to both Atlas and Meridian, so everyone upstream now has visibility into this second leg too.

Step 11 to 12: Final Acknowledgment and Tracker Update

Crestline acknowledges Harbor with pacs.002 at step 11. As the final agent, Crestline has no further leg to forward, so once it has acknowledged Harbor, completes the internal processing of the payment by crediting the creditor account and then it reports its status directly at step 12. The Tracker broadcasts this all the way back to Harbor, Atlas, and Meridian, completing the chain’s visibility.

Step 13 to 14: Completion

Crestline credits Ridgeline’s account and sends camt.054 (Bank to Customer Debit/Credit Notification) – the credit notification, followed eventually by a camt.053 statement entry.

Note:

• The Statements are not tied to the transaction processing. They are sent at regular intervals like intraday, end of day on all the transactions that happen between every interval.
• Statements are sent by Account Servicing FI to Account Owner (irrespective of whether the Account Owner is a retail corporate or another FI.)

The full STP happy path, fourteen steps, no exceptions.

How Does the GPI Tracker Actually Decide Who Reports What?

The pattern across the whole flow: any bank that receives a payment first does its initial validations, and once those pass, sends a Status Report telling its sender “I am taking over this payment now.” It then processes the payment and forwards it to the next agent. After forwarding, it updates the Tracker to say “I completed my processing and sent the payment onward.” If the agent is the final one in the chain, like Crestline here, it credits the beneficiary instead of forwarding, then updates the Tracker to say it finished the payment. Different stages use different status codes to say this; we cover the codes below without getting into every nuance of when each specific code applies.

Statements, Precisely

• camt.054 (Bank to Customer Debit/Credit Notification) – an individual debit or credit notification, tied to one specific transaction, sent in real time.
• camt.052 (Bank to Customer Account Report) – an intraday, interim account report, a snapshot of activity during the day.
• camt.053 (Bank to Customer Statement) – the definitive end-of-day statement, the account’s formal record for that business day.

For a retail customer without ISO-message capability, camt.054’s real-time role is typically played by an SMS, email, or app push notification instead. Statement reporting is also not limited to the two customer-facing ends of the chain. camt.052 and camt.053 also flow between every account-servicing relationship along the way, Meridian to Atlas, Atlas to Harbor where a Nostro or Vostro relationship exists, and Harbor to Crestline, even though we do not draw every one of these in every diagram.

Key Takeaway

STP is not a separate message type. It is the absence of any exception. Rather it is the main message with field restrictions.

Every message here reappears throughout the rest of this guide; what changes in later parts is what happens when one of these steps does not go as planned.

Messages Introduced in This Part

Code	Name	Role
pain.001	Interbank Customer Credit Transfer Initiation	Customer’s instruction to their bank
pain.002	Interbank Customer Payment Status Report	Bank’s status ack/report to the customer
pacs.008	FI to FI Customer Credit Transfer	The interbank payment message itself
pacs.002	FI to FI Payment Status Report	Interbank status ack/report, optional per leg
camt.054	Bank to Customer Debit/Credit Notification	Real-time per-transaction notice
camt.052	Bank to Customer Account Report	Intraday account snapshot
camt.053	Bank to Customer Statement	Definitive end-of-day statement
trck.001	Payment Status Tracker Update	Agent to gpi Tracker, sent after ack and forward
trck.002	Payment Status Tracker Report	gpi Tracker to all upstream agents

Status Codes Introduced in This Part

Code	Meaning
ACSP	Accepted, forwarded, in progress. Reported by an intermediary after it acknowledges and forwards.
ACCC	Accepted, credit completed. Reported by the final agent once the beneficiary has been credited.

Part 2: When Things Go Wrong, Non-STP, Reject and Return

Not every payment sails through. This part covers what happens when a payment is rejected at three different possible points in the chain, and how the reversal propagates back to the Debtor once money has already moved.

Where Can a Cross-Border Payment Actually Get Rejected?

Same cast as Part 1: Northwind Traders, Meridian Bank, Atlas Bank, Harbor Bank, Crestline Bank. This time we follow three different places the payment could be turned away.

Rejection Point 1: At Meridian Bank, Before It Ever Leaves

Step 1, pain.001 arrives from Northwind. Step 1a, pain.002 RJCT, Meridian declines the instruction outright. The flow ends here. Since no pacs.008 was ever generated, this payment never touched the network. There is nothing for the gpi Tracker to have a record of, so no Tracker interaction happens at all.

The Payment Enters the Network

Step 2, pain.002, accepted this time. Step 3, pacs.008, Meridian sends the payment to Atlas Bank. Step 4, camt.054, Meridian notifies Northwind of the debit immediately, the same book-on-network-ACK rule from Part 1. This detail matters more here than in Part 1: Meridian debits before knowing whether the payment will ultimately succeed. If it is rejected further down the chain, that early booking is exactly why a reversal notice becomes necessary later.

Rejection Point 2: At Atlas Bank

Step 5a, pacs.002 RJCT, or step 5b, pacs.004 (Payment Return, the message that sends funds back that were already forwarded), Atlas rejects. One or the other, never both, decided by Atlas’s bilateral relationship with Meridian. Step 6a, trck.001 and trck.002, Atlas reports the rejection to the Tracker using an RJCT status code, not ACSP, since this is terminal, not in progress. Step 7a, pain.002 RJCT, Meridian informs Northwind. Step 8a, camt.054, reversal notice, undoing the earlier debit. Flow ends here.

No Rejection at Atlas: The Payment Continues

Step 5, pacs.008, Atlas forwards to Harbor Bank. Step 6, trck.001 and trck.002, Atlas reports ACSP, accepted, forwarded, in progress, to the Tracker, only now, after it has both acknowledged and forwarded. Step 7, pacs.002, Harbor’s optional ack back to Atlas. Step 8, pacs.008, Harbor forwards to Crestline. Step 9, trck.001 and trck.002, Harbor reports ACSP.

Rejection Point 3: At Crestline Bank

Step 10a, pacs.002 RJCT, or step 10b, pacs.004, same either-or logic, this time governed by the Harbor to Crestline relationship. Step 11, trck.001 and trck.002, Crestline reports RJCT, broadcast to every agent in the chain.

The Return, Propagating Backward

This is the crucial mechanical detail. Step 12, pacs.004: if Crestline sent the return directly at step 10b, Harbor simply relays it unchanged to Atlas. If Crestline only sent a status rejection at step 10a, Harbor must itself originate a new pacs.004 to actually unwind the funds it already forwarded. Step 13, pacs.002, Atlas’s optional ack of that return. Step 14, pacs.004, Atlas relays the return backward to Meridian, by this point it is already a real value message, so this leg is a straightforward relay regardless of how it originated. Step 15, pacs.002, Meridian’s optional ack.

Step 16, pain.002 RJCT, then step 17, camt.054, reversal notice, then step 18, camt.053 or camt.052 statement, Meridian closes the loop with Northwind. No further explicit Tracker update is needed during this backward propagation; the network already tracks the return implicitly once RJCT has been posted.

Three rejection points, one consistent either-or rule at each one.

Why Does Meridian Notify the Customer Before Knowing If the Payment Will Succeed?

Notice what did not change from Part 1: Meridian still books the debit unconditionally at step 4, exactly as it did in the STP flow. Non-STP is not a different booking philosophy, it is the same philosophy, plus the machinery, steps 7a and 8a, or 16 through 18, needed to undo that booking when things do not complete.

Key Takeaway

A rejection is either-or at every hop: a status message or a value return, never both, decided by the bilateral relationship between the two agents at that specific point. Once RJCT is posted anywhere in the chain, the network blocks any further forward movement; the only path left is the return, propagating hop by hop back to origin.

Messages Introduced in This Part

Code	Name	Role
pacs.004	Payment Return	Returns funds already forwarded

Status Codes Introduced in This Part

Code	Meaning
RJCT	Rejected, terminal negative status, carries a reason code

🚩 Note on depth: pacs.004 has a richer taxonomy than shown here, including complete versus incomplete returns, partial returns, refunds, and cover-method-specific variants. The core either-or mechanic covered above applies consistently across all of them.

Part 3: Stopping a Payment, Cancellation, Serial vs. SRP

Once a payment is moving, can it be pulled back? This part covers two ways to try: the traditional hop-by-hop route, and a faster, Tracker-mediated alternative built to close a real timing gap in the traditional method.

Can You Actually Cancel a Cross-Border Payment Once It Has Left the Bank?

Northwind’s payment has already left Meridian Bank and reached Harbor Bank, the Receiver Correspondent, though the position does not matter; the payment could be sitting at any agent in the chain and the mechanics would not change. Steps 1 to 3, pain.001, pacs.008, pacs.008, the normal path so far, exactly as in Part 1.

Requesting the Cancellation

camt.055 (Customer Payment Cancelation Request) – Northwind asks Meridian to cancel the payment. Step 5, camt.029 (Resolution of Investigation) – Meridian may send an interim response back to Northwind, coded PDCR, Pending Cancellation Request, more time needed. This is optional and black: a genuine acknowledgment that the case is open, not a final answer. Where a reason is included, it uses a Cancellation Status Reason code, for example RQDA, meaning debit authority has been requested from the Creditor.

Scenario A: Normal Serial Cancellation

Step 6, camt.056 (FI to FI Cancellation Request) – Meridian forwards the request to Atlas Bank. Step 7, camt.056, Atlas forwards it on to Harbor Bank, wherever the payment currently sits. Step 8, camt.029, PDCR, Atlas may send its own interim back to Meridian, same optional logic. Step 9, camt.029, Harbor Bank, holding the payment, makes the actual decision and reports it: CNCL, cancelled as requested, or RJCR, cancellation rejected, the payment proceeds. This is mandatory and red, it is the actual answer. Step 10, camt.029, relayed back to Meridian. Step 11, camt.029, relayed to Northwind.

Step 12, if the outcome is CNCL: the investigation concludes, and a Payment Return, pacs.004, may follow if funds already moved, camt.054 to Northwind, pacs.004 between the agents, or pacs.004 versus pacs.002 RJCT depending on relationship, mirroring the return mechanics from Part 2. If the outcome is RJCR: none of this fires, the original payment simply continues to Crestline Bank as normal. That is why step 12 is optional and black, it depends entirely on which way the decision went.

Scenario B: Cancellation via SRP, Stop and Recall Payment

Instead of hop-by-hop relay, Meridian can route through the gpi Tracker directly.

Step 6a, camt.056, Meridian sends the cancellation straight to the Tracker, not to Atlas. Step 7a, camt.056, the Tracker routes it directly to Harbor Bank, the agent actually holding the payment, skipping Atlas entirely. Step 8a, the Tracker places the payment on a cancellation hold. This is the real advantage of SRP: even if Harbor mistakenly forwards the payment to Crestline before processing the recall internally, the network itself intercepts and stops it before it reaches the final agent.

Step 9a, camt.029, Harbor’s decision, CNCL or RJCR, goes back to the Tracker. Step 10a, camt.029, broadcast directly back to Meridian, again bypassing Atlas. Step 11a, the same unwind logic as step 12, conditional on the decision.

🚩 An interim PDCR response is genuinely possible on the SRP path too, if Harbor needs more time before answering the Tracker. It is not drawn in the diagram to avoid clutter, but it is a real, documented possibility.

Serial cancellation travels hop by hop. SRP routes directly to whichever agent holds the payment, and backs that up with a network-level stop.

Why Does SRP Exist If Serial Cancellation Already Works?

The Serial method has a structural gap: camt.056 has to physically travel hop by hop, so there is a race condition. By the time it reaches Harbor Bank, Harbor may have already forwarded the payment to Crestline, making the cancellation too late. SRP closes this two ways: routing directly to whichever agent holds the payment, and backing that up with a network-enforced stop that works even against operator error. SRP is not mandated today, but SWIFT is moving toward mandating it specifically to close this gap.

This same Serial-versus-SRP mechanic applies identically when cancelling Cover, FI to FI, or Advice-initiated payments; the underlying pattern does not change with the payment type, only which message initiated the original payment.

Two Code Families, Not One

This is worth stating clearly, because it is an easy mix-up. camt.029’s own Confirmation codes, what the cancellation investigation itself concludes with, are CNCL, PDCR, and RJCR. The gpi Tracker’s own status codes, what trck.001 and trck.002 report about overall payment progress, are ACSP, ACCC, and RJCT. These look conceptually parallel, accepted, pending, rejected, but they are not interchangeable.

Key Takeaway

PDCR marks “still deciding.” CNCL and RJCR mark the actual outcome of the investigation itself. SRP’s real innovation is not just speed, it is a network-level safety net that prevents the exact race condition the Serial method is structurally exposed to.

Messages Introduced in This Part

Code	Name	Role
camt.055	Customer Payment Cancelation Request	Customer asks their bank to cancel
camt.056	FI to FI Cancellation Request	Interbank relay of the cancellation
camt.029	Resolution of Investigation	Interim, PDCR, or final, CNCL/RJCR, response

Status Codes Introduced in This Part

Code	Meaning
CNCL	Cancelled as requested, concludes the investigation, a Payment Return may follow
PDCR	Pending, under investigation, carries a reason such as RQDA
RJCR	Rejected, concludes the investigation, must carry a reason

Part 4: When the Payer Is a Bank, FI to FI Payments

What Changes When Both Ends of a Payment Are Banks?

Every flow so far has used the same seven-actor canvas from Part 0. FI to FI payments need a variant of it, built up in five steps.

Building the FI to FI Canvas

Baseline. The familiar canvas: Debtor and Creditor as customers, gpi Tracker shown, Sender Correspondent and Receiver Correspondent as named correspondents.

Debtor and Creditor become banks. Same seven lifelines, but both ends are now Financial Institutions. This is the defining feature of FI to FI: every actor in the chain is a bank.

gpi Tracker removed. Not because tracking does not exist for FI to FI, but because it runs under a separate, optional service called gFIT, gpi for Financial Institutional Transfers, the same underlying concept as the Tracker in Parts 1 to 3, just not mandated for this payment type, so we do not repeat it here.

Sender Correspondent and Receiver Correspondent become Intermediary 1 and Intermediary 2. Those names only make sense when Debtor Agent originates the first bank-to-bank leg, as it does in a customer payment. Here the Debtor, itself an FI, initiates the transfer directly, so there is no sender role to assign to Debtor Agent. See Correspondent Bank vs Intermediary Bank for the fuller distinction between these two roles.

Intermediaries removed. Long FI to FI chains are rare in practice; dropping them keeps focus on the messages. Final working canvas: Debtor, Debtor Agent, PMI, Creditor Agent, Creditor.

The Flow

pacs.009 (Financial Institution Credit Transfer) – the interbank payment message used when the paying party is itself a bank, not a retail or corporate customer. This is the message throughout, not pacs.008, used precisely because the Debtor side is itself an FI rather than a customer.

Scenario 1: Direct Accounting Relationship, No PMI

Steps 1 to 2, pacs.009 and pacs.002, Debtor to Debtor Agent. Steps 3 to 4, Debtor Agent and Creditor Agent settle directly through their own Nostro or Vostro relationship, pacs.009 and pacs.002 pass straight between them, no PMI involved.

The crucial final-leg branch: whether Creditor Agent sends step 5a, camt.054, camt.053, or camt.052, or step 5b, pacs.009, plus step 6b, pacs.002, depends entirely on who physically holds the settlement-currency account. If Creditor Agent holds the Creditor’s account, it just notifies, step 5a, the books are already updated. If the Creditor itself holds its own account for that currency, Creditor Agent is merely a chain connector, Creditor Agent must forward the actual pacs.009, step 5b, and the Creditor, itself an FI, acknowledges with pacs.002, step 6b. These are alternate endings, not sequential steps.

Scenario 2: Via PMI or Clearing

Step 3, pacs.009 hops through PMI, Debtor Agent to PMI to Creditor Agent. Critically, step 4, pacs.002 comes back from PMI itself, not Creditor Agent. Settlement confirmation happens at the clearing or RTGS rail, not at the bilateral bank level.

Steps 3a and 4a, payment splitting. When the settlement amount exceeds a scheme-agreed clearing threshold, the sending bank splits it into smaller child payments, each carrying a new UETR and a split Service Level indicator, while the original UETR is retained only in the splitting bank’s internal mapping, never published to the network. This is a formally documented PMI and clearing-system behaviour, confirmed in the CBPR+ reference material, applicable at any PMI hop across this entire guide, not unique to FI to FI. See Payment Identifiers in ISO 20022 for the full picture of how identifiers like the UETR are created and maintained.

Same final-leg alternates, 5a versus 5b and 6b, close out Scenario 2 as well.

Two accounting relationships, two settlement paths, one recurring final-leg question.

Why Is the Accounting Relationship the Hidden Engine of CBPR+ Flows?

This is worth its own section, because the same underlying fact, who holds whose account, and how, quietly drives three separate things across this entire guide.

• Settlement Method: a direct Nostro or Vostro relationship, INDA or INGA, versus settlement via a clearing system, CLRG, versus the correspondent-chain cover method, COVE. For the full picture of what these accounts actually are, see Nostro, Mirror Nostro, Vostro, and Loro Accounts.
• Return behaviour: the either-or pacs.002 RJCT versus pacs.004 choice from Part 2 exists precisely because of this relationship at each hop, not as an arbitrary bank preference.
• Final-leg communication: notify with CAMT versus instruct with a forwarded payment message, as just shown above, and something that resurfaces identically at the final leg of Cover and Advice payments in Part 5.

Key Takeaway

FI to FI payments reuse everything structurally, the canvas, the message logic, even the return mechanics, but strip away the customer layer and the mandated Tracker. What is left exposes something that was quietly operating underneath every prior flow too: the accounting relationship between two agents, not the message type, is what actually decides how a payment settles.

Messages Introduced in This Part

Code	Name	Role
pacs.009	Financial Institution Credit Transfer	FI-initiated interbank payment

Terms Introduced in This Part

Code	Meaning
INDA / INGA	Settlement via direct Nostro/Vostro relationship
CLRG	Settlement via a clearing system/PMI
COVE	Settlement via the cover method (correspondent chain)

Part 5: Two Ways to Move Money, Cover vs. Advice

What Is the Difference Between the Cover Method and the Advice Method?

Neither flow here needs new canvas building, each reuses one already established. Cover runs on the customer canvas from Part 1, Debtor, Debtor Agent, Sender Correspondent, PMI, Receiver Correspondent, Creditor Agent, Creditor. Cover is a customer-flow method. Advice runs on the FI to FI canvas from Part 4, Intermediary 1 and Intermediary 2 in place of the correspondents. Advice is an FI-flow method.

Cover Process: Customer Flow

pain.001 (Interbank Customer Credit Transfer Initiation) – Northwind sends this to Meridian Bank.

The direct message. Meridian sends pacs.008 (Financial Institution to Financial Institution Customer Credit Transfer) – straight to Crestline Bank, a single arrow that bypasses the correspondent chain at the message level entirely. Crestline optionally acknowledges with pacs.002. This direct message is the advice: Crestline now knows a payment is coming and can, at its own risk appetite, credit the supplier immediately, or wait for the actual funds to arrive.

The funding leg begins, in parallel. Meridian sends pacs.009 (cov) (Financial Institution ‘Cover’ Credit Transfer) – to Sender Correspondent, this is the real money, moving to actually reimburse Crestline. The direct-message step and the funding-leg step fire close together, not one gated on the other; the direct message’s optional ack is not a precondition for the funding leg starting.

Sender Correspondent forwards the pacs.009 (cov) to Receiver Correspondent, either directly through their own account relationship, or via PMI, with PMI issuing its own ack, exactly the same either-or established in Part 4.

The COV Message’s Own Final Leg: A Role Mapping Worth Getting Right

Within this specific pacs.009 (cov) message, Receiver Correspondent is playing the role the message calls “Creditor Agent,” and Crestline Bank, the canvas’s Creditor Agent, is playing the role the message calls “Creditor,” the endpoint of this message’s own journey. So the same accounting-relationship logic from Part 4 applies, but between these two: either Receiver Correspondent just notifies Crestline with camt.054, camt.053, or camt.052, or forwards the actual pacs.009 (cov), acknowledged with pacs.002.

The Full Chain’s True Final Leg

Once the covering funds have reached Crestline Bank, Crestline notifies the real, underlying Creditor, Ridgeline Supplies, with camt.054, camt.053, or camt.052. Since Ridgeline is a retail or corporate customer, not an FI, this step is a straightforward notification only, there is no forwarded-payment-message alternative the way Part 4 describes, because a customer is not equipped to receive or process a pacs.009. This mirrors the simple notification pattern from Part 1’s STP flow, not Part 4’s FI-to-FI branching.

Once reconciled, Crestline matches the incoming pacs.009 (cov) against the earlier direct pacs.008, by UETR or end-to-end reference, closing out any risk it took on if it credited the supplier early.

Advice Process: FI Flow

Debtor is itself an FI and initiates directly with pacs.009 (Financial Institution Credit Transfer) – no customer layer at all.

Debtor Agent sends pacs.009 (adv) (Financial Institution ‘Advice’ Credit Transfer) – directly to Creditor Agent, pre-advising it of the incoming payment ahead of settlement, useful for liquidity and position management across time zones. Creditor Agent optionally acknowledges with pacs.002.

In parallel, Debtor Agent sends a plain pacs.009, no ADV tag, since there is no underlying customer pacs.008 to reconcile against, to Intermediary 1. Intermediary 1 forwards to Intermediary 2, direct or via PMI, same pattern as Cover.

The funding message’s own final leg follows the same structure as Cover: within this pacs.009 message, Intermediary 2 plays the message’s own Creditor Agent role, and Creditor Agent, canvas, plays the message’s own Creditor role. Either camt.054, camt.053, or camt.052, or a forwarded pacs.009 acknowledged with pacs.002, governed by the Intermediary 2 to Creditor Agent accounting relationship.

Creditor Agent then notifies the real Creditor with camt.054, camt.053, or camt.052. Since Advice’s Creditor is itself an FI here, the accounting-relationship alternate from Part 4 genuinely could apply at this final step too, just as it did at the message’s own final leg. We do not redraw or re-explain that branching a third time here, since it is already fully covered in Part 4.

Cover Process: a direct advice plus a parallel funding leg, customer flow.

Advice Process: the same shape, FI flow, no COV tag on the funding leg.

The Defining Difference

	Cover	Advice
Initiated by	Customer, pain.001	FI itself, pacs.009
Direct message	pacs.008	pacs.009 (adv)
Funding leg	pacs.009 (cov)	plain pacs.009
Purpose of direct message	Let Creditor Agent credit sooner, at its own risk	Pre-advise for liquidity and position management

Two Final Legs, Not One

Every Cover or Advice flow actually has two distinct final legs, easy to conflate: the funding message’s own endpoint, where Receiver Correspondent or Intermediary 2 hands off to Creditor Agent using the message’s own internal role names, and the full payment chain’s true endpoint, Creditor Agent reaching the real Creditor. The accounting-relationship rule from Part 4 governs both message-final-legs in Cover and Advice alike. But it only governs the full chain’s final leg when the ultimate Creditor is itself an FI, true for Advice, not for Cover. For Cover, the full chain’s final leg is a plain notification, matching Part 1’s STP pattern instead.

Key Takeaway

Cover and Advice are the same underlying pattern, a direct notice plus a parallel funding leg, applied to two different origins. The COV tag is the structural marker; the two-final-legs distinction is what keeps the mechanics precise once you look closely at where each message actually ends.

Messages Introduced in This Part

Code	Name	Role
pacs.009 (cov)	Financial Institution ‘Cover’ Credit Transfer	Funding leg reconciling against an underlying pacs.008
pacs.009 (adv)	Financial Institution ‘Advice’ Credit Transfer	Pre-advise to Creditor Agent ahead of settlement

Part 6: Pulling Instead of Pushing, Direct Debit

How Does a Direct Debit Actually Move Money If the Creditor Starts It?

Every flow so far has been the Debtor pushing money out. Direct Debit reverses the initiator: the Creditor requests a collection, and once agreed, the funds still move using the same mechanics already built in this guide.

Customer Direct Debit

Steps 1 to 2, the supplier, Ridgeline Supplies, the Creditor, sends pain.008 (Interbank Customer Direct Debit Initiation) – to Crestline Bank, requesting a collection from Northwind. Crestline acknowledges with pain.002.

Step 3, Crestline sends pacs.003 (Financial Institution to Financial Institution Customer Direct Debit) – the interbank collection request, directly to Meridian Bank, bypassing the correspondent chain at the message level, the same direct-message pattern seen in Part 5’s Cover method.

Step 4, Meridian acknowledges with pacs.002. Step 5, Meridian originates pacs.008, a genuine credit-push, to Atlas Bank, physically delivering the collected funds toward Crestline. Step 6, Meridian notifies Northwind with camt.054, the debit notice, same book-on-send rule from Part 1.

Steps 7 to 11, the funds travel forward exactly as in the Part 1 STP backbone, Atlas to Harbor to Crestline, with optional pacs.002 acks at each leg. Steps 12 to 13, Crestline notifies the supplier with camt.054, followed by camt.053 and camt.052 statements at both ends.

🚩 The diagram here specifically depicts the case where funds genuinely need to travel to reach Crestline, the DD-sending bank. Getting there can happen one of two ways: a simple book transfer, if Meridian directly holds Crestline’s account, closing out with a single pacs.002 carrying status ACSC, or an actual payment message that Meridian originates, exactly as shown in the diagram.

The collection request travels one way, the actual funds travel the other.

Why Does the Initiating Message Travel in the Opposite Direction From the Funds?

The initiating message, pacs.003, travels Creditor Agent to Debtor Agent. The actual funds travel the opposite way, Debtor Agent to Creditor Agent. Once Meridian accepts the collection request, the funding leg is functionally identical to the STP backbone from Part 1, the direct debit’s settlement leg is a credit transfer wearing a different hat.

FI to FI Direct Debit

Steps 1 to 2, here it is the Creditor itself, an FI, that initiates, sending pacs.010 (Financial Institution Direct Debit) – directly to Debtor Agent, with no Creditor Agent involved at origination at all. Debtor Agent acknowledges with pacs.002. This mirrors exactly how, in Part 4, the FI Debtor initiated pacs.009 directly with no pain.001 precursor; here the FI Creditor initiates pacs.010 directly with no pain.008 precursor, since there is no customer layer on either side.

Steps 3 to 4, Debtor Agent originates pacs.009 to Intermediary 1, and notifies its own Debtor with camt.054. Steps 5 to 6, the funds travel through Intermediary 1 to Intermediary 2 to Creditor Agent, same PMI-transparent pattern as every FI to FI flow. Steps 7 to 8, Creditor Agent notifies the Creditor with camt.054, then camt.053 and camt.052 statements close both ends.

The FI Creditor initiates directly; no customer layer on either end.

What Happens When a Direct Debit Is Rejected?

Two entirely separate failure points, and it matters which one you mean.

• The collection request itself is declined: reported via pacs.002 at bank level or pain.002 at customer level. Because this happens before any funding pacs.008 or pacs.009 has been originated, the funds flow never starts at all, the same logic as Rejection Point 1 in Part 2.
• The funding leg, once accepted, is rejected downstream: this follows the exact Non-STP path from Part 2, with no direct-debit-specific variant. This applies identically to FI Direct Debit, pacs.010, too; it is not re-covered as its own flow, since the mechanics do not change based on what triggered the original credit-push.

Where Do Direct Debit Mandates Fit In?

Real-world direct debits depend on a pre-existing mandate, the Debtor’s authorisation for the Creditor to collect. This exists only as domestic-scheme-specific messaging; CBPR+ has no message representing it. It is operationally essential for direct debit to function at all, but it does not appear anywhere in this guide’s diagrams.

Key Takeaway

Direct Debit does not introduce new settlement mechanics, it introduces a new initiator. Everything downstream of acceptance, the funding leg, the statements, the rejection handling, is the same machinery this guide has already built, just triggered from the opposite end of the chain.

Messages Introduced in This Part

Code	Name	Role
pain.008	Interbank Customer Direct Debit Initiation	Customer’s collection request to their own bank
pacs.003	FI to FI Customer Direct Debit	Interbank collection request, customer-initiated
pacs.010	Financial Institution Direct Debit	Interbank collection request, FI-initiated

Status Codes Introduced in This Part

Code	Meaning
ACSC	Settlement completed via direct book transfer, functionally equivalent to ACCC in a different message context

Part 7: Beyond the Payment, Reference and Administrative Messages

What Other CBPR+ Messages Exist Besides the Ones That Move Money?

Not every CBPR+ message moves money. This part covers the messages that inform, request, or administer around a payment, each shown as an independent, self-contained scenario rather than one continuous story, restarting its own numbering.

Notice to Receive

camt.057 (Notification to Receive) – the Creditor pre-advises their own bank, Crestline, of an expected incoming payment. Step 2, camt.025 (Receipt) – Crestline issues a Receipt, accepting or rejecting the notification. Step 2, PACSXX, the actual payment arrives, pacs.008 or pacs.009 depending on scenario, from Harbor Bank. Step 3, camt.054, camt.053, camt.052, standard notification follows.

Separately: step 1, camt.057, step 2, camt.058 (Notification to Receive Cancelation Advice) – the Creditor cancels their earlier notification, again acknowledged with step 3, camt.025.

Charges

This mechanism activates when a payment carries Charge Bearer equal to DEBT, the Debtor pays all charges. It does not apply under CRED, SHAR, or SLEV, which do not require this interbank recovery messaging at all.

Steps 1 to 3, pain.001, pacs.008, pacs.008, the normal path. Step 4, camt.106 (Charges Payment Request) – Harbor Bank requests reimbursement for the processing charge it deducted, sent backward to Atlas Bank. Step 5, camt.025, Atlas’s Receipt, accept or reject. Step 5, camt.106, Atlas forwards the request further back to Meridian Bank, since its own charge was not sufficient to settle it. Step 6, camt.025, Meridian’s Receipt. Steps 7 to 8, pacs.009, with a new UETR, quoting the Charge Identification in the End-to-End ID, Meridian settles the charge request, relayed forward to Harbor Bank, the original requestor.

Separately: step 4, camt.105 (Charges Payment Notification) – and step 5, camt.053 and camt.052, both sent Atlas Bank to Meridian Bank, Account Servicer to Account Owner. This is the simpler case: Atlas notifying Meridian of a charge it deducted directly, with no interbank recovery request needed. See Understanding Charge Codes in SWIFT Payments for the full picture of OUR, BEN, and SHA charge codes and how they map to DEBT, CRED, and SHAR in ISO 20022.

🚩 Not shown, but worth noting: a simple, non-forwarded version of the camt.106 request exists too, where the first agent asked can settle directly without relaying further. There is also a camt.106, Multiple Charges, variant for batch charge requests.

Investigations

camt.110 (Investigation Request) – Creditor Agent uploads a request to the gpi Tracker. Step 2, camt.110, the Tracker routes it directly to Atlas Bank, the agent that can actually answer, skipping Harbor Bank entirely. Step 3, camt.111 (Investigation Response) – Atlas’s answer goes back to the Tracker. Step 4, camt.111, broadcast directly back to Creditor Agent.

This pairing, Creditor Agent to Atlas Bank, is purely illustrative. camt.110 and camt.111 can fire between any two FIs in the chain. The underlying principle is identical to SRP from Part 3: the Tracker identifies which FI currently holds the answer and routes directly to it, bypassing intermediate agents.

🚩 A broader set of case-type reason codes exist for camt.110 and camt.111, for example CCNR, CONR, and UTAP, among others. This guide names them but does not decode each one; the detailed rulebook exists separately for readers who need it.

Other Messages

camt.060 (Account Reporting Request) – Meridian Bank, as Account Owner, requests a statement from Atlas Bank, the Account Servicer for that relationship. Atlas replies with the report, same Owner-to-Servicer, Servicer-to-Owner direction established in the Charges section above.

admi.024 (Notification of Correspondence) – Harbor Bank to Creditor Agent, a one-way, pre-agreed administrative message with no value movement, generic correspondence between agents.

Key Takeaway

These messages do not move money, but they carry weight in reconciliation, cost recovery, and case resolution, and several of them, camt.106’s forwarding, camt.110 and camt.111’s Tracker-mediated routing, reuse patterns this guide already established elsewhere, rather than introducing new mechanics of their own.

Everything covered in this part, on one canvas.

Messages Introduced in This Part

Code	Name	Role
camt.057	Notification to Receive	Pre-advise of an expected incoming payment
camt.058	Notification to Receive Cancelation Advice	Cancels an earlier camt.057
camt.025	Receipt	Accept/Reject response to a request
camt.105	Charges Payment Notification	Servicer notifies Owner of a deducted charge
camt.106	Charges Payment Request	Formal interbank charge-recovery request
camt.110	Investigation Request	Case query, routed via the Tracker
camt.111	Investigation Response	Answer to a camt.110, routed via the Tracker
camt.060	Account Reporting Request	Owner requests a statement from Servicer
admi.024	Notification of Correspondence	One-way administrative message

Part 8: Reference Appendix

The full lookup reference for everything covered across Parts 0 to 7, built for quick scanning, not narrative reading.

Full ISO 20022 CBPR+ Message Glossary

Code	Name	First Appears	Role
pain.001	Interbank Customer Credit Transfer Initiation	Part 1	Customer’s instruction to their bank
pain.002	Interbank Customer Payment Status Report	Part 1	Bank’s status ack to the customer
pacs.008	FI to FI Customer Credit Transfer	Part 1	Interbank customer payment message
pacs.002	FI to FI Payment Status Report	Part 1	Interbank status ack
camt.054	Bank to Customer Debit/Credit Notification	Part 1	Real-time per-transaction notice
camt.052	Bank to Customer Account Report	Part 1	Intraday account snapshot
camt.053	Bank to Customer Statement	Part 1	Definitive end-of-day statement
trck.001	Payment Status Tracker Update	Part 1	Agent to gpi Tracker
trck.002	Payment Status Tracker Report	Part 1	gpi Tracker to upstream agents
pacs.004	Payment Return	Part 2	Returns funds already forwarded
camt.055	Customer Payment Cancelation Request	Part 3	Customer asks their bank to cancel
camt.056	FI to FI Cancellation Request	Part 3	Interbank relay of the cancellation
camt.029	Resolution of Investigation	Part 3	Interim/final response to a cancellation
pacs.009 (core)	Financial Institution Credit Transfer	Part 4	FI-initiated interbank payment
pacs.009 (cov)	Financial Institution ‘Cover’ Credit Transfer	Part 5	Funding leg for a Cover payment
pacs.009 (adv)	Financial Institution ‘Advice’ Credit Transfer	Part 5	Pre-advise for an Advice payment
pain.008	Interbank Customer Direct Debit Initiation	Part 6	Customer’s collection request
pacs.003	FI to FI Customer Direct Debit	Part 6	Interbank collection request, customer-initiated
pacs.010	Financial Institution Direct Debit	Part 6	Interbank collection request, FI-initiated
camt.057	Notification to Receive	Part 7	Pre-advise of an expected incoming payment
camt.058	Notification to Receive Cancelation Advice	Part 7	Cancels an earlier camt.057
camt.025	Receipt	Part 7	Accept/Reject response to a request
camt.105	Charges Payment Notification	Part 7	Servicer notifies Owner of a deducted charge
camt.106	Charges Payment Request	Part 7	Formal interbank charge-recovery request
camt.110	Investigation Request	Part 7	Case query, routed via the Tracker
camt.111	Investigation Response	Part 7	Answer to a camt.110
camt.060	Account Reporting Request	Part 7	Owner requests a statement from Servicer
admi.024	Notification of Correspondence	Part 7	One-way administrative message

Status and Reason Code Glossary

gpi Tracker Status Codes (carried in trck.001/002)

Code	Meaning
ACSP	Accepted, forwarded, in progress
ACCC	Accepted, credit completed
RJCT	Rejected, terminal negative status, with reason code

camt.029 Confirmation Codes (a separate family, do not confuse with the Tracker codes above)

Code	Meaning
CNCL	Cancelled as requested, concludes the investigation
PDCR	Pending, under investigation, carries a reason, for example RQDA
RJCR	Rejected, concludes the investigation, must carry a reason

Direct Debit Specific

Code	Meaning
ACSC	Settlement completed via direct book transfer, functionally close to ACCC, different message context

Settlement Method Codes (describe how two agents settle, not a status)

Code	Meaning
INDA / INGA	Settlement via a direct Nostro/Vostro relationship
CLRG	Settlement via a clearing system/PMI
COVE	Settlement via the cover method, correspondent chain

Charge Bearer Codes

Code	Meaning
DEBT	Debtor bears all charges, the only code illustrated in this guide
CRED / SHAR / SLEV	Other charge-bearer arrangements, exist but not illustrated here

Investigation case-type codes (camt.110/111, named only, not decoded in this guide): CCNR, CONR, UTAP, among others.

Deliberately Out of Scope or Simplified

• Cheque-related messages, camt.107, camt.108, camt.109.
• Mandate and authorisation messages for Direct Debit, domestic-scheme specific, no CBPR+ representation.
• Additional pacs.004 variants, partial return, refund, complete/incomplete distinction, cover-already-returned; the core either-or mechanic covered in Part 2 applies throughout.
• camt.106, Multiple Charges, the bulk/batch variant of the mechanic shown in Part 7.
• G-series reason-code qualifiers on ACSP, for example G002, G003, G004.
• Domestic-scheme-specific implementations; the PMI is treated generically as a clearing/RTGS-type infrastructure throughout, never tied to a specific country’s system.
• pacs.010 Margin Collection, not found as a distinct documented use case; standard Direct Debit mechanics apply.

Cast of Characters, Recap

Role	Name Used	Introduced
Debtor / customer	Northwind Traders	Part 1
Debtor Agent	Meridian Bank	Part 1
Sender Correspondent	Atlas Bank	Part 1
PMI	Unnamed, generic	Part 0
Receiver Correspondent	Harbor Bank	Part 1
Creditor Agent	Crestline Bank	Part 1
Creditor / supplier	Ridgeline Supplies	Part 1
Intermediary 1 / 2	Used in place of Sender/Receiver Correspondent for FI to FI flows	Part 4

Common Mistakes When Reading ISO 20022 CBPR+ Flows

These are the mix-ups that surface most often once you start actually reading real flows, not the textbook version. Each one below is a genuine, specific trap, not generic advice.

• Assuming a PMI always confirms settlement itself. Most of the time the PMI is a transparent pass-through and the two correspondent banks acknowledge each other directly. It only issues its own pacs.002 when the correspondents are actually linked through it as a clearing rail rather than a direct Nostro or Vostro relationship.
• Assuming a rejection always produces both a status message and a return. It never does. Every rejection point in this guide is either-or, a pacs.002 RJCT or a pacs.004, decided by the bilateral relationship between the two specific agents at that hop, never both.
• Mixing up camt.029’s own codes with the gpi Tracker’s codes. CNCL, PDCR, and RJCR belong to camt.029’s Confirmation element. ACSP, ACCC, and RJCT belong to the Tracker’s trck.001 and trck.002 reporting. They look parallel and they are not interchangeable.
• Assuming the accounting relationship works symmetrically. If Debtor Agent holds the other bank’s account, a simple book transfer with an ACSC status works. If the relationship runs the other way, Debtor Agent has to actually originate a payment message; it is not a mirror image of the book-transfer case.
• Assuming pacs.010 is sent by the Creditor’s bank. In FI to FI Direct Debit, the Creditor institution itself sends the pacs.010 directly to Debtor Agent, exactly the same pattern as an FI Debtor initiating pacs.009 directly in Part 4.
• Assuming the gpi Tracker applies everywhere by default. It does not apply to FI to FI payments out of the box. That world runs on gFIT, a separate, optional service, not the mandated Tracker used for customer payments.

Frequently Asked Questions About the ISO 20022 Payment Lifecycle

Watch the Full Walkthrough on YouTube

This guide is also being built out as a four-part video series on the PaymentTalks YouTube channel, walking through the same nine parts with the actual flow diagrams on screen.

• Video 1: Foundations + STP Backbone – the canvas, the legend, the gpi Tracker, and the happy path, Parts 0 and 1.
• Video 2: Non-STP + Cancellation – every way a payment can be rejected, returned, or pulled back, Parts 2 and 3.
• Video 3: FI to FI + Cover vs. Advice – when the payer is a bank, and the two ways cover funds move, Parts 4 and 5.
• Video 4: Direct Debit + Reference and Admin Messages – pulling instead of pushing, and everything that sits around the edges of a payment, Parts 6 and 7.

Summary: What to Take Away From This Guide

Every ISO 20022 CBPR+ flow in this guide is built from the same seven actors, the same red-and-black legend, and a small number of repeating rules: banks post on their own network acknowledgment, not on a counterparty’s confirmation; rejections are always either a status message or a value return, never both; and the accounting relationship between two agents, more than the message type itself, decides whether a step ends in a notification or an instruction.

The one clear next action: bookmark the Part 8 reference appendix. Every time you hit an unfamiliar message code in a real payment investigation, that glossary, and the flow it points back to, is the fastest way to place it correctly.