[{"data":1,"prerenderedAt":802},["ShallowReactive",2],{"blog-\u002Fblog\u002Fmt940-format-tags-explained":3,"blog-related-\u002Fblog\u002Fmt940-format-tags-explained":778,"blog-surround-\u002Fblog\u002Fmt940-format-tags-explained":801},{"id":4,"title":5,"audience":6,"body":9,"cluster":731,"conversionGoal":732,"cornerstone":733,"date":734,"description":735,"draft":733,"extension":736,"factCheckedAt":734,"faq":737,"featured":733,"language":732,"meta":750,"minRead":751,"navigation":752,"order":753,"originalAsset":732,"path":754,"pillar":755,"primaryKeyword":756,"publicationOrder":757,"relatedProject":732,"releaseScope":758,"reviewCycle":759,"reviewMethod":760,"reviewStatus":761,"reviewedAt":734,"reviewedBy":762,"searchIntent":763,"seo":764,"sources":765,"stem":772,"tags":773,"type":66,"updated":732,"__hash__":777},"blog\u002Fblog\u002Fmt940-format-tags-explained.md","MT940 Format: The Tags, Line by Line",[7,8],"treasury-system-lead","solution-architect",{"type":10,"value":11,"toc":720},"minimark",[12,36,44,49,57,60,70,89,93,104,110,116,139,143,153,218,225,229,232,238,241,387,390,396,410,416,438,446,449,455,462,466,475,482,559,562,568,575,579,588,598,604,607,611,614,634,637,641,690,697,700],[13,14,15,19,20,25,26,30,31,35],"p",{},[16,17,18],"strong",{},"MT940 is the SWIFT Customer Statement Message — the tagged flat-file end-of-day statement — and the whole format is a short chain of tags: a message reference (:20:), the account (:25:), a statement number (:28C:), an opening balance (:60a:), one :61: statement line per booked entry with an optional :86: information block under it, and the closing balances (:62a:, :64:, :65:)."," If you're choosing between statement formats, that's the ",[21,22,24],"a",{"href":23},"\u002Fblog\u002Fbank-statement-formats-mt940-camt053-bai2","MT940 vs camt.053 vs BAI2 comparison","; if your file is XML, you want the ",[21,27,29],{"href":28},"\u002Fblog\u002Fcamt-053-structure-and-fields","camt.053 field walkthrough","; if it's a US flat file, the ",[21,32,34],{"href":33},"\u002Fblog\u002Fbai2-file-format-explained","BAI2 record walkthrough",". This post is for the day an MT940 is in front of you and you need to know what each tag and subfield actually holds — verified against a bank's published implementation (Nordea's MT940 service description), because SWIFT's own specification sits behind the user handbook login.",[13,37,38,39,43],{},"And no, this isn't archaeology. The CBPR+ interbank coexistence period ended in November 2025, but the corporate-to-bank space runs on its own clock: SWIFT's SCORE participants can continue exchanging MTs like MT940 after the cutover, and migration is not yet mandatory for corporates — the ",[21,40,42],{"href":41},"\u002Fblog\u002Fmt101-vs-mt103-vs-mt202","MT retirement timeline post"," untangles the different clocks. MT940s keep landing in import folders every morning, which is why the tag-level detail still earns its keep.",[45,46,48],"h2",{"id":47},"the-shape-of-the-message","The shape of the message",[13,50,51,52,56],{},"An MT940 is a SWIFT FIN message: blocks delimited by curly braces, with the statement data living in block 4 as a sequence of tags, each on its own line, each starting with a colon-wrapped tag number. The character set is deliberately narrow — uppercase A–Z, digits, and a short list of punctuation (",[53,54,55],"code",{},"\u002F - ? : ( ) . , ' +"," plus space and line breaks). No lowercase, no accents, and that constraint alone explains a lot of shouting beneficiary names in statement archives.",[13,58,59],{},"The tag sequence:",[61,62,67],"pre",{"className":63,"code":65,"language":66},[64],"language-text",":20:   transaction reference number   mandatory   16x\n:21:   related reference              optional    16x\n:25:   account identification         mandatory   35x\n:28C:  statement\u002Fsequence number      mandatory   5n[\u002F5n]\n:60a:  opening balance (F or M)       mandatory   1!a6!n3!a15d\n:61:   statement line                 repeating, one per entry\n:86:   information to account owner   optional, follows its :61:\n:62a:  closing balance (F or M)       mandatory   1!a6!n3!a15d\n:64:   closing available balance      optional    1!a6!n3!a15d\n:65:   forward available balance      optional    1!a6!n3!a15d\n","text",[53,68,65],{"__ignoreMap":69},"",[13,71,72,73,76,77,80,81,84,85,88],{},"The format notation is SWIFT's own shorthand, and you only need four readings of it here: ",[53,74,75],{},"6!n"," is exactly six digits, ",[53,78,79],{},"16x"," is up to sixteen characters, ",[53,82,83],{},"15d"," is a decimal amount whose decimal comma is mandatory, and ",[53,86,87],{},"6*65x"," (coming up in :86:) is up to six lines of 65 characters. Square brackets mean optional.",[45,90,92],{"id":91},"_20-21-25-28c-the-header-tags",":20:, :21:, :25:, :28C: — the header tags",[13,94,95,98,99,103],{},[16,96,97],{},":20: Transaction Reference Number"," (16x, mandatory) is the reference assigned by the sender to unambiguously identify the ",[100,101,102],"em",{},"message"," — not the statement, the message. One statement split across three messages has three different :20: values. Store it for support calls; don't key on it.",[13,105,106,109],{},[16,107,108],{},":21: Related Reference"," (16x, optional) — rarely interesting on a statement; present in the structure.",[13,111,112,115],{},[16,113,114],{},":25: Account Identification"," (35x, mandatory) is the account for which the statement is sent. The format is generous on purpose: banks put IBANs, domestic account numbers, sometimes BIC-prefixed constructions in here. Your importer's account-matching logic should treat it as an opaque string mapped per bank, not parse it.",[13,117,118,121,122,126,127,130,131,134,135,138],{},[16,119,120],{},":28C: Statement Number\u002FSequence Number"," (5n",[123,124,125],"span",{},"\u002F5n",", mandatory) is the sequential number of the statement, optionally followed by the sequence number of the message within that statement when one statement spans several messages: ",[53,128,129],{},"28C:235\u002F1",", then ",[53,132,133],{},"28C:235\u002F2",". Two operational facts from Nordea's description worth wiring into an importer. First, the statement number resets to 1 on 1 January each year — so a gap check must tolerate the year-end wrap, or it will page someone every New Year's morning. Second, when downloading files, the sequence numbers will not necessarily arrive sorted — reassemble on :28C:, never on arrival order. This is MT940's version of the gap check I recommend on camt.053's ",[53,136,137],{},"ElctrncSeqNb",": a missed statement is a silently wrong cash position, and the statement number is the free detector.",[45,140,142],{"id":141},"_60a-opening-balance",":60a: — opening balance",[13,144,145,146,149,150,152],{},"Format ",[53,147,148],{},"1!a6!n3!a15d",", mandatory, and the little ",[53,151,21],{}," in :60a: means the tag comes in two variants — :60F: (first opening balance) and :60M: (intermediate opening balance, for multi-message statements; more below). The subfields, in order:",[154,155,156,172],"table",{},[157,158,159],"thead",{},[160,161,162,166,169],"tr",{},[163,164,165],"th",{},"Subfield",[163,167,168],{},"Format",[163,170,171],{},"Content",[173,174,175,187,197,208],"tbody",{},[160,176,177,181,184],{},[178,179,180],"td",{},"D\u002FC mark",[178,182,183],{},"1!a",[178,185,186],{},"D or C — which side the balance sits",[160,188,189,192,194],{},[178,190,191],{},"Date",[178,193,75],{},[178,195,196],{},"YYMMDD",[160,198,199,202,205],{},[178,200,201],{},"Currency",[178,203,204],{},"3!a",[178,206,207],{},"ISO 4217 code",[160,209,210,213,215],{},[178,211,212],{},"Amount",[178,214,83],{},[178,216,217],{},"Decimal comma mandatory",[13,219,220,221,224],{},"The rule that matters: ",[16,222,223],{},":60a: must always equal field :62a: of the previous customer statement message for this account."," That's the integrity check the format hands you for free — previous closing equals current opening, and opening plus the signed sum of :61: lines equals closing. When either fails you have a missing statement or a broken file, and you want the importer to say so before the cash position ships.",[45,226,228],{"id":227},"_61-the-statement-line-subfield-by-subfield",":61: — the statement line, subfield by subfield",[13,230,231],{},"This is the tag the whole format exists for: one :61: per booked entry, everything packed into a single line with almost no delimiters. The format string, exactly as specified:",[61,233,236],{"className":234,"code":235,"language":66},[64],"6!n[4!n]2a[1!a]15d1!a3!c16x[\u002F\u002F16x][34x]\n",[53,237,235],{"__ignoreMap":69},[13,239,240],{},"Nine subfields, in fixed order:",[154,242,243,257],{},[157,244,245],{},[160,246,247,250,252,254],{},[163,248,249],{},"#",[163,251,165],{},[163,253,168],{},[163,255,256],{},"What it holds",[173,258,259,272,288,302,317,328,342,355,371],{},[160,260,261,264,267,269],{},[178,262,263],{},"1",[178,265,266],{},"Value date",[178,268,75],{},[178,270,271],{},"YYMMDD — the date that drives position and interest",[160,273,274,277,280,285],{},[178,275,276],{},"2",[178,278,279],{},"Entry date",[178,281,282],{},[123,283,284],{},"4!n",[178,286,287],{},"Booking date, MMDD — optional, and note: no year",[160,289,290,293,296,299],{},[178,291,292],{},"3",[178,294,295],{},"Debit\u002Fcredit mark",[178,297,298],{},"2a",[178,300,301],{},"D, C, RC or RD (see below)",[160,303,304,307,310,314],{},[178,305,306],{},"4",[178,308,309],{},"Funds code",[178,311,312],{},[123,313,183],{},[178,315,316],{},"Optional third character of the currency code",[160,318,319,322,324,326],{},[178,320,321],{},"5",[178,323,212],{},[178,325,83],{},[178,327,217],{},[160,329,330,333,336,339],{},[178,331,332],{},"6",[178,334,335],{},"Transaction type ID code",[178,337,338],{},"1!a3!c",[178,340,341],{},"S\u002FN\u002FF family plus three characters (see below)",[160,343,344,347,350,352],{},[178,345,346],{},"7",[178,348,349],{},"Reference for account owner",[178,351,79],{},[178,353,354],{},"The customer-side reference; NONREF when none is available",[160,356,357,360,363,368],{},[178,358,359],{},"8",[178,361,362],{},"Account servicer's reference",[178,364,365],{},[123,366,367],{},"\u002F\u002F16x",[178,369,370],{},"The bank's own reference, after a double slash; may be omitted for bank-initiated transactions",[160,372,373,376,379,384],{},[178,374,375],{},"9",[178,377,378],{},"Supplementary details",[178,380,381],{},[123,382,383],{},"34x",[178,385,386],{},"Free text; when subfield 7 is NONREF the bank should provide the best available alternative here",[13,388,389],{},"Three of these deserve more than a table row.",[13,391,392,395],{},[16,393,394],{},"The debit\u002Fcredit mark is two characters wide for a reason."," Besides D and C there are RC — reversal of credit, which books as a debit entry — and RD, reversal of debit, which books as a credit. A parser that only knows D and C will either reject reversal lines or, worse, book them on the wrong side. Reversals are rare enough to survive testing and common enough to corrupt a live position.",[13,397,398,401,402,405,406,409],{},[16,399,400],{},"Subfield 7 is the reconciliation handle."," For debit entries its purpose is to identify, to the account owner, the instruction that caused the debit — this is where the reference you supplied with your payment comes back to you, MT940's modest ancestor of the ",[53,403,404],{},"EndToEndId"," round trip in ",[21,407,408],{"href":28},"pain.001 and camt.053",". Sixteen characters, no structure, and NONREF when the bank has nothing — at which point subfield 9's supplementary details are the consolation prize.",[13,411,412,415],{},[16,413,414],{},"The transaction type identification code"," (subfield 6) is the entry's classification, and it comes in three families:",[417,418,419,426,432],"ul",{},[420,421,422,425],"li",{},[16,423,424],{},"S"," + three digits: the SWIFT message type behind the entry, 100–999.",[420,427,428,431],{},[16,429,430],{},"N"," + three characters: a code from a standard list of several dozen three-letter codes (TRF, CHG, INT, DDT, STO, MSC and their kin) for entries arising from payment and transfer instructions.",[420,433,434,437],{},[16,435,436],{},"F"," + three characters: entries originated by the account servicing institution itself.",[13,439,440,441,445],{},"Nordea's description then adds its own codes on top for cash-pool bookings — CMZ (zero balancing), CMS (sweeping), CMT (topping) — which is worth pausing on: even the classification code, the most machine-readable thing in the file, grows bank-specific extensions. When an ",[21,442,444],{"href":443},"\u002Fblog\u002Felectronic-bank-statement-processing-in-sap","electronic bank statement run in SAP"," picks a posting rule for an MT940 line, this code is the external transaction code it keys on. It's doing the job camt.053's Bank Transaction Code does — with four characters instead of a curated three-level taxonomy, which is a fair summary of the two formats' relationship.",[13,447,448],{},"Here's a real line from Nordea's sweeping example, with the packing on display:",[61,450,453],{"className":451,"code":452,"language":66},[64],":61:0509070908D494031,34NCMZTOP\u002FSWEEPSVERIGE GBPAX DANMARK A\u002FS\n",[53,454,452],{"__ignoreMap":69},[13,456,457,458,461],{},"Read it with the table: value date 050907, entry date 0908, D for debit, amount 494031,34, transaction type NCMZ (a zero-balancing sweep), customer reference ",[53,459,460],{},"TOP\u002FSWEEPSVERIGE",", and the counterparty name riding in supplementary details. No delimiters between any of them — the only way to cut that line correctly is to apply the format definition left to right.",[45,463,465],{"id":464},"_86-information-to-account-owner-and-why-its-bank-specific",":86: — information to account owner, and why it's bank-specific",[13,467,145,468,470,471,474],{},[53,469,87],{}," — up to six lines of 65 characters — optional, attached to the :61: line it follows. And here is the sentence this post exists to say plainly: ",[16,472,473],{},"the standard defines the size of :86:, not its structure."," What goes into those 390 characters, and in what layout, is decided bank by bank. Everything below is Nordea's implementation, shown as a worked example — not \"the MT940 :86: format\", because there is no such thing.",[13,476,477,478,481],{},"Nordea structures the field as ",[53,479,480],{},"\u002FCode\u002FInformation"," pairs, with these codes:",[154,483,484,494],{},[157,485,486],{},[160,487,488,491],{},[163,489,490],{},"Code",[163,492,493],{},"Content (per Nordea's service description)",[173,495,496,504,512,520,528,536,544,551],{},[160,497,498,501],{},[178,499,500],{},"CHGS",[178,502,503],{},"Currency code and \"OUR\" charges",[160,505,506,509],{},[178,507,508],{},"OCMT",[178,510,511],{},"Original currency and amount",[160,513,514,517],{},[178,515,516],{},"EXCH",[178,518,519],{},"Exchange rate",[160,521,522,525],{},[178,523,524],{},"ORDP",[178,526,527],{},"Ordering party",[160,529,530,533],{},[178,531,532],{},"BENM",[178,534,535],{},"Beneficiary party",[160,537,538,541],{},[178,539,540],{},"TRMT",[178,542,543],{},"Amount to beneficiary",[160,545,546,549],{},[178,547,548],{},"RATE",[178,550,519],{},[160,552,553,556],{},[178,554,555],{},"REMI",[178,557,558],{},"Remittance information",[13,560,561],{},"For its sweeping services the first :86: line switches to a fixed layout instead — transaction code (CMZ, CMS or CMT), account number, customer reference, beneficiary or payer name:",[61,563,566],{"className":564,"code":565,"language":66},[64],":86:CMZ\u002F20496116759120\u002FTOP\u002FSWEEPSVERIGE\u002FGBPAX DANMARK A\u002FS\n",[53,567,565],{"__ignoreMap":69},[13,569,570,571,574],{},"Two implementations inside one bank's :86:, and neither is portable. Another bank will use different codes, a different sub-structure, or plain prose. This is the concrete mechanism behind the ",[21,572,573],{"href":23},"format comparison's"," verdict that MT940's weakness is structure: the remittance information, counterparty names and FX details that camt.053 carries in typed XML elements live here in a free-text field whose layout is a per-bank convention. Every MT940 auto-matching rate I've seen quoted is really a statement about how well someone reverse-engineered each bank's :86: — so treat that parser as per-bank deliverable work, written from the bank's implementation guide and tested against production statements, never copied from the last project.",[45,576,578],{"id":577},"_62a-64-65-the-closing-balances",":62a:, :64:, :65: — the closing balances",[13,580,581,584,585,587],{},[16,582,583],{},":62a: Closing balance"," — mandatory, same ",[53,586,148],{}," structure as :60a:, same F\u002FM split: :62F: is the final closing balance, :62M: an intermediate one. The chaining rule from the opening balance, stated from the other end: the content of this field will be repeated in field :60a: of the subsequent customer statement message for this account.",[13,589,590,593,594,597],{},[16,591,592],{},":64: Closing available balance"," — optional. The definition has more teeth than \"available\": funds which are available to the account owner if the balance is credit, ",[100,595,596],{},"or the balance which is subject to interest charges"," if it is debit. Booked versus available is the difference between what the ledger says and what you can actually spend today — same distinction camt.053 makes with its CLBD\u002FCLAV balance codes.",[13,599,600,603],{},[16,601,602],{},":65: Forward available balance"," — optional. Funds available to the account owner (credit or debit balance) for a specified forward value date — a small forward-looking window in an end-of-day format.",[13,605,606],{},"Both availability tags are optional, and whether a given bank sends them is an implementation fact, not a standard one. If your cash position needs available figures, confirm per bank before you design for them.",[45,608,610],{"id":609},"multi-message-statements-how-f-and-m-chain","Multi-message statements: how F and M chain",[13,612,613],{},"A busy account outgrows one message, and the format's answer is mechanical. The statement number stays fixed while the :28C: sequence number increments, and the balance variants mark the pieces:",[417,615,616,622,628],{},[420,617,618,621],{},[16,619,620],{},"First message:"," opens :60F:, closes :62M:",[420,623,624,627],{},[16,625,626],{},"Intermediate messages:"," :60M: … :62M:",[420,629,630,633],{},[16,631,632],{},"Final message:"," :60M: … :62F: — the last message of the statement must contain :62F:",[13,635,636],{},"The statement and sequence numbers are what let the receiver put the messages back into sequence and form the complete statement — remembering the earlier warning that downloaded files won't necessarily arrive in sequence order. An importer that treats every message as a self-contained statement will double-count balances on the first busy day; key the reassembly on :28C: and only trust :62F: as the day's closing figure.",[45,638,640],{"id":639},"what-usually-goes-wrong","What usually goes wrong",[417,642,643,649,655,661,667,684],{},[420,644,645,648],{},[16,646,647],{},"Treating :86: as standard."," It's bank-specific by construction. One parser per bank, written from that bank's guide, tested on that bank's production files.",[420,650,651,654],{},[16,652,653],{},"Only handling D and C."," RC and RD exist, and each books on the opposite side of its name. Reversals in the debit\u002Fcredit mark are the classic year-two production incident.",[420,656,657,660],{},[16,658,659],{},"Skipping the balance chain check."," Previous :62a: must equal current :60a:, and :60a: plus the signed :61: lines must equal :62a:. Two comparisons, and they catch missing statements and truncated files before the position is wrong.",[420,662,663,666],{},[16,664,665],{},"A gap check that forgets 1 January."," The statement number resets to 1 at the start of the year (in Nordea's implementation) — build the wrap into the check.",[420,668,669,672,673,675,676,679,680,683],{},[16,670,671],{},"Parsing amounts with a decimal point."," The ",[53,674,83],{}," format's decimal comma is mandatory. ",[53,677,678],{},"494031,34"," is the format; a locale-naive ",[53,681,682],{},"parseFloat"," reads it as something else entirely.",[420,685,686,689],{},[16,687,688],{},"Trusting arrival order."," Sequence numbers in downloaded files aren't necessarily sorted. Reassemble multi-message statements on :28C:.",[13,691,692,693,696],{},"The tags themselves have been stable for decades — that stability is exactly why MT940 still flows in the corporate-to-bank space while the interbank world has moved on. The craft, as with ",[21,694,695],{"href":28},"camt.053",", is never in the standard's skeleton; it's in the bank-specific corners — :86: layouts, code extensions, which optional tags actually arrive — and all of that is written down per bank. Get each bank's MT940 description, diff it against what your importer consumes, and the format holds few surprises after that.",[698,699],"hr",{},[13,701,702],{},[100,703,704,705,708,709,708,712,715,716,719],{},"See also ",[21,706,707],{"href":23},"bank statement formats: MT940 vs camt.053 vs BAI2",", ",[21,710,711],{"href":28},"the camt.053 field walkthrough",[21,713,714],{"href":443},"electronic bank statement processing in SAP",", and ",[21,717,718],{"href":41},"MT101 vs MT103 vs MT202",".",{"title":69,"searchDepth":721,"depth":721,"links":722},2,[723,724,725,726,727,728,729,730],{"id":47,"depth":721,"text":48},{"id":91,"depth":721,"text":92},{"id":141,"depth":721,"text":142},{"id":227,"depth":721,"text":228},{"id":464,"depth":721,"text":465},{"id":577,"depth":721,"text":578},{"id":609,"depth":721,"text":610},{"id":639,"depth":721,"text":640},"connectivity",null,false,"2026-08-03","Every MT940 tag explained: :20:, :25:, :28C:, the :61: statement line subfield by subfield, the bank-specific :86:, and the :62a:\u002F:64:\u002F:65: balances.","md",[738,741,744,747],{"question":739,"answer":740},"What do the subfields in the MT940 :61: statement line mean?","A :61: line packs up to nine subfields into one string, in fixed order: value date (six digits, YYMMDD), an optional entry date (four digits, MMDD, no year), the debit\u002Fcredit mark (D, C, RC or RD), an optional funds code (the third character of the currency code), the amount (decimal comma, no thousands separators), the transaction type identification code (a letter S, N or F plus three characters), the reference for the account owner (up to 16 characters, or NONREF when the bank has none), then optionally the bank's own reference after a double slash, and up to 34 characters of supplementary details. Everything runs together with no separators except the \u002F\u002F before the bank reference, so a parser has to work from the format definition, not from delimiters.",{"question":742,"answer":743},"Is the MT940 :86: field standardized?","Only its size: up to six lines of 65 characters of 'information to account owner', attached to the :61: line above it. How that space is structured is a bank-by-bank decision. Nordea, for example, populates it with \u002FCode\u002FInformation pairs using codes like ORDP (ordering party), BENM (beneficiary party), OCMT (original currency and amount) and REMI (remittance information), and uses a different fixed layout for cash-pool sweeping entries. Another bank will structure it differently, or not at all. Any parser or reconciliation rule that reads :86: is bank-specific work, and each bank's implementation guide is the only reliable description of what will be in it.",{"question":745,"answer":746},"What is the difference between :60F: and :60M: in MT940?","The letter marks the message's place in a multi-part statement. When one statement is too long for a single message, it is split, and the balance tags chain the parts: the first message opens with :60F: (first opening balance) and closes with :62M: (intermediate closing balance), middle messages use :60M: and :62M:, and the final message uses :60M: and closes with :62F: (final closing balance). The :28C: statement and sequence numbers tell you which part you are holding. A single-message statement simply uses :60F: and :62F:.",{"question":748,"answer":749},"What are fields :64: and :65: in an MT940?","They are the available-balance tags, both optional and both in the same format as the booked balances. :64: is the closing available balance — per Nordea's service description, the funds available to the account owner if the balance is credit, or the balance subject to interest charges if it is debit. :65: is the forward available balance: the funds available to the account owner for a specified forward value date. Whether you receive them at all depends on the bank, so a cash position that needs available rather than booked figures has to be confirmed against each bank's implementation, not assumed from the standard.",{},11,true,3.3,"\u002Fblog\u002Fmt940-format-tags-explained","treasury-systems-architecture","mt940 format",194,"Tag formats, subfields and codes verified against Nordea's published MT940 service description; SWIFT's own MT940 specification sits behind the user handbook and is not reproduced here. The :86: layout and several code sets are bank-specific — your bank's implementation guide is the contract.","on ISO 20022 \u002F bank format changes","editorial-and-factual","reviewed","Tan Gravam","informational",{"title":5,"description":735},[766,769],{"title":767,"url":768,"accessed":734},"Nordea — Account Statement Service MT940 file description","https:\u002F\u002Fwww.nordea.com\u002Fen\u002Fdoc\u002F2010-05-31accountstatementservicemt940en.pdf",{"title":770,"url":771,"accessed":734},"SWIFT — ISO 20022: Corporates (FAQ)","https:\u002F\u002Fwww.swift.com\u002Fstandards\u002Fiso-20022\u002Fiso-20022-faqs\u002Fcorporates","blog\u002Fmt940-format-tags-explained",[774,775,776],"treasury","bank-connectivity","integration","eOL_c97Eaks-Fom0i6tMzItXw07woo6KMUnhv3DLk4g",{"related":779,"prev":791,"next":794,"hasOrder":752,"place":796},[780,783,787],{"path":41,"title":781,"description":782},"MT101 vs MT103 vs MT202: Which SWIFT Message Does What","MT101 is a corporate's payment instruction, MT103 a bank-to-bank customer transfer, MT202 an interbank transfer. How they differ and what replaced them.",{"path":784,"title":785,"description":786},"\u002Fblog\u002Fiso-20022-payments-pain-001-pain-002","ISO 20022 Payments Explained: pain.001 and pain.002","ISO 20022 is the global XML standard for financial messaging. For payments, pain.001 is the instruction you send and pain.002 the status back. What they are.",{"path":788,"title":789,"description":790},"\u002Fblog\u002Fpain-001-structure-and-fields","pain.001 Structure: The Fields That Actually Matter","Inside the pain.001 file: GroupHeader, PaymentInformation and the transaction level — which fields treasury maps, and where bank implementations differ.",{"path":792,"title":793,"type":66,"language":732},"\u002Fblog\u002Fcamt-054-notification-explained","camt.054: The Debit\u002FCredit Notification and When You Need It",{"path":33,"title":795,"type":66,"language":732},"BAI2 File Format: Records, Type Codes and How to Read One",{"label":797,"position":798,"total":799,"hub":800},"Connectivity",6,15,"\u002Ftopics\u002Ftreasury-systems-architecture",[],1785752414131]