GLOBAL PAYMENTS KNOWLEDGEISO 20022 / SWIFT / SEPA / MT / MX
09 / ISO 20022 & CBPR+12 MIN

How a payment declares what it is

Service level, local instrument, category purpose, purpose, and priority — the fields that tell everyone what kind of payment this is, and the 4-letter codes they carry.

NOT STARTED

L0 Explain simply

Analogy: a parcel does not just carry an address — it carries labels. 'Fragile', 'This way up', a customs code saying what is inside, a service sticker saying 'next-day' or 'economy'. Anyone handling the parcel reads the labels and treats it accordingly, without opening it. An ISO 20022 payment works the same way. Alongside the amount and the parties, it carries small coded labels that say what kind of payment this is and how to handle it: which scheme it runs under, whether it is instant, what it is for, and how urgent it is. Each label is a short code — usually four letters — from an agreed list, so a bank on the other side of the world reads 'SALA' or 'SEPA' and knows exactly what is meant.

L1 Core concepts

Four elements do most of this labelling, and it helps to keep them apart. Service level (SvcLvl) names the rulebook the payment runs under — for a euro retail payment that is the code SEPA. Local instrument (LclInstrm) narrows that to a variant, such as INST for SEPA Instant. Category purpose (CtgyPurp) tells the banks in the chain what kind of payment this is — SALA for salary, SUPP for a supplier — so they can apply special handling. Purpose (Purp) states the reason for the payment for the creditor's benefit, carried unchanged from debtor to beneficiary. On top of these, instruction priority (InstrPrty) is a coarse urgent/normal flag. The useful mental model: service level and local instrument say 'how it is carried', category purpose says 'what kind, for the banks', and purpose says 'why, for the customer'.

L2 Practitioner view

Two confusions cause most mistakes. First, category purpose versus purpose: they draw on overlapping 4-letter code lists (both can say SALA), but category purpose is read by the banks to route or prioritise, while purpose is informational for the creditor. Putting the reason only in one of them, or assuming a bank acts on the customer-facing purpose, misfires. Second, charge bearer: the ChrgBr element decides who pays the banks' fees — DEBT (debtor pays all, the beneficiary gets the full amount), CRED (creditor pays all), SHAR (each side pays its own), or SLEV (follow the service level, which the SEPA schemes require). These map to the MT103's OUR / BEN / SHA. Reading a payment well means reading these labels together: the service level sets the rules, the purpose codes set the intent, and the charge bearer sets who pays for the trip.

L3 Technical details

The codes themselves live in ISO 20022 external code sets — lists maintained separately from the message schemas so new codes can be added without reissuing every message version; they are refreshed quarterly. Service level, category purpose, and purpose values (SEPA, SALA, SUPP, INTC, CORT, and many more) come from these external lists; charge bearer, settlement method (INDA/INGA/CLRG/COVE), and instruction priority (HIGH/NORM) are defined in the base message schema. Which values are valid on a given rail is narrowed further by that rail's usage guideline: the SEPA rulebooks, for example, require service level SEPA and charge bearer SLEV and restrict the rest. The full, current code lists are on iso20022.org; the reference here is a curated practitioner subset.

Sources & standards1
  1. Official requirement

    ISO 20022 External code setsISO 20022 Registration Authority · service level, category purpose, purpose external code sets

    Defines the externally maintained code lists (for example category purpose, status reason, and return reason codes) referenced by ISO 20022 payment messages. · Checked 2026-07-12

    Updated quarterly (end of February, May, August, and November) in XLSX, XSD, and JSON formats; always check the latest published version for valid codes.

L4 Standards & sources

The governing sources are the ISO 20022 External Code Sets (published on iso20022.org and updated each quarter — February, May, August, November) for the externalised code lists, the ISO 20022 message definitions for the schema-defined codes such as charge bearer and settlement method, and each rail's usage guideline for what is actually permitted. The CBPR+ guidelines govern cross-border interbank use; the EPC rulebooks govern the SEPA schemes, where they fix service level SEPA, charge bearer SLEV, and the instant variant's local instrument. In practice: never assume a code is valid just because it exists in the external list — confirm it against the usage guideline for the rail the payment travels, and check which quarterly release of the external code set your validation is built against.

