Why SWIFT Message Testing Is Not the Same as Workflow Testing
Most trade finance UAT confirms that a SWIFT message is generated at the right workflow stage. What it does not confirm is whether the message content is correct at the field level — whether mandatory fields are populated, whether field formats comply with SWIFT standards, and whether the content of the message accurately reflects the underlying trade finance transaction.
A correspondent bank that receives an MT700 with a truncated Field 45A (description of goods) or an incorrect Field 31D (expiry date/place) will reject the message or, worse, process it against the wrong terms. SWIFT field-level accuracy is not a technical concern — it is a business correctness concern that only surfaces when the counterparty bank processes the message.
MT700 Series — Letters of Credit
SW-MT700-001
MT700 field content accuracy
Field 40A (form of credit), 31D (expiry date/place), 32B (amount), 45A (goods description), 46A (documents required) — verify content matches LC application. Not just: message is generated.
SW-MT700-002
MT707 amendment reference
Field 20 (sender's reference) and 21 (related reference) must correctly link the amendment to the original MT700. Wrong reference number causes counterparty bank to process against wrong LC.
SW-MT700-003
MT734 discrepancy reason
Field 77J must contain specific, accurate discrepancy descriptions — not generic codes. System must not auto-populate placeholder text. Correspondent bank decision depends on this field.
SW-MT700-004
MT754 payment amount
Field 32B (currency and amount) must match the complying presentation amount, not the original LC amount. Partial drawings must reflect the amount presented, not the LC face value.
MT760 Series — Guarantees and Standby LCs
SW-MT760-001
MT760 applicable rules
Field 40C must correctly reflect the applicable rules — URDG 758, ISP98, or local law. System must not default all guarantees to URDG. Standby LCs are typically ISP98 or UCP 600.
SW-MT760-002
MT767 guarantee amendment
Extension of guarantee must generate MT767 with updated expiry date. Amount increase must include beneficiary acceptance confirmation where required under URDG 758.
SW-MT760-003
MT769 release advice
Generated on guarantee closure after full payment or expiry with no demand. Must reconcile to original MT760 amount minus any prior partial demands processed.
SW-MT760-004
Counter-guarantee linkage
MT760 from issuing bank to correspondent must carry reference that links to the underlying guarantee. Correspondent's own MT760 to beneficiary must carry both references.
MT202 — Bank-to-Bank Cover Payments
MT202 (and its variant MT202 COV) is used for bank-to-bank cover payments in trade finance — the payment leg that settles between correspondent banks when an LC or guarantee payment is made. It is the most frequently misconfigured payment message in trade finance UAT.
- Field 52A/52D (ordering institution): Must carry the issuing bank's BIC, not the applicant's details. Confusing issuing bank with applicant is a consistent configuration error.
- Field 57A (account with institution): The beneficiary's correspondent bank — must be derived from the LC advising bank, not defaulted to a generic correspondent
- MT202 COV: Required for payments where the underlying transaction involves a third party — the COV variant carries the originator and beneficiary details for AML screening; using plain MT202 where COV is required is a compliance gap
- Value date: Must match the LC payment date — not the system processing date, which may differ by one or two days depending on cut-off times
Common UAT Gap
MT202 COV vs. plain MT202 selection is almost never tested as a distinct scenario. Teams test that a payment message is generated; they do not test whether the correct variant is selected based on the underlying transaction type. MT202 COV compliance gaps are flagged by correspondent banks during live operations, not during UAT.
ISO 20022 MX — What to Test During Migration
SWIFT's migration from MT to MX (ISO 20022) messages is underway across the global banking community. Banks implementing or upgrading core banking systems now need to handle both MT and MX formats during the coexistence period, and UAT needs to reflect this.
MX Migration test areas
Parallel MT/MX message generation during coexistence · Translation accuracy between MT and MX field mappings (data elements that have no direct MT equivalent must be handled, not dropped) · Character set differences — MX supports Unicode; MT is restricted to the SWIFT character set · Truncation handling — MX fields allow longer content than MT equivalents; truncation rules when converting MX to MT must be tested · Structured vs. unstructured address handling — MX requires structured postal addresses; mapping from unstructured MT address fields must be validated
Field-Level Validation Test Approach
SWIFT field-level testing requires a different approach from workflow testing. For each message type, the test plan needs to specify:
- Which fields are mandatory under SWIFT standards vs. conditional vs. optional
- What the correct content derivation rule is for each field — where does the system read the data from, and is that the right source
- What character set restrictions apply to each field
- What the maximum field length is and how truncation is handled
- What the expected ACK/NAK response is from SWIFT, and how the system handles a NAK
SWIFT MT/MX test coverage built into Bankly domain packs
MT700 series · MT760 series · MT202/COV · Field-level validation · ISO 20022 MX coexistence
Get in Touch →