ISO 20022 Agents and Parties: The Complete Guide to 13 Critical Roles

What Are the ISO 20022 Agents and Parties in a Payment Message?

Every payment message carries a chain of agents and parties long before money actually lands in an account. ISO 20022 agents and parties are how the standard names each link in that chain: Debtor, Creditor, their agents, the intermediaries between them, and the reimbursement path that moves the funds. Get one of these roles wrong in a PACS.008 or PAIN.001 message, and reconciliation breaks somewhere down the line.

This guide walks through all 13 agent and party roles, in the order they actually show up in a payment’s journey. If you build payment engines, map message specs, or debug why a cross-border transfer stalled at a correspondent, this is the reference you keep open. For the full picture of how a payment moves end to end, see What Is a Payment: Its Brief Evolution and Key Elements.

Everything below follows the ISO 20022 message standard maintained by the ISO 20022 Registry. I’ll reference PACS.008 (FI-to-FI Customer Credit Transfer) and PAIN.001 (Customer Credit Transfer Initiation) throughout, since that’s where most of these fields actually live. If you need the building blocks before the agent roles, start with Fundamentals of ISO 20022.

Here’s the full picture before we go role by role, all 13 agents and parties in one summary view:

Summary of all agents and parties involved in an ISO 20022 payment message

Who Is the Ultimate Debtor in ISO 20022?

The Ultimate Debtor (UltmtDbtr) is an optional party in messages like PACS.008. It’s the original party who actually owes the payment, and it’s not the same as the Debtor sitting in the transaction. You use it when the payment is made on someone else’s behalf.

CBPR+ works on the premise that an Ultimate Debtor has no direct, regulated account relationship with the Debtor. That distinction matters the moment compliance or reconciliation starts asking who really owed the money.

Key Characteristics of the Ultimate Debtor

• Distinct from Debtor: the Ultimate Debtor holds the original obligation to pay; the Debtor is the immediate party making the payment.
• Transparency: clarifies where a payment originated, which matters in layered payment chains, regulatory reporting, and reconciliation. It does not involve itself in the payment settlement process.
• Optional field: only populate it when it’s actually relevant, never as a default.
• Typical usage: payments made by agents, trustees, or subsidiaries, where the actual obligation sits with someone other than whoever initiates the payment.

Example: The Money Transfer Bureau Scenario

Individual X walks into a Money Transfer Bureau with ID and asks for a payment to be sent, on their behalf, to Individual Y. The Bureau accepts the payment and initiates it through its own bank. That bank processes the payment to Individual Y’s bank, which then credits Y’s account and reports the funds.

• Ultimate Debtor: Individual X. Has no financial regulated direct account relationship with the Money Transfer Bureau.
• Debtor: Money Transfer Bureau (can also sit in Initiating Party here). The Bureau’s account is what actually gets debited by its agent.
• Debtor Agent: Money Transfer Bureau’s bank
• Creditor Agent: Individual Y’s bank
• Creditor: Individual Y

Ultimate Debtor example: Individual X to Money Transfer Bureau to Individual Y payment flow

The Ultimate Debtor exists purely to keep this kind of layered obligation transparent, without dragging the Debtor field into a role it doesn’t actually occupy.

What Is the Debtor’s Role in an ISO 20022 Message?

The Debtor (Dbtr) is the party responsible for initiating and funding the payment. That’s typically an individual, an organisation, or a corporate customer, and sometimes a bank itself, who owes the amount and instructs their bank to move it to the Creditor.

Key Characteristics of the Debtor

• Primary payer: the direct party responsible for initiating the payment.
• Distinct from the Ultimate Debtor: the Ultimate Debtor is the original obligor, if one exists; the Debtor is who actually funds it.
• Linked to the Debtor Agent: the payment instruction flows to the Debtor’s own bank, which executes the transfer.
• Mandatory field: required in customer payment messages such as PACS.008.

Every example in this article uses the Debtor as the anchor. It’s the field everything else in the chain is built around, refer back to the Ultimate Debtor example above for how it plays out in practice.

