Every pain.001 transaction may carry remittance information in one of two shapes: *structured* (the <RmtInf>/<Strd> block, with sub-elements like <CdtrRefInf>/<Ref> for an ISO 11649 SCOR reference or <Cd>QRR</Cd> for a Swiss QRR) or *unstructured* (the <RmtInf>/<Ustrd> block, up to 140 characters of free text).
The structured form is the right default for any new integration. It is machine-readable, mod-97 (SCOR) or mod-10 (QRR) checksum-protected, and is preserved end-to-end through every ISO 20022 rail. The reconciliation moat in iso-compliant (the carrier-field catalog) treats structured remittance as the highest-confidence candidate.
The unstructured form is the legacy fallback. It is human-readable but not machine-parseable without per-tenant regex. The corruption rate (line truncation at 140 characters, character-set folding, intermediary modifications) is non-trivial. The reconciliation engine still extracts candidates from <Ustrd> (see apps/api/src/lib/recon-key-extract.ts) but ranks them below structured carriers.
A pain point worth flagging: many banks' legacy corporate-channel UIs only expose the unstructured field, so corporates end up jamming structured-shape references into a free-text field. The customer-side fix is to populate <Strd> *in addition to* <Ustrd> — most pain.001 builders, including iso-compliant's, allow both.
iso-compliant's pain.001 builder accepts a remittance object with either structured (an SCOR / QRR reference) or unstructured (a free-text string) or both. When both are supplied, the structured form is emitted in <Strd> and the free-text form is emitted in <Ustrd> so the downstream camt.053 reconciliation has the maximum carrier surface to match against.