ISO 20022 Can Standardize the Message and Still Not Settle the Payment.
A richer payment message can improve identification, screening and reconciliation, but it does not determine who is allowed to pay, who accepts the message or when value becomes final. The article makes standard, rail and bank authority visible rather than letting a format migration wear a settlement badge.
The rule
A standard tells you what a field means; it does not tell you that the payment happened.
The Format Has Arrived, Wearing a Settlement Badge
There is a moment in a payments migration when an otherwise sensible institution becomes convinced that a better message has improved the payment itself.
Your new pacs instruction has party data, structured remittance information, identifiers, timestamps and a sufficiently handsome XML pedigree.
Somebody describes the programme as an ISO 20022 settlement upgrade.
Several people nod, because the alternative is asking which part was upgraded.
It is worth asking.
ISO 20022 supplies a common model and message definitions.
Your rail supplies a local profile, validation rules, routing, cut-offs and settlement procedure.
Your payer bank decides whether its customer may give the instruction.
Your receiving bank decides whether it can accept and post it.
Your system rules decide when value becomes final.
Not four descriptions of one event.
Four authorities holding different opinions about a payment, as institutions so often do when a noun has been asked to carry a verb.
The migration dates have not helped the optimism.
Swift’s CBPR+ coexistence for payment instructions ended in November 2025.
Fedwire adopted ISO 20022 in July 2025.
Meaningful implementation events, in named scopes.
Neither means every participant, payment product, message profile, correspondent route or receiving account has quietly become a guaranteed settlement mechanism.
Swift is a cooperative, a network and a standards-service provider.
ISO 20022 is an international financial-message scheme.
They have excellent reasons to appear in the same conversation.
They are not the same conversation.
Pedantic?
Certainly.
It is also what keeps your money from becoming an investigation.
A Message Definition Is Not a Message
An ISO 20022 artefact has a business area, a message identifier, a version, business components, data types, a schema and a lifecycle status.
The message definition is the published form.
The message instance you transmitted is the occurrence.
Actual debtor.
Actual creditor.
Actual amount.
Actual date.
Saving ISO 20022 in your technical inventory is rather like recording English as the terms of a contract.
It gives the reader a sporting chance. It does not give them an interface.
For a pacs payment message, keep the exact version. Whether it is a credit transfer or a return.
The business-application header convention.
The usage guideline or market-practice release that restricts it.
Swift’s initial CBPR+ release introduced 15 usage guidelines across pain, pacs and camt material.
One standard family becomes several disciplined local dialects on your desk before breakfast.
The payment-system operator, market infrastructure or software vendor is authoritative for the accepted local profile, the certification test and the production release.
ISO is authoritative for the common model.
There is no official ISO 20022 certification authority.
Which makes certified ISO 20022 a phrase needing a named community and a test programme before it enters a steering-committee deck.
So build a record rather than a souvenir.
The twelve payment-message controls are complete: message version; debtor; creditor; account identifiers; agent identifiers; amount; currency; purpose; remittance data; timestamp; status code; settlement reference.
They establish what instruction moved through your machinery, whom it named, what it claimed to be for, and what happened to it.
They do not give every field the same authority.
A creditor name may be supplied by your payer.
An account identifier may be structurally valid.
An agent identifier may identify an operational party.
A status code may describe a rail event.
None of them is a universal affidavit of identity, authority or completion.
The familiar identifiers are particularly good at being mistaken for certificates of good character.
An IBAN begins with 2 country letters and 2 check digits, followed by up to 30 further characters.
Normalise the spaces and case, check the country length, apply the modulus-97 check, and you have established structural validity.
You have not established that the account exists.
Or that it belongs to the stated creditor.
Or that it can accept a credit.
Or that it is unrestricted.
Or that it has passed sanctions screening.
A maximum length is not a promise that every string of that length is useful.
The national record decides your permitted length and pattern. Exactly the sort of detail that sounds tiresome until a payment is held and Operations is asked whether valid meant real.
BICs want the same adult supervision.
ISO 9362 gives the core BIC 8 characters, with an optional 3-character branch identifier.
A connected BIC has access to the Swift network. A non-connected BIC has no authorisation to exchange messages there.
Neither fact proves its owner holds the beneficiary account, is a licensed bank in a particular jurisdiction, or is the beneficiary’s legal owner.
A BIC is not an LEI either.
An LEI identifies one legal entity through a 20-character code and its linked reference data.
A neat identifier field is a valuable thing. It is not a settlement asset.
The Payment Has Gates, and None Is Optional
Start with your customer’s authority.
Your account contract says how instructions bind you.
Device binding, login history, biometric result, one-time code or signed mandate may all become your evidence.
Authentication establishes that a credential was presented.
Authorisation decides whether that credential may order this payment, to this payee, at this time.
A bank can authenticate a customer perfectly and still be handling a customer-authorised payment induced by a fraudster.
ISO 20022 cannot adjudicate that commercial misery.
It has a much narrower and more useful job.
Next comes your operating decision as payer bank.
On a €2,400 credit transfer, your bank applies format, authority, balance, fraud, sanctions and cut-off checks.
It may reserve the amount, reject the instruction, or accept it for later execution.
The reserve stops your buyer spending the same €2,400 twice. The receiving bank has no claim merely because you applied that control.
Debiting the account and releasing the message is a real event on your balance sheet.
It is not necessarily final payment.
You can reverse a customer-ledger posting under your contract.
The system can reject a message before settlement.
Then your rail validates and routes.
Its rulebook covers your membership, message syntax, routing, cut-offs, rejection codes, returns, settlement, fees, security, audits and participant default.
It can acknowledge receipt and accept an instruction into a queue.
It does not thereby become your customer’s account contract, any more than the account contract becomes a participant-default procedure.
PFMI Principle 23 expects clear, comprehensive rules and procedures, participant information about risks, fees and material costs, and public disclosure of relevant rules and key procedures.
Sensible institutional plumbing.
It does not mean a green validation response has acquired legal finality by enthusiasm.
Liquidity supplies another gate, usually absent from your migration presentation because it has poor typography.
Where a bank holds settlement funds already committed to queued payments, the next instruction needs more liquidity, offsetting incoming payments, credit, collateral, or a decision to defer.
Your payer’s account may already be debited.
The message may validate beautifully.
The receiving bank still has no funded claim.
A rich message is not cash.
An inconvenient conclusion for a format programme, and a useful one for Treasury.
Finally your receiving bank decides whether it can act.
It checks that it is reachable, that the account is open, and that the message can be posted.
A bad account number, a closed account or a sanctions match can cause a rejection, or a later return.
That distinction is worth preserving.
A rejection is a refusal before completion, or a failure of it.
It is not your recall of settled funds.
The recall comes after the money has done its work and somebody would like a different answer. The rejection is the machinery saying no before it has.
Status Is a Fact About a Stage
Do not store a single cheerful field called payment_status.
Store your status as a dated statement, by an authority, about a stage.
Not submitted.
Rejected.
Accepted.
Settled.
Four distinct states.
A rail’s acceptance status says it has accepted an instruction under its rules.
A receiving bank’s posting status says something about its account processing.
A settlement reference connects the instruction to the transfer of the interbank asset.
A customer notification can be useful to you.
It is not a cross-examination of every downstream account.
In an instant-settlement flow, the service debits one bank’s settlement account and credits another’s.
In central-bank settlement, those are banks’ claims on the central bank.
They are not customer deposits.
FedNow processes and settles individual payments within seconds, around the clock, every day of the year, by debit and credit entries to participating institutions’ master accounts.
A defined service characteristic.
It tells your reader far more than a screen saying ISO 20022 sent.
Finality is the decisive gate.
PFMI Principle 8 calls for clear and certain final settlement at least by the end of the value date, with intraday or real-time finality where needed or preferable.
Before finality, participant default, insufficient liquidity or technical rejection leaves your receiver unpaid.
After it, the rules stop the payer’s insolvency officer reaching backward and converting completed transfers into a group activity.
In a real-time system, finality may arrive one message at a time. In deferred net settlement it may arrive at a settlement cycle.
So a 16:00 cut-off can separate an accepted payment from an overnight exposure.
The status is not wrong. It is speaking about a smaller fact.
Your receiving bank may then make the customer balance usable.
Available, booked and final can differ.
A bank can make a credit available before settlement and carry rejection or unwind risk.
It can receive final settlement and delay customer use for a fraud review or an account restriction, subject to law and contract.
After a late error, your payer bank can ask the receiving bank to return funds.
It cannot ordinarily pull back a finally settled transfer because its customer regrets an identifier typed that afternoon.
Not a defect in the message format.
It is what finality is for.
Preserve the Argument, Not Just the Last XML File
Message transformation is where a dignified standard becomes an operational adventure.
An original message can be validated.
Translated through a gateway.
Enriched by a vendor or internal system.
Constrained to a rail profile.
Repaired manually.
Rejected.
Re-submitted.
And finally associated with a settlement reference.
Overwrite the first instance with the last and you have kept a conclusion and disposed of the argument.
Auditors are not always charmed by this literary approach.
Keep your original and every transformed message.
The exact version.
The usage guideline.
The validation result.
The screening outcome.
The routing decision.
The timestamp.
The status transition.
The settlement reference.
Preserve the source of every added or changed field.
A poor map of yours turns a legally valid instruction into a misrouted payment, or one held for repair.
A map between related financial standards is not semantically lossless merely because both sides contain parties, amounts, dates and status.
pain, pacs and camt can coexist in one business process without becoming interchangeable containers.
Then turn your exceptions into a dataset.
The complete control classification is message validation; customer authority; fraud or sanctions screening; participant routing; liquidity; receiving-account posting; settlement; reconciliation.
For each break, keep the relevant message and status, the time, the affected account or participant, the transformation path, the error or return code, the repair action, and a named owner.
A sanctions hold is not a schema error.
A queue caused by insufficient liquidity is not a receiving-bank refusal.
An invoice reference that will not match after final credit is not an interbank settlement failure.
All three look equally red on a dashboard, which is why dashboards have occasionally been known to overstate their legal education.
Manual repair belongs at the bottom of the hierarchy.
A named operations owner needs documented authority, and the record needs the original message, the changed field, the reason, the evidence, the time, the required approval, and the resulting version or status.
The repair may make a message processable.
It cannot invent payer authority.
It cannot compel your receiving bank to accept it. It cannot cure a sanctions match, create liquidity, or pronounce settlement final.
That last function is not available in the dropdown.
The Ladder, Before the Format Takes Credit
Message version or field meaning?
Read the published standard, not your mapping note.
Message validation or local profile?
Go to the rail.
Payment authorisation?
Ask your payer bank.
Execution acceptance?
Ask your receiving bank.
Settlement finality?
Read your system rules.
Data enrichment?
Inspect your vendor or internal system.
Manual repair?
Demand a named operations owner.
A standard tells you what a field means; it does not tell you that the payment happened.
What the paper establishes
- ISO 20022 message definitions, local usage guidelines, and transmitted payment instances must be recorded as separate objects.
- A payment record needs message version, debtor, creditor, account identifiers, agent identifiers, amount, currency, purpose, remittance data, timestamp, status code, and settlement reference.
- Structural validation of an account identifier does not prove account ownership, payee identity, sanctions clearance, credit availability, or receiving-bank acceptance.
- Payment authorization belongs to the payer bank under its customer authority and controls, while execution acceptance belongs to the receiving bank and the rail under their own rules.
- Original and transformed messages, usage guidelines, validation results, screening outcomes, and status transitions must be retained so a payment can be reconstructed.
- Validation, screening, routing, liquidity, account-posting, and settlement failures require separate classifications and named operational owners.
- A status code or customer notification must be reconciled to the actual customer-account movement and the system-defined settlement reference before completion is claimed.
- Manual message repair requires a named operations owner, retained authority evidence, and an auditable reason for the change.
Questions
- Does ISO 20022 mean that a payment has settled?
- No. ISO 20022 defines financial message models and message definitions; a transmitted message instance carries parties, amounts, dates, and other payment data. Settlement occurs only when the relevant payment system applies its own settlement process and reaches its defined point of finality. A correctly structured message can still be rejected, queued, screened, returned, or left unsettled for lack of liquidity.
- What information should an ISO 20022 payment record keep?
- A payment record keeps the message version, debtor, creditor, account identifiers, agent identifiers, amount, currency, purpose, remittance data, timestamp, status code, and settlement reference. It also retains the original message, each transformed version, the applicable usage guideline, validation result, screening outcome, routing decision, and status-transition history. Those records allow operations to distinguish a message defect from an uncompleted payment.
- If an IBAN passes its check digits, is the beneficiary verified?
- No. An IBAN check validates the nationally defined format and calculation after spaces and case are normalized. It does not prove that an account exists, belongs to the named payee, can receive a credit, has passed sanctions screening, or will be accepted by the receiving bank. The servicing bank or a controlled verification service provides account-status evidence where jurisdiction and consent permit it.
- Who decides whether a customer is allowed to make the payment?
- The payer bank decides whether to treat an instruction as authorized under the account agreement and its controls. Authentication establishes that a credential was presented; authorization determines whether that credential is permitted to order the particular payment. The payer bank also applies format, balance, fraud, sanctions, and cut-off checks. A message standard does not grant customer authority or require the bank to execute it.
- Who decides whether the receiving side accepts the message?
- The receiving bank and the payment rail apply their own acceptance conditions. The operator validates participant and format rules, while the receiving side checks reachability, account status, posting capability, and applicable controls such as sanctions screening. A payment can be authorized by the payer bank and still be rejected or returned because the receiving account is closed, unavailable, restricted, or incompatible with the rail’s rules.
- Can a payment show as sent even though no bank has been paid?
- Yes. A customer-facing status can mean that the payer bank accepted an instruction or released a message. It does not establish that the receiving bank has a funded claim. Before settlement, a transfer can be queued for liquidity, rejected by the system, or stopped by a control. Completion requires reconciliation to the relevant customer-account movement and the payment system’s settlement reference and finality rule.
- Why does a richer payment message still get stopped for screening?
- Richer party, account, purpose, and remittance data can improve identification and make screening and reconciliation more precise. It does not remove the payer bank’s, receiving bank’s, or intermediary’s obligation to apply their controls. A sanctions match, fraud concern, account restriction, or policy exception can hold or reject a message whose fields are complete and structurally valid.
- What is the difference between a rejected payment and a recall?
- A rejection is a refusal before, or a failure of, completion under the applicable processing rules. A recall is a request concerning a payment after settlement. After final settlement, the payer bank cannot ordinarily pull the funds back unilaterally merely because the payer regrets the instruction. The receiving bank’s response depends on law, contract, facts, and the rail’s procedures.
- Why must the original payment message be kept after it is converted?
- The original message preserves what the sending party actually instructed. Each transformed message preserves how a gateway, vendor, or internal system mapped, enriched, normalized, or repaired that instruction. Keeping both, with the message version and applicable usage guideline, makes it possible to reproduce a rejection, identify a lost field, and distinguish a source-data error from a transformation or local-profile error.
- How should a payment team classify a failed ISO 20022 payment?
- A payment team classifies the failure by layer: message validation, customer authority, fraud or sanctions screening, participant routing, liquidity, receiving-account posting, settlement, or reconciliation. The classification records the relevant message and status, time, affected account or participant, and named owner. Treating every exception as a generic payment failure hides whether the repair belongs to data, compliance, operations, a bank, or the rail.
- Who is allowed to repair a payment message by hand?
- A named operations owner repairs a payment message only under documented authority and an auditable repair procedure. The record retains the original message, changed field, reason, evidence, time, approver where required, and resulting message version or status. Manual repair can make an instruction processable, but it cannot create payer authority, override a receiving-bank refusal, or declare settlement final.
- When does a payment become final?
- A payment becomes final at the point defined by the applicable payment system’s finality rules, not when a message adopts ISO 20022 or when a customer app displays a status. PFMI Principle 8 calls for clear and certain final settlement at least by the end of the value date, with intraday or real-time finality where necessary or preferable. The rule identifies when an interparticipant exposure becomes protected from ordinary unwinding.