SWIFT / Learning brief
What a payment declares about itself — and who carries it
Your notes
In simple terms / 01
What this means in plain language
Every ISO 20022 payment carries two kinds of metadata: coded fields that declare what the payment is — service level, local instrument, category purpose, purpose — and an agent chain that names who moves it, bank by bank. This article reads a fictional pacs.008 field by field: what each code means, why there are four purpose-ish fields and not one, and how the instructing, previous-instructing, intermediary and reimbursement agents thread a payment across borders.
An ISO 20022 payment says two things about itself before it says how much to move. First, a set of coded fields declares what kind of payment it is: the service level (which scheme or speed, e.g. SEPA), the local instrument (a scheme variant, e.g. instant), the category purpose (a hint to the banks about how to handle it, e.g. salary), and the purpose (the reason for the payment, meant for the parties, e.g. supplier invoice). Second, an agent chain names the banks that carry it: the instructing and instructed agents at each hop, an optional previous-instructing agent that records where the payment came from, intermediary agents in the middle, and — in a cover arrangement — reimbursement agents that settle the funds separately. Read together, the codes tell handlers what to do and the chain tells them who does it next.
Complete lesson / 02
Understand the full idea, step by step
Before an ISO 20022 payment tells the banks how much to move, it tells them two other things: what kind of payment it is, in a handful of coded fields, and who is carrying it, in a chain of named agents. Most confusion about these messages comes from treating the four purpose-ish codes as one field, or reading the agent chain as a straight line from sender to receiver. This lesson takes a single fictional pacs.008 apart so you can read both the codes and the chain with confidence.
Why does one payment need four different 'what is this' fields — service level, local instrument, category purpose, and purpose? Isn't one enough?
Because they answer four different questions, aimed at different readers. Service level says which scheme or speed the sender chose (SEPA, urgent). Local instrument narrows that to a scheme variant (instant, a direct-debit flavour). Category purpose is a hint to the banks about how to handle the payment (treat it like a salary run). Purpose is the reason for the payment, meant for the debtor and creditor (a supplier invoice). Collapse them into one field and you lose the ability to route, prioritise, and reconcile independently.
ISO 20022 — ILLUSTRATIVE, NON-PRODUCTION
PmtTpInf (Payment Type Information)
The container that declares what kind of payment this is, before any money is described. It holds the instruction priority, the service level, the local instrument, and the category purpose. It is the message's own label for itself: read it first, because it tells you how the payment expects to be handled.
The four coded fields, and who each one is for
- Service level (SvcLvl/Cd)
- Which scheme or speed the sender chose — e.g. SEPA, URGP (urgent). A CHOICE: a code from the list, or a bilaterally agreed proprietary value. For the whole payment.
- Local instrument (LclInstrm/Cd)
- The scheme variant within that service level — e.g. INST (instant), CORE / B2B for direct debits. Narrows how the scheme handles it.
- Category purpose (CtgyPurp/Cd)
- A handling hint to the banks — e.g. SALA (salary), SUPP (supplier), PENS (pension). Tells the agents how to treat the payment as a class.
- Purpose (Purp/Cd)
- The reason for the payment, for the debtor and creditor — e.g. SUPP, GDDS (goods), SCVE (services). Carried through to the parties, not primarily a routing signal.
| Field | Answers | Read by | Example code |
|---|---|---|---|
| Service level | Which scheme / speed? | Routing & the network | SEPA |
| Local instrument | Which variant of that scheme? | The scheme's processing | INST |
| Category purpose | How should banks handle it? | The agents (a hint) | SALA |
| Purpose | Why is it being paid? | The debtor & creditor | SUPP |
COMMON CONFUSION
“Category purpose and purpose are the same thing written twice — you can read either one to know why a payment was sent.”
They aim at different readers. Category purpose is a hint to the banks about how to handle the payment as a class (treat it like a salary run, a pension, a tax payment), and can influence processing or prioritisation. Purpose is the reason for the payment, carried to the debtor and creditor for their records. They often share a code — SUPP can appear in both — but a payment can carry one without the other, and they are not guaranteed to agree.
The agent chain — a relay, hop by hop
- CLEARING
Instructing agent (InstgAgt) and instructed agent (InstdAgt): the two banks on THIS hop. InstgAgt sends the instruction; InstdAgt receives it. They are not the debtor's and creditor's banks fixed for the whole payment — they change at every hop.
- CLEARING
Previous-instructing agent (PrvsInstgAgt1): the bank that instructed the hop before this one. It is a breadcrumb — it records where the payment just came from, so the route can be reconstructed. PrvsInstgAgt2 and 3 record earlier hops still.
- CLEARING
Intermediary agent (IntrmyAgt1): a bank in the middle of the chain, between the debtor's and creditor's banks, that neither holds the debtor's account nor the creditor's — it just passes the payment along. IntrmyAgt2 and 3 add further middle hops.
- SETTLEMENT
Debtor agent (DbtrAgt) and creditor agent (CdtrAgt): the fixed endpoints — the bank that holds the debtor's account and the bank that will credit the creditor. Everything between them is the relay.
- SETTLEMENT
Reimbursement agents (InstgRmbrsmntAgt / InstdRmbrsmntAgt): in a cover arrangement, these name where the funds are actually settled, on a separate track from the instruction. The message you read may be moving the instruction while a cover message moves the money.
Why the reimbursement agents sit apart
In a serial payment the instruction and the funds travel together, bank to bank. In a cover payment they split: the pacs.008 carries the instruction straight to the creditor's bank, while a separate pacs.009 moves the actual funds between the correspondents. The reimbursement agents — instructing and instructed — are how the instruction message points at that separate settlement: they say 'the money for this is being settled over there, between these two banks'. If you follow only the agent chain in the instruction, you will miss where the cash actually moved; that is the whole reason cover exists as a pattern.
The debtor is more than a name now
The debtor and creditor are not just names. Under ISO 20022 each can carry a structured postal address — street name, building number, post code, town name, and country each in its own labelled element — rather than a few free-text lines. Structured data is what screening systems read cleanly, and from 15 November 2026 a fully unstructured address is no longer permitted for in-scope cross-border payments. So 'Dbtr → Nm + PstlAdr' is not a formality: the name identifies the party, and the structured address is increasingly the difference between a payment that clears screening and one that stops for review.
STRICTLY SPEAKING
The four-letter values here — SEPA, INST, SALA, SUPP — come from the ISO 20022 External Code Sets, which are updated on a published schedule and are larger than any list a lesson can show. Crucially, a scheme's own usage guidelines may permit only a subset: a code that is valid in the External Code Set can still be rejected by a rail that does not allow it. When a specific value is load-bearing, confirm it against the current External Code Sets spreadsheet and the relevant scheme's usage guidelines rather than a summary.
FOR NOW, REMEMBER
- A payment declares itself in four coded fields: service level (which scheme/speed), local instrument (which variant), category purpose (a handling hint to the banks), and purpose (the reason, for the parties). They are not interchangeable.
- The agent chain is a relay: instructing and instructed agents change every hop; previous-instructing and intermediary agents record the route; debtor and creditor agents are the fixed endpoints.
- Reimbursement agents point at a separate settlement track in a cover arrangement — the instruction and the funds can travel on different messages.
- The codes are four-letter values from the ISO 20022 External Code Sets, and a scheme's usage guidelines may allow only a subset, so a valid code can still be refused by a rail.
TRY IT YOURSELF
A pacs.008 carries CtgyPurp/Cd = SALA and no Purp. A colleague says 'the purpose is missing, we don't know why this was paid.' What is the most accurate response?
You have read the codes and the chain on one message. Next, see the full code-value reference — every SvcLvl, LclInstrm, CtgyPurp and Purp value the academy documents — and the topic that ties them to routing and reconciliation.
KEEP GOINGKey takeaways / 03
Three things to remember
- 01
The coded payment-type fields answer four different questions: service level = which scheme/speed, local instrument = which scheme variant, category purpose = a handling hint for the banks, purpose = the reason for the parties. They are not interchangeable.
- 02
The agent chain is a relay, not a single sender-to-receiver line: instructing and instructed agents change at every hop, previous-instructing and intermediary agents record the route, and reimbursement agents settle a cover payment on a separate track.
- 03
Almost all of these fields carry four-letter codes from the ISO 20022 External Code Sets (SEPA, INST, SALA, SUPP, …); a scheme's usage guidelines may allow only a subset, so a valid code can still be rejected by a rail.
Practical use cases / 04
Where you would use this
An operations analyst investigating why a payment was routed a certain way reads PmtTpInf: the service level and local instrument together tell them which scheme and variant the sender asked for.
A screening or reconciliation team traces funds across borders by following the agent chain — instructing → previous-instructing → intermediary → creditor agent — rather than assuming the debtor's bank paid the creditor's bank directly.
A channels or product team decides where to surface a purpose code by learning that category purpose is a hint to the banks while purpose is the reason for the parties, so the two belong in different places in a UI.
Worked example / 05
Put the idea into a real situation
A fictional pacs.008 moves EUR 12,500.00 from Delta Handels GmbH to Orion Trading Ltd. Its PmtTpInf declares SvcLvl/Cd = SEPA (the scheme), CtgyPurp/Cd = SUPP (a supplier payment, a handling hint), and Purp/Cd = SUPP (the reason, for the parties). The agent chain reads: InstgAgt DEMODEFFXXX (the debtor's bank, instructing this hop), PrvsInstgAgt1 DEMOFRPPXXX (the bank that instructed the previous hop, recorded for the trail), IntrmyAgt1 DEMONL2AXXX (a correspondent in the middle), and the creditor agent that will credit Orion. RmtInf carries Ustrd = 'DEMO INVOICE 1001' and a structured Strd creditor reference RF98 1234 5678. Each code is a four-letter value from the External Code Sets; each agent is one bank in a relay, not the endpoints.
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
- 01MessageThe debtor initiates the cross-border paymentDebtor (payer) → Bank Alfa (debtor agent) · pain.001
A corporate treasury sends a pain.001 with structured party and remittance data — the structure survives the whole journey because every hop speaks ISO 20022.
- 02ProcessingBank Alfa validates, screens, and debitsBank Alfa (debtor agent)
Checks and screening run on rich, structured fields — one of ISO 20022's main gains. The customer account is debited on acceptance.
- DR Debtor's account at Bank Alfa — USD 1,250,000.00
Screening checkpoint: Outbound screening on structured data — Structured names and addresses screen more precisely than free-text lines, cutting false positives.
- 03MessageThe pacs.008 leaves with a BAH and UETRBank Alfa (debtor agent) → Meridian Bank (intermediary agent) · pacs.008
The interbank message travels with a Business Application Header and a UETR — the end-to-end reference every bank keeps unchanged, making the payment trackable.
- 04ProcessingMeridian screens in the middle of the chainMeridian Bank (intermediary agent)
The intermediary agent screens the structured parties and checks cover on Bank Alfa's account.
- 05SettlementThe correspondent settles across its booksMeridian Bank (intermediary agent)
Settlement is a book transfer between the two banks' USD accounts at Meridian — same mechanics as the MT world; the message standard changed, the money movement did not.
- DR Bank Alfa's USD account at Meridian (vostro) — USD 1,250,000.00
- CR Cassia's USD account at Meridian (vostro) — USD 1,250,000.00
- 06MessageThe pacs.008 continues to the creditor agentMeridian Bank (intermediary agent) → Cassia Bank (creditor agent) · pacs.008
The same UETR arrives at Cassia; anyone with the reference can see where the payment is in the chain.
- 07ProcessingCassia validates the incoming paymentCassia Bank (creditor agent)
Inbound screening and account checks before the credit is applied.
- 08PostingThe creditor is creditedCassia Bank (creditor agent)
The structured remittance information lets the creditor reconcile the invoice automatically.
- CR Creditor's account at Cassia — USD 1,250,000.00
- 09MessageA confirmation closes the loopCassia Bank (creditor agent) → Bank Alfa (debtor agent) · pacs.002
A status confirmation tells the debtor agent the payment completed — the debtor can be told with certainty rather than silence.
Evidence & review / 07
Evidence & review
ISO 20022 customer and interbank credit transfers (pain.001, pacs.008) and their coded payment-type and agent fields; the code meanings are drawn from the ISO 20022 External Code Sets, scheme usage may restrict which values are allowed.
What this brief simplifies: A single intermediary and one reimbursement pair; real chains and code lists are larger. All worked values are fictional and for training only.
Sources for this brief4
- Official requirement
ISO 20022 External code sets ↗ — ISO 20022 Registration Authority · ExternalServiceLevel, ExternalLocalInstrument, ExternalCategoryPurpose, ExternalPurpose code lists
Updated quarterly (end of February, May, August, and November) in XLSX, XSD, and JSON formats; always check the latest published version for valid codes.
- Official requirement
ISO 20022 Catalogue of messages ↗ — ISO 20022 Registration Authority · pacs.008 FIToFICustomerCreditTransfer: PmtTpInf, agent chain, Dbtr/Cdtr, RmtInf
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+ usage of the agent chain and structured remittance in cross-border payments
Full guidelines require MyStandards access; content here relies on public summaries. MT-to-CBPR+ translation rules are published on Swift's translation portal.
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
What this simplifies: One intermediary agent and a single remittance line; the full agent chain can be longer and codes can be scheme-restricted. BICs, names, amounts, and references are fictional (SYNTHETIC / TRAINING ONLY).
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.