ISO 20022 migration: what changes in a payment message
Where the structured data comes from, and what truncation costs.
Read the guide →
Resource center · Structured Data & Messaging
Message validation: schema, scheme rules and rejections.
Almost every messaging incident starts with the same sentence: the message is valid, so why was it rejected? Because validity is only the first of four layers, and the later ones belong to somebody else.
The four layers
| Layer | Tests | Applied by |
|---|---|---|
| Well-formedness | That the document parses at all — encoding, structure, reserved characters. | Your own systems, before sending |
| Schema validity | That elements, types, cardinalities and enumerations conform to the message definition and version. | The schema |
| Scheme rules | That the message conforms to the usage guideline: which optional elements are mandatory here, which are forbidden, permitted character sets, field lengths and value constraints. | The scheme or market infrastructure |
| Business rules | That the instruction can actually be carried out — account status, sanctions and screening, limits, currency and value date. | The receiving institution |
A message can clear the first two and fail the third or fourth, which is why “it validates” is never the same statement as “it will be accepted”.
Why scheme rules bite hardest
The standard is deliberately permissive: it defines what a message can carry so that many communities can use it. The scheme then narrows that dramatically. Elements optional in the schema become mandatory. Elements present in the schema are forbidden. Character sets are restricted, so an accented name that is perfectly valid in the schema is rejected by the scheme. Lengths are cut below the schema maximum, so a value that fits is still too long.
Build against the usage guideline, not the schema. A generator written from the message definition alone will produce schema-valid messages that the scheme rejects, and the defect surfaces only once traffic is live.
Rejection, return and cancellation
Three outcomes are frequently conflated and have completely different consequences.
- Rejection — the message was not accepted and the payment never entered the system. Nothing moved. The status report carries a reason code.
- Return — the payment was processed and then sent back, because it could not be applied at the beneficiary end. Funds moved twice.
- Cancellation — a request to stop a payment already sent. It is a request, not an instruction, and it can be refused.
The accounting, the customer communication and the repair path differ in each case. A system that treats all three as “failed” will misstate positions and mislead the operations team.
The repair path
- Read the reason code against the scheme’s published list rather than inferring meaning from the accompanying text.
- Classify the cause — source data, mapping, scheme constraint, or a genuine business condition at the receiving end.
- Fix at the right level. Source data defects belong in the system of record; scheme constraints belong in the generator; one-off business conditions belong with the customer.
- Resend under the scheme’s rules, with a new message identifier where required and the original references preserved where they must be.
- Retain the evidence — the rejected message, the reason code and the repair — because payment investigations arrive long after the event.
Official sources
Primary instruments only. Each is named in full so the reference remains traceable even if a link moves.
- ISO 20022 — message definitions and schemas maintained by the registration authorityISO · the schema layer
- Regulation (EU) No 260/2012 establishing technical and business requirements for credit transfers and direct debits in euroEUR-Lex · Regulation · requirements applying to euro credit transfers and direct debits
- The applicable scheme rulebook, implementation guidelines and reason code listScheme · the layer that produces most rejections · consult the version in force
Questions, answered
Our message validates against the schema but the scheme rejects it. Why?
The schema defines what the standard permits; the scheme usage guideline defines what this particular community requires. Optional elements become mandatory, some are forbidden, and character sets and lengths are restricted below the schema maximum. Build the generator from the usage guideline.
Is a returned payment the same as a rejected one?
No, and the distinction matters for both accounting and customer communication. A rejection means the payment never entered the system and no funds moved. A return means it was processed and then sent back, so funds moved twice and a separate message carries the return.
Can we just edit the message and resend it?
Only if the defect is genuinely in the message rather than in what produced it. Editing an output leaves the underlying cause in place, so the next message fails the same way, and the change is lost when the message is regenerated. Fix the source or the mapping.
How long should we keep rejection records?
Long enough to answer a payment investigation, which typically arrives well after the event and asks what was sent, what came back and why. Retain the message, the reason code and the repair together, and follow the retention period your own obligations and scheme rules set.
REGREP is an independent software provider. This record explains a reporting framework in plain language and is not legal, tax or regulatory advice. Confirm scope, thresholds and submission dates with your competent authority before you file.
Keep reading
More on this framework, and the module that produces the filing.
Message types in ISO 20022: pain, pacs and camt
Which message carries a status report, a return or a cancellation.
See the reference →Reading a REGREP validation report
The same layered model, applied to regulatory filings.
Read the guide →Build against the guideline, not the schema.
We scope messaging work around the scheme you send to, including the exception path that usually gets left until last.