The same pacs.008 can be perfectly valid on one network and rejected on another. That's not a bug in ISO 20022. It's the gap between the standard and the rulebooks that govern how it's actually used.
Read in the interactive Academy →The problem first. An engineer builds a pacs.008 that passes every schema check in her test suite. She sends it into the local RTGS and it sails through. Two weeks later the identical construction, pointed at a correspondent across the border, bounces. Same message type, same fields, same standard.
By now you can read a pacs.008 and you know the header names a rulebook. This article is about a puzzle that trips up nearly everyone once, and it's cleaner to solve it than to be told the answer.
{{think}} Same message. Same fields. Passes the ISO schema. Green light on one network, rejected on the next. Nothing about the XML changed between the two sends.
If the standard says it's valid, how can a network say it isn't? {{reveal}} Because "valid ISO 20022" isn't the bar the network actually checks against. The published standard is deliberately generous — a pacs.008 has hundreds of optional elements so every community on earth can say what it needs. No real network wants all that generosity. So each community publishes a usage guideline: a narrowed-down version that says which fields its members must use, may use, and must not use.
Your message passed the base schema and then failed a stricter rulebook the second network enforces. Schema-valid and guideline-valid are two different tests. {{/think}}
Two of those rulebooks matter more than all the rest combined: CBPR+ and HVPS+.
CBPR+ — Cross-Border Payments and Reporting Plus — is the usage guideline for payments travelling bank-to-bank over Swift, the many-to-many world where any of eleven thousand institutions might message any other. Every cross-border payment you've followed in this Library — Bob's dirhams becoming Sweety's rupees — lives under CBPR+.
A many-to-many network has a particular problem: nobody controls both ends. So CBPR+ has to be precise about things a closed club could leave loose — which settlement methods are allowed (INDA, INGA, and the COVE cover method), and exactly how agents, amounts, and addresses must be written so any receiver, anywhere, can process the message unseen.
HVPS+ — High Value Payment Systems Plus — is the base guideline for market infrastructures: the central-bank-run RTGS systems from earlier in this level. The Eurosystem's T2, the UK's CHAPS, the US Fedwire and CHIPS, Singapore's MEPS+ and their peers all start from HVPS+ and tune it to local law.
{{think}} A market infrastructure is one-to-many: one operator, a defined set of participants, one rule-setter. Correspondent banking is many-to-many: no shared operator, no shared book. Given only that difference, why can an RTGS use a CLRG settlement method that CBPR+ has no use for? {{reveal}} Because a clearing system settles on its own books. Every participant holds an account with the one operator, so "settle through the clearing system" (CLRG) is a meaningful instruction. Bank-to-bank across a border has no shared book to settle on, so it leans on INDA/INGA (settle across an account at an agent) or the COVE cover method instead. The rulebook can only offer what the network's shape makes real. {{/think}}
That flow implies something worth saying out loud: a single end-to-end payment can legitimately pass through both rulebooks. The cross-border leg obeys CBPR+; the final domestic leg obeys the local HVPS+ flavour. The correspondent in the middle isn't translating between languages — it's translating between dialects of the same one.
You've already met the mechanism. The Business Application Header carries a BizSvc (Business Service) element, and that's where a message says which service and rulebook it's travelling under. The receiver reads it off the envelope, before parsing anything, and knows which validation profile to apply. Same letter, different postal regulations, declared on the outside.
{{aside:model|The mental model}} The standard is the language; the rulebook is the accent. A message is never just "valid ISO 20022." It's valid under a guideline — CBPR+ for cross-border over Swift, an HVPS+ flavour for a domestic RTGS. Which guideline applies is the first question of every integration, not the last. {{/aside}}
{{aside:chair|From the engineer's chair}} Read BizSvc on the header (e.g. swift.cbprplus.02) to know which profile to validate against — and validate against the usage guideline, not just the raw schema. If you only test against the base ISO XSD, you'll pass messages the network will reject. The generosity of the standard is exactly the gap a rulebook exists to close. {{/aside}}
{{aside:breaks|Where it breaks}}
{{/aside}}
CLRG arriving on a correspondent leg, or COVE pointed at a clearing system. Each is meaningful only inside its own rulebook.{{aside:map|The map}} Rulebooks sit on top of the standard and the roads:
{{/aside}}
{{aside:ref|Reference card}}
{{/aside}}
INDA, INGA, COVE.CLRG (settle on the system's own books).BizSvc). Validate against the guideline, not just the schema.Where BizSvc lives: the envelope that names the rulebook →
The message both rulebooks constrain: pacs.008 field by field →
What is CBPR+? The usage guideline for ISO 20022 in correspondent banking over Swift
Why do market infrastructures use the CLRG settlement method while CBPR+ does not? A clearing system settles on its own books, an option that doesn't exist bank-to-bank
A pacs.008 passes ISO schema validation but is rejected by the receiving network. What most likely happened? It violated the network's usage guideline, which is stricter than the base standard