[{"data":1,"prerenderedAt":1000},["ShallowReactive",2],{"blog-\u002Fblog\u002Fpain-001-structure-and-fields":3,"blog-related-\u002Fblog\u002Fpain-001-structure-and-fields":978,"blog-surround-\u002Fblog\u002Fpain-001-structure-and-fields":999},{"id":4,"title":5,"audience":6,"body":9,"cluster":925,"conversionGoal":926,"cornerstone":927,"date":928,"description":929,"draft":927,"extension":930,"factCheckedAt":928,"faq":931,"featured":927,"language":926,"meta":944,"minRead":172,"navigation":945,"order":946,"originalAsset":926,"path":947,"pillar":948,"primaryKeyword":949,"publicationOrder":950,"relatedProject":926,"releaseScope":951,"reviewCycle":952,"reviewMethod":953,"reviewStatus":954,"reviewedAt":928,"reviewedBy":955,"searchIntent":956,"seo":957,"sources":958,"stem":971,"tags":972,"type":976,"updated":926,"__hash__":977},"blog\u002Fblog\u002Fpain-001-structure-and-fields.md","pain.001 Structure: The Fields That Actually Matter",[7,8],"treasury-system-lead","solution-architect",{"type":10,"value":11,"toc":916},"minimark",[12,26,31,43,97,104,111,326,341,345,348,422,426,429,552,571,575,578,752,756,767,814,817,824,828,849,852,856,891,894,897,912],[13,14,15,19,20,25],"p",{},[16,17,18],"strong",{},"A pain.001 file has exactly three levels — a GroupHeader that identifies the message, one or more PaymentInformation blocks that carry the debit side, and inside each of those one or more credit transfer transactions that carry the credit side — and once that shape clicks, most of the mapping work becomes deciding which level each piece of your payment data belongs to."," This is the field-level companion to the ",[21,22,24],"a",{"href":23},"\u002Fblog\u002Fiso-20022-payments-pain-001-pain-002","pain.001 and pain.002 overview",": that post explains what the messages are; this one opens the file. I've mapped this format against enough bank implementation guides to know that the ISO definition is the easy half — so alongside the standard structure I'll show where a real bank guide (Nordea's, one of the few you can actually read without an NDA) narrows, repurposes or rejects what the schema allows.",[27,28,30],"h2",{"id":29},"the-three-levels","The three levels",[13,32,33,34,38,39,42],{},"The message is ",[35,36,37],"code",{},"CustomerCreditTransferInitiation"," — root element ",[35,40,41],{},"\u003CCstmrCdtTrfInitn>",". Nordea's implementation guide describes the shape exactly as the standard has it: one message per file, built from three blocks.",[44,45,46,60,77],"ul",{},[47,48,49,55,56,59],"li",{},[16,50,51,52],{},"GroupHeader ",[35,53,54],{},"\u003CGrpHdr>"," — occurs once (",[35,57,58],{},"1..1","). Identifies the message as a whole: who sent it, when, how many transactions, checksum.",[47,61,62,68,69,72,73,76],{},[16,63,64,65],{},"PaymentInformation ",[35,66,67],{},"\u003CPmtInf>"," — occurs one or more times (",[35,70,71],{},"1..n","). The ",[16,74,75],{},"debit side",": which account pays, at which bank, on which date, by which method. Everything shared by a group of payments lives here.",[47,78,79,68,85,87,88,92,93,96],{},[16,80,81,82],{},"CreditTransferTransactionInformation ",[35,83,84],{},"\u003CCdtTrfTxInf>",[35,86,71],{},") ",[89,90,91],"em",{},"inside each"," PaymentInformation. The ",[16,94,95],{},"credit side",": who gets paid, how much, in what currency, with what reference and remittance detail.",[13,98,99,100,103],{},"The mental model that survives contact with real files: ",[16,101,102],{},"the envelope, the debit, the credits",". One file can pay 3 invoices from your EUR account today and 200 salaries from your SEK account on Friday — that's one GroupHeader, two PaymentInformation blocks, 203 transactions. A message can even mix several debtors and accounts, one PmtInf each.",[13,105,106,107,110],{},"Here is an illustrative skeleton assembled from the elements in Nordea's pain.001.001.03 guide. It is ",[16,108,109],{},"not a bank-ready file"," — mandatory identifiers, agreement references and country rules are omitted — but every tag name is real:",[112,113,118],"pre",{"className":114,"code":115,"language":116,"meta":117,"style":117},"language-xml shiki shiki-themes github-light github-dark","\u003CDocument xmlns=\"urn:iso:std:iso:20022:tech:xsd:pain.001.001.03\">\n  \u003CCstmrCdtTrfInitn>\n    \u003CGrpHdr>\n      \u003CMsgId>ACME-20260802-0001\u003C\u002FMsgId>\n      \u003CCreDtTm>2026-08-02T09:30:00+02:00\u003C\u002FCreDtTm>\n      \u003CNbOfTxs>2\u003C\u002FNbOfTxs>\n      \u003CCtrlSum>15000.00\u003C\u002FCtrlSum>\n      \u003CInitgPty>\u003CNm>ACME TREASURY\u003C\u002FNm>\u003C\u002FInitgPty>\n    \u003C\u002FGrpHdr>\n    \u003CPmtInf>\n      \u003CPmtInfId>ACME-20260802-0001-01\u003C\u002FPmtInfId>\n      \u003CPmtMtd>TRF\u003C\u002FPmtMtd>\n      \u003CBtchBookg>true\u003C\u002FBtchBookg>\n      \u003CReqdExctnDt>2026-08-03\u003C\u002FReqdExctnDt>\n      \u003CDbtr>\u003CNm>ACME Oy\u003C\u002FNm>\u003C\u002FDbtr>\n      \u003CDbtrAcct>\u003CId>\u003CIBAN>FI0000000000000000\u003C\u002FIBAN>\u003C\u002FId>\u003C\u002FDbtrAcct>\n      \u003CDbtrAgt>\u003CFinInstnId>\u003CBIC>NDEAFIHH\u003C\u002FBIC>\u003C\u002FFinInstnId>\u003C\u002FDbtrAgt>\n      \u003CChrgBr>SLEV\u003C\u002FChrgBr>\n      \u003CCdtTrfTxInf>\n        \u003CPmtId>\n          \u003CInstrId>INV-4711-P2P\u003C\u002FInstrId>\n          \u003CEndToEndId>INV-4711\u003C\u002FEndToEndId>\n        \u003C\u002FPmtId>\n        \u003CAmt>\u003CInstdAmt Ccy=\"EUR\">7500.00\u003C\u002FInstdAmt>\u003C\u002FAmt>\n        \u003CCdtrAgt>\u003CFinInstnId>\u003CBIC>NDEADKKK\u003C\u002FBIC>\u003C\u002FFinInstnId>\u003C\u002FCdtrAgt>\n        \u003CCdtr>\u003CNm>Supplier A\u002FS\u003C\u002FNm>\u003C\u002FCdtr>\n        \u003CCdtrAcct>\u003CId>\u003CIBAN>DK0000000000000000\u003C\u002FIBAN>\u003C\u002FId>\u003C\u002FCdtrAcct>\n        \u003CRmtInf>\u003CUstrd>Invoice 4711\u003C\u002FUstrd>\u003C\u002FRmtInf>\n      \u003C\u002FCdtTrfTxInf>\n      \u003C!-- more \u003CCdtTrfTxInf> blocks -->\n    \u003C\u002FPmtInf>\n    \u003C!-- more \u003CPmtInf> blocks -->\n  \u003C\u002FCstmrCdtTrfInitn>\n\u003C\u002FDocument>\n","xml","",[35,119,120,128,134,140,146,152,158,164,170,176,182,188,194,200,206,212,218,224,230,236,242,248,254,260,266,272,278,284,290,296,302,308,314,320],{"__ignoreMap":117},[121,122,125],"span",{"class":123,"line":124},"line",1,[121,126,127],{},"\u003CDocument xmlns=\"urn:iso:std:iso:20022:tech:xsd:pain.001.001.03\">\n",[121,129,131],{"class":123,"line":130},2,[121,132,133],{},"  \u003CCstmrCdtTrfInitn>\n",[121,135,137],{"class":123,"line":136},3,[121,138,139],{},"    \u003CGrpHdr>\n",[121,141,143],{"class":123,"line":142},4,[121,144,145],{},"      \u003CMsgId>ACME-20260802-0001\u003C\u002FMsgId>\n",[121,147,149],{"class":123,"line":148},5,[121,150,151],{},"      \u003CCreDtTm>2026-08-02T09:30:00+02:00\u003C\u002FCreDtTm>\n",[121,153,155],{"class":123,"line":154},6,[121,156,157],{},"      \u003CNbOfTxs>2\u003C\u002FNbOfTxs>\n",[121,159,161],{"class":123,"line":160},7,[121,162,163],{},"      \u003CCtrlSum>15000.00\u003C\u002FCtrlSum>\n",[121,165,167],{"class":123,"line":166},8,[121,168,169],{},"      \u003CInitgPty>\u003CNm>ACME TREASURY\u003C\u002FNm>\u003C\u002FInitgPty>\n",[121,171,173],{"class":123,"line":172},9,[121,174,175],{},"    \u003C\u002FGrpHdr>\n",[121,177,179],{"class":123,"line":178},10,[121,180,181],{},"    \u003CPmtInf>\n",[121,183,185],{"class":123,"line":184},11,[121,186,187],{},"      \u003CPmtInfId>ACME-20260802-0001-01\u003C\u002FPmtInfId>\n",[121,189,191],{"class":123,"line":190},12,[121,192,193],{},"      \u003CPmtMtd>TRF\u003C\u002FPmtMtd>\n",[121,195,197],{"class":123,"line":196},13,[121,198,199],{},"      \u003CBtchBookg>true\u003C\u002FBtchBookg>\n",[121,201,203],{"class":123,"line":202},14,[121,204,205],{},"      \u003CReqdExctnDt>2026-08-03\u003C\u002FReqdExctnDt>\n",[121,207,209],{"class":123,"line":208},15,[121,210,211],{},"      \u003CDbtr>\u003CNm>ACME Oy\u003C\u002FNm>\u003C\u002FDbtr>\n",[121,213,215],{"class":123,"line":214},16,[121,216,217],{},"      \u003CDbtrAcct>\u003CId>\u003CIBAN>FI0000000000000000\u003C\u002FIBAN>\u003C\u002FId>\u003C\u002FDbtrAcct>\n",[121,219,221],{"class":123,"line":220},17,[121,222,223],{},"      \u003CDbtrAgt>\u003CFinInstnId>\u003CBIC>NDEAFIHH\u003C\u002FBIC>\u003C\u002FFinInstnId>\u003C\u002FDbtrAgt>\n",[121,225,227],{"class":123,"line":226},18,[121,228,229],{},"      \u003CChrgBr>SLEV\u003C\u002FChrgBr>\n",[121,231,233],{"class":123,"line":232},19,[121,234,235],{},"      \u003CCdtTrfTxInf>\n",[121,237,239],{"class":123,"line":238},20,[121,240,241],{},"        \u003CPmtId>\n",[121,243,245],{"class":123,"line":244},21,[121,246,247],{},"          \u003CInstrId>INV-4711-P2P\u003C\u002FInstrId>\n",[121,249,251],{"class":123,"line":250},22,[121,252,253],{},"          \u003CEndToEndId>INV-4711\u003C\u002FEndToEndId>\n",[121,255,257],{"class":123,"line":256},23,[121,258,259],{},"        \u003C\u002FPmtId>\n",[121,261,263],{"class":123,"line":262},24,[121,264,265],{},"        \u003CAmt>\u003CInstdAmt Ccy=\"EUR\">7500.00\u003C\u002FInstdAmt>\u003C\u002FAmt>\n",[121,267,269],{"class":123,"line":268},25,[121,270,271],{},"        \u003CCdtrAgt>\u003CFinInstnId>\u003CBIC>NDEADKKK\u003C\u002FBIC>\u003C\u002FFinInstnId>\u003C\u002FCdtrAgt>\n",[121,273,275],{"class":123,"line":274},26,[121,276,277],{},"        \u003CCdtr>\u003CNm>Supplier A\u002FS\u003C\u002FNm>\u003C\u002FCdtr>\n",[121,279,281],{"class":123,"line":280},27,[121,282,283],{},"        \u003CCdtrAcct>\u003CId>\u003CIBAN>DK0000000000000000\u003C\u002FIBAN>\u003C\u002FId>\u003C\u002FCdtrAcct>\n",[121,285,287],{"class":123,"line":286},28,[121,288,289],{},"        \u003CRmtInf>\u003CUstrd>Invoice 4711\u003C\u002FUstrd>\u003C\u002FRmtInf>\n",[121,291,293],{"class":123,"line":292},29,[121,294,295],{},"      \u003C\u002FCdtTrfTxInf>\n",[121,297,299],{"class":123,"line":298},30,[121,300,301],{},"      \u003C!-- more \u003CCdtTrfTxInf> blocks -->\n",[121,303,305],{"class":123,"line":304},31,[121,306,307],{},"    \u003C\u002FPmtInf>\n",[121,309,311],{"class":123,"line":310},32,[121,312,313],{},"    \u003C!-- more \u003CPmtInf> blocks -->\n",[121,315,317],{"class":123,"line":316},33,[121,318,319],{},"  \u003C\u002FCstmrCdtTrfInitn>\n",[121,321,323],{"class":123,"line":322},34,[121,324,325],{},"\u003C\u002FDocument>\n",[13,327,328,329,332,333,336,337,340],{},"One detail worth noticing before any field: the ",[16,330,331],{},"namespace is the version",". Nordea's guide is explicit that the ",[35,334,335],{},"xmlns"," value — ",[35,338,339],{},"urn:iso:std:iso:20022:tech:xsd:pain.001.001.03"," — is what identifies the pain.001 version of the message. If your file says one version and your mapping was built for another, nothing else on this page matters yet.",[27,342,344],{"id":343},"groupheader-the-fields-banks-validate-first","GroupHeader: the fields banks validate first",[13,346,347],{},"Four elements do the work here, and they're the ones a status report will quote back at you.",[44,349,350,370,381,402],{},[47,351,352,357,358,360,361,364,365,369],{},[16,353,354],{},[35,355,356],{},"\u003CMsgId>"," (MessageIdentification, ",[35,359,58],{},", max 35 characters) — your identifier for the whole message. Textbook: a unique reference. Reality: it's your ",[16,362,363],{},"idempotency key",". Nordea requires it to be unique per customer for a minimum of 90 calendar days and uses it for duplicate control — send the same MsgId twice and the second file is treated as a duplicate, which is precisely the behaviour you want when a ",[21,366,368],{"href":367},"\u002Fblog\u002Ftreasury-bank-connectivity-swift-host-to-host-api-ebics","host-to-host channel"," retries an upload. Generate it from your payment run, not from a timestamp someone can regenerate.",[47,371,372,377,378,380],{},[16,373,374],{},[35,375,376],{},"\u003CCreDtTm>"," (CreationDateTime, ",[35,379,58],{},") — when the message was created, as an ISO date-time. Not free of validation either: Nordea accepts values back to current date minus 30 calendar days. A test file with last quarter's timestamp fails before anyone looks at a payment.",[47,382,383,388,389,391,392,397,398,401],{},[16,384,385],{},[35,386,387],{},"\u003CNbOfTxs>"," (NumberOfTransactions, ",[35,390,58],{},") and ",[16,393,394],{},[35,395,396],{},"\u003CCtrlSum>"," (ControlSum, ",[35,399,400],{},"0..1",") — the transaction count and the hash total of the instructed amounts, irrespective of currency. The count is validated and the whole message is rejected if it's wrong; the control sum is optional, but if you send it, it's checked with the same consequence. Send it anyway. A rejected file at the gate is cheap; a half-imported one is not.",[47,403,404,409,410,412,413,417,418,421],{},[16,405,406],{},[35,407,408],{},"\u003CInitgPty>"," (InitiatingParty, ",[35,411,58],{},") — who initiated the message, which can be the debtor or a party acting on its behalf: this is where a shared-service centre or ",[21,414,416],{"href":415},"\u002Fblog\u002Fwhat-is-an-in-house-bank","payment factory"," sending on behalf of subsidiaries identifies itself. At Nordea it identifies the ",[89,419,420],{},"signer"," of the message and comes back in the status report.",[27,423,425],{"id":424},"paymentinformation-the-debit-side","PaymentInformation: the debit side",[13,427,428],{},"This level answers: from which account, at which bank, on what date, by what method — for every transaction grouped under it.",[44,430,431,442,461,484,495,521],{},[47,432,433,438,439,441],{},[16,434,435],{},[35,436,437],{},"\u003CPmtInfId>"," (",[35,440,58],{},", max 35) — the batch reference. Same 90-day uniqueness and duplicate control at Nordea as MsgId, and it's echoed in the pain.002 status report and — if you use the bank's reporting — on the account statement. That echo is what stitches a statement debit back to a payment run, so treat the naming scheme as reconciliation design, not as a filler field.",[47,443,444,449,450,452,453,456,457,460],{},[16,445,446],{},[35,447,448],{},"\u003CPmtMtd>"," (PaymentMethod, ",[35,451,58],{},") — ",[35,454,455],{},"TRF"," for credit transfer; Nordea also accepts ",[35,458,459],{},"CHK"," for cheque payments, with country-specific rules about when each is allowed. If you're wondering who still pays by cheque: the field exists because someone does.",[47,462,463,468,469,452,471,474,475,478,479,483],{},[16,464,465],{},[35,466,467],{},"\u003CBtchBookg>"," (BatchBooking, ",[35,470,400],{},[35,472,473],{},"true"," requests one batch booking for the transactions under this PmtInf; ",[35,476,477],{},"false"," requests single bookings. Omit it and the bank's default applies — at Nordea, batch booking for domestic payments, with the cross-border behaviour in a country appendix, and no batch booking at all for relayed Request for Transfer instructions. This single optional flag decides whether your statement shows one consolidated debit or two hundred lines, which is to say it decides how your ",[21,480,482],{"href":481},"\u002Fblog\u002Fbank-statement-formats-mt940-camt053-bai2","reconciliation"," works. Agree it per bank, explicitly.",[47,485,486,491,492,494],{},[16,487,488],{},[35,489,490],{},"\u003CReqdExctnDt>"," (RequestedExecutionDate, ",[35,493,58],{},") — the date the payment should be debited and processed, funds permitting. All transactions under one PmtInf share it — which is the main reason files get split into multiple PmtInf blocks in the first place.",[47,496,497,509,510,512,513,516,517,520],{},[16,498,499,502,503,502,506],{},[35,500,501],{},"\u003CDbtr>"," \u002F ",[35,504,505],{},"\u003CDbtrAcct>",[35,507,508],{},"\u003CDbtrAgt>"," — debtor, debtor account, debtor agent, all ",[35,511,58],{},". The trio looks trivial and is where the bank-specific rules cluster. Nordea requires the debtor's name but then ",[89,514,515],{},"replaces it with the account holder name from its own records"," for payments it executes. The account is IBAN or a local format under ",[35,518,519],{},"\u003COthr>"," — except Finland, where only IBAN is allowed — and the account currency must be present. The debtor agent takes a BIC — except Sweden, where a clearing-system code is an alternative. Three fields, three asterisks, one bank.",[47,522,523,528,529,531,532,535,536,539,540,543,544,539,546,548,549,551],{},[16,524,525],{},[35,526,527],{},"\u003CChrgBr>"," (ChargeBearer, ",[35,530,400],{},") — who pays the charges: ",[35,533,534],{},"DEBT",", ",[35,537,538],{},"SHAR"," or ",[35,541,542],{},"SLEV"," in Nordea's guide (the schema also knows CRED; this guide doesn't offer it — an example of a MIG narrowing the standard). Two rules worth memorising: it belongs on either the payment level or the transaction level but not both, and within the EU\u002FEEA only ",[35,545,538],{},[35,547,542],{}," are accepted — send ",[35,550,534],{}," on an intra-EU payment and it's a rejection, not a warning.",[13,553,554,555,560,561,564,565,570],{},"Same either-level-but-not-both logic applies to ",[16,556,557],{},[35,558,559],{},"\u003CPmtTpInf>"," (PaymentTypeInformation — service level, instruction priority, category purpose such as ",[35,562,563],{},"SALA"," for salaries, which at Nordea is payment-level only) and ",[16,566,567],{},[35,568,569],{},"\u003CUltmtDbtr>"," (UltimateDebtor — on-behalf-of payments; supplying it on both levels gets the file rejected). The pattern to internalise: anything at PaymentInformation level applies to every transaction beneath it, and banks police the redundancy.",[27,572,574],{"id":573},"credittransfertransactioninformation-the-credit-side","CreditTransferTransactionInformation: the credit side",[13,576,577],{},"One block per payment. The fields your accounts-payable data actually populates:",[44,579,580,615,643,678,706],{},[47,581,582,587,588,438,593,391,595,438,600,602,603,606,607,610,611,614],{},[16,583,584],{},[35,585,586],{},"\u003CPmtId>"," with ",[16,589,590],{},[35,591,592],{},"\u003CInstrId>",[35,594,400],{},[16,596,597],{},[35,598,599],{},"\u003CEndToEndId>",[35,601,58],{},") — two references with different lifespans. InstructionIdentification is your ",[89,604,605],{},"point-to-point"," reference to the bank. ",[16,608,609],{},"EndToEndIdentification travels with the payment",": it comes back in the pain.002 status report, in camt.054 debit notifications, and on statements — it's the single field that lets a status or a statement line find its way back to an invoice. Nordea requires it unique per customer for 90 calendar days and runs transaction-level duplicate control on it. The honest caveat, straight from the same guide: it is ",[89,612,613],{},"not"," forwarded on every domestic or international rail, because some local clearings and SWIFT-era infrastructure can't carry it. Design your reconciliation to prefer it, not to depend on it existing everywhere.",[47,616,617,438,622,624,625,630,631,636,637,642],{},[16,618,619],{},[35,620,621],{},"\u003CAmt>",[35,623,58],{},") — one of two shapes: ",[16,626,627],{},[35,628,629],{},"\u003CInstdAmt Ccy=\"...\">",", the amount in the currency the beneficiary should receive, or ",[16,632,633],{},[35,634,635],{},"\u003CEqvtAmt>"," — amount plus ",[16,638,639],{},[35,640,641],{},"\u003CCcyOfTrf>"," — for \"debit my account for the equivalent of X in transfer currency Y\", which Nordea allows only for cross-currency payments. Negative amounts are rejected; decimal and digit limits vary by payment type and country. If you've never seen EquivalentAmount used, you haven't done a cross-currency payment run where the budget was fixed in the debit currency.",[47,644,645,438,650,652,653,658,659,662,663,666,667,535,670,673,674,677],{},[16,646,647],{},[35,648,649],{},"\u003CCdtrAgt>",[35,651,400],{}," here — conditional, not blindly mandatory) — the beneficiary's bank, as a ",[16,654,655],{},[35,656,657],{},"\u003CBIC>"," or as a clearing-system code plus bank name: Nordea's list includes ",[35,660,661],{},"USABA"," (US routing number), ",[35,664,665],{},"GBDSC"," (UK sort code), ",[35,668,669],{},"AUBSB",[35,671,672],{},"CNAPS"," and others. And a rule that surprises people: for SEPA payments identified by IBAN, the creditor agent is ",[89,675,676],{},"ignored"," — the IBAN already routes the payment.",[47,679,680,688,689,694,695,697,698,701,702,705],{},[16,681,682,502,685],{},[35,683,684],{},"\u003CCdtr>",[35,686,687],{},"\u003CCdtrAcct>"," — the beneficiary and their account. Name and country are required; cross-border payments need the town as well, and since the structured-address push you should assume address rules are tightening everywhere, not just here. The account is an ",[16,690,691],{},[35,692,693],{},"\u003CIBAN>"," — mandatory within the EU\u002FEEA for cross-border and SEPA payments in Nordea's guide — or an ",[35,696,519],{}," identification for local schemes, including proprietary codes like ",[35,699,700],{},"BGNR"," (Swedish bankgiro) and ",[35,703,704],{},"OCR"," (Denmark). If you thought pain.001 abolished local account formats, the schema disagrees.",[47,707,708,713,714,716,717,722,723,728,729,732,733,736,737,438,740,743,744,747,748,751],{},[16,709,710],{},[35,711,712],{},"\u003CRmtInf>"," (RemittanceInformation, ",[35,715,400],{},") — what the beneficiary sees, and the field with the widest gap between schema and reality. Structurally: ",[16,718,719],{},[35,720,721],{},"\u003CUstrd>"," free text (each occurrence max 140 characters) or ",[16,724,725],{},[35,726,727],{},"\u003CStrd>"," with referred documents (",[35,730,731],{},"CINV"," invoice \u002F ",[35,734,735],{},"CREN"," credit note, with number and amount) or a ",[16,738,739],{},"creditor reference",[35,741,742],{},"SCOR",", e.g. an ISO 11649 RF reference). The schema says ",[35,745,746],{},"0..n"," occurrences; Nordea's per-country reality says: Denmark up to 1,435 characters of free text, Norway 875, Sweden 140, international payments one occurrence of 140 — and if structured remittance is present, unstructured is dropped. Whatever your ERP exports, the rail decides what arrives. This is exactly the \"richer data\" that makes ISO 20022 worth adopting — ",[21,749,750],{"href":23},"when you actually populate the structured elements"," instead of pasting invoice lists into free text that gets truncated at the border.",[27,753,755],{"id":754},"where-banks-fight-over-the-same-schema","Where banks fight over the same schema",[13,757,758,759,762,763,766],{},"Everything above came from ",[89,760,761],{},"one"," bank's implementation guide, and that's the point: ",[16,764,765],{},"pain.001 is a schema, but a payable file is a schema plus a MIG",". Nordea's guide states openly that elements the service doesn't use are left out of the guide entirely, even when the ISO message definition and the CGI-MP implementation guide include them. Every bank does a version of this. The recurring fight zones, all visible in this walkthrough:",[44,768,769,775,781,787,804],{},[47,770,771,774],{},[16,772,773],{},"Identification style."," BIC vs clearing codes vs IBAN-only routing; which local account formats are allowed where.",[47,776,777,780],{},[16,778,779],{},"Level discipline."," Charge bearer, payment type information and ultimate debtor accepted at payment level, transaction level, or either-but-not-both — with rejection as the penalty for both.",[47,782,783,786],{},[16,784,785],{},"Defaults."," Batch booking, service levels and charge codes all have bank defaults that apply when you're silent, and they differ per bank and per country.",[47,788,789,792,793,535,796,799,800,803],{},[16,790,791],{},"Field length and content."," Remittance limits per country; characters like ",[35,794,795],{},"¤",[35,797,798],{},"-"," and ",[35,801,802],{},"\u002F"," that Nordea warns it will convert to spaces to avoid clearing rejections. Your reference format survives some rails and not others.",[47,805,806,809,810,813],{},[16,807,808],{},"Regulatory add-ons."," ",[35,811,812],{},"\u003CRgltryRptg>"," (RegulatoryReporting) is optional in the schema and mandatory at Nordea for international payments above 100,000 NOK from Norway or 150,000 SEK from Sweden. The schema can't tell you that; only the MIG can.",[13,815,816],{},"And it isn't only banks: schemes layer rules on top too. In SWIFT's CBPR+ Standards Release 2026, change request CR 3014 formalises a rule that the PaymentInformationIdentification must match the MessageIdentification in the GroupHeader for the interbank pain.001 relay — a constraint no schema validator would ever tell you about. CGI-MP exists precisely to shrink this variation in the corporate-to-bank space, and guides like Nordea's are written against it; it narrows the fight, it doesn't end it.",[818,819,821],"callout",{"type":820},"tip",[13,822,823],{},"Build your pain.001 mapping in two layers: a clean ISO 20022 layer that populates the structure correctly, and a thin per-bank layer that applies each MIG's restrictions — allowed codes, levels, lengths, defaults. When bank number four arrives, you change the thin layer, not the model.",[27,825,827],{"id":826},"versions-and-the-pain002-echo","Versions, and the pain.002 echo",[13,829,830,831,834,835,838,839,843,844,848],{},"Two closing facts that save arguments. First, versions: Nordea's guide implements ",[16,832,833],{},"pain.001.001.03",", the CustomerCreditTransferInitiationV03 defined in the 2009 payments maintenance that CGI-MP built its recommendations on — while the ISO 20022 catalogue is now at ",[16,836,837],{},"pain.001.001.13"," (CustomerCreditTransferInitiationV13), with older versions kept in the message archive and communities encouraged toward recent ones. In the corporate-to-bank world you will meet old versions for years; the namespace tells you which one you're holding, and your bank's MIG tells you which one to send. The interbank world moves on ",[21,840,842],{"href":841},"\u002Fblog\u002Fiso-20022-migration-mt-to-mx","its own clocks"," — including the ",[21,845,847],{"href":846},"\u002Fblog\u002Fmt101-vs-mt103-vs-mt202","MT101 relay's retirement into a pain.001 relay in November 2026",".",[13,850,851],{},"Second, the identifiers are the contract with pain.002. Nordea's reference table maps them one-to-one: MsgId, PmtInfId and EndToEndId each come back at the corresponding level of the status report, and PmtInfId and EndToEndId flow onward into camt.054 debit notifications. That's the field-level answer to \"pain.001 vs pain.002\": the same three references, outbound and inbound. Design them well in the pain.001 and the status handling builds itself; design them lazily and every rejection becomes a research project.",[27,853,855],{"id":854},"what-usually-goes-wrong","What usually goes wrong",[44,857,858,864,870,876,885],{},[47,859,860,863],{},[16,861,862],{},"Timestamps and counts treated as decoration."," CreationDateTime outside the accepted window, NbOfTxs off by one, a stale MsgId — all message-level rejections before a single payment is looked at.",[47,865,866,869],{},[16,867,868],{},"Duplicated levels."," Charge bearer or ultimate debtor on both payment and transaction level; some banks reject the file for redundancy the schema happily allows.",[47,871,872,875],{},[16,873,874],{},"Assuming EndToEndId always arrives."," It's the backbone reference, and some rails still drop it. Check per payment type, not per bank.",[47,877,878,881,882,848],{},[16,879,880],{},"One mapping for all banks."," The schema is shared; the MIGs aren't. Budget a mapping-and-test cycle per bank, same as any ",[21,883,884],{"href":367},"connectivity project",[47,886,887,890],{},[16,888,889],{},"Remittance built for the schema, not the rail."," 999 structured occurrences validate beautifully and arrive as 140 truncated characters.",[13,892,893],{},"The structure is genuinely simple — envelope, debit, credits. The craft is in respecting what each bank's guide does to it.",[895,896],"hr",{},[13,898,899],{},[89,900,901,902,904,905,908,909,848],{},"See also the ",[21,903,24],{"href":23},", the ",[21,906,907],{"href":841},"ISO 20022 migration from MT to MX",", and ",[21,910,911],{"href":846},"MT101 vs MT103 vs MT202",[913,914,915],"style",{},"html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html.dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}",{"title":117,"searchDepth":130,"depth":130,"links":917},[918,919,920,921,922,923,924],{"id":29,"depth":130,"text":30},{"id":343,"depth":130,"text":344},{"id":424,"depth":130,"text":425},{"id":573,"depth":130,"text":574},{"id":754,"depth":130,"text":755},{"id":826,"depth":130,"text":827},{"id":854,"depth":130,"text":855},"connectivity",null,false,"2026-08-02","Inside the pain.001 file: GroupHeader, PaymentInformation and the transaction level — which fields treasury maps, and where bank implementations differ.","md",[932,935,938,941],{"question":933,"answer":934},"What are the three levels of a pain.001 file?","A pain.001 (CustomerCreditTransferInitiation) has three nested blocks. GroupHeader (GrpHdr) appears once and identifies the whole message: MsgId, CreationDateTime, NumberOfTransactions, ControlSum, InitiatingParty. PaymentInformation (PmtInf) repeats and carries the debit side: the debtor, debtor account and debtor agent, payment method, requested execution date. CreditTransferTransactionInformation (CdtTrfTxInf) repeats inside each PmtInf and carries the credit side: EndToEndId, amount, creditor, creditor account, creditor agent and remittance information.",{"question":936,"answer":937},"What is EndToEndId used for in pain.001?","EndToEndIdentification is the mandatory per-transaction reference the debtor assigns. It travels with the payment and comes back in the pain.002 status report and in debit notifications and statements, which is what lets you match a status or a statement line back to the exact payment you sent. Banks also use it for duplicate control — Nordea, for example, requires it to be unique per customer for at least 90 calendar days. One caveat from the same guide: some local clearings and legacy rails don't forward it all the way.",{"question":939,"answer":940},"What is batch booking in pain.001?","BatchBooking (BtchBookg) is an indicator on the PaymentInformation level that tells the bank how to book the debit side: true requests one batch booking covering the transactions grouped under that PmtInf, false requests a single booking per transaction. It changes what you reconcile on the bank statement — one consolidated debit versus one line per payment. If you omit it, the bank's default applies, and defaults differ by bank and payment type, so agree it explicitly.",{"question":942,"answer":943},"Which version of pain.001 should I use?","The one your bank's implementation guide specifies — the version is identified by the XML namespace, e.g. urn:iso:std:iso:20022:tech:xsd:pain.001.001.03. Many bank guides in the corporate-to-bank space are still written on pain.001.001.03, the version from the 2009 payments maintenance that CGI-MP built on, while the ISO 20022 catalogue has moved on to CustomerCreditTransferInitiationV13 and recommends recent versions. In practice corporates run whatever versions their banks accept, which usually means the older one.",{},true,4.05,"\u002Fblog\u002Fpain-001-structure-and-fields","treasury-systems-architecture","pain.001 structure",189,"pain.001 element usage is version- and bank-specific: the walkthrough follows a pain.001.001.03 bank implementation guide (Nordea, CGI-MP aligned), while the ISO catalogue is at CustomerCreditTransferInitiationV13 and scheme rulebooks add their own rules. Verify every field against your own banks' MIGs before build.","on ISO 20022 \u002F bank format changes","editorial-and-factual","reviewed","Tan Gravam","informational",{"title":5,"description":929},[959,962,965,968],{"title":960,"url":961,"accessed":928},"Nordea — Message Implementation Guidelines, pain.001.001.03 (Corporate Access Payables, MIG v2.4)","https:\u002F\u002Fwww.nordea.com\u002Fen\u002Fdoc\u002Fnordea-message-implementation-guide-cap-pain.001.001.03.pdf",{"title":963,"url":964,"accessed":928},"ISO 20022 — Message definitions catalogue (Payments Initiation)","https:\u002F\u002Fwww.iso20022.org\u002Fiso-20022-message-definitions",{"title":966,"url":967,"accessed":928},"SWIFT — ISO 20022: Corporates (FAQ)","https:\u002F\u002Fwww.swift.com\u002Fstandards\u002Fiso-20022\u002Fiso-20022-faqs\u002Fcorporates",{"title":969,"url":970,"accessed":928},"SWIFT — ISO 20022 in bytes: Call to action for November 2026","https:\u002F\u002Fwww.swift.com\u002Fstandards\u002Fiso-20022\u002Fiso-20022-bytes\u002Fcall-action-november-2026","blog\u002Fpain-001-structure-and-fields",[973,974,975],"treasury","payments","bank-connectivity","text","QDqsU8C1q14na1sLvaX4CKCh7HBWpkCsI-Wz0oI1gj8",{"related":979,"prev":992,"next":994,"hasOrder":945,"place":996},[980,984,988],{"path":981,"title":982,"description":983},"\u002Fblog\u002Fswift-gpi-tracking-cross-border-payments","SWIFT gpi: Tracking Cross-Border Payments","SWIFT gpi makes cross-border payments faster and trackable end to end, giving each a unique reference (UETR) so you can follow its status. What treasury gets.",{"path":985,"title":986,"description":987},"\u002Fblog\u002Freal-time-treasury","Real-Time Treasury: What It Actually Means","Real-time treasury is the shift from batch to continuous operations, driven by instant payments and APIs. What changes, and where it genuinely matters vs batch.",{"path":989,"title":990,"description":991},"\u002Fblog\u002Fbank-connectivity-security","Bank Connectivity Security: Keys, Certificates and Controls","The security layer under treasury bank connectivity: certificate and key lifecycle, mTLS, OAuth, key rotation, HSM, SWIFT CSP, and who owns the technical user.",{"path":23,"title":993,"type":976,"language":926},"ISO 20022 Payments Explained: pain.001 and pain.002",{"path":841,"title":995,"type":976,"language":926},"ISO 20022 Migration: Moving from SWIFT MT to MX (CBPR+)",{"label":997,"position":160,"total":184,"hub":998},"Connectivity","\u002Ftopics\u002Ftreasury-systems-architecture",[],1785696768075]