Sources & standards2
  1. Official requirement

    ISO 20022 External code setsISO 20022 Registration Authority · External Code Sets quarterly release

    Defines the externally maintained code lists (for example category purpose, status reason, and return reason codes) referenced by ISO 20022 payment messages. · Checked 2026-07-12

    Updated quarterly (end of February, May, August, and November) in XLSX, XSD, and JSON formats; always check the latest published version for valid codes.

  2. Official requirement

    Cross-Border Payments and Reporting Plus (CBPR+) usage guidelinesSwift (CBPR+ working group) · permitted code values for cross-border payments

    Defines how ISO 20022 messages (including pacs.008, pacs.009, pacs.002, pacs.004, and camt investigation messages) are used and validated for cross-border payments on the Swift network. · Checked 2026-07-12

    Full guidelines require MyStandards access; content here relies on public summaries. MT-to-CBPR+ translation rules are published on Swift's translation portal.

THE CODE VALUES

Service level

PmtTpInf/SvcLvl/Cd

Names the rulebook or agreed service the payment runs under — 'under which scheme'. It tells every agent which obligations, timings, and validation apply.

Service level codes
CODENAMEMEANING
SEPASEPA schemeThe payment follows a SEPA scheme rulebook.Mandatory on SEPA credit transfers; paired with local instrument INST for the instant scheme.
SDVASame day valueThe creditor is to receive value the same day the payment is made.
URGPUrgent paymentThe payment is to be treated as urgent.
PRPTEBA priority serviceThe EBA priority (PRIEURO) service level.
NURGNon-urgent paymentThe payment is explicitly non-urgent (normal handling).
G001gpiThe payment is tracked under SWIFT gpi (further G002–G004 values narrow the gpi service).Used in cross-border interbank messages, not customer initiation.
Sources for Service level3
  1. Official requirement

    ISO 20022 External code setsISO 20022 Registration Authority

    Defines the externally maintained code lists (for example category purpose, status reason, and return reason codes) referenced by ISO 20022 payment messages. · Checked 2026-07-12

    Updated quarterly (end of February, May, August, and November) in XLSX, XSD, and JSON formats; always check the latest published version for valid codes.

  2. Scheme-specific rule2025 version 1.1 (EPC125-05)

    2025 SEPA Credit Transfer rulebookEuropean Payments Council

    Governs the SEPA Credit Transfer scheme: participant obligations, datasets, time cycles, and r-transaction rules for euro credit transfers. · Effective 2025-10-05 · Checked 2026-07-12

    Version 1.1 replaced version 1.0 at publication on 5 October 2025 and is stated to remain in effect up to 21 November 2027. It moves the date from which the unstructured address format is no longer permitted to 15 November 2026.

  3. Simplified educational illustration

    Payments Signal editorial teaching modelsPayments Signal

    This site's own simplified teaching models. · Checked 2026-07-12

    What this simplifies: A curated subset of the commonly-used codes with plain-language meanings — not the full externally-maintained list, which is updated quarterly (Feb/May/Aug/Nov) on iso20022.org.

    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.

Local instrument

PmtTpInf/LclInstrm/Cd

Narrows the service level to a specific clearing variant — 'which variant of the scheme'. Values are largely community- or scheme-specific.

