Fedwire — header announces a different message than it carries
The Business Application Header says <MsgDefIdr>pacs.009.001.08</MsgDefIdr> while the document it heads is a pacs.008. Both halves validate against their own schema; only comparing them catches it.
head.001.001.03 + pacs.008.001.08 — Invalid
The Business Application Header says <MsgDefIdr>pacs.009.001.08</MsgDefIdr> while the document it heads is a pacs.008. Both halves validate against their own schema; only comparing them catches it.
What this file shows
The Business Application Header says <MsgDefIdr>pacs.009.001.08</MsgDefIdr> while the document it heads is a pacs.008. Both halves validate against their own schema; only comparing them catches it.
| Transactions | 1 |
|---|---|
| Total | $125,000.00 |
| Date in the file | 2026-11-20 |
The defects it carries
- BAH-MSGDEFIDRThe header announces a different message than the one enclosed
Quoted verbatim from the validator, not paraphrased.
Every party, IBAN and amount below is fictitious. The IBANs are structurally valid — they pass the mod-97 check — but they belong to no real account.
File content
<?xml version="1.0" encoding="UTF-8"?>
<Envelope>
<AppHdr xmlns="urn:iso:std:iso:20022:tech:xsd:head.001.001.03">
<Fr>
<FIId>
<FinInstnId>
<BICFI>CHASUS33XXX</BICFI>
<ClrSysMmbId>
<ClrSysId>
<Cd>USABA</Cd>
</ClrSysId>
<MmbId>021000021</MmbId>
</ClrSysMmbId>
</FinInstnId>
</FIId>
</Fr>
<To>
<FIId>
<FinInstnId>
<BICFI>PNBPUS3NNYC</BICFI>
<ClrSysMmbId>
<ClrSysId>
<Cd>USABA</Cd>
</ClrSysId>
<MmbId>021000089</MmbId>
</ClrSysMmbId>
</FinInstnId>
</FIId>
</To>
<BizMsgIdr>20261120CHASUS33001</BizMsgIdr>
<MsgDefIdr>pacs.009.001.08</MsgDefIdr>
<CreDt>2026-11-20T09:30:00Z</CreDt>
</AppHdr>
<Document xmlns="urn:iso:std:iso:20022:tech:xsd:pacs.008.001.08">
<FIToFICstmrCdtTrf>
<GrpHdr>
<MsgId>20261120CHASUS33001</MsgId>
<CreDtTm>2026-11-20T09:30:00</CreDtTm>
<NbOfTxs>1</NbOfTxs>
<SttlmInf>
<SttlmMtd>CLRG</SttlmMtd>
</SttlmInf>
</GrpHdr>
<CdtTrfTxInf>
<PmtId>
<InstrId>FDW20261120001</InstrId>
<EndToEndId>INV-2026-8842</EndToEndId>
<UETR>7a56b2c4-1f3e-4d9a-b8e5-2c1a9f7d3b60</UETR>
</PmtId>
<IntrBkSttlmAmt Ccy="USD">125000.00</IntrBkSttlmAmt>
<IntrBkSttlmDt>2026-11-20</IntrBkSttlmDt>
<ChrgBr>SHAR</ChrgBr>
<Dbtr>
<Nm>Northwind Manufacturing Inc</Nm>
<PstlAdr>
<StrtNm>West 57th Street</StrtNm>
<BldgNb>240</BldgNb>
<PstCd>10019</PstCd>
<TwnNm>New York</TwnNm>
<CtrySubDvsn>NY</CtrySubDvsn>
<Ctry>US</Ctry>
</PstlAdr>
</Dbtr>
<DbtrAcct>
<Id>
<Othr>
<Id>4417820033</Id>
</Othr>
</Id>
</DbtrAcct>
<DbtrAgt>
<FinInstnId>
<BICFI>CHASUS33XXX</BICFI>
<ClrSysMmbId>
<ClrSysId>
<Cd>USABA</Cd>
</ClrSysId>
<MmbId>021000021</MmbId>
</ClrSysMmbId>
</FinInstnId>
</DbtrAgt>
<CdtrAgt>
<FinInstnId>
<BICFI>PNBPUS3NNYC</BICFI>
<ClrSysMmbId>
<ClrSysId>
<Cd>USABA</Cd>
</ClrSysId>
<MmbId>021000089</MmbId>
</ClrSysMmbId>
</FinInstnId>
</CdtrAgt>
<Cdtr>
<Nm>Pacific Components LLC</Nm>
<PstlAdr>
<StrtNm>Market Street</StrtNm>
<BldgNb>1355</BldgNb>
<PstCd>94103</PstCd>
<TwnNm>San Francisco</TwnNm>
<CtrySubDvsn>CA</CtrySubDvsn>
<Ctry>US</Ctry>
</PstlAdr>
</Cdtr>
<CdtrAcct>
<Id>
<Othr>
<Id>9920014455</Id>
</Othr>
</Id>
</CdtrAcct>
<RmtInf>
<Ustrd>Invoice 8842 - Q4 component delivery</Ustrd>
</RmtInf>
</CdtTrfTxInf>
</FIToFICstmrCdtTrf>
</Document>
</Envelope>
How we know these results hold
Every file in this library is run through the site's own validator on each build. The expected result stated above is asserted by an automated test — if a file stopped matching what this page claims, the build would fail. Two inherited fixtures were repaired this way before publication: three IBANs failed the mod-97 check and several names used characters outside the basic SEPA character set.