What Does the Initiating Party Do in ISO 20022?

The Initiating Party (InitgPty) is the entity that originates the payment instruction and submits it to the first bank in the chain, usually the Debtor Agent. It has authority to initiate on the Debtor’s behalf, but sometimes the Initiating Party is the Debtor itself.

Key point: when the Initiating Party is different from the Debtor, it plays no role in the payment settlement process. It initiates. It doesn’t settle. But including it still helps ensure clarity and traceability in complex or layered payment processes.

Key Characteristics of the Initiating Party

• Originates the transaction: can act on behalf of the Debtor or initiate in its own capacity.
• Distinct from the Debtor: a payment service provider or parent company can initiate for another entity.
• Optional field: used mainly for transparency in third-party payment arrangements.
• Supports traceability: useful audit trail in layered or complex payment setups.

Example: Third-Party Initiation

Individual X asks a Third-Party Payment Service Provider to send funds to Individual Y. The Provider initiates the payment against X’s own account at X’s bank, not its own. X’s bank processes it through to Y’s bank, which credits Y.

• Debtor: Individual X, since his account is the source of funds for the payment. In the Ultimate Debtor example above, X’s own account was never involved. Here it is, same-looking scenario, different field entirely.
• Initiating Party: the Third-Party Payment Provider, who needs Debit Authority to initiate the payment from X’s account, communicated in advance to X’s bank. This provider is not involved in the actual movement of funds.
• Debtor Agent: Individual X’s bank
• Creditor Agent: Individual Y’s bank
• Creditor: Individual Y

Initiating Party example: Individual X to Third-Party Payment Provider to Individual Y payment flow

This kind of mapping decision, same scenario shape, different field depending on whose account actually funds it, is exactly what Payment Type Information in ISO 20022 covers in more depth, for PAIN.001 and PACS.008 both.

When Do You Need a Forwarding Agent in PAIN.001?

The Forwarding Agent shows up specifically in PAIN.001 (Customer Credit Transfer Initiation). It’s a financial institution that relays the payment instruction from the Initiating Party or Debtor to the Debtor Agent, typically as a concentrating institution in a relay scenario.

Two things to remember. First, the Forwarding Agent needs Debit Authority over the Debtor’s account, usually set up through tripartite agreements. Second, it’s a technical role only, it is not involved in the payment settlement process or funds movement, and it never shows up in clearing or settlement, which means it doesn’t carry through into the PACS messages at all.

Key Characteristics of a Forwarding Agent in PAIN.001

• Intermediary institution: bridges the Initiating Party or Debtor and the Debtor Agent.
• Optional role: only appears when an intermediary institution forwards the payment instruction.
• Part of the initiation chain: routes the message to the correct Debtor Agent for processing, without touching settlement.

Example: The Relay Scenario

Corporate A sends a payment initiation to Payment Service Provider X. Provider X forwards it to the bank holding Corporate A’s account. That bank processes the payment through to Individual Y’s bank, which credits Y.

• Debtor: Corporate A, since its account is the source of the initial funds. Corporate A can also be called Initiating Party here, since it’s initiating the payment, but since it’s already represented as Debtor, there’s no need to duplicate it in Initiating Party.
• Forwarding Agent: Payment Service Provider X, relaying the instruction, holding Debit Authority over Corporate A’s account, communicated to Corporate A’s bank for smooth processing.
• Debtor Agent: Corporate A’s bank
• Creditor Agent: Individual Y’s bank
• Creditor: Individual Y

Forwarding Agent example: Corporate A to Payment Service Provider X relay scenario in PAIN.001

If you’re mapping PAIN.001 fields end to end, What Is PAIN.001? walks through the full initiation flow with real examples.

What Is the Debtor Agent’s Role in ISO 20022?

The Debtor Agent (DbtrAgt) is the bank that services the Debtor’s account. It debits the funds and pushes the payment to the next party in the chain.

Key Characteristics of the Debtor Agent