Local instrument codes
CODENAMEMEANING
INSTInstantThe SEPA Instant Credit Transfer variant (settlement in seconds, 24/7).Used with service level SEPA on SCT Inst.
CORESDD CoreThe SEPA Direct Debit Core scheme (consumer direct debits).
B2BSDD B2BThe SEPA Direct Debit Business-to-Business scheme (no refund right).
Sources for Local instrument3
  1. Official requirement

    ISO 20022 External code setsISO 20022 Registration Authority

    Defines the externally maintained code lists (for example category purpose, status reason, and return reason codes) referenced by ISO 20022 payment messages. · Checked 2026-07-12

    Updated quarterly (end of February, May, August, and November) in XLSX, XSD, and JSON formats; always check the latest published version for valid codes.

  2. Scheme-specific rule2025 version 1.1 (EPC125-05)

    2025 SEPA Credit Transfer rulebookEuropean Payments Council

    Governs the SEPA Credit Transfer scheme: participant obligations, datasets, time cycles, and r-transaction rules for euro credit transfers. · Effective 2025-10-05 · Checked 2026-07-12

    Version 1.1 replaced version 1.0 at publication on 5 October 2025 and is stated to remain in effect up to 21 November 2027. It moves the date from which the unstructured address format is no longer permitted to 15 November 2026.

  3. Simplified educational illustration

    Payments Signal editorial teaching modelsPayments Signal

    This site's own simplified teaching models. · Checked 2026-07-12

    What this simplifies: A curated subset of the commonly-used codes with plain-language meanings — not the full externally-maintained list, which is updated quarterly (Feb/May/Aug/Nov) on iso20022.org.

    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.

Category purpose

PmtTpInf/CtgyPurp/Cd

The high-level kind of payment, read by the banks in the chain to apply special handling or routing — 'what kind of payment, for the banks'. Distinct from Purpose (customer-facing).

Category purpose codes
CODENAMEMEANING
SUPPSupplier paymentPayment to a supplier for goods or services.
SALASalary paymentPayroll — often triggers priority or bulk handling.Some banks give SALA batches dedicated processing windows.
PENSPension paymentPayment of a pension.
SSBESocial security benefitA government benefit paid to an individual.
TAXSTax paymentPayment of taxes.
INTCIntra-company paymentA payment between two entities of the same group.
TREATreasury paymentA treasury/liquidity-management payment between financial parties.
CORTTrade settlementSettlement of a trade (e.g. the cash leg of an FX or securities trade).
DIVIDividendPayment of a dividend.
GOVTGovernment paymentA payment to or from a government.
CASHCash managementA general cash-management transfer between accounts.
TRADTrade servicesSettlement of a trade-finance transaction.
LOANLoanTransfer of a loan to a borrower.
EPAYePaymentA payment made through online banking.
Sources for Category purpose2
  1. Official requirement

    ISO 20022 External code setsISO 20022 Registration Authority

    Defines the externally maintained code lists (for example category purpose, status reason, and return reason codes) referenced by ISO 20022 payment messages. · Checked 2026-07-12

    Updated quarterly (end of February, May, August, and November) in XLSX, XSD, and JSON formats; always check the latest published version for valid codes.

  2. Simplified educational illustration

    Payments Signal editorial teaching modelsPayments Signal

    This site's own simplified teaching models. · Checked 2026-07-12

    What this simplifies: A curated subset of the commonly-used codes with plain-language meanings — not the full externally-maintained list, which is updated quarterly (Feb/May/Aug/Nov) on iso20022.org.

    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.

Purpose

Purp/Cd

The reason for the payment stated by the debtor and carried unchanged to the creditor — 'why, for the customer'. Informational; the creditor's system can auto-post on it. Not used by the banks to route.

