Payment Message Validation

Payment message validation is the series of automated checks that a payment instruction must pass before a bank, payment processor or clearing system will accept and process it. The checks confirm that the message is correctly formed, that each field holds allowed values, that bank and account identifiers are genuine, and that the combination of data makes business sense. A message that fails is rejected back to the sender or routed for manual repair.

Validation happens at several points: in the customer's banking software, at the sending bank, on the network, and at each receiving institution. It is distinct from sanctions screening and fraud checks, which ask whether a payment should be made at all, though all three usually run in the same processing pipeline. Since most high-value and cross-border systems moved to ISO 20022 formatted messages, validation has become stricter and more detailed.

Think of the checks a post office makes before accepting a parcel. Is it a box of an allowed size? Is there an address, and is the postcode a real one? Does the name of the town match the postcode? Has a stamp been added? A parcel that fails goes back to the sender or to a desk where staff fix the label.

Banks do the same with payments, only faster and by computer. They check that the instruction is in the right layout, that every required box is filled, that the bank code and account number exist and fit together, and that the amount and date are sensible. Catching mistakes at the door is far cheaper than chasing a payment that has gone to the wrong place.

1. Syntax. The message must match its schema, for ISO 20022 an XML Schema Definition (XSD) for the exact message version, with correct element order, data types and field lengths, such as a maximum of 35 characters for many references.
2. Character set. Many schemes restrict characters, for example to a limited Latin set, so that the text survives every system on the route.
3. Usage rules. Market guidelines such as Swift CBPR+ or a domestic scheme's rulebook narrow the standard further, making some optional fields mandatory and forbidding others.
4. Header consistency. The ISO 20022 Business Application Header (BAH) must name the same message type as the document and identify valid parties.
5. Reference data. Identifiers are checked against directories: a Bank Identifier Code (BIC) must exist and be reachable, and an International Bank Account Number (IBAN) must have valid check digits and the right length for its country.
6. Business rules. Cross-field checks, such as the settlement date not being in the past, the currency being supported, charges codes being allowed and the amount being within limits.
7. Duplicate checks. Repeated message or transaction identifiers are caught so the same payment is not processed twice, often supported by an idempotency key in API channels.

One of the most widely used checks is the IBAN check-digit test defined in ISO 13616, which catches most typing errors. The account number is rearranged by moving the first four characters to the end, each letter is replaced by two digits (A = 10, B = 11, up to Z = 35), and the result is treated as one large number $N$. The IBAN is valid only if:

Here $N$ is the rearranged, all-digit form of the IBAN, and $\bmod 97$ means the remainder after dividing by 97.

For the sample IBAN GB82 WEST 1234 5698 7654 32, moving "GB82" to the end gives WEST12345698765432GB82. Converting the letters (W = 32, E = 14, S = 28, T = 29, G = 16, B = 11) gives 3214282912345698765432161182. Dividing by 97 leaves a remainder of 1, so the IBAN passes. An IBAN checker runs the same calculation. Passing proves only that the number is well formed, not that the account exists or belongs to the named payee; that question is answered by services such as Verification of Payee (VoP).

A failed message is either rejected, with a status report such as an ISO 20022 pacs.002 giving a reason code, or held in a message repair queue for staff to correct. Real-time systems such as FedNow generally reject rather than repair, because the payment must complete in seconds. Errors that slip through validation surface later as a returned payment or a beneficiary-account mismatch, which are slower and more expensive to fix.

The move from SWIFT MT messages to ISO 20022 brought richer and more structured data, such as separate fields for street, town and country in addresses, and schemes have phased in rules requiring that data. Stricter checks raise early rejection rates during migration but improve straight-through processing, screening accuracy and reconciliation later. For payment firms, a clear map of each scheme's rules, kept up to date with each annual release, is a basic part of operating a payment gateway or bank connection.

• ISO 20022
• Swift Standards