• Account-servicing institution: holds and manages the Debtor’s account.
• Mediator in the flow: moves funds toward the Creditor or the next intermediary agent.
• Executes the instruction: acts on what the Debtor, or an authorised Initiating Party, instructs.
• Mandatory in most messages: required in PACS.008 and PAIN.001. Optional in PACS.009, since there the Debtor is itself a financial institution.

This is the field every earlier example already showed you. It’s the anchor bank on the paying side, full stop, refer back to the examples above for how it sits in each scenario.

What Is the Creditor Agent’s Role in ISO 20022?

The Creditor Agent (CdtrAgt) is the bank that services the Creditor’s account. It’s the institution that actually receives the incoming funds and credits them.

Key Characteristics of the Creditor Agent

• Account-servicing institution: manages the Creditor’s account and posts the credit.
• Receives from upstream: gets the payment directly from the Debtor Agent, or through one or more Intermediary Agents.
• Final leg of the chain: usually the last bank before the Creditor sees the funds. In PACS.009, the Creditor itself is a financial institution.
• Mandatory in most messages: required in PACS.008 and PAIN.001. Optional in PACS.009.

Refer back to the examples above for how the Creditor Agent shows up across different scenarios.

Who Is the Creditor in an ISO 20022 Message?

The Creditor (Cdtr) is the beneficiary of the payment, an individual, business, organisation, or sometimes a bank. This is the party the funds are actually meant for, identified by account details such as an IBAN.

Key Characteristics of the Creditor

• Payment beneficiary: the final recipient in the chain.
• Identified by account details: IBAN or an equivalent account identifier.
• Direct link to the Creditor Agent: the Creditor’s account is typically held at the Creditor Agent.
• Mandatory field: required in PACS.008 and PAIN.001.

Refer back to the examples above for how the Creditor sits at the end of each chain.

What Is the Ultimate Creditor and Why Does It Matter?

The Ultimate Creditor (UltmtCdtr) is the true beneficiary of the funds, even when that’s not the same party as the Creditor. You’ll see this whenever money is credited to a proxy or intermediary account before it reaches whoever it’s actually for.

Same CBPR+ premise as the Ultimate Debtor: no direct, regulated account relationship between the Ultimate Creditor and the Creditor.

Key Characteristics of the Ultimate Creditor

• True beneficiary: the party who ultimately benefits, regardless of which account was credited first.
• Optional and often identical to the Creditor: they diverge in proxy or intermediary arrangements.
• Adds transparency: extra clarity in the payment chain, useful for regulatory purposes.

Example: Paying a Care Facility on Someone Else’s Behalf

Person A pays a retirement care facility’s fees for resident X, through Bank A to Bank B, which holds the facility’s account.

• Debtor: Person A
• Debtor Agent: Bank A
• Creditor Agent: Bank B
• Creditor: the Retirement Care Facility, since its account is what actually receives the amount.
• Ultimate Creditor: Resident X, the actual beneficiary of the service the fee pays for.

Ultimate Creditor example: Person A paying a retirement care facility on behalf of Resident X

How Does the Instructing Agent Work in a Payment Chain?

The Instructing Agent (InstgAgt) is the bank sending the payment instruction to the next party in the chain. Its role is dynamic: it holds different financial institution information at every step of the chain, depending on who’s currently sending the message.

Key Characteristics of the Instructing Agent

• Sender of the instruction: initiates and transmits the message to the next agent.
• Can be any bank in the chain: Debtor Agent, an Intermediary Agent, or another institution.
• Message originator for that leg: identified as the sender for that specific step.
• Mandatory element: essential for tracing the source of every instruction and maintaining accountability.

What Is the Instructed Agent’s Role?

The Instructed Agent (InstdAgt) receives the instruction from the Instructing Agent. It’s the recipient at that step, responsible for the next action, whether that’s crediting funds, forwarding the payment, or running compliance checks. Same as the Instructing Agent, its role is dynamic across the payment’s life cycle.

Key Characteristics of the Instructed Agent