Purpose codes
CODENAMEMEANING
SUPPSupplier paymentPayment of a supplier invoice.
GDDSPurchase of goodsPayment for goods.
SCVEPurchase of servicesPayment for services.
TRADTrade servicesTrade-related payment.
SALASalary paymentSalary paid to an employee.
RENTRentPayment of rent.
LOANLoanLoan disbursement or repayment.
CHARCharity paymentA charitable donation.
TAXSTax paymentPayment of taxes.
INSUInsurance premiumPayment of an insurance premium.
ELECElectricity billPayment of an electricity bill.
GASBGas billPayment of a gas bill.
WTERWater billPayment of a water bill.
Sources for Purpose2
  1. Official requirement

    ISO 20022 External code setsISO 20022 Registration Authority

    Defines the externally maintained code lists (for example category purpose, status reason, and return reason codes) referenced by ISO 20022 payment messages. · Checked 2026-07-12

    Updated quarterly (end of February, May, August, and November) in XLSX, XSD, and JSON formats; always check the latest published version for valid codes.

  2. Simplified educational illustration

    Payments Signal editorial teaching modelsPayments Signal

    This site's own simplified teaching models. · Checked 2026-07-12

    What this simplifies: A curated subset of the commonly-used codes with plain-language meanings — not the full externally-maintained list, which is updated quarterly (Feb/May/Aug/Nov) on iso20022.org.

    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.

Charge bearer

ChrgBr

Who pays the banks' fees on the payment. The ISO codes correspond to the MT103's field 71A values OUR / BEN / SHA.

Charge bearer codes
CODENAMEMEANING
DEBTBorne by debtorThe debtor pays all transaction charges (MT: OUR).The creditor receives the full instructed amount.
CREDBorne by creditorThe creditor pays all transaction charges (MT: BEN).
SHARSharedEach side pays its own side's charges (MT: SHA).
SLEVFollowing service levelCharges follow whatever the scheme's service level prescribes.The SEPA schemes require SLEV.
Sources for Charge bearer2
  1. Official requirement

    ISO 20022 Catalogue of messagesISO 20022 Registration Authority

    Defines the current versions of all ISO 20022 message definitions, including the pain, pacs, and camt messages taught on this site. · Checked 2026-07-12

    Each message set is described by a Message Definition Report; earlier versions remain available in the ISO 20022 messages archive.

  2. Simplified educational illustration

    Payments Signal editorial teaching modelsPayments Signal

    This site's own simplified teaching models. · Checked 2026-07-12

    What this simplifies: A curated subset of the commonly-used codes with plain-language meanings — not the full externally-maintained list, which is updated quarterly (Feb/May/Aug/Nov) on iso20022.org.

    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.

MESSAGES INVOLVED

Sources for this topic4
  1. Official requirement

    ISO 20022 External code setsISO 20022 Registration Authority · service level, local instrument, category purpose, purpose code sets

    Defines the externally maintained code lists (for example category purpose, status reason, and return reason codes) referenced by ISO 20022 payment messages. · Checked 2026-07-12

    Updated quarterly (end of February, May, August, and November) in XLSX, XSD, and JSON formats; always check the latest published version for valid codes.

  2. Official requirement

    ISO 20022 Catalogue of messagesISO 20022 Registration Authority · charge bearer, settlement method, instruction priority in the base schema

    Defines the current versions of all ISO 20022 message definitions, including the pain, pacs, and camt messages taught on this site. · Checked 2026-07-12

    Each message set is described by a Message Definition Report; earlier versions remain available in the ISO 20022 messages archive.

  3. Scheme-specific rule2025 version 1.1 (EPC125-05)

    2025 SEPA Credit Transfer rulebookEuropean Payments Council · SEPA required service level and charge bearer

    Governs the SEPA Credit Transfer scheme: participant obligations, datasets, time cycles, and r-transaction rules for euro credit transfers. · Effective 2025-10-05 · Checked 2026-07-12

    Version 1.1 replaced version 1.0 at publication on 5 October 2025 and is stated to remain in effect up to 21 November 2027. It moves the date from which the unstructured address format is no longer permitted to 15 November 2026.

  4. Simplified educational illustration

    Payments Signal editorial teaching modelsPayments Signal

    This site's own simplified teaching models. · Checked 2026-07-12

    What this simplifies: The parcel-label analogy and the curated code subset simplify externally-maintained lists that are updated quarterly and narrowed per rail; always confirm against the current external code set and the usage guideline in force.

    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.

Deepest material on this page: L4 Standards & sources. Where a topic stops short of implementation depth, that is a deliberate coverage decision, not an oversight — see coverage.