R25 — Rails and ISO 20022: integrating with external systems whose rules you cannot change

Rails differ on three axes that drive architecture: settlement speed, reversibility, and batch versus real time. Everything else is detail.

Payment lifecycle and where the rails differ

flowchart LR
  I["initiated"] --> V["validated<br/>+ sanctions / fraud screening"] --> A["authorized"] --> SU["submitted"] --> AK["acknowledged"] --> SE["settled"]
  SE --> RT["returned"]
  SE --> RV["reversed"]
  V -->|"screening hit"| PK["parked — never silently failed"]
  SU -->|"irrevocable rail:<br/>no take-backs"| SE
  RT -->|"ACH returns arrive days later"| REOPEN["Reopen a settled payment"]

ISO 20022 message families

flowchart LR
  CUST["Corporate / customer"] -->|"pain.001 initiation"| BK1["Debtor agent"]
  BK1 -->|"pain.002 status"| CUST
  BK1 -->|"pacs.008 credit transfer (MT103 replacement)"| BK2["Creditor agent"]
  BK2 -->|"pacs.002 status"| BK1
  BK2 -->|"pacs.004 return"| BK1
  BK1 -->|"camt.053 statement"| RECON["Your reconciliation"]
  BK1 -->|"camt.054 notification"| RECON

Rail	Speed	Reversible?	Architectural consequence
Card (auth/capture)	Auth in ms, settle T+1 or later	Yes — chargebacks for months	Two-phase money: holds, partial capture, expiry, dispute handling
ACH / NACHA	Batch windows, same-day options	Returns arrive days later with reason codes	Windows and cutoffs drive your schedule; late returns must reopen a settled payment
RTP / UPI / FedNow	Sub-second	No	All risk work moves before the send; screening sits in the hot path
Cross-border (correspondent)	Hours to days	Partially, by recall request	Multi-hop, FX, fees deducted en route, status arrives asynchronously

ISO 20022 in one pass. An XML standard replacing SWIFT MT, organised by business domain. The families you must recognise:

pain (payment initiation, customer to bank): pain.001 credit transfer initiation, pain.002 status report back to the customer, pain.008 direct debit initiation.
pacs (clearing and settlement, bank to bank): pacs.008 customer credit transfer — the MT103 replacement, pacs.009 FI-to-FI transfer, pacs.002 status, pacs.004 payment return.
camt (cash management): camt.052 intraday report, camt.053 end-of-day statement — this is your reconciliation input, camt.054 debit/credit notification, camt.056 cancellation request.

Details that signal fluency. Every payment carries a UETR, a unique end-to-end reference that lets you track and query it across hops — this is what you use in the timeout-after-debit recovery. Structured addresses and richer remittance data are the point of the migration, and the industry has been moving off unstructured formats. A Business Application Header wraps the message. Cross-border migration off MT ran through a coexistence period that ended in late 2025, so "we still translate MT for some corridors" is a realistic thing to say.

Design implication to state out loud. Validation, enrichment and screening happen on initiation, before the message enters the clearing flow, because a pacs.008 on an irrevocable rail cannot be recalled. On a batch rail you can afford a repair queue; on RTP you cannot. That one sentence shows you understand the domain rather than the format.

What to say in the interview

"Rails differ on three axes that actually change the architecture: settlement speed, reversibility, and batch versus real time. Irrevocable rails move all the risk work before the send — screening and validation sit in the hot path, because there's no repair queue after a pacs.008 is accepted. On a batch rail like ACH I can afford a repair queue, but I have to handle returns arriving days later and reopening a settled payment. ISO 20022 gives me the structure and the UETR, which is what makes the timeout-after-debit recovery and reconciliation possible at all."