SWIFT MT to ISO 20022 CBPR+ Migration Auditor

ISO 20022 Migration Audit Report

Repository: N/A (inline artifacts)
Commit: N/A
Audit scope: MT192 → camt.056.001.08 (Recall)
CBPR+ baseline: UHB v5
Files audited: 3 (CODE: 1, FIXTURE: 2, CONFIG: 0)
Line-number provenance: counted from pasted text (Camt056Builder.cs)
Audit timestamp: 2026-09-21T00:00:00Z

Executive summary

Audited the MT192→camt.056 recall builder plus the sample inbound MT192 and generated camt.056 output. Confirmed the reported linkage failure: OrgnlUETR is never populated anywhere in the build path (C-20, CRITICAL), and Assgnmt/Cretr is hardcoded to a literal BIC instead of being parsed from MT field 11S/11R (MAP-01, CRITICAL), silently corrupting assignor data for any originator other than BANKUS33XXX. The MT 72 reason sub-code wrapper is passed through unstripped into CxlRsnInf/Prtry (MAP-02, HIGH), and the settlement amount is serialized with a culture-unaware .ToString() immediately next to a date parse that correctly uses InvariantCulture (C-10, HIGH). Overall risk posture: HIGH — the builder emits schema-shaped but semantically unlinkable and partly corrupted recall messages.

Finding counts: CRITICAL: 3 | HIGH: 3 | MEDIUM: 0 | LOW: 1

CRITICAL findings

[C-20] camt.056 recall not linked to the original payment via OrgnlUETR

• File: Camt056Builder.cs:12-21 (pasted, Build method, TxInf construction)
• Evidence:

doc.TxInf.OrgnlIntrBkSttlmAmt = new Amount {
    Value = mt.Field32A.Amount.ToString(),
    Ccy = mt.Field32A.Currency
};
doc.TxInf.OrgnlIntrBkSttlmDt = DateTime.ParseExact(
    mt.Field32A.ValueDate, "yyMMdd", CultureInfo.InvariantCulture
).ToString("yyyy-MM-dd");
doc.TxInf.CxlRsnInf = new CxlRsnInf {
    Rsn = new Reason { Prtry = mt.Field72 }
};

• Impact: Per §8.3, TxInf/OrgnlUETR is the element that lets the correspondent/clearing house match the recall back to the original credit transfer. No OrgnlUETR assignment exists anywhere in Build(), and the generated camt.056 sample confirms it is absent from the output. This is exactly the defect the downstream clearing house flagged: recalls carry Case/Id (a free-text reference) but no machine-linkable transaction identifier, so automated matching against the original pacs.008/MT103 fails or falls back to fragile string matching on Case/Id.
• Fix: Thread the original transaction's UETR through from wherever it is captured when the original payment was sent/received (e.g., a lookup keyed on mt.Field21 or a stored UETR-to-reference index), and set doc.TxInf.OrgnlUETR before returning doc. If the UETR is genuinely unavailable to this service, that is itself a data-flow gap that must be closed upstream — it cannot be omitted silently.
• Verification: CONFIRMED

[MAP-01] Assgnmt/Cretr hardcoded to a literal BIC instead of parsed from MT 11S/11R

• File: Camt056Builder.cs:7
• Evidence: doc.Assgnmt.Cretr = new Party { Bic = "BANKUS33XXX" };
• Impact: Per §8.3, Assgnmt/Cretr is sourced from MT field 11S/11R, not from a fixed constant. The sample input happens to carry :52A:BANKUS33XXX, making the hardcoded value coincidentally match — but the code never reads mt.Field11S or mt.Field11R at all. Any recall processed through this builder from a different creator institution will silently emit the wrong Cretr BIC while still validating against the XSD, producing schema-valid but factually false assignment data on every message that isn't from BANKUS33XXX.
• Fix: Parse mt.Field11S (or the appropriate creator-identifying field per your MT192 model) and map it to doc.Assgnmt.Cretr.Bic. Remove the literal. Add a unit test asserting Cretr varies with a non-BANKUS33XXX fixture.
• Verification: CONFIRMED

[C-09] Amount type/serialization path not confirmed float-safe

• File: Camt056Builder.cs:13
• Evidence: Value = mt.Field32A.Amount.ToString(),
• Impact: If mt.Field32A.Amount is a float/double anywhere upstream in the Mt192/Field32A model (not shown in the pasted artifacts), this is a CRITICAL rounding/precision defect for settlement amounts. The pasted snippet does not show the declared type of Amount, so this cannot be confirmed either way from what was provided.
• Fix: Confirm Field32A.Amount is decimal (or an equivalent fixed-point type) end-to-end from MT parsing through to this builder. If it is ever cast through float/double, replace with decimal.
• Verification: UNVERIFIED (type of mt.Field32A.Amount not shown in provided code)

