ISO 20022 Purpose Codes and Category Purpose

An ISO 20022 payment message carries more than amounts and account numbers. It can also carry a machine-readable answer to a simple but important question: why is this payment being made? Two related fields answer it — purpose and category purpose — and confusing them is a common beginner mistake.

Two codes, two audiences

The distinction comes down to who the information is for.

• Purpose (element Purp) describes the reason for the payment for the benefit of the end parties — typically the debtor and creditor. It travels end to end and is not meant to be changed by the banks in between.
• Category purpose (element CtgyPurp) signals the high-level type of payment to the banks and clearing systems processing it, so they can apply the right handling, routing, or scheme rules.

A helpful way to remember it: purpose is the detailed reason for the people; category purpose is the broad classification for the plumbing.

Where they live in the message

Both appear in the payment information structure of messages such as pain.001 (customer credit transfer initiation) and are carried into interbank messages like pacs.008. Each field is usually expressed as a four-letter code from an externalized ISO 20022 code list, though a proprietary value can be supplied where a scheme permits it. Externalized code lists are published and updated separately from the message schemas, so new codes can be added without reissuing the whole standard.

Purpose codes in practice

Purpose codes are specific. A few widely used examples give the flavour:

• SALA — salary payment.
• SUPP — supplier payment.
• TAXS — tax payment.
• PENS — pension payment.
• DIVD — dividend.
• INTC — intra-company payment.

These help the receiver's systems classify incoming funds automatically — useful for accounting, for triggering downstream processes, and increasingly for regulatory reporting where the reason for a flow must be captured.

Category purpose in practice

Category purpose codes are broader and aimed at processing decisions. Examples include:

• SALA — bulk salary run, which a bank may route through a payroll-optimised path.
• SUPP — supplier payments.
• TAXS — tax.
• CASH — general cash management transfer.
• INTC — intra-company.

Note that some code values, like SALA, exist in both lists. That is deliberate: the same concept can be relevant both as an end-party reason and as a processing hint. The field it sits in determines how it should be read.

Why these codes matter

Structured purpose data unlocks several benefits that free-text descriptions cannot:

• Straight-through processing. A receiver can auto-post a SALA payment to payroll or a TAXS payment to a tax account without human interpretation.
• Regulatory and statistical reporting. Many jurisdictions require the reason for cross-border flows; a coded field is far more reliable than parsing narrative text.
• Scheme-specific handling. Some instant-payment and high-value schemes use category purpose to apply limits, fees, or priority.
• Screening context. Purpose can give compliance systems useful context, though it is never a substitute for proper sanctions screening.

Because the codes come from a controlled external list, both sender and receiver interpret them identically — the whole point of a shared standard. When populating them, the guidance is to use the most accurate code available and to respect each scheme's rules about which codes are supported, since not every rail accepts every value.

Common mistakes to avoid

A few pitfalls recur when teams first work with these fields. The first is conflating the two — putting an end-party reason into category purpose, or vice versa. Remember the audience test: if the information is meant for the banks' processing, it belongs in CtgyPurp; if it is the detailed reason for the debtor and creditor, it belongs in Purp.

A second pitfall is treating the codes as mandatory everywhere. Both fields are generally optional in the base standard, and whether a scheme requires, ignores, or restricts them varies. Sending an unsupported code can cause a payment to be rejected or the value to be silently dropped, so always check the relevant scheme rulebook. A third is inventing proprietary codes when a suitable external code already exists; reach for a proprietary value only when the standard list genuinely has no fit, because proprietary codes lose the interoperability that makes the standard useful in the first place.

Key takeaways

• Purpose (Purp) tells the end parties why a payment is made; category purpose (CtgyPurp) tells the banks its high-level type.
• Both are typically four-letter codes drawn from externalized ISO 20022 code lists updated independently of the schemas.
• Examples include SALA (salary), SUPP (supplier), TAXS (tax), PENS (pension), and DIVD (dividend).
• Some values appear in both lists; the containing field decides how to read them.
• Coded purposes enable straight-through processing, regulatory reporting, and scheme-specific handling that free text cannot.