• Receiver of the instruction: gets the message from the preceding institution.
• Executes the next step: credits funds, forwards the payment, or performs compliance checks.
• Any agent in the chain: Creditor Agent, an Intermediary Agent, or another institution, depending on the leg.
• Mandatory element: ensures traceability and accountability at every step.

Example: Dynamic Roles Across a Four-Bank Chain

Person P pays Person Q. P’s bank is A, Q’s bank is E. Three intermediary banks, B, C, and D, sit between them, so the payment moves in four legs.

• First leg: Bank A to Bank B
• Intermediary leg 1: Bank B to Bank C
• Intermediary leg 2: Bank C to Bank D
• Final leg: Bank D to Bank E

In the first leg, Bank A, though it’s Debtor Agent, is also the Instructing Agent, and Bank B, the first intermediary bank in the chain, is now Instructed Agent. In Leg 2, Bank B, previously Instructed Agent, becomes Instructing Agent, and Bank C, one of the intermediary agents in the original chain, becomes Instructed Agent. In Leg 3, Bank C becomes Instructing Agent and Bank D becomes Instructed Agent. In the final leg, Bank D becomes Instructing Agent, and Bank E, which was Creditor Agent all along, is now also Instructed Agent.

Bank A and Bank E never change: they stay Debtor Agent and Creditor Agent for the entire payment life cycle. That confirms the static role of Debtor Agent and Creditor Agent, versus the dynamic role Instructing and Instructed Agent play at every leg, and it’s a distinction that trips up a lot of people mapping these fields for the first time.

Dynamic roles example: Instructing Agent and Instructed Agent reassigning across a four-bank payment chain

What Are Previous Instructing Agents and When Do You Use Them?

Previous Instructing Agent(s) (PrvsInstgAgt) are the institutions that already handled and forwarded the payment instruction before it reached the current Instructing Agent, relative to the message sender’s perspective.

Previous Instructing Agent concept: institutions that already handled the payment before the current Instructing Agent

Key Characteristics of Previous Instructing Agents

• Earlier institutions in the chain: handled the instruction before the current Instructing Agent.
• Sequential and relative: “previous” is relative to the message sender’s, or Instructing Agent’s, perspective.
• Multiple agents possible: depends on the complexity of the chain.
• Static roles: once a bank occupies a Previous Instructing Agent slot, additional agents get appended to the history, but existing ones don’t change position for the life of the payment.

🚩 Industry Best Practice Tip: only populate Previous Instructing Agent when a financial institution doesn’t already hold a position in Debtor Agent or Instructing Agent. Don’t duplicate a bank that’s already represented elsewhere.

Types of Previous Instructing Agents

• Previous Instructing Agent 1: the first historic institution between the Debtor Agent and the current Instructing Agent (or PrvsInstgAgt2, if present).
• Previous Instructing Agent 2: the second historic institution, between PrvsInstgAgt1 and the current Instructing Agent (or PrvsInstgAgt3).
• Previous Instructing Agent 3: the most recent historic institution, between PrvsInstgAgt2 and the current Instructing Agent.

Example: Tracking the Chain, Leg by Leg

Same four-bank chain as before: A to B to C to D to E.

First leg has no Previous Instructing Agents, the payment hasn’t gone anywhere yet. In Leg 2, the payment has passed Bank A, but since A already holds the Debtor Agent slot, it doesn’t get repeated here. In Leg 3, the payment has passed A and B. A still stays out. B, which holds no other position, lands in Previous Instructing Agent 1. In the final leg, A, B, and C have all been passed. A stays out, B keeps its static position in PrvsInstgAgt1, and C now fills PrvsInstgAgt2.

Previous Instructing Agent example tracked across a four-bank payment chain, leg by leg

If you’re also mapping how payment references and end-to-end IDs travel through this same chain, Payment Identifiers in ISO 20022 is the companion piece for that.

What Are Intermediary Agents in ISO 20022?

Intermediary Agents (IntrmyAgt) are banks that sit between the Debtor Agent and Creditor Agent when there’s no direct relationship connecting them. Without a correspondent relationship in place, the payment has to route through one or more intermediaries.

