The flattening problem
A bank spends two years enriching payment messages, then feeds them into a reconciliation process that reads a concatenated narrative string, because that is what the previous format provided. The structure is discarded at exactly the point where it would have paid for itself, and the repair queue does not move.
Bankautomation reads the message as a message. Structured references are matched as references, party fields as parties, and the end to end id is a first-class key rather than a substring somewhere inside a narrative.
The message families that matter for reconciliation
| Message | Direction | Reconciliation role |
|---|---|---|
| pain.001 | Customer to bank | The instruction as the customer asked for it |
| pacs.008 | Bank to bank | The interbank instruction, carrying the end to end id |
| pacs.002 | Status report | Accepted, rejected or pending, tied to the original |
| pacs.004 | Return | Money coming back, with a reason code and the original reference |
| camt.053 | Statement | What the account actually shows at end of day |
| camt.054 | Notification | Intraday debit and credit advices for pending matching |
| camt.056 | Cancellation request | A recall in flight, which changes what should match |
What structured data does to matching
- End to end id preserved across pacs.008 and camt.053 turns a fuzzy match into an exact one.
- Structured remittance means an invoice reference is a field, not a substring somebody parses with a regular expression.
- Purpose codes let routing and classification rules be written in business terms.
- Proper party fields cut the repairs caused by names and addresses jammed into one line.
- Return reason codes tie a returned payment to its original instruction automatically.
Coexistence is the hard part
For a long stretch, some correspondents send MT and some send MX, and the same payment can arrive in either shape on different legs. That is not a reason to postpone automation, it is a reason to buy a system that reads both natively and reconciles across them, so a truncated MT leg does not break the chain your MX leg established.
The fields that decide whether matching is automatic
A pacs.008 carries a lot and only a handful of elements determine whether your reconciliation matches without a person. Knowing which ones, and verifying that they arrive populated from each source, is more valuable than any amount of rule writing.
| Element | Why matching depends on it | What to verify per source |
|---|---|---|
| EndToEndId | The originator key that should reach the statement entry | That it survives the chain and appears on the statement |
| UETR | Identifies the payment through every hop | Whether the reporting bank carries it onto the statement |
| IntrBkSttlmAmt and Dt | The amount and date a tolerance is measured against | Whether the ledger keys on the same date concept |
| ChrgBr and ChrgsInf | Predicts whether the arriving amount is net | That charges are read on ingestion rather than inferred later |
| RmtInf structured | Carries invoice references usable as secondary keys | Whether it is populated or sent as free text |
None of that requires a project. It requires a sample of real files from each source and an afternoon, and it produces a per source picture that predicts the reconciliation result far more accurately than a vendor benchmark.
Repair rate, and how to make it actionable
A repair is a payment stopped by a field that is missing, malformed or ambiguous. It costs the time to fix and it usually costs a second time, because a repaired payment frequently continues with a rewritten reference and stops matching at the far end. The measurement that turns this from a complaint into a work plan is recording which field caused each repair and counting by field for a month.
The list is always shorter than expected. In most banks two or three causes dominate: a party field arriving as free text from one channel, a reference format that one originator uses, or a purpose code that arrives empty. Each of those is a fix in one place, upstream, that removes a permanent operational cost rather than managing it.
Structured remittance, and why it is under-used
The structured remittance block can carry referenced document types, numbers, amounts and dates as fields rather than as a sentence. It is the element that lets a corporate customer's invoice reference arrive intact and be used as a matching key. It is also the element most often populated correctly and then ignored, because the receiving process was built to read free text and nobody revisited it after the migration.
The check is simple and worth running: take a sample of incoming payments that carry structured remittance and ask whether anything in your reconciliation actually reads it. If the answer is no, the structure your correspondents are sending is being paid for and discarded, and enabling it is configuration rather than a project.
MT is still inside your bank, whatever the network says
The network position and the internal position are different things. Even where MX is the standard on the wire, a bank typically still meets MT on some domestic schemes, in older bilateral arrangements, in internal interfaces built before the migration and across every archive it holds for investigations. Treating MT support as a legacy embarrassment to be removed creates gaps precisely where investigations need to reach. Treating format as an attribute of the source, with parsing retained for as long as any source uses it, costs very little and removes an entire class of avoidable problem.
The background reading is ISO 20022 explained and the CBPR+ migration. The operational companion to this page is payment reconciliation software.
Questions about iso 20022 payments
Do you convert MT to MX or the other way?
Translation belongs in your payments stack. What we do is read both natively for matching and reconciliation, so you do not need a translation step just to reconcile during coexistence.
Will this cut our repair rate?
Repair volume falls when structured data is preserved and used, which is a property of your whole chain, not of one product. What we can do is measure repairs by classification so you can see which upstream field is actually causing them.
Does it handle CBPR+ specifics?
CBPR+ usage guidelines constrain how fields are populated on cross border payments. Matching rules can be written against those constrained fields, which is exactly what makes the structured data useful.
What about Fedwire and FedNow?
US rails have their own ISO 20022 timelines and formats. The Fedwire and FedNow post covers what is different and what it means for reconciliation.