rust_iso20022 0.1.4

ISO 20022 financial message parser and generated Rust types for SWIFT MX XML/JSON.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68

# MT103 to pacs.008.001.08

The `mt103` migration feature converts a bounded parsed MT103 into the existing
generated `pacs.008.001.08::Document`. The generated document remains the only
canonical ISO 20022 model; the MT syntax tree and mapping report are transient
migration evidence.

```rust
use rust_iso20022_migration::mt103;

let input = "{4:\n:20:REF-1\n:32A:260928EUR1,00\n-}";
let conversion = mt103::convert(input)?;
let generated = conversion.message;
let report = conversion.mapping_report;
# Ok::<(), mt103::Mt103Error>(())
```

Enable the converter with
`rust_iso20022_migration = { version = "0.1.2", features = ["mt103"] }`.

## Mapping table

| MT103 tag | pacs.008.001.08 target | Classification | Current behavior |
|---|---|---|---|
| `20` | `GrpHdr/MsgId`, `PmtId/EndToEndId`, `PmtId/TxId` | Derived | One reference supplies three identifiers. |
| `23B` | none | Unsupported | Reported and retained as an unmapped source. |
| `32A` | `IntrBkSttlmDt`, `IntrBkSttlmAmt/@Ccy`, `IntrBkSttlmAmt` | Ambiguous | Splits date, currency, and amount. The two-digit year is explicitly interpreted as `20YY`, so manual review remains required. |
| `50K` | `Dbtr`, `DbtrAcct/Id/IBAN` | Lossy | Maps validated IBAN and name; address lines are not mapped. |
| `52A` | `DbtrAgt/FinInstnId/BICFI` | Exact | Supports a direct validated 8- or 11-character BIC only. |
| `57A` | `CdtrAgt/FinInstnId/BICFI` | Exact | Supports a direct validated 8- or 11-character BIC only. |
| `59` | `Cdtr`, `CdtrAcct/Id/IBAN` | Lossy | Maps validated IBAN and name; address lines are not mapped. |
| `70` | `RmtInf/Ustrd` | Exact | Maps the preserved unstructured value. |
| `71A` | `ChrgBr` | Derived | `OUR` → `DEBT`, `BEN` → `CRED`, `SHA` → `SHAR`; other values are typed failures. |
| `72` | none | Ambiguous | Requires manual interpretation and remains unmapped. |
| any other tag | none | Unsupported | Appears in the report and in `unmapped_fields`. |

Every parsed block-4 field receives exactly one mapping entry. Ambiguous and
unsupported fields are also listed in `unmapped_fields`; lossy fields emit a
value-free warning. The report includes source positions but never copies
account numbers, names, references, or free text.

## Validation and limits

`32A` must contain an ASCII `YYMMDD`, an uppercase three-letter supported ISO
4217 currency, and a valid amount. Calendar dates, amount precision, IBANs, and
BICs are checked through the core SDK helper types before generated fields are
created. Invalid financial values return a typed, value-free `Mt103Error` and
do not panic.

The converter inherits all limits from the migration parser: 1 MiB input,
nesting depth 8, 16 blocks, 512 fields, 64 KiB per field, and 256 continuation
lines per field.

## Known limitations

- The fixed `20YY` interpretation is a documented provisional policy, not an
  assertion that the source century is known.
- Structured party addresses and optional party identifiers in `50K`, `52A`,
  `57A`, and `59` are not reconstructed.
- Field `23B` and sender-to-receiver information in `72` are not converted.
- The converter does not claim full FIN conformance, semantic equivalence, or
  lossless migration.
- A successful conversion and implemented L2 validation do not guarantee bank
  or network acceptance, regulatory certification, onboarding approval, or
  legal compliance.

The checked fixture set is in `fixtures/migration/mt103/`; its expected report
explicitly records every classification, warning, and unmapped tag.