🚩 Industry Best Practice Tip: only use Intermediary Agent fields when a financial institution doesn’t already hold a position in Instructed Agent or Creditor Agent.

Intermediary Agent concept: banks bridging the Debtor Agent and Creditor Agent with no direct relationship

Key Characteristics of Intermediary Agents

• Bridge the gap: connect institutions with no direct correspondent relationship.
• Multiple possible: one or more, depending on the chain.
• Optional fields: only required when routing or settlement demands it.
• Dynamic roles: numbered in order, and the bank occupying each numbered slot changes leg by leg.

Types of Intermediary Agents

• Intermediary Agent 1: the first institution in the chain between the Debtor Agent and Creditor Agent, the one the Instructed Agent is attempting to route to next.
• Intermediary Agent 2: the next institution, receiving from Intermediary Agent 1, sitting between it and Intermediary Agent 3 or the Creditor Agent.
• Intermediary Agent 3: the institution forwarding the instruction closer to the Creditor Agent.

Example: Same Chain, Different Numbering Each Leg

Same A to B to C to D to E chain. In the first leg, Instructing Agent A sends to Instructed Agent B. Between B and Creditor Agent E sit two more banks, C and D. C takes Intermediary Agent 1 (the next agent immediately after the Instructed Agent), and D takes Intermediary Agent 2. E stays Creditor Agent and is never labelled an Intermediary Agent.

In Leg 2, B becomes Instructing Agent, C becomes Instructed Agent, and D, now the only bank left before E, moves into Intermediary Agent 1. By Leg 3, there’s nothing left between the Instructed Agent and Creditor Agent, so no Intermediary Agent fields are needed. In the final leg, same thing: nothing to fill.

Intermediary Agent example tracked across a four-bank payment chain, leg by leg

What Are Reimbursement Agents and How Do Cover Payments Work?

Reimbursement Agents settle funds between the Debtor Agent and Creditor Agent when those two banks don’t have a direct account relationship in the payment currency, but do have an RMA relationship to exchange direct or announcement messages. This is the classic cover payment scenario, run through correspondent banking or a clearing system.

Reimbursement Agent concept: settling funds between Debtor Agent and Creditor Agent via correspondent banking

Key Characteristics of Reimbursement Agents

• Handle actual settlement: move real funds between banks, often via correspondent accounts or clearing systems.
• Used for indirect relationships: the Debtor Agent and Creditor Agent lack a direct banking relationship, but hold RMA.
• Optional, based on complexity: only appear when the settlement arrangement needs them.

Types of Reimbursement Agents

Instructing Reimbursement Agent (InstgRmbrsmntAgt): the first institution in the reimbursement chain, receiving the covering payment instruction from the Debtor Agent and initiating the transfer. This is your currency correspondent.

Example: Person A, through Bank A, pays Person B at Bank B. Bank A and Bank B have no accounting relationship in that currency, only an RMA relationship for messaging. Bank A routes through its currency correspondent, Bank X, which settles through domestic clearing. Bank B then reports the credit to Person B. One Reimbursement Agent, one hop.

Instructed Reimbursement Agent (InstdRmbrsmntAgt): the second agent in the chain, receiving the covering instruction from the Instructing Reimbursement Agent, directly or via clearing, and crediting the account.

Example: same setup, but now Bank A’s correspondent is Bank X, and Bank B’s correspondent is Bank Y. The payment settles through Bank X and Bank Y.

Instructing Reimbursement Agent example: Bank A settling through currency correspondent Bank X

Instructed Reimbursement Agent example: settlement chain through Bank X and Bank Y correspondents

Sometimes Bank X and Bank Y don’t have a direct accounting relationship either, and route instead through a local clearing system to settle funds in that currency.

Instructed Reimbursement Agent example: settlement chain through Clearing

Third Reimbursement Agent (ThrdRmbrsmntAgt): the final institution in the chain, transferring funds to the Creditor Agent, used when there’s an additional agent beyond what’s captured in Instructed Reimbursement Agent.