HIGH findings

[MAP-02] MT 72 reason sub-code wrapper passed through unextracted into CxlRsnInf/Prtry

• File: Camt056Builder.cs:19-20
• Evidence: Rsn = new Reason { Prtry = mt.Field72 }
• Impact: §8.3 explicitly states for field 72→CxlRsnInf/Prtry: "extract the reason text, do not pass the raw sub-code wrapper." The builder assigns mt.Field72 verbatim, and the generated sample output confirms <Prtry>/REASON/FRAUD SUSPECTED</Prtry> — the /REASON/ wrapper is included rather than stripped. Downstream systems and the clearing house that expect a clean proprietary reason string (per CBPR+ usage) may reject, mis-file, or fail to route the recall reason correctly — plausibly contributing to the structural non-conformance the clearing house flagged.
• Fix: Strip the /REASON/ (and any other) sub-code delimiter before assignment, e.g. Prtry = ExtractSubCodeText(mt.Field72, "REASON"), and only fall back to the raw string if no recognized sub-code wrapper is present.
• Verification: CONFIRMED

[C-10] Settlement amount serialized without explicit invariant culture

• File: Camt056Builder.cs:13
• Evidence: Value = mt.Field32A.Amount.ToString(),
• Impact: .ToString() with no format provider uses the current thread culture. On a host configured with a comma-decimal locale (common in many European deployments), this would emit 50000,00 into an XML numeric element expecting a dot-decimal value — malformed per ISO 20022 numeric typing. This is a real inconsistency in the file itself: three lines later, DateTime.ParseExact(...) correctly passes CultureInfo.InvariantCulture, but the amount serialization does not.
• Fix: Value = mt.Field32A.Amount.ToString(CultureInfo.InvariantCulture).
• Verification: CONFIRMED

[C-08] Currency not visibly validated against ISO 4217

• File: Camt056Builder.cs:14
• Evidence: Ccy = mt.Field32A.Currency
• Impact: No ISO 4217 validation is visible at the point Ccy is assigned. If mt.Field32A.Currency can carry an invalid, lowercase, or non-list code (e.g., XXX) unvalidated through to this builder, the resulting OrgnlIntrBkSttlmAmt/@Ccy would be non-conformant. The validation could plausibly exist in the (unseen) MT192/Field32A parsing layer.
• Fix: Confirm and, if absent, add an ISO 4217 active-code-list check either in the MT192 parser or immediately before this assignment.
• Verification: UNVERIFIED (validation, if any, would live in code not provided)

MEDIUM findings

None found.

LOW findings

[LOW-01] OrgnlGrpInf/OrgnlMsgNmId hardcoded to a fixed literal

• File: Camt056Builder.cs:11
• Evidence: doc.OrgnlGrpInf.OrgnlMsgNmId = "pacs.008.001.08";
• Impact: This value is fixed regardless of input, while MT fields 11S/11R (MT192) indicate the original message context. Section 8.3 does not map any MT field to OrgnlGrpInf/OrgnlMsgNmId, so this cannot be asserted as a confirmed mapping defect against the provided ground truth — but a hardcoded literal in a field named "original message name" is a maintainability/correctness risk if this builder is ever reused for recalls of non-pacs.008-originated payments.
• Fix: If this builder is intentionally scoped to pacs.008-only recalls, document that constraint in code (a named constant with a comment). If not, derive the value from the actual original message type.
• Verification: UNVERIFIED (target element not covered by §8.3 ground truth; cannot confirm intended source)

Mapping gaps (fields silently dropped)

Truncation risks

No .substring(N)/.slice(N)-style truncation patterns were present in the pasted Camt056Builder.cs. No truncation-risk findings identified.

Character set and encoding issues

None found. The only free-text field observed (mt.Field72 → CxlRsnInf/Prtry) contains plain ASCII with no &, <, >, or " characters requiring XML escaping in this sample, and no X-charset validation is applied to any MX field in the pasted code.

Structured address readiness

Not applicable. The camt.056 FIToFIPmtCxlReq recall flow audited here carries no party postal address elements (no PstlAdr/AdrLine in either the MT192 input or the camt.056 output); §11 structured-address rules do not apply to this artifact set.

Files audited

• Camt056Builder.cs — CODE_BUILDER — 7 findings (C-20, MAP-01, C-09, MAP-02, C-10, C-08, LOW-01)
• Sample inbound MT192 (pasted) — FIXTURE — 0 findings (evidence source only)
• Sample generated camt.056 output (pasted) — FIXTURE — 0 findings (corroborating evidence for Camt056Builder.cs findings above; not double-counted)

Out-of-scope artefacts skipped

None. All three pasted artifacts (MT192 fixture, camt.056 fixture, Camt056Builder.cs) are in-scope per section 4.