What Are ISO 20022 Purpose Codes?
ISO 20022 purpose codes (formally ExternalPurpose1Code) are standardised 4-character codes that describe the economic purpose of a payment. They appear in the Purp/Cd element of pacs.008, pain.001, and other payment messages. Unlike SWIFT MT's Field 26T (which was rarely standardised in practice), ISO 20022 purpose codes are formally defined, machine-readable, and increasingly used by central banks and regulators for reporting.
When Are Purpose Codes Mandatory?
Purpose codes are mandatory in specific contexts:
- Singapore PayNow corporate: Certain transaction types (payroll, government payments) require purpose codes
- India RTGS/NEFT cross-border: Purpose codes are mandatory for inbound remittances from Singapore under RBI rules
- Thailand PromptPay cross-border: Specific purpose codes required for SGD-THB corridor
- MAS PSA reporting: Payment purpose is a required field in certain MAS data submissions
Commonly Used Purpose Codes for APAC Payment Teams
| Code | Meaning | When to use |
|---|---|---|
SALA | Salary Payment | Payroll disbursements to employees |
SUPP | Supplier Payment | B2B payments to vendors/suppliers |
TREA | Treasury Payment | Interbank/treasury transfers |
INTC | Intra-Company Payment | Transfers between entities in same corporate group |
GDDS | Purchase Sale of Goods | Trade payment for physical goods |
SVCS | Purchase Sale of Services | Payment for professional/consulting services |
TAXS | Tax Payment | GST, corporate tax, IRAS payments |
PENS | Pension Payment | CPF or pension fund disbursements |
CORT | Trade Settlement Payment | Securities settlement (DVP) |
LOAN | Loan | Drawdown or repayment of loans |
Common Mapping Mistakes from Legacy Systems
Mistake 1: Sending no purpose code
Many legacy payment systems simply leave purpose code empty. For most SWIFT cross-border flows this is technically valid, but receiving correspondent banks in India and Thailand will reject or return payments without required purpose codes. Build mandatory code capture into your payment initiation UI.
Mistake 2: Using OTHR for everything
OTHR (Other) is a valid code but overuse is a red flag for AML reviewers — it suggests your firm is not capturing economic purpose properly. MAS examiners note high OTHR rates in data submissions. Map your internal transaction types to specific codes first; use OTHR only as a true fallback.
Mistake 3: Confusing payment purpose with remittance information
Purpose code (Purp/Cd) describes the economic reason for the payment (salary, trade). Remittance information (RmtInf) is the invoice reference or free-text memo. These go in separate fields. Populating one field's content into the other causes downstream processing errors.
How Regulators Use Purpose Codes
Central banks including MAS and RBI use purpose codes for balance of payments (BoP) statistics. When you send SALA on a cross-border wire, this flows into Singapore's current account statistics for labour income. Incorrect purpose codes distort national economic data and can trigger regulatory queries if patterns look anomalous.
Key Takeaways
- Purpose codes are mandatory for some APAC cross-border corridors (India, Thailand) — check corridor-specific requirements
- Map your internal transaction types to specific ExternalPurpose1Code values; avoid overusing
OTHR - Purpose code and remittance information go in separate fields — do not conflate them
- MAS and RBI use purpose codes for regulatory statistics — wrong codes have downstream reporting consequences
- Build purpose code validation into your payment initiation workflow, not as an optional field