Example: Bank A’s correspondent is Bank X, Bank B’s is Bank Z, and there’s an additional Reimbursement Agent, Bank Y, sitting between them. Settlement now runs through Bank X, Bank Y, and Bank Z, three hops instead of one or two.

Third Reimbursement Agent example: settlement chain via Bank X, Bank Y, and Bank Z,

This whole mechanism only exists because correspondent banking relationships aren’t universal. For the account structures underneath it, see Nostro, Mirror Nostro, Vostro, and Loro Accounts, and for how the RMA and correspondent relationship gets established in the first place, Understanding Correspondent Banking. SWIFT’s own network documentation is worth bookmarking too, at SWIFT.

ISO 20022 Agents and Parties: PACS.008 vs PACS.009 at a Glance

PACS.008 (customer credit transfer) and PACS.009 (financial institution credit transfer) share most of the same agent structure, but a few roles shift depending on whether the Debtor and Creditor are customers or banks themselves. The comparison below is a high-level view, not a field-by-field spec, meant to simplify the concept.

ISO 20022 agents and parties comparison PACS.008

ISO 20022 agents and parties comparison PACS.009

The meaning and definition of each agent doesn’t change between the two messages, but there are variations, especially where the Debtor and Creditor are themselves the agents in a PACS.009 message.

A Hypothetical Payment Chain: Mapping Debit and Credit Accounts

Once you’ve got all 13 roles straight, the next question is practical: given the agents and parties actually present in a payment, what’s the priority and sequence, and where do the debit and credit accounts sit? The hypothetical chain below maps that directly. Agents shown in green are mandatory elements; everything else is optional. Based on which elements actually appear in a given payment, you can read the journey the payment has already made, and the journey still ahead of it, including where funds are debited and to whom they’ll be credited at each leg.

Hypothetical ISO 20022 payment chain showing mandatory agents in green and the order of agents and parties

This is exactly the logic behind Debit and Credit Party Derivation. If you’re building or auditing that logic in a payment engine, Debit-Credit Party Derivation (DPD / CPD) walks through incoming, onward, and outgoing payments field by field. And since every one of these derivations ultimately has to balance, Double-Entry Accounting in Payments is the foundation worth having solid underneath it.

Why These Agent Roles Matter for Every Payments Professional

ISO 20022’s real strength is that it names every one of these roles precisely instead of leaving them implicit. From Ultimate Debtor through Ultimate Creditor, and every agent in between, each field carries a distinct, deliberate function in getting funds from A to E cleanly, and in keeping the payment chain transparent, efficient, and interoperable across the global payments ecosystem.

Get the static roles (Debtor Agent, Creditor Agent) confused with the dynamic ones (Instructing Agent, Instructed Agent, Intermediary Agent), and your reconciliation logic breaks the first time a payment takes more than one hop. Understand the distinction and the hierarchy between these roles, and mapping any payment chain, however many banks it runs through, becomes mechanical instead of guesswork, and that’s what drives real compliance and service quality as ISO 20022 adoption keeps expanding. For how these roles sit inside the bigger transaction flow, Payment Life Cycle: Banking Transaction is the natural next read.

Watch the Full Walkthrough on YouTube

Prefer video? The full walkthrough is on the PaymentTalks YouTube channel.

Three-part breakdown of everything above, on video: Part 1 covers the Payment Initiating Agents (Ultimate Debtor, Debtor, Initiating Party, Forwarding Agent), Part 2 covers the Payment Processing Agents (Debtor Agent, Instructing Agent, Instructed Agent, Creditor Agent, Creditor, Ultimate Creditor), and Part 3 covers the Additional Agents (Previous Instructing Agents, Intermediary Agents, Reimbursement Agents) plus the bonus PACS.008/PACS.009 and hypothetical chain concepts.

• Part 1, Payment Initiation: youtu.be/WPoiauuQC8U
• Part 2, Payment Processing: youtu.be/n_n0dYqHDpE
• Part 3, Additional Agents: youtu.be/qwt–d0ysjo

Frequently Asked Questions